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

Les deux moteurs représentent deux générations de reconnaissance optique de caractères par apprentissage profond. PaddleOCR (basé sur PaddlePaddle, architecture PP-OCR, v3.7.0) est un pipeline en deux étapes moderne : une étape de détection localise les régions de texte, puis une étape de reconnaissance les transcrit — conçu pour une forte précision sur le texte imprimé à grande échelle. 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 Connectioniste. Il est connu pour sa très large couverture linguistique et scripturale (plus de 80 langues prêtes à l'emploi) et une installation notoirement 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 ~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 meilleur pour 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 partition de test SROIE 2019, l'architecture moderne gagne sur les deux métriques de texte : CER 0,2045 contre 0,2833 (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 au niveau des 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 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 : PaddleOCR cer 0.20449 / wer 0.32563 ; EasyOCR cer 0.28327 / wer 0.61578. Un CER/WER plus bas est meilleur. Aucun moteur n'est le champion de la précision globale du benchmark — ce titre revient à Surya2 (CER 0.1915) et docTR (CER 0.1971) dans la même course à 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çus plats (entreprise, date, adresse, total) en utilisant deux post-traitants sur le texte OCR de chaque moteur : des modèles regex fixes (l'approche traditionnelle OCR + extraction d'informations clés basée sur des règles) et un post-traitant LLM (deepseek-v4-flash à température 0) avec un prompt structuré. Par regex, PaddleOCR extrait les champs avec un F1 de 0,3254 contre 0,1477 pour EasyOCR — un avantage de 2,2× ; par le LLM, l'écart persiste avec 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 du reçu est parfaitement récupéré, 0 signifie rien. Les colonnes de champs regex SROIE sont les métriques postprocessed_sroie_receipt_regex_* du benchmark : des modèles fixes appliqués au texte OCR de chaque moteur (post-traité, pas la sortie structurée native). Notez le contexte de classement : le 0,3254 de PaddleOCR est le troisième meilleur résultat en champs regex dans le 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, field_f1_regex, lignes sroie_2019).

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 — colonnes regex et llm, lignes sroie_2019. Les colonnes regex sont les métriques postprocessed_sroie_receipt_regex_* : motifs fixes appliqués au texte OCR de chaque moteur. Post-traitement LLM : deepseek-v4-flash à température 0 (colonne llm_model). La latence LLM est imposée par l'API et distincte de la latence du moteur (summary_metrics.csv latency_p50_ms). « Documents avec tous les champs exacts » est la fraction de documents où chaque champ cible correspondait 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 LLM d'EasyOCR : texte moyen, pire extraction en aval

C'est le point de données le plus distinctif de la page, et il est véritablement contre-intuitif : le texte OCR d'EasyOCR est au milieu du peloton en termes de précision par caractère (CER SROIE 0.2833, quatrième sur huit moteurs) — pourtant, lorsque ce texte est envoyé au même postprocesseur LLM utilisé pour tous les autres moteurs (deepseek-v4-flash, même prompt, mêmes reçus), son score F1 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 de 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 SROIE d'EasyOCR 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. L'implication pratique est l'opposé de la façade marketing : sur ce corpus, choisir EasyOCR pour un texte « suffisant » signifie prévoir la pire récupération de champs en aval LLM 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 LLM (0.3717, inférieur à celui 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 : là où EasyOCR est réellement compétitif

La précision n'est pas le seul axe, et sur l'axe opérationnel, EasyOCR présente de vrais avantages mesurés. Sur la même RTX 4090 au même tarif de $0,76/heure, 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 resserrée : p95 à 960,4 ms contre le pic de première page de PaddleOCR à 3 331,4 ms (une queue 3,5× plus resserrée). Son empreinte est également plus simple à déployer — un seul runtime PyTorch avec une large couverture linguistique, par opposition à l'empilement de frameworks plus lourd de PaddlePaddle.

Une contradiction apparente mérite une explication honnête : PaddleOCR a une latence médiane par page plus basse (297,0 ms p50 contre 413,6 ms pour EasyOCR) mais un débit en pages par minute plus bas (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'exécution complète, 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 au 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 (beaucoup de 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 durée d'exécution en temps réel × 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 par minute en temps réel incluant la même initialisation. Les latences p50/p95 sont les temps d'inférence par page en régime permanent, mesurés à chaud puis scorés (chargement du modèle exclu) ; la p95 de PaddleOCR à 3 331 ms est un pic de première page/remplissage, pas 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, exclut le chargement du modèle).

Source : summary_metrics.csv — colonne cost_per_1000_pages, lignes sroie_2019. PaddleOCR 0,2214, EasyOCR 0,1098. Coût = durée d'exécution en temps réel × $0,76/heure incluant l'initialisation du modèle, prix horodaté dans les manifests d'exécution (août 2026). Aucun des moteurs n'est le moins cher du benchmark — docTR détient ce record à $0,048 pour 1 000 pages (summary_metrics.csv, ligne doctr/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. 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 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), 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 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 de champs racontent une histoire différente des CER quasi identiques. Via le post-traitement 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 du 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 caractère. Le F1 de champ LLM d'EasyOCR sur CORD est le deuxième plus bas des huit moteurs (seulement au-dessus des 0.1627 de Tesseract, lignes cord_v2 de summary_metrics.csv/field_method_comparison.csv) — suivant encore des moteurs avec un CER plus mauvais, le paradoxe persistant sur les deux jeux de données. 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 / cost_per_1000_pages / pages_per_minute) et field_method_comparison.csv (field F1), lignes cord_v2. Ne fusionnez pas les chiffres 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, ce qui explique pourquoi le field F1 par regex s'effondre à ~0–2% sur les deux moteurs. Le field F1 LLM de PaddleOCR de 0,5527 sur CORD répète son avantage sur SROIE (0,5810 vs 0,3717) — sa récupération en aval via LLM survit au choc linguistique que celui d'EasyOCR ne surmonte pas.

Qui gagne quand : le tableau récapitulatif

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

Foire aux questions

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

Oui, sur tous les axes de précision mesurés dans ce benchmark. Sur SROIE 2019 : CER 0,2045 vs 0,2833 (amélioration relative de 27,8 %), WER 0,3256 vs 0,6158, F1 des champs par regex 0,3254 vs 0,1477 (2,2×), F1 des champs post-traités par LLM 0,5810 vs 0,3717 (summary_metrics.csv et field_method_comparison.csv, lignes sroie_2019). Aucun des deux moteurs n'est le champion global du benchmark en matière de texte — 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 de reçus en anglais : 0,110 $ vs 0,221 $ sur SROIE 2019, l'écart se creusant à 0,086 $ vs 0,342 $ sur CORD, sur le même RTX 4090 à 0,76 $/h avec 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 que vous considérez. PaddleOCR a une latence médiane en régime permanent plus faible (297,0 vs 413,6 ms p50), mais EasyOCR a un débit en temps réel plus élevé (124,5 vs 79,7 pages/min) car le débit en temps réel inclut l'initialisation du modèle et les effets de lot, et le chargement plus léger d'EasyOCR est plus rapide (summary_metrics.csv, latency_p50_ms / pages_per_minute, lignes sroie_2019). Pour un pipeline long et chaud, PaddleOCR est plus rapide par page ; pour de nombreux petits lots ou des lots fréquents à froid, EasyOCR gagne la course en temps réel.

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

C'est le paradoxe documenté du benchmark, actuellement sans mécanisme prouvé. Le CER d'EasyOCR sur SROIE (0,2833) se classe quatrième sur huit moteurs, mais son F1 des champs post-traités par LLM (0,3717) est dernier — en dessous même 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 dispose ou joint les lignes de texte, ce qui dégrade l'extraction LLM en aval ; cela est qualifié de pattern observé et reproductible dont le mécanisme n'est pas vérifié (field_method_comparison.csv, llm_field_value_f1, lignes sroie_2019).

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

Deux causes cumulatives que le protocole 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.9083 (PaddleOCR) et 0.9185 (EasyOCR) (summary_metrics.csv, cer, lignes cord_v2). Ce qui les distingue encore est la récupération en aval par LLM : PaddleOCR 0,5527 vs EasyOCR 0,3378 en F1 par champ — le schéma SROIE persiste même lorsque les deux reconnaissances échouent au niveau des caractères.

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

Si votre pipeline exploite des champs — valeurs extraites pour l'entreprise, la date, les totaux — PaddleOCR est le choix par défaut évident pour les reçus : 2,2× en F1 par champ sous regex, 1,56× sous LLM, et une récupération en aval par LLM qui survit au choc linguistique de CORD (field_method_comparison.csv). Si vous avez besoin de volumes importants à faible coût, d'une queue pire des cas resserrée, d'une pile légère ou d'une couverture linguistique étendue pour démarrer, EasyOCR est réellement compétitif sur l'axe opérationnel (2× moins cher, 1,56× de débit en temps réel, 3,5× de p95 plus serrée, 80+ langues) — mais prévoyez sa faible récupération 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, F1 par champ 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 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 direct d'un benchmark indépendant et reproductible (niveau officiel) — pas un recueil d'affirmations de tiers, ni une page de comparaison de fournisseurs. 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. Les deux moteurs ont traité les mêmes images, les mêmes vérités terrain et le même protocole de mesure (warm_then_scored : un passage de chauffage fixe précède le passage mesuré, de sorte que les chiffres de latence sont en régime permanent). Les deux exécutions se sont terminées avec un error_rate de 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 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 est calculé au tarif à la demande de RunPod de $0.76/hr, le prix étant horodaté dans le manifeste édité de chaque exécution (août 2026).
• Moteurs : en configuration par défaut, sans affinage. Versions verrouillées : PaddleOCR 3.7.0 (OCR deep learning moderne en deux étapes — détection + reconnaissance PP-OCR, GPU) et EasyOCR 1.7.2 (classique ResNet+CRNN avec décodage CTC, 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 le 2026-08-17 (exécutions répétées 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 de champs 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 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. 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 meilleur.
• 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 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 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 combinés.
• Champs-document exact : fraction des documents où tous les champs cibles correspondaient 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 mesuré, 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 ; 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 $/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 CER/WER, latence, coût et débit sur cette page proviennent 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 champ-valeur regex/llm, document-fields-exact, llm_median_latency_ms, token counts. Tous les chiffres F1 champ regex/LLM proviennent des lignes paddleocr et easyocr ici (et des huit lignes sroie_2019 dans le tableau du paradoxe).
3. Dépôt ImageToTableai/benchmark-ocr. Dépôt public hébergeant les CSV de résultats, les manifests d'exécution expurgés, le protocole figé et les listes d'échantillons de jeux de données (répartitions de test fixes) pour la reproduction.
4. results/manifests/ (GitHub). Un manifest.json expurgé 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 de la tâche 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 n'évalue les capacités de mise en page/tableau/document de PaddleOCR (PP-Structure), la couverture de 80+ langues d'EasyOCR sur du texte non-reçu, 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 reçus en indonésien. Les scores F1 et CER par champ dépendent du corpus ; des écarts d'un ou deux points de pourcentage doivent être considérés comme du bruit, pas comme une vérité technique — bien que les écarts documentés ici (27,8 % de CER, 2,2× le F1 du regex) soient bien au-delà de cette marge.
• Un seul niveau de GPU et un seul tarif : tous les chiffres proviennent d'un seul RTX 4090 à 0,76 $/h, le tarif étant horodaté en août 2026 dans les fichiers d'exécution. D'autres GPU, un service multi-GPU, une planification par lots ou des modifications de tarif impacteront la latence, le débit et le coût — recalculez les coûts aux tarifs actuels avant de budgétiser.
• Un seul LLM en post-traitement : toutes les lignes LLM utilisent deepseek-v4-flash à température 0. Un autre LLM modifierait le score F1 absolu par champ ; l'ampleur du paradoxe EasyOCR pourrait varier avec le LLM, bien que le schéma observé se soit maintenu pour ce seul post-traitement sur les deux jeux de données. La latence du LLM (~1 817–2 005 ms médian sur SROIE, champ llm_median_latency_ms du fichier field_method_comparison.csv) est imputable à l'API et ne fait pas partie de la latence propre à l'un ou l'autre moteur.
• Mécanisme du paradoxe EasyOCR non vérifié : le benchmark documente que le texte à 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é. Considérez-le comme un résultat mesuré pour planifier, pas comme une propriété prouvée de la bibliothèque.
• Paramétrage du regex : l'ensemble de motifs a été écrit une seule 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 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 deux moteurs n'a été principalement entraîné sur de l'indonésien ; le CER de CORD (~0,91) reflète un décalage 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).
• Verrouillage des versions : les résultats sont valables pour PaddleOCR 3.7.0 et EasyOCR 1.7.2 (août 2026). De nouvelles versions de l'un ou l'autre moteur peuvent modifier chaque chiffre de cette page.

Références associées : Benchmark de reçus docTR vs Surya2 · OCR traditionnel vs VLM d'analyse de documents · Regex vs extraction de champs par LLM · Précision par champ vs par caractère · Précision de l'OCR de reçus

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