Accueil › Glossaire › Markdown Output

Markdown Output

Le Markdown output désigne une sortie de LLM formatée en Markdown, utilisant la syntaxe standardisée de titres (#), listes, gras, italique, blocs de code et tableaux pour structurer le contenu de manière lisible à la fois par l’humain et par les machines.

Le Markdown, format par défaut des LLM

Quand vous interagissez avec ChatGPT, Claude.ai ou Gemini sans spécifier de format de sortie, le modèle répond naturellement en Markdown. Les titres sont marqués par #, le texte important est en **gras**, les listes utilisent - ou 1., et les blocs de code sont encadrés par des triple backticks. Ce n’est pas un hasard : les LLM ont été entraînés sur des corpus massifs contenant du Markdown (documentation technique, README GitHub, articles de blog, wikis) et ont appris à le produire comme format de structuration par défaut.

Les interfaces chat des principaux providers convertissent automatiquement le Markdown en HTML pour le rendu visuel. Un titre ## Section devient un <h2>, un bloc de code avec syntaxe highlighting est rendu avec coloration, et les tableaux Markdown sont affichés comme de vrais tableaux HTML. Cette conversion transparente fait du Markdown le format le plus « plug and play » pour les applications conversationnelles.

Syntaxe Markdown courante dans les sorties LLM

Avantages du Markdown output

Léger en tokens

Le Markdown est le format structuré le plus économique en tokens. Un titre Markdown (## Résultat) consomme environ 3 tokens. L’équivalent XML (<h2>Résultat</h2>) en consomme environ 7. L’équivalent JSON ("heading": "Résultat") environ 5. Sur des sorties longues (rapports, articles, analyses), cette différence s’accumule. Quand le contenu est destiné à la lecture humaine et que le coût en tokens de sortie est un facteur (rappel : $25/M tokens output sur Claude Opus 4.6), le Markdown est le choix le plus économique.

Lisible à la fois par l’humain et la machine

Le Markdown est lisible en texte brut (sans rendu) tout en étant facilement convertible en HTML, PDF, DOCX ou tout autre format. Un rapport en Markdown peut être lu directement dans un terminal, rendu dans une interface web, ou converti en document Word. Cette polyvalence est unique parmi les formats de sortie LLM.

Rendu natif dans les interfaces

Toutes les interfaces de chat LLM (ChatGPT, Claude.ai, Gemini, Perplexity) rendent le Markdown nativement. Les blocs de code ont la coloration syntaxique, les tableaux sont formatés, et les listes sont indentées correctement. Si votre application a une interface utilisateur, le Markdown est le format qui demande le moins d’effort de rendu.

Familiarité des modèles

Les LLM produisent du Markdown naturellement et avec une grande cohérence. C’est le format sur lequel ils ont été le plus exposés pendant l’entraînement (documentation, README, articles, forums). Vous n’avez pas besoin d’instructions particulières dans le prompt pour obtenir du Markdown : c’est le comportement par défaut.

Cas d’usage du Markdown output

Rapports et analyses

Le Markdown est idéal pour les sorties destinées à être lues par un humain : résumés de documents, analyses de marché, rapports techniques, études comparatives. La structure en titres et sous-titres permet de naviguer facilement dans un long document. Les tableaux Markdown rendent les comparaisons visuellement claires.

Documentation technique

La génération de documentation (READMEs, guides d’utilisation, changelogs, API docs) est un cas d’usage naturel. Le Markdown produit par le LLM peut être directement commité dans un dépôt Git, publié sur un wiki, ou intégré dans un site de documentation (MkDocs, Docusaurus, GitBook).

Contenu éditorial

Articles de blog, newsletters, publications LinkedIn, scripts vidéo : tout contenu éditorial bénéficie du Markdown. Le format permet au modèle de structurer son contenu avec des titres, des listes et du formatage sans la lourdeur du HTML ou la rigidité du JSON. Le contenu peut ensuite être copié-collé dans un CMS (WordPress, Ghost, Notion) qui convertit automatiquement le Markdown.

Explications avec code

Le Markdown excelle pour les réponses qui mélangent explications textuelles et blocs de code. Un tutoriel qui alterne paragraphes explicatifs et snippets de code est naturellement structuré en Markdown, grâce aux blocs de code fencés (```python ... ```) avec indication du langage pour la coloration syntaxique.

Markdown vs JSON vs XML

Contrôler le Markdown output

Forcer ou interdire le Markdown

Pour forcer une sortie en Markdown riche (avec titres, tableaux, listes), précisez-le dans le system prompt : « Structurez votre réponse en Markdown avec des titres ##, des listes à puces, et des tableaux quand c’est pertinent. » À l’inverse, pour interdire le Markdown (quand vous voulez du texte brut sans formatage), ajoutez : « Répondez en texte brut sans aucun formatage Markdown. Pas de #, **, -, ni backticks. »

Imposer un template

Fournissez un template Markdown dans le prompt pour que le modèle le remplisse :

Remplissez ce template avec votre analyse :

## Résumé exécutif
[1-2 phrases]

## Points forts
- [point 1]
- [point 2]
- [point 3]

## Risques identifiés
| Risque | Probabilité | Impact |
|--------|------------|--------|
| [risque] | [faible/moyen/élevé] | [description] |

## Recommandation
[paragraphe]

Cette technique produit des résultats remarquablement cohérents. Le modèle remplit le template en respectant la structure, les types de contenu (listes, tableaux, paragraphes) et le niveau de détail implicitement suggéré par le format.

Extraction de données depuis le Markdown

Le parsing de Markdown pour en extraire des données structurées est moins fiable que pour le JSON ou le XML, mais reste faisable. Les bibliothèques comme markdown-it (JavaScript), mistune (Python) ou marked parsent le Markdown en AST (Abstract Syntax Tree) que vous pouvez traverser programmatiquement. Pour des cas simples (extraire les titres, les éléments de liste, les cellules de tableau), des regex suffisent.

Pièges courants

Le sur-formatage est le piège le plus fréquent. Les LLM ont tendance à structurer excessivement leurs réponses avec des titres, des listes et du gras quand ce n’est pas nécessaire. Une question simple mérite une réponse en une phrase, pas un rapport structuré en 5 sections. Pour des réponses concises, ajoutez dans le system prompt : « Répondez de manière concise. N’utilisez le Markdown (titres, listes, tableaux) que quand la complexité de la réponse le justifie. »

Les liens hallucinés sont un autre problème. Les LLM génèrent souvent des liens Markdown ([texte](url)) avec des URLs inventées qui ne mènent nulle part. Ne faites jamais confiance aux URLs générées par un LLM sans vérification. Si vous avez besoin de liens fiables, fournissez-les dans le contexte et demandez au modèle de les référencer.

L’inconsistance de formatage est aussi courante. D’une réponse à l’autre, le modèle peut utiliser des conventions Markdown différentes (tirets vs astérisques pour les listes, ATX vs Setext pour les titres, espaces variables). Si la cohérence est importante (publication automatique), fournissez un guide de style Markdown dans le system prompt.

Markdown dans les pipelines LLM

Dans les pipelines automatisés, le Markdown sert souvent de format intermédiaire entre la génération LLM et le rendu final. Le modèle produit du Markdown, qui est ensuite converti en HTML (pour le web), en PDF (pour les rapports), en DOCX (pour les documents professionnels), ou en texte brut (pour les e-mails). Des outils comme Pandoc, WeasyPrint et python-docx facilitent ces conversions. C’est le workflow classique des applications de génération de contenu.

Pour les systèmes RAG avec interface utilisateur, le Markdown est le format de sortie standard. Le modèle intègre les informations des documents récupérés dans une réponse formatée en Markdown, qui est rendue directement dans l’interface de chat. Les citations peuvent être ajoutées comme notes de bas de page Markdown ou comme liens hypertextes.

Variantes de Markdown et compatibilité

Il n’existe pas un seul standard Markdown mais plusieurs « flavors » (variantes). Les LLM produisent généralement du Markdown compatible avec GitHub Flavored Markdown (GFM), qui supporte les tableaux, les blocs de code fencés, les listes de tâches (- [x] fait, - [ ] à faire), et le strikethrough (~~texte~~). Le CommonMark est une spécification plus stricte qui sert de base à GFM.

En pratique, les différences entre les variantes importent peu pour les sorties LLM. Les éléments les plus utilisés (titres, listes, gras, code, tableaux) sont communs à toutes les variantes. Les problèmes de compatibilité surviennent surtout avec les éléments avancés : les tableaux complexes (cellules fusionnées, alignement), les notes de bas de page, et les formules mathématiques (LaTeX). Si votre application utilise un renderer Markdown spécifique, testez la compatibilité avec les sorties typiques de votre modèle.

Les formules mathématiques méritent une attention particulière. Les LLM produisent souvent des formules en notation LaTeX encadrées par $...$ (inline) ou $$...$$ (bloc). Ce format n’est pas standard en Markdown de base mais est supporté par de nombreux renderers (KaTeX, MathJax). Si votre application doit afficher des formules, assurez-vous que votre renderer les gère.

Contrôle qualité du Markdown généré

Pour les applications de publication automatique (génération de documentation, articles de blog, rapports), la qualité du Markdown généré est un enjeu important. Plusieurs aspects méritent une vérification systématique.

La cohérence hiérarchique : le modèle respecte-t-il la hiérarchie des titres (H1 > H2 > H3 sans saut de niveau) ? Les LLM sautent parfois du H2 au H4, ce qui produit un document mal structuré. Ajoutez dans le system prompt : « Respectez une hiérarchie de titres stricte : ## pour les sections principales, ### pour les sous-sections. Ne sautez pas de niveau. »

La qualité des tableaux : les tableaux Markdown sont fragiles. Si le modèle génère un tableau avec des colonnes mal alignées ou des pipes manquants, le rendu sera cassé. Pour les tableaux complexes, envisagez de demander le format HTML directement, qui est plus robuste pour les structures tabulaires complexes.

La cohérence stylistique : d’une génération à l’autre, le modèle peut alterner entre différentes conventions (tirets vs astérisques pour les listes, espaces variables après les #). Un linter Markdown comme markdownlint peut normaliser automatiquement le style après génération. Intégrez-le dans votre pipeline si la publication est automatisée.

La longueur et structure : sans contrainte, les LLM ont tendance à sur-structurer (trop de titres, trop de listes) ou à produire des réponses trop longues. Spécifiez la longueur et la structure attendues dans le prompt. « Rédigez un rapport de 500 mots avec 3 sections » produit un résultat plus cohérent que « Rédigez un rapport ».

Verdict

Le Markdown est le format de sortie le plus naturel et le plus économique pour les LLM quand le contenu est destiné à la lecture humaine. C’est le format par défaut, le plus léger en tokens, et le plus facile à rendre dans une interface. Utilisez-le pour les rapports, la documentation, le contenu éditorial, et les réponses conversationnelles riches. En revanche, évitez de parser du Markdown pour en extraire des données critiques : c’est un format de présentation, pas de données. Pour les intégrations programmatiques, les structured outputs JSON sont la bonne réponse. Le Markdown et le JSON ne sont pas concurrents, ils sont complémentaires.