Coût OCR pour 1 000 pages
8 moteurs open-source, testés (2026)

Le coût pour 1 000 pages correspond au temps GPU facturé pour traiter 1 000 pages au tarif horaire enregistré — temps d’exécution réel × 0,76 $ de l’heure, le temps d’exécution réel incluant l’initialisation du modèle. Tout le classement des coûts de cette page est calculé exactement de cette façon ; le détail des calculs figure dans la section Comment estimer votre propre coût et dans la ligne de source de chaque tableau.

La facturation étant à l’heure, le coût suit le temps, pas la précision : un moteur qui lit une page en 109 ms coûte environ 25× moins cher qu’un moteur qui la lit en 2 668 ms au même tarif. Le coût de chaque moteur diminue à mesure que la taille du lot augmente, car le coût unique d’initialisation du modèle est amorti sur davantage de pages — les chiffres en dollars ci-dessous reflètent le schéma d’exécution du benchmark (split de test fixe, mesure warm_then_scored) et ne seront pas identiques au coût de votre propre exécution.

SROIE 2019 : classement du coût pour 1 000 pages

Sur 361 reçus en anglais, les moteurs OCR traditionnels en deux étapes occupent le bas du classement et les VLM de traitement de documents le haut — mais c’est l’écart au sein de chaque famille qui surprend : PaddleOCR-VL, un VLM compact de 0,9 milliard de paramètres, se situe à 0,2048 $, soit 4,3× le coût du moteur le moins cher, tandis que son homologue VLM Surya2 coûte 22,2× le coût du moins cher — un écart de 5,2× rien que dans le cluster VLM.

Source : summary_metrics.csv — colonne cost_per_1000_pages, lignes sroie_2019. docTR 0,0479, EasyOCR 0,1098, PaddleOCR-VL 0,2048, PaddleOCR 0,2214, Unlimited-OCR 0,3879, Docling 0,3978, Surya2 1,0609. Tesseract CPU uniquement : cellule vide dans le CSV (aucune heure GPU facturée). Coût = temps d’exécution réel × 0,76 $/h (RunPod RTX 4090, tarif daté d’août 2026), initialisation du modèle incluse.

Tableau : summary_metrics.csv — cost_per_1000_pages / pages_per_minute, lignes sroie_2019 (361 échantillons chacune, error_rate 0.0). GPU à $0.76/h (RTX 4090, prix horodaté dans les manifests) ; Tesseract a tourné en CPU uniquement (cellule de coût vide par conception — aucune heure GPU facturée, pas un coût nul). Le coût inclut l'initialisation du modèle, donc le coût par page diminue avec des lots plus importants.

Le coût suit le débit, pas la précision

Classez les moteurs par coût et par précision des caractères : les deux classements ne concordent guère. La meilleure qualité de texte brut sur SROIE revient à Surya2 (CER 0,1915) — le moteur le plus cher à 1,0609 $ — tandis que la deuxième meilleure revient à docTR (CER 0,1971) — le moins cher à 0,0479 $. Le coût est une facture de temps : les 12,1 pages/min de Surya2 offrent environ 37× moins de débit que les 449,3 pages/min de docTR au même tarif horaire.

La corrélation poids-architecture est réelle mais lâche. En tant que classe, les VLM de parsing documentaire (Surya2, Unlimited-OCR, PaddleOCR-VL) se situent au-dessus des moteurs OCR traditionnels en deux étapes (docTR, EasyOCR, PaddleOCR), avec le parseur pipeline Docling entre les deux. Mais au sein de chaque classe, l’écart est large — le cluster VLM s’étend sur 5,2× (de 0,2048 $ à 1,0609 $) et le cluster traditionnel sur 4,6× (de 0,0479 $ à 0,2214 $) — et PaddleOCR-VL, le plus petit VLM de l’exécution avec 0,9 milliard de paramètres, se situe à moins de 4,3× du moteur le moins cher, tandis que Surya2 est à 22,2×. L’enseignement pratique : supposez que « plus précis = plus cher » est faux jusqu’à ce que vous le mesuriez sur vos propres documents ; dans ce benchmark, la relation entre le rang de coût et le rang de précision est effectivement découplée.

Source : summary_metrics.csv — colonne pages_per_minute, lignes sroie_2019. Pages/min en temps réel incluant l’initialisation du modèle. Tesseract a fonctionné uniquement sur CPU (78,6 pages/min sur matériel CPU).

Tableau : summary_metrics.csv — cer / latency_p50_ms / pages_per_minute / cost_per_1000_pages, lignes sroie_2019. Ratios de coût calculés par simple division par rapport à docTR’s 0.0479 (par ex., 1.0609 / 0.0479 = 22.16). Le CER de Surya2 doit être lu avec la réserve sur la normalisation de casse mentionnée dans la méthodologie (les sorties VLM sont normalisées en casse ; le CER surestime l'erreur des VLM). La latence de Tesseract est mesurée sur CPU ; sa cellule de coût est vide par conception (pas de facturation GPU).

La colonne de latence ajoute la perspective des charges de travail interactives : le coût par volume et la latence par page sont deux vues du même fait de temps réel. Le p50 de docTR de 108,7 ms en fait à la fois le moteur le moins cher pour 1 000 pages et le seul proche d’une réponse interactive ; le p50 de Surya2 de 2 668 ms en fait à la fois le plus coûteux et une charge de travail exclusivement par lots sur les reçus. Les détails de latence sont analysés dans le comparatif des 8 moteurs.

CORD (reçus indonésiens) : le coût dépend du jeu de données

Changez le jeu de documents et le classement des coûts se réorganise — ce qui prouve que le coût pour 1 000 pages n’est pas une constante du moteur. Sur CORD v2, EasyOCR devient le moteur le moins cher (0,0863 $) et docTR passe en deuxième position (0,0939 $), tandis que les repères tiennent aux deux extrémités : docTR reste proche du bas et Surya2 reste le plus coûteux (1,1616 $). L’écart sur CORD se réduit à 13,5×.

Le mécanisme est le débit sur le jeu de documents réel : les reçus indonésiens de CORD sont plus courts et moins denses en texte que ceux en anglais de SROIE, donc les pages par minute de chaque moteur changent, et le coût pour 1 000 pages suit. Les deux jeux de données sont délibérément séparés dans ce benchmark — CORD comporte aussi une inflation de la structure d’annotation dans sa vérité terrain qui rend ses lectures CER peu fiables (voir méthodologie) — traitez donc les colonnes SROIE et CORD comme deux points de données indépendants, pas comme un seul classement.

Source : summary_metrics.csv — colonne cost_per_1000_pages, lignes cord_v2. EasyOCR 0,0863, docTR 0,0939, Unlimited-OCR 0,2063, PaddleOCR-VL 0,2409, PaddleOCR 0,3419, Docling 0,5382, Surya2 1,1616. Tesseract CPU uniquement (cellule vide). Même RTX 4090 à 0,76 $ de l’heure (prix horodaté), coût incl. init. du modèle.

Tableau : summary_metrics.csv — cost_per_1000_pages, lignes cord_v2 (100 échantillons chacune). CORD est conservé séparément du classement SROIE (langue différente, structure de vérité terrain différente) ; l'intérêt de la comparaison est que le coût par 1 000 pages varie avec l'ensemble de documents, et non qu'un classement « gagne ».

Scénarios de volume mensuel (estimations dérivées)

Les chiffres par tranche de 1 000 pages se multiplient directement dans les calculs de volume dont les rédacteurs budgétaires ont besoin. À 100 000 pages/mois sur la base de coût SROIE, le temps GPU de docTR est de 4,79 $US/mois et celui de Surya2 de 106,09 $US/mois — un écart d’environ 101 $US/mois qui s’élargit à environ 1 013 $US/mois à 1 million de pages. Il s’agit d’extensions arithmétiques des chiffres mesurés par tranche de 1 000 pages, et non de nouvelles exécutions.

Tableau : Estimations dérivées sur la base de coût SROIE 2019 — pas des exécutions mesurées. Chaque cellule est une simple multiplication du cost_per_1000_pages mesuré (docTR 0,0479, Surya2 1,0609 ; lignes sroie_2019 de summary_metrics.csv) par le volume en milliers, au même tarif de 0,76 $US/h sur RTX 4090, prix horodaté d’août 2026. Temps GPU uniquement — pas de CPU, stockage, transfert sortant, orchestration ni post-traitement LLM. À 10 millions de pages/mois, Surya2 seul atteint environ 10 609 $US/mois sur cette base (10 000 × 1,0609 $US).

Le vrai profil de coût de Tesseract : pas de facture GPU, mais pas gratuit

Tesseract est le seul moteur du benchmark à fonctionner uniquement sur CPU, et sa cellule de coût est vide par conception — il n’a consommé aucune heure GPU facturée, il n’y a donc rien à facturer à 0,76 $/h. Cela ne signifie pas qu’il ne coûte rien : l’infrastructure CPU sur laquelle il s’exécute (votre propre matériel ou une instance CPU louée) représente un coût réel que ce benchmark ne quantifie pas, et son plafond de récupération des champs peut reporter les dépenses en aval.

Sur SROIE, Tesseract a maintenu 78,6 pages/min sur CPU — plus que quatre des sept moteurs GPU (PaddleOCR-VL 68,2, Docling 56,7, Unlimited-OCR 34,4, Surya2 12,1). À faible volume sur une infrastructure CPU déjà provisionnée, cela le rend réellement rentable : aucune location GPU du tout. Le revers apparaît lorsque les champs, et pas seulement le texte, sont le livrable : le texte de base faible de Tesseract limite ce qu’un LLM en aval peut récupérer — son F1 de champs LLM CORD est de 0,163 avec un CER CORD de 0,9523 (field_method_comparison.csv, ligne tesseract/cord_v2) — les économies sur le GPU peuvent donc être compensées par des dépenses de post-traitement et de correction ailleurs. Le compromis CPU-vs-GPU fait l’objet de la comparaison dédiée Tesseract vs PaddleOCR ; le plafond du postprocesseur est couvert dans la comparaison entre l’extraction par règles et par LLM.

Coût du pipeline ≠ coût du moteur : la frontière du postprocesseur LLM

Chaque chiffre de cette page est la facture GPU du moteur OCR et rien d’autre. Les pipelines de production ajoutent couramment une passe d’extraction de champs par LLM par-dessus le texte OCR — le benchmark en a exécuté une (deepseek-v4-flash) sur les 16 exécutions — et cette passe représente un coût API distinct, par jeton, qui n’apparaît dans aucun chiffre de moteur ici.

Le CSV de comparaison enregistre les nombres de jetons pour la passe de post-traitement sur SROIE — par exemple, le texte OCR de docTR a coûté 151 131 jetons de prompt + 25 377 jetons de complétion pour extraire les quatre champs du reçu — et ces nombres de jetons servent de base pour estimer la dépense supplémentaire. Cette page ne convertit délibérément pas les jetons en dollars : la tarification des LLM varie selon le fournisseur, le plan et le modèle, et tout montant en dollars deviendrait rapidement obsolète. Le coût du moteur et le coût du pipeline sont deux lignes du budget ; la ligne LLM dépend de la conception de votre prompt et de votre fournisseur, pas du moteur OCR.

Tableau : field_method_comparison.csv — llm_prompt_tokens / llm_completion_tokens, lignes sroie_2019 ; llm_model = deepseek-v4-flash. Les comptes de jetons couvrent une passe d'extraction de champs (quatre champs de reçu) sur la division de test SROIE de 361 pages. Ces données servent de base pour estimer les dépenses de post-traitement LLM ; aucune conversion en dollars n'est fournie car la tarification LLM varie selon le fournisseur et le plan.

Comment estimer votre propre coût

Vous n'avez pas besoin de relancer un benchmark de 8 moteurs pour obtenir une estimation de coût défendable pour votre propre charge de travail. La méthode du benchmark — temps réel × votre tarif horaire — se reproduit en quatre étapes et un exemple concret.

Il s'agit d'une méthode approximative dérivée de la base de coût du benchmark lui-même (temps réel × tarif, incl. init du modèle) ; ce n'est pas un conseil financier et vos chiffres exacts varient selon le matériel, le mix de documents, les tailles de lots et l'utilisation. Le tarif de 0,76 $/h est un prix à la demande horodaté d'août 2026 — recalculez aux tarifs actuels.

Questions fréquemment posées

Combien coûte l'OCR pour 1 000 pages ?

Entre 0,048 $ (docTR) et 1,061 $ (Surya2) pour 1 000 pages sur SROIE 2019, mesuré sur un RTX 4090 à 0,76 $/h avec le prix daté d'août 2026 (summary_metrics.csv cost_per_1000_pages, lignes sroie_2019). Le coût inclut l'initialisation du modèle, donc le coût par page diminue à mesure que la taille du lot augmente. Sur CORD v2, les mêmes moteurs s'échelonnent de 0,086 $ (EasyOCR) à 1,162 $ (Surya2).

Quel moteur OCR open-source est le moins cher à exécuter ?

docTR était le moteur GPU le moins cher mesuré à 0,0479 $ pour 1 000 pages sur SROIE (449,3 pages/min, ligne doctr/sroie_2019 de summary_metrics.csv) — et la réserve liée au jeu de données compte : sur CORD v2, EasyOCR (0,0863 $) a devancé docTR (0,0939 $). La réponse à « le moins cher » dépend de votre ensemble de documents ; les points d'ancrage (docTR proche du minimum, Surya2 élevé) se sont maintenus sur les deux.

Pourquoi le moteur le plus rapide est-il aussi le moins cher ?

Parce que la facture repose sur les heures d'exécution à 0,76 $/h : le moteur qui traite une page en 109 ms (docTR) paie environ 1/25 des heures qu'un moteur à 2 668 ms (Surya2) paie par page (summary_metrics.csv latency_p50_ms / cost_per_1000_pages, lignes sroie_2019). Avec une facturation GPU au compteur, le débit est le coût — c'est pourquoi le classement des coûts et celui du débit sont presque en miroir.

L'OCR Tesseract est-il gratuit ?

Non — Tesseract est uniquement CPU, donc il ne consomme aucune heure GPU facturée et sa cellule de coût est vide dans le CSV de référence par conception, mais ce n'est pas un zéro : l'infrastructure CPU sur laquelle il s'exécute est un coût réel, et son plafond de récupération de champs (F1 du champ LLM CORD 0,163, ligne tesseract/cord_v2 de field_method_comparison.csv) peut faire grimper les dépenses dans le post-traitement en aval. À faible volume sur du matériel CPU déjà provisionné, il peut être réellement rentable — 78,6 pages/min sur SROIE, plus rapide que quatre des sept moteurs GPU — mais « pas de facture GPU » et « gratuit » sont des affirmations différentes.

Pourquoi Surya2 est-il si coûteux pour 1 000 pages ?

Parce que c’est le moteur le plus lent du benchmark : 12,1 pages/min sur SROIE signifie le plus grand nombre d’heures de temps réel par 1 000 pages au même tarif de 0,76 $/h (summary_metrics.csv pages_per_minute / cost_per_1000_pages, ligne surya2/sroie_2019). Notamment, il offre aussi la meilleure précision des caractères (CER 0,1915) — l’exemple le plus clair du benchmark que le coût suit le temps, pas la précision.

Le coût OCR par page diminue-t-il à mesure que le volume augmente ?

Oui, jusqu’à un plancher. Le coût inclut ici l’initialisation du modèle, payée une fois par processus/lot ; l’exécution docTR du benchmark a payé l’initialisation dans 81 867 ms pour 361 pages (manifest performance.run_wall_time_ms), donc à 1 million de pages, cette initialisation est diluée à près de zéro et le coût se rapproche du débit pur en régime permanent. Le plancher est le coût en régime permanent lui-même — le $0,0479/1K de docTR sur SROIE est déjà proche de son plancher ; le $1,0609 de Surya2 reflète une inférence en régime permanent réellement lente, pas seulement un surcoût d’initialisation.

Qu’est-ce qui n’est pas inclus dans ces chiffres par 1 000 pages ?

Le post-traitement LLM (un coût API séparé par jeton ; comptes de jetons dans field_method_comparison.csv), le CPU/l’infrastructure pour les piles de type Tesseract, le stockage et la sortie, l’orchestration, les écarts d’utilisation du GPU, et les services OCR cloud/API — aucun de ces éléments n’est dans la facture GPU du moteur que ces chiffres représentent. Les API cloud facturent aussi par appel avec des tarifs dépendant des fonctionnalités, un modèle de coût différent du temps réel sur GPU loué ; elles ne sont pas évaluées sur cette page.

D’où viennent ces chiffres ?

Chaque chiffre est une ligne des CSV publiés du benchmark propriétaire — results/summary_metrics.csv (coût par 1 000 pages, débit, latence, précision) et results/field_method_comparison.csv (jetons du post-processeur LLM et F1 des champs) — hébergés sur ImageToTableai/benchmark-ocr, avec un manifest.json expurgé par exécution enregistrant le tarif de 0,76 $/h, l’horodatage des prix d’août 2026, les versions des modèles et les hachages d’environnement.

Méthodologie & sources

Protocole

Cette page présente la dimension coût d'un benchmark indépendant et reproductible (tier officiel) — et non une synthèse de revendications tierces. Uniquement des splits de test fixes : test SROIE 2019 (361 reçus anglais, champs plats société/date/adresse/total) et test CORD v2 (100 reçus indonésiens, champs imbriqués menu/sous-total/total) ; les splits d'entraînement n'ont jamais été évalués. Chaque paire (moteur × jeu de données) a utilisé les mêmes images, la même vérité terrain et le même protocole de mesure (warm_then_scored : un passage de préchauffage fixe précède le passage noté). Les 16 exécutions se sont toutes terminées avec error_rate 0.0 (colonne error_rate de summary_metrics.csv).

Environnement d'exécution et base de coût

• Matériel : toutes les exécutions GPU sur un NVIDIA RTX 4090 (24 Go) ; coût GPU calculé au tarif à la demande RunPod de 0,76 $/h, avec l'horodatage du prix (price_recorded_at_utc 2026-08-13T08:00:00Z) enregistré dans le manifeste expurgé de chaque exécution. Tesseract a fonctionné CPU uniquement et n'a aucun coût GPU (cellule de coût vide dans le CSV — par conception, pas un zéro).
• Formule de coût : coût pour 1 000 pages = temps d'exécution × 0,76 $/h × (1 000 / pages traitées), y compris l'initialisation du modèle. Vérifié par l'exemple docTR détaillé dans la section Comment estimer (81 867 ms → 0,0479 $/1K).
• Moteurs : tous les modèles exécutés tels quels, sans fine-tuning. Versions verrouillées selon les manifestes d'exécution (Tesseract 5.3.4, PaddleOCR 3.7.0, EasyOCR 1.7.2, docTR v1.0.1, Docling 2.119.0, Surya2 0.22.1, Unlimited-OCR servi par vLLM, PaddleOCR-VL 1.6).
• Postprocesseur LLM : deepseek-v4-flash via API à température 0 (colonne llm_model dans field_method_comparison.csv) ; ses comptages de jetons sont rapportés comme base du coût de pipeline séparé — les chiffres de coût du moteur OCR ne l'incluent jamais.
• Post-traitement des champs : les métriques de champs SROIE sont postprocessed_sroie_receipt_regex_* / variantes LLM — champs extraits du texte OCR, pas d'une sortie structurée native.
• Réserve CORD : le texte de vérité terrain CORD intègre la structure d'annotation, ce qui gonfle le CER brut de chaque moteur ; les lignes CORD sont donc conservées séparées des classements SROIE. Les chiffres de coût (basés sur le temps d'exécution) ne sont pas affectés par la réserve CER, mais les deux jeux de données restent des reçus uniquement.

Définitions des métriques

• Coût pour 1 000 pages : heures GPU facturées pour 1 000 pages au tarif enregistré de 0,76 $/h, temps réel incluant l'initialisation du modèle. Vide pour Tesseract en CPU uniquement.
• Pages par minute : débit en temps réel incluant l'initialisation du modèle.
• Latence p50/p95 : temps d'inférence par page en régime permanent (échauffement puis évaluation, hors chargement du modèle).
• CER/WER : distance d'édition (insertions + suppressions + substitutions) sur les caractères/mots de référence. Sensible à la casse et aux conventions de formatage — les sorties VLM sont normalisées en minuscules, donc le CER surestime l'erreur VLM (voir la page de synthèse).
• F1 sur les valeurs de champs : moyenne harmonique précision/rappel sur les valeurs de champs extraites, par postprocesseur (regex ou LLM).

Liste des sources

1. summary_metrics.csv (GitHub raw). 16 lignes = 8 moteurs × 2 jeux de données de reçus (sroie_2019, cord_v2). 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 chiffre de coût, de débit, de latence et de CER sur cette page provient d'une ligne 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 champs regex/LLM, document-fields-exact, llm_median_latency_ms, llm_prompt_tokens, llm_completion_tokens. Chaque nombre de jetons et chaque chiffre de F1 sur les champs LLM provient d'une ligne ici.
3. Dépôt ImageToTableai/benchmark-ocr. Dépôt public hébergeant les CSV de résultats, les manifestes de runs expurgés, le protocole figé et les listes d'échantillons des jeux de données (splits de test fixes) pour la reproduction.
4. results/manifests/ (GitHub). Un manifeste.json expurgé par run publié (16 runs) avec l'empreinte d'environnement, les versions de modèles, les métadonnées de coût (gpu_hourly_usd, price_recorded_at_utc), le temps réel et les 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

• Un seul niveau de GPU et un seul instantané de prix : toutes les données GPU proviennent d'un RTX 4090 à 0,76 $/h, prix relevé en août 2026. Les prix spot/à la demande des GPU changent — recalculez aux tarifs actuels ; d'autres GPU, le service multi-GPU et la planification par lots modifient le débit et le coût.
• Reçus uniquement : reçus SROIE (anglais) et CORD (indonésien). Le coût, le débit et la précision sur les factures, formulaires, contrats ou documents longs ne sont pas mesurés ; les classements ci-dessus ne sont pas généralisables au-delà des reçus.
• Le coût inclut l'initialisation du modèle — dépend de la taille du lot : les chiffres reflètent le schéma d'exécution du benchmark (répartitions fixes 361/100 pages, évaluation à chaud puis notation). Les lots plus petits paient l'initialisation à chaque fois et coûtent plus cher pour 1 000 pages ; les lots plus grands se rapprochent du plancher en régime permanent.
• Asymétrie CPU/GPU : Tesseract (CPU) est comparé aux moteurs accélérés par GPU. Son avantage de coût reflète l'absence de facturation GPU, pas un coût nul — l'infrastructure CPU, l'électricité et le temps du personnel ne sont pas quantifiés, et son plafond de récupération de champs (F1 champ LLM CORD 0,163) peut déplacer les dépenses vers le post-traitement.
• Pas de modèles cloud/API : AWS Textract, Google Document AI, Azure AI Document Intelligence et les API OCR/VLM hébergées ne sont pas inclus ; leur tarification par appel et par fonctionnalité diffère fondamentalement de la facturation au temps d'exécution des GPU loués, et aucune comparaison n'est implicite.
• Utilisation et temps d'inactivité non modélisés : les chiffres supposent que le GPU est facturé pour le temps d'exécution du benchmark et qu'il est sinon inutilisé ; les déploiements réels avec des GPU inactifs, multi-locataires ou sous-utilisés ont des coûts effectifs différents.
• Le coût du post-traitement LLM n'est pas converti en dollars : les comptages de jetons (field_method_comparison.csv) servent de base ; la tarification LLM varie selon le fournisseur et le plan et est volontairement laissée au lecteur.
• Les scénarios dérivés ne sont pas mesurés : le tableau des volumes mensuels est une simple arithmétique sur la base de coût SROIE, étiqueté comme estimations dérivées — pas des exécutions de benchmark supplémentaires.
• Taille de l'échantillon et épinglage des versions : 361 + 100 échantillons ; les résultats valent pour les versions de modèles d'août 2026 listées ci-dessus. Les versions plus récentes des moteurs peuvent modifier le coût/le débit ; les différences de quelques points de pourcentage doivent être traitées comme du bruit.

Références associées : OCR traditionnel vs VLM de parsing de documents · docTR vs Surya2 : égalité CER, écart de coût · Tesseract vs PaddleOCR : profil de coût CPU · comment les regex et les LLM extraient les champs · Répartition des coûts de traitement de documents

Lectures complémentaires : Tarification de l'extraction de documents IA (2026) · précision au niveau des champs en OCR IA vs OCR traditionnel · comment l'extraction par vision IA lit les images différemment de l'OCR