Sur le plan de la configuration initiale, Nuxeo est aussi en tête. Une fois l'application lancée, on s'y connecte, et on personnalise les réglages via l'interface web directement. Du côté d'Alfresco, rien n'est prévu pour faciliter la configuration au moment du déploiement. Il faut éditer un fichier de configuration à la main dans le quel on indique des chemins de fichiers, des informations de connexions pour le serveur de bases de données, etc. De même seul Nuxeo prévoit un menu d'administration complet gérant entre autres choses les patch de mises à jour, et le redémarrage de l'application.

Mais tout ça n'est pas grand chose. Finalement, on ne passe pas son temps à installer et configurer une application. La différence se fait sur l'usage.

En terme d'ergonomie, c'est Nuxeo qui remporte la palme. L'interface est enrichie de fonctions en AJAX, qui permettent par exemple de déplacer un document d'une catégorie à une autre par glisser-déposer, ou bien d'envoyer des documents directement à partir de votre ordinateur vers Nuxeo. Alfresco quant à lui est très en dessous. Tout d'abord il est livré sous la forme de deux applications Alfresco d'un côté, et Share de l'autre. La première se rapproche un peu de Nuxeo DM, mais sans l'AJAX. Pour faire la moindre choses il faut multiplier les clics, c'est assez pénible. La seconde, Share, est plutôt orientée utilisateur final, publication, média "sociaux". Elle propose l'import de documents par glissé-déposé comme Nuxeo, mais elle manque de sobriété. Les documents sont présentés par défaut sous forme de liste de grosses icones aussi inélégantes qu'encombrantes. De nombreuses actions peuvent être faites aussi bien dans Alfresco que dans Share, mais pas toutes. Par exemple je peux utiliser des noms de tags dans le champs de recherche de Share, alors que cela ne fonctionne pas dans Alfresco. Finalement quand on veut faire quelque chose, il faut d'abord se souvenir dans la quelle des deux applications c'est possible (et le plus simple) et s'y connecter. C'est juste n'importe quoi.

La recherche des documents est aussi une dimension importante de la GED. Elle repose sur une indexation du contenu des documents, sur des métadonnées, sur une organisation. J'ai tendance à considérer que l'organisation physique des documents ne doit pas trop peser dans la balance. Il n'y a qu'une manière de classer une facture médicale. Doit-on la ranger dans le dossier "facture", dans le dossier "facture" du dossier "santé" ou dans le dossier "santé" du dossier "facture" ?
Je préfère de loin un système de tags ou de catégories qui me permette d'accoler plus d'une étiquette à un document, et surtout de retrouver tel ou tel document en combinant ces étiquettes dans un champ de recherche. Les tags dans Nuxeo sont assez accessibles. On en ajoute facilement, mais je ne peux pas chercher un document en tapant un ou plusieurs tags dans le champs de recherche. Les tags sont très bien cachés dans Alfresco, et ils sont inutilisables par défaut. A contrario, sans Share les tags sont accessibles, et on peut les utiliser facilement pour une recherche. Malheureusement, il est alors impossible de préciser qu'on souhaite chercher uniquement dans les tags, ce qui réduit l'intérêt de la chose.

La gestion des sauvegardes d'un entrepôt de données est primordiale. Nuxeo étant par défaut entièrement inclus dans un répertoire unique, il n'y a que deux choses importantes à sauvegarder pour que l'application puisse repartir rapidement en cas de désastre : le répertoire de l'application, et la base de données. J'ai déjà un script qui sauvegarde automatiquement mes bases MySQL, mais comme expliqué plus haut, MySQL n'est pas une option. Garder Nuxeo impliquerait donc d'apprendre à gérer des sauvegardes PostgreSQL (dump, rétention, archivage, et restauration), en plus de l'administration courante.
Alfresco est fragmenté, et nécessite un peu plus de préparation pour gérer les sauvegardes, en contrepartie, son support de MySQL m'assure une sauvegarde fonctionnelle immédiatement, et des archives que je sais restaurer sans lire le manuel. Alfresco bénéficie aussi d'un mécanisme de réplication, ce qui permet de bénéficier d'un second serveur de secours (ou de proximité) en cas de panne du serveur habituel.

Au bout du compte, j'ai l'impression que Nuxeo reste une solution intéressante. Ses points faibles ne sont pas si dramatiques, même si pour moi une bonne recherche par tags est primordiale. Alfresco propose des fonctionnalités appétissantes comme la réplication de serveur, une interface orientée utilisateur permettant la recherche par tags (Share). Mais le manque de glisser-déposer et glisser-déplacer, ainsi que le très grand nombre de clics pour la moindre action sont de vrais handicaps dans la phase de remplissage.
Malheureusement pour Nuxeo, je n'ai pas une minute à consacrer à l'apprentissage de PostgreSQL, ce qui laisse une chance à Alfresco de se faire une place sur mon serveur. Comme la migration d'un système à l'autre est totalement illusoire, voire impossible, je vais me laisser encore le temps de la réflexion, avant de charger et classer des centaines de documents dans l'un ou l'autre.

C'est Noël ! Dommage que mes congés soient terminés...

#!/bin/sh

# PROVIDE: nuxeo
# REQUIRE: DAEMON
# BEFORE: LOGIN

# Define these nuxeo_* variables in one of these files:
#       /etc/rc.conf
#       /etc/rc.conf.local
#
# DO NOT CHANGE THESE DEFAULT VALUES HERE
#
nuxeo_enable="${nuxeo_enable-NO}"
nuxeo_user="${nuxeo_user-nuxeo}"
nuxeo_home="/CHEMIN/DE/nuxeo"

. /etc/rc.subr

name="nuxeo"
rcvar=`set_rcvar`
start_cmd=${name}_start
stop_cmd=${name}_stop

nuxeo_start()
{
cd $nuxeo_home
$nuxeo_auditflags sudo -u $nuxeo_user ./bin/nuxeoctl startbg
}

nuxeo_stop()
{
cd $nuxeo_home
sudo -u $nuxeo_user ./bin/nuxeoctl stop
}

load_rc_config $name

run_rc_command "$1"

Une fois le fichier créé, rempli, et rendu exécutable, il faut ajouter ces quelques lignes à votre fichier /etc/rc.conf :

nuxeo_enable="YES"
nuxeo_user="NUXEO_USER"

Vous remplacerez bien sûr NUXEO_USER par le nom du compte utilisateur qui fera tourner l'application Nuxeo DM. Après cela, les commandes /usr/local/etc/rc.d/nuxeo restart, /usr/local/etc/rc.d/nuxeo stop et /usr/local/etc/rc.d/nuxeo start doivent fonctionner.
Attention, suivant la puissance de votre machine, et l'état de remplissage de Nuxeo, le temps de lancement peut varier énormément.

Côté mise à jour, vous pouvez accéder aux "hotfix" officiels, gratuitement pendant 30 jours, moyennant une inscription sur le site web de Nuxeo. L'inscription se passe facilement, par contre les mise à jour sont délicates et nécessitent de suivre scrupuleusement les instructions du support Nuxeo. Notamment, relancez bien l'application entre chaque mise à jour.

Il existe plusieurs moyens de présenter Nuxeo DM au travers d'un proxy Apache. J'ai choisi d'utiliser mod_proxy. Avec mod_proxy, la configuration est assez standard. Tout, ou presque, est réglé en 3 lignes si on se contente de l'HTTP. Mais pour sécuriser mes connexions à Nuxeo, qui contiendra mes documents personnels et confidentiels, j'ai décidé d'utiliser HTTPS.
J'ai donc un virtual host Apache, et un certificat SSL associé, dans le quel j'inclue les directives de mod_proxy.

<VirtualHost IP.DU.SER.VEUR:443>
   ServerName DOMAINE.TLD:443
   UseCanonicalName On
   DocumentRoot "/chemin/de/nuxeo/"

   SSLEngine on
   #... config SSL ...

   RequestHeader append nuxeo-virtual-host "https://DOMAINE.TLD/"
   <IfModule proxy_module>
     ProxyRequests Off
     <Proxy *>
        Order deny,allow
        Allow from all
     </Proxy>
     ProxyPass /nuxeo/ http://localhost:8080/nuxeo/
     ProxyPassReverse /nuxeo/ http://localhost:8080/nuxeo/
     ProxyPreserveHost On
   </IfModule>

</VirtualHost>

Ça c'est d'après la documentation. En réalité, ce n'est pas suffisant. Tout d'abord, il faut bien placer la directive RequestHeader à l'extérieur du bloc proxy_module, sinon elle est juste ignorée par le serveur. Il ne m'a pas fallu moins qu'un tcpdump pour localiser le problème.
J'ai aussi constaté qu'avec ces directives, la première connexion à l'application se fait bien, puis on est immédiatement redirigé vers le même virtual host mais sur le port 80. Je règle le problème avec une directive de redirection dans le vhost http :

<VirtualHost *>
    ServerName DOMAINE.TLD
    DocumentRoot /chemin/de/nuxeo
    Redirect / https://DOMAINE.TLD/
</VirtualHost>

Ce n'est pas totalement satisfaisant, mais faute de mieux, cela fonctionne parfaitement.
En relançant Apache à ce stade, on obtient un proxy fonctionnel et sécurisé par SSL pour Nuxeo.

Avant d'aller plus loin, on peut prendre quelques minutes pour créer une base de données MySQL (ou autre) et un utilisateur MySQL associé à cette base. C'est ce compte de base de données qu'il faudra fournir au moment de la configuration de Nuxeo.

Je fais totalement l'impasse sur la configuration de Nuxeo DM dans le "wizard", elle est bien documentée, et plutôt simple. Il suffit de lancer l'application par la commande ad-hoc si ce n'est pas déjà fait :

# cd /chemin/du/répertoire/nuxeo
# sudo -u nuxeo_user ./bin/nuxeoctl startbg

Ensuite on se connecte à l'adresse https://DOMAINE.TLD/nuxeo et on peut entamer la configuration.

Côté pré-requis, il faut tout d'abord installer le Java Runtime Environment, et le Java Development Kit. Sous FreeBSD, il faut donc installer les ports java/diablo-jdk16 et java/diablo-jre16. Pour une question de licence, il faut télécharger à la main les packages nécessaires chez Oracle. Il suffit simplement de suivre les instructions obtenues pour chaque port au moment du make. Par exemple :

$ cd /usr/ports/java/diablo-jdk16/
$ make
===>  License check disabled, port has not defined LICENSE
===>  Found saved configuration for diablo-jdk-1.6.0.07.02_12

 Because of licensing restrictions, you must fetch the distribution
 manually.

 Please open http://www.oracle.com/technetwork/java/javase/downloads/index.html
 in a web browser and follow the "Download" link for
 "JDK DST Timezone Update Tool - 1_3_42" to obtain the
 time zone update file, tzupdater-1_3_42-2011k.zip.

 Please place the downloaded file(s) in /usr/ports/distfiles.
 ...

Une fois les ports java/diablo-jdk16 et java/diablo-jre16 installés, il faut installer un serveur web comme Apache 2.2, un serveur de bases de données (MySQL ou PostgreSQL par exemple), et à minima pdftohtml. Il est aussi possible d'installer OpenOffice, mais comme il n'existe pas de version "headless" dans les ports de FreeBSD, cela vous embarque dans l'installation complète avec gestionnaire de fenêtre et tutti quanti. Une calamité.
Pour utiliser l'application sur une connexion sécurisée (HTTPS), il faut qu'Apache dispose d'un certificat SSL adéquat.

Quand tout ceci est installé et configuré, il faut encore ajouter un compte utilisateur pour l'application Nuxeo. Les paresseux pourront la faire tourner sous le compte www. J'ai préféré un utilisateur indépendant, plus facile à tracer via auditd et l'accounting.

On peut alors télécharger et décompresser le package multiplateforme à partir du site internet de Nuxeo. On obtient un répertoire nommé nuxeo-dm-5.4.2-tomcat. J'ai pour habitude d'exploiter une application à partir d'un répertoire ne portant pas de numéro de version. On aura intérêt à renommer ce répertoire en nuxeo, car ici, faire un lien symbolique de nuxeo-dm-5.4.2-tomcat vers nuxeo ne donne pas vraiment satisfaction.
Pour en finir avec les fichiers, il faut faire un chown -R sur le répertoire nuxeo pour que les fichiers appartiennent tous à l'utilisateur non privilégié que l'on a créé plus haut.

Ensuite, comme nous sommes sur FreeBSD et pas Linux, il faut revoir certains scripts shell. Ces derniers ont un shebang qui pointe vers /bin/bash alors que notre bash est dans /usr/local/bin/. Les scripts à modifier sont les suivants : bin/monitorctl.sh, bin/nuxeoctl, bin/pack.

Arrivé là, il est intéressant de lancer l'application via la ligne de commande pour tester qu'au moins elle se lance et répond sur le port 8080 :

# cd nuxeo
# sudo -u nuxeo_user ./bin/nuxeoctl startbg
...
No current configuration, generating files...
Configuration files generated.
Server started with process ID 1438.

Le serveur est lancé, et il écoute bien sur le port 8080 :

# netstat -alnf inet | grep 8080
tcp4       0      0  *.8080                 *.*                    LISTEN

Ce que l'on peut aisément vérifier avec un client HTTP en ligne de commande, ou un coup de telnet :

$ curl http://127.0.0.1:8080
<META HTTP-EQUIV="refresh" CONTENT="0;URL=/nuxeo">

On a maintenant une application Tomcat/Java qui tourne sur notre serveur FreeBSD, sous un compte utilisateur dédié. Il reste à brancher devant un proxy Apache HTTPS, créer un script de démarrage automatique pour l'application, et configurer cette dernière.

La suite au prochain épisode :)

L'ajout de documents déjà électroniques est assez trivial. Dans Nuxeo en prime on peut le faire par glisser-déposer, c'est super cool™. La difficulté finalement à ce niveau, c'est le classement. Avec le papier c'est simple : on n'a pas vraiment le choix. Soit le classeur rouge, soit le chasseur vert, mais pas les deux. Le classement électronique permet quant à lui de créer autant de dossiers qu'on le souhaite, et de surcharger ce classement par des étiquettes (tags). Une facture d'examen médical pourrait être classée dans "Santé" ou "Factures", ou dans "Santé/Factures", ou dans "Factures/Santé", ou ne pas être classée du tout mais porter les étiquettes "Santé" et "Facture", ou d'autres combinaisons de ces éléments.
Plus j'y réfléchi, et plus je me dis que le classement en dossiers/sous dossiers est archaïque. J'ai d'ailleurs toutes les peines à choisir une structure figée dans la quelle je puisse ranger à la fois l'existant, mais aussi les futurs documents. Le classement par tags a un bel avenir, sous réserve que l'application de GED choisie sache gérer ces étiquettes de manière ergonomique pour la recherche et la navigation.

J'ai un (autre) regret au sujet de Nuxeo : quand j'importe un PDF contenant des méta-données, ces dernières ne sont pas indexées par l'application. Je m'étais naïvement attendu à ce qu'un PDF dont le champs "Author" est renseigné puisse être retrouvé par une recherche sur le nom de l'auteur. Ce n'est pas le cas.
Globalement, j'ai l'impression que les outils de GED ne font pas vraiment la part belle aux méta-données contenues dans les documents. Nuxeo en tout cas considère que les méta-données importantes sont celles qui entourent la vie de votre document dans l'application. Certaines de ces informations sont gérées automatiquement (qui l'a mis en ligne, qui l'a modifié la dernière fois…), mais la majorité sont gérées manuellement par les utilisateurs : date d'expiration, sujets, source, nature, langue, flux de travail, relations entre documents, commentaires...

L'ajout de documents papier passe quant à lui par une étape de numérisation. On sort un peu du périmètre de l'application, mais il est intéressant de se pencher sur la question. Numériser en masse une foule de documents différents nécessite du temps et de la méthode. Ceux qui ont de la chance ont quelque part à porté de main un copieur numérique connecté. Ce genre de grosse machine d'entreprise permet de traiter les documents exactement comme le fait une photocopieuse classique : par lot, recto-verso, avec réduction ou agrandissement, avec optimisation du contraste, etc. Le résultat de la numérisation est en général un fichier PDF envoyé par email, ou déposé sur un serveur. Si vous avez un de ces copieurs à disposition, prenez le temps d'en assimiler les réglages et l'interface. Certains permettent de créer des programmes personnalisés. Ainsi, en pressant une seule touche, je suis capable de numériser recto-verso une pile de documents, avec un réglage spécial de résolution, de contraste, et de destination. Le PDF est déposé sur un serveur WebDAV où je peux le récupérer sans limite de taille. Ensuite, j'utilise un logiciel de reconnaissance de caractères qui me permet de transformer mon PDF "image" en "image+texte". Ainsi, le contenu de chaque document ajouté à Nuxeo est indexé, et peut être retrouvé par le moteur de recherche de l'application. En effet, je ne conçois pas la GED sans la possibilité de rechercher mes documents par leur contenu.

Maintenant au boulot. Il me reste deux cartons d'archives et deux gros classeurs de papiers à numériser.

Et donc j'ai choisi Nuxeo. Dans les grandes lignes, voici quelques raisons objectives :

• accès au support
• facilité de tester l'application
• choix du moteur de bases de données
• interface et fonctionnalités

Nuxeo est livrée clé en main, sous la forme d'une archive à décompresser. L'archive utilisable sur FreeBSD est celle qui est destinée à Linux, mais elle nécessite quelques modifications. Notamment les scripts de lancement de l'application devront être révisés (chemin du shell, entre autre).
Quoi qu'il en soit, il y a beaucoup de travail entre le moment où l'application est fonctionnelle et le moment où elle est vraiment utilisable (sécurisée, servie dans les règles de l'art).
Rien n'est précisé par exemple en terme de bonnes pratiques. L'utilisateur béotien risque de se retrouver avec une application fonctionnelle mais peu sécurisée. Avant même de lancer l'application pour s'y connecter, il est souhaitable d'utiliser un compte utilisateur non privilégié pour faire tourner ce serveur. Il est aussi fortement recommandé de mettre un serveur web en frontal qui redirigera les requêtes du port standard vers le port 8080. De même, il ne faut pas lancer l'application sur toutes les IP, mais la restreindre à 127.0.0.1.
L'utilisation d'un serveur web comme Apache se fait très simplement si on se contente du protocole HTTP, mais configurer un frontal HTTPS (donc avec chiffrement des transactions) est une autre paire de manches. Ici, même la documentation officielle n'est pas suffisante, et j'ai du utiliser tcpdump pour venir à bout des problèmes de configuration.

Et ça, c'était la partie drôle. Ça se gâte vraiment quand on souhaite mettre à jour l'application. Tout d'abord, il faut enregistrer l'instance de Nuxeo chez l'éditeur, une fois que c'est fait, le système de mise à jour interne devient accessible. Ce système de mise à jour est une énorme calamité. Une bouse monumentale. C'est un concentré des sept plaies de l'Égypte.
Après installation, j'avais une bonne quinzaine de mises à jour à installer. Mes 5 ou 6 premières tentatives se sont soldées par des échecs, nécessitant une réinstallation complète de l'application (ou une restauration à partir d'un snapshot, dans mon cas). En fait, la clé du succès est sur le site de support de Nuxeo. Il y a bien sûr un ordre pour appliquer les mises à jour, mais il faut surtout redémarrer l'application après chaque patch et suivre les recommandations spécifiques à la lettre.

Finalement, cette application si simple à installer au premier abord m'aura fait perdre de longues heures avant même que j'ai l'occasion de m'en servir pour archiver mes documents.

• - facilité d'accès à l'application sur le site du vendeur (démonstration en ligne, vidéo d'introduction, téléchargement, etc.)
• - fonctionnalités de l'application (ni trop, ni trop peu)
• - pré-requis logiciels (choix du moteur de base de données, par exemple)

J'ai écarté Quotero assez vite, car je n'ai pas trouvé que l'application est assez complète. Je pense qu'elle ne propose pas de gestion poussée des métadonnées. Ça ressemble finalement trop à un explorateur de fichier classique, et pas assez à quelque chose sur le quel je peux me reposer entièrement pour gérer des années de paperasse.
Et après quelques péripéties j'ai choisi Nuxeo car ils proposent une démonstration sous la forme d'une machine virtuelle pour VMWare Fusion. J'ai donc pu tester chez moi l'application complète avant de décider ou pas de la déployer sur mon serveur.

Finalement, c'est après que ça se gâte. Suite au prochain épisode.

Tout ceci ne serait pas un problème si le client Steam n'était pas affreusement mal codé et si le système de gestion de droit était indolore.

Au chapitre des bugs, sur la version Mac du client, voici une liste partielle de problèmes que l'on peut rencontrer avec Steam :

Il est presque impossible d'avoir un bon focus. Vous pensez cliquer sur le bouton OK d'une fenêtre Steam, en fait non, vous ramenez au premier plan la fenêtre qui se trouvait derrière votre cible. Vous lisez une page web dans votre navigateur, et votre souris fait apparaitre de temps en temps des bulles d'info de la fenêtre Steam qui se trouve derrière. Vous tentez de ramener une fenêtre au premier plan, mais elle reste à l'arrière plan en dépit de l'avalanche de clicks que vous lui envoyez. J'en passe. Bref à tous les niveaux de son utilisation, l'application souffre d'énormes problèmes de focus.

Le client Steam est mis à jour automatiquement. Il arrive que cette mise à jour de Steam se passe mal, vous interdisant l'accès à l'ensemble de vos jeux jusqu'à ce que vous parveniez à le faire fonctionner à nouveau. La dernière fois que cela m'est arrivé, j'ai du utiliser le terminal pour déterminer les adresses des fichiers de mise à jour, pour les télécharger, et pour les placer au bon endroit de sorte que Steam les trouve au lancement suivant et achève sa mise à jour. Rendez-vous compte, Steam est un client web, et il n'est pas foutu de télécharger quelques fichiers.

Comme si cela ne suffisait pas, Steam grossit. Chaque mois, la place occupée par le client Steam sur votre disque dur augmente de quelques mégaoctets à quelque dizaines de mégaoctets. Le mien pèse actuellement 256 Mo.

Steam gère mal les téléchargements des mises à jour de votre ludothèque. Les jeux Valve subissent souvent des mises à jour, et chaque fois elles sont téléchargées automatiquement avec plus ou moins de bonheur. Il arrive un peu trop souvent que des téléchargements soient mis en pause sans qu'il soit possible de les réactiver (bien que l'interface propose un bouton pour cela). Parfois aussi la mise à jour d'un jeu reste bloquée à 99% indéfiniment, vous laissant frustrés de ne pas pouvoir rejoindre vos amis dans une partie. À nouveau, la "Méthode Windows" s'impose : on relance le client Steam.

Le système de chat est désastreux. Il n'existe pas de moyen d'enregistrer des conversations, et l'horodatage est digne d'une plaisanterie. Vous tapez du texte dans la fenêtre de chat et rien ne se passe, comme si il était impossible de sélectionner le champ de saisie, il vous faut alors relancer le client Steam (et donc quitter le ou les jeux lancés, sinon Steam ne peut pas être relancé).

Steam n'utilise pas les API de Mac OS X. C'est un portage fait à la va-vite d'une application windows, et donc il ne bénéficie pas de la correction orthographique (pour le chat par exemple), de l'accès au dictionnaire, etc. C'est d'ailleurs sans doute ce qui explique les incessants problèmes de focus.

Bientôt 26 ans que je pratique le Mac, et je n'ai jamais eu l'occasion d'utiliser une application aussi catastrophique. Peut être que les développeurs de Valve ont un robinet dans l'œil qui les empêche de bien faire leur travail.

 1: #!/bin/bash
 2: case $1 in
 3: 	[1-9])
 4: 		find_args="-mtime -$1"
 5: 		;;
 6: 	*)
 7: 		find_args=""
 8: 		;;
 9: esac
10:
11: for XML in $(find . $find_args -name "IMG_*xmp"); do
12: 	rating=$(awk '/xap:Rating/ {gsub(/ *<[^>]*>/,"",$0); print $0}' "$XML")
13: 	[ -f "${XML/xmp/CR2}" ] && \
14: 	xattr -w "com.apple.metadata:kMDItemStarRating" $rating "${XML/xmp/CR2}"
15: done

Téléchargez le script push_img_ratings.sh (Mac OS X uniquement).

Lignes 2 à 9, on teste le premier argument du script, si c'est un chiffre entre 1 et 9 il sera utilisé pour limiter la plage de recherche. Le seul but de cette première partie, est de pouvoir limiter l'impact du script aux photos récemment notées. Cela permet de ne pas re-noter l'intégralité de sa collection de photos, ce qui peut être assez long si vous avez des disques durs lents et de très nombreux fichiers.
À la ligne 11, on crée une boucle qui utilisera comme argument la liste des fichiers retournée par la commande find. Il s'agit ici de trouver tous les fichiers du répertoire courant et des répertoires inclus, dont le nom commence par "IMG_" et termine par "xmp", et dont la date de modification est dans les $1 dernières 24 heures si $1 est entre 1 et 9.
Pour chaque fichier trouvé, on extrait la note de la photo (ligne 12), et si le fichier RAW correspondant au fichier XMP existe, alors on écrit dans ses métadonnées la note extraite (lignes 13 et 14).
Ce script est aisément modifiable pour fonctionner avec des fichiers RAW d'autres appareils (NEF pour Nikon par exemple). Il nécessite par contre que Bridge soit configuré pour stocker les métadonnées dans un fichier indépendant, et non dans le fichier RAW lui-même.

Il vous suffit ensuite de lancer ce script sur l'ensemble de votre photothèque pour propager votre notation "Bridge" dans les métadonnées Spotlight. Si vous souhaitez recopier les notes attribuées dans les dernières 24h uniquement, lancez le script avec comme seul argument le chiffre 1 :

$ cd Pictures/2011_03_16
$ push_img_rating.sh 1

Vous pouvez aussi bien lancer push_img_rating.sh 1 tous les jours automatiquement grâce à launchd, sous réserve de préciser le chemin de recherche pour la commande find (ligne 11).