OCR en 2026 : pipelines classiques, VLMs et Document AI

Viacheslav Dubrov

2026-03-04 · Mis à jour 2026-09-06 · 19 min · Systèmes de recherche et de langage

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

Mise à jour de l’article

Publié initialement le 4 mars 2026. Relu et mis à jour le 6 septembre 2026. Cette mise à jour ajoute de nouveaux candidats en OCR et en modèles de vision, des références de benchmarks et des recommandations pour interpréter les résultats d’extraction documentaire.

Les classements OCR ne concordent pas parce qu’ils testent des documents, des sorties et des évaluateurs différents. Le tableau versionné du benchmark OmniDocBench et les votes de préférence en temps réel d’OCR Arena peuvent produire des ordres différents ; leurs scores ne sont pas interchangeables, mais ce désaccord est utile. Un choix de production doit s’appuyer sur les documents et les métriques de la charge réelle.

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 simple de reconnaissance de texte. Les moteurs traditionnels restent compétitifs sur les documents imprimés propres, en particulier lorsque la latence CPU et le coût d’exploitation sont importants. 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 faire un choix actuel.

Dépôt associé : The OCR Gauntlet contient trois notebooks pédagogiques et cinq exemples téléchargés. Il s’agit d’une démonstration de smoke test, et non d’un classement validé des moteurs. Dans la révision examinée, les labels Docling ne sélectionnent pas toujours correctement le pipeline annoncé, les références de reconnaissance de reçus incluent des clés d’annotation, les échecs disparaissent des moyennes et la requête Gemini utilise gemini-2.5-flash alors que le notebook l’étiquette Gemini 3 Flash. Son ANLS sur la page entière et ses scénarios de coût doivent également être interprétés séparément. Ces défauts d’implémentation doivent être corrigés avant d’utiliser ses scores pour choisir un modèle.

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 de texte, de tableaux et de champs, et acheminez les champs à faible confiance ou à haut risque vers un autre modèle ou vers un humain.

Pour la version compacte consacrée à la sélection de 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, lit 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 total 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 l’analyse, le chunking, les embeddings et l’indexation. Ses erreurs doivent faire l’objet d’une évaluation dédiée plutôt que d’être absorbées dans un score de bout en bout unique.

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, analyse 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 des caractères et celle des champs en aval afin qu’une page lisible ne masque pas un total ou un identifiant erroné.

Certains chemins VLM end-to-end regroupent davantage d’étapes du pipeline dans un encodeur de vision et un décodeur de langage. Des modèles comme GOT-OCR 2.0 peuvent produire simultanément le texte et la structure, tandis que des VLMs généralistes peuvent également mapper les champs vers un schéma demandé. Les compromis dépendent de la charge : latence, coût GPU ou API et risque de produire un texte plausible absent de l’image.

Point pratique : un modèle qui ne travaille qu’à partir d’images a besoin de pages rasterisées, tandis qu’un service acceptant des PDF peut gérer lui-même la conversion. Le deskewing, le redimensionnement et le nettoyage sont des expériences propres au pipeline, et non des améliorations obligatoires. AWS Textract recommande de préserver les entrées prises en charge plutôt que de les convertir ou de les sous-échantillonner systématiquement. Le parsing et la validation des sorties relèvent toujours de l’application.

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

Les datasets suivants illustrent la manière dont les tâches OCR produisent des métriques différentes. Les tailles et les métriques décrivent la version nommée du dataset ; utilisez le leaderboard actuel de chaque projet pour les scores des modèles.

Les nombres de lignes d’IAM dépendent du split de rédacteur choisi et du protocole de reconnaissance ; aucun nombre unique de lignes de test n’est supposé ici.

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

Les classements automatisés de benchmarks peuvent contredire 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 sur des sorties comparées deux à deux. Son classement en temps réel évolue à mesure que de nouveaux duels arrivent ; il ne s’agit donc pas d’un instantané historique reproductible d’un benchmark. Le tableau versionné d’OmniDocBench présenté plus loin répond à une autre question, avec des métriques de dataset. Ne combinez pas les deux leaderboards en un score unique.

Les facteurs probables incluent le type de documents, le format de sortie, la couverture linguistique et les critères de jugement. Les chiffres publiés sont utiles pour effectuer un premier filtrage, mais la sélection finale nécessite un jeu de test mis de côté et représentatif de la charge 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 bons 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 documents imprimés propres

Tesseract (v5.5.x, Apache 2.0) est un moteur mature, principalement CPU, qui propose plus de 100 packs linguistiques. La précision sur les impressions propres peut être élevée après une rasterisation et un prétraitement adaptés, mais l’écriture manuscrite, le texte dans les scènes et les mises en page complexes nécessitent des tests distincts. Son principal avantage est un petit déploiement local sur CPU. La prise en charge expérimentale d’OpenCL ne démontre pas un avantage général en matière de performances.

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 d’EasyOCR et un receipt.jpg local. Il est vérifié syntaxiquement, mais 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, l’analyse documentaire et le déploiement. Le quick start actuel utilise l’API predict() et des paramètres d’orientation explicites. Épinglez le package paddleocr et le pipeline sélectionné, car les exemples de 2.x utilisant .ocr(..., cls=True) ne correspondent pas à l’API de 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. Il est vérifié syntaxiquement, mais 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éralistes

Les reçus déformés, les étiquettes de produits inclinées, l’écriture manuscrite et les mises en page denses sont les cas où il devient pertinent de tester des VLMs spécialisés ou généralistes face aux moteurs traditionnels.

La vague des OCR spécialisés

La liste de modèles de cette section a été vérifiée le 06/09/2026. Il ne s’agit pas d’un classement actuel. Les modèles spécialisés dans l’analyse documentaire publiés entre 2024 et 2026 incluent :

• PaddleOCR-VL 1.6 : Pipeline en deux étapes qui effectue d’abord l’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 toujours ce résultat du fournisseur au pipeline et à la version du benchmark nommés.
• dots.mocr (3B) : Le rebranding de mars 2026 de dots.ocr-1.5 analyse le texte et les graphiques structurés, avec notamment une variante orientée SVG. Le dots.ocr original reste un modèle 2025 distinct.
• GOT-OCR 2.0 : Modèle unifié de 580M de paramètres qui produit du texte brut et des sorties formatées telles que 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 : Checkpoint documenté dans le dépôt officiel à la date de l’instantané, successeur du modèle DeepSeek-OCR original de classe 3B, qui avait introduit la « contextual optical compression ». Considérez les chiffres de débit de l’une ou l’autre génération comme spécifiques au matériel et au dataset.
• Mistral OCR 4.1 (mistral-ocr-4-1) : Sa model card date la sortie du 16 juillet 2026 ; le changelog indique la disponibilité générale le 31 août. Le modèle ajoute une confiance par bloc aux boîtes de paragraphes et aux labels structurels. Calibrez la confiance par rapport à l’exactitude des champs avant toute acceptation automatique. L’identifiant OCR 3 du projet associé correspond à un contexte d’exécution historique, et non au candidat ou au prix actuels. Épinglez une version explicite pour les comparaisons ; un alias latest peut changer.
• Granite-Docling 258M : Produit des DocTags qui peuvent être convertis en DoclingDocument structuré. Le pipeline VLM de Docling doit être sélectionné explicitement ; le fait qu’un converter par défaut soit utilisé ne prouve pas que ce modèle a été exécuté.
• MinerU et olmOCR : Candidats respectivement pour la conversion structurée et la linéarisation documentaire. Inspectez leurs pipelines complets et les licences des modèles sélectionnés. Les conditions applicables aux modèles de MinerU ajoutent des contraintes à la base Apache 2.0 ; la licence de la bibliothèque seule ne suffit donc pas à déterminer les droits de déploiement.

VLMs de pointe

Les VLMs généralistes constituent une autre option lorsque la tâche combine extraction et raisonnement visuel ou sémantique. Ces candidats ont été vérifiés le 06/09/2026 et sont utilisés dans l’exemple de gateway ci-dessous. Il s’agit d’une shortlist de départ, et non d’un classement OCR :

• Gemini 3.8 Flash (Google) : Modèle multimodal généralement disponible, avec entrée image et sorties structurées. Utilisez son identifiant stable pour commencer une nouvelle comparaison plutôt que l’ancien exemple Gemini 3 Flash Preview.
• Claude Sonnet 5 (Anthropic) : Nouvelle génération Sonnet destinée à une comparaison hébergée. Testez la fidélité de transcription et l’extraction des champs sur vos propres documents ; les améliorations générales du raisonnement ne démontrent pas une meilleure précision OCR.
• Qwen3.8-27B (Alibaba) : Modèle vision-langage à poids ouverts, testable via une gateway ou en auto-hébergement. Sa taille de 27B en fait un choix de déploiement différent du Qwen3-VL 8B précédent, qui reste un baseline plus petit utile lorsque la mémoire est limitée.

Une version plus récente mérite une place dans le jeu de test, mais pas une promotion automatique en production. Comparez l’exactitude des champs, l’abstention, la latence et le coût par document accepté selon un protocole identique.

Mesurer la latence par niveau

Mesurez la latence par page avec la résolution réelle, la taille des batchs, le matériel ou la région du fournisseur et la longueur de sortie. Incluez le prétraitement et les retries dans le total ; une mesure limitée au modèle ne permet pas de tarifer une page réussie.

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, tels que la casse, les espaces et la ponctuation ; fixez donc le protocole de comparaison avant de comparer les modèles.
• Exact match des champs et Field F1 pour les formulaires et les reçus. L’exact match est binaire pour un champ ; son taux correspond à la fraction des champs évalués qui réussissent. Rapportez séparément l’exactitude document-level sur l’ensemble des champs. Pour le Field F1, définissez la correspondance clé/valeur, la normalisation, les champs dupliqués ou manquants et l’agrégation ; un montant correct associé à la mauvaise ligne est une erreur.
• 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 de structure et de contenu des cellules que le CER masque.
• Comparaison de l’ordre de lecture lorsque le consommateur a besoin d’une séquence linéaire unique. Comparez directement les blocs ou spans ordonnés, ou utilisez une métrique tenant compte de l’ordre ; OmniDocBench évalue séparément l’ordre de lecture. Des caractères et des cellules de tableau corrects ne garantissent pas l’ordre d’une page à plusieurs colonnes.
• ANLS pour la VQA documentaire. L’Average Normalized Levenshtein Similarity compare les réponses à des références acceptées. La définition originale de ST-VQA attribue 1 − normalized_distance uniquement lorsque la distance est strictement inférieure à 0,5 ; sinon, le score est nul. Elle conserve le meilleur score parmi les références acceptées et calcule la moyenne sur les questions. DocVQA adopte ANLS. Fixez la casse, les espaces et la normalisation de la distance utilisées par l’évaluateur lorsque vous reproduisez un score. Le projet associé évalue à la place des chaînes correspondant à la page entière et inclut la borne 0,5 ; sa variante ne correspond donc pas au protocole du benchmark.

Les CER/WER comptent les substitutions, suppressions et insertions divisées par le nombre de caractères ou de mots de référence. Ils peuvent dépasser un lorsque les insertions dominent. Précisez si l’agrégation additionne les erreurs et les longueurs de référence sur l’ensemble du corpus ou si elle moyenne les scores par document. Conservez la page, le bloc, la bounding box, le texte original et l’historique de normalisation afin de pouvoir remonter d’un champ erroné jusqu’à l’image.

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

Tester les VLMs avec OpenRouter

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

L’extrait nécessite pip install openai, un OPENROUTER_API_KEY, un accès réseau, un receipt.jpg local et des identifiants de modèles encore pris en charge par OpenRouter. Il est vérifié syntaxiquement, mais 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,
    )
    choice = response.choices[0]
    if choice.finish_reason != "stop":
        raise RuntimeError(f"{model} did not finish: {choice.finish_reason}")
    if not choice.message.content:
        raise RuntimeError(f"{model} returned no text (finish_reason={choice.finish_reason})")
    return choice.message.content

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

Le catalogue de modèles OpenRouter listait google/gemini-3.8-flash, anthropic/claude-sonnet-5 et qwen/qwen3.8-27b avec entrée image et paramètres de sortie structurée le 06/09/2026. La prise en charge indiquée dans le catalogue ne prouve pas que cette requête exacte réussira sur chaque endpoint routé ; aucune inférence payante n’a été exécutée pour cette mise à jour.

Pour l’extraction structurée, utilisez response_format avec un schéma JSON lorsque le modèle sélectionné et la gateway le prennent en charge. Cela peut rendre la réponse parsable ; cela ne valide pas les valeurs extraites par rapport à l’image. Avec OpenRouter, provider.require_parameters fait échouer la requête lorsqu’aucun endpoint routé ne prend en charge tous les paramètres demandés, au lieu de basculer vers un endpoint incapable de respecter le schéma. Le bloc suivant répète sa configuration afin d’être lisible indépendamment. Il nécessite toujours pip install openai, un 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 de le vérifier syntaxiquement.

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.8-flash",
    messages=[{
        "role": "user",
        "content": [
            {"type": "text", "text": "Extract only visible receipt fields. Copy amounts as source strings. Use null for absent or unreadable values; do not infer them. Use null for an unreadable item list, and [] only when no items are present."},
            {"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", "null"]},
                    "date": {"type": ["string", "null"]},
                    "items": {
                        "type": ["array", "null"],
                        "items": {
                            "type": "object",
                            "properties": {
                                "description": {"type": ["string", "null"]},
                                "amount": {"type": ["string", "null"]},
                            },
                            "required": ["description", "amount"],
                            "additionalProperties": False,
                        },
                    },
                    "total": {"type": ["string", "null"]},
                },
                "required": ["vendor", "date", "items", "total"],
                "additionalProperties": False,
            },
        },
    },
    extra_body={"provider": {"require_parameters": True}},
)

def completed_text(response, label: str) -> str:
    choice = response.choices[0]
    if choice.finish_reason != "stop":
        raise RuntimeError(f"{label} did not finish: {choice.finish_reason}")
    if not choice.message.content:
        raise RuntimeError(
            f"{label} returned no text (finish_reason={choice.finish_reason})"
        )
    return choice.message.content

receipt = json.loads(completed_text(response, "receipt extraction"))

Conservez les chaînes de montants copiées à côté des valeurs normalisées. Effectuez le parsing monétaire en aval avec une arithmétique décimale ou entière en unités mineures, dans le cadre d’une devise et d’une locale explicites ; la validité du schéma ne valide pas un total de paiement. Acheminez les champs critiques nuls vers une revue.

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 10/04/2026 et consulté le 09/08/2026. Les quatre lignes proviennent de ce tableau épinglé. Le tableau ne mélange pas des valeurs provenant 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 prédit pas à elle seule le score d’analyse documentaire. OmniDocBench a ensuite enregistré la v1.7 et son intégration à EvalScope. Des modifications de la correspondance entre prédictions et références peuvent modifier les scores même lorsque la sortie du modèle est identique. Conservez les lignes historiques ci-dessus ; ne comparez les nouveaux runs qu’avec un évaluateur épinglé unique. Le score composite inclut la distance d’édition du texte, le TEDS des tableaux et le CDM des formules ; l’ordre de lecture nécessite son propre résultat.

Le projet associé calcule des métriques illustratives sur cinq exemples. Vérifiez l’identité du pipeline, les références de reconnaissance, le comptage des échecs, les noms des modèles, le protocole de métriques et les hypothèses de coût avant d’interpréter une ligne comme une preuve comparative.

Déployer l’OCR en production

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

Remarque sur l’orchestration : des outils tels que 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 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érifier la présence d’un texte intégré (niveau 0). Pour les PDF, inspectez la couche de texte avec PyMuPDF ou pdfplumber avant de rasteriser, mais validez qu’elle est complète et correctement ordonnée.
1. Essayer un modèle rapide. Utilisez un moteur traditionnel pour les classes de documents sur lesquelles il atteint la cible.
2. Évaluer 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. Passer à un modèle plus puissant. Acheminez les pages incertaines vers un VLM spécialisé ou général.
4. Transférer 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 des caractères ne sont pas automatiquement calibrées sur l’exactitude des champs. La fonction pondérée par la surface ci-dessous est une baseline pour l’agrégation au niveau de la page, et non un routeur universel. Calibrez-la sur des pages annotées et attribuez leurs propres règles aux 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 one 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"]
    ):
        width = int(x_max) - int(x_min)
        height = int(y_max) - int(y_min)
        area = width * height
        weighted_sum += score * area
        total_area += area
    return weighted_sum / total_area if total_area > 0 else 0

assert area_weighted_confidence({
    "rec_boxes": [[0, 0, 300, 300]], "rec_scores": [0.5]
}) == 0.5

Pour chaque paire moteur/document prévue, conservez un résultat avec un statut de réussite, d’erreur ou d’omission. Les sorties échouées, vides et tronquées restent dans le dénominateur des documents tentés, avec le coût engagé. Rapportez le taux de complétion, les erreurs de champs critiques parmi les acceptations automatiques, la fraction envoyée en revue, la latence end-to-end p50/p95 et le coût par document traité avec succès. Réutilisez les objets de conversion pour mesurer les temps à chaud et consignez séparément l’initialisation.

Analyse des coûts à grande échelle

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

Utilisez une formule commune : monthly pages × cost per successful page + review cost + fixed operating cost. Une « page réussie » doit satisfaire les mêmes critères de texte, de tableau et de champs sur les deux chemins. Les prix des fournisseurs et la location de GPUs é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. Un total de reçu « $42.50 » peut devenir « $45.20 » : syntaxiquement valide, mais invisible pour un correcteur orthographique.

Exemple d’échec synthétique : un VLM extrait trois lignes d’un reçu et un total indiqué qui concordent, mais un chiffre diffère de l’image. Les calculs internes sont corrects alors que l’extraction est erronée. C’est pourquoi la validation nécessite des labels ancrés dans l’image ou un chemin de revue indépendant, et pas uniquement 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, avec 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 par 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 cross-model. 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 ont des modes d’échec suffisamment différents ; elle ne constitue pas une preuve de correction.

Points clés

1. Adaptez le niveau du 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éralistes 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. Tarifez les pages réussies. Incluez les retries, la revue, les opérations fixes et les contrôles qualité lors de la comparaison entre APIs et auto-hébergement.

Le prétraitement et la détection restent importants, mais l’OCR de production nécessite désormais aussi du routage, une évaluation spécifique à la tâche et des protections contre les erreurs d’extraction plausibles.

Références

• OCR Arena Leaderboard — Duels de modèles en face à face issus de votes participatifs
• Le dépôt The OCR Gauntlet — Notebooks exécutables pour comparer les moteurs OCR, inspecter les sorties Docling et estimer les coûts
• OmniDocBench — Évaluation end-to-end de l’analyse documentaire
• dots.ocr — Environ 3B paramètres au total, dont un modèle de langage de 1,7B
• PaddleOCR — Toolkit et modèles OCR traditionnels
• OpenRouter — Gateway d’accès unifiée pour les tests A/B de modèles