Voir pdf-to-md sur GitHub →
Tout pipeline RAG et tout corpus d'entraînement de LLM commence par la même étape ingrate : transformer des documents — surtout des PDF — en texte propre et structuré qu'un modèle peut réellement exploiter. Le markdown s'est imposé comme format cible de fait, parce qu'il préserve les titres, les tableaux et l'ordre de lecture tout en restant assez léger pour être découpé, vectorisé ou injecté tel quel dans un entraînement.
Firecrawl a récemment mis en open source pdf-inspector, le moteur Rust derrière sa nouvelle pile de parsing Fire-PDF, avec une promesse qui a retenu mon attention : une conversion en markdown en quelques millisecondes, sans aucun modèle de ML. Comme Docling — le parseur de documents d'IBM Research, aujourd'hui hébergé par la LF AI & Data Foundation — est depuis un moment ma référence open source pour la conversion PDF vers markdown, j'ai construit une petite application pour faire tourner les deux côte à côte sur les mêmes documents et comparer les résultats.
L'application de comparaison
pdf-to-md est une application Next.js qui prend un ou plusieurs PDF — fichiers individuels, dossier entier, ou glisser-déposer — et convertit chacun d'eux avec les deux moteurs en parallèle : Docling via sa CLI Python, pdf-inspector via ses bindings Node (@firecrawl/pdf-inspector). Pour que la comparaison reste équitable côté Docling, les PDF multiples sont regroupés en une seule invocation, afin d'amortir le coût de chargement des modèles au lieu de le payer pour chaque document.
Chaque exécution produit deux fichiers markdown par PDF plus un manifeste JSON qui enregistre les temps de traitement et les tailles de sortie, et les résultats s'affichent dans un tableau de bord qui montre les deux conversions côte à côte, avec la classification du PDF et des statistiques de contenu. C'est cette dernière partie qui rend immédiatement visibles les différences décrites ci-dessous : on voit ce que chaque moteur a conservé — et ce qu'il a perdu.
Deux philosophies très différentes
Les deux outils abordent le même problème de manières radicalement opposées.
pdf-inspector est écrit en Rust pur avec une seule dépendance (lopdf) et, délibérément, aucun modèle de ML. Il fonctionne en deux étapes : il classifie d'abord chaque PDF en échantillonnant sa structure interne — encodages de polices, opérateurs de texte, couverture d'images — et le range dans l'une des catégories texte, scanné, image ou mixte, en 10 à 50 ms environ. Puis, pour les pages textuelles, il extrait le texte avec sa position et le convertit en markdown : titres, listes, blocs de code, tableaux, ordre de lecture multi-colonnes, et même prise en charge des écritures de droite à gauche. Il est distribué avec des bindings Rust, Python, Node.js et WebAssembly, sous licence MIT.
Docling prend le chemin inverse : il exécute un pipeline de ML complet — modèles d'analyse de mise en page, TableFormer pour la structure des tableaux, OCR optionnel — et construit une représentation riche, le DoclingDocument, qui capture la mise en page, l'ordre de lecture, les cellules des tableaux, la position des formules et l'emplacement des images, avant d'exporter en markdown, HTML ou JSON. Il s'intègre nativement à LangChain, LlamaIndex et Haystack, ce qui explique qu'il soit devenu un choix par défaut pour les pipelines RAG en production.
Vitesse : pdf-inspector gagne, et de loin
C'est toute la raison d'être de pdf-inspector. Dans mes tests, il convertit un PDF textuel typique en markdown en une fraction de seconde — le benchmark de Firecrawl annonce une médiane de 0,47 seconde pour un corpus de 200 documents, et leur pipeline hébergé revendique environ 0,002 s par page. Sans modèle à charger et sans GPU, il tourne partout, y compris dans le navigateur via WASM.
Docling, à l'inverse, paie le prix de son pipeline de ML sur chaque document : chargement des modèles, inférence de mise en page, reconnaissance de la structure des tableaux. Sur un ordinateur portable sans GPU, un seul article scientifique peut prendre de quelques secondes à quelques dizaines de secondes. Pour une conversion ponctuelle, c'est acceptable ; à l'échelle d'un corpus — des milliers d'articles pour un index RAG ou un jeu d'entraînement — la différence se compte en heures contre minutes.
L'intuition de Firecrawl, c'est qu'une grande partie des PDF en circulation sont textuels et n'ont tout simplement pas besoin d'OCR ni d'analyse neuronale de mise en page. Pour ceux-là, un parseur structurel rapide fait 90 % du travail pour une fraction infime du coût.
Le défaut qui compte : les figures
C'est ici que la comparaison a cessé d'être serrée pour mon cas d'usage.
La version open source de pdf-inspector n'extrait pas les images. Il détecte qu'une image est présente — les XObjects d'images apparaissent dans sa classification des pages — mais les images elles-mêmes ne sortent jamais du PDF. Impossible de récupérer les figures sous forme de fichiers, et encore moins de les décrire.
Pour les articles scientifiques, ce n'est pas un détail. Les figures d'un article portent souvent le résultat central : le schéma d'architecture, la courbe d'ablation, le tableau de benchmark rendu sous forme d'image. Une conversion en markdown qui perd silencieusement toutes les figures produit un texte qui semble complet mais auquel il manque une grande partie de la substance — et un système RAG construit dessus répondra avec assurance tout en étant aveugle à la preuve de la figure 3.
Le plus frustrant, c'est que Firecrawl sait le faire — sur firecrawl.dev, leur endpoint /parse combine pdf-inspector avec des modèles maison d'OCR et de mise en page qui gèrent les pages scannées, les formules (exportées en LaTeX) et les images. Mais cette partie de la pile reste derrière leur API. La version open source, c'est le cœur structurel rapide, pas le pipeline complet.
Docling gère les figures de bout en bout, entièrement en open source. Avec generate_picture_images=True, il extrait chaque figure sous forme de fichier image, conserve sa position et sa légende dans la structure du document, et peut aller un cran plus loin : son pipeline d'enrichissement fait passer un modèle vision-langage — SmolVLM, Granite Vision, ou n'importe quel endpoint VLM distant — sur chaque image pour en générer une description textuelle (do_picture_description=True). Pour du RAG sur la littérature scientifique, les figures deviennent ainsi du texte interrogeable au lieu de trous dans le document.
Une limite pratique rencontrée en chemin : Docling stocke ces annotations VLM dans l'objet document, mais ne les insère pas automatiquement dans l'export markdown — il faut les sérialiser soi-même (c'est un problème connu).
Ce que je retiens de la comparaison
| pdf-inspector (open source) | Docling | |
|---|---|---|
| Vitesse | Quelques millisecondes par document, sans GPU | Quelques secondes par document, accéléré par GPU |
| Dépendances | Rust pur, aucun modèle de ML | Pipeline de ML complet (mise en page, tableaux, OCR) |
| Tableaux | Détection heuristique et par rectangles | TableFormer (structure apprise) |
| PDF scannés | Classification seule — renvoie vers un OCR externe | OCR intégré |
| Figures | Détectées mais non extraites | Extraites + descriptions par VLM |
| Idéal pour | Le tri rapide et les PDF textuels à grande échelle | Les documents scientifiques riches en figures |
Les deux outils sont moins des concurrents que des compléments, et c'est ainsi que je les déploierais réellement :
- Utiliser pdf-inspector comme porte d'entrée. Son étape de classification est si rapide qu'elle est quasi gratuite — passer chaque PDF entrant dedans et le laisser router le document.
- Lui confier la conversion complète des documents purement textuels. Contrats, rapports, documentation : des millisecondes au lieu de secondes, à qualité pratique égale.
- Envoyer tout ce qui contient des figures ou des scans vers Docling, avec l'extraction d'images et les descriptions VLM activées, pour que le contenu visuel finisse lui aussi dans le corpus.
Pour les données d'entraînement et le RAG sur la littérature scientifique en particulier, Docling reste mon choix : la complétude l'emporte sur la vitesse quand les figures sont le contenu.
La vue d'ensemble
La conversion PDF vers markdown est devenue l'un des coins les plus actifs de l'outillage IA open source, précisément parce que tous ceux qui construisent des pipelines de RAG ou d'entraînement se heurtent à ce mur. Au-delà de ces deux outils, Marker offre un bon équilibre vitesse/qualité, MinerU excelle sur les mises en page complexes et les langues CJK, et olmOCR cible les documents scannés. Le fait que Firecrawl mette en open source son cœur Rust s'inscrit dans une tendance plus large : la couche de parsing rapide et déterministe devient une commodité, tandis que la partie différenciante (et monétisée) est la couche neuronale au-dessus — OCR, compréhension de la mise en page et traitement des images.
C'est-à-dire exactement la couche dont les documents scientifiques ont le plus besoin. Tant que cet écart ne se comble pas côté open source, mon pipeline reste hybride : pdf-inspector pour la vitesse, Docling pour tout ce qui contient une figure.
Liens
- pdf-inspector sur GitHub — bibliothèque Rust sous licence MIT
- L'annonce de Firecrawl /parse — le pipeline hébergé avec prise en charge des images
- Docling — documentation, dont l'enrichissement des images
- Rapport technique de Docling (arXiv)
- pdf-to-md, mon application de comparaison, sur GitHub