Extraire un PDF avec l'IA open-source : quel outil ?

Un client m'a un jour envoyé 4 000 PDF de factures fournisseurs. Certains sortaient d'un logiciel comptable, d'autres avaient été scannés de travers, quelques-uns photographiés au téléphone. Il voulait un tableur. Mon premier script avec une librairie d'extraction classique récupérait proprement un tiers des fichiers. Le reste ressortait vide ou en bouillie.

Lire un PDF semble trivial. Ça ne l'est pas, parce qu'un PDF n'est pas un document structuré. C'est une liste d'instructions de dessin : "place ce caractère à ces coordonnées, trace ce trait ici". Il n'existe ni paragraphe, ni tableau, ni ordre de lecture. Juste des glyphes posés sur une page.

La reconnaissance de PDF par IA consiste à reconstruire cette structure perdue : retrouver le texte, l'ordre de lecture, les titres, les tableaux et les formules, y compris quand le PDF n'est qu'une image scannée. Et en 2026, les meilleurs outils pour le faire sont open-source et tournent en local.

Deux familles de PDF, deux problèmes

Avant de choisir un outil, il faut savoir ce qu'on a entre les mains.

Un PDF natif est généré par un logiciel (Word, LaTeX, un ERP). Le texte est présent dans le fichier, encodé. On peut le sélectionner à la souris. Le défi est de le remettre dans l'ordre et de reconstruire les tableaux.

Un PDF scanné ne contient qu'une image par page. Aucun caractère n'existe dans le fichier. Il faut de l'OCR (Optical Character Recognition) pour transformer les pixels en texte, ce qui relève de la reconnaissance d'images par deep learning.

Un test rapide permet de trier un lot de fichiers :

import pymupdf  # pip install pymupdf
 
def is_scanned(path: str) -> bool:
    doc = pymupdf.open(path)
    text = "".join(page.get_text() for page in doc)
    # Moins de 50 caractères par page en moyenne : probablement un scan
    return len(text.strip()) < 50 * len(doc)
 
print(is_scanned("facture.pdf"))

Sur mes 4 000 factures, ce test a coupé le lot en deux. Ça a changé toute la stratégie.

Le panorama des outils open-source

Les licences ne sont pas un détail. Marker et MinerU sont excellents, mais leur licence pose question pour un produit commercial fermé. Vérifiez avant de les intégrer. Docling, sous MIT, est le choix le plus serein pour une entreprise.

Niveau 1 : extraire un PDF natif sans IA

Si le texte est déjà dans le fichier, pas besoin de réseau de neurones. pdfplumber lit le texte et détecte les tableaux à partir des traits dessinés.

pip install pdfplumber

import pdfplumber
 
with pdfplumber.open("rapport.pdf") as pdf:
    for i, page in enumerate(pdf.pages, start=1):
        print(f"--- Page {i} ---")
        print(page.extract_text())
 
        for table in page.extract_tables():
            for row in table:
                print(" | ".join(cell or "" for cell in row))

Ça fonctionne très bien sur des documents simples. Ça casse dès que la mise en page se complique : deux colonnes lues ligne par ligne, tableaux sans bordures fusionnés en un bloc, en-têtes et pieds de page mélangés au contenu. C'est là que l'IA devient utile.

Niveau 2 : rendre un scan cherchable avec OCRmyPDF

Pour un scan, la première étape est souvent d'ajouter une couche de texte invisible sous l'image. Le PDF reste visuellement identique, mais devient sélectionnable et indexable. OCRmyPDF fait exactement ça en s'appuyant sur Tesseract.

# Debian / Ubuntu
sudo apt install ocrmypdf tesseract-ocr-fra
 
# Redresse les pages, nettoie le bruit, OCR en français
ocrmypdf -l fra --deskew --clean scan.pdf scan_ocr.pdf

Le paramètre -l fra est indispensable pour du français : sans lui, les accents ressortent en caractères parasites. --deskew corrige les pages scannées de travers, ce qui améliore nettement la reconnaissance.

C'est cette brique qui fait tourner Paperless-ngx pour archiver ses documents papier. Pour de l'archivage et de la recherche plein texte, elle suffit largement. Pour extraire des données structurées d'un tableau, elle ne suffit pas : Tesseract lit des lignes de texte, pas des cellules.

Niveau 3 : comprendre la mise en page avec Docling

Docling est le projet que je recommande par défaut. Développé par IBM Research et confié à la Linux Foundation, il enchaîne plusieurs modèles : un modèle de détection de mise en page qui repère titres, paragraphes, figures et tableaux, un modèle dédié à la structure des tableaux, et de l'OCR quand la page est un scan.

pip install docling

from docling.document_converter import DocumentConverter
 
converter = DocumentConverter()
result = converter.convert("rapport.pdf")
 
markdown = result.document.export_to_markdown()
with open("rapport.md", "w", encoding="utf-8") as f:
    f.write(markdown)

Le premier lancement télécharge les modèles, quelques centaines de mégaoctets. Ensuite, tout tourne en local, sur CPU ou GPU.

La sortie est un Markdown propre : titres en ##, tableaux en syntaxe Markdown, colonnes remises dans l'ordre de lecture. Pour un pipeline de données, l'export JSON est plus utile, car il garde la page et la position de chaque élément.

from docling.document_converter import DocumentConverter
 
result = DocumentConverter().convert("facture.pdf")
 
for table in result.document.tables:
    df = table.export_to_dataframe()  # nécessite pandas
    print(df.head())

Sur mes factures natives, Docling récupérait les lignes de produits là où pdfplumber fusionnait tout. Sur une page de deux colonnes avec un tableau au milieu, la différence est spectaculaire.

Docling expose aussi une CLI pratique pour traiter un dossier entier :

docling ./factures --to md --output ./sortie

Marker et MinerU : quand Docling ne suffit pas

Marker vise le même objectif : PDF vers Markdown, JSON ou HTML. Il excelle sur les livres, les documents techniques et les formules mathématiques, converties en LaTeX.

pip install marker-pdf
marker_single rapport.pdf --output_dir ./sortie

Il propose une option qui fait relire les passages difficiles par un LLM, au prix de la vitesse et, selon le modèle choisi, de la confidentialité.

MinerU, issu du laboratoire OpenDataLab, cible les articles scientifiques : formules, références, mises en page académiques complexes. Si vous traitez des publications de recherche en masse, il mérite un test comparatif.

Mon approche : je commence avec Docling, et je ne teste Marker ou MinerU que sur les documents où il échoue. Rarement l'inverse.

Niveau 4 : un modèle de vision local

Certains documents résistent à tous les pipelines : formulaires remplis à la main, factures photographiées, mises en page sans aucune logique. Pour ceux-là, on peut confier la page entière à un modèle de vision-langage (VLM) qui la "regarde" comme un humain.

Ollama fait tourner ces modèles en local. Qwen2.5-VL est l'un des meilleurs en open-weights pour lire des documents.

ollama pull qwen2.5vl:7b
pip install ollama pymupdf

import json
import ollama
import pymupdf
 
PROMPT = """Extrais de cette facture : fournisseur, numéro, date (AAAA-MM-JJ),
total HT et total TTC. Réponds uniquement en JSON."""
 
doc = pymupdf.open("facture_scannee.pdf")
page = doc[0]
page.get_pixmap(dpi=200).save("page.png")
 
response = ollama.chat(
    model="qwen2.5vl:7b",
    messages=[{"role": "user", "content": PROMPT, "images": ["page.png"]}],
    format="json",
)
 
data = json.loads(response["message"]["content"])
print(data)

{'fournisseur': 'Bureau Pro SARL', 'numero': 'F-2026-0412', 'date': '2026-03-14', 'total_ht': 412.5, 'total_ttc': 495.0}

Le gain est énorme : plus de règles, plus de parsing. On demande ce qu'on veut, et le modèle comprend la sémantique ("total TTC", même s'il est écrit "Net à payer"). Le principe est le même que pour appeler un LLM depuis une application, sauf qu'ici rien ne sort de votre machine.

Le prix à payer est réel. Il faut un GPU avec au moins 8 Go de VRAM pour un débit correct. Chaque page prend plusieurs secondes. Et surtout, un VLM peut halluciner : inventer un chiffre plausible là où un OCR classique aurait laissé un blanc. Pour des montants financiers, je valide toujours la cohérence (HT + TVA = TTC) avant d'accepter un résultat.

Le pipeline qui fonctionne en production

Pour mes 4 000 factures, la solution finale n'était pas un outil unique, mais une cascade :

PDF entrant
  → texte natif présent ?
      oui → Docling (rapide, sans OCR)
      non → Docling avec OCR
  → champs obligatoires trouvés et cohérents ?
      oui → validé
      non → Qwen2.5-VL sur la page
  → toujours incohérent ?
      → file de vérification manuelle

Résultat : environ 85 % traités par Docling seul, 12 % rattrapés par le modèle de vision, 3 % vérifiés à la main. Le coût GPU reste faible parce que le modèle lourd ne touche que les cas difficiles.

Ce schéma vaut aussi pour le RAG. Si vous indexez des PDF pour qu'un assistant IA réponde à des questions dessus, la qualité de l'extraction détermine tout le reste. Un tableau mal lu donne des réponses fausses, quelle que soit la qualité du LLM derrière. Exporter en Markdown avec Docling avant de découper en morceaux améliore nettement la pertinence des réponses.

Pourquoi l'open-source et le local comptent ici

Les PDF qu'on veut automatiser sont rarement anodins : factures, contrats, bulletins de paie, dossiers médicaux. Les envoyer à une API cloud, c'est transférer des données personnelles à un sous-traitant, avec tout ce que le RGPD impose face aux traitements par IA : base légale, registre, localisation des serveurs.

Un pipeline Docling + Ollama sur votre propre serveur évite la question. Les fichiers ne quittent jamais votre infrastructure, le coût par page est nul une fois le matériel en place, et vous n'êtes pas exposé au changement de tarif ou à la fermeture d'une API.

Les API commerciales gardent un avantage de précision sur les documents les plus difficiles. L'écart se réduit chaque année.

Quel outil choisir ? Docling dans la grande majorité des cas : licence MIT, local, bon sur les tableaux et les colonnes. OCRmyPDF si vous voulez juste rendre des scans cherchables. Un modèle de vision comme Qwen2.5-VL en dernier recours, pour les pages que rien d'autre ne sait lire. Ne cherchez pas l'outil parfait. Construisez une cascade, mesurez où elle échoue, et réservez la puissance de calcul aux documents qui la méritent.