EasyOCR vs docTR sur les reçus
Champion de la vitesse vs Extracteur de terrain (2026)

Les deux moteurs représentent deux générations de reconnaissance optique de caractères (OCR) par apprentissage profond, tous deux du côté traditionnel de la dichotomie OCR vs VLM. EasyOCR (basé sur PyTorch, 1.7.2) est un classique reconnaisseur CNN + RNN + CTC en une seule passe — un extracteur de caractéristiques ResNet alimentant un modèle de séquence décodé par Classification Temporelle Connectionniste, avec un raffinement basé sur l'attention. Son centre de conception est une couverture très large des langues et des écritures (plus de 80 langues prêtes à l'emploi) et une installation notoirement simple. docTR (v1.0.1) est un pipeline neuronal en deux étapes moderne : 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 ~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 meilleur pour les deux. Aucun des deux moteurs n'est un modèle de vision et de langage (VLM) — tous deux produisent du texte brut, pas une structure comprise.

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

Sur les 361 reçus en anglais de la partition de test SROIE 2019, l'architecture moderne gagne sur les deux métriques de texte : 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 des mots entiers sur ce corpus. Les deux moteurs fonctionnent sans erreur (taux d'erreur 0,0 sur chaque ligne SROIE et CORD du CSV). Aucun des deux n'est le champion du CER global du benchmark — ce titre appartient à Surya2 (0,1915) et docTR lui-même se classe deuxième ; EasyOCR est 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 meilleur. 361 échantillons par moteur ; error_rate 0,0 pour les deux.

Tableau : 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% plus bas, WER 48% plus bas pour docTR. Un CER/WER plus bas est meilleur. Contexte de classement CER au sein de la même série 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-Field : texte plus mauvais, champs plus récupérables

Le test des deux moteurs’texte brut via 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) basée sur des règles — inverse le classement : EasyOCR extrait les champs avec 0.1477 de F1 sur les valeurs de champ contre 0.0766 pour docTR, un avantage de 1.93× pour le moteur avec la pire précision au caractère. C’est l’inversion récurrente du benchmark « précision du texte ≠ précision du champ » — le même schéma observé entre l’OCR traditionnel et les VLM d’analyse de documents sur docTR vs Surya2 — qui se produit maintenant entre deux moteurs traditionnels qui produisent le même type de texte brut ligne par ligne.

Le F1 sur les valeurs de champ est la moyenne harmonique de la précision et du rappel sur les valeurs des champs extraits par rapport à la vérité terrain : 1.0 signifie que chaque champ du reçu est parfaitement récupéré, 0 signifie rien. Le mécanisme derrière l’inversion est une propriété de l’ensemble de motifs regex, et non 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 originale et le bruit des séparateurs — fait échouer les motifs fixes ; la sortie d’EasyOCR correspond plus souvent à ceux-ci. Les colonnes « regex field extraction » sont les métriques postprocessed_sroie_receipt_regex_* du benchmark : elles mesurent le texte OCR + l’extraction basée sur des règles en aval, et non la sortie structurée native. Une bibliothèque de motifs spécifique à chaque format et très optimisée pourrait obtenir des scores différents pour l’un ou l’autre moteur — l’ensemble de motifs est un instrument de mesure fixe, et non un analyseur de production optimisé.

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-traitement LLM : deepseek-v4-flash (colonne llm_model). 361 échantillons par moteur (llm_ok_count).

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

Le levier LLM : le renversement, décisif

Alimentez les deux moteurs OCR avec un post-traitement LLM (deepseek-v4-flash à température 0) et un prompt d'extraction structurée, et le classement des champs s'inverse à nouveau — avec la plus grande marge de tous les appariements du benchmark : docTR 0.6171 contre EasyOCR 0.3717 en F1 sur les valeurs de champ, un écart de 1,66×. Le résultat de docTR est le meilleur F1 sur les valeurs de champ par LLM des huit moteurs ; celui d'EasyOCR est le pire. Là où le jeu de motifs regex pénalisait le texte propre de docTR, le LLM le récompense — et le texte moyen d'EasyOCR, qui était par ailleurs compatible avec les regex, se dégrade sous le même prompt.

C'est le même schéma de convergence par LLM observé sur l'ensemble du benchmark à huit moteurs — le post-traitement LLM tire les moteurs performants dans une fourchette de 0,57 à 0,62 en F1 sur les valeurs de champ car il comprend la sémantique (noms, dates, chiffres) au lieu de 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 OCR (1 996,3 ms pour le texte de docTR, 2 004,5 ms pour celui d'EasyOCR, coûts API, de même nature), et il ne peut pas sauver un texte qu'un moteur n'a pas réussi à lire fondamentalement. Mais pour cet appariement, le post-traiteur devient le composant décisif : avec un LLM dans le pipeline, le choix de docTR se cumule.

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 un coût API, séparée de la latence moteur (colonne latency_p50_ms de summary_metrics.csv). « Exactitude document-champs » est la fraction de documents où chaque champ cible a été trouvé exactement — un critère bien plus strict que le F1 par champ ; EasyOCR obtient les quatre champs exactement sur 0,28 % des reçus.

Le paradoxe EasyOCR LLM : texte moyen, pire extraction en aval

Le point de données le plus contre-intuitif de cette comparaison directe — d'abord documenté dans PaddleOCR vs EasyOCR et confirmé ici face à un adversaire différent : le texte OCR d'EasyOCR est dans la moyenne par précision caractères (CER SROIE 0.2833, quatrième sur huit moteurs) — mais lorsque ce texte est fourni au même postprocesseur LLM utilisé pour tous les autres moteurs (deepseek-v4-flash, même prompt, 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, le prompt et les reçus étaient identiques.

Pattern observé, mécanisme non vérifié. Une hypothèse plausible — et rien de plus — est 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 des champs 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 EasyOCR du SROIE a été revérifiée lors d'un rerun torch 2.8 le 2026-08-17, r1/r2/r3 identiques octet par octet ; 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 atteint le sommet de la même bande que 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 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 — texte de niveau intermédiaire avec la récupération de champ en aval LLM la plus faible (0.3717, inférieure à celle de Tesseract, 0.4389). 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 de la vitesse ET du 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 $/h, docTR maintient 449,3 pages/min à 108,7 ms p50 par page pour 0,048 $ pour 1 000 pages ; EasyOCR maintient 124,5 pages/min à 413,6 ms p50 pour 0,110 $ 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 $ de coût 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 durée d'exécution réelle × le tarif RunPod RTX 4090 (0,76 $/heure, prix horodaté dans les manifests d'exécution), incluant l'initialisation du modèle — le prix que vous paieriez réellement pour le temps GPU. Le débit est le nombre de pages réelles par minute incluant cette même initialisation. Les latences p50/p95 sont les temps d'inférence par page en régime stable, mesurés à chaud puis scorés (chargement du modèle exclu) ; la queue d'EasyOCR est proportionnellement pire — 960,4 ms p95 contre 281,4 ms pour docTR, un écart de 3,4×. EasyOCR reste réellement moins cher que la plupart des autres moteurs mesurés (ses 0,110 $ sont le deuxième coût le plus bas pour 1 000 pages dans le benchmark, derrière uniquement docTR) — il est moyen en coût et moyen en vitesse, pas cher ou 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 stable (mode de mesure warm_then_scored, exclut le chargement du modèle).

Source : summary_metrics.csv — colonne cost_per_1000_pages, lignes sroie_2019. docTR 0,0479, EasyOCR 0,1098. Coût = durée d'exécution réelle × 0,76 $/h incluant l'init du modèle, prix horodaté dans les manifests d'exécution (août 2026). Les 0,048 $ de docTR sont le coût le plus bas pour 1 000 pages de tous les moteurs du benchmark ; les 0,110 $ 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, prix horaire de $0.76 horodaté dans les manifests) ; le coût inclut l'initialisation du modèle, pas le débit pur 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. Meilleurs résultats globaux : docTR détient la latence p50 la plus basse, le plus grand nombre de pages/min et le coût le plus bas des huit moteurs (summary_metrics.csv, lignes sroie_2019).

CORD (Reçus indonésiens) : Les deux s'effondrent sur le texte, l'écart du LLM s'élargit

Aucun moteur n'a été principalement entraîné sur des reçus indonésiens, donc CORD v2 (100 échantillons, champs imbriqués menu/sub_total/total) fonctionne comme un test de résistance interlingue — et les deux s'effondrent sur le CER brut : 0.9101 (docTR) et 0.9185 (EasyOCR), un match nul de décalage linguistique où les deux moteurs sont effectivement incapables de lire le texte. Selon le protocole de benchmark, les chiffres de CORD sont maintenus isolés de la comparaison SROIE — non fusionnés dans aucun classement — car le texte de référence de CORD intègre une structure d'annotation, ce qui gonfle le CER brut pour chaque moteur en plus du véritable décalage linguistique.

Les métriques par champ montrent la poursuite du schéma SROIE — et son élargissement. Via le post-traitement LLM, le F1 par champ de docTR se maintient à 0.5500 contre 0.3378 pour EasyOCR sur CORD — un écart de 1,63×, le même ordre que le 1,66× de SROIE, même lorsque les deux reconnaisseurs de texte échouent au niveau caractère. Via les expressions régulières, docTR ne récupère aucun champ (0.0000 F1 par champ — un zéro littéral dans le CSV, pas une valeur manquante) car les motifs au format anglais ne correspondaient à rien dans le texte indonésien, tandis qu'EasyOCR en récupère 0,0067. L'avantage de coût de docTR se réduit et s'inverse également sur CORD ($0,094 contre $0,086 pour EasyOCR par 1 000 pages) — mais son avantage de débit en temps réel croît pour atteindre 500,4 contre 211,8 pages/min (2,4×). CORD est cité ici pour le contexte de robustesse linguistique ; il est délibéré de ne jamais le regrouper avec les chiffres SROIE dans un classement unique.

Tableau : summary_metrics.csv (cer / pages_par_minute / coût_par_1000_pages) et field_method_comparison.csv (F1 sur les champs), lignes cord_v2. Ne fusionnez pas les chiffres de CORD dans un quelconque classement SROIE : le CER de CORD combine une véritable inadéquation linguistique avec une inflation de la structure d'annotation dans la vérité terrain. Les expressions régulières ont été rédigées pour des formats anglais, c'est pourquoi le F1 sur les champs par regex s'effondre à ~0–1% sur les deux moteurs ; la valeur 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 via LLM (0.5500 vs 0.3378) prolonge le schéma SROIE à travers les langues ; l'ordre des coûts s'inverse (EasyOCR $0.086 vs docTR $0.094) tandis que l'écart de débit s'accentue (2,4×).

Qui gagne quand : le tableau récapitulatif

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

Foire aux questions

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

Oui, sur tous les axes de précision du texte brut et de l'extraction de champs dans ce benchmark. Sur SROIE 2019 : CER 0,1971 vs 0,2833 (30 % de moins), WER 0,3199 vs 0,6158 (48 % de moins), F1 des champs post-traités par LLM 0,6171 vs 0,3717 (1,66×, meilleur des 8 vs pire des 8) — mais pas sur le F1 des champs par regex, où EasyOCR gagne avec 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 dans le benchmark — Surya2 (0,1915) détient ce titre, juste devant docTR.

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

Parce que les deux métriques évaluent des sorties différentes avec un instrument de mesure fixe. docTR renvoie des lignes de texte brut propres — précis selon le CER, mais conservant la casse et les séparateurs originaux — et les motifs regex fixes, écrits une seule fois par jeu de données pour des valeurs formatées, échouent la plupart du temps contre elles : F1 des champs par regex sur SROIE 0,0766 (field_method_comparison.csv, regex_field_value_f1, ligne doctr/sroie_2019). La sortie d'EasyOCR correspond par hasard aux motifs à 0,1477. Si on les alimente tous les deux avec un LLM à la place, l'écart s'inverse en faveur de docTR (1,66×) — c'est l'ensemble de motifs regex, et non l'OCR, qui était le goulot d'étranglement.

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

C'est le paradoxe documenté du benchmark, actuellement sans mécanisme prouvé. Le CER de SROIE d'EasyOCR (0,2833) se classe quatrième sur huit moteurs, mais son F1 des champs post-traités par LLM (0,3717) est dernier — même en dessous de Tesseract (0,4389), qui a un CER plus mauvais. L'hypothèse principale est une convention de format de sortie dans la façon dont EasyOCR présente ou joint les lignes de texte, ce qui dégrade l'extraction LLM en aval ; cela est étiqueté comme un motif observé et reproductible dont le mécanisme n'est pas vérifié (field_method_comparison.csv, llm_field_value_f1, lignes sroie_2019). Le même paradoxe est documenté face à un autre adversaire sur PaddleOCR vs EasyOCR.

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

3,8× de latence p50 inférieure (108,7 vs 413,6 ms), 3,4× de latence p95 inférieure (281,4 vs 960,4 ms), 3,6× de débit supérieur (449,3 vs 124,5 pages/min), et 2,3× de coût inférieur pour 1 000 pages ($0,048 vs $0,110) sur la même RTX 4090 à $0,76/heure (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 horloges ; EasyOCR est à coût moyen (deuxième moins cher) et à vitesse moyenne (deuxième meilleur débit).

Pourquoi les deux moteurs obtiennent-ils de si mauvais résultats sur les reçus CORD ?

Deux causes cumulatives que le protocole du benchmark sépare du classement SROIE : une véritable inadéquation linguistique (reçus indonésiens en dehors du champ 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 sépare encore est la récupération en aval par LLM : docTR 0,5500 vs EasyOCR 0,3378 pour le F1 sur les champs — le schéma SROIE persiste et s'élargit, même lorsque les deux reconnaisseurs échouent au niveau des caractères.

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

Pour un pipeline dont l'objectif est l'extraction de champs à volume avec coût mesuré, docTR domine sur ce corpus : meilleur texte brut (CER 30% inférieur), 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 l'OCR en masse bon marché, facile à installer et multi-écritures sur des documents propres où l'extraction par regex ou le texte brut à volume modeste est la tâche et que la qualité des champs en aval par LLM importe moins — mais prévoyez son faiblesse mesurée en aval par LLM avant de vous engager. Ces résultats s'appliquent aux reçus en anglais et en indonésien sur un seul niveau de GPU en août 2026 ; relancez-les sur votre corpus cible avant toute décision de production (voir Limitations).

D'où viennent les chiffres de cette page ?

Chaque chiffre est une ligne des CSV publiés du benchmark interne — results/summary_metrics.csv (CER/WER, regex F1 sur les champs, 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 partiellement masqué 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 extrait comparatif d'un run de benchmark indépendant et reproductible (niveau officiel) — pas un recueil d'affirmations tierces, ni une page de comparaison de fournisseurs. Uniquement des partitions de test fixes : SROIE 2019 test (361 reçus anglais, champs plats company/date/address/total) et CORD v2 test (100 reçus indonésiens, champs imbriqués menu/sub_total/total) ; les partitions d'entraînement n'ont jamais été évaluées. 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 chauffage fixe précède le passage mesuré, donc les chiffres de latence sont en régime permanent). Les deux runs se sont terminés avec un error_rate de 0.0 sur les deux jeux de données (colonne error_rate de summary_metrics.csv). Le run sous-jacent contient huit moteurs au total ; cette page ne compare que les deux moteurs nommés, les autres 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 le même NVIDIA RTX 4090 (24 Go) ; le coût GPU calculé au tarif à la demande de RunPod de $0.76/hr, le prix horodaté dans le manifest masqué de chaque run (août 2026).
• Moteurs : en configuration par défaut, sans fine-tuning. Versions verrouillées : EasyOCR 1.7.2 (reconnaiseur classique CNN + RNN + CTC, extracteur de caractéristiques ResNet, GPU) et docTR v1.0.1 (OCR neuronal moderne en deux étapes — détection par transformeur de type DETR + reconnaissance, GPU) — selon le tableau des modèles du dépôt public (README.md) et les manifests de run. La ligne SROIE d'EasyOCR a été revérifiée lors d'un rerun torch 2.8 le 2026-08-17 (runs répétés r1/r2/r3 identiques octet par octet) ; 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 dans field_method_comparison.csv) ; c'est le seul modèle utilisé pour toutes les lignes LLM des deux moteurs.
• Base de coût : temps d'exécution réel × $0.76/hr, incluant l'initialisation du modèle — le traitement par lots réduit le coût par page.
• Post-traitement des champs : les métriques regex des champs SROIE sont postprocessed_sroie_receipt_regex_* (colonnes regex_* de field_method_comparison.csv) — 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ées.

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 mieux.
• WER (Word Error Rate) : le même calcul de distance d'édition au niveau du mot.
• F1 sur les valeurs de champ (regex) : moyenne harmonique précision/rappel sur les valeurs de champ 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. 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 post-processeur 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 du document exacts : fraction des documents où tous les champs cibles correspondent exactement — un critère beaucoup plus strict que le F1 par champ.
• Latence p50/p95 & pages/min : temps d'inférence par page en régime permanent (après chauffe puis mesure, exclut le 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. Tous les chiffres de CER/WER, latence, coût et débit sur cette page proviennent des lignes easyocr et doctr ici.
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, document-fields-exact, llm_median_latency_ms, token counts. Tous les chiffres de F1 sur les valeurs de champ regex/LLM proviennent des lignes easyocr et doctr ici (et des huit lignes sroie_2019 du tableau paradoxe).
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 les versions des modèles, GPU/pilote, versions torch/CUDA/Python, métadonnées de coût avec horodatage du prix et empreintes 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 du document — reçus uniquement : SROIE + CORD. Rien ici ne mesure l'étendue des 80+ langues d'EasyOCR sur du texte non-reçu, le comportement de docTR sur des tableaux/formulaires/documents longs, ou tout autre type de document. N'utilisez pas cette page pour conclure qu'un moteur « gagne sur tout. »
• Taille de l'échantillon : 361 reçus en anglais + 100 en indonésien. Le F1 par champ et le CER dépendent du corpus ; des différences d'un ou deux points de pourcentage doivent être traitées comme du bruit, pas comme une vérité technique — bien que les écarts documentés ici (30% CER, 48% WER, 1,66× F1 LLM) soient bien au-delà de cette marge.
• Un seul niveau de GPU et un seul prix : tous les chiffres proviennent d'un seul RTX 4090 à 0,76 $/h, horodaté en août 2026 dans les manifests d'exécution. D'autres GPU, un service multi-GPU, une planification par lots ou des changements de prix modifieront la latence, le débit et le coût — recalculez les coûts aux tarifs actuels avant de budgétiser.
• Un seul postprocesseur LLM : toutes les lignes LLM utilisent deepseek-v4-flash à température 0. Un autre LLM modifierait le F1 par champ absolu ; l'ampleur du paradoxe EasyOCR pourrait varier avec le LLM, bien que le schéma observé se soit maintenu pour ce seul postprocesseur sur les deux jeux de données. La latence LLM (~2,0–2,1 s médian sur SROIE, llm_median_latency_ms dans field_method_comparison.csv) est imputable à l'API et ne fait pas partie de la latence propre des moteurs.
• Mécanisme du paradoxe EasyOCR non vérifié : la mesure montre que le texte de CER intermédiaire d'EasyOCR produit la pire récupération de champs en aval par le LLM (0,3717 SROIE / 0,3378 CORD) — un résultat observé et reproductible sous l'hypothèse des conventions de mise en page du texte de sortie, avec le mécanisme causal explicitement non isolé. Traitez-le comme un résultat mesuré pour planifier, pas comme une propriété prouvée de la bibliothèque.
• Paramétrage des regex : l'ensemble de motifs a été écrit une fois par jeu de données. Une bibliothèque de motifs spécifique à chaque format et fortement optimisée pourrait obtenir de meilleurs scores sur ses propres mises en page — au prix de la maintenance que le LLM supprime. Le désavantage regex de docTR (0,0766 vs 0,1477) est une propriété de cet instrument fixe, pas une affirmation sur ce qu'un analyseur optimisé pourrait récupérer.
• Le CER de CORD n'est pas une mesure de qualité par modèle : la vérité terrain de CORD intègre la structure d'annotation et aucun des moteurs n'a été principalement entraîné sur de l'indonésien ; le CER de CORD (~0,91) reflète l'inadéquation linguistique + une inflation de la vérité terrain. Les lignes CORD sont citées avec un contexte et ne sont jamais fusionnées dans un quelconque classement SROIE (règle de protocole).
• Deux moteurs seulement : cette confrontation 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.
• Verrouillage des versions : les résultats sont valables pour EasyOCR 1.7.2 et docTR v1.0.1 (août 2026). De nouvelles versions de l'un ou l'autre moteur pourraient modifier chaque chiffre de cette page.

Références connexes : PaddleOCR vs EasyOCR Receipt Benchmark · docTR vs Surya2 Receipt Benchmark · Traditional OCR vs Document Parsing VLMs · Regex vs LLM Field Extraction · Field-Level vs Character-Level Accuracy · OCR Cost per 1,000 Pages

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