docs: track design docs, plans, audits, coordination infrastructure, handoffs

- 21 docs/*.md: audits, design notes, deployment plans, checklists, memos
- Coordination: ROLES, runbooks (DGX reboot, Lea live), patches, registre, syntheses, systemd, QG template
- Handoffs: 6 Codex handoff documents + README + template

docs/VEILLE_OCR_SPACE_ENGINE3_2026-07-02.md

@@ -0,0 +1,83 @@
+# 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).