Aller au contenu principal
← Retour aux articles

Extraction de documents par IA : vérifier les données avant leur import

Champs attendus, preuve dans le PDF, contrôles métier et validation humaine : une méthode pour préparer un premier projet d’extraction documentaire par IA.

Extraction de documents par IA : vérifier les données avant leur import
Sommaire
  1. 1. Définir précisément les données attendues
  2. 2. Séparer la structure du résultat et son exactitude
  3. 3. Garder un lien vérifiable avec le document
  4. 4. Organiser la validation humaine
  5. 5. Traiter le document comme une entrée non fiable
  6. 6. Mesurer les erreurs avant de généraliser

Un PDF arrive par email. Une IA en extrait les références, les quantités et la date demandée, puis prépare leur import dans votre logiciel de gestion. Avant de laisser ces données alimenter une commande, il faut pouvoir répondre à une question simple : chaque valeur correspond-elle vraiment au document reçu ?

Voici une méthode pour cadrer cette vérification dans une PME. Nous prendrons un exemple entièrement fictif : un distributeur souhaite préparer des brouillons de commandes à partir des bons envoyés par ses clients. L’acceptation commerciale et le lancement de la livraison restent soumis à validation.

1. Définir précisément les données attendues

Commencez par une seule famille de documents. Mélanger dès le premier essai bons de commande, devis et bons de livraison complique les règles : une date peut désigner l’émission, la validité ou la livraison souhaitée.

Dans notre exemple, le résultat attendu comprend :

  • le numéro du bon et l’identité du client ;
  • la référence de chaque article, sa quantité et son unité ;
  • la date de livraison demandée, si elle figure dans le document ;
  • un statut indiquant les informations manquantes ou ambiguës.

Écrivez la signification de chaque champ avec la personne qui saisit habituellement ces commandes. Une quantité de « 12 » reste ambiguë si elle peut désigner des pièces ou des cartons.

Prévoyez aussi une valeur absente. Une date non indiquée doit rester vide, avec un motif, plutôt qu’être remplacée par une date plausible. Conservez séparément le texte lu et sa version normalisée : « 5 octobre 2026 » et « 2026-10-05 », par exemple.

2. Séparer la structure du résultat et son exactitude

Une sortie structurée impose au modèle un format exploitable, par exemple des champs JSON avec des types et des catégories définis. Google documente cette possibilité pour Gemini, tout en demandant de vérifier les valeurs dans l’application : une réponse conforme au schéma peut contenir une erreur de sens. Source : sorties structurées de Gemini.

Pour notre distributeur fictif, une quantité numérique et une référence bien formatée ne prouvent donc pas que la bonne ligne du PDF a été lue. L’application doit contrôler séparément :

  • la présence des champs indispensables ;
  • l’existence de la référence dans le catalogue autorisé ;
  • la cohérence entre quantité, unité et conditionnement ;
  • l’association de chaque quantité à la bonne référence.

Ces règles doivent être exécutées par le logiciel, après l’extraction. Demander uniquement à l’IA de « vérifier sa réponse » laisse ces contrôles dépendre du modèle qui a produit les valeurs.

3. Garder un lien vérifiable avec le document

Pour chaque champ important, prévoyez un accès au fichier source, au numéro de page et, lorsque l’outil le permet, à la zone correspondante. L’écran de validation doit présenter la valeur extraite à côté du passage à vérifier.

Si la page ou l’extrait sont proposés par un modèle génératif, contrôlez également leur correspondance avec le fichier. Une référence de page produite par l’IA n’est pas automatiquement une preuve fiable.

Imaginez un bon fictif comportant deux lignes voisines : dix boîtes de vis et vingt rondelles. Les nombres peuvent être correctement reconnus tout en étant rattachés au mauvais article. Une vue de la ligne complète aide alors le contrôleur à comprendre l’erreur.

Limitez l’accès aux documents aux personnes qui en ont besoin. Définissez aussi quels fichiers, extraits et journaux sont conservés, pendant combien de temps et chez quel prestataire. Ces choix doivent être connus avant de transmettre des documents réels.

4. Organiser la validation humaine

Certains outils fournissent des scores de confiance. Microsoft précise que Document Intelligence en retourne pour plusieurs éléments extraits, mais pas pour tous les champs. Ces scores peuvent aider à orienter les résultats vers une revue humaine. Source : interpréter les scores de confiance.

Fixez vos règles à partir d’essais représentatifs et des conséquences d’une erreur. Pour notre pilote, toutes les commandes restent à valider. L’interface met particulièrement en évidence une référence inconnue, une unité absente, un document peu lisible ou une information contradictoire.

Nommez la personne responsable et prévoyez trois issues : accepter, corriger ou demander une précision. Enregistrez la correction avec la version initiale et l’identité du validateur. Les dossiers en attente doivent rester visibles dans une file dédiée.

Le passage à davantage d’automatisation pourra être étudié après les essais, pour des cas précisément définis. Un score élevé ne doit pas autoriser à lui seul une action engageante.

5. Traiter le document comme une entrée non fiable

Un fichier externe peut contenir une consigne destinée à influencer le modèle, par exemple lui demander de modifier sa méthode d’extraction. OWASP décrit ce risque d’injection indirecte et recommande notamment de séparer le contenu externe des instructions, de limiter les permissions et d’imposer une validation humaine pour les actions sensibles. Source : injection de prompt selon OWASP.

Dans le pilote, donnez au composant d’extraction uniquement les moyens de lire le document et de produire un résultat intermédiaire. Il ne doit pas pouvoir déclencher une livraison, envoyer un email ou modifier le catalogue.

Vérifiez les valeurs reçues avant toute écriture dans le logiciel métier. Ajoutez au jeu d’essai un document fictif comportant une instruction parasite. Une consigne dans le prompt constitue une précaution parmi d’autres ; elle ne garantit pas l’absence de manipulation.

6. Mesurer les erreurs avant de généraliser

Constituez un lot de documents représentatifs : PDF numériques, scans lisibles et dégradés, plusieurs pages, tableaux coupés et champs absents. Faites établir les résultats attendus par une personne compétente. Gardez une partie de ce lot à l’écart des réglages pour l’évaluation finale.

Mesurez les champs erronés, les informations manquées et les documents nécessitant une correction. Google Document AI distingue notamment la précision, le rappel et les résultats par champ. Un résultat global peut masquer une faiblesse sur une information importante. Source : évaluer un processeur Document AI.

Suivez également le temps de vérification, les dossiers bloqués et le coût du traitement complet. Comparez-les au processus actuel, sans annoncer d’économie avant de l’avoir mesurée. Rejouez les mêmes tests après un changement de modèle, de consigne ou de format de document.

Pour démarrer, préparez trois éléments : quelques documents utilisables pour les essais, la liste exacte des champs attendus et les règles de validation. Vous disposez alors d’un périmètre concret à discuter avec votre intégrateur. Décrivez votre besoin à KADRI AI.

Documentation officielle consultée le 5 octobre 2026. Les fonctions et formats disponibles dépendent de l’outil, du modèle et de leur version.

Sources officielles

Sources consultées le . Les disponibilités et conditions peuvent évoluer.

À propos de cette publication

Veille et analyses KADRI AI : sources officielles datées, applications possibles pour les PME et limites explicites. Les annonces des éditeurs sont distinguées de notre analyse.

Partager :

De la lecture au projet

Une idée à mettre à l’épreuve ?

Partons de votre processus, de vos outils et d’un résultat que votre équipe peut vérifier.

Décrire mon projet