L'IA qui économise des millions : la méthode secrète des PDFs mal lus

UNE PAGE DE PDF PEUT COÛTER 10 000 FOIS PLUS CHÈRE QUE LES AUTRES

Prenez un rapport de 200 pages. Si vous faites analyser chaque page avec l'outil le plus puissant, vous paierez pour 200 pages… pour en sauver trois. Si vous utilisez l'outil le moins cher partout, une seule table aplatie peut faire échouer toute l'analyse. Aucun des deux choix n'est bon pour tout le document, car un PDF n'est jamais uniforme : la plupart des pages contiennent juste du texte, faciles à traiter, mais quelques-unes cachent des tableaux ou des images complexes qui nécessitent un traitement lourd. La solution ? Laisser chaque page décider elle-même de la façon dont elle doit être analysée.

Cette méthode s'appelle le parsing adaptatif. Elle fonctionne en deux phases. D'abord, on choisit un outil de base pour tout le document. Ensuite, on fait des vérifications gratuites sur chaque page. Si une page échoue ces tests, on la renvoie vers un outil plus puissant. La plupart des pages restent sur l'outil de base, seules quelques-unes reçoivent le traitement renforcé dont elles ont besoin.

COMMENT FONCTIONNE LE PARCORSSING ADAPTATIF ?

Imaginons que vous cherchez une information précise dans un article scientifique. Si la réponse se trouve dans un paragraphe de texte, l'outil basique suffit. Mais si l'information est cachée dans un tableau ou une image, l'outil basique échoue silencieusement et l'IA répond à côté de la question. Le piège ? L'outil puissant coûte cher et ralentit tout le processus. La solution : commencer par l'outil le moins cher, puis n'activer l'outil puissant que si les tests montrent qu'il est nécessaire.

Le système fonctionne comme une cascade de vérifications. Chaque test est moins cher que le suivant, mais plus fiable. À chaque étape, le pipeline se demande : « Est-ce que l'outil a produit assez d'informations pour répondre à la question ? ». Si la réponse est non, la page est envoyée vers un outil plus puissant. Sinon, on passe à la page suivante. L'objectif : ne payer que pour la qualité dont on a besoin.

LES DEUX PHASES DU PARSING ADAPTATIF

La première phase s'appelle l'initialisation. On choisit un outil de base en fonction du type de document : PDF natif, scan, ou export Word. Dans un contexte professionnel, cette étape se déclenche dès l'arrivée du document. Chaque nouveau fichier est analysé avec l'outil de base, même pour les PDF scannés où l'outil de base doit être un moteur OCR car PyMuPDF ne peut rien en extraire. Le résultat est toujours une première couche de texte, même pour les scans.

La deuxième phase est la cascade. On applique des tests gratuits et déterministes sur le résultat de l'outil de base. Les pages qui échouent sont envoyées vers un outil plus puissant. La plupart des pages restent sur l'outil de base, seules quelques-unes reçoivent le traitement renforcé. Le pipeline commence toujours par l'outil le moins cher : PyMuPDF pour les PDF natifs, un moteur OCR gratuit pour les scans. Ces deux outils produisent la même structure de données, donc le reste du pipeline (analyse des questions, récupération des informations, Génération de réponses) ne sait pas quel outil a été utilisé. Cela fonctionne dans la plupart des cas, sauf pour une petite mais prévisible partie du contenu.

LES PDF SCANNÉS : UN CAS PARTICULIER

Les PDF scannés, comme les pages photographiées ou faxées, posent un problème différent. PyMuPDF ne peut rien en extraire. Un moteur OCR gratuit comme Tesseract ou PaddleOCR peut combler ce manque, mais avec des limites : il lit bien les paragraphes de texte, mais peine sur les tableaux, les mises en page multi-colonnes, et les scans dégradés. Avec les scans, il n'existe pas d'outil OCR à la fois bon marché et performant.

Les OCR gratuits (Tesseract, EasyOCR) donnent un texte lisible sur des scans modernes et propres, mais se dégradent rapidement sur des pages déformées, en basse résolution, avec des langues mélangées, des polices historiques, ou des colonnes serrées. Les services cloud comme Azure Document Intelligence, AWS Textract ou Mistral Document AI lisent mieux les caractères et ajoutent la mise en page, mais coûtent quelques centimes par page. Les modèles de vision par IA lisent même les scans endommagés que les autres abandonnent, pour quelques centimes à une dizaine de centimes par page selon le modèle.

Cette asymétrie est cruciale pour la phase d'initialisation. Sur un corpus de PDF natifs, l'outil de base est vraiment bon. Sur un corpus de scans, l'outil de base est vraiment faible, et la cascade sera déclenchée sur la plupart des pages plutôt que sur quelques-unes. Sur un corpus très orienté scans, choisir dès le départ un service payant comme outil de base est souvent moins cher que de faire des escalades page par page.

DOCLING : UN OUTIL PLUS PUISSANT, MAIS À QUEL PRIX ?

Docling est un outil open source, gratuit à l'exécution, et conscient de la mise en page. Il combine en un seul appel PyMuPDF et un moteur OCR, et retourne des tableaux structurés, des sections et des légendes d'images directement. Tentant comme outil de base universel, mais le coût est réel : Docling télécharge quelques centaines de mégaoctets de modèles de mise en page et TableFormer lors de la première installation. À l'exécution, il est dix à cent fois plus lent que PyMuPDF sur les PDF natifs (une mesure a montré environ vingt-sept secondes par page sur un scan de 1974), et cela en supposant qu'un GPU est disponible. Sur CPU, il est encore plus lent. Sur un corpus de 500 pages, cela signifie des minutes à une heure de temps de parsing par document, contre les cinq secondes de PyMuPDF. L'installation elle-même peut aussi poser problème dans les environnements d'entreprise avec inspection SSL.

La bonne question n'est pas « Puis-je utiliser Docling comme outil de base ? », mais « Est-ce que mon environnement (taille du corpus, accès au GPU, budget de latence d'ingestion) me le permet ? ». Trois régimes apparaissent :

• Corpus petit, pas de GPU, budget serré → PyMuPDF + OCR gratuit
• Corpus moyen, GPU disponible, budget modéré → Docling
• Corpus grand, budget élevé → Services cloud payants

L'architecture en deux phases absorbe ces trois régimes. Choisissez l'outil de base le plus puissant que votre environnement peut supporter, et laissez la cascade gérer ce que l'outil de base rate encore.

POURQUOI LE PARSING À LA DEMANDE PAIE ?

Un corpus d'entreprise contient en moyenne 30 à 100 pages par document, avec 1 à 3 pages pertinentes pour une question donnée, et moins de 10 questions par document sur toute sa durée de vie. En multipliant ces chiffres, on obtient que 90 % des pages analysées à l'ingestion ne seront jamais utilisées par aucune réponse. Analyser profondément toutes les pages dès le départ, c'est payer pour des pages que personne ne lira jamais.

CINQ FORMES DE CONTENU QUI FONT ÉCHOUER LES OUTILS BASIQUES

Les outils basiques laissent cinq formes de contenu invisibles ou brouillées :

• Les tableaux aplatis (chaque cellule sur sa propre ligne)
• Les images opaques (diagrammes, graphiques sans texte extractible)
• Les anomalies de colonnes (mises en page complexes)
• Les figures avec du texte intégré (graphiques avec légendes)
• Les régions scannées (zones de texte dans des images)

Cet article se concentre sur les deux premières formes (tableaux aplatis et images opaques) car elles sont les plus faciles à reproduire sur un document public. Le mécanisme est le même pour les trois autres. Les tests déterministes de temps de parsing (brique de parsing de document, section 3) détectent ces formes d'échec, et le pipeline envoie la page vers le bon outil plus puissant. Le signal de l'IA au moment de la génération (brique de génération, dans la deuxième partie) est la sécurité ultime pour les cas que les tests déterministes n'ont pas attrapés en amont.

LA CASCADE EN UNE IMAGE

La qualité de l'analyse est une décision multi-tests. Le pipeline commence par l'outil le moins cher et demande, à chaque test, si l'outil a produit assez d'informations pour la question. Chaque test a un coût ; chaque test qui détecte un problème peut envoyer la page vers un outil plus puissant. Le pipeline ne paie que pour la qualité dont la question a besoin.

Les quatre briques du pipeline (parsing de document, analyse des questions, récupération, génération) possèdent chacune un à trois des neuf tests d'évaluation. Cette organisation rend la cascade lisible : chaque test appartient à une brique, chaque brique a son propre profil de coût et son propre test caractéristique. Le diagramme de la cascade dans la section 1 montre la cartographie complète.

Deux exemples récurrents rendent la cascade concrète. Le test le moins cher qui se déclenche l'emporte, et le pipeline ne pose jamais aux tests plus lents une question que les tests plus rapides ont déjà résolue.

LE MODÈLE DE DONNÉES QUI SOUTIENT TOUT ÇA

Quel que soit le test qui déclenche l'escalade, le schéma pour la ré-exécution est le même. On ajoute une colonne, parsing_method, aux tables relationnelles de la section 5. La logique d'escalade devient : écrire de nouvelles lignes avec une méthode plus profonde sur les pages concernées. Les documents mixtes, la piste d'audit et la mise en cache découlent toutes du schéma gratuitement.

page_df est l'endroit canonique car le parsing se fait toujours page par page. Après une exécution adaptative typique sur l'article Transformer, où la cascade a détecté la page 6 (Tableau 1, « Longueurs de chemin maximales », détecté par le test 2 de l'empreinte des tableaux aplatis) et la page 3 (Figure 1, détectée par le signal de densité de caractères au test 1 et le signal de figure opaque au test 2), page_df ressemble à ceci :

SELECT * FROM pagedf WHERE pagenum=6 AND context_structured=True

Deux décisions de conception sont intégrées. D'abord, l'escalade ajoute de nouvelles lignes, elle ne remplace pas. La ligne PyMuPDF pour la page 6 reste à côté de la ligne Azure : « PyMuPDF a essayé, la cascade a détecté l'échec, Azure a été appelé et a réussi ». Ensuite, la colonne context_structured sur page_df permet aux requêtes en aval de choisir la bonne ligne : la requête ci-dessus retourne l'analyse fiable sans ré-exécution.

LA STRUCTURE DES DONNÉES : LIGNES, PAGES ET IMAGES

linedf porte aussi la colonne parsingmethod. Les lignes de PyMuPDF coexistent avec les lignes de l'outil plus profond sur la même page. PyMuPDF a produit le texte autour du Tableau 1 ; Azure a produit les lignes en markdown du tableau lui-même ; les deux restent dans linedf. La brique de récupération lit linedf et voit une structure uniforme, quel que soit l'outil qui a produit quelle ligne.

Les images vivent aussi dans linedf, sous forme de lignes avec type='image' et un texte de substitution. C'est ce qui rend le cas des figures mécaniquement identique au cas des tableaux. Le signal de figure opaque au test 2 détecte déjà ces pages à partir de linedf seul (image présente, zéro caractère extractible dans sa bbox). Quand la cascade détecte la page 3, le pipeline prend la ligne de imagedf, voit parsingmethod='notparsed', et appelle un modèle de vision par IA. La sortie de la vision est ajoutée à linedf sous forme de nouvelles lignes de texte avec parsingmethod='visiongpt4o', et la ligne de image_df est mise à jour.

La ré-analyse ciblée est un seul appel de fonction, indépendant de la méthode, qui retourne de nouvelles lignes avec parsing_method déjà rempli :

def enrich(pdfpath, linedf, page_df, pages, method):
    """Ajoute des lignes de niveau 2 pour pages en utilisant method ; garde les lignes existantes pour l'audit."""
    if method == "azure_layout":
        from docintel.parsing.pdf.azurelayout import azurelayoutpdftolinedf
        newlines = azurelayoutpdftolinedf(pdf_path, pages=pages)
    elif method == "vision_gpt4o":
        newlines = visionextract(pdf_path, pages=pages)
    # newlines porte déjà parsingmethod=method
    linedf = pd.concat([linedf, newlines], ignoreindex=True)
    pagedf = appendpagerows(pagedf, pages, method)
    return linedf, pagedf

Le schéma de linedf de la section 5 reste inchangé pour les briques en aval : la récupération et la génération lisent linedf, groupent par page_num, et n'ont jamais besoin de savoir quel outil a produit quelle ligne. Le seul contrat qui a changé est « l'identité de l'outil voyage avec la ligne ».

LES TROIS TESTS DE LA BRIQUE DE PARSING DE DOCUMENT

La brique de parsing de document possède trois des neuf tests : pré-parsing (test 1, avant toute extraction), parsing-temps (test 2, sur les sorties de PyMuPDF), et post-parsing (test 3, sur les chunks en aval de line_df). Tous les trois sont déterministes, gratuits, et produisent un verdict en millisecondes sans aucun appel à l'IA. Ensemble, ils attrapent la plupart des formes d'échec qui intéressent l'article, y compris les deux cas : le tableau aplati (Tableau 3 à la page 9) et la figure opaque (Figure 1 à la page 3), les deux cas que la deuxième partie parcourt de bout en bout.

LE TEST 1 : LES MÉTADONNÉES GRATUITES AVANT TOUTE EXTRACTION

PyMuPDF peut déjà rapporter des métadonnées par page en millisecondes : combien de caractères il peut extraire, combien d'images embarquées chaque page contient, quelle chaîne de caractères le PDF déclare comme producteur. Ces signaux routent la plupart du corpus avant que la décision de parsing ne devienne intéressante.

Une page de PDF natif extrait typiquement 2000 à 4000 caractères de texte. Les pages qui tombent bien en dessous de cette moyenne, accompagnées d'une ou plusieurs images embarquées, signalent que « la page est surtout une figure » sans aucune inspection plus profonde.

Pour la Figure 1 à la page 3, ce signal seul suffit à la détecter : 1827 caractères contre une moyenne de 2633 caractères dans le document, plus une image embarquée. Le pipeline pourrait router la page 3 vers un modèle de vision par IA sans jamais appeler Azure ou faire passer par une passe de génération. Pour le Tableau 3 à la page 9, le même signal ne déclenche pas : 2973 caractères (au-dessus de la moyenne), zéro image embarquée. Le test 1 attrape un des deux exemples gratuitement ; le test 2 attrapera l'autre.

Les métadonnées du PDF ajoutent un deuxième classifieur bon marché. Le producteur du papier Attention est pdfTeX-1.40.25, ce qui indique LaTeX natif, pas besoin d'OCR. Un PDF produit par un scanner dirait Adobe Scan, Canon, OmniPage. Cette seule chaîne route 80 % d'un corpus d'entreprise vers le bon outil avant toute extraction de texte. La date de création, la liste des polices embarquées et la présence d'un bloc XMP ajoutent des classifieurs grossiers mais utiles.

pre = preparsesignals("data/paper/1706.03762v7.pdf")
pre["producer"]            # -> "pdfTeX-1.40.25"
pre["isscanneroutput"]   # -> False
pre["pages"].head()
# pagenum  charcount  imagecount  imagebboxes
#        1        2858            0  []
#        2        4256            0  []
#        3        1827            1  [(196.6, 72.0, 415.4, 394.4)]   <-- Figure 1
#        4        2508            2  [(175.0, 94.0, 239.0, 221.3),
#                                     (346.8, 82.7, 467.0, 267.3)]   <-- Figure 2
#        5        3193            0  []

Le résultat de ce test n'est pas la réponse à une question. C'est un jugement par page : « cette page est normale », « cette page a une image manquante », « tout le document est scanné et a besoin d'OCR dès le départ ». Le jugement est gratuit et il est embarqué avec la colonne parsingmethod sur pagedf.

LE TEST 2 : LES SIGNAUX DÉTERMINISTES PENDANT L'EXTRACTION

PyMuPDF produit déjà des signaux déterministes sur la mise en page qu'il vient de parcourir. Trois tests se déclenchent à partir de line_df seul, sans aucun appel à l'IA.

PyMuPDF extrait chaque ligne avec des coordonnées de boîte englobante. Regrouper les coordonnées x des lignes par page produit un nombre de colonnes. Un document bien structuré a un nombre de colonnes stable d'une page à l'autre. La variance est le signal de routage.

L'anomalie à la page 10 est elle-même un signal de qualité de parsing. Le détecteur n'a pas produit un mauvais compte par accident, il l'a produit parce que le tableau a cassé le modèle de colonnes. C'est une information que le pipeline peut utiliser pour router la page 10 vers un outil conscient de la mise en page.

Quand PyMuPDF aplatit un tableau, les cellules tombent sur leurs propres lignes avec des boîtes étroites qui suivent immédiatement la légende « Tableau N : … ».

L'empreinte est concrète : à la page 9, les lignes 5 à 20 contiennent les en-têtes du tableau répartis sur deux lignes physiques de boîtes, et les lignes 21 à 33 contiennent les 13 cellules de la ligne de base, chacune sur sa propre ligne. Les cellules sont courtes (1 à 4 caractères), étroites (moins de 30 points PDF de large), et regroupées verticalement dans une bande serrée juste après une légende « Tableau 3 : … ». Un test qui compte ces propriétés sur linedf[pagenum=9] et déclenche un drapeau booléen s'exécute en O(n_lines) sans aucun appel à l'IA. Le Tableau 3 est détecté à ce test.

LE TEST 3 : LES VÉRIFICATIONS POST-PARSING

Le troisième test de la brique de parsing de document regarde les chunks en aval de line_df. Il vérifie si les lignes produites sont assez cohérentes pour répondre à une question. Si ce n'est pas le cas, la page est envoyée vers un outil plus puissant. Ce test est gratuit, déterministe, et ne nécessite aucun appel à l'IA.

LES AUTRES TESTS DE LA CASCADE

Les autres briques du pipeline (analyse des questions, récupération, génération) possèdent leurs propres tests. Par exemple, la brique de génération peut détecter que la réponse de l'IA ne correspond pas à la question posée, et déclencher une ré-analyse de la page. C'est le filet de sécurité ultime pour les cas que les tests déterministes n'ont pas attrapés en amont.

UN EXEMPLE CONCRET : L'ARTICLE ATTENTION

Prenons l'article Attention (Vaswani et al. 2017) comme exemple. Voici ce que donne page_df après une exécution adaptative typique, où la cascade a détecté la page 6 (Tableau 1, « Longueurs de chemin maximales », détecté par le test 2 de l'empreinte des tableaux aplatis) et la page 3 (Figure 1, détectée par le signal de densité de caractères au test 1 et le signal de figure opaque au test 2) :

pagenum  charcount  imagecount  parsingmethod  context_structured
6          1250        0            azure_layout    True
3          1827        1            vision_gpt4o    True

La page 6 a été analysée avec Azure Layout car le test 2 a détecté un tableau aplati. La page 3 a été analysée avec un modèle de vision par IA car le test 1 a détecté une densité de caractères faible et une image, puis le test 2 a confirmé la présence d'une figure opaque. Les autres pages sont restées sur PyMuPDF.

COMMENT UTILISER CE SYSTÈME ?

Le compagnon exécutable de cet article permet de tester les vérifications bon marché soi-même. Vous pouvez appeler preparsesignals sur chaque page de l'article Attention, imprimer les drapeaux par page (charcount, imagecount, l'empreinte du tableau aplati sur line_df), et observer quelles pages sont routées vers un outil plus puissant avant de dépenser un seul dollar. Sur GitHub : doc-intel/notebooks-vol1.

EN RÉSUMÉ : NE PAYEZ QUE POUR CE DONT VOUS AVEZ BESOIN

Le parsing adaptatif change la donne pour l'analyse de documents. Au lieu de payer pour une qualité maximale sur tout un document, ou de se contenter d'une qualité minimale partout, vous ne payez que pour la qualité dont vous avez besoin, page par page. Résultat : des économies massives, une analyse plus rapide, et des réponses plus précises.

Cette méthode est particulièrement utile pour les entreprises qui traitent des milliers de documents chaque mois. Au lieu de dépenser des fortunes en outils d'analyse profonde, elles peuvent commencer par des outils basiques et n'activer les outils puissants que lorsque c'est nécessaire. Dans un monde où 90 % des pages analysées ne sont jamais utilisées, cette approche est tout simplement révolutionnaire.