rpa_vision_v3/docs/VEILLE_OCR_SPACE_ENGINE3_2026-07-02.md

Veille — OCR.space Engine 3 vs notre brique OCR locale (2026-07-02)

Origine : lien trouvé par Dom (https://ocr.space/ocrapi#ocrengine3), analysé par agent de recherche web (Claude) le 2026-07-02. Verdict court : sans suite pour la prod (cloud / on-prem Windows propriétaire, bbox Engine 3 moins précises), mais 3 idées à retenir, dont un bench PP-OCRv5 à faire.

1. Ce qu'est OCR.space

API OCR cloud (https://api.ocr.space/parse/image), JSON, éditée par a9t9 Software — même éditeur que UI.Vision RPA (d'où la proximité ressentie avec notre besoin). Plans : Free (25 000 req/mois, 1 MB/image), PRO (300 000/mois, 5 MB), PRO PDF (100+ MB).

Les 3 moteurs

	Engine 1	Engine 2	Engine 3
Positionnement	le plus rapide, langues asiatiques	« meilleur all-round », auto-détect langue	le plus récent, « précision la plus élevée »
Langues	~25 dont français	latines + chinois	200+, auto-détection
Spécifique	—	orientations mixtes	tables → Markdown, manuscrit, cases à cocher
Overlay bbox	précis, rapide	précis, rapide	dispo mais « not as precise as Engine 1/2 », appel 2-3× plus lent
Quotas free	25 000/mois	idem	2 500/mois (compute-intensive)
PDF searchable	oui	oui	non

Doc officielle : « Engine 3 prioritizes OCR accuracy and Markdown output over spatial precision » → moteur type « document VLM » orienté texte/structure, pas grounding spatial. L'inverse de notre besoin RPA (bbox mot fiables pour cliquer).

Format de sortie

isOverlayRequired=true → TextOverlay.Lines[].Words[] avec WordText/Left/Top/Width/Height. = équivalent de ce que docTR nous donne déjà (hiérarchie mots+bbox), gratuit, Apache 2.0. Paramètres notables : detectOrientation (auto-rotation), scale (upscale interne images basse résolution — cas d'école screenshots 96 DPI), isTable, OCREngine=1|2|3 (même JSON quel que soit le moteur).

2. On-premise ?

« OCR.space Local » existe (section #local) : 100 % offline, mêmes API. MAIS :

• Windows Server 2022+ (DGX = ARM Linux → VM Windows dédiée rien que pour l'OCR)
• Prix opaque (contact sales ; avis tiers : ~999 $/mois entreprise, non confirmé)
• Boîte noire propriétaire installée par leur support via RDP
• Engine 3 en local non garanti (blog on-prem ne mentionne que l'Engine 2)

Sources : https://ocr.space/ocrapi (#local), https://forum.ocr.space/t/how-about-pricing-and-order-ocr-space/28246, https://www.koncile.ai/en/ressources/ocr-space-test-review

3. Verdict (contrainte 100 % local)

Rien pour la prod. Cloud exclu (données patient) ; version locale = Windows Server propriétaire à prix opaque ; le moteur intéressant (Engine 3) a des bbox explicitement moins précises et plus lentes — rédhibitoire pour du grounding de clic.

À retenir (transposable chez nous) :

1. Upscale ×2 des crops basse résolution avant OCR (leur param scale) — gain connu, quasi gratuit, mesurable immédiatement.
2. Schéma overlay unifié multi-moteurs (Lines→Words {text, bbox, confidence}) en sortie de toute la cascade → moteurs interchangeables sans toucher l'aval. La seule vraie bonne idée d'architecture à copier.
3. Leçon Engine 3 : les moteurs « haute précision texte » sacrifient la précision spatiale → valide notre split OCR (valeurs+bbox) / VLM (rôles). Ne pas chercher un moteur unique qui fait les deux.

4. Alternatives locales — état de l'art screenshots/UI (sources < 12 mois)

• PaddleOCR 3.x / PP-OCRv5 — piste n°1. Apache 2.0, 106 langues dont français, return_word_box=True = bbox au niveau mot (post-merge ponctuation/accents à prévoir). Moteur OCR retenu par OmniParser (Microsoft) pour les GUI agents = validation directe sur notre cas. Sources : paddleocr.ai (PP-OCRv5 multi-languages), arxiv 2408.00203 (OmniParser), huggingface.co/blog/baidu/ppocrv5
• Qwen3-VL (déjà déployé vLLM) — text spotting coords normalisées [0,1000] ; utilisable en validateur/fallback OCR sans nouveau composant ; moins déterministe qu'un OCR classique.
• Surya / Surya 2 — très bon mais licence OpenRAIL-M à seuil de revenus → risque licence produit commercial. À écarter ou budgéter.
• Repères 2026 : PP-OCRv5 = meilleure précision/débit généraliste ; docTR/EasyOCR corrects sur texte numérique mais dépassés en multilingue ; GOT-OCR2/dots.ocr = document, pas UI.

5. Actions proposées (non lancées — décision Dom)

1. Bench PP-OCRv5 (lang=fr, return_word_box=True) vs docTR/EasyOCR sur nos vraies captures DPI (jeu du POC tools/poc_lecture_ecran.py, 13 champs GEMSA/CCMU) : précision petites polices, bbox mot, latence GPU DGX.
2. Upscale ×2 systématique des crops avant OCR — à mesurer sur le même bench.
3. Schéma overlay unifié en sortie de cascade (docTR/EasyOCR/PP-OCRv5/Qwen3-VL).