Document AI en assurance : articuler OCR, mise en page, extraction et contrôle humain

Ce qu’il faut retenir

• Un système Document AI robuste ne transforme pas un PDF en vérité structurée. Il conserve le fichier source, reconnaît les signes, reconstruit la mise en page, extrait des champs puis vérifie chaque usage selon son risque.
• OCR, analyse de mise en page et extraction répondent à trois questions différentes : « quels signes sont visibles ? », « comment sont-ils organisés ? » et « quelle donnée métier peut-on proposer ? ».
• Chaque valeur exploitable doit pointer vers une page et une zone du document. Un score sans provenance visuelle rend la correction lente et l’audit fragile.
• Le contrôle humain est une voie conçue, avec motifs, priorité et interface de preuve. Demander à une personne de relire systématiquement tout le document ne constitue pas une supervision efficace.
• La recette se fait par type de pièce, qualité, fournisseur, langue et champ critique. Un taux OCR global ne permet pas de décider si une chaîne peut alimenter un dossier d’assurance.

Traiter le document comme un objet de preuve, pas comme un simple texte

Une attestation, un relevé, un constat ou un courrier n’est pas seulement une suite de caractères. La position d’une valeur, son libellé, la page, un tableau, une case cochée, une annotation manuscrite et la version du formulaire peuvent modifier son sens. Une extraction qui perd ces relations produit parfois un texte plausible mais inutilisable.

La chaîne Document AI doit donc maintenir deux objets. Le premier est la pièce reçue, conservée selon les règles applicables au dossier. Le second est une représentation dérivée : pages, blocs, mots, coordonnées, relations, champs proposés, règles appliquées et corrections. Une donnée dérivée ne remplace jamais silencieusement le document source.

L’objectif métier est défini avant le choix du moteur. « Lire les documents » est trop large. Une fonction exploitable peut être : détecter le type de pièce, repérer une période, extraire trois champs, comparer une référence, signaler une page manquante ou préparer l’écran d’un gestionnaire. Chaque fonction possède une autorité, des champs interdits et une issue d’abstention.

Préserver le fichier dès l’acquisition

Les erreurs commencent souvent avant l’OCR : document incomplet, pages dans le désordre, photo recadrée, double compression, orientation incorrecte, fichier protégé ou pièce associée au mauvais dossier. L’acquisition valide le format, le nombre de pages, la taille, l’intégrité, l’orientation et la présence d’un contenu exploitable. Elle ne tente pas de réparer silencieusement une pièce ambiguë.

Le système calcule une empreinte du fichier pour détecter les doublons sans comparer les seuls noms. Il conserve le MIME réellement observé, la date de réception et le canal. Toute conversion vers une image ou un PDF normalisé produit un dérivé lié à la source, avec version du convertisseur. Les pages originales ne sont pas écrasées.

Contrôle d’entrée	Sortie attendue	État d’échec
Format et intégrité	type réel, taille, empreinte	fichier illisible ou non autorisé
Composition	pages, ordre et éventuels sous-documents	page absente ou séquence incertaine
Lisibilité	résolution, flou, contraste et orientation	nouvelle capture nécessaire
Rattachement	dossier et rôle documentaire proposés	identité ou dossier non résolu
Droits	politique de traitement et de conservation	traitement automatique interdit

Une pièce peut contenir du texte adressé au lecteur, y compris des instructions. Ce contenu reste une donnée. Il ne peut ni changer les droits du système, ni provoquer un appel d’outil, ni élargir la recherche documentaire. La séparation entre données, instructions et règles est indispensable lorsque des modèles génératifs ou multimodaux interviennent.

Produire une couche OCR vérifiable

L’OCR propose les signes visibles : caractères, mots et lignes. Une bonne sortie conserve le texte, ses coordonnées, la page, l’ordre local et, lorsque le moteur l’expose, une confiance. Elle ne décide pas encore que « 12/08/2026 » est une date d’effet ni que « 1 250 » est un montant.

La reconnaissance doit être évaluée sur le corpus réel. Polices fines, cachets, scans inclinés, photocopies, tableaux serrés, caractères voisins, manuscrit et images de téléphone créent des erreurs différentes. Le taux moyen de caractères peut rester bon alors qu’un identifiant, une date ou une décimale critique est mal lu.

Les traitements déterministes précédant l’OCR sont versionnés : rotation, correction de perspective, découpage, réduction du bruit et choix de résolution. Une amélioration visuelle pour une personne peut détruire un signe utile au moteur. Il faut donc comparer chaque transformation sur un jeu indépendant et conserver l’original.

Sortie OCR	Usage autorisé	Usage prématuré
mot et zone	afficher, rechercher, relier à une correction	prendre une décision métier
ligne et ordre local	reconstruire une lecture possible	supposer le rôle du bloc
confiance moteur	prioriser un contrôle après calibration locale	lire « 0,95 » comme 95 % de vérité
langue détectée	choisir une chaîne compatible	inventer une traduction

Les API de Document Intelligence, Textract ou Document AI exposent des objets de page, des coordonnées et des scores. Cette richesse est utile précisément parce qu’elle permet de revenir au visuel. Elle ne dispense pas d’une évaluation propre au portefeuille documentaire.

Reconstruire la mise en page sans inventer l’ordre de lecture

La mise en page répond à une autre question : quels éléments sont des titres, paragraphes, tableaux, cellules, cases ou pieds de page, et comment se relient-ils ? Un texte OCR exact peut être interprété de travers si deux colonnes sont fusionnées, si un libellé est associé à la mauvaise valeur ou si une note de bas de page rejoint le corps.

Les modèles de document tels que LayoutLM ont précisément étudié l’association entre texte et disposition bidimensionnelle. Le papier primaire montre des gains sur ses jeux de formulaires, reçus, classification et autres tâches. Il ne démontre pas qu’un modèle général reconnaît sans recette un formulaire d’assurance français, une version historique ou un document dégradé.

La sortie de layout conserve les relations et leur origine : cellule située dans telle ligne et colonne, valeur proche d’un libellé, paragraphe rattaché à un titre, case sélectionnée à telle position. Lorsqu’un ordre de lecture est incertain, le système garde plusieurs hypothèses ou escalade ; il ne concatène pas arbitrairement les blocs.

L’article sur l’évaluation des modèles multimodaux détaille pourquoi texte, image et document ne se valident pas avec une seule note. Ici, la distinction est opérationnelle : une cellule correctement reconnue mais rattachée à la mauvaise colonne constitue une erreur de layout, pas une erreur OCR.

Extraire des champs avec leur provenance

L’extraction transforme des éléments documentaires en propositions métier. Le schéma est défini avant le modèle : nom, type, cardinalité, unités, valeurs autorisées, caractère obligatoire, règles de normalisation et comportement en cas d’absence. Une chaîne robuste distingue « absent », « illisible », « ambigu » et « non applicable ».

Chaque champ retourne sa valeur brute et sa valeur normalisée. Pour une date, la chaîne conserve le texte « 03/04/26 », la page et la zone, puis indique la normalisation proposée et la convention utilisée. Si l’ordre jour/mois n’est pas démontrable, elle n’invente pas. Pour une somme, elle garde devise, séparateur, signe, emplacement et libellé associé.

La provenance peut prendre la forme d’un ou plusieurs ancrages visuels. Un champ calculé cite aussi les champs sources et la règle. Un champ dérivé par un modèle génératif reste marqué comme tel. La personne qui corrige doit pouvoir voir la zone exacte sans rechercher la valeur dans vingt pages.

Type de champ	Preuve minimale	Contrôle déterministe
Identifiant	texte brut et zone	format, checksum ou correspondance autorisée
Date	expression, libellé et page	format, ordre, plage et cohérence entre dates
Montant	valeur, devise, signe et cellule	type numérique, sommes et unité
Case ou choix	symbole, état et libellé voisin	cardinalité et options permises
Texte libre	passage et limites	longueur, présence et contenu interdit
Champ calculé	entrées et version de règle	recalcul indépendant

Un grand modèle peut aider à associer un libellé variable à un champ ou à proposer une normalisation. Il ne doit pas recevoir le droit implicite de compléter ce qui manque. Les sorties ouvertes sont contraintes par un schéma puis contrôlées. Les opérations exactes restent dans des règles, conformément au découpage des responsabilités entre déterministe, probabiliste et génératif.

Valider par règles et rapprochements, sans transformer une incohérence en correction silencieuse

La validation vérifie la forme, la cohérence interne et, lorsque les droits l’autorisent, la cohérence avec le dossier. Elle ne modifie pas automatiquement la source pour faire disparaître un conflit. Deux dates différentes entre une attestation et une saisie deviennent une contradiction à traiter, avec les deux provenances.

Les règles se répartissent en trois groupes. Les règles syntaxiques contrôlent format, longueur et unité. Les règles documentaires comparent les champs d’une même pièce : total et lignes, période de début et de fin, case et libellé. Les règles dossier rapprochent des objets autorisés : identité, référence, produit ou période. Chaque règle possède une version et une conséquence.

Une faible confiance n’est pas le seul motif de revue. Une valeur très confiante peut violer une règle, provenir de la mauvaise page ou contredire une autre pièce. À l’inverse, un champ peu confiant mais non critique peut rester absent sans bloquer le traitement. La décision combine rôle du champ, provenance, contrôles et coût d’erreur.

• Accepter : le champ et ses preuves satisfont le contrat de l’usage.
• Accepter avec réserve : le champ alimente une aide visible, sans action automatique.
• Demander une revue ciblée : une personne tranche sur une zone et un motif précis.
• Demander une nouvelle pièce : la qualité source empêche une lecture fiable.
• Bloquer la chaîne : identité, droits, intégrité ou contradiction critique ne sont pas résolus.

Concevoir le contrôle humain comme un produit de preuve et de correction

Un contrôle humain utile ne présente pas seulement un formulaire prérempli. Il montre la page, surligne la zone, affiche la valeur brute, la normalisation, les contrôles et le motif de revue. La personne peut accepter, corriger, marquer l’absence, changer le type de document ou demander une nouvelle pièce.

La correction est structurée. Elle enregistre la valeur avant et après, le rôle autorisé, le motif, l’heure et la version de l’artefact. Elle ne remplace pas l’image. Une correction peut alimenter une suite de non-régression après validation de sa qualité ; elle ne devient pas automatiquement une vérité d’entraînement.

La file de revue est priorisée par conséquence et délai, non seulement par confiance croissante. Un champ d’adresse destiné à une recherche peut être moins urgent qu’un identifiant nécessaire à rattacher la pièce. Les temps de traitement, les retours arrière et les désaccords entre réviseurs sont mesurés.

Écran de revue	Question à résoudre	Action permise
Vue page et zone	le signe est-il correctement reconnu ?	corriger le texte brut
Vue structure	le libellé et la valeur sont-ils associés ?	relier ou dissocier les blocs
Vue métier	la normalisation et le champ sont-ils justes ?	corriger, absenter ou escalader
Vue contradictions	quelle source doit être vérifiée ?	demander une pièce ou conserver le conflit

La supervision doit être effective : compétence, temps, information et autorité pour refuser. Une obligation de cliquer « valider » sur toutes les sorties crée une fatigue de contrôle et masque la qualité réelle. Le taux de correction et les motifs servent à améliorer acquisition, modèle, schéma ou règle au bon endroit.

Scénario pédagogique : préparer la lecture d’un relevé d’informations automobile

Ce scénario est une illustration et ne décrit ni client ni automatisation en production. Un courtier reçoit un relevé d’informations automobile. L’objectif est de préparer quelques champs et leurs preuves pour une revue. Le système ne décide pas l’éligibilité, le tarif ou la souscription.

L’acquisition rattache la pièce au dossier proposé, conserve le PDF et vérifie les pages. L’OCR produit mots et zones. Le layout distingue l’en-tête, les lignes d’événements, les colonnes de date et de responsabilité, ainsi que le pied de page. Le classifieur vérifie qu’il s’agit bien du type documentaire attendu et signale une version inconnue.

L’extracteur propose l’identité telle qu’écrite, la période, le coefficient et les événements, avec une zone pour chaque valeur. Les dates sont normalisées seulement si leur format est explicite. Le validateur contrôle les formats et la cohérence chronologique, puis compare la référence au dossier lorsque cette opération est autorisée.

Une ligne coupée sur deux pages ou une colonne ambiguë part en revue ciblée. L’interface affiche les deux fragments. Le gestionnaire peut relier la ligne, la laisser indéterminée ou demander une nouvelle pièce. La donnée corrigée reste associée au document et à l’auteur de la correction.

1. Entrée valide et lisible : vérifier que la chaîne produit champs et zones attendus.
2. Scan incliné : mesurer l’effet du redressement et conserver l’original.
3. Nouvelle mise en page : exiger l’abstention du classifieur ou une revue, pas un remplissage forcé.
4. Colonne décalée : détecter l’incohérence de layout même si chaque mot est exact.
5. Référence contradictoire : garder les deux sources et empêcher l’intégration automatique.

L’article sur l’analyse d’un dossier de souscription imparfait complète cette chaîne au niveau du dossier. Il reste essentiel de ne pas confondre extraction documentaire et appréciation d’une situation d’assurance.

Évaluer chaque étage, chaque type de pièce et chaque champ critique

Le jeu de recette reflète la variabilité connue : types et versions de documents, canaux, appareils, résolutions, langues, manuscrit, tableaux, tampons, pièces incomplètes et cas hors périmètre. Il sépare mise au point, mesure finale et non-régression. Les volumes par segment accompagnent les scores.

L’OCR se mesure au niveau caractère ou mot, mais les identifiants et nombres reçoivent une analyse dédiée. Le layout se mesure sur les zones, l’ordre, les tableaux et les relations. L’extraction utilise précision, rappel et exactitude par champ ; un champ partiellement correct est défini explicitement. La validation se mesure par erreurs acceptées, cas sûrs bloqués et charge humaine.

Étage	Mesure principale	Découpage obligatoire	Erreur critique possible
Acquisition	documents complets et correctement rattachés	canal, format, appareil	mauvais dossier
OCR	erreur caractère/mot et exactitude ciblée	qualité, langue, zone, type de signe	chiffre ou identifiant altéré
Layout	zones, ordre et relations corrects	version, pages, tableaux	valeur rattachée au mauvais libellé
Extraction	précision/rappel par champ	champ, document, population	valeur inventée ou absente acceptée
Validation	faux acceptés et faux rejets pondérés	règle et conséquence	contradiction masquée
Revue	temps, correction et issue	motif, rôle, difficulté	validation automatique par fatigue

Les seuils de confiance sont calibrés sur la sortie et le segment réels. La documentation Google Document AI permet par exemple d’examiner faux négatifs et effets d’un seuil dans son cadre d’évaluation. Le seuil choisi pour un champ non critique ne doit pas être copié sur une date ou un identifiant dont l’erreur change le traitement.

La mesure de bout en bout ajoute la proportion de documents entièrement traités, la charge de revue, le délai par issue et le taux de retour à la source. Elle ne remplace pas les métriques d’étage : sans elles, une régression ne peut pas être localisée.

Comparer une solution sur un banc de documents, puis préparer un pilote réversible

Un comparatif fournisseur doit utiliser les mêmes fichiers, le même schéma et les mêmes règles de scoring. Les fonctionnalités annoncées sont inventoriées — formats, langues, régions, exécution synchrone ou asynchrone, objets de layout, versions, quotas et rétention — puis vérifiées dans la documentation contractuelle applicable au moment du choix.

Le test sépare qualité brute, travail d’intégration et exploitation. Une API peut bien reconnaître les tableaux mais demander une normalisation importante ; une autre peut fournir des ancrages très utiles à la revue. Le coût porte sur pages, appels, stockage, modèles personnalisés, reprises, observabilité et temps humain. Les tarifs sont datés et ne sont pas intégrés comme vérité durable dans cet article.

1. Définir le périmètre. Deux ou trois types de pièces, champs, usages interdits et critères d’arrêt.
2. Constituer le jeu. Cas fréquents, dégradés, nouvelles versions, hors périmètre et contradictions.
3. Étiqueter la preuve. Valeurs, pages, zones, relations et motifs d’abstention.
4. Comparer les étages. OCR, layout, extraction, validation et charge de revue séparément.
5. Tester les limites. Quotas, temps de traitement, pages volumineuses, panne et nouvelle version.
6. Observer sans écrire. Produire les propositions à côté du processus existant.
7. Ouvrir une aide limitée. Affichage de champs et preuves sans décision automatique.
8. Décider avec les erreurs. Étendre seulement si les segments critiques et la reprise sont maîtrisés.

Une architecture d’achat n’exclut pas la réversibilité. Le modèle canonique interne doit pouvoir recevoir la sortie d’un autre moteur, avec des pertes explicitement documentées. Les fichiers source, annotations, règles et résultats de recette restent exportables selon les droits et engagements applicables.

Exploiter, corriger et revenir en arrière sans perdre la preuve

En production, chaque traitement conserve version du moteur, configuration, transformations, schéma et règles. Les indicateurs suivent la composition des documents, les erreurs par champ, les mises en page inconnues, la charge de revue et le temps de traitement. Une moyenne stable peut cacher l’arrivée d’un nouveau formulaire mal reconnu.

Les corrections sont réparties par cause : acquisition, OCR, layout, extraction, règle, données dossier ou interface. Cette taxonomie évite de réentraîner un modèle pour corriger une règle erronée, ou d’ajouter un prompt lorsque la pièce est illisible. Les cas confirmés alimentent une suite de non-régression avec leur statut de provenance.

Le plan de retour arrière peut désactiver un extracteur, revenir à une version précédente, conserver seulement l’OCR, fermer un type de pièce ou repasser en saisie manuelle. Les données déjà intégrées restent attribuables à la version qui les a produites. Le NIST AI RMF recommande une mesure reliée au contexte et un suivi en exploitation ; ces pratiques donnent un cadre à cette traçabilité sans remplacer les responsabilités métier.

La sécurité couvre droits d’accès, chiffrement, région, sous-traitants, conservation, journalisation et suppression. Les documents peuvent contenir des données personnelles ou sensibles. Le principe est de limiter les données et les étapes à ce qui est nécessaire pour la fonction déclarée ; aucune recommandation juridique individuelle n’est déduite ici.

Sources et références primaires

• LayoutLM: Pre-training of Text and Layout for Document Image Understanding : publication primaire sur la modélisation conjointe du texte et de la disposition.
• Microsoft — Document Intelligence Layout : documentation officielle sur le texte, les lignes, coordonnées, structures et scores exposés par le service.
• AWS — Amazon Textract document analysis response objects : documentation officielle des blocs, relations, géométries et confiances.
• Google Cloud — Document AI Document resource : contrat officiel des pages, ancrages, polygones, entités et provenance visuelle.
• Google Cloud — Evaluate processor performance : documentation officielle sur l’évaluation, les seuils et l’analyse d’erreurs.
• NIST AI Risk Management Framework : cadre officiel pour relier mesure, contexte, supervision et gestion des risques.
• Règlement (UE) 2024/1689 : texte officiel de l’AI Act ; la qualification d’un système dépend de son usage réel.