Quand l’équipe AutoGen de Microsoft a publié MarkItDown en novembre 2024, la bibliothèque a atteint plus de 90 000 étoiles GitHub en quelques mois. Pas parce qu’elle fait quelque chose de neuf : parce qu’elle s’attaque à l’étape que tout le monde reportait. Convertir des PDF, Word et Excel en Markdown propre avant de les indexer. La plupart des guides RAG démarrent par le choix du vector store ou du modèle d’embedding. Mais si vos documents entrent mal découpés dans le pipeline, vos réponses seront mauvaises, peu importe le LLM que vous utilisez.
Ce guide couvre les étapes dans l’ordre où elles ont un impact réel : parsing, nettoyage, chunking, embedding, stockage vectoriel et requête. Comptez 2 à 3 heures pour un corpus de 100 documents si vous partez de zéro. Pour 500+, il faut prévoir l’orchestration parallèle dès le départ.
Pourquoi la conversion Markdown est l’étape critique
Un PDF extrait naïvement produit un texte sans structure : les titres de colonnes de tableau se retrouvent collés aux valeurs, les notes de bas de page coupent les paragraphes, les en-têtes se répètent à chaque page. Quand votre modèle d’embedding vectorise ce bruit, il génère des vecteurs qui représentent le désordre typographique plutôt que le contenu sémantique.
Le Markdown fonctionne mieux parce que sa structure en titres (#, ##) fournit des points de découpe naturels alignés sur les frontières sémantiques. Tous les grands LLM ont été entraînés sur des quantités massives de Markdown : c’est le format qu’ils traitent le mieux nativement. Un benchmark 2026 sur GPT-4o mesurant 20 questions factuelles a confirmé que le texte PDF brut scorait systématiquement plus bas que le Markdown sur l’ensemble des dimensions testées.
Autre avantage concret : convertir une fois en Markdown, puis re-chunker sans re-parser le PDF original. Sur un corpus de 500 documents, cela évite de relancer des parseurs lourds à chaque changement de stratégie de chunking.
Choisir son parseur selon le volume et la criticité
Trois outils dominent les benchmarks 2026 sur la conversion PDF vers Markdown. Deux critères décident.
La complexité des layouts d’un côté : un corpus de rapports texte linéaires n’a pas les mêmes besoins qu’un corpus de bilans financiers avec des tableaux à cinq niveaux d’imbrication. Votre tolérance au coût de l’autre : la différence entre une solution entièrement open source à zéro euro et un service cloud facturé à la page peut représenter plusieurs milliers d’euros par mois sur des volumes importants.
MarkItDown (Microsoft, MIT) affiche 82% de F1 sur les benchmarks indépendants, 100 pages en 12 secondes, zéro GPU requis. Commande en une ligne : markitdown rapport.pdf -o rapport.md. Fonctionne bien sur des documents texte majoritairement linéaires : emails, notes, rapports narratifs. Licence MIT sans restriction de revenus. Pour la plupart des équipes qui démarrent, c’est le point d’entrée logique.
Docling (IBM, MIT) monte à 88% de F1, GPU optionnel mais recommandé pour les volumes importants. Meilleure précision sur les tableaux complexes et les mises en page multi-colonnes. À préférer dès que votre corpus contient des documents financiers, des contrats avec annexes chiffrées ou des rapports techniques tabulaires.
LlamaParse (LlamaIndex, commercial) atteint des performances de pointe sur les documents structurés, cloud uniquement, à partir de 0,003 dollar par page en mode standard (jusqu’à 0,056 dollar en mode Agentic Plus). C’est le plafond de précision actuel sur les documents structurés. Pertinent quand une erreur d’extraction a un coût réel (contrats légaux, données médicales) et que vous traitez des volumes modérés plutôt que des dizaines de milliers de pages par mois.
Avant de décider, testez votre parseur sur 10 documents représentatifs de votre corpus. Extrayez le Markdown produit et lisez-le à l’œil : les tableaux sont-ils préservés ? Les titres de sections sont-ils détectés ?
Pour un corpus homogène et textuel (rapports PDF narratifs, notes Word, emails exportés), MarkItDown est suffisant. Pour un corpus hétérogène avec des documents techniques complexes (appels d’offres en multi-colonnes, bilans financiers avec tableaux imbriqués), passez à Docling. LlamaParse est justifié uniquement si le budget et la criticité le permettent : son avantage principal est la gestion des tableaux croisés complexes et des fichiers mal structurés que les parseurs open source échouent à traiter proprement.
Un détail que les guides RAG ne mentionnent pas souvent : la version du parseur compte. MarkItDown v0.1.6 (mai 2026) améliore significativement le rendu des fichiers Excel multi-onglets par rapport aux versions antérieures. Vérifiez votre version avec pip show markitdown. Une heure de test manuel ici évite trois semaines de débogage RAG plus tard.
Nettoyer et normaliser avant de chunker
Le Markdown brut issu d’un parseur contient du bruit résiduel : pages de garde répétées, en-têtes de navigation, listes de références bibliographiques qui polluent les chunks thématiques. Cette étape manque souvent dans les guides RAG.
Quatre opérations de nettoyage à appliquer sur chaque corpus :
- Supprimer les blocs répétitifs identifiés sur plusieurs pages (en-têtes, pieds de page, mentions légales)
- Normaliser les niveaux de titres : si le parseur a détecté des
#pour des sous-titres mineurs, remontez la hiérarchie pour avoir des##comme unités de découpe principale - Retirer les images sans légende (elles produisent des chunks vides ou des références non résolues comme
) - Traiter les tableaux mal parsés : si un tableau à 5 colonnes se retrouve aplati en une liste de valeurs, décidez si vous le conservez en texte brut ou si vous le ré-extrayez manuellement
Un script Python avec re et une logique de déduplication basée sur le hash des blocs suffit pour automatiser 80% de ce travail sur un corpus homogène.
Définir une stratégie de chunking adaptée à vos requêtes
Le chunking divise vos documents en fragments indexables. La taille et la méthode de découpe impactent directement le recall de votre système RAG. Un benchmark NVIDIA 2024 a mesuré une précision de 0,648 pour le découpage par page sur des documents paginés ; plusieurs mesures 2024-2025 indiquent un gain de recall allant jusqu’à 9% pour le chunking sémantique. Les résultats varient fortement selon les corpus.
Point de départ raisonnable : 300 à 600 tokens par chunk avec un chevauchement de 10 à 15%. Ce chevauchement garantit qu’une information à cheval sur deux chunks reste récupérable.
Le chunking récursif par caractères (LangChain RecursiveCharacterTextSplitter) découpe d’abord sur les doubles sauts de ligne, puis sur les sauts simples, puis sur les espaces. Rapide et reproductible sur du Markdown propre. Le chunking par titres Markdown découpe sur les # et ## : produit des chunks sémantiquement cohérents mais de taille variable. À préférer quand vos documents ont une structure de titres fiable.
Évitez le chunking par page brute si vous avez converti en Markdown : vous perdez le bénéfice de la structure.
Générer les embeddings et les stocker
Une fois vos chunks propres, chaque fragment est converti en vecteur flottant par un modèle d’embedding. Ce vecteur capture le sens sémantique du chunk et permet la recherche par similarité.
Pour un corpus de 100 à 1000 documents, text-embedding-3-small d’OpenAI ou text-embedding-004 de Google offrent un bon rapport coût/précision. Pour de l’auto-hébergement, bge-m3 (BAAI) couvre le multilinguisme avec de bonnes performances sur le français.
Le stockage vectoriel dépend de votre infrastructure. Chroma est une base de données vectorielle locale, zéro configuration, idéale pour le prototypage : une ligne suffit (chroma_client = chromadb.Client()). Qdrant est auto-hébergeable via Docker, avec un filtrage par métadonnées performant, bon choix pour la production sur serveur dédié. Pinecone est cloud managé avec scaling automatique, pertinent si vous ne voulez pas gérer l’infrastructure. pgvector est une extension PostgreSQL : à choisir si vous avez déjà une base Postgres et souhaitez éviter un service supplémentaire.
Stockez les métadonnées avec chaque chunk : nom du fichier source, numéro de page, titre de section parent. Ces métadonnées permettent de filtrer la recherche sur un périmètre de documents et d’afficher la source dans la réponse finale.
Tester la qualité de votre pipeline avant de passer en prod
La plupart des équipes déploient sans grille d’évaluation et découvrent les problèmes via les retours d’usage. C’est évitable avec trois mesures à faire avant d’exposer le pipeline à des utilisateurs réels.
Construisez un jeu de 20 à 30 questions de référence sur votre corpus avec les réponses attendues. Ces questions doivent couvrir les cas que vos utilisateurs poseront vraiment : factuelles précises, synthèses sur plusieurs sections, questions qui forcent le croisement d’au moins deux documents sur un même sujet. L’idéal est de les construire avec quelqu’un qui connaît le contenu et non avec le même LLM qui va produire les réponses.
Mesurez ensuite le recall à k=5 : pour chaque question, les 5 chunks retournés par la recherche vectorielle contiennent-ils l’information nécessaire ? Si le recall est inférieur à 70%, le problème vient du parsing ou du chunking, pas du LLM. Réindexer avec un modèle plus puissant n’aidera pas si les chunks d’entrée sont brisés.
Mesurez enfin la fidélité des réponses : le LLM produit-il des réponses étayées par les chunks récupérés ou hallucine-t-il des informations absentes ? Des frameworks comme RAGAS ou TruLens automatisent cette mesure avec des scores de faithfulness et d’answer relevance.
Un piège classique ici : un recall de 90% sur votre jeu de test de 20 questions peut masquer des failles systématiques sur des questions légèrement différentes. Élargissez progressivement le jeu de test en incluant des formulations alternatives des mêmes questions et des questions pour lesquelles la réponse est absente du corpus (le système doit alors répondre qu’il ne sait pas, pas inventer).
Gérer les mises à jour de corpus sans tout re-indexer
Un pipeline RAG en production reçoit de nouveaux documents régulièrement. Ré-indexer l’intégralité du corpus à chaque mise à jour est coûteux et inutile.
Versionnez par hash de contenu. Calculez un SHA-256 de chaque document source. À chaque ingestion, comparez les hashs aux entrées déjà indexées. Seuls les documents modifiés ou nouveaux passent par le pipeline complet : parsing, chunking, embedding. Les documents inchangés sont ignorés. Un corpus de 10 000 fichiers avec 5% de rotation mensuelle ne repasse que 500 fichiers par cycle d’indexation, ce qui rend les mises à jour planifiables en heures creuses sans impact sur la disponibilité du système.
Pour les suppressions, maintenez un champ source_id dans vos métadonnées vectorielles. Quand un document est retiré du corpus, filtrez par source_id et supprimez les chunks correspondants. Chroma et Qdrant gèrent la suppression par filtre de métadonnées nativement depuis leurs premières versions ; Pinecone a ajouté cette fonctionnalité dans son API v2, qui est aujourd’hui la version par défaut.
Avec cette architecture, un corpus de 500 documents avec 10% de rotation mensuelle ne nécessite qu’une fenêtre d’indexation de quelques minutes par semaine. Le recalcul des hashs sur des fichiers non modifiés prend moins d’une seconde. Aucun re-parse superflu, aucun embedding en double.
Formats hétérogènes, token cost et latence
MarkItDown gère nativement Word, Excel, PowerPoint, les images (via OCR si Tesseract est installé) et une dizaine d’autres formats. Pour les PDF scannés sans couche texte, Docling produit des résultats corrects. La conversion en Markdown réduit la consommation de tokens de 30 à 50% selon les benchmarks AI Builder Club 2026, parce que le bruit typographique n’atteint pas le LLM et que les vecteurs encodent du sens plutôt que du désordre de mise en page. Sur 10 000 pages consultées 50 fois par jour, l’économie est concrète sur la facture d’API.
Qdrant et Pinecone répondent en moins de 100 millisecondes sur 100 000 chunks, assez pour un usage temps réel.
Ouvrez votre terminal et lancez markitdown votre_document.pdf -o test.md, puis lisez le fichier produit. Structure correcte sur 10 documents de test ? Vous pouvez démarrer.
