PaddleOCR vs EasyOCR sur les reçus
Benchmark précision vs coût (2026)

Les deux moteurs représentent deux générations d'OCR par apprentissage profond. PaddleOCR (basé sur PaddlePaddle, architecture PP-OCR, v3.7.0) est un pipeline moderne en deux étapes : une étape de détection localise les zones de texte, puis une étape de reconnaissance les transcrit — conçu pour une grande précision sur le texte imprimé à grande échelle. 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é avec la classification temporelle connexionniste. Il est connu pour sa très large couverture de langues et d'écritures (plus de 80 langues prêtes à l'emploi) et son installation remarquablement simple. Le taux d'erreur de caractères (CER) mesure les insertions, suppressions et substitutions divisées par les caractères de référence — un CER de 0,204 signifie environ 20,4 caractères mal lus pour 100 ; le taux d'erreur de mots (WER) applique la même logique de distance d'édition au niveau du mot entier. Plus bas est mieux sur les deux.

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

Sur les 361 reçus en anglais de la division de test SROIE 2019, l'architecture moderne gagne sur les deux métriques de texte : CER 0,2045 contre 0,2833 (une amélioration relative de 27,8 %) et WER 0,3256 contre 0,6158 — le WER d'EasyOCR est presque le double. L'écart de WER est plus grand que l'écart de CER, ce qui indique qu'EasyOCR cumule les erreurs au niveau des caractères en échecs de mots entiers sur ce corpus. Les deux moteurs fonctionnent sans erreur (error_rate 0,0 sur chaque ligne SROIE et CORD du CSV).

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

Table : summary_metrics.csv — colonnes cer / wer / error_rate, lignes sroie_2019. Valeurs exactes : PaddleOCR cer 0.20449 / wer 0.32563 ; EasyOCR cer 0.28327 / wer 0.61578. Un CER/WER plus bas est meilleur. Aucun des deux moteurs n’est le champion global de précision du benchmark — ce titre revient à Surya2 (CER 0.1915) et docTR (CER 0.1971) dans la même exécution de 8 moteurs (summary_metrics.csv, lignes surya2 et doctr sroie_2019).

Extraction de champs : KIE par regex et par LLM

La précision du texte classe les moteurs ; l’extraction de champs est ce que les systèmes en aval consomment réellement. Les métriques de champs SROIE du benchmark ciblent quatre champs de reçu simples (entreprise, date, adresse, total) à l’aide de deux postprocesseurs appliqués au texte OCR de chaque moteur : des motifs regex fixes (l’approche traditionnelle OCR + extraction d’informations clés par règles) et un postprocesseur LLM (deepseek-v4-flash à température 0) avec une invite structurée. Par regex, PaddleOCR extrait les champs à 0.3254 de F1 de champs contre 0.1477 pour EasyOCR — un avantage de 2,2× ; via le LLM, l’écart persiste à 0.5810 contre 0.3717 (1,56×).

Le F1 de valeur de champ est la moyenne harmonique de la précision et du rappel sur les valeurs de champs extraites par rapport à la vérité terrain — 1.0 signifie que chaque champ de reçu est parfaitement récupéré, 0 signifie que rien ne l’est. Les colonnes regex de champs SROIE sont les métriques postprocessed_sroie_receipt_regex_* du benchmark : des motifs fixes appliqués au texte OCR de chaque moteur (post-traité, pas une sortie structurée native). Notez le contexte de classement : le 0.3254 de PaddleOCR est le troisième meilleur résultat regex-champs du benchmark à 8 moteurs (derrière Unlimited-OCR 0.3376 et PaddleOCR-VL 0.3368) et le meilleur parmi les quatre moteurs purement traditionnels ; le 0.1477 d’EasyOCR se classe septième sur huit (summary_metrics.csv, lignes field_f1_regex, sroie_2019).

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

Tableau : field_method_comparison.csv — colonnes regex et llm, lignes sroie_2019. Les colonnes regex sont les métriques postprocessed_sroie_receipt_regex_* : des motifs fixes appliqués au texte OCR de chaque moteur. Post-processeur 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). “Documents avec tous les champs 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 exactement corrects sur 0,28 % des reçus.

Le paradoxe EasyOCR-LLM : texte de niveau intermédiaire, extraction en aval la plus médiocre

C’est le point de données le plus distinctif de cette page, et il est véritablement contre-intuitif : le texte OCR d’EasyOCR se situe dans la moyenne en termes de 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 de champ LLM SROIE de 0,3717 est le plus bas des huit moteurs du benchmark — même en dessous de 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 — est une convention de format de sortie : la manière dont EasyOCR dispose, joint ou sépare les lignes de texte semble dégrader l’extraction de champs LLM en aval pour des raisons sans lien 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 nouvelle 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. L’implication pratique est à l’opposé du vernis marketing : sur ce corpus, choisir EasyOCR pour un texte “assez bon” signifie prévoir la récupération de champs LLM en aval la plus médiocre de tous les moteurs testés.

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 CER d'EasyOCR (0.2833) se classe quatrième sur huit — 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.

Le domaine d'exploitation : là où EasyOCR est réellement compétitif

La précision n'est pas le seul critère, et sur le plan opérationnel, EasyOCR présente des avantages réels et mesurés. Sur la même RTX 4090 au même tarif de $0.76/h, EasyOCR traite SROIE à $0.110 pour 1 000 pages contre $0.221 pour PaddleOCR (un écart de 2,0×), maintient 124,5 pages/min contre 79,7 (1,56×), et garde sa queue de distribution dans le pire cas serrée : p95 960,4 ms contre le pic de première page de PaddleOCR à 3 331,4 ms (une queue 3,5× plus serrée). Son empreinte est également plus simple à déployer — un runtime PyTorch unique avec une large couverture linguistique, par rapport à la pile de frameworks plus lourde de PaddlePaddle.

Une apparente contradiction mérite une explication honnête : PaddleOCR a une latence médiane par page plus faible (297,0 ms p50 contre 413,6 ms pour EasyOCR) mais un débit en pages par minute plus faible (79,7 contre 124,5). Les deux chiffres mesurent des horloges différentes. La latence p50 est l'inférence par page en régime permanent, mesurée à chaud (modèle déjà chargé) ; les pages/min sont le débit en temps réel de l'ensemble de l'exécution, qui inclut l'initialisation du modèle et les effets de lot. Le runtime plus petit et plus rapide à charger d'EasyOCR gagne la course de volume en temps réel ; l'inférence par page de PaddleOCR est individuellement plus rapide une fois à chaud. Les deux chiffres sont réels ; ils décrivent des choses différentes, et une charge de travail dominée par la surcharge de chargement du modèle (nombreux petits lots, démarrages à froid fréquents) bénéficiera de l'avantage en temps réel d'EasyOCR, tandis qu'un pipeline long et à chaud bénéficiera de l'avantage par page de PaddleOCR.

Le coût est calculé comme le temps d'exécution en temps réel × le tarif RTX 4090 de RunPod ($0.76/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, y compris la 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) ; le p95 de 3 331 ms de PaddleOCR est un pic de première page/prefill, et non son comportement en régime permanent.

Source : summary_metrics.csv — colonnes latency_p50_ms / latency_p95_ms, lignes sroie_2019. PaddleOCR p50 296,99 / p95 3331,35 ; 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. PaddleOCR 0,2214, EasyOCR 0,1098. Coût = temps d'exécution en temps réel × $0.76/h incluant l'init du modèle, prix horodaté dans les manifestes d'exécution (août 2026). Aucun des deux moteurs n'est le moins cher du benchmark — docTR détient ce titre à $0.048 pour 1 000 pages (ligne doctr/sroie_2019 de summary_metrics.csv).

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 de $0,76/h horodaté dans les manifests) ; le coût inclut l'initialisation du modèle. Valeurs exactes : PaddleOCR p50 296,99 / p95 3331,35 / 79,71 pg/min / $0,2214 ; EasyOCR p50 413,64 / p95 960,37 / 124,53 pg/min / $0,1098. L'inversion p50 vs pages/min est expliquée dans le texte ci-dessus : inférence par page en régime permanent (PaddleOCR gagne) vs débit en temps réel incluant l'initialisation et les effets de lot (EasyOCR gagne).

CORD (reçus indonésiens) : les deux s'effondrent, mais la récupération de champs par LLM de PaddleOCR survit

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) sert de test de résistance inter-langues — et les deux s'effondrent sur le CER brut : 0.9083 (PaddleOCR) 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 de référence, les chiffres CORD sont maintenus à 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 pour chaque moteur, en plus de la véritable inadéquation linguistique.

Les métriques de champs racontent une histoire différente de celle des CER quasi identiques. Grâce au postprocesseur LLM, le F1 de champ de PaddleOCR se maintient à 0.5527 contre 0.3378 pour EasyOCR sur CORD — le même schéma SROIE, étendu : la récupération en aval par LLM de PaddleOCR résiste au choc linguistique que celle d'EasyOCR ne supporte pas, même lorsque les deux reconnaisseurs de texte échouent au niveau des caractères. Le F1 de champ LLM de CORD pour EasyOCR est le deuxième plus bas des huit moteurs (au-dessus seulement de celui de Tesseract à 0.1627, lignes cord_v2 de summary_metrics.csv/field_method_comparison.csv) — encore une fois à la traîne derrière des moteurs avec un CER pire, le paradoxe persistant sur les deux ensembles de données. 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.

Table : summary_metrics.csv (cer / cost_per_1000_pages / pages_per_minute) et field_method_comparison.csv (field F1), lignes cord_v2. Ne pas fusionner les chiffres CORD dans aucun classement SROIE : le CER CORD combine un véritable décalage 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 du champ regex s'effondre à ~0–2 % sur les deux moteurs. Le F1 du champ LLM de PaddleOCR de 0,5527 sur CORD répète son avantage SROIE (0,5810 contre 0,3717) — sa récupération en aval par LLM survit au choc linguistique que celle d'EasyOCR ne survit pas.

Qui gagne quand : la grille récapitulative

“Mieux” dépend de la charge de travail, et ce face-à-face sépare clairement les axes : chaque axe de précision sur les reçus anglais favorise PaddleOCR ; le coût, le débit en temps réel, la latence de queue et la simplicité de déploiement favorisent EasyOCR ; et le championnat de précision de texte brut n'appartient à aucun des deux (Surya2/docTR) — tandis que le résultat en aval par LLM d'EasyOCR est sa plus grande réserve, pas son argument de vente.

Questions fréquentes

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

Oui, sur tous les axes de précision mesurés dans ce benchmark. Sur SROIE 2019 : CER 0,2045 contre 0,2833 (amélioration relative de 27,8 %), WER 0,3256 contre 0,6158, F1 des champs regex 0,3254 contre 0,1477 (2,2×), F1 des champs post-traités par LLM 0,5810 contre 0,3717 (summary_metrics.csv et field_method_comparison.csv, lignes sroie_2019). Aucun des deux moteurs n'est le champion global du texte du benchmark — Surya2 (CER 0,1915) et docTR (0,1971) détiennent ce titre.

EasyOCR est-il moins cher que PaddleOCR ?

Oui — environ 2× moins cher pour 1 000 pages sur des reçus en anglais : 0,110 $ contre 0,221 $ sur SROIE 2019, écart qui se creuse à 0,086 $ contre 0,342 $ sur CORD, sur le même RTX 4090 à 0,76 $/h, avec un coût incluant l'initialisation du modèle (summary_metrics.csv, cost_per_1000_pages, lignes sroie_2019 et cord_v2). Le moteur le moins cher du benchmark est docTR à 0,048 $ pour 1 000 pages.

Lequel est le plus rapide : PaddleOCR ou EasyOCR ?

Cela dépend de l'horloge à laquelle vous vous référez. PaddleOCR a une latence médiane en régime permanent plus faible (297,0 contre 413,6 ms p50), mais EasyOCR a un débit horloge murale plus élevé (124,5 contre 79,7 pages/min) car les pages/min en horloge murale incluent l'initialisation du modèle et les effets de lot, et le runtime plus léger d'EasyOCR se charge plus rapidement (summary_metrics.csv, latency_p50_ms / pages_per_minute, lignes sroie_2019). Pour un pipeline chaud de longue durée, PaddleOCR est plus rapide par page ; pour de nombreux petits lots froids ou fréquents, EasyOCR gagne la course à l'horloge murale.

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é du benchmark, actuellement sans mécanisme prouvé. Le CER SROIE d'EasyOCR (0,2833) se classe quatrième sur huit moteurs, mais son F1 de champs post-traités par LLM (0,3717) se classe dernier — même en dessous 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 dispose ou joint les lignes de texte, qui dégrade l'extraction LLM en aval ; elle est étiquetée comme un schéma observé et reproductible, avec un mécanisme non vérifié (field_method_comparison.csv, llm_field_value_f1, lignes sroie_2019).

Pourquoi les deux moteurs obtiennent-ils des scores si faibles sur les reçus CORD ?

Deux causes cumulatives que le protocole sépare du classement SROIE : un véritable décalage linguistique (les reçus indonésiens sortent du périmètre 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,9083 (PaddleOCR) 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 : F1 de champ PaddleOCR 0,5527 contre 0,3378 pour EasyOCR — le schéma SROIE persiste même lorsque les deux reconnaisseurs échouent au niveau des caractères.

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

Si votre pipeline consomme des champs — valeurs extraites pour l’entreprise, la date, les totaux — PaddleOCR est le choix par défaut évident sur les reçus : F1 de champ 2,2× supérieur avec regex, 1,56× avec un LLM, et une récupération en aval par LLM qui survit au choc linguistique CORD (field_method_comparison.csv). Si vous avez besoin de volume en masse à faible coût, d’une queue de distribution serrée, d’une pile légère ou d’une large couverture linguistique pour démarrer, EasyOCR est réellement compétitif sur l’axe opérationnel (2× moins cher, débit 1,56× supérieur, p95 3,5× plus serré, plus de 80 langues) — mais prévoyez un budget pour sa faiblesse en aval LLM avant de vous engager. Ces résultats valent pour les reçus en anglais et en indonésien sur un niveau de GPU en août 2026 ; relancez 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 propriétaire — results/summary_metrics.csv (CER/WER, F1 de champ regex, latence, coût, débit) et results/field_method_comparison.csv (post-traitement regex vs 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 extrait comparatif d'un benchmark indépendant et reproductible (tier officiel) — il ne s'agit ni d'une enquête sur des affirmations de tiers, ni d'une page de comparaison de fournisseurs. Uniquement des ensembles de test fixes : test SROIE 2019 (361 reçus en anglais, champs plats entreprise/date/adresse/total) et test CORD v2 (100 reçus en indonésien, champs imbriqués menu/sous-total/total) ; les ensembles 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 : une passe de préchauffage fixe précède la passe notée, de sorte que les chiffres de latence reflètent un état stable). Les deux exécutions ont atteint error_rate 0.0 sur les deux ensembles 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 qu'à titre de 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 fonctionné 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 réglage fin. Versions verrouillées : PaddleOCR 3.7.0 (OCR moderne d'apprentissage profond en deux étapes — détection + reconnaissance PP-OCR, GPU) et EasyOCR 1.7.2 (ResNet+CRNN classique avec décodage CTC, GPU) — conformément au tableau des modèles du dépôt public (README.md) et aux manifestes d'exécution. La ligne SROIE d'EasyOCR a été revérifiée lors d'une nouvelle exécution torch 2.8 du 17-08-2026 (exécutions répétées r1/r2/r3 octet-identiques) ; les CSV publiés portent ces valeurs corrigées.
• Postprocesseur LLM : deepseek-v4-flash via API à température 0 pour une sortie déterministe (colonne llm_model dans 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 mural × 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) — champs extraits du texte OCR par un ensemble de motifs fixes. Elles mesurent l'OCR + l'extraction en aval, et non 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 de caractères) : 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 de mots) : le même calcul de distance d'édition au niveau des mots.
• F1 de valeur de champ (regex) : moyenne harmonique précision/rappel sur les valeurs de champs 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 de valeur 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 mélangés.
• Champs de document exacts : fraction de 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 (mesuré après échauffement, hors chargement du modèle) et débit horloge murale incluant l'initialisation du modèle. Ils mesurent des horloges différentes ; l'inversion p50-vs-pages/min sur cette page est une différence de modèle de mesure, pas une erreur.
• Coût pour 1 000 pages : heures GPU facturées pour 1 000 pages au tarif enregistré de 0,76 $/heure, 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 nombre CER/WER, de latence, de coût et de débit sur cette page provient des lignes paddleocr et easyocr ici.
2. field_method_comparison.csv (GitHub raw). 16 lignes ; colonnes model, dataset, llm_model (= deepseek-v4-flash), précision et F1 de valeur de champ regex/llm, champs de document exacts, llm_median_latency_ms, nombres de jetons. Chaque nombre de F1 de champ regex/LLM provient des lignes paddleocr et easyocr ici (et de toutes les huit lignes sroie_2019 du tableau du paradoxe).
3. Dépôt ImageToTableai/benchmark-ocr. Dépôt public hébergeant les CSV de résultats, les manifestes d'exécution expurgés, le protocole figé et les listes d'échantillons de jeux de données (divisions de test fixes) pour la reproduction.
4. results/manifests/ (GitHub). Un manifeste.json expurgé par exécution publiée (16 exécutions) avec les versions de modèles, GPU/pilote, versions torch/CUDA/Python, métadonnées de coût avec horodatage du prix et hachages d'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 des documents — reçus uniquement : SROIE + CORD. Rien ici ne mesure les capacités de structure/layout/tableau/document de PP-Structure de PaddleOCR, la couverture de plus de 80 langues d'EasyOCR sur des textes autres que des reçus, ni aucun autre type de document. N'utilisez pas cette page pour conclure que l'un ou l'autre moteur « gagne sur tout ».
• Taille de l'échantillon : 361 reçus en anglais + 100 reçus en indonésien. Le F1 par champ et le CER dépendent du corpus ; des différences de quelques centièmes doivent être considérées comme du bruit, pas comme une vérité d'ingénierie — bien que les écarts documentés ici (27,8 % de CER, 2,2× de F1 regex) dépassent largement cette marge.
• Un seul niveau de GPU et un seul prix : tous les chiffres proviennent d'un seul RTX 4090 à 0,76 $/h, prix horodaté 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 d'établir un budget.
• Un seul postprocesseur LLM : toutes les lignes LLM utilisent deepseek-v4-flash à température 0. Un LLM différent modifie le F1 absolu par champ ; l'ampleur du paradoxe EasyOCR peut varier avec le LLM, bien que le schéma observé se soit maintenu avec ce seul postprocesseur sur les deux ensembles de données. La latence du LLM (~1 817–2 005 ms de 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 par 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, le mécanisme causal n'étant 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 : l'ensemble de motifs a été écrit une fois par ensemble de données. Une bibliothèque de motifs fortement réglée par format pourrait obtenir des scores plus élevés sur ses propres mises en page — au prix de la maintenance que le LLM élimine.
• Le CER CORD n'est pas une mesure de qualité par modèle : la vérité terrain CORD intègre la structure d'annotation et aucun des deux moteurs n'a été principalement entraîné sur 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 un cadrage et ne sont jamais fusionnées dans aucun classement SROIE (règle de protocole).
• Épinglage des versions : les résultats valent pour PaddleOCR 3.7.0 et EasyOCR 1.7.2 (août 2026). Les versions plus récentes de l'un ou l'autre moteur peuvent modifier chaque chiffre de cette page.

Références connexes : Benchmark de reçus docTR vs Surya2 · le face-à-face OCR vs VLM · règles regex contre extraction par LLM · précision des caractères contre précision des champs · Précision de l'OCR sur reçus

Lectures complémentaires : comment l'OCR par IA se compare à l'OCR classique · extraction d'images par IA comparée à l'OCR traditionnel · Tarification de l'extraction de documents par IA (2026)