RAG PDF : pdf-inspector ou OCR direct en 2026 ?

10–50 ms pour classifier un PDF : le bon choix n’est pas « pdf-inspector ou OCR »

La documentation officielle de pdf-inspector indique une classification annoncée entre 10 et 50 ms selon la stratégie de balayage utilisée, avec une décision possible au niveau de chaque page. Le projet ne doit donc pas être opposé à l’OCR comme s’il s’agissait de deux parseurs concurrents : pour un RAG PDF, pdf-inspector constitue plutôt la porte d’entrée, tandis que l’OCR devient une branche conditionnelle pour les pages numérisées ou mal encodées. (Détails de la classification et du routage par page)

Cet article s’adresse à trois profils :

les développeurs qui construisent leur première chaîne d’ingestion documentaire ;
les équipes qui appliquent déjà un OCR partout et constatent une latence ou une instabilité difficiles à expliquer ;
les responsables qui préparent un environnement distant pour des tests de volume et doivent définir des critères d’acceptation avant de choisir une configuration.

La décision opérationnelle est simple : utilisez l’extraction native quand le texte, l’ordre de lecture et la structure sont acceptables ; déclenchez l’OCR uniquement lorsque les indicateurs de qualité le justifient ; conservez une voie de repli pour les documents mixtes.

Dernière mise à jour : 10 août 2026. Les informations relatives au projet ont été vérifiées dans son dépôt, sa documentation et ses résultats de comparaison publiés le 31 juillet 2026.

Qualité d’extraction : la présence de caractères ne suffit pas

Dans une chaîne RAG, un texte techniquement non vide peut rester inutilisable. Un PDF peut contenir une couche de texte invisible, issue d’un OCR ancien, dont les mots sont désordonnés, les ligatures mal décodées ou les colonnes fusionnées. À l’inverse, une extraction native correctement positionnée peut conserver une hiérarchie plus exploitable pour le découpage en segments.

Le contrôle doit donc porter sur plusieurs niveaux :

Couverture textuelle : quelle proportion des pages produit réellement du texte exploitable ?
Ordre de lecture : les colonnes sont-elles parcourues dans le bon ordre, sans mélange entre en-têtes, notes et corps de texte ?
Structure éditoriale : les titres, listes, blocs de code, légendes et sauts de page restent-ils identifiables ?
Tableaux : les lignes, colonnes, cellules vides et valeurs négatives conservent-elles leur relation ?
Traçabilité : chaque segment peut-il être relié à un numéro de page, une zone ou un identifiant de document ?
Encodage : les caractères accentués, symboles scientifiques et polices CID sont-ils correctement décodés ?

Le dépôt de pdf-inspector décrit une extraction tenant compte de la position, des coordonnées X/Y, des colonnes, des tableaux et de certains problèmes d’encodage. Il mentionne également une conversion vers Markdown avec titres, listes, liens, sauts de page et détection de tableaux. Ces fonctions sont utiles pour une première étape de PDF Parsing, mais elles ne prouvent pas qu’un document métier complexe sera automatiquement prêt pour le RAG. (Fonctions d’extraction et de conversion Markdown)

L’OCR répond à une autre question : quels caractères sont visibles dans l’image de la page ? Il peut rendre un document numérisé interrogeable en ajoutant une couche textuelle, mais cette opération doit être suivie d’une vérification de l’exhaustivité et de l’exactitude. (Explication de la couche texte créée par l’OCR)

Pour une base de connaissances, la mesure utile n’est donc pas « le texte existe ». Il faut vérifier si une question ciblant un titre, une valeur de tableau ou une note de bas de page retrouve le bon passage avec une référence vérifiable.

Latence et débit : le routage évite l’OCR inutile

L’OCR direct simplifie le diagramme au départ : chaque fichier est rendu en image, envoyé au moteur de reconnaissance, puis nettoyé avant la segmentation et l’indexation. Cette simplicité apparente impose toutefois plusieurs étapes supplémentaires, ainsi qu’une consommation de ressources qui varie selon le nombre de pages, la résolution, la langue et la complexité de la mise en page.

Le dépôt de pdf-inspector fournit un exemple de routage dans lequel la classification est suivie d’une extraction locale pour les documents textuels, tandis que les documents insuffisamment fiables sont transmis à l’OCR. Les valeurs données dans cet exemple sont des indications de fonctionnement du projet, pas une garantie applicable à toutes les machines ni à tous les moteurs OCR. (Exemple officiel de routage PDF)

Les résultats de comparaison publiés dans le README ont été obtenus sur un corpus de 200 PDF, avec OCR désactivé, sur une machine Apple M4 Pro. La version indiquée pour pdf-inspector est 0.2.6 et le temps médian complet communiqué pour ce corpus est de 0,470 seconde. Ce résultat est intéressant pour comparer des parseurs locaux dans ce protocole précis ; il ne permet pas de déduire le temps d’un pipeline complet incluant rendu, OCR, nettoyage, embeddings et stockage. (Méthode et résultats reproductibles du benchmark)

La conséquence architecturale est plus importante que le chiffre lui-même :

un petit corpus homogène peut tolérer un OCR systématique si la simplicité prime ;
un corpus composé majoritairement de rapports, contrats ou articles déjà textuels bénéficie d’une détection en amont ;
un corpus mixte doit être routé page par page lorsque la classification globale masque des pages numérisées ;
une ingestion continue doit enregistrer le taux de déclenchement OCR afin de repérer une dérive du type de documents reçus.

Le débit doit être mesuré avec le même corpus, la même version, la même stratégie de balayage et le même niveau de concurrence. Une comparaison entre un parseur local séquentiel et un service OCR parallèle ne permettrait pas de conclure correctement.

Compatibilité documentaire : trois responsabilités à ne pas confondre

Les fichiers les plus difficiles ne sont pas nécessairement les scans complets. Les cas problématiques incluent aussi les dossiers contenant plusieurs colonnes, des tableaux financiers, des schémas avec texte intégré, des formules, des pages photographiées au milieu d’un rapport natif et des couches de texte corrompues.

La répartition des responsabilités peut être formulée ainsi :

pdf-inspector : détection et extraction native

Le projet sait distinguer plusieurs catégories annoncées, dont les documents textuels, numérisés, fondés sur des images et mixtes. Il peut aussi retourner des pages nécessitant potentiellement un OCR. Son rôle est de déterminer quelle voie semble appropriée et d’extraire le texte déjà présent dans le fichier. (API et catégories de documents)

Parseur de mise en page : reconstruction documentaire

Un parseur généraliste peut regrouper les lignes, ordonner les colonnes, repérer des titres ou transformer certains tableaux. Cette étape traite la géométrie et la structure visibles dans le PDF ; elle ne reconnaît pas automatiquement les caractères absents de la couche texte.

OCR : reconnaissance des caractères dans les images

L’OCR devient nécessaire lorsque le contenu utile est uniquement une image ou lorsque l’extraction native produit des caractères incohérents. Toutefois, reconnaître les mots ne signifie pas reconstruire parfaitement les relations entre cellules, colonnes, légendes et paragraphes. Les outils spécialisés dans l’analyse documentaire distinguent d’ailleurs l’extraction du texte, la détection de la mise en page et l’extraction des tableaux. (Exemple de sortie séparant texte, structure et tableaux)

Pour l’audio, la vidéo et le design, cette distinction est particulièrement utile. Un dossier de conception peut contenir un brief textuel, des captures d’écran, des planches de références et des annotations intégrées à des images. Appliquer un OCR à tout le fichier ne suffit pas : il faut décider quelles pages alimentent la recherche textuelle, quelles images nécessitent une description distincte et quelles références doivent rester liées à leur page d’origine.

Point de vigilance : une classification réussie ne constitue pas une compréhension complète du document. Elle indique une voie de traitement ; la qualité finale doit être évaluée sur des segments et des questions réelles.

Coût total : compter chaque étape du pipeline

Le coût d’un RAG PDF ne se limite pas au moteur OCR. Une estimation exploitable sépare au moins les postes suivants :

réception, stockage temporaire et contrôle d’intégrité du fichier ;
détection du type et analyse de la structure ;
rendu des pages destinées à l’OCR ;
reconnaissance des caractères et éventuelle détection de la mise en page ;
nettoyage, normalisation et conservation des références de page ;
découpage en segments ;
génération des embeddings ;
stockage des vecteurs, des métadonnées et des artefacts de reprise ;
exécution des tests de régression et conservation des journaux.

La formule de base peut rester indépendante des tarifs :

Coût d’une campagne = volume de pages × coût moyen par page + durée d’exécution × tarif de l’environnement + stockage + reprise des échecs.

Pour un environnement loué, la décision doit également tenir compte de la période d’utilisation :

Coût de location = tarif de la période × nombre de périodes nécessaires au traitement, aux tests et à la régression.

Une machine dimensionnée pour une importation mensuelle peut être inefficace si elle reste inactive entre deux campagnes. À l’inverse, un environnement trop petit peut prolonger le traitement, augmenter les fenêtres d’exploitation et compliquer les reprises. Pour préparer une campagne distante, il est pertinent de comparer les scénarios dans un environnement Mac accessible à distance, puis de documenter la durée réelle de chaque étape plutôt que de retenir une configuration sur la seule base de la mémoire annoncée.

Le choix dépend aussi de la confidentialité. Un OCR local limite le transfert de documents sensibles, tandis qu’un service distant peut simplifier la montée en charge mais ajouter des exigences de contrôle d’accès, de conservation et de journalisation. Les équipes doivent séparer le coût d’exécution du coût de conformité.

Architecture selon la taille du corpus

Prototype de petite taille

Pour quelques documents représentatifs, le pipeline peut rester simple :

calculer une empreinte du fichier ;
lancer pdf-inspector en mode détection ;
extraire nativement les documents textuels ;
envoyer les pages numérisées vers l’OCR ;
conserver le résultat original, le résultat nettoyé et les métadonnées ;
tester manuellement les passages critiques avant l’indexation.

Cette approche permet de valider rapidement la qualité du découpage sans construire immédiatement un système de files d’attente complexe.

Traitement périodique

Pour une campagne hebdomadaire ou mensuelle, la séparation des étapes devient préférable. La détection doit produire une décision persistante : type de PDF, pages candidates à l’OCR, score de confiance si disponible, version du parseur et date de traitement. Une file distincte peut ensuite traiter les pages OCR sans bloquer les fichiers natifs.

Les échecs doivent être rejouables à partir du fichier original, et non d’un artefact temporaire. Les règles de conservation, de confidentialité et d’accès aux documents doivent être documentées avant de transférer une campagne vers un environnement distant.

Ingestion continue en production

Pour une ingestion permanente, le routage doit être observable. Les journaux doivent répondre à quatre questions : pourquoi le document a-t-il été envoyé vers l’OCR, quelle version a produit le texte, combien de pages ont échoué et quelle révision a été indexée ?

Les versions doivent être figées pendant une campagne de comparaison. Une mise à jour de dépendance peut modifier l’ordre de lecture, le décodage d’une police ou la reconstruction d’un tableau. Le dépôt indique notamment une dépendance principale liée à l’analyse PDF et propose plusieurs interfaces, dont Python, Node.js, Rust et WebAssembly ; chaque liaison mérite un test séparé avant déploiement. (Interfaces et dépendances annoncées)

Contrôle avant mise en ligne

La liste suivante peut servir de critère de passage entre expérimentation et production :

[ ] Les échantillons couvrent les PDF natifs, numérisés, mixtes, multi-colonnes et riches en tableaux.
[ ] Chaque fichier possède une empreinte, une version de traitement et une référence de source.
[ ] Les pages envoyées vers l’OCR sont identifiables après traitement.
[ ] Les titres, paragraphes, tableaux et numéros de page sont vérifiés séparément.
[ ] Les caractères accentués, symboles, formules et polices inhabituelles font partie de la régression.
[ ] Les échecs de détection, de rendu, d’OCR et d’embedding disposent d’une reprise indépendante.
[ ] Les segments conservent une référence vers le document et la page d’origine.
[ ] Un jeu de questions annotées mesure la récupération avant et après modification du parseur.
[ ] Les versions du parseur, de l’OCR et des dépendances sont figées pendant la comparaison.
[ ] Le taux d’utilisation de l’OCR est suivi dans le temps afin de détecter une dérive du corpus.
[ ] La durée d’exécution est mesurée dans l’environnement réellement prévu pour la production.
[ ] Une régression complète peut être relancée à partir des mêmes fichiers et paramètres.

Pour les tableaux, l’évaluation doit vérifier les relations entre cellules, et pas seulement la présence des mots. Les systèmes d’extraction structurée renvoient souvent des coordonnées ou des niveaux de confiance précisément parce qu’un texte correct mais mal rattaché à sa colonne peut produire une réponse RAG fausse. (Limites et scores de confiance pour l’extraction de tableaux)

Choix final : le routage hybride comme défaut raisonnable

Le score de décision peut être résumé ainsi :

Extraction native via pdf-inspector : 5/5 pour les PDF textuels dont l’ordre de lecture et l’encodage sont vérifiés.
OCR direct : 3/5 pour un prototype homogène, mais moins adapté lorsqu’une grande partie des pages contient déjà du texte.
Routage hybride : 5/5 pour une ingestion mixte, à condition de conserver des seuils, des journaux et une voie de repli.
Compréhension complète de document : 2/5 pour pdf-inspector seul, car la classification et l’extraction ne remplacent pas l’analyse métier des figures, formules et tableaux complexes.

Le bon choix dépend donc de la population documentaire, pas de la popularité d’un outil. Un petit prototype peut accepter l’OCR systématique pour réduire le nombre de composants. Une chaîne périodique doit déjà éviter les appels inutiles. Une plateforme de production doit détecter au niveau de la page, mesurer la qualité des segments et pouvoir rejouer chaque étape.

Le fonctionnement actuel d’un pipeline fondé uniquement sur l’OCR présente trois défauts réels : il traite aussi les pages qui n’en ont pas besoin, il rend plus difficile l’identification de la source d’une erreur et il augmente la durée ainsi que les ressources mobilisées pour chaque campagne. À l’inverse, un routage hybride impose davantage d’observabilité et de tests, mais il évite de confondre reconnaissance de caractères et préparation documentaire. Pour une équipe qui doit exécuter des régressions, comparer plusieurs versions ou absorber un pic d’importation, louer un environnement Mac auprès de Zilmac peut offrir une voie plus souple que l’achat immédiat d’une machine dédiée, surtout lorsque l’usage reste temporaire ; les besoins de calcul et de durée peuvent être cadrés avec l’assistance Mac de Zilmac avant la campagne.

Le point de départ recommandé est une feuille de test reliant chaque type de fichier à ses indicateurs : couverture textuelle, ordre de lecture, tableaux, latence, taux OCR, coût de campagne et qualité des réponses. Pour approfondir le dimensionnement d’un traitement en lot, consultez également les tarifs des environnements Mac VPS et comparez-les à la durée réelle de vos régressions, plutôt qu’à une estimation théorique.