Une CNI photographiée à l'arrache dans un parking, un passeport scanné à 72 dpi, un titre de séjour avec un reflet en plein milieu de la MRZ. C'est le quotidien d'un onboarding KYC, d'un parcours assurance ou d'une vérification d'éligibilité. Et c'est ce qui fait planter 90% des pipelines OCR classiques.
Les LLM multimodaux ont changé la donne. On peut leur envoyer l'image directement : ils lisent, ils comprennent la structure du document. Mais le piège est ailleurs : ils sont chers, ils peuvent halluciner un numéro qui n'existe pas, et un appel à 5 000 tokens sur 80 000 documents par jour, ça pique.
La vraie question n'est plus "est-ce que le LLM sait lire ?". Elle est : combien je dépense pour quelle confiance ? Voilà comment on attaque le problème en production.
Qualifier avant d'OCRiser
La première erreur qu'on voit chez nos clients : balancer toutes les images dans le LLM en attendant le miracle. Mauvaise idée. 30% à 40% des documents sont inexploitables avant même qu'on tente la lecture : photo coupée, document hors champ, flou de bouger, surface réfléchissante. Pas la peine de payer pour qu'un GPT-4 vous le confirme.
On met donc une passe de qualification en amont. Pas un LLM : des modèles légers, locaux, rapides, qui produisent un score sur quatre dimensions :
- Présence du document : détection d'objet (YOLO, EfficientDet). Pas de doc = on rejette tout de suite.
- Netteté : variance du Laplacien sur la zone détectée. En dessous d'un seuil empirique calibré par type de doc, on demande une nouvelle photo.
- Géométrie : angle de prise de vue, recadrage, présence des quatre coins. Si c'est correctible, on redresse. Sinon, on rejette.
- Exposition : histogramme. Trop sombre, surexposé, reflet : on tente une normalisation. Si ça reste illisible, retour à l'utilisateur.
Cette passe coûte des cacahuètes en CPU. Elle fait gagner 30% du budget LLM dès la première semaine en prod. Elle permet surtout au reste du pipeline de partir sur un input propre.
Le calibrage en plusieurs phases
Une fois l'image qualifiée, on n'attaque pas la lecture en un seul coup. On enchaîne des phases, du moins cher au plus coûteux. À chaque étape, on décide : est-ce que je peux m'arrêter là, ou j'escalade ?
Le pipeline fonctionne en cascade : qualification → recadrage/redressement → OCR classique (Tesseract/Doctr) → si confiance ≥ 0,85, validation. Sinon → LLM multimodal sur les zones faibles → si confiance ≥ 0,85, validation. Sinon → boucle agentique avec outils. Chaque étape est un point de sortie possible.
L'OCR classique reste excellent sur 70% à 80% des documents propres. Tesseract sur une CNI bien cadrée, ça fonctionne, c'est gratuit, c'est instantané. Le LLM ne sert que sur le reste, c'est-à-dire les cas où la lecture standard échoue ou retourne une confiance basse.
Le calibrage, c'est le travail le plus important du pipeline. Il n'est jamais terminé :
- Seuils de confiance : on les ajuste par type de document. Un passeport biométrique ne se traite pas comme un titre de séjour de 1998.
- Régions d'intérêt : on cartographie les zones (nom, prénom, MRZ, date) pour pouvoir y revenir au pixel près.
- Ground truth : on labellise un échantillon réel, on mesure la précision par champ. Sans ça, on calibre à l'aveugle.
Donner des outils à l'agent, pas une mission floue
Quand on bascule sur le LLM, on ne lui dit pas : "lis-moi tout". C'est la pire stratégie : il va halluciner, surconsommer, et on n'aura aucune trace de ce qui s'est passé. À la place, on lui donne une boîte à outils précise et on le laisse choisir l'enchaînement.
| Outil | Ce qu'il fait | Coût relatif |
|---|---|---|
crop_zone(x, y, w, h) |
Extrait une zone précise pour une relecture ciblée | très faible |
enhance(operation) |
Déflou, contraste, suppression de reflet, binarisation | faible |
read_mrz() |
Parse la MRZ avec un parser dédié + checksum normalisé | très faible |
lookup_pattern(field, regex) |
Cherche un champ via pattern (ex : format date FR) | très faible |
check_consistency(field, value) |
Croise un champ avec un autre (âge ↔ date naissance) | faible |
score_confidence(field) |
Demande au modèle de noter sa propre certitude | moyen |
escalate_human() |
Lève la main, sortie d'urgence assumée | élevé (humain) |
L'agent boucle : il lit, il évalue sa confiance, il appelle un outil, il relit. Si après N itérations il n'atteint pas le seuil, il escalade. Chaque appel d'outil est tracé. À la fin du run, on a un journal complet : image, étapes, tools utilisés, tokens consommés, confiance finale.
Stratégie : ratio certitude / consommation
C'est là que tout se joue. Sans stratégie explicite, l'agent partira en vrille : il rappellera des outils, demandera des relectures, et vous découvrirez la facture en fin de mois. On pose donc des règles dures.
Budget par document. Chaque image a un plafond : X tokens, Y appels d'outils, Z secondes. Au-delà, on coupe et on escalade vers un humain. Sur nos pipelines actuels, on calibre généralement autour de 4 000 tokens et 6 appels d'outils par doc complexe. C'est arbitraire. Ce qui compte, c'est que le plafond existe.
Routing intelligent en entrée. On évite d'envoyer chaque image au LLM. Un classifieur léger (résolution, score qualité, type doc) décide : route directe vers OCR classique pour les cas simples, escalade LLM pour les cas dégradés. 80% des images n'ont jamais besoin du LLM.
Cache à plusieurs niveaux. Hash de l'image pour ne jamais retraiter le même doc. Cache des MRZ déjà parsées. Cache des templates de mise en page par pays. Le cache ne baisse pas le coût d'un appel : il le supprime.
Validation croisée systématique. La MRZ contient nom, prénom, date de naissance, numéro de doc. On croise avec ce qui est lu dans le corps du document. Si ça matche, confiance maximale. Sinon, escalade. Ce simple croisement a fait gagner 12 points de précision sur un projet récent, sans ajouter un seul appel LLM.
Mesure en continu. On suit deux métriques côte à côte : taux de validation automatique (combien de docs sortent sans intervention humaine) et coût moyen par doc validé. Si l'un monte sans que l'autre baisse, on a calibré dans le mauvais sens.
Le piège classique : faire confiance au "score de confiance" retourné par le LLM lui-même. Il est sympathique, mais pas fiable. Toujours croiser avec une mesure externe : cohérence MRZ, format attendu, plage de valeurs plausibles. Le score auto-déclaré est un signal, pas une vérité.
Ce qu'on retient après plusieurs déploiements
Le LLM ne remplace pas l'OCR classique. Il le complète. Tesseract et Doctr restent imbattables sur un document propre. Le LLM est précieux uniquement sur les cas dégradés, ambigus, ou multilingues. Construire le pipeline dans ce sens, et pas l'inverse, divise la facture par 5 à 10.
La traçabilité est la condition de la confiance. Chaque décision du pipeline doit être loggée : image, étapes, tools, tokens, sortie, confiance. Sans ça, vous ne pourrez ni débugger un cas client, ni améliorer le système en continu, ni passer un audit RGPD. La trace n'est pas une option, c'est une couche du produit.
On ne calibre pas en phase expérimentale. On calibre en prod. Les seuils, les budgets, les zones d'intérêt : tout ça bouge avec les données réelles. Les chiffres qu'on pose au démarrage sont des hypothèses. Au bout de 4 à 6 semaines en production, on les a divisés par deux ou doublés. C'est normal. C'est le calibrage qui fait le système, pas le code initial.
Un dernier point qu'on sous-estime souvent : la boucle de feedback humaine. Quand un agent escalade vers un opérateur, on récupère la correction. Cette correction part dans un dataset d'amélioration. Toutes les 2 semaines, on reprend les cas escaladés et on ajuste : nouveau seuil, nouvel outil, nouveau prompt. Sans cette boucle, le système stagne. Avec, le taux d'escalade baisse de 5 à 10 points par mois sur les premiers trimestres.
Si vous avez un pipeline OCR qui surconsomme, qui hallucine, ou qui demande trop d'intervention humaine, on a sûrement déjà résolu votre cas. On industrialise ce type de système chez des assureurs, des banques et des opérateurs depuis 2023. Premier cas en production en 6 à 8 semaines, forfait, résultat garanti.