CaptchA-N : Vers un système de validation de l’indexation collaborative

Les 8 & 9 décembre 2018 s’est tenu le premier Hackathon des Archives nationales, organisé au Liberté Living Lab (espace collaboratif au milieu de Paris), auquel j’ai pris un grand plaisir à participer et à développer le projet CaptchA-N, coup de cœur innovation du jury. L’occasion de revenir sur ce projet mené avec mes camarades Sylvain Boissel, Anne-Laure Donzel, Pol Enault & Kelyan Morfouesse et dont je pense qu’il mériterait d’être réellement mis en œuvre !

Le logo de notre projet CaptchA-N

Léonore, la base de la Légion d’honneur

Pour comprendre notre projet, il faut déjà que je vous parle de Léonore. Léonore est la base des Archives nationales dédiée aux récipiendaires de la légion d’honneur. Elle référence ainsi environ 350.000 personnes ayant reçu la légion d’honneur entre le moment de sa création sous le Premier Empire et la fin des années 1960 (les données disponibles étant soumises à un délai de 50 ans). Il s’agit de l’un des fonds des Archives nationales les plus fréquentés, eu égard à la popularité de la Légion d’honneur en France.

Interface de Léonore

Léonore, comme un certain nombre de systèmes d’information du ministère de la culture, tourne encore sur le logiciel Mistral, logiciel qui a servi à mettre en ligne la plupart des bases patrimoniales au milieu des années 1990 (vous reconnaîtrez d’ailleurs l’ergonomie type des bases Joconde, Mérimée, Palissy, etc.)

Depuis la mise en ligne de la base, elle a dans l’ensemble peu évolué sur le plan des métadonnées. Cette faible évolutivité ne rend aujourd’hui possible l’interrogation de la base que sur un nombre restreint de champs : ne sont globalement disponibles que les noms et les informations de naissance des légionnaires. Or, les Archives nationales conservent au sein des dossiers de ces légionnaires de nombreuses autres informations à leur propos : bien évidemment les informations concernant leur incorporation au corps des légionnaires (dates, grades, sur proposition de…), mais également des informations issues des documents du dossier monté au moment où la personne est proposée à la légion, comme sa profession.

Exemple de notice indexée collaborativement sur Mémoire des Hommes

Compte-tenu de la popularité du fonds, les dossiers des légionnaires ont été numérisés par les Archives nationales. Mais pour autant les documents n’ont pas été indexés, car il s’agit d’un travail long et fastidieux. Le service en charge de ce fonds aux Archives nationales nous a donc suggéré l’idée de proposer une nouvelle version de cette base mettant en œuvre une indexation collaborative des documents afin d’enrichir les métadonnées sur les légionnaires. Une façon de redonner du travail aux bénévoles ayant indexé Mémoire des Hommes en sommes !

Un problème de validation

Le problème de l’indexation collaborative telle que pratiquée sur Mémoire des Hommes, c’est que 350.000 notices à indexer à raison de environ une dizaine de champs par notice, cela donne potentiellement 3.5 millions d’informations à valider par les membres du service en ayant la charge. Sans compter le fait que ces informations ne sont pas concentrées sur une seule page numérisée (contrairement à Mémoire des Hommes) mais éclatées dans un dossier hétérogène, ce qui rend leur validation d’autant plus fastidieuse.

Il s’agit là d’une situation classique des projets institutionnels de recherche à vocation collaborative : les bénévoles de ces projets sont souvent très motivés et actifs, et l’équipe projet a du mal à suivre le rythme si elle veut continuer à mener en parallèle ses autres missions et obligations professionnelles.

Face à ce problème de validation de l’indexation collaborative, la proposition de mon équipe a été de mettre en œuvre une deuxième étape collaborative : la validation collaborative.

Cette proposition n’est en soi pas nouvelle. Le Transcribathon de Europeana propose une validation de la transcription collaborative par les pairs. Mais cette validation repose souvent sur un ou deux bénévoles qui prennent la responsabilité de la validation de la contribution d’un autre bénévole. Autrement dit : l’équipe projet doit avoir suffisamment confiance dans sa communauté pour lui déléguer cette validation ou tout simplement miser plus sur la quantité du travail collaboratif que sur la qualité… Ou tout du moins sur une très haute qualité, car il faut bien reconnaître que le travail des bénévoles est dans son écrasante majorité très qualitatif.

Cependant, l’idée de notre équipe était bien de se confronter à la validation collaborative avec l’idée d’en proposer un outil solide et qui garantisse un résultat quasi-parfait à la sortie. Pour cela, il fallait faire en sorte que l’utilisateur validateur soit ne sache pas qu’il était en train de valider, soit ne puisse pas tricher avec le système et soit obliger d’apporter la bonne réponse.

Une histoire de captcha

Et bien un système permettant de faire valider à l’aveugle des contributions, cela existe déjà : il s’agit des captcha que vous remplissez tous les jours sur le web.

Ainsi, lorsque je me suis connecté à l’interface d’administration de ce blog hypothèses, le service m’a demandé de confirmer que je n’étais pas un robot qui essayait de pirater mon propre blog et m’a donc afficher cette petite interface que vous devez bien connaître :

Un captcha Google

Le captcha est une variante du test de Turing permettant de différencier un humain d’un robot et ainsi d’assurer la sécurité d’un système auquel on souhait que seuls des humains accèdent.

Seulement voilà, Google (puisque c’est Google qui propose le service qui s’affiche sur hypotheses.org comme sur la plupart des captcha que vous pouvez trouver) n’aurait pas réellement d’intérêt à proposer gratuitement un service de sécurité si cela ne lui rapportait pas quelque chose… C’est pourquoi vos réponses à la question « Quelles images montrent des passages pour piétons » sont en fait réutilisées par les algorithmes de Google pour améliorer ses différents services : géolocalisation, voitures autonomes, reconnaissance d’image, etc.

In fine, en remplissant un captcha, vous travaillez gratuitement pour Google et sans même le savoir. C’est ce que Fuchs, Scholz ou Cardon et Casili qualifient de digital labour.

Un captcha pour la recherche !

Ce que nous avons donc proposé pour le Hackathon des Archives nationales, ce n’est ni plus ni moins que de mettre en place un captcha made in Archives nationales (voire plus globalement, made in Recherche académique) dont l’objectif est d’absorber les contributions des différents projets d’indexation collaborative comme la base Léonore, et de les faire valider par des internautes naviguant sur des sites académiques (comme ce blog Hypothèses) ou institutionnels (par exemple Ameli.fr ou impots.gouv.fr). Ces sites bénéficiant d’un fort trafic (car pour une part liés à des démarches administratives obligatoires), la recherche s’assurerait ainsi une force de validation considérable pour faire avancer ses projets.

Alors concrètement, comment fait-on ? Et bien c’est (presque) simple !

Étape 1 : mettre en place une plateforme collaborative (presque) classique

Première étape, il est nécessaire de mettre en place un système d’indexation collaborative respectant quelques règles :

  • Le contributeur qui indexe (que nous avons qualifié au sein du projet de contributeur actif) doit transcrire ce qu’il lit dans un champ dédié. Il ne s’agit ni plus ni moins que de remplir le formulaire classique des interfaces d’indexation comme Mémoire des Hommes ;
  • Cependant, pour permettre la mise en œuvre du captcha, il est nécessaire de rajouter une étape  : la transcription de l’utilisateur actif se fait au regard d’un contenu numérisé sous forme d’image. Si l’information est une partie de l’image (par exemple un mot au sein d’un texte), il est nécessaire que l’utilisateur découpe dans l’image le mot en question pour que l’on puisse le reproposer sous forme de captcha.

Aussi bien en termes techniques qu’en termes d’interface, ce que nous proposons est simple à mettre en œuvre. Vous pouvez voir ci-dessous la démonstration de l’interface que nous imaginons.

Techniquement, lorsque l’utilisateur dessine la zone de l’image dans laquelle se trouve l’information qu’il identifie, il définit les coordonnées d’une zone au sein de l’image. Nous proposons que les images à indexer soient déposées sur un serveur IIIF. Pourquoi ? Car cela permet ensuite d’indiquer directement les coordonnées dans le paramètre région de l’API Image IIIF. Il n’est donc pas utile de découper l’image pour le captcha.

Application du protocole IIIF

Comme la TGIR Huma-Num propose avec Biblissima la solution IIIF360, on ne pourra pas nous dire que mettre en œuvre une solution IIIF est compliqué dans le monde de la recherche française ;).

Étape 2 : collecter des indexations et les soumettre au captcha

Une fois la plate-forme de contribution lancée, elle va commencer à collecter des données de la part des contributeurs. Le projet sera prêt à communiquer avec le système de captcha une fois qu’il aura accumulé une certaine quantité de données qui correspond à :

  • Au moins 9 indexations du même champ (par exemple « profession ») ;
  • Dont au moins 3 doivent avoir la même valeur (par exemple « maréchal-ferrant ») ;
  • Et au moins 2 ont été validés à la main par l’équipe projet, pour fournir des valeurs de contrôle à l’algorithme.

Il faut ensuite que la plate-forme collaborative autorise le système de captcha à lui adresser des requêtes GET sous la forme d’API REST :

GET /captcha-question

Ce à quoi la plate-forme doit lui retourner des données précisant une question et 9 propositions de réponse, correspondantes aux 9 images à afficher. L’intérêt de ce système est que c’est la plate-forme qui choisit quelle question poser et quelles données afficher afin de coller au mieux à son besoin de validation.

{
"question": "Identifiez les occurrences de Maréchal-ferrant",
"proposals": [
{
"image": "iiif/2/image1.jpg/180,400,200,30/full/full/default.jpg",
"isAMatch": "yes"
},
{
"image": "iiif/2/image2.jpg/180,400,200,30/full/full/default.jpg",
"isAMatch": "no"
},
{
"image": "iiif/2/image2.jpg/180,400,200,30/full/full/default.jpg",
"isAMatch": "maybeYes"
},
{
"image": "iiif/2/image2.jpg/180,400,200,30/full/full/default.jpg",
"isAMatch": "maybeNo"
}

]
}

Les 9 propositions envoyées étant réparties en 4 groupes (via la propriété isAMatch) :

  • 2/9 images ayant une réponse correcte (valeur de contrôle) ;
  • [3-4]/9 images ayant probablement une réponse correcte (valeur à valider) ;
  • [2-3]/9 images ayant probablement une réponse incorrecte (valeur à invalider) ;
  • 1 image ayant une réponse incorrecte (valeur de contrôle).

Étape 3 : soumission à un utilisateur du captcha

Le captcha va donc solliciter l’API de la plate-forme collaborative lorsqu’un utilisateur se connectera sur le site d’une administration ou d’un service public. Nous prenons ici l’exemple de Ameli.fr.

Le captcha va afficher les propositions dans un ordre aléatoire à l’utilisateur, que nous qualifions d’utilisateur passif. L’utilisateur passif est donc celui qui remplit le captcha, souvent sans connaître l’objectif de ce dernier. Notre objectif secondaire est d’ailleurs de le transformer utilisateur actif. Pour cela, nous proposons d’ajouter à notre prototype une phrase type « À quoi sert ce captcha ? » qui renverrait vers une page de la plate-forme contributive, ici celle de Léonore, expliquant les enjeux de l’indexation collaborative :

Du point de vue de la sécurité, nous appliquons les paramètres suivants :

  • Si l’utilisateur ne coche pas les 2 images de contrôle positives, il échoue au test ;
  • Si l’utilisateur coche l’image de contrôle négative, il échoue au test ;
  • Parmi les images probablement positives et négatives, si l’utilisateur effectue plus de 2 actions probablement incorrectes (cocher une image probablement négative par exemple), il échoue au test.

Nous calculons qu’ainsi, il y a un peu moins de 2% de risques que l’utilisateur ou un robot trompe le captcha en répondant au hasard. Si l’utilisateur passif passe le test de sécurité, le captcha renvoie les informations à la plate-forme collaborative via une requête POST.

{
"question": "Identifiez les occurences de Maréchal-ferrant",
"proposals": [
{
"image": "iiif/2/image1.jpg/180,400,200,30/full/full/default.jpg",
"response": 1
},
{
"image": "iiif/2/image2.jpg/180,400,200,30/full/full/default.jpg",
"response": 0
},
{
"image": "iiif/2/image2.jpg/180,400,200,30/full/full/default.jpg",
"response": 1
},
{
"image": "iiif/2/image2.jpg/180,400,200,30/full/full/default.jpg",
"response": 0
}

]
}

Étape 4 : validation statistique de l’indexation

Lorsque le captcha retourne les données à la plate-forme, c’est à cette dernière de les ajouter à sa base de données. Autrement dit, le captcha n’intervient pas dans la validation à proprement parler.

Nous proposons néanmoins la démarche de validation suivante. Chaque indexation collaborative va passer un certain nombre de fois dans le système du captcha. À chaque passage, cette indexation va :

  • récolter des votes, plus ou moins nombreux selon l’action de l’utilisateur et le contexte,
  • indiquer si ces votes sont positifs (l’image correspond à l’indexation) ou négatifs (l’image ne correspond pas à l’indexation).

La validation de l’indexation ou le refus de l’indexation se calculent ensuite selon un ratio de votes. Précisons d’emblée que les lignes suivantes ne valent que et uniquement que si l’utilisateur passif a préalablement passé le test de sécurité indiquant qu’il est bien un humain.

On distingue 4 situations possibles lorsqu’une image passe dans le captcha :

L’utilisateur a coché l’image
L’utilisateur n’a pas coché l’image
À priori, la transcription est vraie
+3 votes positifs
+1 vote négatif
À priori, la transcription n’est pas vraie
+3 votes négatifs
Pas de vote

Le système décrit se base sur un certain nombre de règles logiques :

  • Un clic est une action active qui a plus de valeur qu’une absence de clic (action passive) ;
  • L’utilisateur qui ne clique pas pour sélectionner une image alors qu’il aurait dû la sélectionner commet probablement un oubli mais cela peut aussi dire que l’indexation est fausse ;
  • L’utilisateur qui clique pour sélectionner une image alors qu’il n’aurait pas dû envoie un signal fort sur un potentiel d’erreur d’indexation.

Dans le système de vote décrit, il suffit donc d’indiquer les seuils suivants pour valider ou invalider la transcription :

  • Le seuil de validation est fixé à minimum 20 votes dont 90% sont positifs. Cela veut dire qu’une transcription correcte suggérée à des utilisateurs ne faisant pas d’erreur sera proposée 7 fois avant validation (7×3 = 21). Ce seuil permet donc d’anticiper toute erreur de la part des utilisateurs ;
  • Le seuil de rejet est quant à lui fixé à minimum 10 votes dont 25% sont positifs. Cela veut dire que l’image passera devant 10 (10×1) utilisateurs dont on s’attend à ce qu’ils ne cliquent pas dessus avant d’être rejetée.

Notre système part donc du principe que c’est aux plate-formes de stocker les décomptes des votes puis d’établir les seuils de validation des transcriptions. In fine, nous proposons d’afficher sur l’indexation collaborative les informations suivantes permettant de connaître les statistiques d’une indexation :

Interface présentant pour une indexation les statistiques issues du captcha

Étape 5 : accélérer le processus en évaluant ses contributeurs actifs

On peut tout à fait trouver que les seuils de validation présentés sont relativement hauts. Qui plus est, on sait que la majeure partie des projets collaboratifs fonctionne sur une petite base d’utilisateurs très actifs. À partir de là, il est possible d’accélérer le processus de validation en préjugeant de la qualité d’une indexation au regard de l’historique de l’utilisateur.

Ainsi, l’algorithme de validation peut considérer qu’à chaque indexation validée pour un utilisateur, les prochaines contributions de cet utilisateur partiront avec un nombre de votes initial de +0.5 positif, dans une limite de +5. Cela veut donc dire qu’un utilisateur très actif va rapidement atteindre ce seuil de +5 et qu’il n’aura donc besoin que de +15 votes supplémentaires pour faire valider ses contributions, ce qui revient à 5 passages positifs sur le captcha.

La logique fonctionne également dans le sens inverse – même si elle peut être discutée – pour rendre le système plus dur envers des utilisateurs aux productions peu qualitatives. En ajoutant +0.5 vote négatif par indexation rejetée dans la limite de +5 (ce qui revient tout de même à dire que l’utilisateur a vu ses productions rejetés par 100 personnes au minimum !), on établit que seuls 5 passages négatifs sur le captcha sont nécessaires à l’invalidation de l’indexation. Tout en gardant la porte ouverte à une amélioration de la qualité produite par cet utilisateur puisqu’une indexation validée fera remonter son taux initial.

Service public : dégooglise-toi !

Pour conclure, le service que nous avons proposé nous semble répondre à un grand nombre d’objectifs de la recherche publique et de l’administration de manière générale :

  • Nous favorisons l’accès à des données publiques sur lesquelles existe une forte demande de la part de nos concitoyens en accélérant le processus d’indexation des fonds archivistiques ;
  • Nous offrons à la recherche publique un outil qui lui permettra d’augmenter la qualité de ses données et sa visibilité, dans l’idée de se saisir également de ces contributions pour produire de nouvelles analyses historiques ou sociologiques sur des corpus de données archivistiques ;
  • Nous déchargeons les personnels des archives d’une tâche longue et souvent ingrate de validation des données collaboratives ;
  • En objectif secondaire, nous espérons toucher et amener de nouveaux publics sur les bases patrimoniales, des publics qui ne savaient peut-être pas que ces projets existaient mais qui consultent les sites d’institutions publiques ;
  • Enfin – et presque surtout – nous permettons aux sites institutionnels de trouver une alternative durable et qui fait sens aux systèmes des GAFAM tout en permettant à la recherche de progresser.

Comme je le disais en début d’article, le projet nous a semblé assez pertinent pour le développer. Si vous aussi pensez que l’idée a du potentiel, n’hésitez pas à nous contacter !

L’importance du contexte de la recherche dans les systèmes d’information documentaire

[Article initialement publié le 27 décembre 2017]

Avec la fin de l’année s’achève la période des hackathons et autres conventions tirées de l’univers du numérique et que l’on retrouve de plus en plus dans les institutions culturelles.

Pour ma part, après avoir fréquenté les couloirs de la WikiDataCon en octobre dernier, j’ai participé à la seconde édition du hackathon de la BNF (au sein de l’équipe MusiViz, qui a remporté l’édition 🙂 ) puis au barcamp des Archives nationales qui s’est tenu début décembre.

Or il s’avère que lors de ces deux derniers évènements, j’ai travaillé sur des projets très similaires, tous les deux portés sur la compréhension des données par l’utilisateur. L’objectif de ce billet est donc de vous faire part de mes impressions lors de ces deux évènements, et notamment sur les bénéfices de l’adaptation des interfaces de recherche documentaire au contexte de la recherche.

De la musique et des données

Logo du projet MusivzPour le projet MusiViz (au hackathon de la BNF), nous avons cherché avec notre équipe à rendre tangible un type de contenu généralement complexe à représenter : l’audio. La question initiale que nous nous sommes posés a été la suivante : « en tant qu’utilisateur de Gallica, de quelles informations ai-je besoin pour trouver et sélectionner les documents audio qui m’intéressent ? »

Page de résultats de recherche de Gallica
L’actuelle page de résultats de recherche de Gallica

De ce point de vue, nous nous sommes penchés sur les manières de rendre visible dès la page de résultats de Gallica le contenu de la piste audio. Nous avons donc travaillé autour de deux fonctionnalités durant les 24h qui nous étaient allouées : la génération à la volée de spectrogrammes des pistes audio et la génération de flux d’images relatifs au contenu d’une piste audio. C’est plus particulièrement à la première de ces fonctionnalités (le spectrogramme) que je vais m’intéresser ici.

Un exemple de spectrogramme tiré de Musiviz
Un exemple de spectrogramme tiré de Musiviz

Dit comme cela, on peut se poser la question : qu’est-ce que ça apporte concrètement de montrer un spectrogramme alors que ce que cherche à priori un Gallicanaute est un résultat correspondant à certains mots-clés, qu’il retrouvera dans le titre de sa piste audio ?

L’importance du contexte de la recherche

En réalité, lorsque vous effectuez une recherche sur le web, vous la réalisez systématiquement dans un contexte précis. Prenons un exemple : je fais une recherche sur Thomas Couture.

Si vous, qui me lisez de l’autre côté de l’écran, ne connaissez pas cette personne et souhaitez en savoir plus à son propos, vous allez probablement taper son nom dans Google (ou votre moteur de recherche favoris). La question qui se pose est : à ce moment précis, que souhaitez-vous savoir sur Thomas Couture ? À priori pas toute sa biographie, ni son apparence physique pas plus que l’histoire de ses parents. Non, à priori, vous voulez juste savoir de qui je parle et vous allez donc vous concentrez sur des informations génériques du type : qu’a-t-il fait dans sa vie, quand a-t-il vécu, pourquoi est-il connu ?

C’est en fonction de ce contexte de recherche que vous allez sélectionner les résultats (c’est à dire ici les pages web parlant de Thomas Couture) qui vous intéressent. Et donc si l’on suit notre exemple, comme vous souhaitez obtenir rapidement des informations générales sur Thomas Couture, vous allez plutôt privilégier sa page Wikipédia (si ce n’est uniquement l’introduction de cette page) à sa biographie de 700 pages par Albert Boime sur Google Books.

Ce choix est dicté par votre connaissance préalable de la recherche documentaire. En effet, vous avez acquis (par connaissance ou expérience) le fait qu’une page biographique sur Wikipédia présente un résumé normé d’une personne et que, au contraire, il est souvent difficile de trouver d’un seul coup d’œil les principales informations biographiques d’une personne dans un ouvrage de 700 pages.

Dans les interfaces de recherche documentaires patrimoniales

Les personnes qui effectuent une recherche sur une bibliothèque numérique telle que Gallica ou plus globalement sur une base de données patrimoniales sont soumises aux mêmes logiques.

En effet, quelque soit le contexte de ma recherche, toute information qui m’aidera à l’optimiser (par exemple en éliminant le bruit dans les résultats et en atténuant les silences) sera la bienvenue.

 

Ainsi, sur la capture d’écran suivante tirée de notre prototype MusiViz, chaque spectrogramme représente en quelque sorte l’emprunte du son. Et vous constatez très clairement que si le premier et le dernier résultats sont bien différents, les deux du milieu sont quasi-identiques. Un coup d’œil au titre de ces deux résultats et vous aurez compris qu’il s’agit en réalité de la même piste audio, puisque les titres sont quasi identiques.

Capture d'écran du prototype MusiViz présentant des spectrogrammes identiques
Version MusiViz – Vous constatez aisément la similarité entre les empruntes des deux résultats du milieu

On espère ainsi vous avoir fait économiser un clic inutile (celui d’avoir lancé deux fois une piste similaire). Néanmoins, l’économie du clic – et en réalité la pertinence de votre choix – ne sera complète qu’à partir du moment où vous aurez pu déterminer lequel des deux résultats de recherche est le meilleur. Autrement dit : sur lequel des deux dois-je cliquer ? Pour répondre à cette nouvelle interrogation, il convient de s’attacher au mot « meilleur » dans l’expression « meilleur résultat de recherche ». Qu’est-ce qui définit ici un bon résultat de recherche ?

Résultats de recherche sur Gallica
Les mêmes résultats de recherche sur l’interface actuelle de Gallica

De mon point de vue, un bon résultat de recherche requiert trois caractéristiques :

  • Tout d’abord, il est impératif que le contenu soit celui que vous cherchez. Ici, vous pouvez bien écouter José Greco et sa musique de ballets ;
  • Ensuite, la description du contenu correspond à vos attentes : les données sont suffisantes pour confirmer que le contenu est le bon ou vous apporter de nouvelles informations à son sujet. Sur cet exemple, le résultat daté de 1961 semble contenir des données plus complètes que le résultat de 1960. On trouve par exemple une description ;
  • Enfin, les conditions d’accès au contenu vous permettent de prioriser ou d’opérer des choix après avoir appliquer les filtres précédents.

Ce sont ces conditions d’accès qui m’intéressent ici. En effet, au même titre que vous ne choisissiez pas un livre de 700 pages pour obtenir 5 lignes de description de la vie de Thomas Couture, vous cherchez peut-être (selon le contexte de votre recherche) des pistes sonores avec des caractéristiques précises.

Par exemple, si vous vous lancez dans une recherche exploratoire sur André Breton sur Gallica (en prenant uniquement les documents sonores), il est probable que vous souhaitiez commencer par les pistes les plus courtes (comme ce poème de quelques minutes) avant d’écouter les 40 minutes d’entretien avec André Breton. Car si le contenu (c’est-à-dire le document) est important, la manière dont vous vous l’appropriez ne l’est pas moins. L’ordre de consultation des documents, et donc l’ordre de découverte, est donc un critère essentiel à l’efficacité de votre recherche exploratoire.

Les métadonnées de MusiViz
Les métadonnées mises en avant sur MusiViz

De la même manière, vous serez peut-être exigeant sur la qualité sonore des pistes et souhaiterez éliminer d’office les pistes sur lesquelles le bruit est trop important. Ou bien, vous serez en attente de résultats de recherche particulièrement riches en liens vers d’autres documents. Durant le hackathon de la BNF, c’est ce type d’information que nous avons cherché  à mettre en avant pour les documents sonores de Gallica. Comme le montre l’illustration ci-contre, nous cherchons donc à montrer :

  • Le nombre de documents liés (un point noir plus ou moins gros)
  • La date de la numérisation de la piste (dans l’idéal la date de la piste)
  • La qualité de la piste sonore, son taux de bruit (représenté par la barre de batterie plus ou moins vide à mesure que la qualité baisse)
  • Le nombre de battements par minute de la piste.

Bien sûr, il était difficile de proposer une interface travaillée en 24h (surtout sans graphiste / UI designer dans l’équipe) mais l’idée est là.

Une idée qui a d’ailleurs germé depuis de nombreuses années dans l’esprit des designers des nouveaux services numériques dédiés aux médias, puisque nombreux sont les sites web où vous trouvez aujourd’hui des estimations du temps nécessaire qu’il vous faudra pour lire un document.

En-tête du site Medium
Un exemple sur le site Médium

Le minutier central des Archives nationales

La question de la prise en compte du contexte de la recherche du côté de l’utilisateur est une idée sur laquelle nous nous sommes également penchés avec mon groupe lors du barcamp organisé par les Archives nationales le 9 décembre dernier (organisé dans l’optique d’un hackathon courant 2018).

Le sujet sur lequel mon groupe de travail a travaillé durant cette journée se trouvait être résumable en : la découverte et l’accès au document du Minutier central des notaires de Paris.

Dans le cas du Minutier central, les conditions d’accès aux documents sont d’autant plus importantes que les documents ne sont pas toujours accessibles en ligne (il est possible d’y avoir accès sur place aux archives) voire que leurs données ne sont pas décrites. Dès lors, l’usager des archives est amené à rentrer dans des logiques transcanal complexes pour accéder à son document.

Le Minutier archive les documents reçus des notaires parisiens. Lorsque les cartons qui contiennent les documents arrivent aux archives, ils ne sont pas inventoriés en détail (pour des questions de coût). On dispose ainsi le plus souvent uniquement d’un répertoire des actes du notaire, comme par exemple ici pour le notaire Pierre Claude Melin (cliquez sur la section archives numérisées). Pour trouver l’existence d’un document – par exemple un contrat de mariage entre deux personnes -, il faut donc parcourir le répertoire du notaire dans la période chronologique supposée de l’acte, jusqu’à le trouver (ou pas, si ce n’est pas le bon notaire ou si l’acte n’existe pas). Une fois que l’on sait que l’acte existe, on peut ensuite aller fouiller dans les cartons du notaire en question pour tâcher de le retrouver.

Planche de BD réalisé par l'équipe travaillant sur le Minutier central lors du Barcamp des AN
Planche de BD réalisée par l’équipe travaillant sur le Minutier central lors du Barcamp des AN et décrivant le cas d’usage.

Il va sans dire que ce système (ce workflow comme on dirait aujourd’hui) est tout sauf rapide et efficace. En effet, le cas classique d’une recherche dans les inventaires ne part pas du notaire, mais de son client. Reprenons notre exemple de Thomas Couture cité plus haut. Si je souhaite avoir son contrat de mariage et en partant de l’hypothèse qu’il se soit marié à Paris, je vais donc me rendre au Minutier central pour mettre la main sur le document. Oui mais voilà, la clé d’entrée dans le Minutier n’est pas Thomas Couture, mais son notaire. Pour trouver l’acte, il va donc falloir :

  • Trouver le notaire de Thomas Couture :
    • Je le connais : tant mieux, mais ça n’est pas nécessairement le cas le plus courant ;
    • Je ne le connais pas : arf, il va falloir trouver tous les notaires en exercice à l’époque supposée du mariage dans la zone géographique où habitait et s’est marié Thomas Couture ;
  • À partir de là, vous possédez une liste de 0 à X notaires potentiels. Cette étape se fait principalement aujourd’hui en discutant avec le personnel des archives ou par connaissance préalable. Il existe visiblement peu de ressources à ce sujet (ou alors vous êtes invité à commenter l’article pour me les signaler 🙂 ). Avec cette liste, vous allez pouvoir dépouiller les répertoires de chaque notaire. Cette étape se poursuit jusqu’à ce que vous trouviez trace de l’acte. Cela peut donc prendre du temps, beaucoup de temps. Le facteur déterminant étant la quantité de répertoires à éplucher et leur taille. Et puis il se peut aussi que vous ne trouviez pas l’acte, s’il n’existe pas ou que vous ne cherchez pas chez le bon notaire ;
  • Une fois que vous avez trouvé l’acte (disons que vous êtes chanceux), il ne vous reste plus qu’à vous rendre aux Archives nationales et à demander le carton dans lequel se trouve votre acte pour fouiller dedans jusqu’à le trouver.

Voilà voilà… Si vous vous étiez déjà demandé à quoi servait un cabinet de généalogistes, vous avez maintenant la réponse : ils font ce travail à votre place. On identifie donc un large panel de facteurs rendant la recherche complexe et incertaine :

  • La clé d’entrée est le notaire, et pas non les parties prenantes de l’acte ;
  • Il  n’existe pas nécessairement de listes en ligne des notaires par époque et lieu, il faut aller aux archives ;
  • Toutes les documents ne sont pas nécessairement aux Archives (puisque les documents ne sont versées par les études notariales que 75 ans après la date d’édition de l’acte) ;
  • On sait quand on commence à chercher, mais il est difficile d’évaluer le temps que cela va prendre (compte-tenu de l’incertitude de la recherche) ;
  • Il faut alterner les phases de recherche en ligne et aux archives.

À défaut de pouvoir agir sur le processus en lui-même, il est possible d’agir sur les conditions d’accès au contenu en ligne. En effet, tout au long du parcours de la personne effectuant la recherche, il est possible de définir des métriques afin d’orienter ses choix de recherche ou de lui proposer des outils lui facilitant la vie.

En premier lieu, parmi les outils évoqués par l’équipe du Minutier comme importants, il y a l’idée d’une carte géographique interactive des notaires de Paris. Si parfois la data-visualisation (tiens, un buzzword) tombe un peu dans le gadget et la volonté de faire joli, on comprend bien ici l’intérêt pour un usager du Minutier de disposer d’une carte qui lui indiquerait la liste des notaires dans une zone géographique à une période de temps donnée. La carte servant ici à faciliter le travail de représentation visuelle de la distance relative au logement du sujet de l’étude, ce qui serait un apport conséquent par rapport à une simple liste des notaires à proximité. Signalons au passage que des initiatives existent déjà à ce propos (comme cette liste méthodique des notaires de la Creuse).

Brainstorming de l'équipe Minutier sur l'aspect liste des notaires
Brainstorming de l’équipe Minutier sur l’aspect liste des notaires

Néanmoins, on se rend vite compte que d’autres informations sont utiles à fournir à l’usager – et n’existent pas aujourd’hui. Elles ne concernent pas nécessairement les documents d’archive qui intéressent l’utilisateur, mais le temps qu’il va passer à les trouver (et à les analyser). En effet, comme je l’expliquais auparavant, si votre recherche concerne un notaire peu actif, votre recherche sera courte, alors que si elle concerne une dizaine de notaires sur plusieurs décennies… Bon courage. Savoir que vous allez y passer probablement une après-midi ou alors que ça prendra environ une semaine est une information digne d’intérêt et qui orientera nombre de vos choix de recherche. Il s’agit qui plus est d’une information globalement simple à définir car les Archives sont globalement en mesure de donner le nombre de cartons par notaire et par période pour le Minutier. En déterminant une durée moyenne de consultation d’un carton ou d’un répertoire, que l’on peut pondérer selon l’expérience de l’utilisateur, on obtient aisément une échelle de temps.

Brainstorming de l'équipe Minutier
Brainstorming de l’équipe Minutier

Ainsi, nous proposions lors de ce barcamp d’indiquer lors de la recherche dans la SIV (Salle des Inventaires Virtuelle) non seulement le temps que prendrait une recherche (environ), mais également le niveau de difficulté de pour la lecture de l’écriture des documents. On pourrait également imaginer donner les taux de numérisation d’un fond de notaire, ou les zones chronologiques pour lesquelles les documents ne sont pas disponibles.

Pour conclure

Toutes ces mesures visent in fine à donner un feedback à l’usager. Ce retour d’information concerne non pas les documents mais leur découverte. Cela va ainsi donner un moyen à l’usager de faire des choix : est-ce que je mets tel résultat dans mon panier ? Est-ce que je lis tel document avant tel document ? Est-ce que je raffine ma recherche ?

N’avez-vous ainsi jamais ressenti la frustration de parcourir une longue liste de résultats de recherche sans savoir quand elle s’arrêtera ? Et bien si c’est le cas, vous comprendrez probablement l’utilité d’avoir au début de cette liste une bulle qui vous dirait « Il va vous falloir 2 heures pour parcourir cette liste ».

Peut-être aurez-vous déjà fait le lien, il s’agit bien ici d’enrichir une information qui existe déjà sous la forme du nombre de résultats de recherche, mais qui – compte-tenu de son importance – mérite d’être enrichie et spécialisée en fonction des domaines comme nous avons tâché de le faire avec l’équipe de MusiViz et avec l’équipe du Barcamp. Pour le dire en une phrase, une manière d’améliorer l’expérience utilisateur (oh, un autre buzzword) des interfaces documentaires.