OCR en 2026 : pipelines classiques, VLMs et Document AI

Viacheslav Dubrov

2026-03-04 · Mis à jour 2026-08-10 · 16 min · Systèmes de recherche et de langage

Traduction automatique Cet article a été traduit automatiquement depuis la version originale en anglais.

Les classements OCR divergent parce qu’ils testent des documents, des sorties et des méthodes d’évaluation différents. Un instantané réalisé début 2026 d’OmniDocBench et d’OCR Arena a produit des ordres de classement très différents ; les scores ne sont pas interchangeables, mais ce désaccord est instructif. Un choix de production doit s’appuyer sur les documents et les métriques correspondant réellement à la charge de travail.

Les modèles vision-langage (VLMs) peuvent gérer la mise en page, l’écriture manuscrite, les tableaux et les images dégradées qui mettent en échec un pipeline classique de reconnaissance de texte. Les moteurs traditionnels restent compétitifs sur les impressions propres, en particulier lorsque la latence sur CPU et le coût d’exploitation sont déterminants. L’instantané daté ci-dessous inclut PaddleOCR-VL 1.6 et dots.mocr, avec des compromis différents en matière de matériel, de confidentialité et de format de sortie. Vérifiez chaque projet avant de prendre une décision actuelle.

Dépôt compagnon : The OCR Gauntlet contient trois notebooks. Son notebook principal compare jusqu’à cinq moteurs OCR sur cinq échantillons téléchargés et fournit le CER, le WER, l’ANLS, la latence et une estimation du coût. L’exécution versionnée contient Tesseract, Docling + Tesseract, Mistral OCR v3 et une exécution Gemini ; dots.ocr n’était pas disponible. N’utilisez pas la ligne Gemini pour comparer les modèles : le runner demande gemini-2.5-flash, alors que le notebook versionné identifie cette sortie comme Gemini 3 Flash.

Ce guide s’adresse aux ingénieurs qui choisissent un pipeline OCR ou de Document AI pour des charges de travail réelles où le texte, la mise en page, les tableaux ou les champs extraits sont importants.

Après sa lecture, vous devriez être capable de choisir une baseline, de comparer les modèles avec des métriques adaptées à la tâche et d’acheminer les champs incertains ou à haut risque vers une validation ou une revue.

En bref : Commencez par vérifier la présence d’une couche de texte intégrée. Évaluez un moteur traditionnel sur des scans propres, puis ajoutez un VLM spécialisé ou général uniquement pour les classes de documents qui n’atteignent pas le niveau de qualité cible. Comparez séparément les métriques du texte, des tableaux et des champs, puis acheminez les champs à faible confiance ou à haut risque vers un autre modèle ou un humain.

Pour une version compacte consacrée à la sélection des modèles, consultez Best OCR Models in 2026: Classical OCR, PaddleOCR-VL, VLMs.

L’OCR détermine désormais la qualité en aval

L’OCR alimente depuis longtemps les archives, les systèmes postaux, les outils d’accessibilité et la gestion documentaire. Le RAG et les agents documentaires ont rendu ses modes d’échec visibles pour un groupe plus large d’ingénieurs : un modèle en aval ne peut pas récupérer un texte ou une structure de tableau que l’extraction a supprimé.

La qualité de récupération de votre système RAG est plafonnée par la qualité de l’OCR. Si l’extraction déforme un tableau, interprète mal une date ou supprime un paragraphe, les modifications ultérieures du chunking et des embeddings ne peuvent pas récupérer l’information manquante. Ces erreurs peuvent masquer une clause contractuelle, modifier le montant d’une facture ou corrompre un dossier médical.

L’OCR fait donc partie de l’infrastructure de récupération et des agents, au même titre que le parsing, le chunking, les embeddings et l’indexation. Ses erreurs doivent faire l’objet d’une évaluation spécifique, plutôt que d’être absorbées dans un score unique de bout en bout.

Ce que signifie l’OCR à l’ère des foundation models

L’OCR convertit le texte présent dans une image en caractères lisibles par une machine. La Document AI désigne le système plus large qui l’entoure : analyse de la mise en page, parsing des tableaux et des formules, extraction de champs, raisonnement sémantique, provenance et validation. Certains articles utilisent « OCR-2.0 » pour désigner des modèles end-to-end qui combinent plusieurs de ces étapes, mais cette appellation ne doit pas effacer la distinction entre reconnaissance et compréhension documentaire.

Le pipeline OCR traditionnel comporte trois étapes principales :

1. Détection du texte : localiser les régions contenant du texte (par exemple CRAFT, DBNet).
2. Reconnaissance du texte : convertir les régions détectées en séquences de caractères (par exemple CRNN).
3. Post-traitement : correction orthographique et correction par modèle de langue.

Cette approche fonctionne bien sur les documents propres, mais les erreurs de détection, de reconnaissance et de post-traitement peuvent se cumuler. Mesurez à la fois la précision au niveau des caractères et celle des champs en aval, afin qu’une page lisible ne masque pas un montant ou un identifiant erroné.

OCR-2.0 regroupe une plus grande partie de ce pipeline dans un encodeur visuel et un décodeur de langue. Des modèles comme GOT-OCR 2.0 peuvent produire simultanément le texte et la structure, tandis que des VLMs généraux peuvent également associer les champs à un schéma demandé. Les compromis dépendent de la charge de travail : latence, coût des GPU ou des API, et risque de produire un texte plausible mais absent de l’image.

Une réserve pratique : ne vous laissez pas tromper par l’étiquette « end-to-end ». En production, OCR-2.0 unifie l’inférence du modèle, pas l’ensemble du pipeline documentaire. Vous avez toujours besoin d’une rastérisation des PDF pour produire les images, d’une normalisation des images (deskew, ajustement du DPI) pour obtenir une qualité homogène, et d’un parsing de la sortie pour extraire les champs structurés du texte du modèle. Le pipeline est plus court, il n’a pas disparu.

Ce que mesurent — et ne mesurent pas — les benchmarks OCR

Les datasets suivants montrent comment les tâches OCR produisent des métriques différentes. Les tailles des datasets et les métriques correspondent à la version indiquée ; utilisez le leaderboard actuel de chaque projet pour les scores des modèles.

L’écart entre « benchmark » et « arena »

Les classements issus de benchmarks automatisés peuvent être en conflit avec les préférences humaines, car la distribution des entrées et les critères d’évaluation diffèrent.

Dans OCR Arena, les utilisateurs votent à l’aveugle entre deux sorties. Le 2026-08-09, son classement en direct plaçait Gemini 3 Flash devant GLM-OCR et DeepSeek-OCR, tandis que le tableau versionné d’OmniDocBench présenté plus loin dans cet article classait les modèles documentaires spécialisés au-dessus de Gemini 3 Flash. Les résultats d’Arena évoluent après de nouveaux duels ; il s’agit donc d’un signal directionnel plutôt que d’un instantané de benchmark reproductible. Les deux leaderboards ne doivent pas être combinés en un score unique, car l’un utilise des métriques de dataset et l’autre des votes de préférence.

Les facteurs déterminants incluent probablement le type de documents, le format de sortie, la couverture linguistique et les critères d’évaluation. Les chiffres publiés sont utiles pour une première sélection, mais le choix final doit reposer sur un jeu de données de validation issu de la charge de travail cible.

Les moteurs OCR traditionnels restent pertinents

Si les moteurs traditionnels sont moins performants sur les données complexes, pourquoi les utiliser ? Parce qu’ils sont rapides et peu coûteux sur les données structurées et propres.

Les moteurs traditionnels constituent de bonnes baselines, car ils peuvent s’exécuter localement sur CPU. Leur latence et leur précision dépendent du modèle sélectionné, de la résolution des pages, de la langue, du prétraitement et du matériel. Évaluez-les donc sur les mêmes pages annotées que celles utilisées pour l’évaluation des VLMs.

Tesseract pour les impressions propres

Tesseract (v5.5.x, Apache 2.0) est un moteur mature fonctionnant uniquement sur CPU, avec plus de 100 packs linguistiques. La précision sur les impressions propres peut être élevée après une rastérisation et un prétraitement appropriés, mais l’écriture manuscrite, le texte dans les scènes et les mises en page complexes nécessitent des tests séparés. Son principal avantage est un déploiement local léger sur CPU, et non une supériorité universelle en matière de précision.

EasyOCR

EasyOCR associe un détecteur CRAFT à un reconnaisseur CRNN. Avec l’accélération GPU complète de PyTorch, c’est une option rapide pour le prototypage et le texte dans les scènes.

L’extrait nécessite pip install easyocr, PyTorch, les poids de modèle téléchargés par EasyOCR et un receipt.jpg local. Sa syntaxe est vérifiée, mais il n’est pas exécuté par le runner Markdown du dépôt.

import easyocr

# Three lines for complete OCR
reader = easyocr.Reader(["en"])
result = reader.readtext("receipt.jpg")
# Returns: [(bbox, text, confidence), ...]

PaddleOCR 3

PaddleOCR 3 regroupe des pipelines maintenus pour l’OCR, le parsing documentaire et le déploiement. Le quick start actuel utilise l’API predict() et des paramètres explicites d’orientation. Épinglez le package paddleocr et le pipeline sélectionné, car les exemples en 2.x utilisant .ocr(..., cls=True) ne correspondent pas à l’API 3.x.

L’extrait nécessite pip install "paddleocr>=3,<4", un runtime PaddlePaddle compatible, les poids de modèle téléchargés et un receipt.jpg local. Sa syntaxe est vérifiée, mais il n’est pas exécuté par le runner Markdown du dépôt.

from paddleocr import PaddleOCR

ocr = PaddleOCR(
    use_doc_orientation_classify=False,
    use_doc_unwarping=False,
    use_textline_orientation=False,
)

for result in ocr.predict("receipt.jpg"):
    result.print()
    result.save_to_json("output")

Options VLM spécialisées et générales

Les tickets de caisse froissés, les étiquettes de produits inclinées, l’écriture manuscrite et les mises en page denses sont les cas où les VLMs spécialisés ou généraux deviennent intéressants à tester face aux moteurs traditionnels.

La nouvelle génération d’OCR spécialisé

La liste de modèles de cette section correspond à l’instantané vérifié le 2026-08-09. Il ne s’agit pas d’un classement actuel. Parmi les modèles spécialisés de parsing documentaire publiés entre 2024 et 2026 figurent :

• PaddleOCR-VL 1.6 : un pipeline en deux étapes qui réalise une analyse de la mise en page, puis utilise un composant VLM de 0,9B sur les régions détectées. PaddleOCR annonce 109 langues et un score de 96,3 sur OmniDocBench v1.6 ; associez ce résultat du fournisseur au pipeline nommé et à la version du benchmark.
• dots.mocr (3B) : le successeur, publié en mars 2026, de dots.ocr-1.5. Il parse le texte et les graphiques structurés, notamment avec une variante orientée SVG. Le dots.ocr original reste un modèle distinct de 2025.
• GOT-OCR 2.0 : un modèle unifié de 580M paramètres qui produit du texte brut et des sorties formatées comme Markdown et LaTeX. Son dépôt officiel ne publie pas de valeur minimale de VRAM ; mesurez donc la mémoire maximale avec le runtime, la précision, la taille d’image et la limite de sortie choisis.
• DeepSeek-OCR2 : le checkpoint documenté dans le dépôt officiel à la date de l’instantané, qui succède au modèle DeepSeek-OCR original de classe 3B ayant introduit la « contextual optical compression ». Considérez les chiffres de débit des deux générations comme spécifiques au matériel et au dataset.
• Mistral OCR 4.0 (mistral-ocr-4-0), instantané du 2026-08-09 : le service propriétaire d’extraction de texte et de structure documenté par Mistral. OCR 3 (mistral-ocr-2512) reste disponible pour les intégrations existantes et correspond à la version utilisée par le notebook compagnon. Le compagnon utilise volontairement OCR 3 pour garantir la reproductibilité, et non parce qu’OCR 3 serait plus récent. Les tarifs et les chiffres de benchmark évoluent ; consultez donc la fiche du modèle et les conditions du fournisseur au moment de la comparaison.

VLMs frontier

Les VLMs généraux constituent une autre option lorsque la tâche combine extraction et raisonnement visuel ou sémantique. Les exemples ci-dessous reflètent l’instantané de l’article réalisé début 2026, et non un classement actuel :

• Qwen3-VL (Alibaba) : une famille de VLMs open-weight proposant plusieurs tailles et des variantes à long contexte.
• Gemini 3 Flash (Google) : un modèle multimodal hébergé qui figurait en bonne place dans l’instantané cité d’OCR Arena.
• Claude Opus 4.6 (Anthropic) : un VLM général hébergé prenant en charge les structured outputs.
• GPT-5.2 (OpenAI) : un VLM général hébergé pour les entrées visuelles et textuelles mixtes.

Mesurez la latence par niveau

Mesurez la latence par page avec la résolution réelle, la taille de batch, le matériel ou la région du fournisseur, ainsi que la longueur de sortie. Intégrez le prétraitement et les retries au total ; une mesure limitée au modèle ne permet pas d’évaluer le coût d’une page traitée avec succès.

Métriques : mesurer ce qui compte

Choisissez une métrique adaptée au type de sortie :

• CER et WER pour le texte brut. Le Character Error Rate et le Word Error Rate dépendent des choix de normalisation, comme la casse, les espaces et la ponctuation ; fixez donc le protocole de comparaison avant de comparer les modèles.
• EMR et Field F1 pour les formulaires et les tickets de caisse. L’Exact Match Rate est binaire, ce qui est souhaitable pour les identifiants fiscaux et les totaux. Le Field F1 équilibre la précision et le rappel pour chaque type de champ.
• TEDS pour les tableaux. La Tree-Edit-Distance-based Similarity compare les arbres HTML prédits et de référence, en détectant les erreurs structurelles et de contenu des cellules que le CER masque.
• ANLS pour la document VQA. L’Average Normalized Levenshtein Similarity accorde un crédit partiel aux réponses comportant de légères erreurs d’OCR.

Pour les implémentations : jiwer gère directement le CER/WER, et les implémentations de TEDS se trouvent dans le dépôt OmniDocBench.

Tester les VLMs avec OpenRouter

OpenRouter fournit une gateway compatible OpenAI donnant accès aux modèles de plusieurs fournisseurs. Les identifiants de modèles et les fonctionnalités de requête prises en charge évoluent ; vérifiez-les donc dans le catalogue actuel de la gateway avant d’exécuter l’exemple.

L’extrait nécessite pip install openai, une OPENROUTER_API_KEY, un accès réseau, un receipt.jpg local et des identifiants de modèles encore pris en charge par OpenRouter. Sa syntaxe est vérifiée, mais il n’est pas exécuté par le runner Markdown du dépôt.

import base64
import os
from openai import OpenAI

client = OpenAI(
    base_url="https://openrouter.ai/api/v1",
    api_key=os.environ["OPENROUTER_API_KEY"],
)

def extract_text(image_path: str, model: str) -> str:
    with open(image_path, "rb") as f:
        image_b64 = base64.b64encode(f.read()).decode()

    response = client.chat.completions.create(
        model=model,
        messages=[{
            "role": "user",
            "content": [
                {"type": "text", "text": "Extract all text from this image, preserving layout as markdown."},
                {"type": "image_url", "image_url": {"url": f"data:image/jpeg;base64,{image_b64}"}},
            ],
        }],
        max_tokens=4096,
    )
    return response.choices[0].message.content

# Compare models by changing one string
models = [
    "google/gemini-3-flash-preview",
    "anthropic/claude-sonnet-4.5",
    "qwen/qwen3-vl-8b-instruct",
]
for model in models:
    print(f"\n--- {model} ---\n{extract_text('receipt.jpg', model)[:200]}...")

Ces identifiants de modèles ont été vérifiés dans le catalogue OpenRouter le 2026-08-09. Consultez à nouveau le catalogue avant d’exécuter l’exemple.

Pour l’extraction structurée, utilisez response_format avec un schéma JSON lorsque le modèle et la gateway sélectionnés le prennent en charge. Cela peut rendre la réponse parsable ; cela ne valide pas les valeurs extraites par rapport à l’image. Le bloc suivant répète sa configuration afin de rester lisible indépendamment. Il nécessite également pip install openai, une OPENROUTER_API_KEY, un accès réseau, un receipt.jpg local et un modèle prenant en charge JSON Schema ; le runner du dépôt se contente d’en vérifier la syntaxe.

import base64
import json
import os
from openai import OpenAI

with open("receipt.jpg", "rb") as f:
    image_b64 = base64.b64encode(f.read()).decode()

client = OpenAI(
    base_url="https://openrouter.ai/api/v1",
    api_key=os.environ["OPENROUTER_API_KEY"],
)

response = client.chat.completions.create(
    model="google/gemini-3-flash-preview",
    messages=[{
        "role": "user",
        "content": [
            {"type": "text", "text": "Extract the receipt fields from this image."},
            {"type": "image_url", "image_url": {"url": f"data:image/jpeg;base64,{image_b64}"}},
        ],
    }],
    max_tokens=4096,
    response_format={
        "type": "json_schema",
        "json_schema": {
            "name": "receipt",
            "strict": True,
            "schema": {
                "type": "object",
                "properties": {
                    "vendor": {"type": "string"},
                    "date": {"type": "string"},
                    "items": {
                        "type": "array",
                        "items": {
                            "type": "object",
                            "properties": {
                                "description": {"type": "string"},
                                "amount": {"type": "number"},
                            },
                            "required": ["description", "amount"],
                            "additionalProperties": False,
                        },
                    },
                    "total": {"type": "number"},
                },
                "required": ["vendor", "date", "items", "total"],
                "additionalProperties": False,
            },
        },
    },
)
receipt = json.loads(response.choices[0].message.content)

Résultats des benchmarks : ce que montrent réellement les chiffres

Le tableau ci-dessous correspond à un instantané versionné : OmniDocBench v1.6_full, README officiel au commit 09ba2b606662695b16aafe5f5e36b7ef020e11a8, publié le 2026-04-10 et consulté le 2026-08-09. Les quatre lignes proviennent de ce tableau épinglé. Le tableau ne mélange pas des valeurs issues de tableaux d’articles antérieurs ou d’autres leaderboards.

La conclusion est limitée à cette version d’OmniDocBench : la taille du modèle ne permet pas, à elle seule, de prédire le score de parsing documentaire.

Le notebook compagnon calcule le CER, le WER, l’ANLS, la latence et le coût estimé sur ses cinq échantillons téléchargés. Excluez sa ligne Gemini mal étiquetée, sauf si l’identité du modèle est corrigée et que les échantillons sont réexécutés.

Déployer l’OCR en production

!!! byte « Byte dit »

J’ai fait confiance à la couche de texte intégrée d’un lot de PDF. Chaque caractère était correct, mais dans le mauvais ordre, ce qui a transformé chaque tableau en charabia.

Une architecture par niveaux peut séparer le prétraitement sur CPU de l’inférence sur GPU ou via API, et réserver les chemins coûteux aux documents qui le nécessitent.

Remarque sur l’orchestration : des outils comme Docling peuvent coordonner la conversion et le traitement par batch. La stratégie de retry reste du ressort de l’application ou du service environnant, et le routage nécessite toujours ses propres labels et seuils de qualité.

Le pattern de fallback par niveaux

Commencez par le chemin le moins coûteux qui atteint le niveau de qualité cible, puis calibrez le routage sur des pages annotées :

0. Vérifiez la présence d’un texte intégré (niveau 0). Pour les PDF, inspectez la couche de texte avec PyMuPDF ou pdfplumber avant la rastérisation, mais vérifiez que cette couche est complète et correctement ordonnée.
1. Tentez une extraction avec un modèle rapide. Utilisez un moteur traditionnel pour les classes de documents sur lesquelles il atteint la cible.
2. Évaluez une confiance calibrée. Combinez la confiance du modèle avec la classe du document, la criticité du champ et les règles de validation.
3. Passez à un modèle plus puissant. Acheminez les pages incertaines vers un VLM spécialisé ou général.
4. Transférez les échecs à haut risque à un humain. La revue humaine constitue un niveau distinct pour les valeurs dont le coût d’erreur dépasse le bénéfice de l’automatisation.

Remarque sur la confiance : les probabilités brutes au niveau des caractères ne sont pas automatiquement calibrées sur l’exactitude des champs. La fonction pondérée par l’aire ci-dessous constitue une baseline pour l’agrégation au niveau de la page, et non un routeur universel. Calibrez-la sur des pages annotées et définissez des règles spécifiques pour les champs critiques, car une moyenne par page peut masquer un identifiant ou un total erroné.

def area_weighted_confidence(page):
    """Compute area-weighted confidence from a PaddleOCR 3.x result."""
    total_area, weighted_sum = 0, 0
    for (x_min, y_min, x_max, y_max), score in zip(
        page["rec_boxes"], page["rec_scores"]
    ):
        area = (x_max - x_min) * (y_max - y_min)
        weighted_sum += score * area
        total_area += area
    return weighted_sum / total_area if total_area > 0 else 0

Analyse des coûts à grande échelle

Il n’existe pas de seuil universel de rentabilité selon le volume de pages entre une API et l’auto-hébergement. Construisez la comparaison à partir de la même charge de travail :

Utilisez une formule commune : monthly pages × cost per successful page + review cost + fixed operating cost. Une « page traitée avec succès » doit respecter les mêmes critères de texte, de tableaux et de champs sur les deux chemins. Les tarifs des fournisseurs et la location de GPU évoluent trop rapidement pour constituer une estimation d’achat durable.

Gestion des erreurs : le problème des hallucinations

Les erreurs des VLMs peuvent être plausibles dans leur contexte tout en étant factuellement fausses. Le total d’un ticket de caisse « $42.50 » peut devenir « $45.20 » : la valeur reste syntaxiquement valide, mais l’erreur échappe à un correcteur orthographique.

Exemple d’échec synthétique : un VLM extrait trois lignes d’un ticket et un total indiqué qui concordent entre eux, mais un chiffre diffère de l’image. Les calculs internes sont corrects, alors même que l’extraction est fausse. C’est pourquoi la validation doit s’appuyer sur des labels ancrés dans l’image ou sur un chemin de revue indépendant, et pas uniquement sur des contrôles de cohérence.

Quelques mesures pratiques :

• Réconciliation arithmétique. Lorsque le schéma les expose, vérifiez subtotal + tax + fees + shipping - discounts, dans la tolérance d’arrondi de la devise, par rapport au total indiqué. Acheminez vers la revue les composants manquants ou les incohérences.
• Contrôles de cohérence avec des regex pour les dates (pas de mois 13), les numéros de téléphone (nombre de chiffres correct) et les formats monétaires.
• Vérification inter-modèles. Faites passer les champs critiques dans deux modèles différents et signalez les divergences.
• Contre-vérification OCR indépendante. Exécutez un second chemin d’extraction sur les valeurs critiques et signalez les divergences. La concordance augmente la confiance uniquement lorsque les deux chemins présentent des modes d’échec suffisamment différents ; elle ne constitue pas une preuve d’exactitude.

Points clés

1. Associez le niveau de modèle à une classe de documents annotée. Les moteurs traditionnels peuvent suffire pour du texte propre ; les VLMs spécialisés et généraux doivent justifier leur coût supplémentaire sur les pages plus difficiles.
2. Ne fusionnez pas des leaderboards incomparables. Les métriques d’OmniDocBench et les préférences d’OCR Arena répondent à des questions différentes.
3. Calibrez le routage. Les seuils de confiance, les classes de documents, la criticité des champs et la politique de revue humaine doivent être évalués ensemble.
4. Validez les sorties plausibles. La conformité au schéma et l’arithmétique interne ne peuvent pas prouver qu’une valeur apparaît dans l’image.
5. Chiffrez les pages traitées avec succès. Incluez les retries, la revue, les coûts fixes d’exploitation et les quality gates lorsque vous comparez des API à l’auto-hébergement.

Le prétraitement et la détection restent importants, mais l’OCR en production nécessite désormais aussi du routage, une évaluation adaptée aux tâches et des protections contre les erreurs d’extraction plausibles.

Références

• OCR Arena Leaderboard - Duels de modèles en face à face, évalués par la communauté
• The OCR Gauntlet repo - Notebooks exécutables pour comparer les moteurs OCR, inspecter les sorties de Docling et estimer les coûts
• OmniDocBench - Évaluation end-to-end du parsing documentaire
• dots.ocr - Environ 3B paramètres au total, dont un modèle de langue de 1,7B
• PaddleOCR - Toolkit et modèles OCR traditionnels
• OpenRouter - Gateway d’accès unifié pour les tests A/B de modèles