L'extraction de données de documents par IA consiste à transformer un document brut (facture scannée, bon de commande PDF, liasse fiscale, plan, contrat) en données structurées exploitables par un logiciel, sans ressaisie. En 2026, la chaîne fiable combine trois briques : un OCR pour lire, un modèle de langage pour comprendre la structure et les champs, et une étape de contrôle qui ne remonte à un humain que les cas douteux. Voici quand l'OCR seul suffit, quand il ne suffit plus, et ce que les projets JUWA ont mesuré sur des volumes réels.
OCR, LLM, pipeline hybride : trois niveaux de lecture
L'OCR classique reconnaît des caractères et rend du texte, parfois avec la position de chaque mot. Il est rapide, peu coûteux et suffisant quand le document a un gabarit fixe, comme un formulaire administratif toujours identique. Il échoue dès que la mise en page varie : deux fournisseurs, deux formats de facture, et le champ « montant TTC » n'est plus au même endroit.
Un modèle de langage multimodal lit la page comme une image, reconnaît le type de document, localise les champs quelle que soit leur position et rend une structure (JSON, tableau) que vous avez définie. Les éditeurs exposent aujourd'hui cette capacité directement, comme Mistral avec son API Document AI ou Anthropic avec la lecture de PDF. Le prix est plus élevé par page, la latence plus longue, et surtout le modèle peut inventer une valeur plausible là où l'image est illisible.
Le pipeline hybride combine les deux : l'OCR fournit le texte et les coordonnées, le modèle interprète et structure, puis des règles métier vérifient la cohérence (total HT + TVA = TTC, numéro de commande présent dans l'ERP, date dans une plage plausible). C'est l'architecture retenue sur tous les projets JUWA décrits plus bas.
Résumé de la vidéo (en anglais) : Mistral présente sa chaîne d'extraction documentaire, de l'OCR à la structuration des contrats, factures et rapports, et les cas où le modèle multimodal remplace l'OCR seul.
Ce que mesurent les benchmarks, et ce qu'ils ne disent pas
Le benchmark OmniDocBench (2024) évalue les outils d'analyse de PDF sur neuf types de documents avec des annotations détaillées (texte, tableaux, formules, ordre de lecture). Deux enseignements en ressortent pour une entreprise. D'abord, aucune approche ne domine sur tous les types de documents : les tableaux complexes et les mises en page multi-colonnes restent les points faibles. Ensuite, la qualité du scan pèse plus que le choix du modèle : un document penché, sombre ou compressé dégrade tous les outils.
Ce que les benchmarks ne mesurent pas, c'est le coût d'une erreur non détectée. Un taux de reconnaissance de 98 % sur une facture signifie une erreur toutes les cinquante lignes environ. Sur 1 900 documents par mois, ce sont des dizaines d'écarts qu'il faut attraper. La question utile n'est donc pas « quel outil lit le mieux » mais « comment savoir quand il s'est trompé ».
La validation humaine, placée au bon endroit
La règle appliquée par JUWA est d'attacher à chaque champ extrait un score de confiance et un contrôle de cohérence, puis de router : au-dessus du seuil et cohérent, la donnée passe dans le SI ; en dessous ou incohérent, elle va dans une file de validation avec l'image du document et le champ surligné. L'opérateur ne relit pas tout, il tranche sur ce que la machine a signalé. Sur les premiers jours, le seuil est haut et la file longue ; il baisse à mesure que la mesure montre où l'extraction est fiable.
Ce mécanisme est aussi ce qui rend le traitement conforme quand les documents contiennent des données personnelles : les fiches pratiques IA de la CNIL attendent une minimisation (n'extraire que les champs nécessaires) et une traçabilité que la file de validation fournit naturellement.
Quatre projets, quatre types de documents
| Document | Volume | Ce que fait l'extraction | Résultat mesuré |
|---|---|---|---|
| Bons de commande et accusés de réception, PME aéronautique | 1 900 paires par mois | Lecture des deux documents, alignement des lignes, liste des écarts | 317 heures récupérées par mois |
| Liasses fiscales, administrateur judiciaire | Par dossier | Extraction des postes du bilan et du compte de résultat, contrôle actif = passif, alimentation de l'outil métier | 3 heures gagnées par dossier |
| Plans et pièces de marché, PME du BTP | Par affaire | Lecture des plans, application des règles de débours, DPGF pré-rempli pour l'ERP de chiffrage | Note de débours et DPGF prêts à chiffrer |
| Notices techniques, PME industrielle | 2 000 documents | Extraction et découpage pour indexation dans un assistant RAG | Temps de recherche du SAV réduit de 55 % |
Le premier cas est détaillé dans l'automatisation de la vérification des bons de commande : l'extraction ne sert pas à saisir, mais à comparer, et l'humain ne voit que les anomalies. Le deuxième, l'automatisation des liasses fiscales, montre l'intérêt des contrôles comptables comme garde-fou : une liasse dont le total actif diffère du total passif est renvoyée en validation sans qu'aucun modèle ait à « deviner ». Le troisième, l'automatisation des débours et DPGF dans le BTP, part de documents que l'OCR seul ne sait pas lire, des plans, et illustre pourquoi le modèle multimodal est devenu nécessaire. Le quatrième, l'assistant documentaire d'une PME industrielle, rappelle que l'extraction sert aussi à alimenter une recherche, pas seulement une base de gestion.
Coût par page et ordre de grandeur des délais
Le coût d'un pipeline se lit en trois postes. L'appel au modèle, facturé à la page ou au token, varie d'un facteur dix selon qu'on utilise un OCR seul ou un modèle multimodal sur chaque page ; le pipeline hybride limite l'appel au modèle aux pages où l'OCR ne suffit pas. Le développement des règles métier et de la file de validation représente l'essentiel de la charge initiale, de deux à six semaines selon la diversité des documents. L'exploitation, enfin, se résume à la revue des exceptions et à l'ajout de règles quand un nouveau format apparaît. La Direction générale des Entreprises situe l'analyse documentaire parmi les cas d'usage les plus rentables pour une PME dans son guide France Num, précisément parce que le coût unitaire est faible face au temps de saisie remplacé.
Pour un premier projet, JUWA recommande de partir d'un seul type de document à fort volume et à règles de contrôle évidentes, comme les factures fournisseurs ; l'article sur l'agent IA en PME montre comment ce périmètre s'inscrit ensuite dans un flux complet, et le guide sur la préparation d'une base documentaire pour un RAG couvre le cas où l'extraction alimente une recherche.
Où un premier projet se casse
Tester sur les documents les plus propres, puis découvrir en production les scans de fax et les photos de téléphone. Faire relire toutes les extractions à un opérateur, ce qui coûte plus cher que la saisie initiale et fait abandonner le projet en trois mois. Et laisser le modèle « compléter » un champ absent au lieu de le déclarer manquant : une facture sans numéro de commande doit remonter comme telle, pas avec un numéro plausible.
Comment JUWA mène un projet d'extraction
Le cadrage commence par un échantillon réel : cent documents pris au hasard dans le flux, pas les plus propres. JUWA mesure sur cet échantillon le taux d'extraction correcte champ par champ, avec OCR seul puis avec le pipeline hybride, et fixe le seuil de validation à partir de ces chiffres. Le livrable est un moteur d'extraction documentaire branché sur vos sources et votre SI, avec sa file de validation, son journal et la liste des règles métier, documentée pour que l'équipe puisse en ajouter sans prestataire. Les quatre projets du tableau ont tous suivi ce chemin, de l'échantillon à la production.
