Pourquoi le Markdown rend les LLM plus intelligents, pas seulement moins chers
Pourquoi le Markdown rend les LLM plus intelligents, pas seulement moins chers
La plupart des gens découvrent les workflows Markdown-vers-IA grâce aux économies réalisées. Ils constatent que la conversion d'une page web du HTML brut vers le Markdown réduit l'utilisation des tokens de 80 à 90 %, font le calcul, et basculent immédiatement.
Cette approche est exacte mais incomplète. La réduction des tokens est un effet secondaire. La vraie raison pour laquelle le Markdown fonctionne mieux avec les LLM est structurelle : le Markdown est un format dans lequel la structure du document et le sens sémantique sont une seule et même chose. HTML ne l'est pas. Cette différence compte bien plus que le nombre de caractères.
Comment les LLM lisent réellement le contenu
Avant d'expliquer pourquoi le Markdown l'emporte, il est utile de comprendre ce que fait réellement un modèle de langage lorsqu'il traite du texte.
Les LLM ne « lisent » pas comme les humains. Ils convertissent votre entrée en tokens — des morceaux d'environ 3 à 4 caractères chacun — et traitent ces tokens à travers des couches d'attention qui apprennent les relations entre eux. Le modèle n'a pas de moteur de rendu visuel. Il ne peut pas déduire qu'un élément est un titre parce qu'il apparaît grand et en gras dans un navigateur. Il ne peut travailler qu'avec la séquence de tokens qu'il reçoit.
Cela signifie que la qualité du signal de votre texte d'entrée — la clarté avec laquelle la structure est encodée dans les tokens eux-mêmes — détermine directement à quel point le modèle comprend le contenu.
Le problème : HTML sépare la structure du sens
HTML a été conçu pour les navigateurs, pas pour les modèles de langage. Un navigateur affiche <div class="article-headline"> comme un titre grand et en gras. Le modèle voit ceci :
<div class="article-headline">Why Markdown Makes LLMs Smarter</div>
Ce qui se tokenise approximativement en :
< div class = " article - headline " > Why Markdown Makes LL Ms Sm arter </ div >
Le signal structurel — « ceci est le titre principal » — est enfoui dans une chaîne de nom de classe. Le modèle doit apprendre, par l'entraînement, que article-headline implique de l'importance. Il s'en sort généralement bien, mais il travaille contre le format, et non avec lui.
Considérons maintenant l'imbrication profonde, qui est standard dans les vraies pages web :
<div class="container">
<div class="content-wrapper">
<article class="post">
<div class="post-body">
<h2 class="section-title">Key Findings</h2>
<p>The results showed...</p>
</div>
</article>
</div>
</div>
Au moment où le modèle atteint Key Findings, il a traité quatre niveaux de bruit structurel. La balise <h2> réelle est le seul signal significatif, et elle est en concurrence avec un nom de classe (section-title) qui peut ou non le renforcer.
Pourquoi le Markdown unifie structure et sémantique
Le Markdown résout ce problème en rendant structure et sens identiques. Il n'y a aucune séparation entre « à quoi ça ressemble » et « ce que ça signifie ».
## Key Findings
The results showed...
Le préfixe ## est le signal sémantique. Il signifie sans ambiguïté « titre de deuxième niveau ». Pas de noms de classes, pas de divs d'encapsulation, pas de signaux concurrents. Le modèle reçoit exactement l'information dont il a besoin, encodée directement dans la séquence de tokens.
Ce schéma s'applique à tous les éléments Markdown :
| Type de contenu | Signal HTML | Signal Markdown |
|---|---|---|
| Titre principal | <h1> ou <div class="title"> ou <span id="headline"> | # |
| Sous-titre | <h2> à <h6>, ou divs stylisés | ## à ###### |
| Texte accentué | <strong>, <b>, <span class="bold"> | **texte** |
| Code | <code>, <pre>, <div class="highlight"> | `code` ou blocs délimités |
| Liste | <ul>/<li>, ou <div class="list-item"> | - élément |
| Lien | <a href="..."> avec balisage environnant | [texte](url) |
En HTML, il existe généralement 3 à 5 façons d'encoder chaque élément sémantique, et leur utilisation réelle varie selon les sites. En Markdown, il n'en existe qu'une. Cette cohérence n'est pas seulement plus soignée — c'est la raison pour laquelle les modèles traitent le Markdown de manière plus fiable.
À quoi cela ressemble en pratique
Voici une section d'un vrai article technologique, traitée de deux façons et envoyée à Claude avec le même prompt : « Résumez les trois conclusions principales. »
Entrée A : Extrait HTML brut (4 200 tokens)
<div class="article-body">
<div class="content-section" data-section="conclusions">
<h3 class="section-heading" id="section-3">Conclusions</h3>
<div class="paragraph-wrapper">
<p class="body-text">First, the researchers found that response latency...</p>
</div>
...
</div>
</div>
Résultat : Le modèle a identifié correctement 2 conclusions sur 3. La troisième a été confondue avec une note méthodologique dans une balise <aside> voisine que le modèle n'a pas reconnue comme contenu non principal.
Entrée B : Markdown converti (890 tokens)
## Conclusions
First, the researchers found that response latency...
Résultat : Les 3 conclusions identifiées correctement. Le contenu de la balise <aside> avait été correctement exclu par le convertisseur comme étant supplémentaire, il n'a donc jamais atteint le modèle.
Le nombre de tokens a chuté de 79 %. La précision est passée de 67 % à 100 % dans cet exemple. Les deux changements proviennent de la même source : un encodage structurel plus propre.
Les chiffres des tokens (et pourquoi ils sont une conséquence, pas la cause)
Puisque les coûts comptent, voici les données issues du traitement d'un article technique de 1 500 mots :
| Format d'entrée | Nombre de tokens | Coût (Claude Sonnet) | Rapport signal/bruit | |---|---|---|---| | HTML brut | 16 820 | 0,050 $ | ~6 % | | Texte brut nettoyé | 3 450 | 0,010 $ | ~35 % | | Markdown propre | 1 890 | 0,006 $ | ~92 % |
La différence de coût est réelle — 88 % moins cher que le HTML brut. Mais notez que le texte brut nettoyé (en supprimant simplement les balises HTML) réduit également significativement le nombre de tokens, tandis que le rapport signal/bruit reste à 35 %. Le texte brut perd toutes les informations structurelles : pas de titres, pas d'emphase, pas de hiérarchie de listes. Vous payez moins mais le modèle a moins sur quoi travailler.
Le Markdown atteint l'optimum : le maximum d'informations structurelles au coût minimal en tokens. C'est pourquoi c'est le bon format pour les entrées LLM, pas seulement le moins cher.
Trois scénarios où la qualité du format change les résultats
1. Résumé
Lors du résumé d'un long article, le modèle doit identifier quelles sections constituent le contenu principal et lesquelles sont supplémentaires. La hiérarchie des titres Markdown (#, ##, ###) rend cela explicite. Le texte brut et le HTML mal structuré forcent le modèle à l'inférer à partir du contenu seul, ce qui augmente le risque d'inclure dans le résumé des encadrés latéraux, des biographies d'auteurs ou des liens vers des articles connexes.
2. Questions-réponses sur du contenu web
Lorsque vous collez une page web et posez une question précise, le modèle doit d'abord localiser la section pertinente. Dans un document Markdown propre, les tokens de titres agissent comme une table des matières que le modèle peut parcourir. En HTML brut, trouver la section pertinente nécessite d'analyser les divs d'encapsulation et les attributs de classe avant d'atteindre le contenu — ce qui compresse la fenêtre de contexte et augmente le risque que le modèle s'attarde sur la mauvaise région.
3. Extraction de code
Les pages techniques contiennent souvent des exemples de code mélangés à des explications en prose. Les blocs de code délimités Markdown (```) créent une frontière non ambiguë. Le modèle sait exactement où le code commence et se termine. En HTML, le code peut être encapsulé dans <pre>, <code>, <div class="highlight">, ou un composant personnalisé sans balise standard du tout — autant de patterns de tokens différents pour le même contenu sémantique.
La conclusion pratique
Si vous alimentez du contenu web vers n'importe quel LLM — pour la recherche, le résumé, les questions-réponses ou l'extraction de données — le format que vous utilisez compte autant que le prompt que vous rédigez. Un Markdown propre n'est pas un luxe. C'est le format d'entrée que les LLM ont été implicitement entraînés à mieux comprendre, car une part significative de leur corpus d'entraînement (GitHub, Wikipédia, les sites de documentation, Stack Overflow) est déjà en Markdown ou dans des formats proches du Markdown.
Les économies de coûts sont un bonus. L'amélioration de la qualité est le vrai enjeu.
Convertissez n'importe quelle page web en Markdown propre, prêt pour les LLM, en un clic. Essayez Web2MD — gratuit pour Chrome.