Les cinq erreurs qui font échouer une extraction documentaire par IA au passage en production sont toujours les mêmes : pas de jeu de test représentatif, pas de seuil de confiance par champ, une validation humaine placée en fin de chaîne, des formats de documents non prévus, et aucun suivi une fois le flux ouvert. Aucune ne se voit pendant le pilote, toutes se voient au troisième mois, quand les opérateurs ont cessé de croire à l'outil. Pour chacune, voici le symptôme observé sur des projets OCR et LLM réels, le correctif et l'indicateur à suivre.
Pourquoi un pilote réussi se dégrade-t-il au bout de trois mois ?
Parce que le pilote a été mesuré sur les documents du pilote, et que la production reçoit tout le reste. Gartner annonçait dès juillet 2024 qu'au moins 30 % des projets d'IA générative seraient abandonnés après la preuve de concept fin 2025, en citant la qualité des données et l'absence de contrôle des risques. Sur l'extraction documentaire, ces deux causes ont un visage précis : le scan de travers absent de l'échantillon, et le champ faux passé sans que personne le voie.
| Erreur | Symptôme à trois mois | Correctif | Indicateur à suivre |
|---|---|---|---|
| Pas de jeu de test représentatif | Taux d'erreur réel deux à trois fois supérieur à celui annoncé | 100 documents réels tirés au hasard, cas laids inclus, annotés à la main | Exactitude par champ sur ce jeu, recalculée à chaque changement de modèle |
| Pas de seuil de confiance par champ | Tout passe, ou tout est relu | Un seuil par champ, calé sur la mesure, plus une règle de cohérence métier | Part de documents traités sans intervention humaine |
| Validation humaine en fin de chaîne | L'opérateur relit tout, plus lentement qu'il ne saisissait | File de validation par champ douteux, image et zone surlignée | Temps de validation par document |
| Formats non prévus | Rejets en masse sur un fournisseur ou un type de pièce | Détection du format en entrée, découpage multi-pages, ouverture des pièces jointes | Taux de rejet technique par format |
| Aucun suivi en production | Dérive silencieuse, découverte par la comptabilité | Tableau de bord hebdomadaire, alerte sur nouveau gabarit | Taux de rejet, taux de correction, nouveaux modèles de documents par semaine |
Erreur 1. Tester sur des documents propres, sans jeu de 100 cas réels
Un pilote validé sur trente factures propres ne dit rien de la production. Trois mois plus tard, le taux d'erreur est deux à trois fois supérieur à celui présenté en comité, et l'équipe métier a repris la saisie en parallèle « au cas où ».
Le correctif tient en une consigne : cent documents tirés au hasard dans le flux réel du mois précédent, pas choisis par la personne qui veut que le projet passe. On y trouve les scans de travers, les tampons « reçu le » posés sur le montant, les mentions manuscrites, les photos de téléphone. Ce jeu est annoté à la main, champ par champ, et il sert de référence à chaque changement de modèle ou de prompt. C'est le principe de l'évaluation décrite dans la documentation de Google Document AI : précision, rappel et F1 se calculent contre un jeu de test annoté, et le seuil se choisit en regardant ce que l'un gagne quand l'autre perd. La fiche pratique 11 de la CNIL rappelle que la qualité de cette annotation conditionne celle du système.
Sur la vérification de bons de commande d'une PME aéronautique, le flux réel faisait 1 900 paires de documents par mois, vérifiées à la main. L'outil OCR et IA sur mesure a récupéré 317 heures par mois, un résultat qu'on ne tient que si les documents du flux réel, scans médiocres compris, entrent dans la mesure dès le départ et non au premier bilan.
Erreur 2. Un seul seuil pour tout le document, au lieu d'un seuil par champ
Le symptôme est binaire : soit le seuil global est bas et des montants faux entrent dans l'ERP, soit il est haut et tout part en relecture. Dans les deux cas l'automatisation n'existe pas.
Un modèle d'extraction rend un score par champ, et c'est à ce niveau que la décision se prend. Microsoft documente ce score comme une probabilité que la prédiction soit juste, avec un exemple parlant : à 0,95, la valeur est correcte 19 fois sur 20. La même page recommande de viser 80 % ou plus en général et de s'approcher de 100 % sur des données financières ou médicales. Le montant TTC n'a donc pas à supporter le même seuil que l'adresse de livraison. On règle chaque seuil sur le jeu de test de l'erreur 1, puis on l'encadre d'une règle métier indépendante du modèle (HT plus TVA égale TTC, numéro de commande connu de l'ERP, date dans le trimestre). Un champ à 0,97 qui casse la règle va en validation ; un champ à 0,88 qui la respecte peut passer.
On déconseille les seuils fixés « au ressenti » en réunion de lancement. Ils sont presque toujours trop hauts, et l'équipe finit par les baisser sans mesure.
Erreur 3. Faire relire en bout de chaîne plutôt qu'au champ douteux
Un opérateur placé en fin de chaîne pour « vérifier le résultat » contrôle plus lentement qu'il ne saisissait. À trois mois, la file ne se vide plus, les opérateurs relisent le document entier faute de savoir où regarder, et la direction conclut que l'IA ne fait pas gagner de temps.
Le correctif consiste à déplacer la validation vers le champ, pas vers le document. L'opérateur reçoit l'image, la zone en surbrillance, la valeur proposée et la raison du doute (score bas ou règle cassée). Il tranche en quelques secondes et ne voit jamais les champs passés. Sur des liasses fiscales, la règle métier la plus utile est comptable : une liasse dont l'actif ne boucle pas avec le passif remonte avec les deux totaux surlignés, le reste passe. C'est ce type de chaîne, OCR et IA sans ressaisie, qui a fait gagner 3 heures par dossier à un administrateur judiciaire sur ses liasses fiscales, pas un modèle plus gros. L'indicateur à suivre est le temps de validation par document : s'il dépasse le temps de saisie historique, la validation est au mauvais endroit.
Le retour d'expérience sur les factures fournisseurs applique le même mécanisme à la comptabilité.
Erreur 4. N'avoir prévu ni le PDF image, ni le multi-pages, ni les pièces jointes
Le symptôme est un pic de rejets techniques concentré sur un fournisseur ou un type de pièce, souvent découvert quand ce fournisseur appelle pour un retard de paiement.
Quatre cas reviennent sur chaque projet. Le PDF natif, dont on extrait le texte sans OCR, et le PDF image, qui exige l'OCR et se comporte comme un scan. Le document multi-pages, où le montant total est en page 4 et les lignes en pages 2 et 3, ce qui casse toute extraction page par page. Le courriel avec trois pièces jointes, dont une seule est la facture. Et le PDF assemblé qui contient deux factures collées. La chaîne d'entrée doit détecter le format avant d'extraire, découper les pages puis les regrouper par document, et ouvrir les pièces jointes en ne gardant que celles qui ressemblent à ce qu'on attend. Les modèles récents aident : Mistral OCR 4, sorti en juin 2026, accepte PDF, DOC et PPT en entrée, rend des blocs typés (titres, tableaux, signatures) avec leurs coordonnées, et coûte 4 dollars pour 1 000 pages. Le coût n'est plus le sujet, la gestion des cas d'entrée l'est.
Le cas des débours et DPGF d'une PME du BTP est la version extrême : les documents d'entrée sont des pièces de marché, pas des formulaires. Sur un pilote de 8 à 10 semaines, la note de débours est passée de 30 minutes à moins de 10, avec un DPGF pré-rempli pour l'ERP de chiffrage. Ce genre de résultat n'arrive pas si les formats réels ne sont pas dans le périmètre dès le premier jour.
Erreur 5. Aucun indicateur suivi une fois le flux ouvert
La cinquième erreur est la plus coûteuse parce qu'elle est silencieuse. Le modèle ne se dégrade pas, mais les documents changent : un fournisseur passe à un nouvel outil de facturation, un client ajoute une mention obligatoire, un scanner est remplacé et produit du 150 dpi au lieu de 300. Rien ne casse. La part de champs envoyés en validation monte doucement, les opérateurs valident sans regarder, et une erreur de montant ressort au rapprochement bancaire.
Trois indicateurs suffisent, sur un tableau de bord hebdomadaire lu par le responsable du flux. Le taux de rejet technique par format et par émetteur, qui révèle le nouveau scanner ou le nouveau gabarit. Le taux de correction humaine par champ, qui révèle une dérive ou une règle devenue fausse. Le nombre de gabarits jamais vus par semaine, détecté par une empreinte de mise en page, qui déclenche l'ajout au jeu de test. Chaque nouveau gabarit rejoint les cent documents de référence et l'exactitude par champ est recalculée, sinon le jeu de test de l'erreur 1 ne représente plus rien au bout de six mois. La checklist DSI avant mise en production d'une IA détaille les autres points de contrôle, journalisation et droits d'accès compris.
Ce que JUWA met en place avant d'ouvrir le flux
Un projet d'extraction chez JUWA commence par les cent documents, pas par le choix du modèle. Deux semaines servent à annoter le jeu de test avec le métier, à mesurer l'exactitude par champ avec un OCR seul puis avec le pipeline hybride du guide sur l'extraction de données de documents par IA, et à fixer les seuils et les règles de cohérence sur cette mesure. Les quatre à six semaines suivantes livrent la chaîne d'entrée, la file de validation par champ et le tableau de bord de suivi, branchés sur le SI existant, avec un chef de projet joignable et un point hebdomadaire.
Ce périmètre correspond à l'offre d'extraction documentaire par IA de JUWA, de l'échantillon à la production, avec les règles métier documentées pour que l'équipe interne puisse en ajouter sans prestataire. Si votre pilote a déjà tourné et que l'un des cinq symptômes vous parle, la première action n'est pas de changer de modèle. C'est de monter le jeu de test qui manquait et de mesurer où l'extraction se trompe vraiment.
