Une équipe data branche un pipeline RAG sur son fonds documentaire : factures fournisseurs, rapports annuels, contrats commerciaux, tout au format PDF. Le pipeline convertit chaque document en texte, découpe ce texte en chunks, les indexe. Les premières réponses générées sont correctes. Puis, sur un rapport à deux colonnes, une requête sur “le chiffre d’affaires du troisième trimestre” ramène un chiffre qui appartient en réalité à une autre colonne, une autre ligne, un autre paragraphe. Le texte extrait était bien là, quelque part dans le chunk — mais dans le mauvais ordre.
Un pipeline RAG hérite des défauts du PDF source
Un PDF ne stocke pas une suite de paragraphes dans l’ordre où un humain les lit. Il stocke des instructions de dessin : telle chaîne de caractères, à telle position (x, y) sur la page, dans telle police. L’ordre dans lequel ces instructions apparaissent dans le fichier ne correspond pas forcément à l’ordre visuel de lecture — c’est particulièrement vrai sur les mises en page à colonnes, les tableaux, ou les documents générés par des outils d’export qui n’ont jamais eu besoin de préserver cet ordre puisque personne, jusqu’ici, ne lisait le fichier autrement qu’à l’œil.
Un outil comme pdftotext (et la plupart des extracteurs de texte brut équivalents) doit donc reconstruire un ordre de lecture par des heuristiques de position. Sur une page simple, ça fonctionne. Sur un tableau à deux colonnes — description à gauche, montant à droite — l’heuristique peut interclasser les lignes des deux colonnes, ou coller le montant d’une ligne à la description de la suivante. Le texte extrait reste exact caractère par caractère ; c’est son ordre qui devient faux. Un pipeline RAG qui découpe ensuite ce texte en chunks et les indexe hérite directement de cette erreur — sans jamais la détecter, puisque rien dans le texte brut ne signale qu’une ligne de tableau a été mal recomposée.
L’OCR seul règle la lisibilité, pas la traçabilité
Sur un PDF scanné (une facture papier numérisée, un contrat signé puis rescanné), le problème change de nature mais ne disparaît pas. L’OCR produit du texte à partir de l’image de la page — un vrai progrès par rapport à une image brute illisible pour une machine. Mais ce texte sort sans structure logique ni position exploitable : aucune information sur la zone de la page dont provient chaque phrase, aucune distinction entre un titre et un paragraphe, aucune validation que la hiérarchie du document (titre, sous-titre, corps) a été correctement reconnue. Un moteur RAG qui indexe ce texte peut retrouver la bonne information, mais ne peut pas répondre à la question suivante : cette phrase, elle vient d’où, exactement, sur la page source ?
Cette absence de traçabilité pèse d’autant plus lourd que les documents concernés — factures, contrats, données clients — sont souvent sensibles. Un pipeline OCR maison, assemblé à partir de plusieurs briques open source, pose en plus une question d’hébergement : si une partie du traitement passe par un service hors Union européenne, les données transitent par une infrastructure soumise à des législations extraterritoriales, avec les questions de conformité RGPD que ça soulève. C’est un sujet à part entière (traité plus en détail par ailleurs) — mais il pèse dans la balance dès qu’on choisit où et comment structurer des PDF contenant des données clients.
Ce que contient réellement un export structuré Vigie PDF
Vigie PDF fait tourner opendataloader-pdf sur chaque document déposé, natif ou scanné, pour produire un tagging automatique en arrière-plan. Le résultat n’est pas un fichier texte à plat : c’est une collection de zones, chacune typée selon sa nature (titre, paragraphe, liste, tableau, image, légende, en-tête, pied de page, bloc de texte), positionnée par ses coordonnées exactes sur la page, et ordonnée selon l’ordre de lecture réellement détecté — pas l’ordre d’apparition brut dans le fichier. Cet export s’obtient en un seul appel, dans le format qui convient au pipeline déjà en place (JSON, Markdown ou HTML) ; le détail précis des formats disponibles est dans la documentation, consultable depuis le tableau de bord une fois le compte créé. C’est la même donnée, exposée aussi bien via l’API REST de Vigie PDF que depuis le tableau de bord, sans traitement caché entre les deux.
Concrètement, une zone de type tableau conserve ses lignes et ses cellules organisées comme telles, plutôt que de renvoyer un tableau à deux colonnes en une suite de lignes de texte interclassées comme le ferait une extraction brute. Une zone de type image référence l’image extraite elle-même, accessible uniquement par le compte propriétaire du document — jamais un lien public qui contournerait l’authentification. Chaque zone porte aussi un identifiant propre, ce qui permet à un pipeline RAG de conserver, pour chaque chunk indexé, la référence exacte de la zone dont il provient : la page, le type de contenu, la position sur la page. Une réponse générée par le RAG peut alors être vérifiée jusqu’à sa source — pas juste “extrait du document X”, mais “page 3, tableau, troisième ligne” — ce qui n’a strictement aucun équivalent dans un flux de texte brut ou une sortie OCR non structurée.
C’est précisément ce même modèle de zones, avec ses coordonnées et son ordre de lecture, qui s’affiche à l’écran dans le Studio de visualisation des zones taguées — l’export JSON n’est rien d’autre que la version machine-lisible de ce que le Studio donne déjà à voir visuellement, zone par zone, sur la page rendue.
Une même donnée, deux usages : conformité et exploitation
Cette même pipeline de tagging sert un second objectif, distinct mais parent : la validation PDF/UA-1 (ISO 14289-1), exécutée par le moteur de validation de Vigie PDF sur la structure détectée par opendataloader-pdf. Structurer un document pour l’exploiter dans un pipeline RAG et vérifier sa conformité PDF/UA-1 ne sont pas deux traitements séparés — ce sont deux usages de la même donnée structurée : d’un côté, un lecteur d’écran ou un contrôle d’accessibilité s’appuie sur cette hiérarchie de zones pour restituer le document correctement ; de l’autre, un pipeline RAG s’appuie sur les mêmes zones, les mêmes coordonnées, pour indexer un contenu traçable. Le RGAA, référentiel légal français plus large que la norme PDF/UA-1, encadre l’obligation d’accessibilité elle-même — il ne s’agit jamais d’un second contrôle automatisé distinct, mais du même travail de structuration qui, une fois fait, sert les deux besoins à la fois.
Ce que ça change pour une équipe RAG au quotidien
Pour une équipe data qui alimentait jusqu’ici son pipeline avec du texte extrait à la chaîne, sans structure ni position, le changement se mesure à trois niveaux. D’abord la fiabilité des réponses : un chunk qui respecte l’ordre de lecture réel et la séparation par zone ne mélange plus une colonne de tableau avec une autre, ni un titre avec le paragraphe qui suit. Ensuite la traçabilité : chaque réponse générée peut être reliée à sa source exacte — document, page, zone, coordonnées — sans reconstruire cette information a posteriori par une recherche floue dans le texte brut. Enfin la souveraineté : le traitement tourne sur une infrastructure hébergée dans l’Union européenne (Francfort, Allemagne), sans pipeline OCR maison à maintenir ni service tiers hors UE à intégrer pour combler les manques d’un simple extracteur de texte.
Rien de tout cela ne demande de réécrire le pipeline RAG existant depuis zéro. L’export structuré s’obtient en un appel API sur un document déjà tagué, dans le format qui convient au pipeline de chunking déjà en place — JSON pour un traitement programmatique zone par zone, Markdown ou HTML si le pipeline attend un format de texte enrichi. La question n’est plus de reconstruire une structure absente à coups d’heuristiques fragiles, mais de consommer une structure déjà présente, tracée jusqu’à sa position exacte sur la page source.