PDF en Markdown pour les LLM : préparer des documents pour ChatGPT, Claude et RAG
Collez un PDF dans un modèle de chat et, en général, ça marche, au sens où le modèle répond. En dessous, le bruit de mise en page du PDF — lignes coupées, en-têtes et pieds de page répétés, caprices d'ordre de lecture — devient des tokens que le modèle doit traverser avant d'atteindre le contenu.
Convertir d'abord en Markdown supprime la majeure partie de ce bruit à la source. Cet article explique d'où vient le bruit des PDF, ce qu'il coûte en tokens, pourquoi les paragraphes sur une seule ligne comptent pour le découpage et les diffs, et comment le mode de sortie optimisé pour les LLM de ce site est conçu exactement pour ce flux de travail.
Pourquoi les LLM s'étouffent sur les PDF bruts
Quand un outil de chat accepte directement un PDF, quelque chose doit d'abord le transformer en texte, et ce quelque chose est généralement un extracteur rapide et générique. Ce qui en sort conserve les artefacts de stockage du PDF : sauts de ligne au milieu des phrases, césures issues de la justification d'origine, en-têtes et pieds de page répétés sur chaque page, et texte en colonnes entrelacé dans l'ordre de stockage.
Les modèles savent voir au-delà, c'est pourquoi l'envoi direct semble fonctionner. Mais le modèle dépense de l'attention à reconstituer des paragraphes qu'un convertisseur aurait livrés intacts, et sur les longs documents le gaspillage s'accumule : les seuls pieds de page répétés peuvent représenter des milliers de tokens de pure répétition.
Le texte structuré ancre aussi les citations du modèle. Quand vous demandez au modèle de citer la clause sur laquelle il a fondé une réponse, la numérotation des clauses et les niveaux de titres issus d'une conversion Markdown lui donnent des repères stables ; un mur de texte PDF reformaté ne lui donne rien à pointer.
Le coût caché en tokens du bruit PDF
Les tokeniseurs facturent par morceaux de texte, et le bruit PDF est fait de morceaux. Un paragraphe à retour forcé coûte les mêmes caractères mais des sauts de ligne en plus ; un pied de page répété quarante fois est un coût fixe par page, qu'il soit utile ou non ; les césures comme « conver- sion » peuvent se scinder en morceaux qui ne correspondent ni au mot ni à un sens.
Le gaspillage n'est pas qu'une question de volume, c'est aussi une question de position. Les fenêtres de contexte sont finies, et le bruit placé au début pousse le contenu vers le point de troncature. Des documents qui tiendraient largement en Markdown propre débordent parfois en dump PDF brut, et la qualité des réponses du modèle se dégrade bien avant que quoi que ce soit soit coupé.
Rien de tout cela ne transparaît dans le ton de la réponse, c'est pourquoi cela passe inaperçu. Cela se voit dans la part du document que le modèle a réellement exploitée, et sur la facture si vous payez par token via une API.
Un paragraphe, une ligne : pourquoi les retours comptent
Les outils de texte traditionnels coupent la sortie à 72 ou 80 colonnes parce que les terminaux et les pages imprimées fonctionnaient ainsi. Dans un fichier Markdown destiné à un modèle, chacune de ces coupures est une frontière de chunk potentielle dans un pipeline de récupération qui découpe sur les sauts de ligne ou la longueur des paragraphes.
Les paragraphes d'une seule ligne rendent le découpage trivial : un paragraphe est une ligne, un découpeur peut trancher sur les lignes vides, et chaque chunk contient des phrases entières. Avec du texte à retour forcé, le même pipeline doit d'abord défaire les coupures ; s'il ne le fait pas, les chunks cassent au milieu des phrases et la qualité de la récupération chute de façons difficiles à déboguer.
Les diffs ligne par ligne en tirent le même bénéfice. Quand une révision de contrat modifie une clause, un fichier à paragraphes d'une ligne montre exactement une ligne changée ; un fichier coupé peut reformater le reste du paragraphe et noyer le vrai changement dans une douzaine de blocs de diff.
Le profil compact en pratique
Le convertisseur de ce site possède un interrupteur explicite d'optimisation pour les LLM. Activé, il fait deux choses : le moteur PDF tourne dans son profil d'extraction compact, qui préfère un texte simple et resserré à une verbosité fidèle à la mise en page, et le rédacteur Markdown désactive le retour forcé pour que chaque paragraphe tienne sur une ligne.
Le profil compact est un compromis différent, pas strictement meilleur. Les modes fidèles à la mise en page reproduisent davantage la structure visuelle de la page, ce que veut un lecteur humain qui convertit pour éditer. Le mode compact enlève cette décoration pour ne garder que contenu et structure, ce que veut un flux de tokens.
L'interrupteur n'affecte que la sortie Markdown, et c'est délibéré : les destinations HTML, RST et LaTeX sont consommées par des moteurs de rendu qui recoupent de toute façon. Si votre destination est un modèle, restez en Markdown avec l'interrupteur activé ; si c'est un humain, le réglage par défaut est la meilleure lecture.
Injecter du Markdown dans un pipeline RAG
La génération augmentée par récupération vit ou meurt de la qualité des chunks. Markdown donne au pipeline ce que le PDF ne pourra jamais : des frontières structurelles qui sont aussi des frontières sémantiques. Les titres marquent les sujets, donc un découpeur peut chunker par section et attacher le fil des titres comme métadonnées ; les tableaux arrivent en blocs de tableaux à barres verticales intacts qui traversent l'embedding comme des unités.
La recette pratique est volontairement ennuyeuse : convertissez chaque PDF en Markdown à paragraphes d'une ligne, découpez sur les titres avec un plafond de taille, gardez le chemin des titres avec chaque chunk, puis lancez l'embedding. Chaque étape tient en une ligne contre un fichier Markdown bien formé, et relève de l'heuristique fragile contre un PDF brut.
La conversion par lots compte ici plus qu'en usage interactif. Une base de connaissances, ce sont des dizaines ou des centaines de documents, et cet outil les convertit en série dans le navigateur puis empaquette les résultats à télécharger, sans étape d'envoi au milieu — ce qui compte d'autant plus quand les documents sont du genre que vous ne pouvez pas envoyer.
Pourquoi la conversion doit se faire sur votre machine
Les documents que les gens donnent aux LLM sont disproportionnellement sensibles : contrats, comptes rendus de conseil, recherches inédites, dossiers clients. Les confier à un convertisseur cloud ajoute au flux de données un tiers dont vous n'avez pas écrit la politique de conservation, et la commodité du glisser-déposer masque qu'il s'agit d'un envoi.
Ce convertisseur exécute le moteur d'analyse PDF en WebAssembly dans l'onglet de votre navigateur. Le fichier est lu avec l'API de fichiers du navigateur, traité en mémoire et réécrit localement ; il n'y a aucun composant serveur dans le chemin de conversion. Vous pouvez charger la page, couper le réseau, et la conversion continue de fonctionner.
Ce choix de conception est le même qui rend l'outil adapté spécifiquement au flux de travail LLM : le but même de préparer un document pour un modèle est souvent de garder la maîtrise de qui le voit. Un convertisseur qui enverrait les fichiers saperait cet objectif un pas plus tôt.
Les limites à garder en tête
Les PDF scannés n'ont pas de couche texte, et aucun profil de conversion n'y changera rien. Si la source est un scan, passez-la d'abord dans un logiciel OCR et convertissez la sortie de l'OCR ; le convertisseur signale les pages sans texte extractible au lieu de renvoyer silencieusement une coquille vide.
Les tableaux complexes arrivent simplifiés. Les tableaux à barres verticales GFM ne savent pas exprimer les cellules fusionnées ni les en-têtes multiniveaux, donc les modèles voient une version aplatie. Pour les sources très tabulaires où le tableau est l'essentiel, vérifiez quelques lignes contre l'original avant de faire confiance aux réponses en aval.
Et l'interrupteur n'est pas un curseur de qualité pour l'extraction elle-même : le mode compact change la fidélité de restitution de la mise en page, pas l'exactitude de la reconnaissance du texte. Si une conversion produit des caractères illisibles, le problème vient de l'encodage de la source, pas du profil.