En bref : Les archives d'entreprise, cabinets d'avocats et institutions financières détiennent souvent des dizaines de milliers de PDF — certains born-digital avec vraie couche texte, d'autres « faux PDF » de scanners 2005 (images pleine page, pas de copier-coller). Lancer l'OCR sur 100 000 fichiers en masse gaspille de l'argent et retraite des documents déjà consultables. La bonne approche : détecter d'abord en batch quels PDF ont vraiment besoin d'OCR, puis router par type vers moteurs locaux ou cloud.
Définir « besoin d'OCR »
En ingénierie, « besoin d'OCR » ≠ « le fichier contient des images » :
| État | Traits | OCR requis ? |
|---|---|---|
| Born-digital | Polices intégrées, texte copiable, > 100 car./page | Non |
| Consultable mais OCR médiocre | Couche texte mais caractères manquants | Pages partielles |
| Scan pur | JPEG/TIFF pleine page, pas de couche texte | Oui |
| Hybride | Couverture image, corps avec texte | Généralement non |
Point clé : La détection ne vise pas à reconnaître le contenu, mais à trier à faible coût 100k fichiers en skip / partial / OCR complet — avant tout appel API payant.
Pipeline de détection en 3 couches
L1 : Sonde rapide de couche texte (< 50 ms/fichier)
PyMuPDF ou pdftotext compte les caractères imprimables. avg_chars >= 80 → SKIP ; avg_chars < 20 → OCR_REQUIRED ; zone grise → L2.
L2 : Ratio surface d'images par page
Pour la zone grise L1 : surface images / surface page. Ratio > 85 % + peu de caractères L1 → OCR_REQUIRED ; ratio < 30 % → SKIP ; reste → L3.
L3 : Échantillon de rendu + OCR léger
Fichiers incertains : rendre uniquement pages 1, milieu, fin (3 pages). Vision macOS ou Tesseract. L3 ne traite que ~5–8 % de la zone grise.
Architecture parallèle pour 100 000 fichiers
Manifeste + file de messages : S3/MinIO → manifest.jsonl → Redis/RabbitMQ → N × Workers → SQLite/Parquet.
Débit (Cloud Mac mini M4, 24 Go) :
| Étape | Vitesse | Durée 100k |
|---|---|---|
| L1 seul | 12–18 fichiers/sec | ~1,5–2,5 h |
| L1 + L2 | 8–12 fichiers/sec | ~2,5–3,5 h |
| L1 + L2 + L3 | 6–9 fichiers/sec | ~3–5 h |
Routage en 3 niveaux
| Verdict | Part typique | Action aval |
|---|---|---|
SKIP |
55–70 % | Indexer directement |
PARTIAL |
10–20 % | OCR des pages min_chars < 20 |
OCR_REQUIRED |
15–30 % | OCR complet → Vision local ou API cloud |
Déduplication SHA-256 obligatoire. Cache 90 jours économise 20–40 % de calcul.
Choix d'outils
PDF purs : PyMuPDF + pdftotext en validation croisée. Documents mixtes : Apache Tika (overhead JVM à l'échelle).
Pièges courants
- PDF chiffrés →
qpdf --decryptsur copie - Garble CID → ratio Unicode imprimable en L3
- PDF double couche →
pdffontspour OCR existant - Fichiers corrompus → bucket
CORRUPT - I/O aléatoire NAS →
rsyncvers NVMe locale d'abord
Pourquoi Cloud Mac
- tmux 24/7, fermer un portable interrompt la file
- Mémoire unifiée Apple Silicon : PyMuPDF 20–40 % plus rapide que VPS x86 comparable
- Détecter → OCR sur le même nœud, pas de transfert de 100k fichiers
- Conformité : détection et OCR local sur le nœud loué ; API cloud pour pages complexes uniquement
Checklist en 7 étapes
- Exporter manifest.jsonl depuis l'object store
- Installer poppler, qpdf, PyMuPDF sur Cloud Mac
- Détection L1 complète → Parquet
- Vérifier manuellement 200 fichiers PARTIAL, calibrer seuils
- OCR_REQUIRED → file ocrmypdf ; PARTIAL → OCR par page
- Sidecars JSON pour indexation RAG / ES
- Détection incrémentale quotidienne, pas de rescan complet
Conclusion : Au moins la moitié du coût OCR sur 100k PDF va à des fichiers qui n'avaient jamais besoin d'OCR. Triez d'abord avec la pipeline en 3 couches, puis choisissez Vision local ou Document AI cloud — c'est la bonne pratique de numérisation documentaire en 2026.
ZavCloud Developer Infrastructure
Lancer détection 100k PDF et files OCR sur Cloud Mac
Nœud M4 dédié, batch tmux 24/7, détection et OCR sur une machine
Location journalière pour valider le pipeline, puis hebdo/mensuel