OCR ou LLM pour lire tes documents : lequel te faut-il (et pourquoi l'hybride gagne)

Le même mail arrive presque chaque semaine : « on reçoit des milliers de documents par mois et on les saisit à la main ; on part sur de l'OCR ou sur de l'IA ? ». Ça ressemble à une question technique, c'est une question d'achat : deux devis sur la table, un pas cher et prévisible, un souple et coûteux, et quelqu'un veut qu'on lui dise lequel. La réponse honnête dérange un peu : ce n'est pas la technologie qui décide. C'est la forme de tes documents.

La thèse en une phrase : il ne s'agit pas d'IA oui ou non. Il s'agit de gabarit stable contre format chaotique, et celui qui tranche à la fin, c'est le coût par document. Si tes documents ont toujours la même forme, l'OCR classique est moins cher, déterministe et auditable. Si chacun arrive comme il veut, un LLM multimodal lit n'importe quoi sans gabarit — et te le facture à chaque page. C'est pour ça qu'en production aucun des deux ne gagne seul : c'est l'hybride qui gagne.

OCR ou LLM pour extraire les données de tes documents : ce que fait exactement chacun

L'OCR classique transforme l'image en texte et, par-dessus, une couche de règles décide quel texte correspond à quel champ : le numéro de facture vit dans le cadre en haut à droite, le total est ce qui suit le mot TOTAL. L'intelligence n'est pas dans la lecture : elle est dans le gabarit. Tu lui donnes une zone ou un motif et, à entrée identique, il te rend toujours exactement la même chose.

Un LLM multimodal ne lit pas des zones : il regarde la page entière —texte, tableaux, tampons, une annotation à la main, la photo de travers prise au téléphone— et te rend les champs demandés parce qu'il comprend ce qu'est une facture, un bon de livraison ou un contrat. Aucun gabarit à maintenir. Aucune garantie non plus que deux exécutions sur le même document renvoient caractère pour caractère la même chose.

La différence qui compte n'est pas de savoir lequel est le plus malin. C'est ce qui se passe le mardi où un fournisseur refait sa facture sans prévenir personne.

L'OCR classique échoue quand tu changes la forme. Le LLM échoue quand le document est ambigu et qu'il comble le trou avec quelque chose de crédible. Deux modes de panne différents, deux filets de sécurité différents. Ce qu'aucun des deux ne fait tout seul, c'est te prévenir qu'il vient d'échouer : cette partie-là, tu la construis ou elle n'existe pas.

Quand choisir l'OCR classique avec gabarit

Choisis l'OCR classique quand le document a toujours la même forme et que cette forme ne dépend de personne à l'extérieur. C'est le cas de tout ce que ton propre système génère et d'une courte liste d'émetteurs stables : le même bon de livraison du même transporteur, le même formulaire rempli par tes clients, le même relevé de la même banque mois après mois.

• Gros volume, liste de formats courte. Peu d'émetteurs, beaucoup de documents : le gabarit s'amortit chaque jour qui passe.
• Il te faut toujours le même résultat. Un processus audité, ou qui déclenche un paiement, ne peut pas dépendre du fait qu'aujourd'hui ressemble à hier.
• Tu dois expliquer d'où sort chaque champ. Avec des règles tu montres la zone et le motif ; avec un modèle tu montres un paragraphe de prose, ce qui n'est pas pareil face à un auditeur.
• Le coût par document doit rester plat. Si tu multiplies le volume l'an prochain, un coût qui grimpe à la page se voit bien plus tôt que tu ne crois.

Le prix de cette option se paie en maintenance et n'apparaît jamais sur la facture du logiciel : chaque nouvel émetteur est un nouveau gabarit, et chaque refonte décidée par un autre est un gabarit cassé. Si ta liste d'émetteurs grossit toute seule, tu n'achètes pas une technologie bon marché : tu crées un poste fixe pour quelqu'un.

Quand choisir un LLM multimodal

Choisis le LLM quand la forme est le problème. Des documents de centaines d'émetteurs différents, des contrats où la donnée importante vit dans une clause que chaque cabinet rédige à sa façon, des mails avec pièces jointes qui arrivent en PDF, en photo et parfois transférés trois fois. Là, un gabarit n'est pas cher : il est impossible.

• Chaque document vient d'ailleurs. Le coût de maintenir un gabarit par émetteur dépasse celui de lire avec un modèle, et il ne s'arrête jamais.
• Le champ n'est pas une zone, c'est une idée. « Y a-t-il une pénalité de retard ? » n'est pas dans une case : il faut comprendre le texte pour répondre.
• Le volume est faible ou irrégulier. Avec quelques documents par mois, monter et maintenir des gabarits est un projet qui ne s'amortit jamais.
• Tu explores encore. Avant d'industrialiser quoi que ce soit, un modèle te dit en une semaine quels champs sont vraiment extractibles et lesquels résistent. C'est la reconnaissance de terrain la moins chère qui existe.

Ici le prix est l'inverse : tu paies au document, chaque mois, pour toujours, et tu paies aussi la validation. Un modèle qui renvoie un IBAN presque correct est pire qu'un modèle qui ne renvoie rien, parce que le « presque » traverse sans encombre tous les contrôles qui vérifient seulement si le champ est rempli.

Pourquoi l'hybride gagne en production

Après quelques mois en production, presque tous ces systèmes atterrissent sur la même architecture : les uns par conception, les autres en se cognant. Ce n'est pas un compromis tiède. C'est la seule façon d'avoir à la fois le coût de l'OCR et la couverture du modèle.

1. Classer d'abord. Avant d'extraire quoi que ce soit, le système décide de quel type de document il s'agit et de qui il vient. Cette étape est peu chère et conditionne tout le reste : c'est exactement le travail de classer les documents qui entrent.
2. Le gros du connu passe par la voie pas chère. Si le document correspond à un gabarit que tu as déjà, les règles l'extraient. C'est l'essentiel du volume, et traiter deux mille coûte à peu près ce que coûtent mille.
3. Le bizarre part au modèle. Nouvel émetteur, format qui ne colle pas, scan raté : c'est là que le LLM gagne sa place, parce qu'il n'a pas besoin d'avoir déjà vu le document. Tu paies le prix fort sur la queue seulement, pas sur tout le catalogue.
4. Contrôles croisés sur le sens. Le modèle sert aussi à relire ce que les règles ont sorti : la somme des lignes correspond-elle au total ? L'échéance est-elle postérieure à l'émission ? Ce fournisseur existe-t-il dans ton référentiel ? Ce sont des erreurs qu'un gabarit ne détecte jamais, parce qu'il a parfaitement lu une valeur fausse.
5. Une règle de confiance qui décide qui regarde. Chaque champ sort avec un score ; sous le seuil, le document part dans une file de relecture au lieu d'entrer dans l'ERP. Ce seuil est un levier de gestion, pas un détail technique : le monter coûte des heures de personne, le baisser coûte des erreurs qui remontent tard.
6. Tout ce qu'une personne corrige revient dans le système. Une correction qui se répète sur le même émetteur, c'est le signal que cet émetteur mérite désormais son gabarit. C'est comme ça que l'hybride devient moins cher tout seul : la queue chère se transforme peu à peu en volume pas cher.

C'est le motif de fond de tout processus automatisé de bout en bout avec l'IA : le chemin heureux par la voie la moins chère, l'exception par la voie la plus capable, et une porte explicite vers l'humain. Dans l'extraction documentaire ça se voit avec une clarté presque brutale, parce que le coût par document met tout noir sur blanc.

Ce que coûte vraiment la lecture d'un document

La ligne du devis, c'est la petite partie. Le coût réel d'un système d'extraction se répartit sur cinq postes, et un seul apparaît dans la proposition du prestataire :

• Traitement. Ce que coûte le passage du document dans le moteur. Plat en OCR, proportionnel aux pages et à la longueur en LLM.
• Maintenance du format. Gabarits neufs et gabarits cassés. Quasi nul avec un modèle ; croissant avec ta liste d'émetteurs avec des règles.
• Relecture humaine. Ce que tu paies pour chaque document que quelqu'un doit regarder. C'est souvent le poste le plus lourd et presque jamais dans le comparatif qu'on te montre.
• Retraitement. Documents à repasser parce qu'ils sont arrivés tronqués, chargés deux fois, ou parce que le lot est tombé à la moitié.
• L'erreur qui passe. Un montant mal lu qui arrive en comptabilité ne se paie pas en euros de logiciel : il se paie en double paiement, en avoir, en clôture qui glisse. C'est le plus cher et le seul qui n'a de ligne dans aucun devis.

Avant de signer quoi que ce soit, mets ces cinq postes sur la même feuille pour les deux scénarios, avec ton volume réel et ton mélange d'émetteurs réel. C'est le même exercice que calculer le ROI d'une automatisation avec l'IA : si l'économie n'apparaît qu'en ignorant la relecture humaine, l'économie n'existe pas.

Comment mesurer la qualité : exactitude par champ, pas « précision » globale

C'est là que la moitié des projets coule. Un prestataire te montre un chiffre de précision globale, et ce chiffre ne veut rien dire : il moyenne des champs qui ne valent pas la même chose. Mal lire le nom commercial du fournisseur est un désagrément ; mal lire le montant, c'est de l'argent mal déplacé. Un chiffre unique mélange les deux et te rassure là où tu devrais être nerveux.

La mesure qui sert se fait comme ça :

1. Un chiffre par champ, pas un pour tout. Exactitude sur le montant, sur la date, sur le numéro fiscal, sur le numéro de document. Chacun avec sa barre, fixée par ce que coûte l'erreur sur ce champ-là.
2. Correspondance exacte, pas ressemblance. Sur un IBAN ou un numéro fiscal, « presque » est faux. On compare caractère par caractère contre un jeu de documents annotés à la main par quelqu'un de ton équipe, pas contre la démo du prestataire.
3. Sépare « je ne sais pas » de « j'invente ». Un champ vide est un cas de relecture ; un champ rempli et faux est un incident. Un système qui se tait quand il doute vaut plus qu'un système qui répond toujours.
4. Mesure aussi par émetteur. La moyenne cache le fournisseur dont le format casse depuis trois semaines sans que personne le voie.
5. Remesure dès que quelque chose bouge. Nouveau modèle, nouvelle version du prestataire, gabarit retouché : on repasse le même jeu de test. Sans ça tu ne sais pas si tu as amélioré ou si tu as réparé ici en cassant là-bas.

Avec ces chiffres en main la conversation change de registre : tu arrêtes de comparer des démos et tu commences à comparer des résultats sur tes documents, les seuls que tu vas réellement traiter.

Quoi faire de la relecture humaine

La relecture humaine n'est pas l'échec de l'automatisation : c'est la pièce qui la rend déployable. L'erreur, c'est la façon de la monter. Relire cent pour cent de la sortie, c'est avoir échangé la saisie contre la lecture — et lire des écrans pleins de données correctes est une tâche où l'humain est très mauvais : au bout de vingt minutes tout est validé sans regarder.

Ce qui marche, c'est l'inverse : que le système décide à qui il montre quoi. La personne ne voit que ce que le seuil de confiance marque comme douteux, ce qui dépasse un certain montant et ce qui vient d'un émetteur jamais vu. Et ça arrive avec le champ surligné sur l'image, pas sous forme de formulaire vide à remplir avec le PDF ouvert à côté. C'est exactement l'argument de l'humain dans la boucle d'une automatisation avec l'IA : la valeur n'est pas de superviser, elle est de décider ce qui est supervisé.

Quand ça ne vaut pas le coup d'automatiser

Il y a des cas où la bonne réponse est non, et le dire à voix haute épargne des projets entiers :

• Volume faible et stable. Si le travail tient dans un moment par semaine, le projet —intégration, tests, maintenance— coûte plus cher que le problème. Ne l'automatise pas : documente-le et passe à autre chose.
• Des documents qui arrivent déjà structurés. Si l'émetteur peut t'envoyer la même donnée par API, en XML ou en facture électronique, lire un PDF relève de l'automutilation. Demande la donnée proprement avant de construire un lecteur.
• Personne ne sait quel est le bon résultat. Si ta propre équipe débat de ce qu'est « la date » d'un document, aucune technologie ne tranchera ce débat. On décide d'abord, on automatise ensuite.
• Le document déclenche quelque chose d'irréversible. Extraire pour proposer, oui. Extraire pour exécuter sans relecture un paiement, une résiliation ou une décision, pas encore.
• Les documents sont mauvais dès la source. Photos coupées, scans illisibles, pages à l'envers. Réparer la capture rapporte souvent plus que n'importe quel modèle, et coûte nettement moins.

Ce filtre est le même que celui qu'on applique pour décider quels processus automatiser avec l'IA : répétitif, entrée numérique, critère de réussite défini, et quelqu'un qui répond du résultat. S'il manque le quatrième, tu n'as pas un projet : tu as une expérience avec un budget.

La décision, en trois questions

1. Combien d'émetteurs différents génèrent l'essentiel de mes documents ? Peu et stables, commence par des gabarits. Beaucoup et changeants, commence par un modèle.
2. Combien me coûte un champ mal lu que personne ne détecte ? Si la réponse est « un double paiement », ton seuil de confiance monte haut et ta relecture humaine n'est pas optionnelle.
3. Puis-je annoter à la main cent documents réels cette semaine ? Si tu ne peux pas, tu ne peux pas mesurer ; et sans mesure, choisir entre OCR et LLM, c'est exprimer une préférence, pas prendre une décision.

La question avec laquelle tu es arrivé — « OCR ou LLM ? » — est la question d'un catalogue, pas celle de ton exploitation. La tienne est autre : quelle part de mes documents a une forme stable, quelle part non, et combien me coûte chacune. Une fois répondu, la conception tombe toute seule : des règles pour le connu, un modèle pour le bizarre, un score de confiance qui décide quand une personne entre en jeu, et un compteur qui te dit si la queue chère rétrécit. Le reste, c'est choisir un logo.