Deux méthodes et demie pour publier son catalogue

Version imprimableVersion imprimableEnvoyer par courrielEnvoyer par courriel
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.

Commentaires

Merci pour l'éclairage et très intéressé par cette expérience, je suivrai donc avec plaisir la prochaine publication dans ton labo.

Mais je voulais poser une question sur la méthode des "connecteurs" :

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.

Peut-on espérer que cette limite va être dépassée dans un temps relativement proche en raison des divers développements actuels en ce sens (qui contribueraient à améliorer la performance) ou est-ce illusoire ?

Avec la méthode des connecteurs, le problème des temps de réponse est structurel. Par exemple pour un dédoublonnage à partir de deux sites, les réponses des connecteurs arrivent dans un ordre aléatoire. Un titre peut arriver en première position pour le premier serveur et le même titre à la fin pour le deuxième donc on ne peut dédoublonner qu'après avoir tout récupérer même en pratiquant un dédoublonnage à la volée (dédoublonnage d'un nouveau titre par comparaison avec ceux déjà arrivés). Quelque soit l'intelligence de la technique de dédoublonnage et la puissance de la machine, le temps de réponse est au minimum celui du serveur le plus lent. Et cela, on ne le maitrise pas.

Quand on travaille sur un seul catalogue, il faudra toujours pour un tri ou pour extraire des facettes travailler sur la totalité de l'ensemble des réponses. Ce problème ne se poserait pas si on se contentait d'afficher les données au fur et à mesure de leur arrivée. Par exemple avec Z39.50, le serveur répond à une requête en ne donnant que le nombre de réponses (commande search) et ensuite on demande les notices paquets par paquets (commande present).

Pourquoi deux méthodes et demis ? Je trouve ça incompréhensible. Pourquoi ne pas préciser exactement combien de stratégie existe pour publier son catalogue.

On a le choix entre :

  1. L'Opac est un des modules du SIGB. Il ne peut pas être utilisé de manière indépendante et utilise la base de données du SIGB.
  2. L'information bibliographique est exportée du SIGB e intégrée dans un CMS. L'OPAC est une fonctionnalité de votre CMS en toute indépendance du SIGB. Vous pouvez demain changer votre SIGB sans rien toucher à votre portail.

La méthode intermédiaire (la fameuse demie) est une solution intermédiaire : vous ajoutez à votre portail un module qu utilise les programmes de  votre SIGB. Pour faire une recherche, le module la transmet au SIGB qui l'éxecute et fournit les résultats. Le CMS se contente de les afficher. Comme pour la solution numéro 1, le module dépend du SIGB sauf à utiliser des protocoles normalisés comme Z39.50..