Extraction IA : traiter un champ absent sans inventer sa valeur

La demande contient une quantité et un montant, mais aucune date souhaitée. L’extraction retourne pourtant une date plausible et le formulaire paraît complet. Le gestionnaire découvre ensuite qu’elle vient d’un autre document ou d’une habitude supposée du client. Le risque n’est pas seulement une valeur fausse : le système a supprimé le manque qui aurait dû déclencher une question avant le traitement.

En pratique, extraire un champ consiste à conserver sa valeur lorsqu’elle est soutenue par la pièce, et son état lorsqu’elle ne peut pas être établie. Un champ attendu par le contrat peut rester absent du document. L’automatisation IA des processus métier doit pouvoir transporter cette absence, une contradiction ou une illisibilité jusqu’à une reprise explicite, sans transformer la complétude du JSON en preuve de complétude métier.

Nous utilisons neuf demandes textuelles fictives, des annotations manuscrites et douze propositions contrôlées champ par champ. Aucun OCR ou modèle ne produit ces valeurs ; le banc vérifie un contrat et des preuves locales. Pour confier une demande incomplète à une IA d’extraction sur mesure, le gestionnaire doit pouvoir distinguer une quantité absente d’un zéro écrit dans la pièce. Le calcul d’un total ne devient pas non plus la preuve que ce total figurait dans le document.

Pour qui une extraction doit pouvoir rester incomplète

Définir le champ qui influence une décision réelle

Le sujet concerne une équipe qui extrait des données de demande, quantités, dates ou montants pour préparer un traitement. Un champ peut influencer un routage, une vérification ou la création future d’un objet métier. Son utilité vient de cette décision. Un formulaire rempli avec des valeurs plausibles peut retirer du travail de saisie tout en introduisant des décisions que personne n’a effectivement prises.

Commencez par identifier la conséquence d’une valeur manquante. Une date souhaitée peut entraîner une demande de précision ; une quantité contradictoire peut bloquer une préparation ; un montant absent peut rester optionnel à cette étape. La règle dépend du processus. L’extraction ne doit pas décider seule quels manques sont acceptables, ni compléter un champ sensible parce que le logiciel aval exige techniquement une valeur.

Séparer lecture fidèle et dossier prêt à traiter

Un champ peut être fidèlement lu et rester incompatible avec la règle métier. La pièce peut écrire quantité zéro, une date passée ou une condition non autorisée. La lecture conserve ce fait ; une validation distincte décide de son admissibilité au traitement. Modifier la valeur pendant l’extraction pour satisfaire une règle aval efface une information importante sur la demande originale.

Inversement, une sortie incomplète peut être une bonne extraction. Elle signale précisément ce que la pièce ne permet pas d’établir. Le produit doit montrer la source et la prochaine action plutôt que classer tous les champs vides comme des erreurs techniques. Une équipe peut alors distinguer document incomplet, contenu mal lu et proposition inventée, avec des responsables et des corrections différents.

Distinguer six états avant de remplir une valeur

Garder un motif qui explique la non-valeur

Notre contrat local utilise six états. present porte une valeur soutenue ; absent indique que le champ n’est pas fourni ; conflict conserve des valeurs incompatibles ; unreadable indique un contenu repéré mais illisible ; invalid conserve un contenu qui ne peut pas former la valeur attendue ; ambiguous demande une interprétation que les conventions disponibles ne permettent pas d’arrêter.

Ces états ne décrivent pas la confiance d’un modèle. Ils décrivent ce que le service peut établir sur le champ dans une pièce et un contrat donnés. Leur choix doit rester compréhensible pour l’opérateur. Si le système ne peut pas distinguer absence et défaut de lecture, il doit conserver cette incertitude plutôt qu’annoncer définitivement que le document ne contient rien.

Ne pas remplacer les motifs par une case vide unique

Une valeur null seule peut masquer des situations qui demandent des reprises différentes. Une date absente appelle une question ; une date illisible appelle peut-être une meilleure pièce ; deux dates contradictoires appellent un arbitrage. Conserver état et preuves permet au workflow de préparer la bonne action. La valeur vide ne doit pas conduire automatiquement à appliquer une date par défaut.

Le contrat peut être plus simple pour un usage borné, mais doit couvrir les situations que la recette provoque réellement. Il ne sert à rien d’ajouter des états que personne ne peut distinguer ou traiter. Le propriétaire métier choisit les décisions utiles, puis l’équipe technique définit les formes de sortie et les critères permettant de vérifier leurs transitions.

Décrire un champ attendu sans imposer un fait présent

Distinguer présence de propriété et présence documentaire

La documentation JSON Schema sur les objets distingue propriétés définies et propriétés requises. Exiger la propriété d’un champ dans une sortie structurée ne prouve pas que sa valeur figure dans la source. Le service peut exiger status, value et evidence, tout en autorisant explicitement null pour un état non résolu.

{
  "document_id": "B28",
  "field": "requested_date",
  "status": "absent",
  "value": null,
  "evidence": []
}

Ce JSON est la proposition manuscrite E28-02 réellement contrôlée. La demande B28 contient quantité et montant, sans date souhaitée. Le champ de sortie est présent, sa valeur n’est pas fabriquée et la décision reste une revue du manque. Le banc vérifie ses clés et son contenu avec un contrôleur local ; il n’exécute pas un validateur JSON Schema complet ni une fonction d’extraction fournisseur.

Faire du contrat une frontière entre lecture et reprise

La référence JSON Schema sur null rappelle que null et absence de propriété sont distincts. Notre contrat conserve cette différence : une propriété manquante est une sortie mal formée ; une valeur null accompagnée d’un état attendu est une information de traitement. L’outil aval doit recevoir les deux, plutôt que convertir implicitement null en zéro ou en chaîne vide.

Les contraintes de forme restent nécessaires : types, états autorisés et clés obligatoires. Elles ne suffisent pas à établir la fidélité de la valeur. Une date inventée peut être parfaitement valide au format ISO et un montant faux parfaitement typé. Le contrat doit donc relier la sortie à une pièce et à une attente contrôlée, puis distinguer validation d’extraction et autorisation de poursuivre le processus.

Attacher chaque valeur à sa pièce et à son extrait

Conserver le contenu brut avant sa normalisation

La preuve garde identifiant du document, intervalle de contenu et extrait brut. La documentation Document Intelligence sur la réponse d’analyse présente notamment contenu, champs et spans. Notre format est local : les offsets sont des positions de caractères Unicode Python, avec début inclus et fin exclue. Les conventions d’un fournisseur doivent être vérifiées avant conversion.

Demande A28
Quantité : 12 unités
Date souhaitée : 2026-11-04
Montant proposé : 480,00 EUR

Dans A28, l’extrait 480,00 EUR occupe l’intervalle [79, 89). Le banc vérifie qu’il correspond exactement à la sous-chaîne du document, puis rapproche la valeur 480.00 EUR à l’annotation manuscrite. La normalisation conserve montant et devise. Un intervalle exact prouve seulement l’existence de l’extrait ; le rapprochement à la valeur et au sens du champ reste une vérification supplémentaire.

Refuser une preuve provenant d’une autre demande

Une date présente dans A28 ne peut pas servir de preuve pour la date absente de B28. E28-03 essaie précisément ce transfert : proposition sur B28, référence de preuve sur A28. Le contrôleur renvoie evidence_scope_denied avant de comparer l’état attendu. Une référence consultable n’est pas nécessairement une pièce admissible pour le champ du dossier en cours.

La recette réelle doit aussi vérifier versions, pages et droits. Un extrait peut provenir d’une pièce remplacée ou d’un autre fichier homonyme. L’identité imposée par le service ne doit pas être remplacée par une référence libre proposée par le modèle. Le banc se limite à neuf textes fixes ; il ne démontre pas une authentification complète ou une gestion des révisions documentaires en production.

Préserver la différence entre absence et zéro

Lire un zéro explicite sans le faire disparaître

Exemple concret : C28 écrit « Quantité : 0 unité ». La proposition E28-04 garde un entier zéro, l’état present et cet extrait. Le contrôleur reconnaît une extraction fidèle, mais renvoie accepted_business_review parce que sa règle locale demande une revue pour une quantité non positive. Il n’autorise aucune commande ou opération ERP. Le zéro existe ; son usage métier reste à décider.

Un test de vérité implicite qui traite zéro comme vide ferait perdre cette distinction. La valeur doit être examinée avec son type et son état, pas seulement avec une condition « si valeur ». Les mêmes précautions concernent un booléen faux ou une chaîne explicitement vide lorsque ces valeurs ont un sens dans le contrat. La règle de traitement doit connaître leur signification au lieu de les remplacer automatiquement.

Refuser un zéro qui remplit seulement le schéma

I28 contient une date souhaitée et aucune quantité. L’annotation attend absent avec valeur null. E28-05 remplace ce manque par zéro et état présent ; le verdict status_mismatch refuse cette proposition. Le même entier devient ainsi fidèle dans C28 et inventé dans I28. Sa plausibilité ou sa compatibilité avec un type numérique ne décide pas de son origine documentaire.

Si le processus possède une valeur par défaut légitime, elle doit apparaître dans une opération différente, avec règle et responsabilité. Le dossier peut conserver « quantité absente dans la demande » puis « quantité choisie selon une règle validée ». Fusionner ces deux faits empêche de comprendre ce que l’expéditeur a fourni et ce que l’organisation a décidé ensuite.

Conserver les contradictions et les contenus illisibles

Ne pas choisir arbitrairement entre deux valeurs

D28 contient « Quantité : 12 unités » et une note non arbitrée qui mentionne « quantité 14 unités ». Notre annotation conserve un conflit, null et les deux extraits. E28-06 respecte cette attente ; E28-07 choisit 12 comme valeur présente et ne conserve qu’une preuve. Le contrôleur refuse cette seconde proposition par désaccord d’état. Une preuve vraie mais partielle ne résout pas une contradiction connue.

La présence d’une correction peut parfois fournir une règle de priorité, mais celle-ci doit être définie et vérifiable. Une mention signée qui annule une ligne diffère d’une note non arbitrée. Le modèle ne doit pas choisir systématiquement le dernier nombre ou le plus plausible. Le responsable métier indique quelles pièces permettent de résoudre le conflit et comment cette décision est conservée.

Distinguer lecture impossible et format non interprétable

E28 contient un marqueur manuscrit [illisible] dans la date ; aucun OCR n’est exécuté. L’état attendu est unreadable. G28 écrit 2026-02-30, date impossible vérifiée avec la bibliothèque de date ; son état est invalid. H28 écrit 04/11/26 alors que la recette exige une interprétation ISO complète et ne fournit pas la convention nécessaire ; il reste ambiguous, sans choix automatique de siècle ou de format.

Ces trois états portent null mais appellent des reprises différentes : meilleure pièce, correction d’une valeur impossible ou confirmation d’interprétation. Ils ne sont pas des scores de confiance. En situation réelle, le produit doit conserver le brut et expliquer ce qui manque pour décider. Une date normalisée sans convention peut sembler précise tout en introduisant une hypothèse que personne n’a confirmée.

Séparer normalisation, calcul et invention

Définir les transformations qui préservent la valeur

Passer de 480,00 EUR à 480.00 EUR peut être une normalisation déclarée d’une notation décimale, avec devise conservée. Convertir une date complète selon une convention connue peut également préserver le fait. Chaque transformation doit avoir une règle, ses conditions et une recette. Changer de devise, supposer une taxe ou choisir une date ambiguë n’est pas une simple modification de présentation.

La valeur brute et la valeur normalisée restent rapprochables. Si une extraction fournisseur présente déjà une forme normalisée, vérifiez comment elle est reliée au contenu d’origine et ce qu’elle infère. La fidélité ne vient pas du seul nom du champ. Une normalisation correcte d’un montant situé dans la mauvaise pièce demeure une erreur de dossier.

Conserver un résultat calculé comme une autre donnée

Deuxième cas concret : F28 écrit quantité 12 et prix unitaire 40,00 EUR, mais aucun montant total. Le calcul décimal 12 × 40 = 480 est vérifié ; il ne prouve pas qu’un total de 480 EUR est présent dans la demande. E28-09 conserve le montant total absent. E28-10 le remplit à 480.00 EUR et cite le prix unitaire ; le contrôleur renvoie status_mismatch.

Un processus peut calculer un montant proposé à partir de ces entrées selon une règle autorisée. Il doit alors conserver formule, entrées, unité, version et statut « calculé » dans une donnée distincte, puis faire vérifier les conditions utiles. Le résultat peut différer d’un total commercial réel si d’autres lignes ou règles existent. L’extraction garde son manque ; le calcul n’usurpe pas une mention du document.

Douze propositions vérifiées sur neuf demandes fictives

Rapprocher état, valeur et preuves à une annotation explicite

Les documents, annotations et propositions ont été rédigés manuellement. Le contrôleur vérifie clés, état autorisé, appartenance de preuve, offsets, extrait exact, valeur attendue et liste de preuves. Il compare des objets structurés à une recette connue ; il ne comprend pas automatiquement le sens d’une phrase libre et ne recherche pas tous les champs d’un document quelconque. Les verdicts établissent ce contrôle ciblé.

Les huit propositions fidèles sont acceptées au niveau du champ : une sans revue dans ce banc, une avec revue métier du zéro et six avec reprise d’un état non résolu. Les quatre propositions défavorables sont refusées. Aucun de ces nombres ne mesure la précision d’un modèle : les sorties sont manuscrites. Aucun verdict n’écrit dans l’ERP ni ne rend automatiquement l’ensemble du document prêt au traitement.

Vérifier aussi les défauts du contrôleur de preuve

Quatre mutations supplémentaires sont exécutées sur la proposition de montant A28. Retirer la propriété value donne shape_invalid ; un offset négatif donne evidence_offset_invalid ; remplacer le brut par 481,00 EUR donne evidence_quote_mismatch ; garder la bonne preuve mais proposer 481.00 EUR donne value_mismatch. Une preuve existante et une valeur fidèle sont bien deux contrôles distincts.

La recette repose sur les annotations fournies. Si elles sont fausses ou incomplètes, le contrôleur peut accepter une proposition conforme à une mauvaise attente. Leur relecture par le métier reste donc nécessaire, avec les conventions de champ et les cas de désaccord. Le banc ne démontre ni couverture OCR, ni extraction générale, ni résolution de contradictions documentaires non annotées.

Transformer l’état du champ en prochaine action

Donner au gestionnaire un manque expliqué

Le produit peut afficher « date souhaitée non fournie » avec la pièce consultée, puis proposer une demande de précision. Il peut afficher les deux quantités contradictoires et attendre un arbitrage. L’opérateur ne doit pas refaire toute la lecture pour comprendre pourquoi le champ manque. La reprise conserve dossier, champ, état, preuves et personne chargée de la décision.

Le seuil de complétude appartient à l’étape de workflow : la préparation nécessite certains champs, la validation ou l’exécution en nécessitent d’autres. Le contrat de sortie de l’extraction ne doit pas remplacer cette décision. La responsabilité de validation est nommée, et la traçabilité distingue entrée documentaire, proposition acceptée et correction humaine. Un repli vers la lecture manuelle garde les manques et leurs motifs.

Conserver une correction comme décision séparée

Si le gestionnaire saisit une date après échange avec le demandeur, le dossier conserve l’origine de cette nouvelle valeur. Elle n’était pas extraite de la pièce initiale. Le service peut ensuite rendre le champ exploitable selon sa règle métier, avec auteur, source de confirmation et révision. Cette distinction permet d’évaluer l’extraction sans lui attribuer la donnée que l’humain a ajoutée après coup.

La correction peut également invalider une preuve antérieure ou remplacer une pièce. Les propositions liées à l’ancienne révision doivent être réexaminées avant poursuite. La mémoire du dossier ne doit pas conserver un champ « présent » sans indiquer que sa source a changé. Le système mesure séparément erreurs de lecture, demandes initialement incomplètes et temps de reprise pour comprendre la charge réelle.

Erreurs fréquentes dans la validation d’extraction

Imposer la complétude ou accepter une preuve décorative

La première erreur consiste à exiger une chaîne non vide pour chaque champ, puis à appeler « extraction réussie » tout JSON complet. Le contrat récompense alors une invention utile au formulaire. La seconde consiste à accepter une citation quelconque du document sans vérifier qu’elle soutient la valeur du champ. Une vraie référence et un bon type ne suffisent pas si l’extrait concerne le prix unitaire au lieu du total.

Le signal faible est un taux de complétude très élevé accompagné de corrections fréquentes avant enregistrement. Un autre est la reprise systématique des mêmes dates ou montants sur des documents différents. Vérifiez alors les valeurs par défaut, le contexte partagé et l’appartenance des preuves. La supervision doit distinguer champ renseigné, champ soutenu et champ autorisé pour le traitement.

Lire une confiance comme une autorisation de décider

Un score de confiance éventuel dépend du composant et de sa définition. Il ne résout pas à lui seul l’absence, la contradiction ou l’applicabilité. Le seuil doit être évalué sur les champs et conséquences concernés, avec reprises et cas défavorables. Notre banc n’utilise aucun score fournisseur ; il vérifie états et preuves sur une référence explicite, sans inventer de précision ou de seuil universel.

Paradoxalement, un service qui laisse davantage de champs en attente peut retirer plus de reprises dommageables qu’un service qui remplit toujours tout. Cette utilité reste à mesurer : trop d’abstentions déplacent aussi du travail vers l’humain. La décision compare inventions évitées, manques correctement détectés et effort de clarification. Le coût complet inclut relecture, correction et dossiers qui restent ouverts.

Plan d’action pour une recette champ par champ

Choisir un champ, sa preuve et sa reprise

Commencez par un champ dont l’erreur change une décision et dont le métier peut définir les états utiles. Le propriétaire du processus décrit quand il est requis ; le propriétaire documentaire précise pièces et conventions ; l’équipe technique définit contrat et preuves. Le premier jeu doit montrer valeurs présentes, absences et contradictions, plutôt qu’une collection de documents parfaitement complétés qui ne testerait que le cas favorable.

1. Définir sens, unité et convention du champ. Distinguer valeur extraite, normalisation autorisée et résultat calculé ; écrire la conséquence d’une absence à chaque étape du traitement.
2. Annoter pièces et extraits attendus, avec les états non résolus. Faire relire zéro explicite, contenu illisible, date impossible et contradiction ; conserver les désaccords qui nécessitent une règle métier.
3. Construire la sortie structurée avec état, valeur et preuves. Autoriser les non-valeurs légitimes sans accepter une propriété manquante ; vérifier appartenance de pièce, offsets et correspondance au contenu brut.
4. Provoquer valeur inventée, preuve étrangère, conflit omis et calcul promu en extraction. Vérifier les refus réellement retournés, puis distinguer acceptation du champ et validation métier du dossier.
5. Raccorder chaque état à une reprise attribuée. Mesurer erreurs, clarifications, corrections et charge humaine ; n’élargir le périmètre qu’après contrôle de la recette et des familles documentaires concernées.

Le livrable conserve annotations, propositions défavorables, verdicts et limites du contrôleur. Un nouveau format documentaire peut modifier les conventions ou les emplacements de preuve : il exige une revue avant ouverture. Le choix de modèle intervient sur cette recette, avec le coût et les délais disponibles, plutôt que sur la seule capacité à produire un objet JSON sans erreur de syntaxe.

Vérifier le parcours qui transforme une lecture en donnée métier

Le runbook explique extraction indisponible, pièce remplacée, sortie invalide et conflit non arbitré. L’instrumentation relie entrée, état de champ et sortie acceptée ; la responsabilité de reprise reste visible. Les droits documentaires et l’autorisation d’écriture sont des contrôles de sécurité séparés, afin qu’une valeur proposée ne puisse pas modifier directement un objet métier parce qu’elle possède une forme valide.

La recette en environnement réel vérifie OCR ou extraction choisis, schémas, preuves et interface de revue. Le gestionnaire doit comprendre la différence entre non fourni et non lu, retrouver la pièce et corriger sans perdre le contexte. Une nouvelle version de modèle ou de contrat est comparée avec les mêmes attentes pertinentes. Les décisions humaines ajoutées après lecture restent identifiées pour ne pas masquer les défauts de l’extraction.

Guides complémentaires entre extraction et traitement

Placer le champ dans un parcours qui conserve ses exceptions

Le dossier métier avec états, règles et exceptions organise attente, revue et décision au-delà de l’extraction. Le champ incomplet doit rejoindre une étape connue, avec sa pièce et son responsable. Il ne doit pas disparaître dans une erreur générique ou être remplacé silencieusement pour permettre au workflow d’avancer.

La qualification des demandes avec abstention distingue décision de routage et demande de précision. Elle complète l’état d’un champ lorsque la pièce ne suffit pas à choisir une destination. Une sortie « à clarifier » peut être utile si elle expose exactement la question qui manque, sans inventer une catégorie ou un fait.

Relier la reprise humaine au traitement documentaire complet

La validation humaine en attente et son expiration examine la suite lorsqu’une décision nécessite un responsable. Le champ peut rester correctement extrait pendant que le dossier attend une confirmation. Les versions et la pièce courante doivent être contrôlées avant de reprendre une décision ancienne.

Le traitement documentaire avec extraction, classement et routage élargit la vue à la chaîne complète. Ce choix de périmètre doit préserver les états des champs : la classification réussie d’un document ne prouve pas que ses données sont complètes ou prêtes à écrire dans le système d’information.

Conclusion : conserver le manque au lieu de fabriquer la donnée

Une extraction fiable ne se juge pas au nombre de cases remplies. Elle conserve valeurs soutenues, absences, contradictions et contenus que la pièce ne permet pas d’interpréter. Le contrat rend ces états explicites et relie chaque valeur à sa preuve. La validation métier décide ensuite de la reprise ou du traitement autorisé, sans effacer ce que l’expéditeur a réellement fourni.

Les douze propositions fictives vérifient cette séparation sur neuf demandes manuscrites. Un zéro écrit reste présent mais soumis à revue métier ; un zéro substitué à l’absence est refusé. Une date empruntée à une autre pièce et un total calculé présenté comme extrait sont également refusés. Le banc contrôle des annotations connues et des preuves structurées ; il ne mesure aucune capacité OCR ou précision de modèle.

L’automatisation IA d’un processus métier doit transformer ces états en prochaines actions compréhensibles : demander une date, arbitrer une quantité ou vérifier une pièce. Le dossier conserve la différence entre lecture, normalisation, calcul et décision humaine, avec leurs sources et leurs responsabilités.

Dawap accompagne la recette de votre extraction IA sur mesure à partir d’une demande avec un champ manquant et sa variante renseignée. Avec le gestionnaire, nous fixons l’extrait qui justifie la valeur, les états d’incertitude et la clarification attendue. Le pilote teste également une référence de preuve étrangère, une date ambiguë et un total calculé, avant d’autoriser la transmission des champs à votre logiciel métier.