Le futur de la recherche documentaire : RAG time !

Aujourd’hui, je vous parle d’une application de l’intelligence artificielle et plus spécifiquement, des modèles de langues et de l’IA générative, qui est en train de prendre pas mal d’essor en ce moment : le RAG (Retrieval Augmented Generation). Vous n’en avez jamais entendu parler ? Restez branchés, car le RAG pourrait bien rentrer rapidement dans la boîte à outil courante du professionnel de l’information, juste à côté des catalogues, des ressources électroniques et des moteurs de recherche.

Un peu d’historique et de contexte (on ne se refait pas)

Voilà plusieurs années maintenant qu’on me demande régulièrement d’intervenir pour parler de ce que l’IA change ou va changer dans les bibliothèques. Après avoir étudié tous les use-case possibles et imaginables, j’ai développé un savant exercice d’équilibriste à base de « on va pouvoir continuer à faire ce qu’on fait, mais plus efficacement » ou encore « c’est surtout la masse de ce qu’on peut traiter qui change ». Depuis plusieurs années, j’avais vu débarquer les grands modèles de langue (LLM), en particulier BERT et ses petits amis (CamemBERT, FlauBERT etc.) mais globalement, leur utilisation se passait dans la soute, dans des profondeurs techniques difficiles à expliquer à des publics non-avertis. Cela faisait partie de ces outils « invisibles » qui améliorent les données et les services qu’elles rendent, mais sans faire de bruit.

En novembre 2022, quand ChatGPT a débarqué et a démontré sa capacité à masteriser le test de Turing, j’ai été assez rapidement convaincue qu’une fois le phénomène de mode passé, cet outil (et ses petits frères LLM) aurait surtout un impact quand il s’intègrerait discrètement dans nos applications du quotidien : nos gestionnaires de mail (pour répondre plus vite et envoyer encore plus de mails :-/), nos traitements de texte (pour trouver le bon mot à notre place) et… nos moteurs de recherche (dont il reformulerait à la fois les réponses et les questions, en langage naturel).

Le graal du « langage naturel » dans la recherche documentaire est en effet un idéal après lequel on court depuis bien des années. L’enjeu est de se débarrasser des mots-clefs, méthodes de requêtage et autres trucs de professionnels de l’information, pour pouvoir simplement demander les choses à son moteur de recherche préféré comme on le ferait à un humain, en lui posant des questions. La recherche plein texte à la Google ne répond qu’imparfaitement à ce cas d’usage : on peut en effet formuler des questions, il répondra bien quelque chose, mais le lien entre les deux n’est pas garanti.

Comme nous autres bibliothécaires, Google a commencé par tenter de s’appuyer sur les métadonnées pour pouvoir répondre de manière pertinente à au moins certaines questions, avec le « knowledge graph ». Ce qui donne par exemple ceci :

Encore plus récemment, on a vu apparaître autre chose dans la liste de résultats de Google. Dans la copie d’écran ci-dessous, prise à partir de la même question et toujours sur la 1e page de résultats, vous avez à droite le knowledge graph et à gauche, une liste de questions avec leurs réponses (que l’on peut dérouler en cliquant sur la flèche) :

Il suffit de regarder attentivement les questions et les réponses pour deviner que Google utilise ici les ingrédients de sa bonne vieille recette qui marche : analyser les questions que posent souvent les internautes, les réponses qui leur plaisent le plus, et chercher les chaînes de caractère textuelles qui correspondent. Rien de neuf : on sait depuis longtemps que pour améliorer son référencement, il faut formuler le titre de ses pages/billets/vidéos sous forme de question en essayant d’imaginer ce que les internautes se demandent (vraiment, j’avais capté ça en 2004, ce qui a fait de ce billet mon best-seller de tous les temps).

Ce qui change vraiment, c’est la place importante que Google réserve désormais à ce bloc question-réponse sur sa page de résultats, quelle que soit la requête (même si ce n’est pas une question). On peut donc s’aventurer à le prédire : dès qu’on aura réussi à empêcher les LLM de trop halluciner, les modalités de la recherche documentaire vont profondément changer, et laisseront beaucoup plus de place aux questions-réponses et aux échanges en langage naturel.

Je ne m’appesantirai pas ici sur les tests en cours dans ce domaine du côté des grands moteurs de recherche du web, qu’il s’agisse de Google ex-Bard désormais Gemini ou du Copilot de Bing basé sur ChatGPT. Ce qui m’intéresse aujourd’hui, c’est de vous parler de l’un des impacts de cette évolution sur la recherche documentaire en bibliothèque (ou archives), à travers le RAG.

Qu’est-ce que le RAG et à quoi peut-il servir ?

(Ce titre de niveau H2 est cadeau pour le référencement.)

RAG signifie donc Retrieval Augmented Generation ; en français, on parle de « génération augmentée de récupération ».

Un RAG permet à une intelligence artificielle générative conversationnelle (comme ChatGPT) d’interagir avec un corpus délimité. Celui-ci peut correspondre à un ensemble de documents, un fonds d’archives ou même à un seul document. On peut dès lors poser des questions visant à résumer tout ou partie du corpus ou du document, à vérifier la présence de tel ou tel concept et savoir comment il est traité, ou encore à répondre à des questions précises en se basant sur l’information présente dans le corpus. Bonus non négligeable, grâce au RAG, l’outil est en principe capable de citer ses sources c’est à dire de lister précisément les documents du corpus sur lesquels il s’est basé pour répondre, voire de fournir des extraits et des citations.

Imaginez par exemple que vous tombez sur un article de 50 pages potentiellement intéressant, mais vous n’avez pas le temps de le lire. Vous pourriez alors demander à un agent conversationnel, grâce à votre RAG, de vous le résumer paragraphe par paragraphe, d’en extraire les thématiques principales, de vérifier s’il contient l’idée que vous cherchez ou la réponse à votre question, d’aller droit aux résultats de la recherche qui y est présentée… C’est le cas d’usage qu’a imaginé JSTOR pour son outil AI research tool (beta) :

Les RAG semblent être apparus en 2020 dans l’environnement de Meta. Pour ma part, je les ai découverts (notamment à travers l’exemple de JSTOR) à la conférence AI4LAM de Vancouver en novembre dernier ; néanmoins je ne crois pas que le terme de RAG a été utilisé (ou alors il m’a échappé, on en sera quittes pour vérifier dans les captations vidéo qui devraient arriver bientôt). Sur le coup, j’ai trouvé l’idée intéressante mais un peu anecdotique, peut-être parce que la personne qui faisait l’une des démos avait utilisé ses propres archives et posait des questions sur son chien (les exemples, c’est important). Depuis, j’ai vu passer d’autres applications qui ont attiré mon attention et que je détaillerai un peu plus loin (ça c’est pour vous obliger à lire jusqu’au bout mon billet interminable, quel machiavélisme !)

Comment ça marche ?

Je ne vais pas rentrer dans des détails très techniques, ce qui m’intéresse est comme d’habitude de saisir suffisamment les principes généraux pour comprendre les atouts et les limites potentielles de l’outil.

Les grands modèles de langue comme Chat-GPT présentent la particularité de mélanger une fonction linguistique (construire des phrases correctes dans plusieurs langues) et des connaissances, qui s’appuient sur les données d’apprentissage qui leur sont fournies à savoir, globalement, de grands corpus de texte issus du web ou de bibliothèques numériques. Or, le mélange de ces deux fonctions produit le phénomène qu’on a appelé hallucination, c’est-à-dire que lorsque le modèle n’a pas la connaissance nécessaire, il produit quand même du langage et donc raconte n’importe quoi. Essayez par exemple de demander à Chat-GPT de vous générer la bibliographie d’une personne, il vous fournira des références crédibles mais totalement fantaisistes… Par exemple je n’ai rien écrit de tout cela (encore que l’idée d’une co-publication avec Nathalie Clot soit bien trouvée) :

On ne peut pas vraiment lui en vouloir : ChatGPT est un modèle de langue, son rôle est de générer du langage et pas de rechercher des informations.

Le principe du RAG est donc d’augmenter (A) la fonction générative (G) avec une fonction de recherche (R) dans un corpus externe. Pour effectuer cette spécialisation, il existe plusieurs méthodes possibles : entre l’article initial de P. Lewis et al. en 2020 et celui-ci qui, en 2023-24, analyse 100 publications à propos des RAG, le champ de la recherche s’est déjà complexifié de manière importante, notamment suite à l’irruption de ChatGPT en cours de route. Le schéma ci-dessous, emprunté au 2e article, représente la généalogie de l’évolution des RAG pendant cette période :

Technology tree of RAG research. Source : https://arxiv.org/abs/2312.10997

Je recommande également la lecture de cet article pour les personnes qui souhaiteraient des explications techniques claires et illustrées par des schémas sur le fonctionnement de ces différents types de RAG. Je vais essayer de résumer, mais comme le laisse supposer ce joli graphique, le RAG est un domaine de recherche complexe en plein expansion, qu’il serait difficile de saisir en seulement quelques phrases : je vais donc forcément simplifier de façon un peu caricacturale, pardonnez-moi.

Il y a en gros trois méthodes pour améliorer les résultats d’un LLM en maîtrisant davantage la source des connaissances qu’il utilise pour répondre :

  • le prompt-engineering, qui consiste à agir au niveau du prompt, en y injectant le contenu des références à utiliser pour fournir une réponse correcte et à jour,
  • le fine-tuning, qui consiste à réentraîner le modèle sur un corpus choisi pour lui apprendre à répondre de manière plus spécifique en fonction d’un domaine ou d’un corpus,
  • le RAG proprement dit, qui repose sur la séparation de la fonction langagière du LLM et de la base de connaissances qui la sous-tend.

En réalité, selon les types de RAG, on va combiner ces différentes méthodes pour optimiser les résultats obtenus. Par exemple, en injectant des sources de référence dans les prompts, on va permettre au LLM de tracer l’origine des connaissances qu’il utilise pour formuler sa réponse, voire lui donner des éléments pour fournir des réponses plus à jour (la base de connaissance de la version publique de ChatGPT, par exemple, s’arrête en 2021). Par contre, il existe des risques de brouillage entre les connaissances d’origine du modèle et le corpus choisi. Le fine-tuning nécessite de réentraîner le modèle, ce qui peut être assez lourd en terme de calcul et nécessite de disposer de grands corpus de vérité terrain adaptés. En revanche, le fait de séparer le langage des connaissances a l’avantage de permettre de travailler avec des modèles de langue plus légers – c’est ce que nous a expliqué Pierre-Carl Langlais à la dernière réunion du chapitre francophone d’AI4LAM que vous avez manquée malheureusement, mais que vous devriez pouvoir revoir en vidéo bientôt.

Des exemples ?

Si vous voulez en savoir plus sur le principe des RAG, lire des explications un peu plus techniques (mais quand même accessibles) et découvrir un outil que vous pouvez vous-même tester, allez voir du côté de WARC-GPT, un outil open-source développé par le Lab de l’Université de Harvard (présentationgithub). Son objectif est de permettre d’explorer des paquets d’archives web au format WARC. Vous allez me dire que si vous ne travaillez pas sur les archives du web, ce n’est pas très intéressant… et pourtant ! Si vous utilisez des ressources accessibles en ligne comme à peu près n’importe qui, il est globalement très facile de les empaqueter en WARC (par exemple avec Conifer ou Archiveweb.page).

Sinon, vous pouvez aussi tester Nicolay, un outil qui expérimente le RAG sur 15 discours d’Abraham Lincoln, représentant environ 300 pages de texte (présentationdémogithub).

Au niveau français, j’ai aperçu des expérimentations à droite ou à gauche, mais je n’ai rien de concluant à vous montrer pour l’instant. Pourtant, si on en croit les très nombreuses références commerciales que l’on peut trouver sur Internet, comme par exemple celle-ci (qui est par ailleurs plutôt bien faite pour qui recherche des explications en français), le RAG est aujourd’hui une technologie bien maîtrisée par l’industrie. Donc si vous avez des exemples sous la main, n’hésitez pas à me les signaler, je les ajouterai à ce billet.

Pour revenir au domaine de la recherche documentaire et des bibliothèques, il me semble que le RAG offre des opportunités d’exploration de grands corpus que je serais surprise de ne pas voir fleurir dans les mois ou années qui viennent. Par ailleurs, si ce genre de méthode doit révolutionner à terme la recherche documentaire et voir nos recherches par mots-clef disparaître au profit de prompts, comme la recherche par équation a disparu au profit de de la recherche plein texte… On a intérêt à comprendre comment elles fonctionnent et à apprendre à les maîtriser. Car le prompting, c’est comme la recherche documentaire : ça pourrait paraître simple à première vue, mais c’est une compétence de la litératie numérique qui ne s’invente pas.

Je vous propose de conclure ce billet en écoutant The entertainer’s Rag (Tony Parenti’s Ragpickers Trio, 1958) sur Gallica. RAG time !

Ce billet a été rédigé à 100% à base d’intelligence humaine.

Le catalogueur, l’usager et le système

Comme je parcourais le RDA Toolkit, profitant de sa temporaire gratuité (jusqu’au 31 août, je le rappelle), je me suis sentie dériver librement au fil de pensées inattendues.

S’appuyant sur les FRBR et sur les principes internationaux de catalogage, les RDA rappellent une chose qu’on parfois trop tendance à négliger quand on parle de catalogage : le but du catalogage, c’est de répondre aux besoins des utilisateurs, tout en rationalisant les moyens qu’on déploie pour y arriver :

The data should meet functional requirements for the support of user tasks in a cost-efficient manner.

Non, le catalogage n’a pas été inventé par les bibliothécaires pour se faire plaisir (ou pas uniquement).

Les lecteurs de ce blog, quand on leur parle FRBR, se souviendront peut-être des fameux 3 groupes d’entités et de l’articulation entre Œuvre, Expression, Manifestation et Item. Je suis à peu près sûre que parmi les gens qui ont des notions quelconques de FRBR, peu d’entre eux se souviennent que les FRBR, c’est aussi une description détaillée des opérations effectuées par les utilisateurs, réparties en 4 grands groupes : trouver, sélectionner, identifier et obtenir. S’y ajoute le niveau de pertinence des différentes métadonnées pour accomplir ces tâches.

Les RDA reprennent ces tâches pour rappeler à quoi sert chaque partie de la description, ce qui n’est pas du luxe. Cela leur permet de définir les « core elements », dont on a toujours besoin quoi qu’il arrive, et les autres qui ne sont à renseigner qu’en tant qu’ils sont indispensables pour accomplir les tâches utilisateurs.
En cela, ma compréhension de RDA (je n’ai pas fini de les lire, c’est donc plutôt une impression globale) c’est qu’une grande liberté est laissée au catalogueur (ou à l’agence pour qui il travaille) pour décider plus précisément des éléments nécessaires à la description de telle ou telle ressource.
Derrière cette liberté se cache l’économie du catalogage. En effet, RDA nous laisse entrevoir un monde meilleur où on ne décrirait d’une ressource que ce qui est vraiment nécessaire pour la trouver, l’identifier, la sélectionner et l’obtenir, et rien de plus. Un monde où au lieu de répéter N fois l’information, on pourrait relier les ressources et les descriptions entre elles. Un monde où on aurait des descriptions pour des parties, des descriptions pour le tout, et des descriptions hiérarchiques qui les combinent.

Dérivant toujours le long du fil de mes pensées, j’ai saisi l’effluve évanescent d’un souvenir, ou plutôt, d’un leitmotiv que j’ai entendu maintes fois prononcé, chuchoté dans les couloirs : c’est le fantôme du catalogage à niveaux qui revient.
Moi qui suis une (relativement) jeune professionnelle, je n’ai connu du catalogage à niveaux que ces réminiscences lointaines, comme un spectre qu’on aurait eu tant de mal à chasser, et qui s’obstinerait à revenir par la petite porte.
Alors, me suis-je demandé, au fait, c’était quoi le catalogage à niveaux, et pourquoi diable l’a-t-on abandonné ?
Après une courte recherche dans mon moteur préféré, je suis tombé sur cet article de 1988 qui explique que le catalogage à niveaux, c’était :

une présentation élégante, rationnelle : les éléments communs de la notice sont mis en dénominateur commun ; les éléments propres aux volumes sont donnés à la suite les uns des autres

et qu’on l’a abandonné parce qu’il était mal géré par certains formats MARC (notamment nord-américains) et par les progiciels de catalogues de bibliothèques.
Je ne résiste pas à vous proposer cette autre citation d’une saveur toute particulière (nous sommes, je le rappelle, en 1988) :

L’arrivée de nouveaux supports de diffusion utilisant des logiciels documentaires puissants permettant des combinaisons de clés variées et la recherche par mots clés sur la totalité de la notice, confirme aujourd’hui que la séparation des informations est une technique dépassée.

Un élan de nostalgie m’a emportée à l’idée qu’on a renoncé à quelque chose qui était pratique pour les catalogueurs ET pour les utilisateurs, parce que les formats et les systèmes ne savaient pas le gérer.
Puisse l’avenir nous préserver d’un monde où on définit les formats en fonction des systèmes, et les usages en fonction des formats. Voilà à quoi sert l’étape de modélisation : à définir les objectifs du modèle et le modèle lui-même, avant de concevoir les outils qui vont l’exploiter.

NB : en fait, les notices à niveaux n’ont pas totalement disparu du catalogue de la BnF. L’intermarc permet de gérer des « notices analytiques » pour le dépouillement de plages de disques, lots d’images, etc…

Les catalogues sur le Web

Hier j’étais à Médial à Nancy pour une Journée d’études sur les catalogues nouvelle génération ».

Je ne sais pas si ce diaporama apportera quoi que ce soit sans les explications qui vont avec, mais en tout cas j’avais envie de le partager, ainsi que le plaisir que j’ai eu à faire cette présentation devant un public intéressé, attentif et indulgent.
J’en profite aussi pour remercier Françoise L. pour les quelques diapos que je lui ai empruntées et surtout pour ce qu’elle m’a apporté par ses réflexions.

Catalogues en ligne et qualité des données

Ce billet est un résumé du rapport d’OCLC : Online Catalogues : what users and librarians want, publié en avril 2009.

Le rapport d’OCLC porte sur la définition de la qualité des données du catalogue (de Worldcat en particulier, même si la plupart des conclusions peuvent être extrapolées), qui n’est pas la même pour les bibliothécaires et les utilisateurs. Ce sont les usages du Web qui obligent à repenser les objectifs et les modes de fonctionnement des catalogues.
Les priorités (en termes de qualité) des bibliothécaires sont le dédoublonnage et l’utilisation (correcte) des autorités. Celles des usagers sont l’accès aux ressources elles-mêmes (pas seulement à leur description : delivery vs. discovery) et la simplicité d’utilisation des outils leur permettant d’être autonomes.
Le rapport s’intéresse aussi aux besoins des bibliothécaires en tant que professionnels (acquéreurs, catalogueurs, etc.) et prend en compte l’accès à Worldcat par Z39.50.
Les méthodes utilisées pour l’enquête incluaient des focus groups, un questionnaire en ligne, et un questionnaire ciblé pour les professionnels.

Les résultats : ce que veulent les usagers

Pour l’usager, l’accès à la ressource (delivery) est aussi important, voire plus important que le fait d’être à même de la trouver (discovery). Donc ce qui compte c’est

  • de disposer de notices enrichies (résumés, tables des matières, etc. mais aussi des critiques, des notes…) surtout pour permettre d’évaluer si ce qu’on a trouvé correspond à ses besoins ;
  • le classement de résultats par pertinence doit être efficace et évident (on doit comprendre immédiatement pourquoi tel résultat sort en premier)
  • il faut faciliter par des liens directs le passage de la « trouvaille » (notice) à l’accès à la ressource (document).

La recherche par mots-clefs est « reine » mais la recherche avancée et les facettes sont essentielles pour s’y retrouver dans la masse. Les facettes permettent d’affiner sa recherche de manière guidée, sans avoir à parcourir d’interminables listes de résultats. Elles sont bien comprises et vite adoptées par les usagers. Toutefois pour que cela fonctionne, il faut que les données soient indexées de manière structurée.

Dans la liste des éléments de données essentiels pour trouver l’information, l’importance des localisations / données locales (par ex. informations sur la disponibilité) est à souligner.
En ce qui concerne les éléments qui permettent de décider si le livre est pertinent (couverture, résumé, critiques), l’usager souhaite en disposer dès la liste de résultats. Mais en ce qui concerne les critiques, les avis sont partagés avec un clivage assez traditionnel entre experts/chercheurs et étudiants/jeunes/amateurs : les premiers ne les jugent utiles que si elles sont « éditoriales » ou professionnelles, les seconds sont prêts à exploiter des critiques rédigées par d’autres usagers.

Du point de vue de la qualité des données, le besoin d’accéder facilement à des ressources en ligne directement à partir des catalogues de bibliothèque demandera probablement une croissance de l’investissement concernant la gestion des métadonnées de liens et l’interopérabilité avec des données externes.

Les résultats : ce que veulent les bibliothécaires

Comme les usagers, les bibliothécaires définissent la qualité en fonction de leurs objectifs : mais ce sont des objectifs professionnels de type renseignement bibliographique ou sélection /acquisition. Ils se retrouvent avec les utilisateurs sur le besoin d’enrichissement pour évaluer les ressources (plutôt des tables des matières et des résumés que des couvertures, sauf pour les bibliothèques publiques). Mais ils sont aussi obsédés par le dédoublonnage.

Pour le reste cela varie beaucoup selon les types de bibliothèques et les zones géographiques. Les bibliothèques spécialisées accordent une importance particulière à l’ajout des tables des matières et aux liens vers des ressources en ligne. Les bibliothèques publiques s’intéressent plutôt à la mise à niveau des notices abrégées.
Même chose pour les fonctions : les besoins varient de manière importante entre un catalogueur, un directeur de bibliothèque, un agent de service public, un acquéreur… En commun à toutes les fonctions on retrouve le dédoublonnage, les tables des matières, et les liens vers des ressources en ligne.
Les catalogueurs ont des demandes particulières visiblement liées à la récupération de notices dans Worldcat : plus de notices pour des ressources non anglophones, correction et amélioration des notices. Les directeurs de bibliothèque attachent plus d’importance à l’enrichissement par des résumés et des couvertures. Les bibliothécaires de services de référence bibliographique accordent de l’importance aux résumés et aux localisations.

Autres résultats intéressants

L’étude est quand même très orientée livres. Il faut attendre la page 47 du rapport pour voir apparaître autre chose que de l’imprimé ! (il y est dit que les bibliothécaires qui travaillent au contact direct du public sont conscients de l’importance, pour les usagers, d’avoir accès à des contenus enrichis et à des formats autres que l’imprimé, notamment audio et vidéo. Faut-il en déduire que tous les autres bibliothécaires ne s’intéressent qu’au livre ?)

Les éléments de données considérés comme importants par les bibliothécaires sont liés à la recherche de documents précis. Par exemple, la présence de l’ISBN est une priorité essentielle pour nombre d’entre eux. Quand on leur demande ce qu’ils amélioreraient dans les données du catalogue si on leur donnait une baguette magique, les bibliothécaires répondent qu’ils mettraient des ISBN partout ;-)

Alors que les exigences des bibliothécaires sont liés à leur conception traditionnelle des données structurées, les utilisateurs en bénéficient (recherche avancée, facettes) mais n’en ont pas conscience – ce qui les conduit à ne pas exprimer que c’est important pour eux. C’est aussi pour cela que les bibliothécaires accordent plus d’importance à la correction des données.

La perception des besoins des usagers par les bibliothécaires montre une prédominance de l’enrichissement (couvertures, tables des matières, résumés). L’accès aux ressources en ligne vient seulement après, alors que c’est le premier choix des usagers, suivi de l’augmentation des accès sujets.

Conclusions

Il y d’importantes différences dans la perception de la qualité du catalogue, entre les usagers et les bibliothécaires. Cette différence est due à des objectifs différents, mais aussi à un écart de compréhension quant au fonctionnement des données structurées.
Le fait que les usagers trouvent utile la recherche avancée suggère que l’investissement dans la structuration fine des données et l’utilisation de formes contrôlées pour les noms et les sujets représentent un vrai bénéfice pour les usagers, y compris dans les catalogues de demain.

En ce qui concerne les bibliothécaires, leurs différentes fonctions affectent leurs priorités concernant la qualité des données. Les catalogueurs et les acquéreurs valorisent la structure formelle du catalogue, par exemple les index par champs et les autorités, et reconnaissent son importance.

Noter qu’entre l’ouvrage de Charles Cutter Rules for a Dictionary Catalog et les RDA, les principes d’organisation de l’information sont toujours les mêmes. Mais il n’est pas clair que ces principes ont vraiment été testés au regard des attentes des usagers.
Sur le Web, les principaux acteurs ont adopté une démarche à l’opposé : on ne conceptualise que très peu, on procède par essai-erreur. C’est ce qui a permis le développement des principes de « user-centered design ».
Ce qu’il faut maintenant, c’est intégrer le meilleur des deux mondes, étendre la définition de ce que nous entendons par « qualité » dans les catalogues en ligne, et déterminer qui en est responsable. Pour cela, il faudra :

  • augmenter les liens vers des ressources en ligne ou au moins des extraits
  • enrichir l’information sur le contenu (« subject information ») mais pas en utilisant l’indexation matière traditionnelle
  • prendre la mesure du rôle critique des identifiants (ISBN, et autres).

Recommandations pour ceux qui définissent les besoins des futurs catalogues (oui, je me sens un peu visée là, pas vous ?) :

  • analyser, comparer et rééquilibrer l’investissement de la bibliothèque dans les tâches de catalogage, de fourniture de liens et d’enrichissement de notices
  • explorer, avec des partenaires (bibliothèques ou autres) les différents moyens d’obtenir des enrichissements (par ex. des API -> détour chez Karl)
  • encourager la R&D pour améliorer le classement de pertinence
  • accorder plus d’importance aux fonctions d’accès aux ressources
  • automatiser la création des métadonnées et limiter la redondance des tâches, au niveau des réseaux de bibliothèques, et avec d’autres partenaires.

… n’oublie pas mon petit soulier…

… Imaginez…

C’est Noël. Paris se couvre d’un manteau de flocons blancs qui étouffe le bruit de la circulation. L’esplanade de la BnF, entièrement recouverte, s’est transformée en un grand terrain de jeu.

Tout à coup, faisant taire les cris de joie des enfants, retentit le tintement mélodieux d’une nuée de grelots. Les nuages se percent d’une trouée lumineuse, et le traineau du père Noël apparaît, tiré par quatre rennes fringants et volants.
Après avoir voleté quelques instants au-dessus du jardin, il se dirige vers un groupe de bibliothécaires qui se tenaient là au pied d’une tour, se réchauffant les mains à leur gobelet de café, et devisant agréablement des mérites comparés de Google et du catalogue Bn-Opale Plus.

« Je vous ai entendus, déclare le père Noël, et j’ai décidé de vous faire un cadeau. Vous pouvez me demander chacun une fonctionnalité que j’ajouterai au catalogue. Celle que vous voulez. »

Si vous étiez dans ce groupe de bibliothécaires … qu’est-ce que vous demanderiez ? (Perso, je pense que je choisirais la FRBRisation, parce que vu le travail qu’il y a sur les données, un coup de main du père Noël serait le bienvenu ;-)

(PS : soyez nombreux à répondre ! je compte sur vous !)
(PPS : pas de mauvais esprit, hein, soyez constructifs, ne m’obligez pas à modérer…)

Catalogues de bibliothèques et développements agiles

Dans le dernier numéro de Code4Lib Journal, deux informaticiens de la bibliothèque nationale de Suède publient un article intitulé « User-Centred Design and Agile Development: Rebuilding the Swedish National Union Catalogue ».

Il s’agit d’un retour d’expérience sur l’adoption d’une méthode de développement dite « agile » pour le catalogue collectif des bibliothèques suédoises, Libris.
Il s’agissait de reconstruire le système de A à Z, en un an seulement, y compris la partie moteur de recherche. Pour favoriser l’innovation, ils ont opté pour mener en parallèle une conception orientée utilisateurs, s’appuyant sur des études d’usages, et un développement itératif de type agile (SCRUM).
Côté étude d’usages, ils ont d’abord fait un questionnaire, puis des focus groups conduits sur la base de scénarios d’utilisation, et enfin des tests d’usabilité sur un prototype et une interface en version beta. Tout ça nous est assez familier, mais ce qui est nouveau, c’est d’adapter la méthode de développement de façon à ce que les retours des utilisateurs puissent être pris en compte dans la réalisation informatique au fil de l’eau.

Dans une méthode agile, l’objectif est de prendre en compte le fait que les conditions et les objectifs peuvent évoluer avec le temps, même pendant que se déroule le projet.
Cela implique de favoriser :
– les individus et leurs interactions plutôt que les processus et les outils
– les logiciels qui fonctionnent plutôt qu’une documentation extensive
– la collaboration avec le client plutôt la négociation contractuelle
– de répondre au changement plutôt que suivre un plan pré-établi.

Comme le dit très justement l’article, ces principes, pour séduisants qu’ils sont surtout vus depuis les utilisateurs du futur système, posent un certain nombre de problèmes. D’abord, ils sont plus inconfortables pour les décideurs, qui perdent en visibilité sur les charges et les dates ce que le projet gagne en souplesse. Il est donc important d’obtenir dès le départ le soutien des décideurs sur la méthodologie, et de bien leur expliquer que même s’ils ne peuvent pas voir les spécifications, le produit final sera bon. D’autre part, le code ainsi construit peut au final s’avérer instable, ce qu’ils ont résolu dans le projet cité en planifiant une session de 3 semaines dédiée à une évaluation fine de la qualité du code.
Tout cela est en grande partie une question de confiance et un des facteurs décisifs du projet a été la mise à disposition d’un espace commun pour les développeurs, où se tenaient également les réunions de travail avec l’équipe projet.

En conclusion, leur retour d’expérience est plutôt bon sur la méthode agile, qui semble avoir évité bien des écueils. Ce qui leur manque c’est plutôt la documentation et le transfert de compétences entre développeurs. Et ils auraient voulu impliquer encore davantage les utilisateurs dans le processus.
Je ne voudrais pas paraphraser la conclusion, qui est classe, donc la voici :

Finally, we would like to conclude that working with user-centred design in combination with iterative development is a better, faster and cheaper way of software development, compared to traditional models. Better – the product being released at the end is a more up-to-date and bug-free version than had we worked with a more traditional approach. Faster – it is our conviction that with traditional methodology we would not have finished on time, or at least not with the same amount of features implemented. Cheaper – if the same number of people are able to do a better job in a shorter amount of time, it is a more cost-effective way of getting the job done.

Il faut reconnaître que le résultat est pas mal du tout : même en suédois, on arrive à s’en servir ce qui prouve que niveau usabilité, c’est plutôt bien fait !!! Enfin pour expérimenter moi aussi la méthode agile en ce moment, je dois dire que cela me paraît effectivement très prometteur pour les projets innovants en bibliothèque.
Merci à Pintini pour la référence.

SIGB et métadonnées

Le JISC a publié récemment deux études intéressantes :

Library Management Systems Study (mars 2008), un état de l’art comparatif des principaux systèmes de SIGB utilisés dans les bibliothèques anglo-saxonnes et leurs perspectives d’évolution ;

Metadata for digital libraries: state of the art and future directions (avril 2008), un rapport de veille technologique dans lequel il est question en particulier de métadonnées de préservation (METS, PREMIS et tous leurs amis).

Je les ai justes parcourues mais ce que je peux en dire et qui m’a interpelée, c’est qu’aujourd’hui, en 2008, au JISC on pense que l’avenir des SIGB est dans le Web 2.0, les Web services et les mash-up, et que pour faire de belles métadonnées il faut du XML.
Je ne dis pas que c’est faux, hein, je suis moi-même assez attachée à mes annotations collaboratives et autres tags, je prône la liberté des données et il n’y a rien au monde qui me rassure plus que de savoir que mes métadonnées de préservation sont bien au chaud dans de beaux fichiers METS.
Toutefois, tout cela ne manquerait-il pas un peu de vision ? de modularité ? de technologies innovantes ? de standards décoiffants ? Un peu de Semantic Web quoi… ou c’est moi qui suis à côté de la plaque…

Haro

Après presque 5 semaines de vacances, il va me falloir un peu de temps pour me remettre de ces émotions et remonter la longue file d’attente de la veille en retard (même si j’en ai purement et simplement abandonné une partie, d’ailleurs j’ai découvert à cette occasion qu’on ne pouvait pas avoir plus de 200 items dans un fil dans Bloglines…).

Au petit bonheur la chance, donc, voici un des trucs qui ont attiré mon attention dans ce grand dépouillement estival : les gens qui râlent avec une véhémence extraordinaire contre Google Books. Et pour une fois, avec des bonnes raisons, je veux dire, des raisons bibliothéconomiquement recevables.

L’article de Paul Duguid dans First Monday, pertinemment cité et même traduit par JM Salaün, nous rappelle les danger de la fameuse utopie de la reproduction absolue, du transfert complet de support.

Brewster Khlale (le papa d’Internet Archive) donne dans Library Journal une interview assassine qui dénonce l’adhésion des bibliothèques à un programme qui pèche par sa fermeture d’esprit. On verra s’il fait beaucoup mieux avec son méta- catalogue- universel- wiki- encyclopédie- bibliothèque- numérique, Open Library dont on peut voir pour l’instant une démo, sur lequel on peut lire cette interview d’Aaron Schwartz, et dont je reparlerai plus tard.

Pendant ce temps, Google signe avec Keio au Japon et Cornell aux Etats-Unis, entre deux réflexions sur les moldus et les hobbits.

Au fait, depuis octobre 2005, qu’est-ce qui a vraiment changé ?

Moteurs de recherche et données structurées

Il y a toujours un livre dans mon moteur.

Voyons ce qui se passe en Australie quand on travaille sur l’indexation des données structurées, en s’appuyant sur des fonctionnalités propres aux moteurs de recherche : lisons l’article Relevance ranking of results from MARC-based catalogues : from guidelines to implementation exploiting structured metadata par Alison Dellit et Tony Boston, bibliothèque nationale d’Australie, février 2007.

Il y est question de Libraries Australia, un genre de super catalogue collectif australien, dont l’objectif est de devenir aussi courant pour les Australiens que Google ou Amazon… a challenge.

Premier point : la pertinence. On a pris l’habitude de voir arriver en premier les résultats les plus intéressants. Contrairement aux bibliothécaires qui éprouvent le vertige des chiffres, les usagers ne remarquent même pas qu’on leur présente des milliers de résultats. Ils prennent les premiers.
Pour une bibliothèque ce n’est pas aussi anodin qu’on pourrait le croire de calculer la pertinence des résultats. On peut toutefois s’appuyer assez tranquillement sur les données structurées des notices bibliographiques pour ce faire :

Matches in the title, author and subject fields, and those fields which describe the format, nature or form of the item, are more important than general matches within the record.

Matches in multiples of the above fields are more important than matches in just one of those fields.

Et ainsi de suite.

Second point : les ensembles, regroupements, paquets de données en tout genre.
Partant du principe qu’il est difficile d’anticiper ce qu’un usager a vraiment voulu chercher en tapant sa requête, on va lui proposer plutôt de l’affiner après. Pour lui faciliter la tâche, on lui fait un certain nombre de propositions qui vont lui éviter d’avoir à saisir dans un formulaire compliqué le complément de sa question : juste quelques clics.
Ces propositions s’appuient, je vous le donne en mille, sur des données structurées. On affiche quelque chose qui ressemble à de la navigation à facettes, comme dans Worldcat.

Troisième point : recommander.
Une fois que notre lecteur a trouvé son bonheur, on lui en propose d’autres. Pour cela on utilise… des données structurées, oui, certes, mais également des tags, attribués par les utilisateurs.

Pour que tout ceci puisse marcher, il faut rassembler de grandes quantités de données structurées et s’appuyer sur des protocoles ouverts (comme SRU/SRW, ou Opensearch, cités dans l’article).
Le résultat : 48 millions de notices dans un prototype basé sur Lucène, qui classe les résultats, les FRBRise, propose du RSS, interroge Google books search, complète les requêtes par des recommandations, présente des facettes, classe en Dewey et extrait des mots-clefs. Voir ce que ça donne par exemple avec notre ami Newton. C’est remarquable, ça ressemble au rêve qu’on avait en faisant Europeana mais le temps nous a manqué, espérons qu’on le rattrapera.

Lorcan Dempsey aussi a lu cet article, et a aimé.

Worldcat identities

Moi aussi j’avais hâte qu’ils annoncent Worldcat identities.

Lorcan Dempsey nous l’avait montré en avant-première aux entretiens de la BnF. Ca avait l’air chouette. C’est carrément bluffant.

En deux mots, c’est un espèce de mash-up de données sur des auteurs : les livres qu’ils ont écrits, quand il les ont écrits, dans quelle langue, ce qu’on a écrit sur eux…

Je vous laisse découvrir.