OCR et document AI

Pourquoi l'OCR classique ne suffit plus

Pendant longtemps, « faire de l'OCR » a signifié une seule chose : transformerTransformerIAArchitecture introduite en 2017, fondée sur le mécanisme d'attention, qui traite une séquence entière en parallèle. Elle sert de base à tous les grands modèles de langage actuels.Voir dans le glossaire une image de texte en chaîne de caractères. C'est un problème largement résolu depuis les années 2000 pour du texte imprimé propre, en une seule police, sur fond blanc. Le problème réel que rencontrent les équipes qui traitent factures, contrats, formulaires ou pièces d'identité n'a presque plus rien à voir avec ce cas d'école.

Un document professionnel n'est pas un paragraphe de texte : c'est une mise en page. Une facture combine un en-tête, un tableau de lignes produits, un bloc de totaux, des mentions légales et parfois un tampon manuscrit. Extraire ce document exige de répondre à deux questions distinctes, la seconde étant presque toujours la plus difficile :

1. Que dit chaque caractère, chaque mot ? (reconnaissance)
2. À quoi appartient chaque mot — quel champ, quelle ligne de tableau ? (structure)

Un moteur qui répond parfaitement à la première question et ignore la seconde produit un résultat inutilisable : une liste de mots dans le désordre, sans savoir que « 42,90 » est le prix unitaire de la troisième ligne de commande plutôt qu'un numéro de TVA. C'est cette bascule — de la reconnaissance de caractères vers la compréhension de documents — que recouvre l'expression Document AI.

« OCR » désigne historiquement la seule étape de reconnaissance de caractères. « Document AI » (ou « IDP », Intelligent Document Processing) désigne le pipeline complet incluant layout, extraction et validation. Les deux termes se recouvrent de plus en plus dans l'usage professionnel.

Anatomie d'un pipeline moderne

Un système d'extraction documentaire en production s'organise en six étapes successives, chacune pouvant faire chuter la qualité de tout ce qui suit.

1. Prétraitement. L'image est nettoyée : redressement si le scan est de travers, débruitage, binarisation pour les moteurs classiques, normalisation du contraste pour les modèles récents qui travaillent directement sur l'image couleur. Un scan à faible résolution ou une photo prise avec un angle prononcé dégrade toutes les étapes suivantes, quelle que soit la qualité du modèle en aval.

2. Détection de layout. Cette étape segmente la page en régions : blocs de texte, tableaux, en-têtes, colonnes, zones de signature, cases à cocher. C'est l'étape la plus sous-estimée par les équipes qui découvrent l'OCR, et pourtant c'est souvent elle qui détermine si le projet réussit ou échoue.

3. Reconnaissance de caractères. Chaque région de texte identifiée est convertie en caractères. Les moteurs modernes produisent, en plus du texte, un score de confiance par mot — une information indispensable pour la suite.

4. Extraction structurée. Le texte brut est relié aux champs métier attendus : numéro de facture, date d'échéance, SIRET, montant TTC. Sur un tableau, chaque cellule doit être rattachée à sa ligne et sa colonne — un exercice délicat dès que le tableau contient des cellules fusionnées ou des lignes qui débordent sur deux pages.

5. Validation. Les valeurs extraites sont confrontées à des règles métier (un SIRET fait 14 chiffres, un TTC doit être cohérent avec HT + TVA) et à des seuils de confiance. C'est le filet de sécurité du pipeline.

6. Sortie et boucle de correction. Les documents qui passent la validation produisent une donnée structurée exploitable (JSON, écriture en base ou dans un ERP). Ceux qui échouent sont routés vers une correction humaine, dont les retours peuvent être réinjectés pour améliorer les modèles.

La qualité d'un système d'extraction se mesure au maillon le plus faible, pas à la moyenne. Un OCR excellent avec un layout mal détecté produit un résultat inexploitable ; un layout parfait avec une validation absente produit un résultat dangereux, parce qu'il paraît fiable sans l'être.

Layout analysis : comprendre la page avant de la lire

La détection de layout doit gérer une variabilité considérable :

• Documents multi-colonnes — lus ligne par ligne sans détection de colonnes, ils mélangent le texte de gauche et de droite.
• Tableaux sans bordures visibles — de nombreux formulaires alignent des colonnes par simple espacement ; le moteur doit inférer la structure depuis l'alignement du texte.
• Champs de formulaire — cases à cocher, zones de signature : leur présence ou absence est une information à extraire, pas un texte à lire.
• Documents multi-pages — une commande de 40 lignes peut s'étaler sur trois pages ; le layout doit reconstituer un seul tableau logique.

Deux familles de méthodes coexistent. Les approches géométriques analysent la disposition des pixels et du texte sans comprendre le contenu — rapides et robustes sur des formats stables, fragiles dès que la mise en page varie. Les approches par apprentissage, entraînées sur des milliers de documents annotés, généralisent mieux à des mises en page inédites, au prix d'un besoin de donnéesdonnéesIAEnsemble d'informations structurées ou non utilisées pour entraîner, évaluer ou alimenter un modèle. La qualité, la quantité et la représentativité des données sont les facteurs décisifs pour les performances en apprentissage automatique.Voir dans le glossaire représentatives du domaine réel.

Si votre système se trompe systématiquement sur les mêmes types de documents, le problème est presque toujours situé dans la détection de layout, pas dans l'OCR. Isolez les deux étapes : relisez la sortie brute de l'OCR seule avant d'accuser l'extraction.

Extraction structurée : au-delà du texte brut

Une fois le texte localisé et lu, il faut le relier à un schéma de données métier. Deux approches se combinent souvent.

Extraction clé-valeur. Le système repère des paires du type « Numéro de facture : FR-2026-00891 » en s'appuyant sur des libellés connus. Efficace pour les champs isolés, elle suppose un libellé explicite à proximité de la valeur — ce qui n'est pas toujours le cas.

Extraction par entités appliquée aux documents. Le système classe chaque segment de texte selon une catégorie (montant, date, adresse) indépendamment d'un libellé, en s'appuyant sur le contextefenêtre de contexteIAQuantité de texte qu'un modèle peut prendre en compte simultanément : question, documents fournis et historique. Au-delà, les éléments les plus anciens sortent du champ.Voir dans le glossaire visuel. Plus robuste sur des formats hétérogènes, elle demande davantage de données d'entraînement.

Pour les tableaux, l'extraction doit reconstituer une grille logique : associer chaque valeur à une ligne et une colonne. Les erreurs les plus fréquentes proviennent de cellules fusionnées, de lignes vides insérées pour la lisibilité mais absentes du schéma logique, et de totaux qui se glissent dans le flux du tableau.

Une facture affiche, pour chaque ligne produit, un prix unitaire, une remise en pourcentage et un prix net. Un système naïf, entraîné sur des factures sans remise, associe souvent la colonne « remise » à la colonne « prix net » voisine, les deux étant des valeurs numériques proches en position. Résultat : le prix net enregistré est en réalité le taux de remise. Cette erreur ne se voit pas à l'œil sur un échantillon rapide — elle nécessite une règle de validation dédiée (le prix net doit être inférieur ou égal au prix unitaire).

Architectures : de Tesseract aux modèles document-natifs

OCR classique (Tesseract et dérivés). Pipeline en étapes séparées : segmentationChunkingIADécoupage d'un document en segments de taille fixe ou sémantique avant indexation vectorielle, pour optimiser la récupération RAG.Voir dans le glossaire, classification par réseau convolutifCNNIARéseau de neurones convolutif, architecture dominante en vision par ordinateur pour détecter des motifs locaux dans les images.Voir dans le glossaire ou récurrent, correction par dictionnaire. Robuste sur du texte imprimé propre, faible sur les mises en page complexes car il ne « voit » pas la structure globale de la page.

CRNN + CTC. Combinaison d'un réseau convolutifréseau convolutifIAArchitecture conçue pour les images, qui fait glisser des filtres appris détectant des motifs locaux, puis les combine en motifs de plus en plus abstraits.Voir dans le glossaire et d'un réseau récurrent, entraînée avec une fonction de perte qui tolère un alignement imparfait entre image et texte cible. Nette amélioration sur l'écriture cursive, toujours limité en compréhension de mise en page.

Modèles document-natifs (LayoutLM, Donut, équivalents). Ces architectures traitent conjointement le texte, sa position sur la page et parfois l'image elle-même, dans un seul modèle. Elles apprennent la relation entre position spatiale et rôle sémantique — un montant en bas à droite d'un tableau a statistiquement plus de chances d'être un total qu'un prix unitaire. Certaines se passent même d'une étape d'OCR explicite (approche dite OCR-free).

Modèles multimodaux généralistes. Les modèles de vision-langage récents traitent une image de document et produisent une extraction structurée sans pipeline dédié. Flexibles — pas besoin de réentraîner un modèle par type de document — mais moins prévisibles sur des tâches à fort volume et fortement contraintes, où un modèle spécialisé et ses règles de validation gardent un avantage en coût et en fiabilité mesurable.

Validation : le maillon qui décide si vous pouvez faire confiance

Un système d'extraction qui ne produit jamais d'erreur n'existe pas. La question n'est pas « comment atteindre 100 % de précisionprécisionIAProportion des alertes émises par un modèle qui sont justifiées. Elle s'oppose au rappel : améliorer l'une dégrade l'autre.Voir dans le glossaire » mais « comment détecter les erreurs avant qu'elles n'atteignent un système en aval ».

Trois familles de contrôles se complètent :

• Seuils de confiance — en dessous d'un seuil calibré sur votre propre jeu de documents, le champ est marqué à vérifier plutôt qu'accepté silencieusement.
• Règles métier — cohérence arithmétique (HT + TVA = TTC), formats attendus (structure d'un IBAN), plages plausibles (une date de naissance ne peut pas être dans le futur).
• Contrôles croisés — comparaison avec une source de vérité externe : un SIRET vérifié contre un registre d'entreprises, un montant contre un bon de commande déjà en base.

Un modèle peut afficher un score de confiance élevé sur une valeur erronée, en particulier lorsque l'erreur provient du layout plutôt que de la reconnaissance : le moteur a lu correctement « 1 200,00 », mais l'a associé à la mauvaise colonne. Le score porte sur la lecture du caractère, pas sur la justesse de l'association structurelle. Ne confondez jamais confiance de reconnaissance et confiance d'extraction — ce sont deux mesures distinctes, rarement calculées par le même composant.

La correction humaine (human-in-the-loopHuman-in-the-loopIABoucle où un opérateur humain valide, corrige ou arbitre les décisions du système IA avant une action irréversible.Voir dans le glossaire) reste, pour tout document à enjeu financier ou juridique, un composant à part entière du pipeline, pas un correctif temporaire en attendant un modèle « suffisamment bon ». Un système bien conçu route automatiquement vers un opérateur les documents à confiance basse ou en échec de règle métier, et laisse passer directement le reste — l'objectif n'est pas de faire disparaître l'humain, mais de concentrer son temps sur les cas réellement ambigus.

Pièges fréquents et contre-exemples

Scans de mauvaise qualité. Photocopie de photocopie, fax reçu par e-mail, photo avec reflet sur le papier : ces documents dégradent la reconnaissance avant même que le modèle n'entre en jeu. Aucun modèle ne restitue une information physiquement perdue à la capture.

Écriture manuscrite. Les moteurs actuels traitent le manuscrit avec une fiabilité nettement inférieure à l'imprimé, en particulier sur des chiffres ambigus (le 1 et le 7 européens, le 0 et le O). Une signature est généralement traitée comme une zone présente/absente, pas comme un texte à décoder.

Tableaux avec cellules fusionnées ou lignes multi-niveaux. Un tableau avec des sous-totaux par catégorie brise l'hypothèse d'une grille régulière ligne × colonne sur laquelle s'appuient beaucoup de moteurs.

Documents multilingues sur la même page. Un contrat bilingue, ou une facture internationale mêlant deux jeux de caractères, dégrade les moteurs calibrés sur une langue unique — la détection de langue doit parfois s'opérer par zone de page.

Faux positifs silencieux. Le piège le plus coûteux en production n'est pas l'échec visible mais l'échec silencieux : une valeur plausible mais fausse, acceptée sans alerte parce qu'elle respecte le format attendu. Un montant de « 1 000,00 € » extrait à la place de « 10 000,00 € » (un zéro manqué) passe souvent tous les contrôles de format tout en étant une erreur d'un ordre de grandeur. N'évaluez jamais un système sur l'échantillon de démonstration d'un fournisseur : un taux de 99 % annoncé sur des documents propres ne garantit rien sur votre flux réel, qui contient des scans dégradés que la démonstration n'inclut jamais.

Cas d'usage et checklist de déploiement

Les déploiements les plus courants concernent les factures fournisseurs, les formulaires KYC, les contrats, les documents d'identité et les bons de commande. Chacun a un profil de risque différent : une erreur sur un montant de facture a un impact financier direct ; une erreur sur un champ KYC peut avoir un impact réglementaire.

Avant tout déploiement, une grille de questions permet d'éviter la majorité des déconvenues :

• Le jeu de testjeu de testIAPartie des données réservée à l'évaluation finale, à n'utiliser qu'une seule fois. Ajuster le modèle d'après ses résultats sur ce jeu lui ôte toute valeur de mesure indépendante.Voir dans le glossaire couvre-t-il la variabilité réelle des documents reçus (qualité de scan, mises en page, langues), pas seulement des exemples propres ?
• Chaque champ dispose-t-il d'un score de confiance distinct entre reconnaissance et extraction structurelle ?
• Des règles métier de cohérence sont-elles appliquées automatiquement avant tout enregistrement en base ?
• Existe-t-il un chemin de correction humaine dimensionné pour le volume réel ?
• Les corrections humaines sont-elles capturées pour améliorer le système, ou perdues à chaque cycle ?
• Le coût par document a-t-il été mesuré sur le volume de production, pas seulement sur un prototype ?

Il est préférable de déployer un système sur un seul type de document à fort volume et de mesurer précisément son taux d'erreur réel sur plusieurs semaines, plutôt que de viser d'emblée une couverture large et mal mesurée. La confiance dans un pipeline documentaire se construit document par document.

La reconnaissance de caractères a cessé d'être le goulot d'étranglement des projets d'extraction documentaire depuis plusieurs années. Ce qui distingue un système fiable d'un système fragile se joue dans la détection de layout, l'extraction structurée et, surtout, dans la rigueur de la couche de validation qui décide ce qui peut être automatisé en confiance et ce qui doit repasser par un regard humain.