Deux méthodes et demie pour publier son catalogue

Cistizen Kane/Orson Welles Pour publier un catalogue, la méthode la plus naturelle est d’utiliser le module intégré au logiciel documentaire. Pourtant, de plus en plus, les bibliothèques et centres de documentation se tournent vers des applications extérieures, découplant ainsi la gestion du catalogue de la publication. Une voie médiane consiste à intégrer les fonctionnalités de recherche documentaire du logiciel de gestion dans une application spécialisée, le plus souvent un système de gestion de contenu.

Le choix de l’une ou l’autre de ces méthodes dépend de ce que l’on veut faire et le but de cet article est de présenter les avantages et inconvénients de chacune d’entre elles.

Autour du catalogue, on peut distinguer trois types de fonctionnalités : celles liées à l’interrogation du catalogue : l’ancien OPAC ; celles liées aux usagers : prêts, réservations, consultation de compte et celles liées à l’information et à la communication de l’établissement  : annonces et comptes rendus d’animations, blogs de bibliothécaires ou de lecteurs, calendrier, promotion du fonds ou encore fonctionnalités collaboratives.

L’outil de publication intégré utilise la même base de données que les modules de gestion  alors que le catalogue doit-être exporté et réintégré dans une base dédiée à la publication. Ceci donne à la première méthode un avantage considérable pour toutes les informations liées à la gestion. Pour accéder à ces données avec une application séparée,  il faut à chaque fois se connecter et interroger le système distant avec des protocoles spécialisés  ou des services web. Cette méthode est satisfaisante pour des interrogations ponctuelles comme connaître la disponibilité des exemplaires d’un titre, consulter un compte lecteur ou réserver un document. Mais, ce mécanisme est pénalisant dès qu’il s’applique à des volumes importants. Par exemple, limiter une recherche aux documents disponibles nécessiterait de récupérer dans un premier temps tous les titres et d'interroger le serveur de gestion pour chacun d'entre eux pour en connaître la situation avant de pouvoir afficher des résultats.

Pour la recherche documentaire, les performances sont liées à la fois au modèle de données et aux fonctionnalités du moteur de recherche.  Je n’aborderai pas ici ce dernier aspect car il n’est pas lié à la nature de l’application mais dépend directement de la qualité des produits et de leurs choix fonctionnels et nécessiterait par conséquent des analyses comparatives, au cas par cas. Avec une application séparée, l’exportation des données et leur intégration dans une nouvelle base permet de concevoir un modèle de données parfaitement adapté aux exigences de la publication, en s’affranchissant des contraintes liées à la gestion. Préparer des résultats ou concevoir des index performants est plus facile avec des données statiques sans les contraintes de mises à jour en temps réel. C’est probablement pourquoi des mécanismes comme la recherche à facettes sont, à de rares exceptions près, réservés aux modules externes. Notons cependant que, quel que soit le modèle de données, on reste limité par la qualité du catalogue original géré par le logiciel intégré.
Pour les catalogues collectifs, il faut également choisir entre une interrogation simultanée des serveurs et la constitution d’une base cumulant l’ensemble des titres du réseau. Le catalogue commun permet une fusion des titres au moment de l’import et facilite les opérations de tri ou de constitution de facettes. Avec une interrogation simultanée, ces opérations doivent se faire à la volée et les résultats ne peuvent être affichés, qu'après avoir récupérer toutes les informations. Pour éviter des temps de réponse trop longs,  les recherches sont souvent limitées en nombre de titres. Mais la constitution d'une base cumulée n’est pas toujours envisageable lorsque la taille ou quand le nombre des catalogues est important et que certaines bases sont rarement interrogées. Imaginez un serveur regroupant la BNF, le SUDOC et plusieurs fonds de bibliothèques pour quelques recherches fédérées par semaine.

En ce qui concerne la gestion de contenu, l’avantage des systèmes spécialisés est évident. Même si certains éditeurs de logiciel documentaire intègrent des fonctionnalités de CMS (création de contenu : articles, billets de blogs, gestion de calendrier, annonces de manifestation, coup de cœur, etc...), ils ne peuvent pas prétendre rivaliser avec des logiciels qui, pour les plus connus d’entre eux (Drupal, Joomla, SPIP, Wordpress…) ont maintenant plusieurs années d’expériences et représentent des milliers de sites. Lorsqu’ils sont libres, les communautés de développeurs sont importantes et très dynamiques. C’est de ce monde que sont issus la plupart des concepts et fonctionnalités demandés aujourd’hui dans les portails documentaires : nuages de mots, commentaires, travail collaboratif, recherche portant à la fois sur le catalogue et le contenu du site, syndication de contenu, etc.

J’ai intitulé cet article deux méthodes et demie car, entre les logiciels intégrés et les applications externalisées, on trouve des applications qui reposent sur des systèmes de gestion de contenu en y intégrant des fonctionnalités du logiciel documentaire. Dans ces configurations, il n’y a pas de réplication des données. L’accès au catalogue passe par des connecteurs spécialisés s’appuyant sur des protocoles normalisés (Z39.50, SRU/SRW), des services web ou des API.  Cette conception voudrait concilier les avantages des deux autres mais elle reste limitée pour les opérations nécessitant de manipuler des ensembles de données en temps réel, comme le dé doublonnage, tri ou constitution de facettes.
Pour les catalogues collectifs, certains constituent une base fédérée pour les bases les plus sollicitées et utilisent une interrogation simultanée pour d’autres sources trop importantes ou rarement sollicitées.

La méthode hybride est apparue la première et est encore la plus répandue pour l’externalisation des portails.  C’est le cas de Koha avec Drupal, le portail Ermes de la société Archimed ou encore de PMB avec SPIP.
Pour ce qui est de la réplication de la base, rendons hommage au logiciel libre Moccam qui a permis une démocratisation de cette technique, surtout en matière de catalogue collectif. On peut citer également l’offre OPAC 2.0 de la société AFI ou la solution Aquabrowser, pionnière en matière de facettes.
 
A titre expérimental, je publierai prochainement dans mon laboratoire une maquette de réplication d'un catalogue dans le CMS Drupal.