Comment choisir le bon format de fichier pour la reconnaissance de texte manuscrit (HTR)

Dernière mise à jour : 20 août 2026

Formats de fichiers OCR pour les documents historiques et manuscrits

La préservation du patrimoine culturel par la numérisation connaît une renaissance. Alors que les premiers systèmes de reconnaissance optique de caractères (OCR) étaient conçus pour analyser des documents impeccables, imprimés mécaniquement au XXe siècle, les institutions modernes du patrimoine culturel sont confrontées à un défi bien plus complexe et riche : manuscrits médiévaux, correspondance cursive du XIXe siècle, feuillets enluminés fragiles et registres centenaires.

La transcription de documents historiques ne consiste plus seulement à extraire du texte ASCII brut. Elle nécessite la capture du context—la géométrie physique de la page, les courbes de ligne de base, les corrections de transpercement, les marginalia, les abréviations et l’incertitude paléographique. Ce domaine spécialisé, souvent classé sous la Reconnaissance de Texte Manuscrit (HTR), dépend fortement du format de fichier utilisé pour stocker et échanger à la fois les coordonnées d’image et les couches textuelles.

Choisir le mauvais schéma peut supprimer des données de ligne de base essentielles, rompre l’alignement avec les manifestes IIIF (International Image Interoperability Framework) ou empêcher la préservation numérique à long terme. Voici un guide définitif des principaux formats de fichiers OCR et HTR pour les documents historiques, leurs points forts structurels, et comment déterminer le bon choix pour votre chaîne d’archivage.

Le dilemme historique : pourquoi le Texte brut et les PDF standards échouent

L’OCR imprimé par machine génère souvent de simples fichiers .txt ou des PDF “sandwich” avec des calques de texte cachés sous le scan. Pour les manuscrits historiques et l’écriture cursive, ces sorties échouent pour trois raisons principales :

1. Texte non linéaire et mises en page complexes : Les scribes historiques ne respectaient pas des grilles rectangulaires nettes. Le texte s’écoule dans les marges, s’enroule autour des initiales enluminées, se tisse entre les corrections interlinéaires insérées, ou s’étend verticalement le long du dos.
2. Lignes de base courbées et inclinées : L’écriture cursive suit rarement un axe horizontal rigide. Les moteurs HTR comme Transkribus, Kraken et eScriptorium s’appuient sur des lignes de base polyline plutôt que sur des boîtes englobantes pour interpréter les scripts riches en ligatures.
3. Complexité paléographique et métadonnées : La recherche archivistique nécessite le suivi des abréviations, des variations orthographiques historiques, des lectures endommagées et des scores de confiance au niveau des lignes. Les formats de documents standard éliminent cette granularité.

Pour maintenir la fidélité à l’objet original, la communauté archivistique s’appuie sur des schémas XML structurés conçus pour préserver la topologie de la mise en page ainsi que le texte transcrit.

1. PAGE XML : la référence d’or pour la reconnaissance de texte manuscrit (HTR)

Développé par le laboratoire de recherche PRImA (Pattern Recognition & Image Analysis), PAGE XML (Page Analysis and Groundtruth Elements) est largement considéré comme le format de pointe pour la reconnaissance de texte manuscrit et l’analyse avancée de la mise en page.

Architecture de base

PAGE XML traite le document physique comme une structure hiérarchique :

• PcGts (Racine)
  • Page (Dimensions de l’image et ordre de lecture global)
    • TextRegion (Paragraphes, titres, notes marginales, mots de tête)
      • TextLine
        • Coords (Coordonnées polygonales autour de la ligne)
        • Baseline (Une série de points suivant la vraie ligne de base de l’écriture)
        • TextEquiv (Le texte reconnu, avec des métriques de confiance optionnelles)

Pourquoi il excelle pour les manuscrits historiques

• Précision des polygones et des polylignes : Au lieu de forcer les caractères dans des boîtes englobantes rectangulaires, PAGE XML utilise des limites polygonales à points multiples et des lignes de base continues. Cela empêche les ascendantes et descendantes cursives qui se chevauchent d’interférer avec la segmentation.
• Types structurels granulaires : Les régions peuvent être classées précisément (par ex., marginalia, drop-capital, signature-mark, header, editorial-note).
• Écosystème logiciel étendu : Il sert de schéma interne et d’exportation principal pour les plateformes HTR phares telles que Transkribus, eScriptorium et Kraken.

2. ALTO XML : la référence des bibliothèques et des archives

ALTO (Analyzed Layout and Text Object) est une norme XML ouverte maintenue par la Library of Congress et largement adoptée par les bibliothèques nationales, y compris la Bibliothèque nationale de France (BnF) et la British Library.

Architecture de base

ALTO structure la mise en page de manière hiérarchique de Page à PrintSpace, puis TextBlock, TextLine et String (mots ou jetons individuels). Il est fréquemment emballé dans un wrapper METS (Metadata Encoding and Transmission Standard) pour associer les métadonnées structurelles aux images maîtresses haute résolution.

Principaux atouts et cas d’utilisation

• Flux de numérisation massive : ALTO a été conçu en pensant à la numérisation industrielle de journaux et de livres. Il encode proprement les attributs de police, les coordonnées au niveau des mots, la confiance des caractères et les espaces blancs.
• Support HTR moderne (ALTO 4) : Les versions antérieures d’ALTO s’appuyaient fortement sur des coordonnées rectangulaires (HPOS, VPOS, WIDTH, HEIGHT). Cependant, à partir de la version 4 d’ALTO, le schéma a introduit des polygones <Shape> et des lignes de base en polylignes, comblant le fossé fonctionnel avec PAGE XML pour les documents manuscrits.
• Préservation à long terme : Parce qu’il s’agit d’une norme officielle soutenue par des consortiums de bibliothèques internationaux, ALTO garantit une stabilité à long terme et une compatibilité descendante de niveau archivistique.

3. hOCR : la norme légère, d’abord Web

Créé par Thomas Breuel, hOCR adopte une approche pragmatique : plutôt que de créer un tout nouveau schéma XML, il intègre les métadonnées de mise en page et de transcription directement dans le HTML/XHTML sémantique en utilisant des microformats et des attributs de classe.

Exemple de syntaxe typique

<div class="ocr_page" id="page_1" title="bbox 0 0 2480 3508">
  <div class="ocr_carea" id="block_1_1">
    <p class="ocr_par" id="par_1_1">
      <span class=\"ocr_line\" id=\"line_1_1\" title=\"bbox 150 320 2200 410; baseline 0 -5\">\n        <span class=\"ocrx_word\" id=\"word_1_1\" title=\"bbox 150 325 380 405; x_wconf 92\">Incipit</span>\n      </span>
    </p>
  </div>
</div>

Avantages et inconvénients des matériaux historiques

• Avantages : Les navigateurs peuvent le rendre nativement. Il est facilement transformé à l’aide de CSS et JavaScript purs, et c’est le format d’exportation structuré par défaut pour les moteurs comme Tesseract.
• Inconvénients : Le support natif des courbes de ligne de base complexes et libres à plusieurs points est limité. Bien qu’il soit pratique pour les ouvrages imprimés anciens (incunables ou grands formats propres), hOCR a du mal avec les mises en page manuscrites erratiques et les marginalia à plusieurs couches.

4. TEI-XML : la référence académique et des humanités numériques

Le format Text Encoding Initiative (TEI) n’est pas strictement un format de sortie d’un moteur OCR ; il s’agit plutôt de la norme principale pour les éditions numériques critiques et la représentation savante des textes littéraires et historiques.

Connexion de l’OCR/HTR à TEI

Les pipelines modernes s’arrêtent rarement à la reconnaissance brute de caractères. Les chercheurs utilisent des outils tels que le Transkribus TEI Exporter ou des pipelines XSLT automatisés pour convertir les fichiers PAGE XML ou ALTO en XML conforme à TEI :

• Les abréviations sont développées (<choice><abbr>...</abbr><expan>...</expan></choice>).
• Les suppressions, ajouts et mains d’écriture sont classés formellement (<add>, <del>, <handShift>).
• Les données de mise en page sont conservées parallèlement à l’analyse littéraire via les éléments <facsimile> et <surface>.

Si votre projet historique vise à créer une édition critique interactive ou une archive savante consultable sémantiquement, la conversion de vos données OCR/HTR en TEI-XML est souvent l’étape finale requise.

Matrice comparative : formats OCR/HTR en un coup d’œil

Recommandations pratiques : choisir votre chaîne d’archivage

Pour mettre en place un pipeline de numérisation efficace et pérenne :

1. Pour les manuscrits entièrement manuscrits et les archives : Standardisez votre transcription et l’extraction de mise en page sur PAGE XML. Son calcul de ligne de base et le contournement polygonal gèrent les écritures non standard avec une perte de données minimale.
2. Pour les bibliothèques à grande échelle et les collections mixtes : Choisissez ALTO XML (v4.2 ou supérieur) associé à METS. Cela garantit une intégration fluide dans les architectures de dépôts numériques standard et les systèmes de gestion d’actifs numériques (DAMS).
3. Pour la présentation Web et les index de recherche en texte intégral : Utilisez hOCR ou dérivez des structures légères GeoJSON/Annotation Web à partir de PAGE XML pour alimenter les visualiseurs IIIF interactifs (comme Mirador ou Universal Viewer) avec des superpositions de texte en direct dans le navigateur.
4. Pour les éditions savantes & la recherche paléographique : Générez votre vérité de référence en PAGE XML, effectuez la reconnaissance, et canalisez la sortie à travers un convertisseur automatisé pour générer TEI-XML pour le balisage éditorial.

En adaptant les capacités structurelles de ces formats aux exigences paléographiques de votre matériel source, vous garantissez que chaque trait, abréviation et nuance historique restent déchiffrables pendant des siècles.

Foire aux questions (FAQ)

Q1. Quelle est la différence fondamentale entre l’OCR standard et le HTR ? L’OCR reconnaît une typographie imprimée par machine constante, tandis que le HTR (Handwritten Text Recognition) utilise des réseaux neuronaux profonds pour décoder l’écriture manuscrite humaine continue et variable ainsi que les lignes de base courbées.

Q2. Tesseract OCR peut-il produire du PAGE XML ou du format ALTO pour les documents historiques ? Oui, Tesseract peut générer du XML ALTO natif et du format hOCR, et des wrappers tiers peuvent convertir ces résultats en PAGE XML.

Q3. Pourquoi les lignes de base sont-elles plus importantes que les boîtes englobantes dans la transcription de texte manuscrit ? Les lignes de base suivent la trajectoire naturelle et ondulée de l’écriture humaine, permettant au logiciel de séparer les ascendantes et descendantes qui se chevauchent et qui se heurtent à l’intérieur de boîtes englobantes rigides.

Q4. Comment la norme IIIF interagit‑elle avec ces formats de fichiers OCR ? IIIF fournit des images haute résolution via des API web ouvertes, tandis que des formats comme ALTO ou PAGE XML offrent des données de coordonnées qui peuvent être converties en annotations de recherche de contenu IIIF.

Q5. Quel format de fichier est le plus facile à convertir directement en PDF consultable ? Le hOCR et le XML ALTO peuvent être associés aux images de page originales pour créer des fichiers PDF à double couche consultables à l’aide d’outils comme OCRmyPDF.

Voir aussi

• PDF/A-3 - Le monstre hybride ? Intégrer les données originales dans votre OCR
• Comprendre les formats de fichiers OCR - HOCR vs ALTO vs PDF/A expliqué
• Quelle est la différence entre PDF et FDF ?
• À quoi sert le FDF ? Comprendre le but du format de données de formulaires
• PDF vs Word : lequel devez‑vous utiliser et quand ?