OCR en masse de PDF scannés : la voie la plus rapide pour des dizaines de milliers de fichiers

En bref : Pour OCRiser des dizaines de milliers de PDF scannés, le goulot d'étranglement n'est presque jamais « quel moteur OCR choisir » seul. C'est de savoir si vous préfiltrez et routez les fichiers, parallélisez le travail et exécutez une file reprenable. Un outil bureau fichier par fichier peut prendre des semaines sur 10 000 documents ; le pipeline ci-dessous sur un VPS 8–16 cœurs ou des workers GPU compresse souvent le même volume en quelques heures ou un à deux jours——à condition d'accepter des compromis : dépistage rapide d'abord, OCR précis ensuite, mauvaises pages en quarantaine.

Ce guide vise les archives, dossiers juridiques, rapports médicaux, papiers historiques et scans de contrats d'entreprise——typiquement 10 000–100 000+ fichiers, surtout des scans purs ou des PDF mixtes. Mots-clés : OCR par lots, reconnaissance PDF scanné, ocrmypdf, PaddleOCR. Si les résultats alimentent un RAG, lisez nos bonnes pratiques RAG PDF Parsing pour les portes d'import——l'OCR n'est que la première étape.

Vérifié le 08/08/2026 contre la doc OCRmyPDF, Tesseract et PaddleOCR.

Pourquoi l'OCR massif de PDF scannés semble insupportablement lent

Échec classique : déposer un dossier dans un outil GUI, CPU à 15 %, ventilateur silencieux, 200 fichiers en une nuit. Les causes s'empilent :

• Traitement sériel——un processus, beaucoup de cœurs inactifs.
• Pas de prévol——30 % ont déjà une couche texte mais passent l'OCR complet.
• Parallélisme au niveau fichier seulement——un classeur de 800 pages bloque un worker, les petits fichiers paient le coût de démarrage.
• Sortie lourde——recompression d'images et polices intégrées à chaque page.
• Pas de point de reprise——crash au fichier 9 000, redémarrage à zéro.

À des dizaines de milliers de fichiers, la conception du pipeline bat le réglage moteur d'un ordre de grandeur. D'abord le chemin le plus rapide, puis l'architecture à l'échelle.

Étape 0 : routage prévol——ne pas OCRiser ce qui n'en a pas besoin

Avant tout OCR, scanner l'arborescence (multiprocessing Python ou find | parallel) :

• Compter get_text() par page via PyMuPDF / pdfinfo. Pages au-dessus de ~80 caractères lisibles → tag text_layer, copier en sortie, sauter l'OCR.
• PDF chiffrés ou corrompus → quarantine/ pour ne pas bloquer la file.
• PDF mixtes : router par page——plus gros gain de temps à grande échelle.

Un projet juridique : 42 000 PDF, 38 % avaient déjà du texte, 12 % chiffrés——seulement ~50 % nécessitaient l'OCR. Cela a divisé le temps par deux avant le choix du moteur.

Chemin le plus rapide aujourd'hui (1 000–5 000 fichiers)

Sur une machine Linux 8 cœurs ou un VPS cloud aujourd'hui :

1. Installer ocrmypdf + Tesseract (chi_sim/chi_tra pour le chinois).
2. GNU parallel ou xargs -P par fichier ; concurrence ≈ cœurs CPU − 1.
3. Flags : --skip-text, faible --optimize, --jobs 1 dans chaque ocrmypdf pour éviter la surcharge imbriquée.
4. Écrire sur SSD local temp, rsync vers object storage après lots——les montages réseau tuent le débit.

cat scan_only.txt | parallel -j 8 \
                  'ocrmypdf --skip-text --optimize 0 --language chi_sim+eng \
                   {} /data/ocr_out/{/.}.pdf'

Tesseract se déploie en minutes ; PaddleOCR gagne souvent sur le chinois complexe——deuxième passe sur les pages à faible confiance, pas un rerun complet.

Architecture 10 000+ : file, workers, reprise

• File : Redis+RQ, Celery ou cloud Batch. Tâche = un PDF ou une plage de pages.
• DB d'état : SQLite/Postgres avec file_hash, statut, retries, version moteur.
• Scale-out : plusieurs VPS moyens battent souvent une grosse machine pour l'OCR CPU-bound.
• Parallélisme page : pdftoppm → file par page → fusionner couches texte pour classeurs 200+ pages.
• Pool GPU : PaddleOCR/Surya sur workers séparés ; routage par langue/mise en page.

Pas besoin de Kubernetes dès le jour un. Beaucoup d'équipes tournent Docker Compose + Redis sur 2–4 workers VPS : un pour file/métadonnées, le reste OCR uniquement.

Matrice outils : vitesse, chinois, PDF consultable

Le plus rapide ≠ le moins cher : benchmarker 200 fichiers représentatifs sur précision × secondes/page × prix avant de s'engager.

Encore 30–50 % de vitesse : réglages pratiques

• Tester rendu 300 DPI si source en 600 DPI——souvent suffisant pour contrats.
• Débruitage/seuillage OpenCV pour scans N&B propres.
• Charger uniquement les packs de langues minimaux.
• Sauter pages blanches/tampons via variance de pixels.
• Exporter .txt/.jsonl si recherche seule ; PDF/A lourd seulement pour tier archive.
• Pointer TMPDIR vers NVMe local sur VMs cloud.

Tenir vitesse et qualité ensemble

Après le lot : échantillonner 0,5 % pour relecture humaine ou CER ; vérifier regex sur pages denses en ID ; remettre en file les pages à faible confiance. Un mauvais OCR dans l'index coûte plus qu'une seconde passe moteur. Les projets d'archive exigent des journaux d'audit——qui, quand, quelle version moteur.

Estimation rapide : 50 000 pages OCR

À ~5 s/page Tesseract milieu de gamme : ~69 h mono-thread ; ~8–12 h sur 8 cœurs ; ~4–6 h sur deux workers 8 cœurs ; GPU PaddleOCR souvent 1–3 s/page——cartes à l'échelle linéaire. Mesurez votre propre échantillon 100 pages pour pages_per_hour.

Checklist à copier

1. Inventaire récursif + manifeste dédupliqué SHA256.
2. Prévol : text_layer / scan / mixed / encrypted.
3. Enqueue (équilibrer par pages OCR).
4. OCR parallèle avec --skip-text ou routage page.
5. PDF consultable ou texte sidecar + métadonnées JSON.
6. QA échantillon + seconde passe faible confiance.
7. Archiver avec ocr_engine_version pour reruns futurs.

Pour RAG en aval, garder les types de page en métadonnées. Coût long contexte : notre guide coût Context Caching.

Une dernière ligne

Pas de balle d'argent pour des dizaines de milliers de scans——mais un chemin le plus rapide reproductible : prévol coupe la moitié de l'OCR gaspillé → file survit aux crashes → workers saturent CPU/GPU → QA bloque les mauvaises pages. Pipeline vert d'abord ; moteurs ensuite.