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

Cause n°1 : Absence d'accélération GPU sur un pipeline lourd

Symptôme. Votre CPU est saturé à 100 % pendant le traitement et chaque page prend bien plus d'une seconde sur des documents propres. Le débit n'augmente pas quand vous ajoutez des 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 classiques de vision par ordinateur — analyse des composants 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. 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 socle d'apprentissage profond (détection de texte CRAFT + un réseau de reconnaissance PyTorch) peut fonctionner sur GPU — et quand c'est le cas, il est nettement plus rapide. Mais voici le piège que la plupart des gens oublient : EasyOCR bascule automatiquement sur 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 aussi trois à quatre fois plus lent que son mode GPU. Des benchmarks sur un NVIDIA T4 montrent EasyOCR GPU atteignant ~0,6 seconde par page — comparable à Tesseract — tandis qu'EasyOCR CPU grimpe à ~2,5 secondes par page.

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

• Pour EasyOCR, assurez-vous que reader = easyocr.Reader(['en'], gpu=True) détecte bien CUDA. Si la bibliothèque bascule silencieusement, votre temps par page va plus que doubler. Lancez nvidia-smi pendant le traitement — si l'utilisation GPU est à 0 %, votre pipeline tourne sur CPU.
• Pour Tesseract, il n'y a pas d'option GPU — il ne supporte tout simplement pas l'accélération GPU. Si vous traitez plus de quelques centaines de pages, envisagez de passer à un moteur compatible GPU.
• Des 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 un RTX 3090 à environ 190 pages par minute — plus de 3 pages par seconde — grâce à l'inférence par lots optimisée et à l'intégration CUDA.

Si votre matériel est fixe (ordinateur portable sans GPU dédié, serveur partagé, VM cloud sans GPU), la voie GPU ne vous est pas directement accessible. Dans ce cas, un service OCR cloud qui traite les documents sur une infrastructure GPU — sans que vous ayez à provisionner le matériel — contourne complètement le problème.

Pour une comparaison côte à côte des moteurs OCR compatibles GPU, consultez notre sélection des meilleurs outils OCR open source.

Cause n°2 : des images bien trop grandes pour l’OCR

Symptôme. Le traitement ralentit sur des pages qui vous semblent parfaitement lisibles. Une photo de 12 mégapixels d’un ticket de caisse met 5 à 8 secondes, alors qu’un PDF scanné du même document met moins de 2 secondes.

Cause racine. La plupart des moteurs d’OCR analysent chaque pixel de l’image. Doublez la résolution sur chaque axe — de 150 à 300 DPI — et vous quadruplez le nombre de pixels : 2x la largeur multipliée par 2x la hauteur. Quadrupler l’entrée 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é en matière d’optimisation des performances OCR, recommande une plage d’entré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 du temps de calcul sans gain mesurable de précision. Le même principe s’applique à tout moteur d’OCR, qu’il soit open source ou propriétaire.

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

Un pipeline de prétraitement Python simple avec Pillow :

from PIL import Image

def resize_for_ocr(image_path, max_dim=2000):
    img = Image.open(image_path)
    # Réduire uniquement, jamais agrandir
    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 — incluant la binarisation, le redressement et la normalisation du contraste — lisez notre guide de prétraitement d’images pour l’OCR.

Cause n°3 : Traitement séquentiel quand vous pourriez paralléliser

Symptôme. L'utilisation du CPU stagne autour de 30–40 % lors d'un traitement par lots. Le pipeline traite les fichiers un par un — vous regardez la barre de progression avancer, fichier après 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(file). C'est mono-thread 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 s'empilent.

La correction est trivialement parallélisable — l'OCR d'une page est indépendant de l'OCR de toute autre page. Il n'y a pas d'état partagé à synchroniser. Cela signifie que vous pouvez traiter N pages simultanément sur une machine à N cœurs et, en théorie, obtenir un débit N×. En pratique, la mise à l'échelle 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 correction. Encapsulez 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.
• Outils de traitement par lots : Des 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. L'associer à 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 du swapping. 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 CPU.

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

Quand passer à l'étape supérieure — Changer d'outil plutôt que de régler

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 d'achèvement des lots est un problème récurrent, le réglage d'un pipeline OCR local sera toujours à la traîne par rapport à ce qu'un service cloud dédié peut offrir. Les services d'extraction cloud fonctionnent sur des clusters GPU de qualité serveur avec équilibrage de charge automatique — un seul lot peut être réparti sur des dizaines de workers parallèles sans que vous ayez à provisionner de matériel.

2. Vos documents sont divers et non traités. Un pipeline optimisé pour des PDF scannés propres aura du mal avec les photos de téléphone, les reçus froissés ou les documents contenant de l'écriture manuscrite. Chaque nouveau type d'entrée nécessite des paramètres de prétraitement différents. ImageToTable.ai utilise des modèles de langage visuel 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 minutes, pas en 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 sera pas à la hauteur. 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 workers 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.