OCR traditionnel vs VLM d'analyse de documents
Résultats du benchmark reçus (2026)

Le taux d'erreur de caractères (CER) mesure la fraction de caractères individuels mal lus — suppressions, insertions et substitutions divisées par les caractères de référence. C'est la mesure classique de l'OCR, et c'est là que le récit de la « supériorité des VLM » s'effondre sur les reçus anglais.

Sur SROIE 2019, les deux meilleurs reconnaisseurs de texte sont un VLM et un moteur traditionnel, séparés de 0,006 point : Surya2 à 0,191 et docTR à 0,197, avec PaddleOCR en troisième position (0,204). Les trois autres VLM — PaddleOCR-VL 0,337, Docling 0,591, Unlimited-OCR 0,655 — se situent à un niveau inférieur ou égal aux moteurs traditionnels comme EasyOCR (0,283) et Tesseract (0,335).

Exactitude des caractères par modèle sur SROIE (reçus anglais)

Source : summary_metrics.csv — colonne cer, lignes sroie_2019 (8 lignes). Surya2 0,1915, docTR 0,1971, PaddleOCR 0,2045, EasyOCR 0,2833, Tesseract 0,3347, PaddleOCR-VL 0,3370, Docling 0,5909, Unlimited-OCR 0,6552. Plus bas est meilleur. Tesseract est uniquement CPU.

Tableau : summary_metrics.csv — colonnes cer et wer, lignes sroie_2019, 361 échantillons chacune (error_rate 0.0 pour les 8 modèles). CER = taux d'erreur de caractères, WER = taux d'erreur de mots ; plus bas est meilleur. Valeurs exactes : Surya2 cer 0.19147 / wer 0.27352 ; docTR cer 0.19707 / wer 0.31990.

Le taux d'erreur de mots raconte la même histoire avec une granularité différente : il évalue les erreurs sur des mots entiers plutôt que des caractères. Surya2 mène le WER à 0.274, docTR suit à 0.320. Notez le cas particulier en bas : Unlimited-OCR a le pire CER (0.655) mais un WER dans la moyenne (0.478) — sa sortie est fortement normalisée en termes de casse et de format (une convention de sortie discutée dans la section méthodologie), ce qui gonfle les modifications au niveau caractère même lorsque les mots sont largement intacts.

Docling mérite une note de classification avant d'apparaître dans les comparaisons : ce n'est ni un moteur OCR traditionnel pur, ni un VLM. Docling est un analyseur en pipeline — une chaîne d'outils par étapes qui exécute l'analyse de mise en page, la détection de tableaux et la reconstruction de l'ordre de lecture autour d'un noyau OCR. Sur un ticket de caisse simple, cette surcharge de pipeline apporte peu, ce qui explique en partie pourquoi son CER brut (0,591 sur SROIE) est inférieur à celui des moteurs en passage unique.

Coût et latence : l'avantage des moteurs traditionnels

Si la précision des caractères ne tranche rien entre les deux familles, le coût et la latence décident de presque tout. Sur le même jeu de test, docTR maintient 449 pages/min à 108,7 ms p50 par page pour 0,048 $ pour 1 000 pages ; Surya2 maintient 12 pages/min à 2 668 ms p50 pour 1,061 $ pour 1 000 pages — soit environ 37× le débit, 24,5× la latence par page, et 22× le coût pour mille pages.

Le coût est calculé comme le temps d'exécution réel × le tarif RunPod RTX 4090 (0,76 $/heure, prix horodaté dans les manifests d'exécution) — le prix que vous paieriez réellement pour le temps GPU, y compris l'initialisation du modèle. Tesseract est le cas particulier : CPU uniquement, il n'a aucun coût GPU et gère quand même 78,6 pages/min sur SROIE ; sa cellule de coût est vide dans le CSV par conception, non pas parce qu'il est gratuit mais parce qu'il ne consomme pas d'heures GPU facturées.

Source : summary_metrics.csv — colonne latency_p50_ms, lignes sroie_2019. docTR 108,7, PaddleOCR 297,0, EasyOCR 413,6, Tesseract 670,9 (CPU), PaddleOCR-VL 694,3, Docling 732,0, Unlimited-OCR 1600,7, Surya2 2668,0. Latence en régime permanent, mode de mesure après chauffe (exclut le chargement du modèle).

Source : summary_metrics.csv — colonne cost_per_1000_pages, lignes sroie_2019. docTR 0,0479, EasyOCR 0,1098, PaddleOCR-VL 0,2048, PaddleOCR 0,2214, Unlimited-OCR 0,3879, Docling 0,3978, Surya2 1,0609. Tesseract CPU uniquement : cellule vide dans le CSV (pas de coût GPU) ; le coût inclut l'initialisation du modèle, pas le débit pur en régime permanent.

Tableau : summary_metrics.csv — latency_p50_ms / latency_p95_ms / pages_per_minute / cost_per_1000_pages, lignes sroie_2019. Exécutions GPU sur RTX 4090 ($0.76/hr, horodatage du prix dans les manifests) ; Tesseract exécuté en CPU uniquement (cellule de coût vide, pas zéro). Le débit est en pages/min temps réel incluant l'initialisation du modèle.

La colonne de latence de queue est importante si vous vous souciez du comportement en cas de pire scénario, et pas seulement des médianes. La p95 de PaddleOCR (3 331 ms) et celle de Docling (3 240 ms) s'éloignent de leurs valeurs p50 — les effets de première page et les pics de préremplissage dominent la queue sur les moteurs GPU — tandis que la p95 de docTR (281 ms) reste resserrée. Pour les charges de travail interactives (un utilisateur attendant une page), cet écart de p95 fait la différence entre une attente de 0,3 seconde et une attente de plus de 3 secondes.

CORD (Reçus indonésiens) : Inadéquation linguistique et surestimation de la vérité terrain

CORD v2 est un jeu de données de reçus en indonésien avec des champs imbriqués (menu, sub_total, total). Aucun des 8 moteurs n'a été principalement entraîné sur des reçus indonésiens, de sorte que CORD fonctionne comme un test de stress interlingue — et le CER de chaque moteur s'effondre à 0,90–1,08. Ces chiffres doivent être lus avec la réserve que le texte de vérité terrain de CORD intègre la structure d'annotation, ce qui gonfle le CER brut pour chaque moteur ; les résultats de CORD sont strictement séparés du classement SROIE et ne sont pas fusionnables dans un classement unique.

Deux forces distinctes poussent le CER de CORD vers 1,0, et l'une d'elles seulement est la langue elle-même. Premièrement, la langue : les moteurs entraînés sur l'anglais lisent réellement mal les mots indonésiens — les noms indonésiens, les adresses et les formats de devise (Rp) sont en dehors de leurs distributions d'entraînement. Deuxièmement, la vérité terrain : les annotations textuelles publiées de CORD intègrent la structure d'annotation (étiquettes de champs avec coordonnées) plutôt que le texte visible pur, de sorte que le CER brut mesure la distance d'édition par rapport à une chaîne structurellement augmentée. Les exemples de VLM les plus propres sont les plus pénalisés — PaddleOCR-VL avec un CER de 1,080 est l'artefact extrême de ce mécanisme, pas une lecture de la qualité de son texte.

La comparaison inter-familles équitable sur CORD est donc la métrique par champ, et non le CER (voir la section suivante). Ce que les colonnes de CER montrent encore utilement, c'est que l'inadéquation linguistique est réelle et universelle entre les architectures — chaque famille, traditionnelle et VLM alike, se retrouve dans la même bande de 0,90–1,08 sans avantage structurel pour l'une ou l'autre.

Tableau : summary_metrics.csv — colonne CER, lignes cord_v2, 100 échantillons chacune. Ne comparez pas ces chiffres à SROIE dans un classement combiné : le CER CORD combine une véritable inadéquation linguistique avec une inflation de la structure d'annotation dans la vérité terrain (méthodologie ci-dessous). Un CER supérieur à 1,0 (PaddleOCR-VL 1,0805) est un artefact de distance d'édition lié à cette vérité terrain gonflée.

F1 champ : Le post-traitement LLM unifie le terrain

La précision des caractères classe les moteurs ; l'extraction de champs est ce pour quoi les utilisateurs en production paient réellement. Le benchmark extrait quatre champs de reçus (entreprise, date, adresse, total) du texte OCR de chaque moteur à l'aide de deux post-traitants — des motifs regex fixes (l'approche OCR traditionnel + KIE basée sur des règles) et un LLM (deepseek-v4-flash) avec un prompt structuré. Résultat : le LLM efface presque l'écart entre les moteurs sur SROIE, tirant six des huit moteurs dans une fourchette de F1 champ de 0,57–0,62 — là où leurs résultats regex étaient étalés sur une plage de 0,26 point.

Le F1 champ-valeur est la moyenne harmonique de la précision et du rappel sur les valeurs de champ extraites, évaluées par rapport à la vérité terrain — 1,0 signifie que chaque valeur de champ est parfaitement extraite, 0 signifie que rien n'est récupéré. Les colonnes regex utilisent un ensemble de motifs fixe par jeu de données ; les colonnes LLM utilisent deepseek-v4-flash à température 0 pour une sortie déterministe (la colonne llm_model dans le CSV de comparaison). Les deux métriques mesurent des pipelines différents et ne sont jamais combinées.

Source : field_method_comparison.csv — colonnes regex_field_value_f1 / llm_field_value_f1, lignes sroie_2019 (décimales 0–1 affichées en %). Post-traitant LLM : deepseek-v4-flash (colonne llm_model). 361 échantillons par moteur (llm_ok_count).

Tableau : field_method_comparison.csv — regex_field_value_f1 / llm_field_value_f1, lignes sroie_2019. LLM = post-traitement deepseek-v4-flash (colonne llm_model). docTR regex 0.0766 → LLM 0.6171 (gain de 8,1×) ; les 6 moteurs performants s'étalent de 0,5685 à 0,6171.

Deux résultats contre-intuitifs se trouvent dans ce tableau. Premièrement, docTR a le pire F1 champ regex sur SROIE (0,077) et le meilleur F1 champ LLM (0,617) — le même texte OCR propre que le regex n'a exploité que pour 7,7 % des champs a rendu 61,7 % sous le LLM. Le post-traitement, et non l'OCR, était le goulot d'étranglement. Deuxièmement, les deux moteurs qui sortent de la bande 0,57–0,62 sont exactement les deux dont la base OCR est dégradée : EasyOCR (0,372, CER SROIE 0,283) et Tesseract — dont le résultat sur CORD (F1 champ LLM 0,163) montre qu'un LLM ne peut pas extraire des champs d'un texte qu'il ne peut fondamentalement pas lire (CER CORD 0,9523). Le plafond de tout post-traitement est la qualité de la base OCR sous-jacente.

Sur CORD, le LLM absorbe aussi une partie du choc linguistique : le F1 champ du LLM se maintient entre 0,47 et 0,55 pour les moteurs performants (PaddleOCR 0,553, docTR 0,550, PaddleOCR-VL 0,520, Surya2 0,520) bien que le regex s'effondre presque à zéro (docTR 0,0, EasyOCR 0,7%) — les motifs ont été écrits pour des formats anglais, et la pénalité d'une « langue supplémentaire » est payée presque entièrement par les règles, pas par le LLM (champ field_method_comparison.csv, llm_field_value_f1 / regex_field_value_f1, lignes cord_v2).

Pourquoi le CER sous-estime les VLM d'analyse de documents

Le CER compare la sortie du VLM et la vérité terrain caractère par caractère, et les VLM sont pénalisés pour deux comportements légitimes qui ne sont pas des erreurs de reconnaissance : la normalisation de la casse et la fusion étiquette/valeur. La décomposition du CER dans le benchmark sur SROIE attribue environ 18% du CER des VLM à des différences de format de casse (par ex., TAN CHAY YEE → tan chay yee) et environ 10% à la fusion de lignes ou à des lignes séparatrices omises — les valeurs des champs elles-mêmes (entreprise, total, date) étant en réalité correctes (analyse de décomposition du CER consignée dans les notes de protocole du benchmark, exécutions SROIE).

La tension de conception est réelle et structurelle : les moteurs OCR traditionnels produisent du texte brut avec la casse intacte, ils sont donc optimisés par conception pour l'évaluation par CER ; les VLM d'analyse de documents produisent du texte « compris » (casse normalisée, paires étiquette-valeur fusionnées, lignes réordonnées), ce qui est plus proche de ce qu'un système aval souhaite mais plus éloigné d'une correspondance exacte caractère par caractère. C'est pourquoi la page titre n'utilise le CER que lorsqu'il est une comparaison équitable entre sorties similaires, et pourquoi la comparaison inter-familles équitable se trouve dans les métriques par champ — et pourquoi le CER de CORD (qui subit en plus une inflation liée à la structure d'annotation) est isolé dans sa propre section. Le point plus large : un écart de CER entre familles n'est pas automatiquement un écart de précision, et quiconque compare des modèles de familles différentes doit vérifier ce que mesure le CER avant de conclure qu'une famille « lit mieux ».

Comment choisir : quel axe est important pour votre charge de travail

« Mieux » n'a pas de sens sans charge de travail. La conclusion honnête du benchmark est que les deux familles gagnent sur des axes différents, et les reçus mesurent spécifiquement les axes où les moteurs traditionnels gagnent et les axes où le post-traitement — et non la famille de moteurs — détermine la qualité des champs.

Les recommandations de sélection sont directement dérivées des lignes CSV citées ; il s'agit d'une aide à la lecture basée sur les données, et non d'une recommandation de fournisseur. Vos résultats exacts varient selon le matériel, le mélange de documents et les versions des modèles.

Foire aux questions

Les VLM d'analyse de documents sont-ils plus précis que l'OCR traditionnel pour les reçus ?

Pas en termes de précision brute des caractères — le meilleur VLM et le meilleur moteur traditionnel sont statistiquement à égalité sur SROIE 2019 (Surya2 CER 0,191 vs docTR 0,197, summary_metrics.csv lignes sroie_2019), et PaddleOCR (0,204) est troisième. Lorsque l'extraction de champs est l'objectif, qu'il s'agisse d'un VLM ou non, le post-traitement par LLM est le facteur déterminant (bande de convergence 0,57–0,62, field_method_comparison.csv).

Quand l'OCR traditionnel est-il plus pertinent qu'un VLM d'analyse de documents ?

Lorsque le volume est élevé, le coût est facturé à l'usage ou la latence doit être interactive. Sur SROIE, docTR a traité 449 pages/min à 0,048 $ pour 1 000 pages et 108,7 ms p50 ; Surya2 a traité 12 pages/min à 1,061 $ pour 1 000 pages et 2 668 ms p50 (summary_metrics.csv, lignes doctr et surya2 sroie_2019). Pour une attente interactive par page, la différence est de 0,1 seconde contre 2,7 secondes.

Pourquoi les VLM d'analyse de documents obtiennent-ils parfois un CER plus élevé que des OCR bas de gamme ?

Parce que le CER mesure les correspondances exactes de caractères, et les VLM sont pénalisés pour la normalisation de la casse et la fusion étiquette/valeur, qui sont des conventions de sortie, pas des erreurs de lecture. La décomposition du CER dans le benchmark attribue environ 18% du CER des VLM à des différences de format de casse et ~10% à la fusion de lignes/séparateurs supprimés — les valeurs des champs étant elles-mêmes souvent correctes (voir Méthodologie). Le CER de CORD est en outre gonflé par la structure d'annotation dans sa vérité terrain, c'est pourquoi cette page isole le CER de CORD de tout classement et utilise les métriques de champs pour les comparaisons inter-familles.

Combien coûte l'OCR de reçus par page sur un RTX 4090 ?

Entre $0,048 (docTR) et $1,061 (Surya2) pour 1 000 pages sur un RTX 4090 à $0,76/heure, prix horodaté en août 2026 dans les manifests d'exécution (summary_metrics.csv cost_per_1000_pages, lignes sroie_2019). Tesseract est uniquement CPU et n'utilise pas d'heures GPU. Le coût inclut l'initialisation du modèle, donc le coût par page diminue à mesure que la taille du lot augmente.

Pourquoi chaque modèle obtient-il un CER supérieur à 0,90 sur les reçus CORD ?

Deux causes cumulatives : une véritable inadéquation linguistique (reçus indonésiens en dehors du domaine d'entraînement de chaque moteur) et une inflation de la structure d'annotation dans le texte de référence de CORD. Aucune famille n'échappe à cela — les 8 modèles se situent dans la fourchette 0,90–1,08 (summary_metrics.csv cer, lignes cord_v2). CORD est un jeu de test de robustesse linguistique/structurelle, conservé séparément du classement SROIE.

Un LLM va-t-il simplement corriger ma mauvaise sortie OCR ?

Uniquement dans la limite de la qualité du texte de base. Sur SROIE, le LLM a propulsé six moteurs dans une fourchette de F1 champ de 0,57–0,62 quel que soit le moteur (field_method_comparison.csv), mais le cas CORD de Tesseract montre la limite : à un CER de 0,9523, son F1 champ avec LLM est de 0,163 — un LLM ne peut pas extraire des champs d'un texte qu'il ne peut pas lire.

Quel est l'OCR le plus rapide pour les reçus ?

docTR dans ce benchmark : 108,7 ms p50 par page et 449 pages/min sur SROIE 2019 (summary_metrics.csv doctr/sroie_2019 : latency_p50_ms, pages_per_minute). Le plus lent testé, Surya2, était 24,5× plus lent au p50 (2 668 ms) et 37× plus lent en débit (12 pages/min).

D'où viennent les chiffres de cette page ?

Chaque chiffre est une ligne des CSV publiés du benchmark interne — results/summary_metrics.csv (8 modèles × 2 jeux de données : CER/WER, F1 champ, latence, coût, débit) et results/field_method_comparison.csv (regex vs post-traitement LLM) — hébergés sur ImageToTableai/benchmark-ocr, avec un manifest.json par exécution pour les empreintes d'environnement. Les définitions des jeux de données proviennent des articles SROIE 2019 et CORD cités ci-dessous.

Méthodologie & Sources

Protocole

Cette page présente la comparaison de l'analyse de documents d'un benchmark indépendant et reproductible (niveau officiel) — pas une enquête sur les affirmations de tiers. Uniquement des ensembles de test fixes : SROIE 2019 test (361 reçus anglais, champs plats entreprise/date/adresse/total) et CORD v2 test (100 reçus indonésiens, champs imbriqués menu/sous_total/total) ; les ensembles d'entraînement n'ont jamais été évalués. Chaque paire (modèle × jeu de données) réutilise les mêmes images, la même vérité terrain et le même protocole de mesure (warm_then_scored : un passage de chauffage fixe précède le passage noté, de sorte que les chiffres de latence sont en régime permanent). Les 16 exécutions se sont terminées avec un error_rate de 0.0 (colonne error_rate de summary_metrics.csv).

Environnement d'exécution

• Matériel : toutes les exécutions GPU sur un NVIDIA RTX 4090 (24 Go) ; coût GPU calculé au tarif à la demande de RunPod de $0,76/heure, avec l'horodatage du prix enregistré dans le manifeste édité de chaque exécution (août 2026). Tesseract a fonctionné en CPU uniquement et n'a pas de coût GPU (cellule de coût vide dans le CSV).
• Moteurs : tous les modèles exécutés tels quels, sans affinage. Versions verrouillées selon les manifestes d'exécution.
• Post-traitement LLM : deepseek-v4-flash via API à température 0 pour une sortie déterministe (colonne llm_model dans field_method_comparison.csv) ; c'est le seul modèle utilisé pour toutes les lignes de champs LLM.
• Base de coût : temps d'exécution réel × $0,76/heure, incluant l'initialisation du modèle — le traitement par lots réduit le coût par page.
• Post-traitement des champs : les métriques de champs SROIE sont les variantes postprocessed_sroie_receipt_regex_* / LLM — c'est-à-dire des champs extraits du texte OCR par un ensemble de regex fixes ou le LLM. Elles mesurent l'OCR + l'extraction en aval, pas la sortie structurée native des modèles.

Versions telles qu'enregistrées dans la table des modèles du benchmark (README.md) et les manifestes édités par exécution (results/manifests/, un par exécution publiée, 16 au total) — chaque manifeste enregistre l'identifiant d'exécution, la version du modèle, le hash du script d'exécution, le GPU/pilote, les versions torch/CUDA/Python, le hash de pip-freeze, les métadonnées de coût avec horodatage du prix et les hash des artefacts pour la reproductibilité.

Définitions des métriques

• CER (Character Error Rate) : distance d'édition (insertions + suppressions + substitutions) entre le texte OCR et la vérité terrain, divisée par le nombre de caractères de la vérité terrain. Plus bas est meilleur. Sensible à la casse et aux conventions de formatage.
• WER (Word Error Rate) : le même calcul de distance d'édition au niveau du mot.
• F1 champ-valeur (regex) : moyenne harmonique précision/rappel sur les valeurs de champs extraites en utilisant des motifs regex fixes sur le texte OCR (pipeline OCR traditionnel + KIE basé sur des règles). Colonne : regex_field_value_f1.
• F1 champ-valeur (LLM) : la même métrique sur la sortie du postprocesseur LLM (texte OCR → deepseek-v4-flash → champs). Colonne : llm_field_value_f1. Les deux pipelines sont différents et ne sont jamais mélangés.
• Latence p50/p95 & pages/min : temps d'inférence par page en régime permanent (après chauffe, hors chargement du modèle) et débit en temps réel incluant l'initialisation du modèle.
• Coût pour 1 000 pages : heures GPU facturées pour 1 000 pages au tarif enregistré de 0,76 $/h ; vide pour Tesseract en CPU uniquement.

Liste des sources

1. summary_metrics.csv (GitHub raw). 16 lignes = 8 modèles × 2 jeux de données. Colonnes : model, compute_type, dataset, cer, wer, field_f1_regex, field_acc_regex, latency_p50_ms, latency_p95_ms, cost_per_1000_pages, pages_per_minute, error_rate. Tous les chiffres de CER/WER, latence, coût et débit de cette page proviennent d'une ligne ici.
2. field_method_comparison.csv (GitHub raw). 16 lignes ; colonnes model, dataset, llm_model (= deepseek-v4-flash), précision et F1 champ-valeur regex/llm, document-fields-exact, llm_median_latency_ms, compteurs de tokens. Tous les chiffres de F1 champ regex/LLM proviennent d'une ligne ici.
3. Dépôt ImageToTableai/benchmark-ocr. Dépôt public hébergeant les CSV de résultats, les manifests d'exécution caviardés, le protocole figé et les listes d'échantillons de jeux de données (partitions de test fixes) pour la reproduction.
4. results/manifests/ (GitHub). Un manifest.json caviardé par exécution publiée (16 exécutions) avec l'empreinte environnementale, la version du modèle, les métadonnées de coût et les hachages des artefacts.
5. Huang et al., « ICDAR2019 Competition on Scanned Receipt OCR and Information Extraction » (2019). Définition du jeu de données SROIE 2019, structure des tâches et licence (CC-BY-4.0).
6. Park et al., « CORD: A Consolidated Receipt Dataset for Post-OCR Parsing » (2020). Définition du jeu de données CORD v2, schéma de champs imbriqués et licence (CC-BY-4.0).

Limitations

• Périmètre des documents : Reçus uniquement (SROIE + CORD). Cette mesure ne couvre pas la gestion des mises en page/tableaux/formules, les documents longs ou les champs non liés aux reçus — les types de documents où les VLM d'analyse de documents revendiquent leurs plus grands avantages restent non mesurés ici. N'utilisez pas cette page pour conclure que « l'OCR traditionnel est meilleur partout ».
• Taille de l'échantillon : 361 reçus en anglais + 100 reçus en indonésien. Le F1 champ et le CER sont sensibles au corpus ; des différences d'un ou deux points de pourcentage doivent être traitées comme du bruit, pas comme une vérité technique.
• Classe GPU unique : tous les chiffres GPU proviennent d'un seul RTX 4090 à 0,76 $/h. D'autres GPU, un service multi-GPU ou une planification par lots modifieront la latence, le débit et le coût.
• Asymétrie CPU/GPU : Tesseract (CPU) est comparé à des moteurs accélérés par GPU ; sa latence/temps reflète le matériel CPU tandis que son avantage de coût reflète l'absence de facturation GPU. Cela est indiqué dans chaque tableau pertinent, mais l'asymétrie est inhérente à la comparaison.
• Le post-traitement LLM est un modèle unique : toutes les lignes de champs LLM utilisent deepseek-v4-flash. Un autre LLM produirait des F1 absolus différents ; l'ordre de convergence pourrait se déplacer en périphérie. La latence LLM (~1,8–2,4 s médiane, llm_median_latency_ms dans field_method_comparison.csv) est imputée à l'API et ne fait pas partie de la latence propre du moteur OCR.
• Horodatage des coûts : le prix GPU de 0,76 $/h a été enregistré dans les rapports d'exécution en août 2026. Les prix GPU spot/à la demande changent ; recalculez les coûts aux tarifs actuels avant de budgétiser.
• Le CER de CORD n'est pas une mesure de qualité : la vérité terrain CORD intègre la structure d'annotation et les moteurs n'ont pas été entraînés sur l'indonésien. Le CER de CORD (0,90–1,08 pour les 8 modèles) reflète l'inadéquation linguistique + la surestimation de la vérité terrain, pas la qualité de lecture par modèle ; les lignes CORD ne sont pas fusionnées dans aucun classement SROIE.
• Paramétrage des regex : l'ensemble de motifs regex a été écrit une seule fois par jeu de données. Une bibliothèque de motifs spécifique à un éditeur et fortement optimisée pourrait obtenir de meilleurs résultats sur ses propres formats — au prix de maintenance que le LLM supprime.
• Pas de modèles cloud/API : AWS Textract, Google Document AI, Azure AI Document Intelligence et les API VLM hébergées (par ex., services OCR cloud) ne sont pas inclus ; leur latence et leur modèle tarifaire diffèrent fondamentalement des moteurs locaux mesurés ici.
• Verrouillage des versions : les résultats sont valables pour les versions de modèles d'août 2026 listées ci-dessus ; les nouvelles versions de tout moteur peuvent modifier les résultats, et les latences p50 des deux mesures avec de fortes pointes p95 (PaddleOCR, Docling) reflètent les effets de préremplissage/première page sous le schéma de lots de cette exécution.

Références associées : Regex vs extraction de champs LLM · Précision au niveau champ vs au niveau caractère · Précision de l'OCR de reçus · Précision de l'OCR par type de document

Lectures associées : Précision de l'OCR IA vs OCR traditionnel · Extraction d'images IA vs OCR traditionnel · Tarification de l'extraction de documents IA (2026)