Lire des PDF : choisir page par page entre extraction de texte et modèle de vision

Par Elisha Bajemon, Ingénieur IA chez TW3 Partners. Dernière mise à jour : 19 octobre 2026.

En bref

Pour extraire un PDF, choisissez page par page entre le texte disponible et la lecture visuelle, selon les informations à conserver. La réalisation publiée par TW3 Partners, sans date, documente un corpus de 20 documents, 999 pages et 1 951 questions de vérification. Son routeur associe un encodeur visuel figé à trois petits classifieurs et deux pré-filtres textuels sans modèle. Il partage le GPU T4 déjà utilisé par la chaîne de recherche. La démarche comprend une mesure du gain à coût égal, une validation par un second annotateur et une réplication sur un banc public. Pour une DSI, nous recommandons de reprendre cette logique de vérification sur son propre fonds documentaire avant de choisir le mode de lecture.

1. Pourquoi ne pas envoyer toutes les pages à un modèle de vision ?

Une lecture visuelle systématique mobilise des ressources même sur les pages dont le texte suffit à alimenter l’assistant. La fiche de TW3 Partners, sans date de publication affichée, décrit une organisation qui synchronise chaque jour depuis SharePoint des supports, examens, procédures et chartes. Le problème posé est celui de l’ingestion : préparer ces documents pour que l’assistant puisse ensuite les exploiter.

La fiche constate que l’envoi de toutes les pages à un modèle de vision coûte cher et ralentit cette préparation. Elle relève aussi les pertes de figures, de formules et de pages scannées lorsque seule l’extraction native est utilisée. Le choix porte donc sur la manière de lire chaque page du fonds.

Pour cadrer un projet similaire, le cabinet recommande de commencer par les informations que les équipes doivent retrouver. Nous proposons d’inclure dans la recette, c’est-à-dire les vérifications avant mise en service, les éléments visuels nécessaires à leurs réponses, puis de vérifier leur restitution. Cette exigence métier permet de définir ce que signifie une extraction suffisante avant de sélectionner les modèles.

2. Extraction native, OCR ou vision : qu’est-ce qui les distingue ?

L’extraction native récupère le texte enregistré dans le PDF ; l’OCR reconnaît le texte dans une image. La réalisation TW3 ajoute une décision : choisir les pages qui justifient une lecture par modèle de vision.

La documentation pypdf, sans date, définit l’OCR, ou reconnaissance optique de caractères, comme l’extraction de texte à partir d’images. Elle distingue les PDF créés numériquement, les scans composés d’images et les scans enrichis d’une couche de texte reconnue par OCR. Un PDF scanné peut donc déjà fournir du texte sélectionnable. La documentation signale également la difficulté de reconstruire les lignes et les colonnes d’un tableau à partir de caractères positionnés dans la page.

Le tableau rapproche ces distinctions des voies décrites dans la réalisation.

Nous recommandons de comparer les sorties avec la page d’origine. Le simple fait d’obtenir du texte constitue un contrôle insuffisant pour accepter une extraction : la recette doit porter sur le contenu attendu par le métier.

3. Que décide le routeur, page par page ?

Le routeur prédit si l’extraction native risque d’échouer en présence d’une image utile, d’une formule ou d’un scan. Un routeur de pages désigne un composant qui choisit la voie de lecture d’une page avant son ingestion, selon les caractéristiques détectées.

Dans la réalisation TW3, trois petits classifieurs portent cette décision, avec deux pré-filtres textuels sans modèle. Le routage intervient avant l’ingestion et oriente la page vers l’extraction de texte ou vers la lecture visuelle.

Pour construire la recette d’un tel composant, nous recommandons de distinguer les erreurs selon leur conséquence. Une page orientée inutilement vers la vision ajoute une lecture à évaluer. Une page conservée en extraction native alors qu’une information utile manque appelle un examen de cette perte. Nous proposons de documenter, pour chaque erreur, la page concernée, le choix du routeur et l’information attendue. Cette trace donne aux équipes métier une base de discussion pour accepter ou corriger la décision.

4. Comment fonctionnent l’encodeur figé et les classifieurs ?

L’encodeur figé conserve ses paramètres pendant l’apprentissage des petites têtes de décision ajoutées à sa sortie. Il fournit une représentation numérique de l’image ; les classifieurs apprennent à utiliser cette représentation pour décider du routage.

La fiche de TW3 Partners indique l’emploi de DINOv3 et l’entraînement de trois têtes de décision. La fiche officielle de DINOv3 publiée par Meta, sans date, décrit l’usage de ces modèles sans réentraînement, avec des classifieurs pouvant être aussi simples que des couches linéaires.

La fiche TW3 cite aussi SigLIP 2 et DINOv2 comme alternatives possibles. Pour préparer leur comparaison, nous recommandons de conserver les mêmes pages de vérification et les mêmes règles d’acceptation. L’équipe peut alors examiner les changements de décision et les informations récupérées. Elle doit aussi consigner la version de l’encodeur et celle des classifieurs pour pouvoir reproduire l’essai.

5. Comment mesurer le gain avant d’intégrer le routeur ?

Nous recommandons de relier les décisions de routage aux informations effectivement récupérées, avec une consommation de ressources comparable. La fiche TW3 décrit un corpus de 20 documents, 999 pages et 1 951 questions de vérification, puis une mesure du gain à coût égal, validée par un second annotateur et répliquée sur un banc public. Elle ne publie ni la valeur du gain ni le nom de ce banc.

Pour une DSI, nous recommandons le protocole suivant. Il s’agit d’une proposition de méthode, distincte du compte rendu de réalisation.

• Choisir des documents représentatifs du fonds à ingérer et faire établir les informations attendues par les référents métier.
• Associer chaque question de vérification à la page qui permet d’y répondre, avec une réponse de référence contrôlée.
• Préparer une extraction native de référence et les sorties obtenues avec routage, en conservant les mêmes questions.
• Examiner les informations récupérées ou perdues et les ressources consommées, puis faire relire les désaccords d’annotation.

Une question de vérification sert ici de critère de recette : l’équipe contrôle si l’extraction conserve les éléments nécessaires pour y répondre. Nous conseillons d’examiner d’abord cette conservation, avant d’attribuer au routeur une amélioration de la réponse finale de l’assistant.

Pour rendre la comparaison à coût égal reproductible, nous proposons de définir à l’avance les ressources comptabilisées et le périmètre de la mesure. Le relevé devrait inclure le temps d’ingestion, les appels de lecture visuelle et les ressources du routeur. L’acceptation porterait conjointement sur ces observations et sur les pertes d’information jugées admissibles par le métier.

6. Où tourne le routeur et quel modèle lit les pages ?

Le routeur décrit par TW3 utilise le GPU T4 déjà partagé avec les composants de représentation et de reclassement de la chaîne de recherche. La fiche de réalisation précise qu’il fonctionne sans matériel dédié. Elle mentionne Qwen3.5-2B et Gemini Flash comme modèles de vision évalués pour lire les pages routées.

Pour reprendre cette architecture, nous recommandons de tester l’ingestion pendant une période où l’assistant est également sollicité. Le partage du matériel devrait faire l’objet d’une recette commune : observer le temps de préparation des documents et celui des réponses de recherche, puis décider des conditions d’exploitation acceptables.

Nous conseillons également de séparer les décisions concernant le routeur et le lecteur visuel. Le premier choisit les pages à traiter ; le second réalise la lecture demandée. Le dossier de validation devrait identifier chacun des composants, les pages qu’il reçoit et les contrôles appliqués à sa sortie. Le choix du lecteur peut ainsi être réexaminé avec les mêmes questions de vérification.

7. Quand la lecture visuelle vaut-elle son coût ?

Nous recommandons de la retenir lorsqu’elle récupère une information utile perdue par l’extraction native et que la comparaison documentée justifie les ressources engagées. La réalisation TW3 situe ce besoin autour des images utiles, des formules et des scans.

Pour décider d’une intégration, nous proposons de réunir les pages ayant motivé le routage, les résultats de vérification et les observations sur l’infrastructure partagée. Les responsables métier peuvent alors examiner les informations préservées ; la DSI peut apprécier les conditions d’exploitation. Le périmètre accepté doit rester celui du corpus testé, avec une nouvelle vérification lorsque le fonds évolue.

Pour poursuivre sur la recherche documentaire, les articles associés sont « Retrouver une page à partir de son image : la recherche visuelle de documents expliquée » et « Rechercher dans des documents techniques et réglementaires qui mêlent texte, tableaux et schémas ».

FAQ

Faut-il un OCR pour lire un PDF ?
Cela dépend de son contenu. Selon la documentation pypdf, un scan peut contenir seulement une image ou disposer d’une couche de texte reconnue par OCR. Dans la réalisation TW3, le scan fait partie des motifs de routage vers le modèle de vision.

Comment connaître la part des pages envoyées vers la vision ?
Nous recommandons de la mesurer sur le fonds destiné à l’assistant. Le relevé devrait rapprocher les décisions du routeur des informations récupérées, afin de juger l’utilité des lectures déclenchées.

Le routeur demande-t-il un serveur supplémentaire ?
La réalisation TW3 fonctionne sans matériel dédié, sur le GPU T4 partagé avec la recherche. Pour un autre environnement, nous recommandons une vérification de la charge conjointe avant de retenir cette organisation.

Quel corpus a servi à vérifier le routeur ?
TW3 documente 20 documents, 999 pages et 1 951 questions de vérification. Pour reproduire la démarche, nous recommandons de constituer un corpus correspondant aux documents et aux questions des utilisateurs concernés.

Quelle licence s’applique aux encodeurs cités ?
La fiche de SigLIP 2 Base publiée par Google, sans date, indique Apache 2.0, comme le dépôt DINOv2 de Meta, sans date pour cette mention, pour son code et ses poids. DINOv3 relève de la DINOv3 License de Meta, mise à jour le 19 août 2025.

En quoi ce routeur diffère-t-il de la recherche par image de page ?
Le routeur décrit par TW3 Partners intervient avant l’ingestion pour choisir comment lire la page. La recherche à partir de son image fait l’objet de l’article « Retrouver une page à partir de son image : la recherche visuelle de documents expliquée ».

Pour aller plus loin

• Aiguillage des pages de documents avant ingestion dans un assistant.
• Retrouver une page à partir de son image : la recherche visuelle de documents expliquée.
• Rechercher dans des documents techniques et réglementaires qui mêlent texte, tableaux et schémas.
• Interroger ses documents internes avec l’IA : fonctionnement d’un assistant relié aux outils métiers.
• Mettre en place un RAG souverain : architecture, stack technique et conformité AI Act.

Sources

• TW3 Partners, Aiguillage des pages de documents avant ingestion dans un assistant, sans date, consulté le 9 octobre 2026.
• pypdf, Extract Text from a PDF, documentation sans date, consulté le 9 octobre 2026.
• Meta, Model Card for DINOv3, sans date, consulté le 9 octobre 2026.
• Google, SigLIP 2 Base, fiche de modèle sans date, consulté le 9 octobre 2026.
• Meta, DINOv2, dépôt officiel, sans date pour la section licence, consulté le 9 octobre 2026.
• Meta, DINOv3 License, mise à jour du 19 août 2025, consulté le 9 octobre 2026.