Tu donnes un Word de 12 pages à Mistral, ChatGPT ou à Claude, et la réponse part de travers. Un titre raté, deux sections mélangées, la moitié d’un tableau qui disparaît. Tu convertis le même document en Markdown, tu recolles, et l’IA suit ton plan à la lettre. Ce n’est pas de la chance 😉. Le format que tu donnes à un modèle LLM compte presque autant que ce que tu lui demandes.
Et ça va bien au-delà du simple prompt !
Ce que l’IA « voit » quand tu lui files un Word
Un fichier Word, ce n’est pas du texte. Un .docx est une archive ZIP qui contient plusieurs fichiers XML : le contenu, les styles, les métadonnées. Ouvre-en un avec un utilitaire d’archive, tu verras. Un titre en gras, une puce, un tableau : tout ça est encodé dans des balises verbeuses, au format OOXML.
Un modèle de langage ne « lit » pas un Word comme toi. Selon l’outil utilisé, soit il reçoit du texte brut aplati (la hiérarchie saute, plus de titres, plus de niveaux), soit il doit se dépatouiller avec la structure XML. Dans les deux cas, il y a du bruit. Et le bruit, dans un contexte limité en tokens, coûte de la place et fait naître des erreurs.
Pourquoi le Markdown est devenu la langue du code ?
Le Markdown n’a pas été inventé pour l’IA. John Gruber l’a créé en 2004, avec un objectif simple : écrire du texte formaté qui reste lisible tel quel, sans éditeur complexe. Le vrai tournant arrive en 2009, quand GitHub en fait le format par défaut des fichiers README. Des millions de dépôts de code adoptent le Markdown pour leur documentation. Stack Overflow, Reddit, les wikis techniques suivent.
Quand les grands modèles de langage s’entraînent sur des montagnes de texte pris sur le web, une grande partie de ce qu’ils avalent est déjà en Markdown. Ils n’ont pas appris de règle : ils ont vu ce format des millions de fois, et c’est devenu un réflexe. Leur donner du Markdown en entrée, c’est leur parler dans leur langue plutôt que de leur faire traduire un dialecte bureautique.
Ce qui rend le Markdown facile à lire pour une IA
Le Markdown coche ce qui compte pour un modèle.
- Un titre, c’est
#. - Un sous-titre,
##. - Une liste, un tiret.
- Un lien,
[texte](url).
Pas de balise fermante, pas de métadonnée cachée. Le modèle voit la hiérarchie directement, sans avoir à la deviner. Les modèles parlent Markdown de naissance. C’est le résultat direct de leur entraînement : ils le recrachent souvent tout seuls, même quand tu ne demandes rien de particulier.
D’ailleurs, lorsque tu développe une application avec l’IA, elle va générer des fichiers Markdown, CLAUDE.md pour Claude Code, GEMINI.md, etc.
Combien de tokens ça économise vraiment ?
Un mot en gras en HTML, c’est <strong>important</strong> : une dizaine de tokens. En Markdown, **important** en prend quatre. Même information, une fraction des caractères. Sur un document de plusieurs pages, l’écart se chiffre en centaines, voire en milliers de tokens.
Cloudflare a mesuré l’écart sur son propre blog, la page qui annonce leur fonctionnalité Markdown for Agents pèse 16 180 tokens en HTML, contre 3 150 en Markdown, une réduction d’environ 80 %. Prends ce chiffre comme un ordre de grandeur, pas une règle universelle : il varie selon les documents. Moins de tokens perdus dans la mise en forme, c’est plus de place pour ton contenu, et une facture API plus légère si tu passes par l’API.
Markdown et RAG : la base d’une bonne base de connaissances
Si tu construis une base de connaissances (un chatbot sur ta documentation interne, une recherche sémantique sur tes articles), tu découpes tes documents en morceaux avant de les indexer. C’est le principe du RAG (Retrieval-Augmented Generation). Découpe un Word mal extrait, tu obtiens des chunks bancals, coupés en plein milieu d’une idée. Découpe un Markdown propre, tu coupes sur les titres, et chaque morceau reste cohérent.
La qualité de tes réponses dépend directement de la qualité de ce découpage. J’ai vu des pipelines RAG passer de médiocres à corrects juste en changeant l’étape de conversion, sans toucher au reste. Un outil comme NotebookLM, qui excelle à analyser des documents entiers, profite du même principe : plus tes sources sont structurées, mieux il en tire quelque chose.
Markdown et prise de notes perso : le cas Obsidian
Ce principe ne s’arrête pas aux pipelines techniques. Si tu tiens tes notes de projet, ta documentation perso, ta base de connaissances au quotidien, le Markdown est devenu le standard de fait. Obsidian en est le meilleur exemple.
Obsidian stocke chaque note comme un simple fichier .md sur ton disque. Pas de base de données propriétaire, pas de format fermé : tu peux ouvrir tes notes dans n’importe quel éditeur de texte, les versionner avec Git, les synchroniser comme tu veux. Cette portabilité change directement ta façon d’utiliser l’IA : tu colles une note Obsidian entière dans Claude ou ChatGPT sans conversion, sans perte de structure, et le modèle en tire le plan immédiatement. C’est le même réflexe que choisir le bon agent pour son second cerveau : la structure de tes données compte autant que l’outil qui les manipule.
Markdown vs Word vs PDF vs HTML : le comparatif
| Critère | Markdown | Word (.docx) | HTML | |
|---|---|---|---|---|
| Lisible par l’IA sans bruit | Oui | Non (XML/OOXML) | Non (souvent OCR) | Partiel (balises) |
| Économie de tokens | Élevée | Faible | Faible | Faible |
| Structure explicite (titres, listes) | Native | Cachée dans le style | Absente (mise en page figée) | Native mais verbeuse |
| Portable / durable | Oui (texte brut) | Dépend du logiciel | Oui pour l’impression, non pour l’édition | Oui, mais nécessite un rendu |
| Idéal pour RAG / chunking | Oui | Non sans conversion | Non sans OCR | Moyen |
La limite à connaître à propos du Markdown IA
Le Markdown est génial pour transmettre du sens à une machine. Ce n’est pas fait pour reproduire une mise en page parfaite. Les tableaux fusionnés, les zones de texte, les colonnes, les images placées au millimètre : tout ça sera simplifié ou perdu. Et il n’existe pas un unique standard Markdown : GitHub Flavored Markdown, CommonMark, les extensions d’Obsidian ajoutent chacune leurs variantes, généralement compatibles entre elles mais pas toujours à 100 %.
Et c’est très bien comme ça 😊. Quand tu convertis un doc pour une IA, tu ne cherches pas à préserver la police et les marges. Tu cherches à préserver la structure et le contenu. Le Markdown fait exactement ce compromis : il jette la déco, il garde le squelette. Et c’est le squelette qui intéresse le modèle.
Questions fréquentes
Le Markdown remplace-t-il le Word pour rédiger ?
Pas forcément pour la rédaction finale destinée à l’impression ou à un client externe. Mais dès que le document est destiné à être lu, indexé ou retravaillé par une IA, le Markdown prend l’avantage.
Faut-il savoir coder pour écrire en Markdown ?
Non. Quelques symboles (#, **, -) suffisent, et n’importe quel éditeur de texte fait l’affaire.
Le Markdown fonctionne-t-il avec toutes les IA ?
Oui. Mistral, ChatGPT, Claude, Gemini et la quasi-totalité des LLM le lisent et l’écrivent nativement. C’est même leur format de sortie par défaut.
J’ai déjà des Word, dois-je tout reconvertir ?
Pas tout, seulement ce que tu comptes réinjecter dans une IA ou une base de connaissances. Convertir un Word en Markdown prend deux minutes une fois le processus en place.
Au fond, la question à se poser avant d’envoyer un document à une IA est simple : ce fichier est-il vraiment destiné à un humain, ou à une machine ? La réponse dicte le format à choisir et change, pour de bon, la moitié de tes habitudes de travail.
