Modélisons un peu : le choix d’un type de bases de données

Publié le 13/12/2023 par manuefig

Alors que je préparais mon dernier (ou presque) cours de modélisation de l’année pour les TNAH, m’est venue l’idée saugrenue de faire un arbre de décision qui récapitulerait les critères de choix entre différents types de bases de données : relationnelles, NoSQL, graphes, colonnes, bases de données documents XML ou non, moteurs de recherche… Il y a beaucoup d’options et ce n’est pas toujours évident d’avoir les idées claires.

Je me suis donc tournée vers Gautier, dont le puits de slides reste la ressource n°1 en matière de formation à la donnée, pour qu’il m’aide à trouver les bonnes formulations et à raconter des choses pertinentes du point de vue de l’infrastructure technique. Il faut dire que cette question nous agite depuis pas mal de temps (on se souviendra des quelques nuits blanches qu’on a passées au moment où on a décidé de mettre les métadonnées de SPAR dans un triple-store RDF) et qu’on se sent un peu responsables du prosélytisme qu’on a pu faire autour des technologies du web sémantique, aujourd’hui largement remises en perspective (lire la série de 4 billets à ce sujet sur Les petites cases).

Néanmoins, après quelques années où j’ai carrément refusé de continuer à enseigner RDF et SPARQL en arguant que ça ne servait plus à rien (merci le creux de la désillusion), je constate actuellement un regain d’intérêt pour le web de données, notamment dans le contexte des données « FAIR » pour la recherche. Je vois régulièrement passer des fiches de stage / de poste qui demandent des compétences en web sémantique, que ce soit pour modéliser des ontologies ou pour faire des requêtes SPARQL. Il est donc important de continuer à former des ingénieurs et analystes des données dans ce domaine, mais en prenant la précaution de replacer cette technologie dans le paysage global des systèmes de gestion de données existant à l’heure actuelle. L’enjeu est de bien comprendre dans quels cas elle peut rendre des services, et dans quelles situations il vaut mieux se tourner vers autre chose.

Différents types de modèles

C’était donc le point de départ de ma démarche, et il m’a emmenée assez loin :

d’abord, il a fallu rappeler que quand on parle de modélisation de données, on a en fait 3 couches de modèles :
- le modèle conceptuel, qui décrit des entités du monde réel et leurs relations,
- le modèle logique qui exprime les données sous une forme pouvant être manipulée par un traitement informatique,
- et le modèle physique qui correspond à la façon dont l’information est exprimée dans un format ou stockée dans un logiciel.

Schéma présentant les 3 types de modèles : conceptuel, logique, physique. Il reprend ce qui est expliqué dans le texte.

À partir de là, j’ai pu détailler les principes et les spécificités des 3 types de modèles logiques :
- le modèle en tables, qui organise les données en tableaux où chaque colonne correspond à un attribut et chaque ligne à une instance ou enregistrement (c’est le modèle des bases de données relationnelles, mais aussi des jeux de données tabulaires en Excel ou CSV),
- le modèle d’arbre, adapté pour représenter une information organisée hiérarchiquement sous la forme de documents (par exemple, en XML ou en JSON),
- le modèle de graphe, où les données sont reliées entre elles suivant la logique des prédicats (en RDF) ou d’autres types de logique de graphe comme les property graphs.
On va alors pouvoir s’intéresser aux différents types de SGBD (systèmes de gestion de base de données) qui correspondent à ces modèles :
- les bases de données relationnelles,
- les bases de données en colonnes,
- les bases de données document,
- les bases de données graphe.

Pour mémoire, ces « bases de données » ou plutôt ces « systèmes de gestion de bases de données » sont des logiciels qui assurent le stockage des données suivant un modèle logique, et fournissent des interfaces – souvent normalisées – pour interagir avec les données. Par exemple, dans une base de données relationnelle, les données sont stockées dans des tables et on interagit avec elles grâce au langage de requête SQL. Passons en revue de manière un peu plus détaillée ces différents outils.

Différents systèmes de gestion de base de données

Les bases de données relationnelles sont les doyennes de leur catégorie et en même temps, restent des outils fiables, solides et maîtrisés, qui peuvent rendre des services à différentes échelles, de la gestion d’informations personnelles en local jusqu’au pilotage d’énormes systèmes d’information. Elles sont efficaces pour stocker des données complexes dans des grandes volumétries, en offrant de bonnes performances en lecture (pour consulter les données) comme en écriture (pour produire et modifier les données).
Surtout, les bases relationnelles sont conformes aux propriétés ACID (Atomicité, Cohérence, Isolation, Durabilité), c’est-à-dire qu’elles garantissent la gestion des transactions. Imaginons que vous ayez besoin de faire une modification dans vos données qui va impacter 500 enregistrements : c’est une transaction. Une fois que celle-ci est lancée, la base va soit l’exécuter jusqu’au bout, soit revenir à l’état initial (en cas de plantage par ex.) Si on lui demande une autre modification (une autre transaction) entre temps, celle-ci sera mise en file d’attente. Grâce à ce principe, la cohérence des données est garantie : il est impossible qu’une même donnée soit simultanément dans deux états différents.
Ces propriétés des bases de données relationnelles en font les favorites dans de nombreuses situations. Il peut toutefois arriver que vos données soient trop hétérogènes pour être exprimées en lignes et en colonnes : ainsi, lorsque je décris un inventaire d’archives, il m’est impossible de savoir à l’avance combien il aura de composants et comment j’aurai besoin de les décrire. Dans ce cas-là, d’autres modèles logiques peuvent être plus indiqués (on les regroupe parfois sous le nom de « NoSQL » ce qui veut juste dire que ce ne sont pas des bases de données relationnelles).

Une autre limite des bases de données relationnelles réside dans la contrainte de cohérence qu’imposent les principes ACID : il est (presque) impossible de les exécuter dans les environnements distribués qui caractérisent aujourd’hui le « big data ». En effet, ces environnements reposent sur le principe de scalabilité horizontale : quand j’ai besoin de plus de performance, je rajoute des machines en parallèle. Il devient alors difficile de continuer à garantir la cohérence des données, car elles peuvent être écrites et lues à différents endroits, avec un délai variable de synchronisation (je schématise sans doute beaucoup trop, mais vous voyez l’idée.)
Le théorème de CAP nous enseigne qu’un système ne peut pas être à la fois cohérent (C), toujours disponible (A pour Available) et distribué (P pour Partition) : les systèmes ACID se concentrent sur les deux premiers, et les systèmes distribués sur les deux derniers.

Visualisation du théorème de CAP sous la forme d'un schéma. On voir que les bases de données relationnelles sont entre le C (consistency) et le A (availability)

Si on a absolument besoin de scalabilité horizontale, et que le modèle est assez simple pour être réduit à une seule table, les bases de données en colonnes (Column Store) peuvent s’avérer utiles. Mais cela arrive quand même assez rarement dans le domaine des données culturelles et historiques, donc je ne m’étendrai pas sur ce scénario.

Les bases de données document sont conçues pour accueillir des données semi-structurées sous la forme de fichiers XML ou JSON par exemple. C’est pour cela qu’on parle de base de données orientée document : 1 fichier = 1 document. Elles permettent une montée en charge progressive des volumes de données, c’est à dire qu’il est relativement simple d’ajouter de nouvelles données (sous la forme de nouveaux documents ou fichiers) sans perturber les données existantes.
Leur principale contrainte est d’imposer un modèle centré sur une entité principale : pour que la base soit cohérente, il faut que tous les documents qui la composent soient de même nature (par exemple, des éditions de texte en TEI ou des inventaires d’archives en EAD). Cela va imposer une limite forte : si on a des données transverses à plusieurs documents (par ex. un référentiel de personnes pour les auteurs, producteurs, personnes évoquées ou représentées…) et que celles-ci sont modifiées fréquemment, il va falloir modifier tous les documents où ces données sont présentes, ce qui peut être assez lourd et surtout risqué. Sans la garantie ACID (voir ci-dessus, les bases relationnelles), on peut se retrouver dans une situation où une partie des documents est mise à jour, le système plante au milieu du processus, le reste n’est pas modifié… et paf, incohérence dans les données !

Le moteur de recherche est une base de données document dotée de fonctionnalités particulières : il facilite notamment la recherche plein texte (grâce à la constitution d’un index) et le filtrage par facettes des résultats. Il permet en outre de très bonnes performances en lecture (montée en charge du nombre d’utilisateurs et vitesse de réponse). Par contre, en raison des limites évoquées ci-dessus, on a plutôt tendance à l’utiliser comme stockage secondaire, c’est-à-dire qu’il va servir uniquement en lecture et pas en écriture, celle-ci étant assurée par un stockage primaire dans un autre type de base.

Schéma : le stockage primaire contient des data avec un accès principalement en écriture. Le stockage secondaire sert principalement l'accès en lecture pour les utilisateurs. Synchronisation entre les 2.

Finalement, si on a un modèle de données trop complexe pour l’exprimer sous forme de documents, et trop hétérogène pour qu’il rentre aisément dans une base de données relationnelle, cela vaut le coup de regarder du côté des bases de données graphes. Celles-ci sont aux données ce que la lampe magique est à Aladin : « des pouvoirs cosmiques phénoménaux… dans un vrai mouchoir de poche ! » (si vous m’avez lue jusque là, vous me pardonnerez la métaphore.)
Le mouchoir de poche, c’est le modèle de triplet (ou de quadruplet, ou autre, suivant le type de graphe que vous utilisez) : on réduit la complexité du modèle à une logique minimaliste et flexible, qui permet d’exprimer à peu près n’importe quoi (d’où les pouvoirs phénoménaux). Mais… all magic comes with a price. Et le prix à payer c’est que ces modèles sont relativement complexes à manipuler, avec des enjeux de maintenabilité et de performance.

Gif animé extrait de la série "Once upon a time" : Rumplestiltskin lève sa baguette en disant "all magic comes with a price"

Si le monde des graphes vous tente, la question est de savoir si vous avez besoin de placer votre graphe dans le web de données, pour faire le lien avec une communauté qui a décidé d’adopter les standards du web sémantique, notamment RDF et SPARQL (ce qui peut quand même être le cas assez souvent dans le domaine des données culturelles et des données de la recherche). Si oui, vous pouvez envisager d’utiliser un triple-store RDF. Mais il faut garder en tête que ces outils ont souvent des limites de performance et qu’ils sont assez peu maîtrisés dans l’industrie (ce qui veut dire qu’il sera difficile de trouver des prestataires pour les développer et les maintenir).
Si vous n’avez pas d’enjeu de diffusion web, pourquoi ne pas opter pour un autre type de graphe comme les « property graph » ? Cela permet de se débarrasser de certains détails agaçants comme la réification (acrobatie de modélisation nécessaire pour représenter certaines informations dans le modèle de triplet) ou les URI (parce que quand même, les URI, c’est compliqué, et si vous pensez le contraire je vous invite à venir expliquer le concept des préfixes en classe l’an prochain).
Malgré tout, ces outils ne vous offriront pas la même robustesse qu’une bonne vieille base de données relationnelle, et resteront plus difficiles à manier qu’une base orientée document (pour afficher le graphe, il faut le redocumentariser de toute façon, c’est-à-dire choisir les triplets qui décrivent une entité et les réunir dans un document JSON, XML ou autre). Cela vaut donc quand même le coup de se demander si l’exposition dans un SPARQL endpoint ne peut pas être un stockage secondaire : au passage, c’est le cas dans data.bnf.fr, qui est construit avec l’outil Cubicweb de Logilab dans lequel les données sont stockées sous la forme d’une base de données relationnelle, quand bien même on a un modèle logique en RDF (cf ci-dessus : dans ce cas précis, il y a une différence entre le modèle logique et le modèle physique). De la même manière, si on a des données stockées de façon primaire sous forme de graphe, disposer d’un stockage secondaire de type moteur de recherche peut aider à résoudre par exemple des problèmes de performance ou à simplifier l’accès aux données.

L’arbre de décision

Après toutes ces réflexions (pfiou !), nous voici prêts à parcourir l’arbre de décision qui résume tout cela :

Arbre de décision permettant de sélectionner un modèle logique et un système de gestion de base de données en fonction d'un modèle conceptuel.

Cet arbre de décision part du principe que vous avez déjà défini votre modèle conceptuel, que vous savez donc de combien de classes et de relations vous avez besoin, quels sont les attributs de vos entités et s’ils sont plutôt homogènes (toutes les instances d’une classe sont décrites de la même manière) ou pas.

La partie haute du schéma vous permet de déterminer quel est le meilleur modèle logique en fonction de votre modèle conceptuel.
La partie du milieu vous permet de déterminer quel est le meilleur type de système de gestion de base de données en fonction de vos usages.
Enfin, la partie du bas identifie les cas où l’on peut avoir besoin d’un stockage secondaire.

Il a fallu 134 diapos à Gautier pour expliquer tout cela. De mon côté, j’y passe une vingtaine d’heures en cours. Ici je vous propose une grosse tartine de texte assortie d’un outil de pensée visuelle : il va de soi que cela n’épuise pas le sujet, mais j’espère quand même que ce billet pourra rendre quelques services (que celles et ceux qui veulent qu’on écrive un manuel complet sur la data lèvent la main !)

Toujours plus de futurs fantastiques ! (édition 2023)

Publié le 19/11/2023 par manuefig

Vue de la salle principale du bâtiment "The Permanent", avec un plafond en verre coloré

Nous voici à Vancouver, dans une ancienne banque construite en 1907, un bâtiment appelé « The Permanent » qui est désormais le siège canadien d’Internet Archive. C’est là que se sont réunis, en ce mois de novembre 2023, les membres de la communauté AI4LAM, consacrée à l’intelligence artificielle dans les institutions culturelles. Souvenez-vous, j’avais assisté à la conférence Fantastic Futures, 2e édition, à Stanford en 2019, et organisé celle de 2021 à Paris.

Cette année, le programme inclut une journée de workshops et deux jours de conférence plénières (dont les enregistrements vidéo devraient être bientôt diffusés), auxquels s’ajoute une réunion du AI4LAM council, l’un des organes de pilotage de la communauté. Je vous livre ici mon compte-rendu partial, partiel et personnel de ces trois jours de travail fécond : pour la première fois, j’avais la sensation de participer en observatrice, étant sortie de la communauté des professionnels, mais préoccupée par une question en particulier : quelle formation faut-il proposer aux personnes qui vont mener des projets IA dans les bibliothèques, archives et musées dans les années à venir ?

Un enjeu : embarquer !

Si les conférences de 2018 et 2019 étaient celles de la découverte, principalement tournées vers la sensibilisation aux enjeux d’une technologie émergente encore peu utilisée dans le monde culturel, celle de 2021 avait montré la maturité de plusieurs projets massifs dans des institutions pilotes. En 2023, le monde a changé : l’irruption de Chat-GPT est vue comme un déclic qui a fait évoluer la perception de l’IA dans la société et de fait, dans les institutions patrimoniales. Il ne fait désormais plus de doute que l’IA est dans le paysage et va changer la donne pour beaucoup de métiers et d’activités : au-delà des « early adopters« , chacun réfléchit à son « use case« , son projet ; la conférence fait la part belle à l’expérimentation, celle-ci requérant de moins en moins de moyens et de compétences techniques, tant le cloud offre de services clef-en-main.

Pour moi, la question majeure qui se pose cette année c’est comment faire « embarquer » dans le vaisseau AI4LAM de nouveaux collègues, qui ont certes de nouveaux projets, mais souhaitent surtout apprendre, comprendre, s’approprier ces nouveaux outils qui ont à présent fait leurs preuves et découvrir comment les intégrer dans leur quotidien.

Dans ce contexte, beaucoup des personnes présentes à Vancouver font figure de spécialistes, de « passeurs », d’accompagnantes : sans être toujours des expertes en ingénierie, elles peuvent jouer le rôle d’aider à embarquer leurs collègues, que ce soit à l’échelle d’une institution, de la communauté dans son ensemble ou d’un groupe spécifique (comme le chapitre francophone d’AI4LAM récemment créé). La question, c’est comment faire !?

Phase 1 : comprendre

Je m’inspire ici du AI planning framework de la Library of Congress, publié juste la veille de la conférence, pour nommer cette première étape. L’outil est encore jeune et demande à être testé, même si le LC Labs a passé cette année à l’éprouver en interne : nos collègues Laurie Allen et Abbey Potter nous invitent maintenant à nous en saisir pour nous aider notamment dans les phases amont de la planification d’un projet IA.

Quel projet IA êtes-vous ?

L’idée est la suivante : quelqu’un débarque dans votre bureau et vous annonce qu’il ou elle souhaite faire un projet IA sur {insérez ici le sujet de votre choix}. On va alors planifier le projet en 3 phases :

une phase d’analyse (understand) visant notamment à évaluer son intérêt, sa faisabilité et à gérer les attentes notamment en matière de qualité du service rendu,
une phase d’expérimentations itératives, visant d’abord à voir si la technologie envisagée fonctionne, puis quels résultats on peut espérer en attendre, et enfin comment ceux-ci peuvent s’intégrer dans le fonctionnement du service,
et enfin, une phase d’implémentation qui implique la mise en place de politiques et standards qui vont garantir un usage responsable de l’IA.

L’outil créé par le LC Labs prend la forme d’une série de questionnaires (« worksheets« ) qui accompagnent chaque étape et jouent autant un rôle de sensibilisation technique et stratégique que de planification. On y trouvera ainsi une analyse des risques, un diagnostic sur l’état et la disponibilité des données, un plan de traitement données et un modèle de contractualisation (les outils de la phase « implement » sont encore en construction).

Cette phase d’analyse préalable est aussi celle où il va falloir se familiariser avec des notions clefs (qu’est-ce qu’une vérité terrain ? comment entraîner un modèle ? ça veut dire quoi fine-tuner ? etc…) et où la formation (qu’elle porte ce nom ou pas, on a souvent parlé plutôt de montée en compétences collective) va jouer un rôle. Cette question était au cœur de plusieurs des workshops du mercredi, l’un des fils rouges étant d’intégrer l’IA dans la littératie numérique classique des bibliothécaires, à travers des initiatives comme Library Carpentry ou dans des cadres de référence comme celui de l’ACRL (association des bibliothèques de recherche américaines).

Le voir pour le croire

Comprendre, cela passe aussi par le fait de pouvoir soi-même tester et manipuler les outils d’intelligence artificielle. Si Chat-GPT a été une telle révolution (alors que les « LLM », large language models, de type transformers étaient dans le paysage depuis plusieurs années), c’est parce que tout à coup, on disposait d’une interface permettant à n’importe qui de les utiliser. Appliquant ce concept aux GLAMs et au traitement des images (computer vision), le projet AI explorer du Harvard Art Museum propose de se poser la question suivante : chacun de nous voit des choses différentes quand il regarde une œuvre d’art ; que voient les ordinateurs ? Les œuvres du musée numérisées ont été étiquetées avec une palette d’outils IA disponibles sur le marché : on peut dès lors comparer les approches de ces différents outils et observer leur pertinence ou au contraire, leurs hallucinations.

Dans le même esprit, on a cité MonadGPT, un chatbot réalisé par Pierre-Carl Langlais qui a été entraîné uniquement sur des textes du 17e siècle et répond donc aux questions avec une vision du monde arrêtée à cette époque. On mesure ainsi l’impact du choix des corpus d’entraînement sur le résultat obtenu, ce qui permet aussi de relativiser la pertinence d’outils comme Chat-GPT.

Enfin la Teachable Machine de Google (utilisée par Claudia Engel et James Capobianco dans leur workshop) permet d’entraîner un véritable modèle Tensorflow sur des images, des sons ou des mouvements sans avoir besoin de connaître la moindre ligne de code. Voilà qui permet d’appréhender par la pratique ce que veut dire entraîner et tester un modèle : il n’y a rien de tel pour se confronter aux enjeux de sélection des données que cela peut poser. J’ai aussi entendu dire que la Teachable Machine était utilisée dans certains projets où on a besoin de faire entraîner les modèles par des chercheurs qui n’ont pas de compétences techniques, pour ensuite récupérer et déployer le fichier Tensorflow qu’elle génère. Mais là, on entre dans les phases suivantes : expérimenter et implémenter (merci pour la transition !)

Phase 2 : expérimenter

L’expérimentation, c’était vraiment le maître mot de cette conférence : une multitude d’outils, d’exemples, de cas d’usages nous ont été présentés et j’aurais même du mal à tous les lister ici. La démarche était souvent une quête d’appropriation : cet outil existe, il a l’air de fonctionner, ce n’est pas si compliqué que ça de l’utiliser, et si je l’essayais sur mes collections ? Mais ce qui m’a le plus frappée, c’est l’inventivité dont font preuve les collègues pour tirer parti notamment des IA génératives dans les contextes les plus divers.

Prompt engineering et métadonnées

Bien sûr, en tant que bibliothécaires, la première question (ou presque) qu’on se pose, c’est de savoir si on ne pourrait pas générer des métadonnées et des descriptions structurées à partir des documents eux-mêmes. Au-delà des approches qu’on connaissait déjà (comme l’utilisation d’Annif pour générer des indexations sujet), certains se sont lancés dans des opérations complexes de prompt engineering : chaînage, utilisation d’exemples et de fonctions, intégration de Json et d’instructions de formatage aux prompts pour générer des données structurées… Voir par exemple les expérimentations réalisées par le groupe Metadata d’AI4LAM ou encore les travaux de William Weaver sur la transcription des inscriptions figurant sur les herbiers : dans ce dernier cas, il combine segmentation des zones de texte, production d’un OCR et prompt engineering pour passer de la numérisation en mode image à la génération d’un tableur où ces informations sont rangées de manière organisée… merci le LLM !

Chatbots et archives

Une autre « famille » d’applications nous emmène vers une approche complètement nouvelle des archives : et si on pouvait poser des questions aux documents au lieu de les lire ? Plusieurs projets comme Rednal.org se sont penchés sur l’idée d’un chatbot qui se limiterait à un document, un fonds ou un corpus et auquel on pourrait demander par exemple de résumer les idées importantes ou de chercher si telle ou telle information s’y trouve. JSTOR a même déployé ce service en version Beta, en y ajoutant une aide à la recherche qui permet de rebondir depuis un document vers d’autres ressources disponibles sur la plateforme. Ce ne sont pas des idées 100% nouvelles : un assistant pour nous aider à nous balader dans la bibliothèque numérique, on l’avait déjà rêvé, mais grâce à Chat-GPT, ils l’ont fait et le résultat est assez bluffant.

Transcrire et annoter les ressources audiovisuelles

Le traitement des ressources audiovisuelles, et en particulier le speech-to-text avec le modèle open source Whisper, semble être enfin l’un des domaines essentiels d’utilisation de l’IA dans les GLAMs. Le projet conduit par Peter Sullivan pour Interpares sur les archives audio de l’Unesco a montré qu’une approche multilingue était possible (et que la diplomatique pouvait jouer son rôle dans l’amélioration de la génération de métadonnées ;-). Nous avons eu droit à une petite démo de la plateforme australienne ACMI (en Beta) et de l’impressionnant éditeur de workflow d’AMP (Audiovisual Metadata Platform), un générateur open source de métadonnées pour contenus audiovisuels (pas encore en production).

Que retenir de toutes ces expérimentations ? Principalement que cette étape d’expérimentation, la 2e dans le modèle de planification de la LoC, est en fait une phase itérative au cours de laquelle on passe par plusieurs questions :

est-ce que cet outil peut marcher sur mes collections ?
une fois qu’il fonctionne, quel niveau de qualité peut-on en attendre ?
une fois que j’ai atteint le niveau attendu, comment l’intégrer à mes services opérationnels ?

Et ainsi, nous voici en route vers la 3e phase : implémenter.

Phase 3 : implémenter

La question du passage de l’expérimentation « R&D » à la mise en production ou intégration aux services opérationnels était l’un des points abordés dans la table ronde que l’on m’a chargée d’animer avec plusieurs institutions (Stanford et Harvard Libraries, bibliothèque nationale de Norvège, Library of Congress et National Film and Sound Archives en Australie). Ces institutions, dont plusieurs se sont dotées de « Labs », reconnaissent que le pas est difficile à franchir, notamment pour des raisons organisationnelles. Face à l’IA, avant même d’entrer dans les enjeux techniques, se posent des questions de montée en compétences, d’alignement des valeurs et des attentes, de disponibilité des données, de mutualisation des moyens.

J’ai apprécié le fait qu’on nous ait proposé des retours d’expérience divers dans ce domaine : du bilan dressé par la British Library de l’imposant projet Living with machines (qui vient de se terminer) au rapprochement informel de trois institutions fédérales couvrant la palette des LAM (LoC, NARA et Smithsonian) en passant par le comité IA que la bibliothèque de l’Université du Mississippi a mis en place pour répondre aux sollicitations contradictoires des universitaires et étudiants… Il existe bien des modèles et des approches pour envisager l’IA dans les institutions culturelles, qui ne nécessitent pas toutes le même degré d’investissement dans le développement et les infrastructures.

Mais quand même, la question qui brûle toutes les lèvres, c’est de savoir si ces tous ces services innovants sont déployés à l’échelle, visibles, disponibles pour les usagers !

Le « vault », coffre-fort de The Permanent… Les secrets de la mise en production de l’IA sont-ils cachés ici ???
(Photo Neil Fitzgerald)

Alors oui, j’en ai déjà cité quelques exemples : on a des versions Beta à droite et à gauche que l’on peut voir fonctionner ; on a vu par exemple apparaître un nouveau service « Text-on-maps » sur le site de la David Rumsey Historical Map collection de Stanford qui est assez épatant.

Du côté déploiement à l’échelle, on va trouver les « gros » acteurs qui ont à la fois une force de frappe importante en matière d’investissement et l’agilité qui reste difficile à atteindre dans le service public. Internet Archive a ainsi déployé son portail « Internet Archive Scholar » qui utilise l’intelligence artificielle pour repérer des articles scientifiques dans l’archive web et extraire des métadonnées (savourez le logo vintage…) OCLC a testé un algorithme de dédoublonnage des notices dans Worldcat qui leur a permis de passer d’un taux d’élimination des doublons tournant autour de 85-90% à plus de 97%, sur des millions de notices. Ainsi, certaines applications de l’IA sont mises en service « dans l’ombre », à un endroit où l’internaute ne peut pas les voir mais bénéficie du service rendu : recadrer les pages issues de la numérisation ou améliorer la qualité de l’OCR chez Internet Archive, marquer les « unes » des journaux numérisés à la Bibliothèque nationale de Norvège…

La technologie et l’humain

Au final, quand on examine tous ces projets (y compris ceux de la phase expérimentale), c’est souvent la question de la qualité des données qui freine, voire empêche la mise en production. Quand on exige un taux d’erreur nul ou presque, l’automatisation est-elle la bonne solution ? Beaucoup répondent en proposant de voir l’IA comme un « copilote », qui ne va pas résoudre tous les problèmes mais seulement faciliter ou assister le travail des humains dans une collaboration fructueuse. Les humains sont donc toujours dans la boucle (Human-in-the-loop comme on dit en anglais).

Ce qui nous amène aux questions éthiques, loin d’être absentes de cette édition puisque les deux conférences introductives les ont abordées, sous des angles différents. Thomas Mboa, chercheur en résidence au CEIMIA, a développé le concept de technocolonialité, posant l’idée qu’à l’heure actuelle, l’enjeu de la colonisation n’est plus géographique : nous sommes tous colonisés par la technologie, et il nous revient de veiller à préserver notre intégrité culturelle, en luttant contre l’extractivisme numérique (exploitation des fournisseurs de données, par le digital labor et autres) et le data-colonialisme, et en luttant en faveur de l’ouverture, de la justice des données et de la mise en places d’écosystèmes de confiance entre les acteurs.

C’est encore la confiance qui était mise en avant par Michael Ridley de l’Université de Guelph au Canada, deuxième conférencier qui prônait l’explicabilité de l’intelligence artificielle (couverte par le sigle XAI), pas seulement pour les développeurs qui cherchent à ouvrir la boîte noire, mais pour toutes celles et ceux qui interagissent avec ces algorithmes. Ces différentes visions concouraient finalement à envisager l’IA comme un collaborateur de plus dans une équipe et à parler, plutôt que d’intelligence artificielle, « d’intelligence augmentée ».

En guise de conclusion, un plan d’action

Il y aurait sans doute encore beaucoup à dire, mais je vais clore ce billet déjà trop long en revenant sur ma question de départ : aujourd’hui, à quoi faut-il former les professionnels qui auront à mener des projets IA dans des institutions culturelles ? (Par exemple dans le cadre d’un master dont ce serait précisément la fonction…) Au-delà des bases théoriques de l’IA et des principaux cas d’usage, il me semble qu’il y a plusieurs idées qui méritent d’être creusées :

analyser, diagnostiquer, faire des études amont pour déterminer la faisabilité d’un projet : prendre en main l’outil de planning de la LoC, le tester, voire le traduire en français pourrait être très utile dans ce contexte ;
utiliser des API pour intégrer les différents modèles existants dans une chaîne de traitement de données ;
faire du prompt engineering avancé pour apprendre à exploiter de manière productive les LLM, en combinaison avec d’autres outils de traitement comme l’OCR/HTR par exemple ;
travailler sur la qualité des données en amont comme en aval du processus IA, maîtriser les métriques habituels (précision, rappel etc.) mais aussi savoir élaborer des démarches d’évaluation de la qualité spécifiques à des contextes ou des usages particuliers ;
enfin, promouvoir des modèles ouverts, explicables, soucieux du respect de l’humain et de l’environnement, bref des IA conçues et utilisées de manière responsable.

Du côté d’AI4LAM, la discussion du conseil a aussi débouché sur l’idée qu’il allait falloir mettre en place des dispositifs d’embarquement pour les nouveaux collègues. Un réservoir de diapos de référence, des présentations régulières d’introduction aux bases de l’IA pour les GLAM (en plusieurs langues et dans plusieurs fuseaux horaires), une « clinique de l’IA » où chacun pourrait venir avec ses questions, des sessions Zoom de rencontre autour de thématiques spécifiques… sont autant d’idées que nous avons brassées pour y parvenir. Il y aura des appels à la communauté pour participer à ces initiatives alors si vous voulez nous rejoindre, n’hésitez pas !

Pour s’abonner aux différents canaux d’échange d’AI4LAM, c’est par ici. Pour devenir membre du chapitre francophone, il vous suffit de rejoindre le forum de discussion du groupe.

Archiver le web pour les chercheurs : mode d’emploi

Publié le 24/02/2023 par manuefig

Depuis deux ans, grâce au projet ResPaDon, je travaille de manière un peu plus approfondie sur les usages des archives web pour la recherche, et ça tombe bien car mes nouvelles activités depuis octobre me conduisent en ce moment d’une part à me replonger dans ma thèse en vue de son édition, et d’autre part à enseigner sur le sujet.

Alors en attendant la journée d’étude professionnelle et le colloque « Le web, source et archive » qui vont conclure ce beau projet respectivement le 13 mars à la BnF et les 3-5 avril à Lilliad, voici en mode mise en bouche un petit mode d’emploi pour les chercheurs qui ont besoin d’archiver des contenus web.

Vous allez me dire, c’est quand même assez spécifique, il y a finalement assez peu de gens qui sont concernés. Mais en fait si. Cela peut arriver à tout le monde de tomber sur un lien mort, une erreur 404 (à commencer par moi-même quand je cherche des vieux trucs dans mon blog, vu que j’ai pété toutes mes URL).
Si on anticipe un tout petit peu ce problème, en tant que chercheur (au sens très large de « quelqu’un qui cherche », quel que soit le sujet, il arrive qu’on tombe sur des ressources en ligne dont on n’est pas sûr qu’elles seront encore là demain (par exemple le blog d’une personne irresponsable qui ne fait pas attention à la préservation de ses URL) voire dont on est sûr qu’elle n’y seront plus (par exemple une fiche de poste intéressante pour réfléchir aux compétences d’étudiants en master).
Dans ces cas-là, si on veut fonder une réflexion scientifique qui tient la route, pouvoir citer la ressource dans un article ou tout simplement en garder la trace, on a besoin de l’archiver.

Voici quelques méthodes qui peuvent être utilisées pour ce faire, de la plus simple à la plus complexe.

1. Zotero : vous utilisez déjà cet outil pour vos références bibliographiques, vous avez déjà installé une extension sur votre navigateur préféré pour sauvegarder en un clic une référence. Si vous le faites sur une page web lambda, le mode « snapshot » archive une copie de la page et vous pourrez la rejouer plus tard. [Edit] Cette méthode peut néanmoins finir par peser lourd sur votre disque dur ; heureusement il existe une extension Memento qui permet de récupérer dans Zotero un lien vers la Wayback Machine d’Internet Archive.

2. Le service Save Page Now d’Internet Archive : également doté de son extension, il vous permet non seulement de chercher une copie archivée d’une page si vous tombez sur une erreur 404, mais aussi d’archiver en 1 clic la page que vous consultez (et si besoin, tous ses liens sortants) dans la Wayback Machine. Cela évite d’encombrer votre disque dur, vous garantit de pouvoir la retrouver, peut être utile à d’autres gens et en plus, il y a plein d’autres fonctionnalités vraiment cool comme la cartographie de site…

3. Les outils de WebRecorder.io : derrière ce service, une communauté d’ingénieurs (dont Ilya Kremer) qui travaillait au départ sur l’idée de « browser-based archiving » c’est à dire d’archiver les sites en se basant sur la navigation d’un internaute. Plus besoin de cliquer sur les pages une à une, un outil comme archiveweb.page (toujours sous la forme d’une extension) vous permet d’enregistrer toute une session de navigation et de l’éditer après. Il y a aussi l’outillage nécessaire pour constituer une archive web avec Python pour les plus aventureux.

4. Hyphe : outil développé par le MediaLab de Sciences Po, il permet de constituer de véritables corpus web. Là, on entre quand même dans les outils plus spécifiques pour les chercheurs qui utilisent le web comme source de façon plus systématique.

5. Le BnF DataLab : si vraiment le web est votre sujet de recherche ou votre principale source, vous finirez sans doute par vous tourner vers des dispositifs plus institutionnels qui permettent d’entrer dans des partenariats avec les organismes en charge du dépôt légal de l’Internet : la BnF et l’Ina. Ceux-ci proposent des outils spécifiques pour naviguer dans les pétaoctets d’archives web amassées depuis plusieurs dizaines d’années, par exemple – sur certains corpus – la recherche plein texte, l’analyse de la tendance d’un terme ou des métadonnées et statistiques diverses.
Dans le DataLab, suite aux travaux conduits dans le projet ResPaDon, il est possible d’utiliser Hyphe pour explorer le web archivé par la BnF. Certains projets accueillis en partenariat peuvent aussi bénéficier de collectes « à la demande », pour lesquelles bibliothécaires et chercheurs vont s’associer pour constituer ensemble un corpus pérenne à des fins de recherche.

Il y en a donc pour tous les goûts, y compris pour les webmestres qui peuvent par exemple utiliser le service Arquivo404 pour proposer sur leur site un lien vers les archives web du Portugal quand la page est introuvable (pourquoi le Portugal me direz-vous, eh bien cette archive partage avec Internet Archive la caractéristique d’être en accès ouvert, là où la plupart des archives web institutionnelles, soumises aux conditions d’accès du dépôt légal, sont consultables uniquement sur place dans les établissements).

Si le sujet vous intéresse, on se retrouve le 13 mars à la BnF, ou à défaut sur Twitter et/ou Mastodon (oui c’est nouveau !) pour de nouvelles aventures avec les archives web.

Les fantastiques futurs de l’intelligence artificielle

Publié le 12/12/2019 par manuefig

La semaine dernière, j’ai eu la chance d’être invitée à me rendre à Stanford pour participer à la conférence Fantastic Futures, 2e du nom, un événement dont l’objectif était de faire émerger une communauté autour de l’intelligence artificielle pour les archives, les bibliothèques et les musées.

Spoiler : la communauté s’appelle AI4LAM, elle a un site web, des chaînes Slack et un groupe sur Google. Sinon, pour revoir la conférence, c’est par ici.

Cela ne vous aura pas échappé : l’intelligence artificielle est à la mode. On en parle à la radio, dans les journaux, des députés au style vestimentaire peu commun rédigent des rapports pour le Président de la République… et dans la communauté professionnelle, nous suivons le mouvement : voir par exemple la journée d’études du congrès de l’ADBU 2019 ou encore celle organisée hier à la BnF par l’ADEMEC (vidéos bientôt en ligne). Pourtant, si l’IA était une boîte de gâteaux, on pourrait écrire dessus « L’intelligence artificielle, innovante depuis 1956″…

Pour ma part, le sujet m’est pour ainsi dire tombé dessus, pour la 1e fois, quand on m’a invitée à participer aux Assises numériques du SNE en novembre 2017. Alors que nous préparions notre table-ronde, j’étais un peu dubitative sur ma participation, et j’ai été jusqu’à dire que de mon point de vue, la BnF n’utilisait pas encore en production de technologies d’intelligence artificielle. L’un des autres participants m’a alors dit « mais si ! l’OCR c’est déjà de l’intelligence artificielle ! » Et finalement, même si tout dépend de la définition (plus ou moins précise) que l’on en donne, ce n’est pas faux. Comme le disait Joanna Bryson à Stanford mercredi dernier, l’intelligence c’est la capacité à transformer une perception en action…

A definition of intelligence by @j2blather : the capacity to transform perception into action (finding the right thing to do in the right time) #fantasticfutures2019

— Emmanuelle Bermes (@figoblog) December 4, 2019

Que de chemin parcouru, pour moi, depuis 2017 !

En 2018, les explications de Yann Le Cun ont éclairé ma lanterne sur cette notion d’intelligence, de perception et ce qu’on appelle l’apprentissage (profond ou non, par machine ou pas !) L’exemple du Perceptron, sorte d’ancêtre de l’OCR, m’a permis de comprendre que mon manque supposé de familiarité avec l’intelligence artificielle relevait en fait d’un malentendu. Comme pour beaucoup de gens, l’intelligence artificielle évoquait pour moi une machine s’efforçant d’adopter des comportements plus ou moins proches de l’humain, l’un de ces comportements étant la capacité à « apprendre » comme le suggère le terme de « machine learning ».

Je me suis donc référée à Jean-Gabriel Ganascia pour tenter de désamorcer ces idées reçues et j’ai appris dans son opus daté de 2007 que la discipline informatique connue sous le nom d’ « intelligence artificielle » vise non pas à créer une machine dotée de toutes les facultés intellectuelles de l’humain, mais à reproduire de façon logique et mathématique certaines de ces facultés, de manière ciblée. Il y a autant de différence entre l’intelligence artificielle et l’humain qu’entre passer un OCR sur un texte et le lire…

Pendant que je plongeais dans ces découvertes, l’IA entrait bel et bien à la BnF, par la petite porte, celle de Gallica studio. Un peu plus tard, à la conférence Europeana Tech je (re)découvrais les rouages du prototype GallicaPix et obtenais encore d’autres exemples et explications avant d’en remettre une couche à LIBER 2018 (la répétition est l’essence de la pédagogie, n’est-ce pas…). Enfin, la première conférence Fantastic Futures était organisée en décembre 2018 à Oslo et inscrivait pour de bon l’IA sur notre agenda stratégique, à travers deux projets, l’un portant sur la fouille d’images dans Gallica dans la continuité de GallicaPix et l’autre sur la mise à disposition de collections-données pour les chercheurs dans le cadre du projet Corpus. J’ai même fini par intervenir sur le sujet dans un colloque organisé en octobre par les archives diplomatiques.

Me revoici donc en décembre 2019 à Stanford, prête à plonger dans le grand bain… Qu’ai-je retenu de ces 3 jours de conférence ?

D’une façon générale, cet événement fait apparaître l’idée que le sujet est encore assez jeune dans la communauté des bibliothèques, archives et musées. Alors qu’il existe une conviction solide et partagée que l’IA va transformer en profondeur la société, les méthodes de travail, et avoir un impact significatif sur nos institutions, la mise en pratique reste encore largement expérimentale.

Trois types d’acteurs ont néanmoins proposé une vision concrète, voire des réalisations effectives :

les acteurs de l’industrie, qui font état d’un déploiement déjà très avancé dans différents secteurs,
les acteurs de la recherche, qui multiplient les projets autour de données diverses, notamment celles des collections spécialisées qui se prêtent tout particulièrement à de telles expérimentations
enfin dans le domaine de la création artistique, à travers un artiste qui utilise l’IA dans le cadre d’une démarche d’interrogation sur la société et les rapports humains.

En termes de projets, deux types d’initiatives sont observables dans le domaine de l’IA pour les LAM.

En premier lieu, celles qui visent à mettre des données et collections numériques à disposition des chercheurs à des fins de fouille de texte et de données, en utilisant le machine learning. On peut citer par exemple le Lab de la Bibliothèque du Congrès qui a récemment obtenu un financement de la Mellon pour une expérimentation à grande échelle dans ce domaine. Certains de ces projets conduisent à développer des outils permettant aux chercheurs de s’approprier les modèles d’apprentissage ou des interfaces innovantes comme PixPlot, développé par le laboratoire d’humanités numériques de Yale, qui permet de manipuler des corpus de plusieurs milliers d’images que l’IA regroupe par similarité.

À l’exemple du prototype « Nancy » de la Bibliothèque Nationale de Norvège, d’autres projets visent en revanche l’automatisation de tâches actuellement réalisées manuellement par les bibliothécaires. Toutefois, Nancy reste une initiative expérimentale qui, si elle démontre efficacement les apports potentiels de l’IA pour le traitement des collections, serait très difficile voire impossible à industrialiser telle quelle sur la production courante. De même, les projets de traitement des collections du IA studio de la bibliothèque de Stanford, l’un d’eux portant sur une collection de romans du 19e s. numérisés mais non catalogués, s’attachent au traitement d’un corpus clos et bien défini et sont en réalité hybrides avec la catégorie précédente, car ils mobilisent également des chercheurs au travers de projets ciblés.

Pour finir, je retiendrai un certain nombre de thématiques phares qui sont revenues à plusieurs reprises, aussi bien dans la conférence elle-même que dans les workshops ou la « unconference » :

Les questions éthiques, bien connues en dehors de notre communauté mais abordées ici avec l’idée que des institutions publiques comme les bibliothèques pourraient devenir un acteur important pour porter cet enjeu au regard de l’industrie. L’idée de doter les projets d’un “plan de gestion éthique” comme on a des “plans de gestion des données” a émergé pendant le workshop que je co-animais.
Les enjeux de qualité des données, avec là aussi l’idée que les bibliothèques ont un savoir-faire qu’elles pourraient mobiliser pour apporter à l’industrie des jeux de données de qualité pour l’entraînement du machine learning.
Le développement d’interfaces graphiques, nécessaires pour comprendre les IA, les manipuler et interpréter les résultats (cf. PixPlot ci-dessus)
La formation, avec notamment l’exemple finlandais : l’IA est un enjeu global de société et chacun devrait pouvoir se former pour comprendre ce dont il s’agit. A cette fin, un cours en ligne a été mis en place, visant 1% de la population du pays. Une extension internationale du projet est en cours, avec sa traduction dans les différentes langues de l’Union Européenne.
Enfin les outils, données et modèles, avec un enjeu d’échanges et de mutualisation au sein de la communauté et un focus sur les documents spécialisés (manuscrits, images et cartes notamment, mais aussi son et vidéo). Le lien de ces problématiques avec IIIF a été constamment mis en avant.

Nous nous sommes quittés après 3 jours riches et intenses sur l’annonce de la création de la communauté AI4LAM que j’ai mentionnée plus haut. Et mon petit doigt me dit que mes futurs n’ont pas fini d’être fantastiques… Prochaine étape le 3 février dans le cadre du séminaire DHAI de l’ENS, où Jean-Philippe et moi présenterons les deux initiatives phares de la BnF dans ce domaine.

Reblog : les technos du Web sémantique ont-elles tenu leurs promesses ?

Publié le 07/10/2018 par manuefig

Il y a quelques années, quand j’ai proposé à Gautier et Antoine de publier au Cercle de la librairie une synthèse de ce que nous avions appris en pratiquant avec ces technologies, mon objectif était de stabiliser nos connaissances dans un manuel, afin de les rendre réutilisables. C’est ainsi qu’est né Le web sémantique en bibliothèque, le livre, fin 2013. J’espérais aussi qu’on pourrait arrêter de se répéter en formation et que cela nous aiderait à passer à autre chose…

Je ne pensais pas si bien dire, puisque dès l’année suivante, j’écrivais « qu’il ne serait ni possible, ni utile de former tous les catalogueurs ou tous les bibliothécaires au Web sémantique« . Nous avons poursuivi cette réflexion au fil des conférences et formations, adaptant petit à petit notre discours à un nouveau constat : les technologies du Web sémantique ne répondraient pas à tous nos espoirs, et devaient trouver leur juste place dans le paysage de la donnée d’une manière plus générale. Un constat parfois amer, quand il s’agissait d’y renoncer dans le contexte de la production, parfois plein d’espoir quand les grands acteurs du web les intégraient dans leur stratégie d’interopérabilité.

Gautier revient aujourd’hui sur cette réflexion avec une somme en 4 articles, dont la lecture est indispensable pour qui veut comprendre l’évolution de notre pensée ces 5 dernières années s’agissant de cette technologie que nous avons longtemps mise en avant :

Le Web sémantique nous aide-t-il vraiment à améliorer la visibilité des ressources patrimoniales sur le Web ? Pourquoi le Linked Entreprise Data n’a-t-il pas révolutionné la conception des systèmes d’information ? Dans quels cas l’investissement dans un mapping vers RDF en vaut-il la peine ? Comment peut-on continuer à défendre les modèles orientés entités si on ne veut plus les implémenter en RDF ? Vous trouverez réponse à ces questions et bien plus sur Les Petites Cases.

Vous l’avez compris, je souscris largement aux conclusions qu’il présente et que nous partageons dans notre cadre professionnel, dans les formations que nous assurons ensemble ou chacun de notre côté, et dans notre salon ;-) Mais j’apporterais peut-être quand même pour ma part une nuance ou un complément d’information.

Dans son 2e billet, Gautier revient sur les limites d’OAI-PMH et dans sa conclusion, il remet en cause l’idée de décentralisation en arguant qu’elle est illusoire en l’état actuel de la technologie. L’OAI-PMH, malgré ses faiblesses, est un modèle qui fonctionne bien parce que justement, il procède par recentralisation des données qui ont été moissonnées. Or, la communauté patrimoniale à l’heure actuelle se focalise sur le développement d’un standard qui vise à réaliser la décentralisation des bibliothèques numériques en termes de contenus : IIIF. Dans une démarche caractéristique de la manière dont la communauté appréhendait le Web sémantique il y a 5 ans, IIIF utilise certains éléments de la technologie – les URI, le JSON-LD – sans se réclamer du Web sémantique ou du Linked Data. Pour Gautier, le choix de JSON-LD est anecdotique et relève d’un espoir qu’on avait à l’époque : que ce genre de détail ferait « cheval de Troie » pour installer la technologie. Pour moi, il témoigne d’une forme de maturité qui replace les briques de la techno à leur juste place dans un ensemble plus large. Néanmoins, le problème est toujours le même : pour exploiter les données, même avec IIIF, il faut rencentraliser les métadonnées. Et pour les recentraliser, il faut qu’elles soient homogènes ce qui exige soit de se mettre d’accord sur une syntaxe commune quelle qu’elle soit, soit de faire des conversions ou mappings…

En fin de compte, ce détail montre que la communauté patrimoniale est encore en train de réfléchir à son modèle d’agrégation des données. L’interopérabilité reste le principal (l’unique ?) cas d’usage du Web sémantique, et les portails ont encore de beaux jours devant eux. Nous garderons donc un œil attentif dans cette direction…

Communautés et institutions : la cohabitation impossible ?

Publié le 27/10/2016 par manuefig

J’ai eu souvent affaire à cette question ces derniers temps, que ce soit dans le contexte de l’association Europeana, d’IIPC ou encore des projets collaboratifs de la BnF : comment faire cohabiter harmonieusement les modes de fonctionnement radicalement différents d’une institution et d’une communauté ?

Les institutions ont plusieurs atouts dans leur manche. Elles sont organisées, pérennes et souvent dotées de ressources telles que des moyens financiers ou logistiques. Wikipédia ne pourrait pas exister s’il n’y avait pas quelqu’un qui faisait tourner les serveurs et lançait les campagnes annuelles de collecte de dons. Bien sûr, Wikipédia n’existerait pas non plus s’il n’y avait la communauté pour créer, organiser, surveiller et améliorer les contenus. Le succès de l’entreprise repose sur la bonne entente des deux colocataires, qui se répartissent harmonieusement les tâches ménagères (les anglo-saxons utilisent d’ailleurs le terme de « housekeeping » pour désigner les affaires administratives). Pourtant la lourdeur des institutions, avec les règles parfois rigides dont elles sont obligées de se doter pour fonctionner, peut avoir pour conséquence un désintérêt, une désaffection voire franchement une défiance de la part des communautés.
Face à ce problème, on peut avoir rapidement l’impression d’essayer de réconcilier deux colocataires qui doivent vivre dans le même appartement alors que l’un est maniaque et psychorigide et l’autre joyeux et bordélique. Au départ, sur le papier, on a l’impression qu’ils sont faits pour s’entendre : l’un des deux apportera la bonne ambiance, les fêtes et la bonne bouffe, l’autre se chargera du ménage le lendemain et de la bonne tenue du foyer. Sauf que rapidement la colocation vire au cauchemar, chacun ayant l’impression de donner plus qu’il ne retire de bénéfices dans l’opération.

De façon assez intéressante, j’ai dernièrement eu l’occasion de regarder le problème sous les deux angles, à travers mon expérience dans Europeana et dans IIPC.
Côté Europeana, on observe un équilibre (ou une tension, ce qui revient au même) intéressant entre l’institution, représentée par la Fondation qui met en œuvre le portail Europeana Collections, et l’Association, qui est censée représenter les intérêts de la communauté. Lequel des deux est le plus important ? Qu’est-ce qui apporte plus de valeur au citoyen européen, entre un portail donnant accès à cinquante millions de ressources numérisées et une plateforme destinée à dynamiser un réseau de professionnels ? Le produit ou la communauté ? J’ai déjà donné mon avis sur la question…
Côté IIPC, le consortium qui a atteint l’âge vénérable de 12 ans doit aujourd’hui passer d’un modèle institutionnel (consistant à définir des projets puis les financer et les piloter) à un modèle de communauté où les projets émergent d’eux-mêmes et pour lesquels il agit comme un facilitateur. Ce changement de logique est compliqué à opérer, mais essentiel pour sa survie et sa croissance.
Enfin, ma récente visite à la British Library, avec la présentation des communautés qu’ils animent comme le Knowledge Quarter ou le Digital scholarship avec son Labs, m’a permis de mieux comprendre les différences entre la logique institutionnelle, qui repose sur la mise en œuvre de projets ou de produits, et celle qui anime les communautés. Il s’agit vraiment de deux façons complètement différentes d’aborder un sujet ; elles ne sont pas forcément incompatibles mais reposent à plusieurs égards sur des logiques opposées.

Le point de départ : think big
La communauté se caractérise par un concept de départ autour duquel il y a une compréhension partagée du problème qu’on cherche à résoudre. Des concepts comme « open innovation », « digital scholarship » ou « knowledge quarter » en sont de bons exemples. Une fois qu’on a réussi à mettre tout le monde d’accord sur le mot à utiliser qui va guider la communauté et faire converger les énergies, le reste suit.
Côté projet, on ne part pas d’un concept mais d’un programme, d’un résultat attendu ou livrable. On définit ce qu’on veut construire, puis on met en place le programme qui permet d’y arriver. Les dix minutes passées à choisir un acronyme imbitable qui deviendra la marque du projet pour le meilleur et pour le pire sont rarement une priorité.
Le « programme » qui sert de point de départ au projet est orienté résultat, alors que le concept qui permet de fonder la communauté est centré sur une compréhension partagée du problème (indépendamment des solutions qu’on peut lui apporter).

Les ressources : fund raising vs. call for proposals
Communautés et projets recourent à des méthodes très différentes pour réunir du financement.
Parce qu’elles reposent sur des concepts partagés et puissants, les communautés ont la capacité d’inciter leurs contributeurs à contribuer à la hauteur des moyens dont ils disposent (ou qu’ils souhaitent apporter), qu’il s’agisse d’argent, de moyens en nature (lieux, fournitures, etc.) ou de compétences. Les moyens apportés peuvent être très petits mais innombrables (cas de Wikipédia aussi bien dans la levée de fonds – crowdfunding – que dans la production de contenus – crowdsourcing) ou ponctuels mais énormes (cas du mécénat apporté par de grosses fondations ou entreprises américaines). Ils sont dans tous les cas difficilement prévisibles à l’avance et obligent la communauté à adapter ses actions aux moyens disponibles, en croissance aussi bien qu’en décroissance suivant la conjoncture.
Côté institutions et projets, le modèle qui prévaut est la subvention : on commence par évaluer combien coûte ce qu’on veut fabriquer, on se partage le gâteau entre partenaires en fonction de l’effort que chacun peut mettre et on va voir un tiers pour obtenir la somme. Ce tiers peut être un pouvoir public (tutelle, agence comme l’ANR…) mais ce modèle est aussi très souvent utilisé par les institutions dans leur recherche de mécénat.

Les méthodes de travail : start small, fail often
Cette différence dans la manière de financer leurs activités a bien sûr un impact sur ce que communautés et projets sont capables de produire et la méthode employée pour ce faire. Là où le projet s’impose dès le départ un résultat à atteindre et un calendrier, la communauté préfère lancer une multitude de petits projets, dont certains échoueront, mais ce n’est pas grave. On est dans la logique de l’essai-erreur, le principe étant de concrétiser aussi vite que possible les idées pour pouvoir se débarrasser rapidement de ce qui ne fonctionne pas et laisser grossir les « best-sellers », presque naturellement emportés par leur succès.

Les dépenses : hacking & yacking
De façon tout à fait logique, les communautés ne dépensent pas non plus leur argent de la même manière que les institutions. Se vivant comme des facilitateurs, elles vont consacrer une part significative de leurs ressources à permettre aux êtres humains qui constituent les communautés de travailler ensemble. Et que font les êtres humains ? Ils mangent, boivent, se rencontrent et communiquent. Rien d’étonnant, donc, que dans une communauté les dépenses soient souvent orientées vers des frais de déplacement, de bouche, de communication ou de logistique. Et s’il y a des emplois à financer, ils seront le plus souvent tournés vers ce type d’activité (planification d’événements, etc.). Le reste, la ressource qui produit réellement du travail, est en fait apportée par la communauté. L’exemple typique c’est le hackathon : l’institution ou l’organisateur fournit un lieu sympa, du café à volonté et des pizzas (yacking), la communauté fournit des idées, de la force de travail et des compétences (hacking).
Vu depuis une logique de projet, l’équilibre financier d’une communauté est une aberration. Un projet va en général consacrer 10 à 20% de son budget à sa propre gestion et communication. Le reste sert à financier des emplois, des équipements, du matériel, bref à acquérir ce que la communauté génère par synergie mais sans garantie de résultat. Si on veut des résultats garantis, il faut aussi garantir les moyens. Cela semble logique, en tout cas vu depuis l’institution…

La mesure du succès : empower & engage
La communauté se considère comme un facilitateur : son objectif principal est d’impliquer (to engage) ses membres et de leur donner des moyens (to empower) pour créer les conditions de la concrétisation de leurs propres idées. L’institution, elle, s’approprie les résultats du projet ou le produit, pas forcément au sens de la propriété intellectuelle mais au moins en tant qu’autorité productrice de ces résultats, généralement mesurables au moyen d’indicateurs. L’approche projet donne donc en apparence un retour sur investissement plus concret. Le résultat est un produit visible, tangible, dont l’institution peut revendiquer la paternité. Pour autant, ce produit sera-t-il suffisamment évolutif, maintenable, et tout simplement réussi ? La communauté de ses utilisateurs sera finalement seul juge.
Quand on cherche à mesurer les résultats de la communauté, on peut avoir l’impression d’une situation contrastée, entre quelques grandes réussites fulgurantes d’une part et une multitude d’initiatives dispersées et pas forcément très pérennes d’autre part. De plus, il n’est pas toujours évident de mesurer la part que la communauté a joué dans le succès d’un projet né en son sein.
Au final, les communautés et les projets ont des moyens très différents de mesurer leur succès. L’objectif premier du projet est de réussir, c’est à dire de livrer des résultats qui correspondent à ce qui était annoncé au départ. Les communautés, elles, cherchent à grossir, à engager de plus en plus de gens, sans poser de limites ou d’objectifs.

Finalement, les communautés sont-elles utiles ?
Si vous vous posez cette question, c’est que vous n’avez probablement pas (encore) intégré le mode de pensée qui sous-tend les communautés. Les communautés sont comme les fées : elles n’existent que par et pour ceux qui y croient. Je n’irais pas jusqu’à dire qu’il suffit de taper dans ses mains, mais l’idée est là : parce que leur but premier est de réunir des gens qui partagent les mêmes valeurs et les mêmes buts et sont prêts à y consacrer des ressources (du temps, des moyens, de l’énergie), les communautés n’ont pas besoin de prouver leur utilité pour exister. Le seul fait qu’elles existent crée de la valeur, une valeur parfois difficilement mesurable et observable de l’extérieur mais clairement ressentie par ses membres, qui perçoivent l’apport de la communauté à leur réussite, même si cet apport est difficile à quantifier ou à retracer de manière directe. Cette valeur se réalise parfois de façon concrète dans des ressources partagées qu’on appelle les communs.

Dans leur livre L’âge de la multitude, N. Colin et H. Verdier qualifient la multitude (ce que j’ai appelé ici les communautés, car à mon avis la multitude n’est pas une réalité unique mais plurielle) d’ « externalité positive » : quelque chose qui est en dehors du projet ou du produit, mais contribue à créer de la valeur qui joue en faveur de sa réussite de manière plus ou moins mesurable. Pour eux, le principal enjeu de la transition numérique, pour les organisations, institutions ou entreprises, est d’entrer en synergie avec la multitude. Pour cela, les institutions doivent devenir des plateformes principalement dédiées à permettre à la multitude de s’en emparer et ainsi déployer sa créativité.
Ce modèle qui a fait le succès des Uber, Amazon, Facebook et autres Twitter implique, pour des institutions comme les bibliothèques, de lâcher prise sur un certain nombre choses : les projets et les produits, les indicateurs de performance, la propriété de ce qu’elles créent. Il suppose de se définir comme une plateforme et donc se recentrer sur le service qu’on offre aux communautés, leur permettant d’exprimer leur créativité ; de se poser en facilitateur d’une expérience plutôt qu’en fournisseur d’un produit (en l’occurrence la collection) ; de concevoir ses propres objectifs en mineure et ceux de ses usagers en majeure. C’est ce que les bibliothèques ont commencé à faire avec la notion de « troisième lieu ».

Parce que toute réflexion de fond sur les bibliothèques ramène toujours à cet ouvrage indispensable qu’est La sagesse du bibliothécaire, je vais conclure en reprenant la citation de Michel Melot retenue par Mathilde Servet dans son article : « Pour atteindre son seuil critique, il faut que la bibliothèque ait de nombreux lecteurs et bien d’autres usages que la simple lecture. La bibliothèque n’existe que par la communauté […] [Le bibliothécaire] ne parle pas pour lui-même mais pour la communauté qu’il sert. Il doit en refléter les goûts et les opinions, mais aussi les ouvrir à d’autres. Son choix doit être celui de la pluralité […], cette “bigarrure” qui caractérise les sociétés libres. »

IIPC 2016 – how to collaborate ?

Publié le 25/04/2016 par manuefig

Il y a deux semaines, j’avais le privilège de partir pour une semaine en Islande à l’occasion de la rencontre annuelle du consortium IIPC pour la préservation de l’Internet : d’abord l’assemblée générale, puis conférence WAC (Web Archiving Conference) et enfin la réunion du Steering Committee, instance de gouvernance du consortium. Ce dernier, constitué de 15 membres issus pour la plupart de bibliothèques nationales, m’a fait la confiance de me confier la présidence du consortium pour un an.

And now it’s official. Emmanuelle Bermès @figoblog from @ActuBnF is the new IIPC Chair! #iipcga2016, #iipcwac2016. pic.twitter.com/gc6qvq5ioB

— IIPC (@NetPreserve) 14 avril 2016

Beaucoup d’entre vous m’ont félicitée sur les réseaux sociaux, ce dont je vous remercie, mais je ne suis pas sûre que tout le monde sache exactement de quoi il retourne, donc j’ai décidé de revenir ici sur le consortium IIPC et ce rôle de présidente.

Le consortium a été fondé il y a 13 ans par un petit groupe de bibliothèques nationales conjointement avec Internet Archive, fondation américaine à but non lucratif qui s’était donné l’objectif d’archiver le web dès le milieu des années 1990 et était pratiquement la seule organisation, à cette époque, disposant de l’infrastructure matérielle et logicielle permettant d’accomplir une tâche aussi dantesque à grande échelle.

IIPC avait alors pour but de créer des outils communs, de susciter l’émergence d’une communauté et d’alerter sur l’importance de l’archivage du web, afin que se mette en place une dynamique internationale qui assurerait la mémoire du web que nous connaissons.

Le propos introductif de Marc Weber, directeur du Computer History Museum, du colloque Time and temporalities of the Web, en fin d’année 2015, m’a fait réaliser que parmi les nombreux réseaux qui ont existé avant que le web ne finisse par s’imposer, comme Arpanet ou le Minitel par exemple, fort peu ont fait l’objet d’un effort de préservation ; en fait, seuls en ont bénéficié ceux dont les créateurs avaient conscience d’une perte de mémoire potentielle et se sont mobilisés pour sauvegarder leur propre objet.

Le travail d’Internet Archive dès 1996 puis l’investissement des bibliothèques nationales, qui ont cherché à se doter non seulement d’outils mais aussi d’un cadre juridique s’appuyant sur le dépôt légal et de procédures métier héritées de leur tradition professionnelle, ont doté le web d’une mémoire qui a en outre la qualité de ne pas être trop biaisée d’un point de vue historique, en tout cas moins que si elle avait été documentée uniquement par les créateurs du web eux-mêmes.

Avec la fondation d’IIPC, les bibliothèques nationales apportaient à la communauté de l’archivage du web un autre atout : leur capacité à organiser des processus de couverture documentaire au niveau international, comme elles l’avaient fait autrefois avec le contrôle bibliographique universel.

Aujourd’hui le consortium IIPC ce sont 50 membres venus de nombreuses régions du globe et dont le profil ne se limite plus aux bibliothèques nationales : des bibliothèques universitaires, des acteurs majeurs dans le domaine de l’audiovisuel ou encore des acteurs privés se préoccupent aujourd’hui de cette question. La conférence annuelle s’ouvre également, de façon de plus en plus prégnante, à des universitaires issus de différentes disciplines, pour lesquels les archives du web sont un objet d’étude et une source de premier plan.

Dans ce contexte, le consortium semble à présent traverser une deuxième crise de croissance (la première ayant eu lieu au moment où le consortium élargissait sa base de 12 membres fondateurs : pour en savoir plus sur l’histoire d’IIPC jusqu’en 2010, lire l’article de Gildas Illien dans le BBF). Ainsi les différentes sessions de l’assemblée générale et de la conférence, sans qu’un thème particulier leur ait été attribué, ont naturellement convergé vers une question récurrente : « how to collaborate » ? Tout le monde s’accordant à reconnaître que la collaboration était aujourd’hui un enjeu majeur et une aspiration généralisée, mais que le « comment » devenait compliqué à définir avec l’élargissement de la communauté, la multiplication de ses centres d’intérêt et de fait, parfois, des divergences de vues. Pour autant, les propositions de collaboration ont été foisonnantes et ont pris de nombreuses formes différentes :

Le panorama : avec plus de 50 institutions et 150 individus autour de la table, un des premiers enjeux réside dans le fait de savoir sur quels projets travaillent les uns et les autres afin de faire émerger des synergies potentielles. Harvard a réalisé récemment un « Web archiving environmental scan » : un travail de 5 mois pour explorer les pratiques de 23 institutions et en tirer 22 opportunités de travaux à conduire. L’idée qu’IIPC puisse être un forum pour mettre régulièrement à jour ce type de rapport et ainsi mieux communiquer sur les pratiques de ses membres a été émise.

Le développement open source : celui-ci reste au cœur des pratiques traditionnelles d’IIPC, et on perçoit aujourd’hui encore des attentes importantes à l’égard des outils majeurs comme le crawler Héritrix (robot qui moissonne les pages web) ou l’open wayback (outil d’accès aux archives web), perçus comme insuffisamment documentés et stabilisés.

Les API : les « gros » outils mentionnés ci-dessus, bien qu’utilisés très largement, sont perçus comme monolithiques et peu évolutifs au regard d’un web qui tend à se modifier techniquement plus rapidement qu’eux. Ainsi la collecte des réseaux sociaux ou encore des plateformes de vidéo sont aujourd’hui des challenges auxquels tout un chacun est confronté. L’idée de travailler sur une chaîne d’outils plus modulaire, souple et évolutive, dont les différentes briques seraient liées entre elles par des API avait déjà été soulevée par Tom Cramer l’année dernière. Mais elle s’est encore renforcée et précisée cette année.

Les normes et standards : fortement liés aux outils, les standards comme le format WARC et ses différents dérivés continuent à jouer un rôle important. L’effort de normalisation requiert la construction d’un consensus et fait donc partie des attentes à l’égard d’IIPC.

Les hackathons : L’exemple d’Archives Unleashed, présenté par Ian Milligan et Matthew Weber, a montré l’importance d’organiser des temps forts d’expérimentation réunissant développeurs, archivistes et chercheurs de toutes disciplines, non seulement pour faire émerger de nouvelles idées et projets de recherche, mais aussi pour mieux comprendre ce matériau particulier que sont les archives web et adapter les outils.

L’étude des usages : l’approche orientée utilisateurs n’est pas une nouveauté au sein de la communauté IIPC qui avait déjà rassemblé des use cases (une première fois en 2006 puis à nouveau en 2013). On a vu cependant émerger de nouvelles méthodes plus orientées études d’usage, comme l’utilisation de « personas » par les archives gouvernementales britanniques.

Les collections collaboratives : là aussi il y a un existant côté IIPC, avec les collections collaboratives qui se sont mises en place d’abord autour des jeux olympiques puis d’autres sujets (la grande guerre, la crise des migrants en Europe…) en utilisant depuis l’an dernier le service Archive It. On a vu cependant émerger d’autres propositions de modèles collaboratifs autour de la collecte, comme le projet Cobweb dont l’objectif est de mettre en commun les ressources de sélection et de collecte à travers un répertoire qui permettrait à chacun de proposer des collections à archiver et à différentes institutions de déclarer leurs collectes.

Le cloud : Brewster Khale, dans sa présentation de la « bibliothèque nationale d’Atlantis » (celle dont le logo est un mermaid cat), va plus loin et renoue avec le vieux rêve d’une grande archive internationale collaborative et reliée, en s’appuyant sur l’idée du cloud : une mutualisation des infrastructures, des ressources et des outils, permettant néanmoins à chaque bibliothèque nationale d’affirmer sa propre identité. On est très proche ici des idées que je présentais récemment au sujet des bibliothèques numériques. Brewster note aussi la difficulté croissante à démêler le web des autres ressources qui intéressent les bibliothèques (livres, revues, audiovisuel…), devenues elles aussi numériques et circulant sur le web, ce qui va nous obliger à penser des interfaces qui ne séparent plus le web du reste de la bibliothèque.

Et mon rôle de présidente, dans tout ça ? Le renouvellement de l’accord de consortium début 2016 a été l’occasion de remettre sur la table la question de la stratégie d’IIPC et ses ambitions, ainsi que de revoir sa gouvernance : ont ainsi été créés trois « portefeuilles » (« portfolios »), trois thématiques qui permettent d’appréhender le consortium sous trois angles différents : le développement des outils, l’engagement des membres et la recherche de nouveaux partenariats.

Ce changement amené par le précédent président, Paul Wagner de Bibliothèques et Archives Canada, pouvait paraître couler de source mais il a été reconnu par certains des membres les plus anciens du steering committee comme une étape essentielle, et avec raison. Il apporte en effet deux éléments qui seront sans doute clefs pour le développement d’IIPC à l’avenir : d’une part une gouvernance plus engagée, d’autre part une lisibilité de la stratégie qui devrait lui permettre de passer cette nouvelle étape de croissance, c’est-à-dire de cesser d’être un groupe ou un club exclusif réservé à quelques experts pour devenir une communauté, dans toute sa richesse et sa diversité.

Prenant le relais de Paul au 1er juin 2016, mon rôle sera d’accompagner cette nouvelle organisation et de l’installer dans le fonctionnement quotidien du consortium et en particulier du Steering Committee, avec pour ambition de transformer les idées en actions concrètes, même si celles-ci ont dans un premier temps une ambition limitée.

Sur ce je vous laisse, j’ai un « strategic plan » à rédiger ;-)

IIPC GA 2015, jour 2 : WARC, WAT, WET et WANE

Publié le 01/05/2015 par manuefig

Si vous venez à la BnF consulter les archives du Web ou que vous utilisez en ligne la Wayback Machine d’Internet Archive, vous pourrez parcourir le Web du passé en le « rejouant » sous la forme de pages qui ressemblent, parfois beaucoup, parfois vaguement à ce qu’elles étaient à l’époque où elles faisaient partie du « Web vivant » comme on l’appelle ici. Vous pouvez, par exemple, regarder à quoi ressemblait le Figoblog en 2005 : sympa pour les nostalgiques ! Cependant, il arrive parfois qu’il manque des bouts (par exemple à cette période la feuille de style CSS n’a manifestement pas été récupérée) ou que le site n’ait simplement pas été aspiré (ou « crawlé » pour employer le terme consacré) à une date précise. Par ailleurs, l’accès aux archives Web mobilise de plus en plus des usages qui n’impliquent pas d’accéder aux pages elles-mêmes en les rejouant, mais aux données qu’elles contiennent, voire aux données contextuelles que sont les informations de formats, de dates, de modalité de collecte, etc.

Le 2e jour de la conférence ouverte d’IIPC, consacré à des ateliers, est entré davantage dans la technique quant aux modalités d’exploitation de ces archives. Il a été notamment question de formats et de protocoles qui permettent différentes modalités d’accès.

La journée s’est ouverte sur une présentation par Herbert Van de Sompel du projet Memento. Memento fournit un protocole pour accéder à distance à différentes archives Web et donc retrouver, à partir d’une URL et d’une date, la version la plus pertinente dans différentes archives disponibles. On crée ainsi de l’interopérabilité entre archives Web, avec pour perspective d’étendre à l’avenir le projet aux « dark archives », c’est à dire les archives qui ne sont pas librement accessibles en ligne mais dont les métadonnées pourraient être signalées.

Ce principe est illustré dans le service Time travel qui s’est également doté récemment d’un mécanisme de reconstruction permettant de récupérer dans différentes archives les « bouts » qui constituent une même page Web afin de la reconstituer au plus proche. Par exemple, si une archive a préservé le contenu d’une page et une autre sa CSS, on arrivera à afficher la page correctement mise en forme.

Memento a aussi développé Robustlinks, un outil permettant notamment aux auteurs d’articles d’associer leurs publications à une archive et à des métadonnées en Schema.org de façon à assurer qu’elles restent accessibles à travers le temps. Le projet Hiberlink étudie l’impact de tels mécanismes sur les publications scientifiques.

Je ne passerai pas en revue une à une les autres interventions de cette journée, je vais plutôt les synthétiser en évoquant les différents formats qui permettent d’archiver le Web et d’exploiter ces archives de différentes manières.

Le premier de ces formats, c’est WARC : un conteneur qui permet de stocker les fichiers archivés avec un certain nombre de métadonnées, dont les informations liées à la collecte (date, etc.). Ce format normalisé à l’ISO va être révisé cette année. Le problème avec WARC, c’est que c’est un format assez lourd à stocker et manipuler. Un certain nombre de développements ont été imaginés pour l’alléger, notamment un mécanisme de dédoublonnage qui évite de stocker plusieurs fois le même fichier s’il n’a pas changé depuis le dernier crawl.

On a besoin des WARC si on veut accéder au contenu. Mais si on s’intéresse aux données (ou aux métadonnées) on peut faire appel à des formats plus légers qui ont été développés à cette fin.

Les WAT contiennent les métadonnées de chaque fichier, les informations concernant la collecte et d’autres éléments comme la liste des liens présents dans les pages HTML. Ces informations sont stockées en JSON ce qui permet de les exploiter facilement pour faire toutes sortes de statistiques. On a en général 1 fichier WAT pour 1 fichier WARC et chaque fichier WAT représente environ 15 à 20% de la taille du WARC auquel il correspond. Il existe également une variante nommée WET qui contient tous les éléments textuels d’un WARC.

Les LGA (Longitudinal Graph Analysis) contiennent la cartographie complète des liens à l’intérieur d’une archive Web. Ils permettent de générer des visualisations de données. Le fichier LGA ne représente qu’1% du poids de toute la collection de WARC qu’il cartographie.

Enfin une mention spéciale pour les WANE : il s’agit de stocker les entités nommées contenues dans les pages web, sur le même principe que les WAT (1 fichier WANE pour 1 fichier WARC). Le fichier WANE représente moins d’1% de son WARC.

Si vous lisez ce billet et que vous ne savez pas ce que sont les entités nommées, je vous conseille de vous arrêter un instant et de plonger dans cette notion. Il devient en effet de plus en plus fréquent d’entendre parler d’entités nommées au détour de réunions où de conférences, y compris en présence d’acteurs pas du tout techniques, ce qui laisse à penser que cette notion est aujourd’hui considérée comme acquise pour des bibliothécaires. Pourtant, lors de mon dernier cours donné à des documentalistes en master 2, j’ai pu constater que la plupart d’entre eux ne savaient pas ce que c’était, voire n’en avaient jamais entendu parler.

Ce terme désigne dans un texte les entités qu’on est capable d’identifier, de qualifier en vue de les relier à d’autres informations : des personnes, des lieux, des organisations, des dates ou périodes, des événements, des concepts, etc. Si on reprend les archives du Web, imaginons qu’on a collecté la page d’accueil du site du Monde le 4 novembre 2008, on pourra sans doute identifier la personne « Barack Obama » et le lieu « États-Unis ».

La plupart des initiatives visant à reconnaître les entités nommées qui ont été présentées dans les différentes conférences de l’assemblée IIPC s’appuyaient sur le logiciel de reconnaissance d’entités nommées de Stanford: Stanford NER. Le principe de ce type de logiciel de reconnaissance d’entités nommées est de définir des règles qui permettent, pour une langue donnée, de les reconnaître (par exemple, si une séquence commence par « Monsieur » on peut supposer que ce qui suit est un nom de personne). Ces règles sont affinées ou enrichies par des mécanismes d’apprentissage (machine learning) : on « apprend » à la machine à reconnaître les entités nommées en le faisant manuellement sur un corpus de référence et ensuite, elle se débrouillera toute seule sur des documents similaires.

Lors d’une présentation qui a eu lieu un peu plus tard (jour 4, désolée d’anticiper) mes collègues de la BnF ont présentées les recherches actuellement réalisées par une ingénieure du labex « les passés dans le présent », qui utilise les WAT pour analyser les relations entre les sites Internet qui traitent de la Grande Guerre.

L’intervention de l’historien canadien Ian Milligan fourmillait d’autres exemples d’application de ces différentes techniques pour le champ de la recherche en histoire depuis les années 1990. Pour Ian, il est impossible de faire de l’histoire récente sans utiliser les archives du Web : on passerait à côté de son sujet en évacuant cette source primordiale. Il va jusqu’à proclamer que les archives du Web vont profondément transformer le travail des historiens et l’histoire sociale.

Seul problème : les compétences. En effet, peu nombreux sont les historiens capables de manipuler ce genre d’outils. Si toutefois vous voulez vous lancer, le tutoriel est par ici ;-)

IIPC GA 2015, jour 1 : « context matters »

Publié le 28/04/2015 par manuefig

La dernière fois que j’ai assisté à une rencontre d’IIPC, le consortium pour l’archivage de l’Internet, c’était en 2009 à San Francisco. Par une sorte de coup du sort, je me retrouve aujourd’hui de nouveau en Californie, cette fois à Stanford, pour assister à l’assemblée générale 2015 du consortium qui a bien grandi (pour suivre l’événement sur Twitter, c’est #iipcga15).

C’est assez amusant de voir que certaines des choses que j’écrivais à l’époque sont toujours – et plus que jamais – d’actualité, même si le sujet de l’archivage du Web semble avoir subi entre temps une petite révolution copernicienne puisque, lors de cette journée d’ouverture, on a moins parlé d’archivage que d’usage. En fait j’en ai retenu principalement deux choses :

d’une part, que « le contexte c’est important » (pour citer Paul Wagner, actuel président du steering committee d’IIPC) – vous me direz, pour des archives, c’est quasiment un truisme ;
d’autre part, que si on n’arrive pas à les rendre utilisables, cela ne sert pas à grand chose de les conserver.

Dès la conférence d’ouverture, pour laquelle nous avions l’honneur d’accueillir Vinton Cerf (vous savez, celui qui n’a pas inventé le Web) en compagnie de Mahadev Satyanarayanan (alias Satya, de Carnegie Mellon University), la question posée était celle de la facilité d’accès ou même de l’expérience utilisateur dans le domaine de l’archivage de l’Internet. En effet, après que V. Cerf ait introduit l’enjeu de la préservation des contenus dynamiques et en particulier exécutables (genre des logiciels ou des data contenues dans des logiciels), Satya a présenté le projet Olive qui vise à rendre l’expérience d’une machine virtuelle aussi fluide qu’un streaming sur Youtube.

Toute personne qui a un jour essayé de lancer une machine virtuelle (par exemple, pour faire tourner un OS Windows sous Linux et ainsi essayer de sauver un vieux powerpoint dont vous voulez absolument récupérer les 52 diapos animées sans avoir besoin de les retaper…) ne peut qu’être saisie d’émerveillement devant la mécanique présentée par Satya, qui permet, en quelques secondes, de faire revivre successivement une vieille version de Windows, le jeu Oregon Trail pour Mac (1990) ou encore d’accéder au Web d’aujourd’hui avec un navigateur Mosaïc 1.0.

Cependant, si on veut utiliser ce genre de méthode pour préserver des sites Web ou même des contenus exécutables, quels qu’ils soient, tels qu’on les connaît aujourd’hui, la question du contexte se pose rapidement : quelle quantité de Web va-t-il falloir « aspirer » pour disposer de tout le contenu nécessaire pour rendre ces objets utilisables de manière similaire à ce qu’ils étaient à l’origine ? Et je ne vous parle même pas de la question de l’Internet des objets, certains objets connectés étant difficiles, voire impossibles à émuler sur une machine virtuelle en raison de leur matérialité.

La question des usages de ces archives de l’Internet et en particulier, des outils nécessaires pour les utiliser est restée centrale pendant toute la journée.

Les exemples danois et anglais ont permis de voir comment les archives du Web peuvent être utilisées pour analyser le domaine Web national d’un pays : taille, format, contenus, etc.

La première session de l’après-midi posait la question de l’archivage de données très personnelles telles que les profils Facebook ou les photos et vidéos de famille, mais du point de vue des individus eux-mêmes. On a ainsi appris que beaucoup de gens ne se soucient guère de voir leur mur Facebook préservé, voire s’y opposent carrément parce qu’ils le font constamment évoluer, de façon à ce qu’il reflète leur perception de leur identité à un instant T. Et pour les plus jeunes, il semblerait qu’ils soient persuadés que de toute façon, tous ces contenus publiés sont conservés automatiquement par quelqu’un quelque part…

D’une façon générale, la préservation des archives familiales semble avoir été profondément bouleversée, voire parfois remise en cause, par l’irruption du numérique parce que dans une famille, celui qui a le rôle de l’archiviste n’est pas forcément celui qui maîtrise l’informatique domestique (c’est là que je me suis félicitée d’avoir à la maison un geek qui s’est pas mal intéressé à la préservation numérique :-D). C’est que créer des contenus est perçu comme plus gratifiant que de passer du temps à les gérer et les organiser…une vérité qui ne me semble pas non plus totalement étrangère à la problématique de la gestion des collections numériques dans les bibliothèques.

Enfin la journée s’est terminée avec la présentation du projet BUDDAH : Big UK Domain Data for the Arts and Humanities, autour des archives Web de la British Library. Ce projet vise à promouvoir l’usage des archives du Web comme matériau pour la recherche, à travers diverses initiatives comme ces vidéos de présentation. Le projet a aussi débouché sur un prototype permettant une recherche à facettes dans l’ensemble des 160 téraoctets d’archives de la British Library : Shine. Shine propose aussi un outil de recherche de tendances, qui permet de comparer l’évolution des occurrences d’un mots dans les archives du Web sous la forme d’un graphique.

C’est là que revient la question du contexte, avec plus d’acuité que jamais. L’un des enjeux majeurs pour que les chercheurs puissent aujourd’hui exploiter de façon satisfaisante les archives du Web est la construction de corpus documentés. On a en effet besoin de savoir comment l’archive a été constituée, voire de la manipuler et de définir des sous-ensembles avant de commencer à en analyser le contenu, faute de quoi on risque de se retrouver avec des résultats biaisés. Ces projets démontrent aussi la pertinence d’une approche de type « big data » : beaucoup des résultats qui nous ont été présentés exploitaient les archives Web sans jamais aller jusqu’à la consultation des pages, en fouillant simplement les données, les métadonnées associées aux objets et aux collectes. Cela implique bien sûr des compétences tout à fait spécifiques pour ces historiens du Web, telles que l’exploitation de données quantitatives et leur visualisation graphique.

Pour conclure, la communauté IIPC semble aujourd’hui préoccupée de rendre les collections qu’elle a pu créer depuis plusieurs années immédiatement utilisables par des chercheurs d’aujourd’hui, qu’il s’agisse d’inventer des outils ou de documenter le contexte de ces archives. Cet enjeu apparaît quasiment comme une question de survie : il y a urgence à démontrer l’intérêt et l’utilité de ces collections. Les web-archivistes sont extrêmement attachés à démontrer l’importance de leur travail, qui pourtant ne fait pas de doute quand on voit qu’en deux ans, 60% des contenus Web du domaine .uk ont disparu, été déplacés ou modifiés :

And last cool chart from @anjacks0n – changing content in the UK Web Archive, 2004-2014. Inspirational. #iipcGA15 pic.twitter.com/8wwVAVO1No

— Ian Milligan (@ianmilligan1) April 27, 2015

De façon assez ironique, l’un des meilleurs moyens de légitimer l’usage des archives du Web aujourd’hui semble être d’inviter des chercheurs à écrire un livre sur le sujet. Numérique, bien sûr, et accessible… sur le Web !

Pourquoi j’ai accepté de sacrifier mes URL

Publié le 06/01/2015 par manuefig

Suite au déménagement du Figoblog, certaines personnes ont été émues par ma décision de ne pas assurer la continuité de service sur les URL des billets. En effet, comment peut-on consacrer tant d’énergie à défendre la cause des identifiants pérennes et se retrouver au final, tel le cordonnier, si mal chaussé ? Quelques explications s’imposent.

D’abord, un mot sur la cause technique. Comme je l’indiquais dans mon précédent billet, le Figoblog tourne maintenant sur une plateforme hébergée, à savoir WordPress.com. Si Got avait eu la main sur le serveur, il aurait pu mettre en place une réécriture d’URL : mes adresses en « /node/[identifiant-du-billet] » étaient en effet suffisamment simples pour que cela puisse fonctionner et l’identifiant a bien été récupéré dans les métadonnées du billet lors de la migration. Mais c’est ça, le problème du SAAS : on n’a pas toutes les fonctionnalités qu’on veut.

Ceci posé, comment aurais-je pu faire pour éviter ce drame, ce génocide, la mort de plus de 600 pauvres petites URL qui n’avaient fait de mal à personne ?

Pour commencer, j’aurais pu choisir une autre plateforme offrant cette fonctionnalité. Il aurait alors fallu que je fasse un critère de priorité de cette fonction, critère qui se serait trouvé prépondérant par rapport aux autres intérêts de WordPress.com (notoriété, gratuité, simplicité d’utilisation, etc.) bon, ce n’est pas le choix que j’ai fait ; il me semblait que les avantages de l’utilisation de cette plateforme, dont le fait qu’on a migré en 24h chrono, surpassaient les inconvénients.

J’aurais aussi pu choisir de laisser mon blog où il était et d’en commencer un nouveau. Après tout, c’est ce que font beaucoup de gens : voyez par exemple ARHV qui a déménagé pour l’Atelier des icônes avant de fermer boutique et passer sur Image sociale. Sur chacun de ses « anciens » blogs, un message indique qu’il est fermé et pour lire la suite, renvoie au nouveau. De fait, les vieux liens vers ARHV que j’ai pu créer dans mes anciens billets fonctionnent toujours.
C’est à dire qu’au lieu de tuer 600 URL, j’aurais pu accepter de laisser mourir mon blog tout seul… Mais tout entier.
Ah non. Ça, ce n’était pas possible. Vous voyez, je suis quelqu’un qui a besoin de changement. Souvent, je déplace tous les meubles de mon salon. Et quand j’en ai marre de déplacer les meubles et que je recherche un changement plus radical, je déménage. Mais je n’ai encore jamais déménagé en abandonnant tous mes meubles et mes cartons derrière moi.
En plus, pour être très franche, je n’ai pas l’intention de me remettre à bloguer beaucoup plus souvent ; alors quitter un blog pour en créer un nouveau qui resterait vide, cela n’avait pas tellement de sens.
Enfin, dans l’opération, j’aurais perdu la notoriété associée à mon nom de domaine : figoblog.org. Le fait que les gens le connaissent, ainsi que son référencement.

Donc quand Got m’a annoncé que les URL allaient être brisées, j’ai dit « tant pis ».
Comment puis-je encore me regarder dans une glace et dormir sur mes deux oreilles après avoir pris une décision pareille ? J’ai plusieurs choses à dire pour ma défense.
La première, c’est que ce n’est qu’un blog. Je n’ai jamais pris le moindre engagement institutionnel quant à la pérennité des URL de chaque billet. Le web change, bouge, chaque jour des URL naissent et meurent. Il y a des dizaines, des centaines de liens morts dans les vieux billets du Figoblog que j’ai emmenés avec moi dans ce déménagement. C’est la vie. Si on veut une image figée du web, il faut aller dans les archives (ou le dépôt légal).
La deuxième, c’est que d’un point de vue fonctionnel, j’estime qu’aujourd’hui on dispose de tous les outils nécessaires pour retrouver un billet, à commencer par le moteur de recherche intégré (là, à gauche). Et grâce à ma nouvelle plateforme, on tombe directement sur ce moteur quand on arrive sur un lien mort sur mon blog.
Last but not least, il me semble que l’usage principal d’un blog n’est pas (ou rarement) d’accéder aux vieux billets par des favoris. En général on les retrouve par son moteur de recherche préféré et de toute façon ce sont les nouveaux billets qui comptent (même si en me relisant j’ai trouvé quelques vieux trucs intéressants !) Quant aux twitts et autres posts Facebook qui sont mes principaux référents, ils sont encore plus éphémères…

Que peut-on retenir de cette aventure ? Et bien, que la pérennité a un coût. Maintenir des URL implique de trouver un équilibre entre le niveau de pérennité nécessaire et attendu des identifiants et les moyens dont on dispose pour les maintenir.
Sur mon ancien blog, le fait même de bloguer était devenu compliqué, laborieux, je ne pouvais plus voir le design en peinture, il y avait des bugs et du spam et plein d’autres inconvénients. Il fallait migrer. Got et moi n’avions que des moyens humains très réduits à consacrer à cette migration et nous avons dû faire des choix. Nous avions tout testé avec succès sur WordPress.com : l’import des anciens billets, les fonctionnalités front et back-office… Si je m’étais crispée sur cette histoire d’URL, tout était à refaire et la migration sans doute remise aux calendes grecques.

Pour résumer, la maintenance des URL était une fonction secondaire en termes d’usage, pour laquelle nous n’avions pas de politique stricte, et dont le coût était tel qu’il était susceptible de menacer l’activité elle-même (le blog). Dans ces cas-là, il faut savoir faire son deuil.

Figoblog

Un blog sur Internet, la bibliothéconomie et la confiture de figues

Archives de Catégorie: Internet