OCR sur un PDF de 7 000 pages :
Pourquoi un seul fichier géant est la mauvaise unité de travail

Ce qu'est réellement un fichier de 7 000 pages

Traitez un fichier de plusieurs milliers de pages comme une archive de sauvegarde et toute l'approche change. Un document a une structure que le lecteur suit : chapitres, sections, table des matières. Une archive est un conteneur, et la seule question utile que vous pouvez lui poser est de savoir où se trouve une page ou un champ particulier. Le fil r/DataHoarder qui s'ouvre sur « 1000+ pages pdf files with text and tabular data, but some idiot exported it as image » décrit exactement ce type d'objet.

Avant toute OCR, effectuez un test de deux minutes. Ouvrez le PDF et essayez de sélectionner du texte avec votre curseur. Si le texte se surligne, le fichier contient déjà une couche de texte, et vous pouvez souvent extraire les champs dont vous avez besoin directement de ce texte avec une précision quasi parfaite. Si le curseur dessine un cadre vide et que rien ne se surligne, les pages sont des images et l'OCR est réellement nécessaire. Ce test sépare deux tâches très différentes, et c'est l'étape que la plupart des guides omettent. Exécuter une OCR sur un fichier qui possède déjà une couche de texte est la façon la plus courante de passer une journée de calcul pour un travail inutile. Pour savoir ce qui se passe lorsque les pages sont réellement des images, voir comment l'IA extrait des données de PDF numérisés.

Pourquoi un fichier géant échoue à chaque étape

La défaillance d'un PDF géant est structurelle. Une meilleure application ne change pas l'arborescence de pages ni la mémoire nécessaire à une seule page.

À l'intérieur du fichier, les pages ne sont pas stockées dans l'ordre de lecture. Elles sont rattachées à une arborescence de pages, une structure ramifiée que le lecteur parcourt pour assembler le document, et la table des matières lisible que vous naviguez est l'arborescence des signets, que la spécification PDF appelle signets (ISO 32000-1:2008, sections 7.7.3 et 12.3.3). Un fichier de 7 000 pages possède une très grande arborescence, et toute opération qui touche l'ensemble du document doit la parcourir.

Deux fonctionnalités ajoutées dans PDF 1.5 aggravent l'expérience en pratique. Les petits objets tels que les dictionnaires de pages, les annotations et les signets peuvent être regroupés dans des flux d'objets compressés, et la table de références croisées du document peut être remplacée par un flux de références croisées. Les deux sont des parties légitimes de la norme (ISO 32000-1, sections 7.5.7 et 7.5.8), et les deux signifient qu'un lecteur ne peut pas accéder à l'objet numéro 5 000 par décalage d'octet. Il doit décompresser des blocs entiers pour trouver quoi que ce soit. C'est pourquoi un fichier de 600 Mo s'ouvre lentement, effectue des recherches lentement et se bloque lorsqu'un outil tente de naviguer à l'intérieur.

Vient ensuite la rastérisation, l'étape où un outil rend une page en image pour pouvoir la lire. Le coût mémoire par page est facile à sous-estimer. Une page A4 rendue à 300 DPI occupe environ 2 480 sur 3 508 pixels, soit environ 26 Mo de couleur brute. À 600 DPI, cela grimpe à environ 104 Mo pour une seule page. Une application de bureau qui maintient plusieurs pages en cours, ou qui tente de construire un modèle unique de l'ensemble du document, manque de mémoire plutôt que de logique.

Une page à 600 DPI peut occuper environ 104 Mo de mémoire avant toute reconnaissance. Ce chiffre détermine si un fichier géant est une tâche de bureau ou une tâche de pipeline.

Le forum d'assistance d'Acrobat est l'endroit public le plus clair pour voir où cela mène. Un utilisateur rapporte que « sur environ 1 500 pages, cela plante ». Un autre dit « chaque année, je dois faire de l'OCR sur quelques PDF de plus de 10 000 pages », et qu'Acrobat « plante à la fois quand j'essaie de faire l'OCR du fichier et si j'essaie de le découper ». Un troisième pose une question sur un document de 24 595 pages. Un expert de la communauté résume : « Acrobat est un outil pour de faibles volumes en OCR » (fil de discussion de la communauté Adobe). L'application fonctionne comme prévu, et elle n'a jamais été conçue pour un travail sur un fichier unique de 600 Mo. La même limite apparaît dans la comparaison de l'OCR d'Acrobat avec un modèle de vision sur des documents dépassant cette taille.

Les calculs de débit pour 7 000 pages

À 7 000 pages, la question utile est de savoir combien d'heures et combien de dollars le travail prendra.

Tesseract est la référence de base sur CPU. Sur du texte imprimé propre, il traite environ 25 pages par minute sur un CPU moderne, et des benchmarks indépendants le placent à ce niveau par rapport à des moteurs plus lourds comme PaddleOCR (environ 120 pages par minute sur une RTX 3090) et EasyOCR (environ 8 pages par minute sur CPU). Si vous envoyez 7 000 pages à Tesseract en mono-thread, vous obtenez environ 280 minutes, un peu moins de cinq heures. Sur le chemin CPU d'EasyOCR, le même travail s'étire au-delà de 14 heures.

Le levier qui change ces chiffres est le parallélisme. OCRmyPDF enveloppe le moteur Tesseract dans un outil en ligne de commande qui prend un nombre de tâches, de sorte que huit cœurs peuvent transformer une exécution de cinq heures en quelque chose de plus proche de quarante minutes. La mise en garde de la section précédente s'applique toujours : plus de travailleurs signifie aussi plus de mémoire résidente par page, donc une machine avec une RAM modeste terminera un petit nombre de pages plus rapidement qu'un grand nombre en parallèle.

L'OCR cloud échange le contrôle contre le parallélisme et facture par page. Google Document AI et AWS Textract se situent tous deux autour de la barre d'un dollar pour mille pages, ce qui place un document de 7 000 pages sous 10 $ avant les nouvelles tentatives. Les services de meilleure qualité ou plus structurés coûtent plus cher, avec le tarif publié de Reducto à 10 $ pour 1 000 pages. Le budget est rarement la contrainte ici. La contrainte est que vous avez rarement besoin de faire l'OCR des 7 000 pages, et que les outils autour d'un fichier géant unique sont ce qui rend le travail pénible.

Le protocole pratique consiste à échantillonner avant de s'engager. Prélevez cinq à dix pages qui couvrent la gamme des archives (une page propre, une page délavée, un tableau dense, une page avec une mise en page de formulaire différente), passez-les dans le chemin candidat, et mesurez le nombre réel de pages par minute et le taux d'erreur réel. Extrapoler à partir de votre propre échantillon mesuré vaut mieux que de se fier à n'importe quel tableau de benchmarks, y compris les chiffres ci-dessus.

Découper par structure, pas à la main

La réponse à un grand PDF consiste à le découper en unités adaptées aux outils dont vous disposez déjà, le long de limites que le document déclare lui-même.

La meilleure limite est l'arborescence des signets. Lorsqu'un PDF possède des signets, ils constituent sa propre table des matières, et chaque signet de premier niveau marque une unité naturelle : un chapitre, une période de relevé, un dossier. Découper le long de ces limites conserve les pages connexes ensemble, ce qui importe pour la précision de l'extraction en aval, et donne à chaque fichier résultant un nom que vous pourrez comprendre plus tard.

Ce qu'il faut exécuter localement et ce qu'il faut envoyer à un service

Une répartition judicieuse confie à la machine locale la découpe et l'indexation, et à un service les pages qui nécessitent réellement une lecture.

La découpe avec qpdf ou pdftk est rapide, s'exécute sur le fichier sans l'envoyer, et ne coûte rien. L'OCR avec Tesseract ou OCRmyPDF peut également s'exécuter localement, ce qui importe lorsque les archives contiennent des documents que vous préférez ne pas confier à un outil d'envoi en ligne inconnu. La contrepartie est le débit : une machine, un pool de CPU, et un coût mémoire réel par page en cours de traitement. Un outil de bureau peut néanmoins rester la bonne solution pour l'étape d'extraction sur un document unique, et les forces et limites de cette catégorie sont abordées dans comparaison des logiciels OCR de bureau.

Un service d'OCR cloud supprime la limite matérielle et facture à la page. Il impose aussi des plafonds d'envoi qu'un fichier de 600 MB atteint immédiatement, si bien qu'un service ne devient utile qu'après la découpe du fichier. Les outils de découpe en ligne plafonnent généralement à quelques dizaines de mégaoctets, ce qui les exclut pour le fichier source lui-même.

Conservez les archives et la découpe en local. Envoyez un sous-ensemble défini à l'outil qui le lit. Un envoi unique de 600 MB n'existe pas en tant que produit, et le flux de travail n'en a pas besoin.

Où l'extraction intervient après la découpe

Une fois le fichier géant découpé en morceaux, il reste à extraire quelques champs nommés de milliers de pages et à les regrouper dans un seul tableur.

C'est là que l'extraction diffère de l'OCR. L'OCR convertit l'image d'une page en un bloc de texte. L'extraction répond à une question plus ciblée : quelle est la date du document, le numéro de dossier, le numéro de compte, le montant sur cette page ? Un outil d'extraction basé sur la vision répond directement à cette question au lieu de produire un texte que vous devez ensuite analyser, et la différence est la même que celle abordée dans pourquoi la précision dépend de l'entrée.

Extraction de colonnes personnalisées part de ce que vous voulez. Vous saisissez les noms de colonnes, comme Date du document, Numéro de dossier ou Numéro de compte, et l'outil localise chaque valeur par le sens sur chaque page et chaque mise en page. Un formulaire qui change de conception entre la page 400 et la page 4 000 ne nécessite pas de nouveau modèle, car rien n'est entraîné ni configuré par type de document. Vous définissez la sortie ; les archives ne définissent rien.

Traitement par lots en priorité gère le volume. Vous envoyez un lot entier comme un ensemble de fichiers plutôt qu'un à la fois, et les résultats fusionnent dans un seul tableur avec une ligne par page. Pour un lot de documents numérisés, c'est la même idée que celle décrite dans exécution d'un OCR par lots sur un dossier, étendue d'un dossier à des archives.

Le flux devient : découpe, puis lot, puis extraction. Découpez les archives par structure en morceaux de la taille d'un chapitre ou selon un nombre de pages, envoyez un morceau par lot, et extrayez les mêmes colonnes nommées de chaque morceau. La sortie n'est plus un document de 7 000 pages. C'est un tableau que vous pouvez trier par date, filtrer par numéro de dossier, et parcourir pour repérer les pages revenues vides. Ce dernier point est une fonctionnalité : une cellule vide indique que la page n'avait rien à lire, et cela maintient l'index fiable sur des milliers de lignes.

Les limites à prendre en compte

Aucun produit n'ingère un PDF de 600 Mo et 7 000 pages en un seul appel, et un plan qui le supposerait échouerait dès le premier jour. Les limites qui comptent sont publiques et méritent d'être vérifiées avant de commencer :

Un travail de 7 000 pages représente donc au moins 7 000 fichiers. Sur un plan Max, cela correspond à environ 24 lots de 300, et au niveau Standard, à 7 000 credits. Ces deux chiffres expliquent pourquoi vous vérifiez votre plan avant de commencer, et aucun des deux n'empêche de mener le travail à bien.

La longueur joue aussi contre la précision. Les erreurs de transcription s'accumulent avec le volume, si bien qu'une erreur à la page 87 d'un traitement de 120 pages peut se propager à travers les champs à références croisées. C'est pourquoi le cap des cent pages est le seuil à partir duquel la plupart des outils recommandent de diviser en sections logiques, et cela est traité en détail dans ce qu'il faut attendre de l'extraction PDF multipage. À 7 000 pages, l'argument de la division est opérationnel et concerne tout autant la précision.

Une dernière règle fait gagner le plus de temps : ne faites pas d'OCR sur ce qui possède déjà une couche de texte. Si le test de sélection de texte réussit sur un échantillon de pages, extrayez le texte directement et sautez entièrement l'étape de reconnaissance.

FAQ

Puis-je OCR un PDF de 7 000 pages en une seule fois ?

Non. Un seul téléversement de 600 Mo dépasse la limite de 10 Mo par fichier et le plafond de 50 pages côté serveur, et les outils de bureau manquent de mémoire bien avant cela. Divisez d'abord le fichier, puis traitez les morceaux.

Comment diviser un grand PDF par signets sans le faire à la main ?

Acrobat peut diviser par signets de premier niveau, et des outils tels que Apryse PDF PageMaster, EverMap AutoSplit et DeftPDF prennent en charge des niveaux de signets plus profonds. qpdf, le diviseur courant en ligne de commande, ne peut pas diviser par signets ; il divise par plage de pages ou par nombre fixe de pages.

Pourquoi mon lecteur PDF plante-t-il sur un fichier de 600 Mo ?

Le rendu d'une seule page à 600 DPI peut prendre environ 104 Mo de mémoire, et un lecteur qui conserve plusieurs pages ou qui construit un modèle du document dépasse ce qu'une application de bureau peut gérer. Les flux d'objets compressés et l'absence d'une mise en page à visionnement rapide aggravent le ralentissement.

Combien de temps prend l'OCR sur des milliers de pages ?

À environ 25 pages par minute sur un processeur avec Tesseract, 7 000 pages représentent environ 4,7 heures en monothread, ou environ 40 minutes avec huit travailleurs en parallèle. Les services cloud s'exécutent sur de nombreuses machines et facturent par page à la place.

Dois-je OCR chaque page si je n'ai besoin que de quelques champs ?

Non. Nommez les champs que vous voulez et exécutez-les sur les pages qui les contiennent. Un index des dates, des numéros de dossier et des montants est généralement le véritable livrable, pas une transcription complète des archives.

Quel est le moyen le moins cher d'OCR des milliers de pages ?

Tesseract en local est pratiquement gratuit et limité par le processeur. Les principales API OCR cloud coûtent environ un dollar pour 1 000 pages, donc un travail de 7 000 pages démarre sous 10 $. L'économie la plus importante consiste à ne pas exécuter d'OCR du tout sur les pages qui ont déjà une couche de texte ou dont vous n'avez pas besoin.

La taille d'un fichier est une déclaration sur le travail qu'il contient. 7 000 pages sont un problème de recherche bien avant d'être un problème d'OCR, et le livrable qui vaut la peine d'être construit est un index des pages dont vous avez besoin plutôt qu'une copie fidèle d'une archive que vous ne lirez jamais de bout en bout. Coupez le fichier là où il se divise déjà, nommez les champs qui vous intéressent et laissez un lot faire le reste.

Extrayez les champs dont vous avez besoin d'un PDF géant