Extraire des données de PDF avec l'IA : comment vérifier ce qui est lu

Un système qui lit une facture et restitue dix champs remplis fait bonne impression. Le problème arrive après : sur deux mille documents, comment savoir lesquels de ces dix champs sont erronés ? L'extraction automatique ne se juge pas sur la démonstration réussie, mais sur ce qui se passe quand elle se trompe en silence. Ce guide sert à concevoir les contrôles avant de faire écrire ces données quelque part.

D'abord les champs, ensuite l'outil

La première décision n'est pas technologique : c'est la liste des champs dont vous avez besoin, avec le format et la règle de chacun, écrite avant de tester quelque outil que ce soit.

• Quels champs. Pas « tout ce qu'il y a dans le document » : seulement les champs que quelqu'un utilisera. Chaque champ extrait est un champ à contrôler.
• Quel format. Une date est un jour précis, pas une ligne de texte ; un montant a une devise et des décimales ; un code a une longueur. Sans format, il n'existe pas de contrôle automatique.
• Quels documents sont admis. Un fichier généré par un autre système se lit d'une façon, le scan de travers d'une feuille tamponnée est un autre problème. Dire « nous acceptons tout » signifie ne pas avoir de seuil de qualité.
• Que faire quand un champ n'existe pas. C'est le cas le plus fréquent et le moins conçu : le document est valide mais cette donnée n'apparaît pas. La réponse ne peut pas être une valeur reconstruite par intuition.

Si cette liste ne peut pas être écrite, le problème n'est pas l'intelligence artificielle : c'est que le processus en aval n'est pas défini et que personne ne sait ce qu'on fera de ces données.

Trois opérations différentes appelées « lecture »

Dans la même phrase se confondent trois choses qui se trompent différemment et doivent être vérifiées différemment.

• La reconnaissance du texte : transformer une image en caractères. Ici, les erreurs sont matérielles — un huit lu comme un trois, une ligne coupée par le pli de la feuille, une partie hors cadre. Un document né numérique saute cette étape et est beaucoup plus fiable.
• L'extraction : décider lequel, parmi les nombres présents, est le total, et laquelle des trois dates est celle d'émission. Ici, les erreurs sont d'interprétation, et elles sont les plus dangereuses parce que le résultat est toujours plausible.
• Le contrôle : établir si la donnée extraite est cohérente avec le reste. C'est la seule des trois étapes qui peut s'apercevoir que quelque chose ne colle pas, et c'est celle que presque personne ne conçoit.

Un système qui saute la troisième étape n'est pas automatisé : il a seulement déplacé le contrôle vers celui qui reçoit les données, sans le lui dire.

Le tableau des champs

Le document de projet le plus utile est un tableau avec une ligne par champ. Un exemple, sur une facture reçue d'un fournisseur.

Les deux dernières colonnes sont le vrai guide. Un champ sans contrôle et sans destination en cas d'erreur est un champ que personne ne vérifiera jamais.

Les contrôles qui s'écrivent à la main

Les contrôles utiles ne sont pas statistiques : ils sont arithmétiques et se fondent sur les fichiers de référence, et c'est justement pour cela qu'ils sont fiables.

• Cohérence interne : les totaux concordent, les lignes s'additionnent, les pourcentages se recalculent.
• Cohérence avec ce que vous savez déjà : le fournisseur existe, le numéro de commande existe, ce client a vraiment ce siège.
• Plausibilité : une date du siècle dernier, un montant hors échelle de trois ordres de grandeur, une quantité négative là où elle ne peut pas l'être.
• Doublons : le même document chargé deux fois est une erreur plus courante qu'un champ mal lu, et plus coûteuse.

Quand un contrôle échoue, on ne corrige pas automatiquement. On envoie en révision : corriger seul une donnée dont le système s'est déjà montré incertain est le moyen le plus direct de créer des erreurs invisibles.

Où passe la révision humaine

L'objectif réaliste n'est pas d'éliminer la personne : c'est de lui faire regarder peu de documents au lieu de tous, et de savoir lesquels.

1. Les documents qui passent tous les contrôles poursuivent leur chemin, avec leur trace.
2. Les documents avec un contrôle échoué vont dans une file de révision, avec le champ problématique mis en évidence et le document original à côté : celui qui corrige n'a pas à chercher.
3. Les documents bloquants — un total qui ne concorde pas, un doublon possible — ne poursuivent leur chemin en aucun cas, même en cas d'urgence.

La file de révision doit se lire comme un indicateur. Si elle croît toujours sur le même type de document ou le même fournisseur, la solution n'est presque jamais d'améliorer l'extraction : c'est de demander ce document dans un format différent.

Conserver la provenance

Pour chaque donnée écrite dans un système, on doit pouvoir remonter à l'endroit où elle a été prise. Ce n'est pas de la bureaucratie : c'est la condition pour pouvoir contester, corriger et comprendre.

• Le document original, conservé et relié à la donnée.
• Le point du document d'où la valeur a été extraite, pour le retrouver sans tout relire.
• Si la valeur a été corrigée à la main : par qui, quand, et quelle était la valeur précédente.
• Quels contrôles ont été exécutés et avec quel résultat.

Sans ces quatre informations, quand dans un an un chiffre se révélera erroné, on ne saura pas si l'erreur se trouve dans la lecture, dans la correction ou dans le document de départ.

Ce que ce guide ne couvre pas

Ici, on traite l'extraction assistée : ce qu'on peut lire d'un document et comment on le vérifie. Il n'existe pas de configuration qui garantisse une précision totale, et aucune donnée extraite ne devrait entrer en comptabilité sans les contrôles décrits. Le cas d'un système qui ne se limite pas à lire mais écrit ou modifie des données dans un système de gestion est un problème différent, de permissions et d'actions autorisées, et fait l'objet de son propre guide ; le transfert ponctuel de données depuis des feuilles de calcul ou depuis un ancien système suit lui aussi sa propre méthode.