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 !

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.

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.

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 :

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.

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 :

É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 !
OpenEdition vous propose de citer ce billet de la manière suivante :
Karl Pineau (11 décembre 2018). CaptchA-N : Vers un système de validation de l’indexation collaborative. Données culturelles. Consulté le 17 février 2025 à l’adresse https://dculturelles.hypotheses.org/33
C’est une excellente idée. Je salue la maturité de l’idée qui a émergé d’un Hackathon.
Va t’elle être déployée ?
Bonjour, merci pour votre commentaire 🙂 Le projet a été proposé aux services innovants du ministère de la culture. Si le projet est sélectionné, il sera développé, à minima en prototype.
Bravo et merci pour ce billet à la fois détaillé et accessible. C’est vraiment un beau projet qui j’espère se fera, tant les différents points du derniers paragraphes sont évidents.