Résultats du benchmark OCR de reçus :
Précision, latence et coût de 5 modèles OCR open-source (2026)

Le paradoxe : le meilleur lecteur de texte, le pire extracteur de champs

La même exécution du benchmark a produit à la fois le meilleur et le pire résultat d'extraction de champs sur les 361 reçus. La différence ne tient pas à la qualité des données — elle tient à la différence entre lire du texte et extraire des champs.

Deux métriques de précision répondent à des questions différentes. Le taux d'erreur sur les caractères (CER) mesure le nombre de caractères mal lus par rapport à la transcription de référence — un CER de 19,7 % signifie environ un caractère erroné sur cinq. Le taux d'erreur sur les mots (WER) fait échouer un mot entier dès qu'un seul caractère est mal lu à l'intérieur, ce qui explique pourquoi les valeurs de WER sont toujours supérieures au CER. Le F1 de champ, dans ce benchmark, mesure si les quatre champs SROIE — nom de l'entreprise, date, adresse et total — peuvent être récupérés à partir du texte OCR par un postprocesseur à base d'expressions régulières fixes, calculé comme la moyenne harmonique de la précision et du rappel sur l'ensemble des champs des 361 documents.

docTR a produit la transcription la plus propre (19,7 % de CER, 32,0 % de WER), mais sa récupération de champs s'est effondrée à 7,7 % de F1 — un passage d'expressions régulières sur un texte propre peut encore échouer lorsque le format des valeurs (symboles monétaires, totaux à virgule décimale, adresses sur plusieurs lignes) ne correspond pas au motif d'extraction. La transcription de PaddleOCR était légèrement plus bruitée (20,5 % de CER), mais sa sortie correspondait mieux aux motifs de champs, donnant 32,5 % de F1. Aucun de ces résultats n'est une erreur — ce sont deux couches différentes de la même chaîne de traitement, et aucun modèle de ce lot n'a obtenu ne serait-ce qu'un seul document entièrement correct sur les quatre champs (correspondance exacte au niveau document = 0 pour chaque modèle). C'est le sens pratique de l'affirmation selon laquelle la précision du texte OCR n'est pas la précision des champs.

Résultats SROIE 2019 : précision du texte, F1 de champ, latence et coût

L'ensemble de classement principal est SROIE 2019 (Scanned Receipt OCR and Information Extraction, le jeu de données de la compétition ICDAR 2019) — 361 reçus numérisés en anglais dans la répartition de test officielle fixe, évalués avec les cinq modèles dans le même groupe d'exécution sur le même GPU. Un CER/WER plus faible est meilleur ; un F1 de champ plus élevé est meilleur.

Source : ImageToTable.ai Receipt OCR Benchmark v1, répartition de test SROIE 2019 (361 échantillons). Exécutions : niveau officiel, protocole warm_then_scored, RTX 4090. IC bootstrap à 95 % via 2 000 rééchantillonnages. Pack d'artefacts complet disponible sur demande. Jeu de données : compétition ICDAR 2019 SROIE.

Source : ImageToTable.ai Receipt OCR Benchmark v1, split de test SROIE 2019. Toutes les métriques proviennent d'artefacts de prédiction figés (n=361 par modèle, taux de réussite de 100 %). CER/WER : taux d'erreur sur les caractères/mots par rapport à la transcription de référence. F1 de champ : extraction de champs post-traitée à partir du texte OCR via une regex fixe — PAS une sortie de champs native du modèle (aucun des cinq modèles n'émet de champs structurés natifs). IC : intervalle de confiance bootstrap à 95 %, 2 000 rééchantillonnages. Coût : calculé sur RunPod RTX 4090 à 0,76 $/heure (prix relevé le 11/08/2026). Artefacts complets disponibles sur demande.

Pourquoi le F1 de champ est si loin derrière la précision textuelle

Chaque modèle de ce lot lit le texte correctement, mais aucun ne produit de champ structuré exploitable sur la plupart des reçus — le meilleur F1 de champ est de 32,5 %, et aucun modèle n'a produit un seul document entièrement correct (entreprise + date + adresse + total, tous exacts).

Les métriques de champ SROIE présentées ici sont post-traitées par regex : le benchmark prend le texte OCR de chaque modèle et applique une extraction fixe basée sur des motifs pour les quatre champs. C'est volontairement différent de la sortie native de champs structurés d'un modèle — aucun des cinq moteurs OCR open source de ce lot n'émet de champs structurés natifs pour la mise en page des reçus, le postprocesseur est donc la seule voie de champ disponible pour eux. L'écart entre un CER de 19,7 % et un F1 de champ de 7,7 % est ce qu'un pipeline d'extraction réel paie pour la couche de sortie structurée manquante : un texte de haute qualité nécessite encore une compréhension de la mise en page et une normalisation des valeurs pour devenir des champs.

L'inversion du classement entre les modèles est stable : PaddleOCR mène le F1 de champ à 32,5 % (IC 30,5–34,5 %), suivi de Tesseract 23,2 %, Docling 22,3 %, EasyOCR 14,8 % et docTR 7,7 % — tandis que le classement des métriques textuelles est presque exactement inversé en tête (docTR 19,7 % de CER contre 20,5 % pour PaddleOCR). Tout pipeline qui ne rapporte que la « précision OCR » masque la couche d'extraction de champs où se trouve la véritable variance.

CORD v2 : le test de résistance linguistique

Sur 100 reçus en indonésien (CORD v2), le CER de chaque modèle s'effondre à 90–95 % — une pile OCR entraînée sur l'anglais ne se transfère pas à une autre langue, et ce benchmark quantifie la pénalité au lieu de l'éluder.

CORD v2 (un jeu de données consolidé de reçus conçu pour l'analyse post-OCR) fournit le test de résistance inter-langues. Ses 100 échantillons de test examinés sont des reçus en indonésien, et chaque modèle de ce lot a été principalement entraîné sur des données anglaises. Les résultats ci-dessous ne constituent pas un classement de la qualité des modèles — les métriques textuelles CORD sont présentées comme preuve de robustesse reçu/langue/mise en page et ne doivent pas être fusionnées avec SROIE dans un classement global unique. Les métriques de champ ne sont pas applicables sur CORD, car aucun modèle n'émet de champs structurés natifs CORD et aucun postprocesseur CORD n'est défini pour ce lot.

Source : ImageToTable.ai Receipt OCR Benchmark v1, split de test CORD v2 (100 échantillons). Toutes les exécutions en niveau officiel, RTX 4090, taux de réussite de 100 %. Avertissement : test de résistance au décalage linguistique — ne comparez pas les valeurs CER de CORD aux valeurs CER de SROIE. Jeu de données : CORD v2 (Clova AI).

Vitesse et coût : l'écart de 7,7×

Sur du matériel identique, le débit varie de 7,7× et le coût pour 1 000 pages varie de 7,8× — pour un volume de reçus, choisir le modèle le plus rapide peut réduire le coût de calcul OCR d'environ 87 % avant même de considérer la précision.

Le débit est rapporté de deux manières dans ce benchmark : la latence p50/p95 par page (à partir des enregistrements de prédiction réussis, hors initialisation du runner) et le nombre de pages par minute en temps réel de bout en bout (y compris le démarrage du processus runner en mode warm_then_scored). Le coût pour 1 000 pages est calculé à partir du temps d'exécution au tarif enregistré de 0,76 $/heure sur RunPod RTX 4090. Les graphiques ci-dessous montrent le débit en temps réel et le coût sur SROIE ; CORD suit la même tendance, docTR et PaddleOCR étant à nouveau les plus rapides et les moins chers.

Source : ImageToTable.ai Receipt OCR Benchmark v1, split de test SROIE 2019 (361 échantillons). Pages par minute en temps réel issues d'exécutions chronométrées du benchmark, y compris l'initialisation du runner. Toutes les exécutions en niveau officiel, RTX 4090.

Source : ImageToTable.ai Receipt OCR Benchmark v1, split de test SROIE 2019. Coût = temps d'exécution × 0,76 $/h (RunPod RTX 4090, tarif enregistré le 11/08/2026). Inclut la surcharge d'initialisation par exécution.

Comment choisir un modèle à partir de ces résultats

Il n'existe pas de modèle « meilleur » unique dans ce benchmark — les résultats permettent de choisir par priorité, et le même tableau répond à différentes questions. Trois priorités courantes correspondent directement aux données :

• Si la précision brute de transcription est l'objectif (indexation plein texte, numérisation lisible) : docTR est en tête avec 19,7 % de CER et est également le plus rapide et le moins cher à 256,0 pages/min et 0,049 $ pour 1 000 pages — il remporte simultanément les trois critères de précision textuelle, de vitesse et de coût.
• Si l'extraction structurée de champs est l'objectif (alimentation de systèmes en aval nécessitant société/date/total) : PaddleOCR est en tête avec 32,5 % de F1 de champ, mais cela représente tout de même un taux d'échec de champs d'environ 2 sur 3 — la conclusion honnête est qu'aucun de ces moteurs OCR open source ne fournit à lui seul une extraction de champs de reçus de qualité production sans une couche d'extraction structurée par-dessus.
• Si le coût à volume est la contrainte : l'écart de coût de 7,8× signifie qu'un million de pages coûte environ 49 $ avec docTR contre 381 $ avec Docling — une différence d'environ 332 $ par million de pages sur du matériel identique.

Quelle que soit la priorité, le protocole et les artefacts vous permettent de reproduire chaque chiffre de ce tableau sur votre propre GPU avant de vous engager — et pour un flux de reçus multilingue, les résultats CORD constituent un avertissement : les modèles entraînés sur l'anglais doivent d'abord être testés sous contrainte sur la langue cible.

Questions fréquentes

Quel modèle OCR open-source est le plus précis sur les reçus ?

Cela dépend de la métrique : docTR offre la meilleure précision textuelle (19,7 % de CER sur 361 reçus SROIE) tandis que PaddleOCR offre la meilleure extraction de champs (32,5 % de F1 de champ) dans le benchmark ImageToTable.ai Receipt OCR Benchmark. Aucun modèle ne domine sur les deux — la précision textuelle et l'extraction de champs relèvent de couches de pipeline différentes.

Pourquoi la précision textuelle de docTR est-elle meilleure mais son extraction de champs moins bonne que celle de PaddleOCR ?

Parce que les deux métriques mesurent des couches de pipeline différentes. docTR a lu les caractères plus précisément (19,7 % de CER contre 20,5 %) mais sa sortie ne correspondait pas aux motifs regex fixes des champs pour société/date/adresse/total, faisant chuter son F1 de champ post-traité à 7,7 % tandis que PaddleOCR atteignait 32,5 %. Un texte plus propre ne garantit pas une meilleure extraction de champs lorsque le format des valeurs (symboles monétaires, séparateurs de virgules, disposition multiligne) diverge du motif d'extraction.

PaddleOCR est-il meilleur que Tesseract pour l'OCR de reçus ?

Oui sur toutes les métriques de ce benchmark : PaddleOCR bat Tesseract sur le CER (20,5 % contre 33,6 %), le WER (32,6 % contre 56,2 %), le F1 de champ (32,5 % contre 23,2 %), la vitesse (157,8 contre 54,4 pages/min) et le coût (0,080 $ contre 0,233 $ pour 1 000 pages) sur le jeu de test SROIE de 361 reçus.

La précision de l'OCR diminue-t-elle pour les reçus non anglophones ?

Considérablement : sur 100 reçus indonésiens CORD v2, chaque modèle entraîné sur l'anglais a obtenu un CER de 90–95 % (PaddleOCR 90,8 % meilleur, Tesseract 95,2 % pire) contre 20–58 % sur les reçus SROIE anglais. Considérez cela comme un test de résistance linguistique, pas comme un classement des modèles — ces mêmes modèles n'ont pas été entraînés pour l'indonésien.

Combien coûte l'OCR open-source par page sur un GPU ?

Entre 0,049 $ et 0,381 $ pour 1 000 pages sur un RTX 4090 au tarif RunPod enregistré de 0,76 $/heure — environ 0,00005 $ à 0,0004 $ par page, démarrage inclus, selon le modèle.

Qu'est-ce que SROIE et que teste-t-il ?

SROIE 2019 (Scanned Receipt OCR and Information Extraction) est le jeu de données du concours ICDAR 2019 composé de reçus anglais numérisés réels avec transcription et vérité terrain des champs clés — ce benchmark utilise sa répartition de test fixe de 361 échantillons. Il teste si un modèle OCR peut lire le texte des reçus (CER/WER) et récupérer les champs société, date, adresse et total ; pour les modèles open-source ici, les champs ont été récupérés via un postprocesseur regex fixe, car aucun n'émet de champs structurés natifs.

Puis-je reproduire moi-même ces chiffres de benchmark ?

Oui. Le protocole du benchmark est versionné et figé, tous les jeux de données sont publiquement disponibles (SROIE d'ICDAR 2019, CORD v2 de Clova AI), et les cinq modèles sont open-source avec des versions publiées. Le package complet d'artefacts — prédictions, métriques, manifestes, journaux de performance — est disponible sur demande. Une réserve : les manifestes actuels sont antérieurs à l'empreinte d'environnement du schéma v2, et une réexécution dans les environnements de modèles exacts serait nécessaire pour une reproductibilité intégrale octet par octet ; voir Limitations.

Méthodologie et sources

Protocole

Ce benchmark suit un protocole versionné et figé (v0.1, 2026-08-11). Chaque chiffre de cette page provient d'un artefact de prédiction spécifique produit selon le protocole, et chaque exécution satisfait le même ensemble de critères de publication : run_tier=official, expected_split=test, aucune prédiction manquante, et toutes les métriques not_applicable conservées telles quelles (non converties en zéro). Un audit qualité (2026-08-12) a vérifié tous les contrats de prédiction, les hachages d'échantillons et les hachages de performance.

Environnement d'exécution

Comment reproduire

Le code du benchmark, les scripts d'exécution et les évaluateurs sont maintenus dans le dépôt ImageToTable.ai benchmark-ocr (commit Git 8bdc616 ; publication publique à venir). Les commandes exactes qui ont produit chaque chiffre de cette page :

export BENCHMARK_RUN_TIER=official
export BENCHMARK_EXPECTED_SPLIT=test
export BENCHMARK_MEASUREMENT_MODE=warm_then_scored
export BENCHMARK_GPU_LABEL="rtx_4090"
export BENCHMARK_GPU_PROVIDER="runpod"
export BENCHMARK_GPU_HOURLY_USD="0.76"
export BENCHMARK_FIELD_POSTPROCESSOR=sroie_receipt_regex

for model in tesseract paddleocr easyocr doctr docling; do
  BENCHMARK_WARMUP_SAMPLES=sroie_warmup_5.jsonl \
    bash server/run_model.sh "$model" sroie 361 "receipt-v1-sroie-${model}"
done

unset BENCHMARK_FIELD_POSTPROCESSOR

for model in tesseract paddleocr easyocr doctr docling; do
  BENCHMARK_WARMUP_SAMPLES=cord_v2_warmup_5.jsonl \
    bash server/run_model.sh "$model" cord_v2 100 "receipt-v1-cord-v2-${model}"
done

Tous les modèles ont été utilisés out-of-the-box avec leurs configurations par défaut. Aucun réglage fin, aucun pack de langue personnalisé, aucune adaptation post-entraînement. Consultez le dépôt du benchmark pour les scripts d'exécution par modèle et la configuration de l'environnement.

Définitions des métriques

• CER (taux d'erreur sur les caractères) : distance de Levenshtein au niveau des caractères divisée par le nombre de caractères de référence (plus bas = mieux). IC bootstrap à 95 % via 2 000 rééchantillonnages, graine 20260811.
• WER (taux d'erreur sur les mots) : distance de Levenshtein au niveau des mots (tokenisation par espaces) divisée par le nombre de mots de référence (plus bas = mieux). Même méthode d'IC que le CER.
• F1 de champ (SROIE uniquement) : moyenne harmonique de la précision et du rappel sur les quatre champs SROIE (company, date, address, total), extraits du texte OCR par un postprocesseur regex fixe (sroie_receipt_regex). Il ne s'agit PAS d'une sortie native de champs structurés du modèle — les cinq modèles ont non applicable pour les métriques de champs natives.
• Latence p50 / p95 : temps d'inférence par page (ms) à partir des enregistrements de prédiction réussis, hors initialisation de l'exécuteur.
• Pages/min en temps réel : nombre total d'échantillons notés divisé par le temps total d'exécution, y compris le démarrage du processus de l'exécuteur. Plus haut = mieux.
• Coût pour 1 000 pages : temps d'exécution (heures) × 0,76 $ × (1 000 / nombre d'échantillons). Utilise les métadonnées réelles de prix du fournisseur, pas des tarifs estimés.
• Taux de réussite : 100 % pour les 10 exécutions de ce lot (0 erreur, 0 délai dépassé, 0 prédiction manquante).

Jeux de données

1. SROIE 2019 (Scanned Receipt OCR and Information Extraction) — ICDAR 2019 Robust Reading Competition, Task 3. 361 reçus réels scannés en anglais avec transcription texte au niveau des lignes et quatre étiquettes de référence de champs clés (company, date, address, total). Split de test fixe.
2. CORD v2 (Consolidated Receipt Dataset) — Clova AI Research, NAVER Corp. 100 échantillons de reçus en indonésien issus du split de test public, utilisés comme test de résistance inter-langues. Inclut les éléments de ligne imbriqués du menu et la vérité terrain des sous-totaux/totaux (non notés dans ce lot — nécessite des émetteurs de champs structurés natifs).

Modèles testés

Accès aux artefacts et reproductibilité

Code source du benchmark : maintenu dans le dépôt benchmark-ocr (commit Git 8bdc616). Le dépôt comprend des scripts d'exécution par modèle, des évaluateurs (CER/WER, métriques de champ, IC bootstrap), des manifestes d'échantillons de jeux de données avec hachages SHA256, et le protocole figé. La publication publique est en attente — une fois publiée, chaque chiffre de cette page sera reproductible de manière indépendante en clonant le dépôt, en obtenant les jeux de données publics et en exécutant les commandes ci-dessus sur une RTX 4090.

Paquet d'artefacts complet : prédictions par modèle (*.jsonl), métriques avec IC à 95 % (metrics.csv), diagnostics au niveau des champs (field_details.csv), journaux de performance en temps réel (performance.json) et manifestes d'exécution (manifest.json) sont versionnés selon le protocole et disponibles avec le code source. Contactez [email protected] pour un accès anticipé avant la publication publique.

Note sur le schéma v1 : les manifestes actuels sont antérieurs à l'empreinte d'environnement du schéma v2 (qui capture le système d'exploitation, la version CUDA et les versions des paquets Python par modèle au moment de l'exécution). Le tableau d'environnement ci-dessus reflète ce que le schéma v1 enregistre ; une reproductibilité intégrale octet par octet nécessitera une nouvelle exécution avec le schéma v2. Cela n'affecte pas l'exactitude des métriques rapportées.

Limites

• Schéma de manifeste v1 : les manifestes des exécutions actuelles sont antérieurs à l'empreinte d'environnement du schéma v2, qui capture l'environnement Python exact au moment de l'exécution. Une reproductibilité intégrale octet pour octet nécessite une réexécution avec le schéma v2 dans les environnements de modèles exacts.
• Les métriques de champ SROIE sont post-traitées par regex, pas une extraction native : le F1 de champ mesure la récupération des champs à partir du texte OCR via des motifs fixes — ce n'est pas la capacité native de structuration des champs des modèles (qui n'est disponible pour aucun modèle de ce lot).
• Les résultats CORD sont un test de stress de décalage linguistique, pas un classement de précision : les cinq modèles sont entraînés en anglais ; les valeurs CER de CORD (90 % et plus) quantifient l'effondrement interlinguistique et ne doivent pas être fusionnées avec SROIE dans un classement unique.
• PaddleOCR-VL exclu du classement : exclu en raison de problèmes directs de pipeline ; ses résultats ne sont pas comparables aux cinq modèles classés.
• Surya2 et Unlimited-OCR non inclus : ils nécessitent un pod serveur vLLM et sont prévus pour un lot v1.1 ; la version actuelle couvre uniquement le groupe local_torch.
• Niveau GPU unique uniquement : toutes les exécutions sont sur RTX 4090 ; aucune comparaison multi-GPU ou RTX 3090/A100 n'est disponible pour l'instant, donc les conclusions sur les coûts et le débit sont spécifiques à ce seul niveau.
• Modèles open-source uniquement : aucun modèle cloud/API (AWS Textract, Google Document AI, Azure Form Recognizer) n'est inclus ; leur comparaison fait l'objet d'un benchmark distinct prévu.

Références associées : Précision de l'OCR des reçus · Précision de l'OCR par type de document · Qu'est-ce que l'OCR ?

Lectures complémentaires : ABBYY FineReader vs OCR IA moderne · OCR Adobe Acrobat vs extraction IA · Comment lire les affirmations de précision de l'OCR