Afin de rendre visible le travail colossale d’annotation réalisé par les équipes des Archives nationales, les transcriptions susceptibles de servir de données d’entraînement sont désormais publiées au sein du projet HTR-United, dans 3 répertoires Github distincts. Leur publication permet désormais à d’autres utilisateurs et utilisatrices de l’HTR de les réemployer pour leur propres expérimentations.
Il s’agit des répertoires suivants :
– LECTAUREP Repertoires : qui contient les pages de répertoires, transcrites et validées (de nombreuses nouvelles pages sont en cours de relecture).
– LECTAUREP Bronod : qui contient les minutes rédigées par Maître Bronod, dont le format diffère du corpus de répertoires car elles datent de 1742.
– LECTAUREP Mariages et Divorces : qui contient les registres des Mariages et Divorces, pour le début du XXe siècle principalement.

Un modèle générique v1
Un nouveau modèle générique intitulé lectaurep_base a été entraîné à partir de ces données. Il est publié sur deux plateformes :
– sur Zenodo, ce qui le rend interrogeable depuis Kraken et permet de lui attribuer un DOI : https://zenodo.org/record/6542744
– sur Github afin de correctement documenter ses conditions de création : https://github.com/lectaurep/lectaurep_base_model
Les deux espaces de publication sont synchronisés et ont l’avantage de permettre de versionner les dépôts. Cela signifie que lorsque de nouvelles données seront publiées, nous pourrons entraîner un nouveau modèle et le publier dans les mêmes répertoires comme des v2, 3, etc.
Il est toujours possible d’accéder aux autres modèles entraînés au cours du projet LECTAUREP, notamment Generic_lectaurep_26, en se rendant ici : https://gitlab.inria.fr/dh-projects/kraken-models.
9,8% de CER
Le modèle générique produit encore beaucoup d’erreurs car son CER (Character Error Rate) reste au-dessus de 5%. Ce taux d’erreur augmente sur des données hors-domaine, c’est-à-dire des variations d’écritures inconnues pour le modèle.
Si on l’applique à un poème autographe d’Apollinaire par exemple, il fait 5 erreurs sur le titre :
Lettres à lire | Lettres lue |
L | l |
ont | ais |
b | l |

Le modèle lit donc “le Pais Miraleau” au lieu de “Le Pont Mirabeau”. Il est toutefois intéressant de noter deux choses :
– sur ce même segment, le modèle lectaurep_base fait moins d’erreurs que le modèle generic_lectaurep_26 (même si une partie d’entre elles sont identiques)
– les erreurs propres à lectaurep_base ont plus de sens que celles de generic_lectaurep_26 : si on regarde le tracé des lettres, on comprend l’origine de ces inversions.
L’ajout de nouvelles données d’entraînement pourra peut-être permettre d’abaisser le taux d’erreur théorique, mais cela permettra surtout d’augmenter la robustesse face à des écritures inconnues. Par ailleurs, le but d’un tel modèle n’est pas forcément d’être utilisé comme tel, mais plus de servir de base (comme son nom l’indique) pour affiner de nouveaux modèles de transcription, spécialisés sur une période ou une famille d’écritures.
Publication avec Kraken
Le dépôt Zenodo à été généré à partir de l’utilitaire de publication proposé par Kraken. Il me paraît intéressant d’expliquer ici la marche suivie.
Après avoir installé Kraken (dans un environnement virtuel), la commande “ketos publish” permet de lancer l’utilitaire de publication. La commande complète la plus basique ressemble à ceci :
ketos publish -a $ACCESS_TOKEN chemin/vers/le/model.mlmodel
Cette commande déclenche l’utilitaire en mode interactif. L’utilisateur ou l’utilisatrice est alors amené(e) à renseigner, entre autres, le nom des auteurs et autrices du modèle, leur affiliation, la licence associée au modèle, ainsi qu’une description plus ou moins longue.
La valeur ACCESS_TOKEN doit être obtenue prélablement à partir de Zenodo. Pour cela, il faut créer un compte Zenodo et s’y connecter, puis aller sur Paramètres, puis Applications (ou cliquer ici). C’est depuis cette page que l’on peut créer un jeton d’authentification (access token) qu’il faut prendre soin de copier avant qu’il ne devienne invisible. Le jeton est une (longue) liste de caractères, par exemple “xTjfTjffMh3Ch0CSfwT1tpC”. Avec une telle valeur, la commande ressemble donc à ceci :
ketos publish -a xTjfTjffMh3Ch0CSfwT1tpC chemin/vers/le/model.mlmodel
Comme il peut sembler risqué d’utiliser la ligne de commande pour fournir les métadonnées qui seront ensuite publiées avec le modèle, il est possible d’utiliser un fichier JSON reprenant la structure suivante :
{"authors": [{"name": "", "affiliation": ""}], "summary": "", "description": "", "accuracy": 00.00, "license": "", "script": [], "name": "", "graphemes": []}
C’est l’option “-i” qui permet de passer le fichier de métadonnées à Ketos. Le mode interactif ne se déclenche pas si on utilise cette option. Admettons que le fichier soit nommé “metadata.json”, la commande ressemblerait à ceci :
ketos publish -i chemin/vers/metadata.json -a xTjfTjffMh3Ch0CSfwT1tpC chemin/vers/le/model.mlmodel
Lorsque la publication vers Zenodo est terminée, Kraken affiche l’identifiant du nouveau dépôt. Il est alors possible d’éditer les métadonnées depuis Zenodo de manière à corriger des erreurs, mieux structurer la description longue, ou encore ajouter d’autres contributeurs et contributrices.
En publiant à l’aide de Kraken, le modèle est automatiquement associé à la communauté “OCR/HTR model repository“. Cela lui donne plus de visibilité, ce qui n’est pas un luxe dans l’océan de dépôts qu’est Zenodo !
OpenEdition vous propose de citer ce billet de la manière suivante :
alixchague (12 mai 2022). Publication d’un modèle de transcription et de la vérité de terrain ! LECTAUREP. Consulté le 7 février 2025 à l’adresse https://doi.org/10.58079/qssm