« Pourquoi l'OCR est-il si lent ? »
3 causes racines du traitement par lots lent — et comment corriger chacune

Cause n°1 : absence d'accélération GPU sur un pipeline à forte charge de calcul

Symptôme. Votre CPU atteint 100 % pendant le traitement et chaque page prend bien plus d'une seconde sur des documents propres. Le débit ne s'améliore pas lorsque vous ajoutez plus de fichiers à un lot — le pipeline est saturé.

Cause racine. Tous les moteurs OCR ne se valent pas sous le capot. Tesseract, la référence open source maintenue par Google, est un moteur purement CPU. Il utilise des pipelines de vision par ordinateur traditionnels — analyse des composantes connexes, analyse de la mise en page et reconnaissance de caractères basée sur LSTM — dont aucun ne tire parti du parallélisme GPU. Le benchmark d'un chercheur a chronométré Tesseract 5 à environ 0,8 seconde par page sur un CPU moderne avec du texte imprimé propre. Acceptable pour quelques pages. Pénible à 500.

EasyOCR adopte une approche architecturale différente. Son backbone d'apprentissage profond (détection de texte CRAFT + un réseau de reconnaissance PyTorch) peut fonctionner sur GPU — et lorsqu'il le fait, il est considérablement plus rapide. Mais voici le piège que la plupart des gens manquent : EasyOCR retombe automatiquement sur le CPU si aucun GPU compatible n'est détecté. Sur CPU, le même pipeline d'apprentissage profond qui rend EasyOCR précis le rend également trois à quatre fois plus lent que son mode GPU. Les benchmarks sur une NVIDIA T4 montrent EasyOCR GPU atteignant ~0,6 seconde par page — comparable à Tesseract — tandis qu'EasyOCR CPU s'étire jusqu'à ~2,5 secondes par page.

La solution. Vérifiez si votre pipeline OCR utilise réellement un GPU :

• Pour EasyOCR, vérifiez que reader = easyocr.Reader(['en'], gpu=True) détecte réellement CUDA. Si la bibliothèque retombe silencieusement, votre temps par page fera plus que doubler. Exécutez nvidia-smi pendant le traitement — si l'utilisation du GPU affiche 0 %, votre pipeline fonctionne sur CPU.
• Pour Tesseract, il n'y a pas de bascule GPU — il ne prend tout simplement pas en charge l'accélération GPU. Si vous traitez plus de quelques centaines de pages, envisagez de passer à un moteur compatible GPU.
• Les moteurs OCR dédiés comme PaddleOCR sont conçus pour le GPU dès le départ. Des benchmarks de vitesse indépendants placent PaddleOCR sur une RTX 3090 à environ 190 pages par minute — plus de 3 pages par seconde — grâce à une inférence par lots optimisée et à l'intégration CUDA.

Si votre matériel est fixe (ordinateur portable sans GPU discret, serveur partagé, VM cloud sans GPU), le chemin GPU ne vous est pas directement accessible. Dans ce cas, un service OCR cloud qui traite les documents sur une infrastructure adossée à des GPU — sans que vous ayez à provisionner le matériel — contourne entièrement le problème.

Pour une comparaison côte à côte des moteurs OCR compatibles GPU, voir notre tour d'horizon des meilleurs outils OCR open source.

Cause n°2 : des images bien plus grandes que ce dont l’OCR a réellement besoin

Symptôme. Le traitement ralentit considérablement sur des pages qui vous semblent parfaitement lisibles. Une photo de reçu de 12 mégapixels prise avec un téléphone met 5 à 8 secondes à être traitée, alors qu’un PDF scanné du même document prend moins de 2 secondes.

Cause profonde. La plupart des moteurs d’OCR traitent chaque pixel de l’image. Si vous doublez la résolution sur chaque axe — de 150 DPI à 300 DPI — vous quadruplez le nombre de pixels : 2x la largeur multipliée par 2x la hauteur. Un quadruplement de la saisie signifie environ 4x le temps de traitement pour le même contenu. Une photo de smartphone à 4000×3000 pixels contient 12 millions de pixels. Le même document scanné à 300 DPI (environ 2550×3300 pour du format lettre) en contient 8,4 millions. Un document scanné à 200 DPI — parfaitement suffisant pour la plupart des OCR — ne contient que 3,7 millions de pixels.

Le guide des performances du moteur ABBYY FineReader, l’un des documents les plus faisant autorité sur le réglage des performances de l’OCR, spécifie une plage d’entrée recommandée de 200 à 400 DPI. En dessous de 150 DPI, la reconnaissance des caractères se dégrade. Au-dessus de 400 DPI, vous payez en temps de calcul sans gain mesurable de précision. Le même principe s’applique à tout moteur d’OCR, open source ou propriétaire.

La solution. Ajoutez une étape de prétraitement qui redimensionne les images avant de les soumettre au moteur d’OCR. L’objectif est d’obtenir 150 à 300 DPI sur l’image de sortie — environ 1200 à 2500 pixels sur le côté le plus long pour un document type.

Un pipeline Python de prétraitement simple avec Pillow :

from PIL import Image

def resize_for_ocr(image_path, max_dim=2000):
    img = Image.open(image_path)
    # Only shrink, never upscale
    if max(img.size) > max_dim:
        ratio = max_dim / max(img.size)
        new_size = (int(img.size[0] * ratio),
                    int(img.size[1] * ratio))
        img = img.resize(new_size, Image.LANCZOS)
    return img

Cette seule étape peut réduire le temps de traitement par page de 40 à 70 % selon vos images sources, sans aucun impact sur la précision de l’extraction. Pour un guide complet sur la préparation des images — notamment la binarisation, la redressement et la normalisation du contraste — lisez notre guide de prétraitement d’images OCR.

Cause n°3 : Traitement séquentiel alors que vous pourriez exécuter en parallèle

Symptôme. L'utilisation du CPU oscille autour de 30 à 40 % pendant un traitement par lots. Le pipeline traite les fichiers un par un — vous regardez la barre de progression avancer, fichier par fichier, sans jamais accélérer.

Cause racine. La plupart des pipelines OCR sont écrits sous forme de boucles simples : for file in files: ocr. C'est monothread par défaut. Les CPU modernes ont 4, 8 ou 16 cœurs, mais une boucle séquentielle n'en utilise qu'un seul. Les autres cœurs restent inactifs pendant que les pages font la queue.

La solution est remarquablement parallélisable — l'OCR d'une page est indépendant de l'OCR de toute autre page. Il n'y a aucun état partagé à synchroniser. Cela signifie que vous pouvez traiter N pages simultanément sur une machine à N cœurs et, en théorie, atteindre un débit N×. En pratique, la montée en charge est presque linéaire jusqu'à 4 à 8 cœurs, avec des rendements décroissants au-delà en raison de la bande passante mémoire et de la contention d'E/S.

La solution. Enveloppez votre appel OCR dans un framework d'exécution parallèle :

• GNU Parallel (Linux/macOS) : L'approche la plus simple pour les pipelines basés sur des scripts. parallel -j 4 ocrmypdf {} output/{} ::: *.pdf exécute quatre processus OCR simultanément.
• multiprocessing Python : Utilisez multiprocessing.Pool pour distribuer les fichiers entre les processus workers. Chaque worker obtient sa propre instance du moteur OCR, et les résultats sont collectés au fur et à mesure de leur achèvement.
• Outils de traitement par lots : Les outils OCR par lots dédiés comme OCRmyPDF prennent en charge le traitement parallèle intégré. Son paramètre --jobs contrôle la concurrence. Le combiner avec GNU Parallel (en limitant le parallélisme à 2 tâches pour éviter la saturation des E/S) est un modèle de production documenté.

La considération pratique clé : chaque worker parallèle a besoin de suffisamment de mémoire pour contenir l'image de sa page et les tampons intermédiaires. Exécuter 8 workers sur une machine avec 8 Go de RAM déclenchera le swap. Un point de départ sûr est de 2 Go de RAM par worker parallèle pour les images de documents standard. Adaptez le parallélisme à votre budget mémoire avant d'atteindre le nombre de cœurs de votre CPU.

Pour une procédure complète de configuration des pipelines par lots parallèles, consultez notre guide sur le traitement par lots de plusieurs fichiers.

Quand passer à l’étape supérieure — changer d’outil plutôt que d’optimiser

Si vous avez vérifié les trois causes — votre GPU est actif, vos images sont correctement dimensionnées et votre pipeline s’exécute en parallèle — mais que le traitement reste trop lent pour votre charge de travail, le goulot d’étranglement est peut-être architectural plutôt que configurationnel.

Trois signaux indiquent qu’il est temps d’envisager une approche fondamentalement différente :

1. Votre volume est constamment élevé. Si vous traitez plus de 500 pages par jour et que le temps de traitement par lot est un problème récurrent, l’optimisation d’un pipeline OCR local sera toujours en retard par rapport à ce qu’un service cloud spécialisé peut offrir. Les services d’extraction cloud fonctionnent sur des clusters GPU de niveau serveur avec équilibrage de charge automatique — un seul lot peut être réparti sur des dizaines de travailleurs parallèles sans que vous ayez à provisionner du matériel.

2. Vos documents sont variés et non traités. Un pipeline optimisé pour des PDF numérisés propres aura du mal avec les photos de téléphone, les reçus froissés ou les documents manuscrits. Chaque nouveau type d’entrée nécessite des paramètres de prétraitement différents. ImageToTable.ai utilise des modèles vision-langage qui lisent les documents de manière sémantique — interprétant la mise en page comme le ferait un humain, sans nécessiter de réglage par type de document. Il n’a pas besoin d’une étape de prétraitement distincte pour la normalisation de la résolution, car le pipeline cloud gère la mise à l’échelle automatiquement avant l’inférence.

3. Vous avez besoin de résultats en quelques minutes, pas en quelques heures. Si un lot de 300 pages doit être traité et exporté pendant une pause déjeuner, un pipeline local séquentiel — même optimisé pour la vitesse — ne suffira pas. Le traitement par lots cloud parallélise l’ensemble du volume de documents. Un lot de 300 pages qui prend 3 à 4 heures sur une machine équipée d’un seul CPU peut être terminé en 5 à 10 minutes sur une infrastructure cloud qui exécute le même travail sur 20 à 40 travailleurs GPU parallèles.

Questions fréquentes

Tesseract est-il plus rapide qu'EasyOCR ?

Sur CPU, Tesseract est généralement plus rapide — environ 0,8 seconde par page contre 2,5 secondes pour EasyOCR sur du texte imprimé propre. Sur GPU, la comparaison s'inverse : EasyOCR sur un GPU NVIDIA tourne à environ 0,6 seconde par page, égalant ou dépassant le débit de Tesseract tout en offrant une précision nettement meilleure sur les images dégradées, les annotations manuscrites et les mises en page mixtes. En pratique : si vous avez un GPU, utilisez EasyOCR (ou PaddleOCR). Si vous êtes uniquement sur CPU, Tesseract offre un meilleur débit pour les documents propres, mais attendez-vous à une précision moindre sur les entrées complexes.

Quelle résolution d'image est optimale pour la vitesse d'OCR ?

200–300 DPI est le point idéal pour la plupart des moteurs d'OCR. En dessous de 150 DPI, la précision de reconnaissance des caractères chute sensiblement, surtout pour les petites polices. Au-dessus de 400 DPI, vous payez 2 à 4 fois plus de temps de traitement pour un gain de précision négligeable ou nul. Pour un document standard au format lettre (8,5"×11"), 200 DPI produit une image d'environ 1700×2200 pixels — soit environ 3,7 mégapixels. C'est bien plus petit qu'une photo de smartphone typique et le traitement sera bien plus rapide.

Puis-je utiliser plusieurs GPU pour accélérer l'OCR ?

Oui, si votre moteur d'OCR le prend en charge et que votre charge de travail est suffisamment importante pour en bénéficier. PaddleOCR et EasyOCR peuvent être répartis sur plusieurs GPU en assignant différents lots de documents à différentes instances GPU. En pratique, un seul GPU moderne (RTX 3090 ou supérieur) traite déjà 150 à 190 pages par minute pour des documents standard, donc les configurations multi-GPU ne sont nécessaires qu'à très haut volume (10 000+ pages par jour). Le principal goulot d'étranglement à cette échelle passe du calcul à l'E/S — lecture des fichiers, écriture des résultats — donc une configuration multi-GPU doit être associée à un stockage rapide (SSD NVMe) et à une mémoire RAM suffisante.

Quelle est la différence de vitesse entre GPU et CPU pour l'OCR ?

Pour un moteur d'OCR basé sur l'apprentissage profond comme EasyOCR ou PaddleOCR, l'accélération GPU offre généralement un gain de 3 à 7× par rapport au traitement CPU seul, selon le modèle de GPU et les caractéristiques de l'image. Sur un NVIDIA T4 (un GPU cloud courant), EasyOCR est environ 4× plus rapide que son alternative CPU. Sur des GPU grand public comme le RTX 3090, PaddleOCR atteint plus de 190 pages par minute — soit une amélioration de 5 à 7× par rapport à un CPU 4 cœurs exécutant le même pipeline. Tesseract ne prend pas en charge l'accélération GPU, sa vitesse dépend donc uniquement des performances du CPU et n'est pas directement comparable.

Réduire la taille de l'image réduit-il la précision de l'OCR ?

Réduire la taille de l'image ne diminue la précision que si l'on descend en dessous de la résolution minimale nécessaire au moteur d'OCR pour lire les petits caractères. Pour la plupart des documents imprimés, 200 DPI suffisent pour une précision des caractères supérieure à 99 %. En dessous de 150 DPI, vous risquez de perdre des détails fins : notes de bas de page en police 8pt, points décimaux et caractères en indice. L'approche sûre consiste à redimensionner à une résolution cible de 200 à 300 DPI — cela préserve la lisibilité tout en éliminant les 4 à 5 mégapixels de données redondantes qui ne font que ralentir le traitement. Si vos documents contiennent du texte très petit (par exemple, des mentions légales en 6–8pt), visez 300 DPI comme minimum.

Quand arrêter le réglage et passer à un autre outil ?

Lorsque le temps de traitement par lots est dominé par la surcharge du pipeline — prétraitement, entrées/sorties de fichiers et sérialisation — plutôt que par le moteur d'OCR lui-même, vous avez atteint la limite pratique du réglage local. Signes qu'il est temps de changer : vous avez déjà implémenté l'accélération GPU, la normalisation de la résolution et le traitement parallèle, mais un lot de 300 pages prend encore plus d'une heure ; ou vos documents sont si divers (photos de téléphone, scans, captures d'écran, écriture manuscrite mélangée) que les paramètres de prétraitement doivent être ajustés par page. Dans ces scénarios, un service d'extraction cloud qui parallélise sur des GPU et lit les documents de manière sémantique — sans réglage par type — surpassera un pipeline localement réglé en termes de vitesse et de précision.