OCR : la reconnaissance de texte, entre pipelines classiques et VLM

Troisième arrêt du dossier sur IA : LLM, VLM, OCR... le panorama des familles de modèles : l’OCR, la reconnaissance optique de caractères. C’est la famille la plus ancienne du lot (les premiers systèmes datent du tri postal des années 1950¹), mais elle vient de vivre un vrai renouveau sous l’effet des VLM.

L’objectif : extraire du texte, rien d’autre

Là où un VLM (voir l’article sur les VLM : quand un modèle d’IA sait lire une image) raisonne sur une scène visuelle entière et répond à des questions ouvertes, un moteur OCR a un objectif plus étroit et plus mécanique : transformer une image contenant du texte (facture scannée, plaque d’immatriculation, formulaire) en texte brut exploitable. Trois familles techniques voisines sont souvent confondues : l’OCR s’occupe des caractères imprimés standardisés, l’ICR (Intelligent Character Recognition) gère l’écriture manuscrite cursive¹.

Le pipeline classique

Pendant longtemps, l’OCR reposait sur un pipeline en plusieurs étapes bien distinctes¹ :

1. Layout analysis : repérer les colonnes, en-têtes, tableaux et images à exclure.
2. Segmentation : isoler chaque caractère ou chaque ligne.
3. Classification : reconnaître chaque caractère, historiquement via des architectures CRNN (un CNN pour extraire les traits visuels, un RNN pour gérer la séquence).
4. Post-traitement : correction linguistique (“teh” devient “the”), reconstruction de la structure des tableaux.

flowchart LR
    A[Image du document] --> B[Analyse de mise en page]
    B --> C[Segmentation des caractères/lignes]
    C --> D[Classification<br/>CRNN ou VLM]
    D --> E[Post-traitement<br/>correction, structure]
    E --> F[Texte structuré]

Le tournant VLM

Depuis 2025-2026, les architectures vision-langage plient tout ce pipeline en une seule passe : le modèle lit la page comme une scène visuelle complète, mise en page comprise, plutôt que caractère par caractère¹. Mistral OCR 4, sorti en juin 2026, illustre bien la tendance : ce VLM gère 170 langues et plusieurs formats de documents, et ne se contente pas de reconnaître les mots, il comprend aussi la structure du document². D’autres acteurs (LightOn, Datalab, Baidu, DeepSeek, PaddlePaddle) misent sur des VLM dédiés à l’OCR plutôt que sur des LLM multimodaux généralistes jugés trop coûteux pour cette tâche².

OCR spécialisé ou VLM généraliste : le vrai arbitrage 2026

Le paysage se répartit aujourd’hui en trois approches, avec des compromis très différents :

• Les pipelines classiques légers (Tesseract, PaddleOCR) : toujours utiles pour du traitement CPU, hors-ligne, déterministe et à gros volume.
• Les VLM spécialisés OCR (Mistral OCR, GLM-OCR, PaddleOCR-VL) : le meilleur rapport précision/coût sur l’extraction pure, avec des pipelines auto-hébergés jusqu’à environ 167 fois moins chers par page qu’un appel à une API vision généraliste³.
• Les LLM multimodaux généralistes (Gemini, Claude, GPT) : plus chers à l’usage, mais capables de raisonner sur le contenu extrait, pas seulement de le lire. Utile quand la tâche dépasse l’extraction (“resume-moi ce contrat” plutôt que “extrais le texte de ce contrat”).

Beaucoup de pipelines de production combinent d’ailleurs les deux : un modèle spécialisé pour l’extraction en masse, un LLM pour les documents qui demandent une analyse plus fine³.

Cas d’usage concrets

Facture ou reçu à classer automatiquement, formulaire papier à numériser, extraction de tableaux depuis un PDF, lecture de plaques d’immatriculation, ou passage préalable avant d’indexer un document dans un système de recherche sémantique (voir l’article sur les Embeddings et reranking : les briques invisibles derrière le RAG).