Après le catalogage, faut-t-il supprimer aussi le catalogue ?

Après bien des années d’efforts, le temps de travail consacré au catalogage, rédaction de notices bibliographiques ou autorités, est en forte diminution, quand il n’est pas carrément supprimé

Ceci est le résultat d’une longue bataille de quelques personnes tenaces, avec une mention particulière pour l’équipe de la Médiathèque de Fresnes et son directeur Thierry Giappiconi, et de quelques avancées techniques : généralisation des formats Marc, changement de politique pour la fourniture de notices à la BNF, base BN Opale+ et son serveur Z3950, intégration de clients Z3950 dans les SIGB et automatisation de la récupération de notices sur l’exemple du vendangeur inauguré à Fresnes en 2005 avec le SIGB Aloès (Opsys).

Après plusieurs années de fonctionnement, il est possible aujourd’hui de dresser un premier bilan. S’il apparaît que le travail de catalogage est devenu, pour ceux qui le souhaitent, négligeable, la gestion et l’administration du catalogue reste une procédure lourde et complexe.

Difficulté de synchronisation des catalogues.

Le principe de la récupération de notices présuppose que le catalogue de la bibliothèque, notices bibliographiques et autorités, devienne un sous-ensemble d’un catalogue de référence (par exemple BN Opale+)

Le catalogage d’un nouveau document se résume à la recopie de la notice bibliographique du catalogue maître dans le catalogue local, complétée éventuellement par la dérivation des notices autorités dépendantes, sauf si la bibliothèque a préchargé l’intégralité des fichiers autorités du serveur de référence. La bibliothèque complète finalement la notice avec ses données locales.

Ensuite, la notice originale et sa copie évoluent de manière autonome. Il faut donc imaginer des mécanismes, toujours complexes, pour qu’une modification sur la base maître soit répercutée sur la base locale en respectant les données locales.

La BNF propose un abonnement mensuel aux modifications et mises à jour. La bibliothèque peut alors rapatrier ce fichier et modifier les notices qui la concernent. On peut aussi aller régulièrement rechercher les notices sur le serveur de référence pour en avoir la dernière version.

Toutes ces procédures demandent des infrastructures logicielles et matérielles et des temps machine importants pour intégrer les modifications et réindexer les notices, sans compter un travail des bibliothécaires pour suivre le processus, valider les opérations et administrer la base. Ceci induit donc un coût qui, même s’il est très faible par rapport à un catalogage manuel, reste important.

A ceci s’ajoute tous les problèmes de compatibilité de format (InterMarc, Unimarc) et les paramétrages des systèmes d’indexation et de liens entre notices avec des systèmes de gestion aux logiques différentes..

Supprimer les notices de la base locale.

Toute la lourdeur vient de la nécessité de recopier en local une partie du catalogue maître, un peu comme si votre navigateur Internet avait besoin de recopier et tenir à jour sur le disque dur de votre ordinateur l’intégralité des sites qui vous intéressent, pour pouvoir vous afficher une page. Votre navigateur se contente d’aller chercher sur le serveur du site une page pour vous l’afficher au moment où vous voulez la consulter, garantie que celle-ci est toujours à jour.

Pour les notices du catalogue de référence, on pourrait imaginer un fonctionnement similaire : le SIGB irait chercher, chaque fois que nécessaire, la notice sur le serveur de la base de référence. On se contenterait alors localement d’un pointeur vers la notice de la base maître, complété par des données locales. Pour un affichage ou une indexation, le SIGB inclurait dans une même notice les parties distantes et locales.

Ce mécanisme permettrait de s’affranchir complètement du problème de synchronisation des bases et de toutes les tâches qui en découlent.

Supprimons aussi la base d’indexation !

Avec le système de pointeurs, la synchronisation des bases est résolue pour le contenu de la notice elle-même, mais il reste un problème au niveau du moteur de recherche.

Si une notice est modifiée sur la base maître et que les index sont locaux, la modification ne sera pas répercutée, et les recherches continueront d’aboutir sur une ancienne forme modifiée depuis la dernière indexation, et n’aboutiront pas sur la forme corrigée.

En s’inspirant du fonctionnement des moteurs de recherche, on peut résoudre le problème de deux manières.

Les moteurs d’indexation passent leur temps à parcourir le web pour mettre à jour la base d’indexation. Une modification sur un site est prise en compte dès que le moteur d’indexation repasse après qu’elle a été effectuée.

Tout est donc fonction du délai entre cette modification et la prise en compte par le moteur, et l’importance d’un retard dans la mise à jour du catalogue local dépend de l’usage qui en est fait : il peut être plus important pour un catalogue de fonds ancien que pour un OPAC, il doit être très rapide pour un système de prêt ou d’acquisition.

Plus ce délai est court, plus la ressource informatique devra être importante. Votre moteur d’indexation parcourra régulièrement le catalogue distant, souvent de manière inutile. Combien de notices sur un catalogue de plusieurs dizaines voire centaines de milliers de titres seront modifiées avec un passage tous les jours voire toutes les heures ?

La ressource machine ou la bande passante d’un réseau ont elles aussi un coût.

Et pour finir, la fin du moteur de recherche !.

Pour effectuer une recherche sur le contenu d’un site, on peut déléguer le travail à Google : La recherche est faite par Google sur sa base d’indexation et Google restreint ensuite le résultat aux seules pages de votre site.

Sur le même modèle, on pourrait imaginer une recherche bibliographique qui serait faite sur le moteur de recherche du catalogue distant avec des protocoles connus (Z3950, SRU, SRW) Le système local éliminerait dans un deuxième temps toutes les réponses qui ne correspondent pas à un titre du catalogue local. Ce résultat pourrait enfin être combiné avec des données locales (localisation, cote, etc.….).

Avec une telle architecture, la bibliothèque s’affranchit totalement des tâches de catalogage, supprime la partie bibliographique et autorité de son catalogue et la base d’indexation correspondante. Elle bénéficie également des fonctionnalités du moteur de recherche de systèmes spécialisés qui est souvent (pas toujours) plus puissant que celui d’un SIGB local.

Certains verront dans une telle solution le retour de la tentation d’un SIGB centralisé et hégémonique. Comme pour Internet, c’est exactement l’inverse : il s’agit d’un système décentralisé sans redondance d’informations et avec répartition des compétences Chaque site conserve en local les données et le fonctionnement qui lui sont propres et il utilise les ressources extérieures correspondant à des compétences qu’il ne possède pas ou ne veut pas assumer.

Utopie ou réalité ?

Il n’existe pas d’obstacles techniques à une telle architecture : toutes les technologies utiles sont déjà présentes avec Internet ou dans les SIGB (Z3950, SRU/SRW, OAI)

Mais le passage à un tel système nécessite des garanties de services au niveau des infrastructures :

• La connexion réseau doit être permanente avec une bande passante suffisante pour les échanges entres les serveurs. Aujourd’hui l’offre semble suffisante ou en passe de l’être dans tous les territoires.

• Ne conserver qu’un pointeur dans la base locale suppose que le catalogue de référence mette en place un système de lien permanent ou d’adresse pérenne pour les notices de la base maître. J’ai de très mauvais souvenirs des implications du changement de numérotation lors du passage de BN Opale à BN Opale+.

• L’utilisation du moteur de recherche pour des requêtes d’intérêt local va beaucoup solliciter le serveur externe. Il faudra donc trouver les moyens matériels et financiers (puissance machine, bande passante) pour que ce mode de fonctionnement ne mette pas en péril le fonctionnement normal de la base de référence.

• Mais cela suppose surtout une évolution des mentalités : accepter de déléguer le travail de catalogage a été une tâche longue et difficile. Ne plus avoir son catalogue, son moteur de recherche et sa base d’indexation risque d’en perturber plus d’un.

Je suis convaincu que l’on arrivera un jour à un tel mode de fonctionnement. Et ce d’autant plus qu’on peut l’appliquer à d’autres aspects du SIGB : catalogue collectif, circulation des documents, etc.……. J’y reviendrai prochainement.

PS : Bien sûr un tel système de vampirisation ne pourra pas s’appeler autrement que

Dracula

(Détournement Radical et Automatisé de Catalogue par Usurpation d’un Logiciel Alien)

NDLC Un bon orateur revient toujours à son point de départ (cf photo)