EasyOCR vs docTR sur les reçus
Champion de la vitesse vs extracteur de champs (2026)

Les deux moteurs représentent deux générations d'OCR par deep learning, tous deux du côté traditionnel du fossé OCR-VLM. EasyOCR (basé sur PyTorch, 1.7.2) est un reconnaisseur classique à passage unique CNN + RNN + CTC — un extracteur de caractéristiques ResNet alimentant un modèle séquentiel décodé par classification temporelle connexionniste, avec un raffinement par attention. Son centre de conception est une couverture très large de langues et d'écritures (80+ langues prêtes à l'emploi) et une installation notoirement simple. docTR (v1.0.1) est un pipeline neuronal moderne en deux étapes : une étape de détection localise les régions de texte, puis une étape de reconnaissance les transcrit — construit autour d'une détection par transformateur de type DETR et d'un reconnaisseur à transformateur, conçu pour la précision sur les documents imprimés. Le taux d'erreur par caractère (CER) mesure les insertions, suppressions et substitutions divisées par les caractères de référence — un CER de 0,197 signifie environ 19,7 caractères mal lus pour 100 ; le taux d'erreur par mot (WER) applique la même logique de distance d'édition au niveau du mot entier. Plus bas est mieux sur les deux. Aucun des deux moteurs n'est un modèle vision-langage (VLM) — les deux produisent du texte brut, pas une structure comprise.

Précision textuelle sur SROIE (reçus anglais) : l'avantage net de docTR

Sur les 361 reçus anglais de la partition de test SROIE 2019, l'architecture moderne gagne sur les deux métriques textuelles : CER 0,1971 contre 0,2833 (amélioration relative de 30 %) et WER 0,3199 contre 0,6158 — le WER d'EasyOCR est presque le double. L'écart de WER (48 %) est bien plus grand que l'écart de CER (30 %), ce qui indique qu'EasyOCR cumule les erreurs au niveau des caractères en échecs au niveau du mot entier sur ce corpus. Les deux moteurs fonctionnent sans erreur (error_rate 0,0 sur chaque ligne SROIE et CORD du CSV). Aucun des deux moteurs n'est le champion global du CER du benchmark — ce titre revient à Surya2 (0,1915) et docTR lui-même se classe deuxième ; EasyOCR se classe quatrième sur huit.

Source : summary_metrics.csv — colonnes cer et wer, lignes sroie_2019. docTR cer 0,19707 / wer 0,31990 ; EasyOCR cer 0,28327 / wer 0,61578. Plus bas est mieux. 361 échantillons par moteur ; les deux error_rate 0,0.

Table : summary_metrics.csv — colonnes cer / wer / error_rate, lignes sroie_2019. Valeurs exactes : docTR cer 0,19707 / wer 0,31990 ; EasyOCR cer 0,28327 / wer 0,61578. Écarts relatifs : CER 30 % inférieur, WER 48 % inférieur pour docTR. Un CER/WER plus bas est meilleur. Contexte du classement CER au sein de la même exécution de 8 moteurs : Surya2 0,1915, docTR 0,1971, PaddleOCR 0,2045, EasyOCR 0,2833 (summary_metrics.csv, cer, lignes sroie_2019).

L'inversion regex-champ : un texte moins bon, des champs plus récupérables

Faites passer le texte brut des deux moteurs dans les mêmes motifs regex fixes sur les quatre champs de reçu SROIE (entreprise, date, adresse, total) — l'approche traditionnelle OCR + extraction d'informations clés (KIE) par règles — et le classement s'inverse : EasyOCR extrait les champs à 0,1477 de F1 sur les champs contre 0,0766 pour docTR, soit un avantage de 1,93× pour le moteur ayant la moins bonne précision de caractères. C'est l'inversion récurrente « précision du texte ≠ précision des champs » du benchmark — le même schéma observé entre l'OCR traditionnel et les VLM de parsing de documents sur docTR vs Surya2 — qui se produit désormais entre deux moteurs traditionnels produisant le même type de texte brut en lignes.

Le F1 sur les valeurs de champ est la moyenne harmonique de la précision et du rappel sur les valeurs de champ extraites par rapport à la vérité terrain : 1,0 signifie que chaque champ du reçu est parfaitement récupéré, 0 signifie que rien ne l'est. Le mécanisme derrière cette inversion est une propriété de l'ensemble de motifs regex, pas de la qualité de reconnaissance en soi : les motifs ont été écrits une fois par jeu de données pour des valeurs formatées comme RM 12.00 ou 14/08/2020. Le texte brut mais propre de docTR — précis selon le CER, mais préservant la casse d'origine et le bruit des séparateurs — fait échouer les motifs fixes ; la sortie d'EasyOCR leur correspond plus souvent par hasard. Les colonnes « extraction de champs par regex » sont les métriques postprocessed_sroie_receipt_regex_* du benchmark : elles mesurent le texte OCR + l'extraction en aval par règles, pas une sortie structurée native. Une bibliothèque de motifs fortement ajustée par format pourrait donner des scores différents pour chaque moteur — l'ensemble de motifs est un instrument de mesure fixe, pas un parseur de production réglé.

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

Tableau : field_method_comparison.csv — colonnes regex, lignes sroie_2019. Ce sont les métriques postprocessed_sroie_receipt_regex_* : des motifs fixes appliqués au texte OCR de chaque moteur (post-traité, pas d'extraction native). Le F1 regex de docTR de 0.0766 est le deuxième plus bas des huit moteurs de l'exécution sous-jacente malgré le deuxième meilleur CER — l'ensemble de motifs a été écrit une fois par jeu de données, et le texte de ligne propre mais brut de docTR n'est pas compatible regex sur ces quatre champs.

Le levier LLM : l’inversion se confirme, nettement

En alimentant un postprocesseur LLM (deepseek-v4-flash à température 0) avec le texte OCR des deux moteurs, via une invite d’extraction structurée, le classement des champs s’inverse à nouveau — avec la marge la plus large de tout le benchmark : docTR 0,6171 contre EasyOCR 0,3717 en F1 sur les valeurs de champ, soit un écart de 1,66×. Le résultat de docTR est le F1 LLM sur les champs le plus élevé des huit moteurs ; celui d’EasyOCR est le plus bas. Là où le jeu de motifs regex pénalisait le texte propre de docTR, le LLM le récompense — et le texte de niveau intermédiaire d’EasyOCR, qui se trouvait être compatible regex, se dégrade sous la même invite.

C’est le même schéma de convergence LLM observé sur l’ensemble du benchmark à huit moteurs — le posttraitement LLM ramène les moteurs sains dans une bande de F1 sur les champs de 0,57–0,62, car il comprend la sémantique (nombres, dates, noms) au lieu de faire correspondre des formes de caractères — avec EasyOCR comme exception flagrante. Le levier n’est pas gratuit : un appel LLM ajoute environ 2,0–2,1 s de latence médiane par document, en plus du temps d’OCR (1 996,3 ms pour le texte de docTR, 2 004,5 ms pour celui d’EasyOCR, imputable à l’API et de même nature), et il ne sauve pas un texte que le moteur n’a pas fondamentalement réussi à lire. Mais pour cette paire, le postprocesseur devient le composant décisif : avec un LLM dans le pipeline, le choix de docTR se renforce.

Tableau : field_method_comparison.csv — colonnes llm_*, lignes sroie_2019. Modèle LLM : deepseek-v4-flash à température 0 (colonne llm_model). La latence LLM est imputable à l’API et distincte de la latence du moteur (summary_metrics.csv latency_p50_ms). « Champs de document exacts » correspond à la fraction de documents où chaque champ cible correspond exactement — un critère bien plus strict que le F1 par champ ; EasyOCR obtient les quatre champs exacts sur 0,28 % des reçus.

Le paradoxe EasyOCR-LLM : un texte de niveau moyen, la pire extraction en aval

Le point de données le plus contre-intuitif de ce face-à-face — documenté pour la première fois sur PaddleOCR vs EasyOCR et confirmé ici contre un adversaire différent : le texte OCR d’EasyOCR se situe dans la moyenne en précision des caractères (CER SROIE 0,2833, quatrième sur huit moteurs) — pourtant, lorsque ce texte est transmis au même postprocesseur LLM utilisé pour tous les autres moteurs (deepseek-v4-flash, même invite, mêmes reçus), son F1 sur les valeurs de champ LLM SROIE de 0,3717 est le plus bas des huit moteurs du benchmark — inférieur même à Tesseract (0,4389), un moteur CPU avec un CER plus mauvais (0,3347). Seul le texte OCR a changé ; le LLM, l’invite et les reçus étaient identiques.

Schéma observé, mécanisme non vérifié. Une hypothèse plausible — et rien de plus — concerne une convention de format de sortie : la façon dont EasyOCR dispose, joint ou sépare les lignes de texte semble dégrader l’extraction de champs par le LLM en aval, pour des raisons sans rapport avec la précision brute des caractères. Le benchmark n’a pas isolé ce mécanisme ; le résultat est documenté ici comme reproductible et stable (la ligne SROIE d’EasyOCR a été revérifiée lors d’une réexécution torch 2.8 du 17/08/2026, r1/r2/r3 octet pour octet identiques ; le CSV publié contient déjà ces valeurs corrigées), mais aucune affirmation causale n’est faite. Le texte de base plus propre de docTR + le LLM se place en tête de la même bande qu’EasyOCR manque.

Source : field_method_comparison.csv — llm_field_value_f1, les huit lignes sroie_2019, 361 échantillons chacune (llm_ok_count). Postprocesseur LLM identique pour tous les moteurs : deepseek-v4-flash à température 0. Contexte CER issu de summary_metrics.csv, colonne cer, lignes sroie_2019.

Tableau : field_method_comparison.csv — llm_field_value_f1, toutes les lignes sroie_2019 ; colonne CER issue de summary_metrics.csv, cer, lignes sroie_2019. Le 0.6171 de docTR est le F1 sur les valeurs de champ LLM le plus élevé du benchmark ; le CER d'EasyOCR (0.2833) se classe quatrième sur huit — un texte de niveau intermédiaire avec la pire récupération de champs en aval par LLM (0.3717, sous le 0.4389 de Tesseract). Le paradoxe est documenté comme observé et reproductible ; son mécanisme n'est pas isolé par ce benchmark.

L’enveloppe opérationnelle : docTR est le champion vitesse ET coût du benchmark

La précision détermine quel moteur lit le mieux ; l’enveloppe opérationnelle détermine lequel termine. Sur la même RTX 4090 au même tarif enregistré de 0,76 $US/h, docTR soutient 449,3 pages/min à 108,7 ms p50 par page pour 0,048 $US pour 1 000 pages ; EasyOCR soutient 124,5 pages/min à 413,6 ms p50 pour 0,110 $US pour 1 000 pages — un écart de latence de 3,8×, un écart de débit de 3,6× et un écart de coût de 2,3×, tous en faveur de docTR. Sur l’ensemble des huit moteurs testés, les 108,7 ms p50, 449,3 pages/min et 0,048 $US de docTR sont chacun les meilleurs de tous les moteurs mesurés — docTR est simultanément le moteur le plus rapide et le moins cher du benchmark.

Le coût est calculé comme le temps d’exécution × le tarif RunPod RTX 4090 (0,76 $US/heure, prix horodaté dans les manifestes d’exécution), y compris l’initialisation du modèle — le prix que vous paieriez réellement pour le temps GPU. Le débit est le nombre de pages par minute en temps réel, incluant cette même initialisation. Les latences p50/p95 sont les temps d’inférence par page en régime permanent, mesurés à chaud puis notés (chargement du modèle exclu) ; la queue de distribution d’EasyOCR est proportionnellement pire — 960,4 ms p95 contre 281,4 ms pour docTR, soit un écart de 3,4×. EasyOCR reste néanmoins réellement moins cher que la plupart des autres moteurs mesurés (ses 0,110 $US constituent le deuxième chiffre le plus bas pour 1 000 pages du benchmark, derrière docTR uniquement) — c’est un moteur à coût et vitesse moyens, ni cher ni lent.

Source : summary_metrics.csv — colonnes latency_p50_ms / latency_p95_ms, lignes sroie_2019. docTR p50 108,72 / p95 281,38 ; EasyOCR p50 413,64 / p95 960,37. Latence en régime permanent (mode de mesure warm_then_scored, chargement du modèle exclu).

Source : summary_metrics.csv — colonne cost_per_1000_pages, lignes sroie_2019. docTR 0,0479, EasyOCR 0,1098. Coût = temps d’exécution × 0,76 $US/h incluant l’initialisation du modèle, prix horodaté dans les manifestes d’exécution (août 2026). Les 0,048 $US de docTR constituent le coût le plus bas pour 1 000 pages de tous les moteurs du benchmark ; les 0,110 $US d’EasyOCR sont le deuxième plus bas (summary_metrics.csv, cost_per_1000_pages, toutes les lignes sroie_2019).

Tableau : summary_metrics.csv — latency_p50_ms / latency_p95_ms / pages_per_minute / cost_per_1000_pages, lignes sroie_2019. Les deux moteurs sur GPU (RTX 4090, tarif $0.76/h horodaté dans les manifests) ; le coût inclut l'initialisation du modèle, pas le simple débit en régime permanent. Valeurs exactes : docTR p50 108.72 / p95 281.38 / 449.31 pg/min / $0.0479 ; EasyOCR p50 413.64 / p95 960.37 / 124.53 pg/min / $0.1098. Meilleures performances du benchmark : docTR détient la latence p50 la plus basse, le plus grand nombre de pages/min et le coût le plus faible des huit moteurs (summary_metrics.csv, lignes sroie_2019).

CORD (reçus indonésiens) : les deux échouent sur le texte, l'écart LLM se creuse

Aucun des deux moteurs n'a été entraîné principalement sur des reçus indonésiens, donc CORD v2 (100 échantillons, champs imbriqués menu/sub_total/total) sert de test de résistance inter-langues — et les deux s'effondrent sur le CER brut : 0,9101 (docTR) et 0,9185 (EasyOCR), une égalité due à l'inadéquation linguistique, les deux moteurs étant effectivement incapables de lire le texte. Conformément au protocole du benchmark, les chiffres CORD sont tenus à l'écart de la comparaison SROIE — non fusionnés dans aucun classement — car le texte de vérité terrain de CORD intègre la structure d'annotation, ce qui gonfle le CER brut de chaque moteur en plus de la véritable inadéquation linguistique.

Les métriques de champ montrent que le schéma SROIE se prolonge — et se creuse. Via le postprocesseur LLM, le F1 sur les valeurs de champ de docTR se maintient à 0,5500 contre 0,3378 pour EasyOCR sur CORD — un écart de 1,63×, le même ordre que celui de SROIE à 1,66×, même lorsque les deux reconnaisseurs de texte échouent au niveau des caractères. Via les motifs regex, docTR ne récupère aucun champ (0,0000 de F1 sur les valeurs de champ — un zéro littéral dans le CSV, pas une valeur manquante) car les motifs au format anglais n'ont rien trouvé dans le texte indonésien, tandis qu'EasyOCR en extrait 0,0067. L'avantage de coût de docTR se réduit aussi et s'inverse sur CORD ($0,094 contre $0,086 pour EasyOCR pour 1 000 pages) — mais son avantage de débit en temps réel passe à 500,4 contre 211,8 pages/min (2,4×). CORD est cité ici pour le contexte de robustesse linguistique ; il n'est délibérément jamais regroupé avec les chiffres SROIE dans un classement unique.

Tableau : summary_metrics.csv (cer / pages_per_minute / cost_per_1000_pages) et field_method_comparison.csv (F1 sur les valeurs de champ), lignes cord_v2. Ne mélangez pas les chiffres CORD dans un classement SROIE : le CER CORD combine une véritable inadéquation linguistique avec une inflation de la structure d'annotation dans la vérité terrain. Les motifs regex ont été écrits pour des formats anglais, c'est pourquoi le F1 sur les champs par regex s'effondre à ~0–1 % sur les deux moteurs ; le 0.0000 de docTR est un zéro littéral enregistré dans le CSV, pas une valeur manquante. L'écart de F1 sur les champs par LLM (0.5500 contre 0.3378) prolonge le schéma SROIE à travers les langues ; l'ordre des coûts s'inverse (EasyOCR 0,086 $ contre docTR 0,094 $) tandis que l'écart de débit se creuse (2,4×).

Qui gagne quand : la grille récapitulative

“Mieux” dépend de la charge de travail, et ce face-à-face sépare clairement les axes : la précision du texte brut, les champs en aval par LLM, la vitesse, le débit et le coût favorisent tous docTR ; l'extraction de champs par regex fixe et l'histoire de déploiement favorisent EasyOCR — avec la réserve que le résultat en aval par LLM d'EasyOCR est son plus grand risque, pas son argument de vente.

Questions fréquentes

docTR est-il plus précis qu'EasyOCR sur les reçus ?

Oui, sur chaque axe de précision en texte brut et en extraction de champs de ce benchmark. Sur SROIE 2019 : CER 0.1971 vs 0.2833 (30 % plus bas), WER 0.3199 vs 0.6158 (48 % plus bas), F1 sur les valeurs de champ post-traité par LLM 0.6171 vs 0.3717 (1,66×, meilleur des 8 vs pire des 8) — mais pas sur le F1 de champ par regex, où EasyOCR gagne 0.1477 vs 0.0766 (summary_metrics.csv et field_method_comparison.csv, lignes sroie_2019). Aucun des deux moteurs n'est le champion global du CER de ce benchmark — Surya2 (0.1915) détient ce titre de justesse devant docTR.

Pourquoi docTR a-t-il une meilleure précision textuelle mais une extraction de champs par regex pire qu'EasyOCR ?

Parce que les deux métriques évaluent des sorties différentes sur un instrument de mesure fixe. docTR renvoie un texte brut nettoyé par ligne — précis selon le CER, mais préservant la casse et les séparateurs d'origine — et les motifs regex fixes, écrits une fois par jeu de données pour les valeurs formatées, échouent surtout contre lui : SROIE F1 de champ par regex 0.0766 (field_method_comparison.csv, regex_field_value_f1, ligne doctr/sroie_2019). La sortie d'EasyOCR correspond aux motifs à 0.1477. Fournissez les deux à un LLM et l'écart s'inverse en faveur de docTR (1,66×) — l'ensemble de motifs regex, pas l'OCR, était le goulot d'étranglement.

Pourquoi EasyOCR a-t-il la pire extraction de champs par LLM malgré une précision de caractères correcte ?

C'est le paradoxe documenté de ce benchmark, actuellement sans mécanisme prouvé. Le CER SROIE d'EasyOCR (0.2833) se classe quatrième sur huit moteurs, mais son F1 sur les valeurs de champ post-traité par LLM (0.3717) se classe dernier — en dessous même de Tesseract (0.4389), qui a un CER pire. L'hypothèse principale est une convention de format de sortie dans la façon dont EasyOCR agence ou joint les lignes de texte qui dégrade l'extraction LLM en aval ; il est signalé comme un motif observé et reproductible, sans mécanisme vérifié (field_method_comparison.csv, llm_field_value_f1, lignes sroie_2019). Le même paradoxe est documenté contre un autre adversaire sur PaddleOCR vs EasyOCR.

Combien docTR est-il plus rapide et moins cher qu'EasyOCR ?

3,8× de latence p50 en moins (108,7 vs 413,6 ms), 3,4× de latence p95 en moins (281,4 vs 960,4 ms), 3,6× de débit en plus (449,3 vs 124,5 pages/min), et 2,3× de coût en moins pour 1 000 pages ($0,048 vs $0,110) sur la même RTX 4090 à $0,76/h (summary_metrics.csv, latency_p50_ms / latency_p95_ms / pages_per_minute / cost_per_1000_pages, lignes sroie_2019). docTR est le moteur le plus rapide et le moins cher du benchmark sur les trois mesures ; EasyOCR est à coût moyen (deuxième moins cher) et à vitesse moyenne (deuxième débit le plus rapide).

Pourquoi les deux moteurs obtiennent-ils d'aussi mauvais scores sur les reçus CORD ?

Deux causes cumulées que le protocole du benchmark sépare du classement SROIE : une véritable inadéquation linguistique (reçus indonésiens hors de la zone d'entraînement des deux moteurs) et une inflation de la structure d'annotation dans le texte de référence de CORD — le CER atteint 0,9101 (docTR) et 0,9185 (EasyOCR) (summary_metrics.csv, cer, lignes cord_v2). Ce qui les distingue encore, c'est la récupération en aval par LLM : docTR 0,5500 vs EasyOCR 0,3378 en F1 sur les valeurs de champ — le schéma SROIE persiste et s'élargit, même quand les deux reconnaisseurs échouent au niveau des caractères.

Quel moteur un pipeline de reçus devrait-il choisir, EasyOCR ou docTR ?

Pour un pipeline dont l'objectif est des champs extraits en volume avec un coût mesuré, docTR domine sur ce corpus : meilleur texte brut (CER 30 % plus bas), les meilleurs champs en aval par LLM de tous les moteurs (0,6171 vs 0,3717), et un avantage de coût de 2,3×, un débit de 3,6×, une latence de 3,8× — les quatre axes à la fois (summary_metrics.csv / field_method_comparison.csv, lignes sroie_2019). EasyOCR reste un choix légitime pour de l'OCR en masse multi-script, bon marché et facile à installer, sur des documents propres où l'extraction par regex ou le texte brut à volume modeste est la tâche et où la qualité des champs en aval par LLM importe moins — mais prévoyez son faible downstream LLM mesuré avant de vous engager. Ces résultats valent pour des reçus en anglais et en indonésien sur un niveau de GPU en août 2026 ; relancez sur votre corpus cible avant les décisions de production (voir Limitations).

D'où viennent les chiffres de cette page ?

Chaque chiffre est une ligne des CSV publiés du benchmark propriétaire — results/summary_metrics.csv (CER/WER, F1 sur les champs regex, latence, coût, débit) et results/field_method_comparison.csv (regex vs post-traitement LLM, llm_model = deepseek-v4-flash) — hébergés sur ImageToTableai/benchmark-ocr, avec un manifest.json expurgé 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 un comparatif direct d'une exécution de benchmark indépendante et reproductible (niveau officiel) — pas un relevé d'affirmations tierces, ni une page de comparaison de fournisseurs. Uniquement des splits de test fixes : test SROIE 2019 (361 reçus anglais, champs plats company/date/address/total) et test CORD v2 (100 reçus indonésiens, champs imbriqués menu/sub_total/total) ; les splits d'entraînement n'ont jamais été évalués. Les deux moteurs ont vu les mêmes images, la même vérité terrain et le même protocole de mesure (warm_then_scored : un passage de préchauffage fixe précède le passage noté, donc les chiffres de latence sont en régime permanent). Les deux exécutions se sont terminées avec error_rate 0.0 sur les deux jeux de données (colonne error_rate de summary_metrics.csv). L'exécution sous-jacente contient huit moteurs au total ; cette page ne compare que les deux moteurs nommés, les autres moteurs n'étant cités que comme contexte de classement. Les résultats complets des 8 moteurs sont publiés séparément sur Traditional OCR vs Document Parsing VLMs.

Environnement d'exécution

• Matériel : les deux moteurs ont tourné sur la même NVIDIA RTX 4090 (24 Go) ; le coût GPU est calculé au tarif à la demande RunPod de 0,76 $/h, prix horodaté dans le manifeste expurgé de chaque exécution (août 2026).
• Moteurs : prêts à l'emploi, sans fine-tuning. Versions verrouillées : EasyOCR 1.7.2 (reconnaisseur CNN + RNN + CTC classique, extracteur de caractéristiques ResNet, GPU) et docTR v1.0.1 (OCR neuronal moderne en deux étapes — détection par transformer de type DETR + reconnaissance, GPU) — selon le tableau des modèles du dépôt public (README.md) et les manifestes d'exécution. La ligne SROIE d'EasyOCR a été revérifiée lors d'une réexécution torch 2.8 du 2026-08-17 (répétitions r1/r2/r3 octet-identiques) ; les CSV publiés portent ces valeurs corrigées.
• Post-traitement LLM : deepseek-v4-flash via API à température 0 pour une sortie déterministe (colonne llm_model de field_method_comparison.csv) ; c'était le seul modèle utilisé pour toutes les lignes de champs LLM sur les deux moteurs.
• Base de coût : temps d'exécution réel × 0,76 $/h, y compris 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 regex SROIE sont postprocessed_sroie_receipt_regex_* (colonnes regex_* de field_method_comparison.csv) — des champs extraits du texte OCR par un ensemble de motifs fixes écrit une fois par jeu de données. Ils mesurent l'OCR + l'extraction en aval, pas la sortie structurée native de l'un ou l'autre modèle ; les colonnes LLM_* mesurent le texte OCR + l'extraction LLM. Les deux pipelines ne sont jamais mélangés.

Définitions des métriques

• CER (taux d'erreur par caractère) : 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 c'est bas, mieux c'est.
• WER (taux d'erreur par mot) : le même calcul de distance d'édition au niveau des mots.
• F1 sur les valeurs de champ (regex) : moyenne harmonique précision/rappel sur les valeurs de champ extraites à l'aide de motifs regex fixes appliqués au texte OCR (pipeline OCR traditionnel + KIE basé sur des règles). Colonne : regex_field_value_f1. Un score de 0 signifie qu'aucune valeur de champ n'a été récupérée.
• F1 sur les valeurs de champ (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 combinés.
• Champs de document exacts : fraction de documents où tous les champs cibles correspondent exactement — un critère bien plus strict que le F1 par champ.
• Latence p50/p95 & pages/min : temps d'inférence par page en régime permanent (mesuré après échauffement, hors chargement du modèle) et débit en temps réel incluant l'initialisation du modèle. Ils mesurent des horloges différentes.
• Coût pour 1 000 pages : heures GPU facturées pour 1 000 pages au tarif enregistré de 0,76 $/h, incluant l'initialisation du modèle.

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. Chaque valeur CER/WER, latence, coût et débit de cette page provient des lignes easyocr et doctr de ce fichier.
2. field_method_comparison.csv (GitHub raw). 16 lignes ; colonnes model, dataset, llm_model (= deepseek-v4-flash), précision et F1 des valeurs de champ regex/LLM, champs de document exacts, llm_median_latency_ms, nombres de jetons. Chaque valeur de F1 de champ regex/LLM provient des lignes easyocr et doctr de ce fichier (et des huit lignes sroie_2019 du tableau des paradoxes).
3. dépôt ImageToTableai/benchmark-ocr. Dépôt public hébergeant les CSV de résultats, les manifestes de run expurgés, le protocole figé et les listes d'échantillons des jeux de données (splits de test fixes) pour la reproduction.
4. results/manifests/ (GitHub). Un manifest.json expurgé par run publié (16 runs) avec versions des modèles, GPU/pilote, versions torch/CUDA/Python, métadonnées de coût avec horodatage du prix et 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).

Limites

• Périmètre documentaire — reçus uniquement : SROIE + CORD. Rien ici ne mesure la couverture des 80+ langues d'EasyOCR sur du texte hors reçus, le comportement de docTR sur les tableaux/formulaires/documents longs, ni aucun autre type de document. N'utilisez pas cette page pour conclure que l'un des deux moteurs « gagne sur tout ».
• Taille d'échantillon : 361 reçus en anglais + 100 reçus en indonésien. Le F1 par champ et le CER dépendent du corpus ; des écarts de quelques centièmes doivent être traités comme du bruit, pas comme une vérité d'ingénierie — même si les écarts documentés ici (30 % de CER, 48 % de WER, F1 LLM ×1,66) sont bien au-delà de cette bande.
• Un seul niveau de GPU et un seul prix : tous les chiffres proviennent d'une seule RTX 4090 à 0,76 $/h, prix horodaté d'août 2026 dans les manifests d'exécution. D'autres GPU, le service multi-GPU, l'ordonnancement par lots ou les variations de prix feront évoluer la latence, le débit et le coût — recalculez les coûts aux tarifs actuels avant d'établir un budget.
• Un seul postprocesseur LLM : toutes les lignes LLM utilisent deepseek-v4-flash à température 0. Un autre LLM déplace le F1 absolu par champ ; l'ampleur du paradoxe EasyOCR peut bouger avec le LLM, même si le schéma observé s'est maintenu avec ce seul postprocesseur sur les deux jeux de données. La latence du LLM (~2,0–2,1 s en médiane sur SROIE, field_method_comparison.csv llm_median_latency_ms) est imputable à l'API et ne fait pas partie de la latence propre de l'un ou l'autre moteur.
• Mécanisme du paradoxe EasyOCR non vérifié : le benchmark documente que le texte CER de niveau intermédiaire d'EasyOCR produit la pire récupération de champs en aval du LLM (0,3717 sur SROIE / 0,3378 sur CORD) — un résultat observé et reproductible sous l'hypothèse des conventions de mise en page du texte de sortie, dont le mécanisme causal n'est explicitement pas isolé. Traitez-le comme un résultat mesuré à prendre en compte, pas comme une propriété prouvée de la bibliothèque.
• Réglage des regex : le jeu de motifs a été écrit une seule fois par jeu de données. Une bibliothèque de motifs fortement réglée par format pourrait obtenir de meilleurs scores sur ses propres mises en page — au prix de maintenance que le LLM élimine. Le désavantage regex de docTR (0,0766 contre 0,1477) est une propriété de cet instrument fixe, pas une affirmation sur ce qu'un analyseur réglé pourrait récupérer.
• Le CER CORD n'est pas une lecture de qualité par modèle : la vérité terrain CORD intègre la structure d'annotation et aucun des deux moteurs n'a été entraîné principalement sur de l'indonésien ; le CER CORD (~0,91) reflète l'inadéquation linguistique + l'inflation de la vérité terrain. Les lignes CORD sont citées avec leur contexte et jamais fusionnées dans un classement SROIE (règle de protocole).
• Deux moteurs uniquement : ce face-à-face exclut délibérément les six autres moteurs de l'exécution sous-jacente, les services OCR cloud/API et les API VLM hébergées ; leurs modèles de latence et de tarification diffèrent fondamentalement des moteurs locaux mesurés ici.
• Épinglage des versions : les résultats valent pour EasyOCR 1.7.2 et docTR v1.0.1 (août 2026). Des versions plus récentes de l'un ou l'autre moteur peuvent faire bouger chaque chiffre de cette page.

Références associées : Benchmark de reçus PaddleOCR vs EasyOCR · Benchmark de reçus docTR vs Surya2 · OCR traditionnel vs VLM d'analyse de documents · correspondance de motifs vs extraction de champs par modèle · mesurer la précision par champ, pas par caractère · Coût OCR pour 1 000 pages

Lectures complémentaires : pourquoi la précision de l'OCR IA diffère de l'OCR traditionnel · pourquoi l'extraction IA surpasse l'OCR sur les images · Tarification de l'extraction de documents IA (2026)