Métamoteur de recherche pour bibliothèque : recherche fédérée ou outil de découverte ?

Le problème : une bibliothèque, ce sont plusieurs systèmes

Une bibliothèque universitaire type exploite au moins quatre systèmes distincts : le catalogue de son système intégré de gestion de bibliothèque (Koha, par exemple), son dépôt institutionnel en accès ouvert (DSpace), une série de bases de données commerciales sous abonnement (EBSCO, Scopus, JSTOR ou ProQuest, pour citer des types de ressources courants, sans oublier côté francophone des plateformes de revues comme Cairn.info ou Érudit) et, de plus en plus, ses propres revues publiées sous OJS. Chacun a son interface, sa syntaxe de recherche et, pour les bases commerciales, son propre mode d'authentification.

Concrètement, l'étudiant qui cherche « changement climatique et politiques publiques locales » doit choisir, avant même de taper un mot, où chercher. Dans le catalogue, au cas où il existerait un livre ? Dans Scopus, pour un article indexé ? Dans le dépôt, au cas où un enseignant-chercheur aurait déjà écrit sur le sujet ? La plupart choisissent mal, essaient une seule source, n'y trouvent rien de pertinent et abandonnent. C'est la cause la plus courante, et la moins discutée, de la faible utilisation des bases de données que la bibliothèque paie chaque année : elles ne sont pas inutiles, mais presque personne n'arrive jusqu'à elles.

Recherche fédérée vs outil de découverte : deux architectures

Il existe deux façons de construire un point d'accès unique, et la différence n'a rien de cosmétique.

La première est la recherche fédérée en temps réel : le métamoteur reçoit la requête de l'usager, la transmet en parallèle à chaque source connectée, via le protocole que chacune expose, et assemble les résultats sur le moment, à partir de ce que chaque système contient à cet instant. La seconde est l'index central, propre aux outils de découverte classiques : le système moissonne périodiquement les métadonnées de chaque source, une fois par jour ou une fois par semaine, et les stocke dans sa propre base, de sorte que chaque recherche interroge cet index et non les sources d'origine.

L'avantage de l'index central est la vitesse : la réponse ne dépend pas de la réactivité de plusieurs systèmes externes. Il offre aussi une large couverture du texte intégral commercial, précieuse pour les établissements aux abonnements très étendus. Son coût est la fraîcheur : ce qui a été ajouté hier à une base peut mettre des jours à apparaître, et ce qu'un fournisseur a retiré de son catalogue peut rester affiché comme disponible pendant un temps.

La recherche en temps réel présente l'avantage inverse : l'usager voit exactement ce qui existe à cet instant dans chaque source, sans décalage de mise à jour, en échange d'une réponse qui dépend de la disponibilité et de la rapidité des sources connectées. Elle gagne aussi en visibilité du contenu propre à l'établissement, celui que les index commerciaux couvrent le moins bien, et ne dépend pas des accords qu'un tiers a passés avec chaque éditeur. BiblioMeta, le métamoteur développé par BiblioLabTech, repose sur ce second modèle : il interroge les sources en temps réel plutôt qu'un index préétabli, pour que les résultats reflètent ce que la bibliothèque a réellement à disposition, et non une photographie vieille d'une semaine. Ce sont deux choix différents, et aucun n'est meilleur dans l'absolu.

Les sources qu'un métamoteur peut unifier

Dans un déploiement type, on connecte le catalogue du SIGB, le dépôt institutionnel en accès ouvert, les bases de données commerciales sous abonnement, les revues de l'établissement publiées sous OJS et, pour les universités, des agrégateurs de la recherche comme OpenAIRE en Europe ou LA Referencia en Amérique latine. Les archives ouvertes s'y prêtent bien : en France, HAL expose par exemple ses métadonnées par OAI-PMH. Plus la bibliothèque possède de sources distinctes, plus il est utile de les unifier, car le problème que résout le métamoteur grandit avec le nombre de systèmes qui cohabitent aujourd'hui sans communiquer.

Les protocoles qui rendent l'intégration possible

Aucune de ces connexions n'est automatique : chaque source expose, ou non, une manière standard d'être interrogée par un système externe. Les plus courantes en bibliothèque sont Z39.50 et son successeur SRU pour interroger les catalogues en temps réel, OAI-PMH pour moissonner les métadonnées des dépôts et des revues, les API REST propres à chaque base commerciale quand le fournisseur en propose et, pour les intégrations plus avancées en données liées, SPARQL. Koha et DSpace font partie des intégrations les plus directes, car ils exposent des protocoles standard : Z39.50 et SRU pour Koha, OAI-PMH et API REST pour DSpace.

Quand une source n'expose aucun de ces protocoles, son intégration cesse d'être une affaire de configuration et devient un développement sur mesure. Certains fournisseurs ouvrent une API sur demande, d'autres n'autorisent qu'un lien profond vers leur propre interface. Mieux vaut le savoir avant de promettre à une direction que « tout sera connecté » dès la première phase du projet : quand ni la technique ni le contrat ne le permettent, il faut le dire avant de signer.

De la syntaxe booléenne au langage naturel

Au-delà de l'unification des sources, un métamoteur change la manière de poser la question. Les systèmes traditionnels, catalogues comme bases commerciales, reposent encore largement sur les opérateurs booléens et sur des thésaurus qu'un étudiant de première année ne connaît pas et ne devrait pas avoir à connaître. BiblioMeta permet de chercher en langage naturel, sans syntaxe technique, et classe les résultats combinés par pertinence avec l'aide de l'intelligence artificielle : ce qui apparaît en premier n'est pas le premier résultat renvoyé par chaque source dans son propre ordre, mais ce qui répond le mieux à la question complète de l'usager.

Un métamoteur de recherche pour bibliothèque ne remplace ni le catalogue ni les bases

Il faut être précis sur le vocabulaire, car il prête à confusion : le métamoteur ne remplace pas le catalogue ni les bases de données, il les réunit. Chaque source continue d'exister, avec son contenu et ses règles d'accès ; ce qui change, c'est que l'usager n'a plus besoin de savoir dans laquelle se trouve ce qu'il cherche. Le coût de son absence n'a rien d'abstrait : ce sont des abonnements annuels que la bibliothèque continue de payer et que la plupart des usagers n'ouvrent jamais. Dans les projets de BiblioLabTech, l'argument qui convainc le plus une direction financière n'est pas l'expérience usager, même si elle compte, mais le retour sur ce qui est déjà dépensé en abonnements sous-utilisés.

Le tableau de bord de BiblioMeta rend ce retour mesurable : ce que l'on cherche, quelles ressources sont réellement consultées, quelles recherches ne renvoient aucun résultat et comment l'usage évolue dans le temps. Pour une bibliothèque, la donnée la plus utile est souvent celle des recherches sans résultat, car elle signale de vrais manques dans la collection ou dans la façon dont elle est décrite.

BiblioMeta et BiblioMeta Académico : un même socle, deux publics

BiblioMeta s'adresse aux bibliothèques en général, qu'elles soient publiques, scolaires ou spécialisées, avec une recherche centralisée, des résultats en temps réel, une interface aux couleurs de l'établissement et un tableau de bord des usages. BiblioMeta Académico ajoute ce dont une université a besoin sur cette base : une recherche en langage naturel qui génère des équations de recherche avancées, visibles et modifiables ; l'intégration par protocoles standard au catalogue, au dépôt, aux bases et aux agrégateurs ; un accès distant intégré (proxy) pour consulter les bases payantes hors campus ; une interface multilingue conforme aux WCAG 2.1 niveau AA ; et un assistant de recherche IA inclus gratuitement dans chaque intégration.

Lorsque BiblioLabTech équipe une université, le point de départ est presque toujours BiblioMeta Académico, parce que l'accès distant y est déjà réglé, et que c'est la question que les étudiants posent le plus vite dans n'importe quelle réunion de lancement.

Un cas réel : quatre systèmes, un seul point de recherche

À l'Escuela Colombiana de Ingeniería Julio Garavito, à Bogotá, BiblioLabTech a déployé BiblioMeta sur une infrastructure qui comprenait déjà Koha, DSpace et un assistant conversationnel de référence. Le métamoteur a été publié comme point d'entrée unique de la recherche, avec un panneau d'administration et des statistiques d'usage en temps réel : la bibliothèque voit ce que l'on cherche et quelles ressources sont réellement consultées, et pas seulement lesquelles elle paie.

Quand faut-il un métamoteur ?

Un métamoteur se justifie lorsque la bibliothèque possède déjà plus d'une source qui mérite d'être unifiée : catalogue et dépôt, catalogue et bases sous abonnement, ou les trois à la fois. Si elle n'a qu'un catalogue et aucun abonnement actif, il n'y a encore rien à fédérer réellement, et le plus sensé est d'attendre que ce deuxième système existe avant de chiffrer un métamoteur.

BiblioLabTech établit toujours ses devis sur le nombre réel de sources à intégrer et non sur un forfait fermé, car l'effort varie beaucoup entre connecter deux systèmes et en connecter huit. Le prix dépend du nombre de sources, de la complexité de chaque intégration, du besoin d'accès distant aux ressources sous abonnement et du niveau de personnalisation visuelle. Il s'agit d'un service annuel qui couvre l'exploitation de la plateforme, l'hébergement et la maintenance des connexions, indispensable puisque les sources changent : un fournisseur modifie son interface, un abonnement est résilié, le catalogue change de version. Sans cette maintenance, un métamoteur se met à échouer en silence et interroge moins de sources que l'usager ne le croit.

Dans un scénario type, comptez de deux à trois mois de mise en œuvre pour BiblioMeta, et de trois à quatre mois pour BiblioMeta Académico, pilote avec des chercheurs compris. Pour démarrer, il faut l'inventaire des ressources sous abonnement avec leurs contrats, un contact technique pour chaque système propre, les accès aux sources et une personne de la bibliothèque qui décide quoi connecter en premier. Aucune infrastructure n'est requise de votre côté : la plateforme est exploitée dans le cloud.