Dans le cadre du partenariat entre le LIFAT-RFAI et le CESR-BVH, les développements de fonctionnalités et d’interfaces du logiciel RETRO pour la transcription de livres imprimés anciens se poursuivent. Le projet bénéficie ainsi en 2022 du financement d’un premier stage [pourvu] de 3 mois financé et encadré par Thierry BROUARD (LIFAT) pour améliorer l’application et les IHM. Un second stage [encore à pourvoir en date du 1^er mars 2022], soutenu par le Réseau thématique de recherche DIAMS (RTR), sera dédié à l’amélioration de l’IA avec une approche dite de clustering.

La transcription s’apparente à de l’OCR : on donne une image dans laquelle il y a du texte, et on ressort un fichier ASCII. Dans le cas des documents anciens, l’OCR est difficile, et les logiciels habituels, formés sur nos polices modernes et notre langue contemporaine (syntaxe, grammaire), ne dépassent pas les 20-30 % de bonne reconnaissance. Dans les documents anciens, orthographe et grammaire ne sont pas formalisées, et un même ouvrage rassemble souvent plusieurs langues (par exemple latin / grec / vieux français).

L’approche proposée commence par utiliser un algorithme d’apprentissage non supervisé (appelé aussi clustering) afin de rassembler les caractères qui se ressemblent le plus. L’utilisateur qui réalise la transcription donne alors, pour chaque groupe, le ou les caractères représentés. C’est donc l’humain qui fait la transcription, la machine essaie de minimiser le nombre de transcription à réaliser en regroupant au mieux les caractères qui se ressemblent.

Partant du constat que lorsque l’humain fait la transcription, il « donne la solution » à la machine, on peut établir une liste d’images qu’il fallait reconnaître, et de caractères transcrits associés, certifiés exacts par l’humain. En donnant cela à un algorithme de classification supervisée, d’une part il peut apprendre les différents caractères, et d’autre part il pourra proposer lui-même une transcription.

On dispose alors de deux processus :
1. L’humain transcrit à la main, ce qui permet de constituer une base de connaissance : telle image se transcrit en “…” et de produire des groupes d’images qui attendent une transcription.
2. La machine peut apprendre les transcriptions réalisées, et proposer les transcriptions des groupes en attente.

L’humain a, à tout moment, la possibilité de corriger une proposition de la machine ; celle-ci est d’ailleurs colorée en fonction d’un score de confiance (plus c’est vert et a priori plus la machine est certaine du résultat, plus c’est rouge et plus la machine a besoin de la validation de l’utilisateur). L’architecture retenue est distribuée, sous la forme d’une application web :

• la partie serveur stocke les données (textes, images, base de données…) et construit à la demande les pages affichées, en python
• la partie cliente affiche l’interface graphique et permet de voir les pages, de transcrire directement sur le texte, de corriger une proposition, de valider une page… (HTML, CSS, Javacript, Ajax…)

Le logiciel a déjà été étudié, et en partie modélisé, d’un point de vue fonctionnel et graphique. Une première réalisation a été tentée, en python/Qt, mais l’interface graphique s’est révélée complexe à réaliser. Une expérimentation a été faite en HTML/CSS, et en très peu de temps, et de lignes de code, l’interface a pris forme. La difficulté réside maintenant dans l’échange entre client et serveur : génération du code de la page en python, d’après des données d’entrée (un fichier XML actuellement, mais une BD est à l’étude, l’inconnue est la charge que cela représente pour la BD), mise à jour, coté client en Javascript (ou serveur en Ajax) des clusters lors de la transcription ou de la classification, gestion des corrections…

Actuellement, les images sont stockées sur le serveur http. Il est nécessaire que cela évolue vers le traitement d’images pointées par des URL situées en dehors du serveur http :

• Prise en compte de drives réseau (images en cloud)
• Pris en compte de IIIF, l’image est accessible via une URL et délivrée à la demande, l’URL précisant la forme du résultat (le serveur à qui on demande l’image est paramétré par l’URL pour découper, redimensionner, tourner, etc. l’image avant de l’envoyer).

Un exemple d’interface en cours de développement est donné en figure 1.

Poursuite des développements 2022 : application & IHM

Travail à réaliser

• Réétudier les scénarios de fonctionnement, d’après les informations qui seront transmises
• Redéfinir l’architecture de l’application, en mode web, en tenant compte du fait que les images seront référencées sous la forme d’URL qui peuvent être en dehors du périmètre du site
• S’inspirer / reprendre le code de la maquette actuelle et développer le logiciel pour les scénarios (par ordre de priorité) :
  • importation d’un ouvrage à transcrire (on travaillera sur un ouvrage de Montaigne – Les Essais – daté de 1580 et faisant 500 pages env.),
    • transcription de l’ouvrage par l’homme (donc basé clustering) coté client, et récupération des résultats coté serveur de façon à ce que l’ensemble du processus reste cohérent.
    • Recherche et consultation : un utilisateur accède à une partie du site « en lecture », et peut effectuer une recherche plein texte : il donne un ou plusieurs mots, la machine ressort l’ensemble des références aux pages contenant ces mots (classées par date, puis auteur, puis ouvrage puis n° de page, et permet de les consulter (le ou les mots trouvés étant idéalement surlignés sur l’image d’origine de l’ouvrage)

Points importants

• modélisation disponible (UML) et correcte
• code python et javascript documenté
• travail sous Git
• réfléchir aux aspects sécurité d’une application ouverte de ce type, car il est envisageable d’ouvrir l’application sur une communauté de chercheurs pour faire la transcription
• les algorithmes plus complexes (clustering, classification d’images…) seront donnés ; le travail se limite à la modélisation, la réalisation du logiciel incluant la réutilisation de code extérieur (algorithmes donnés, librairies python, framework web, etc.)

Point complémentaire

Un ouvrage à transcrire arrive sous la forme d’un fichier ALTO (Analysed Layout and Text Object, XML conçu pour représenter des documents numériques interopérables entre bibliothèques, format proposé par la Bibliothèque du Congrès aux USA). Les ouvrages à importer sont traités par un logiciel qui utilise une très vieille version d’ALTO. Ce qui pose question quand à la pérennité de ce support. On envisage de remplacer cela par une base de données relationnelle, et la possibilité de produire le fichier ALTO à la demande. Il faut alors proposer cette base de données (schéma, implémentation) et évaluer la charge serveur que représente son utilisation.

Thierry Brouard (MCF, LIFAT-RFAI, Tours)
Avec la collaboration pour le CESR-BVH de :
Rémi Jimenes, Toshinori Uetani, Sandrine Breuil

---

---