Le Markdown était une erreur pour les sorties d'agents IA. Un ingénieur de Claude vient de le prouver.

7 min read

« HTML est le nouveau Markdown. »

C'est Thariq Shihipar, de l'équipe Claude Code chez Anthropic, sur X la semaine dernière.

MAIS

CLAUDE.md, AGENTS.md, SKILL.md... Du Markdown partout. C'est devenu l'oxygène d'un projet Claude Code, le format par défaut que personne n'a vraiment choisi. Alors quand l'agent produit un résultat, il sort du Markdown. C'est ce qu'il a vu partout.

Puis Thariq balance une galerie de vingt artefacts HTML pour étayer son propos.

RÉSUMÉ : Le Markdown a envahi nos projets via les fichiers de config (CLAUDE.md, AGENTS.md, SKILL.md), puis s'est infiltré partout ailleurs, y compris dans les sorties d'agents que personne ne lit jamais. Un membre de l'équipe Claude Code vient d'expliquer pourquoi il est passé au HTML, et ça se résume à une commande toute simple.

Pour un fichier de config, c'est parfait. Court, instructionnel, lu une fois et stocké en contexte. Mais quand l'agent vous pond un plan de 200 lignes ou un rapport de revue de code ? Autre histoire. Vous l'ouvrez, lisez quinze lignes, fermez l'onglet. Trois jours plus tard vous redemandez à l'agent parce que vous n'avez aucun souvenir de ce qu'il avait décidé.

L'agent a bien bossé. Le format l'a fait disparaître.

Retour aux sources. HTML précède Markdown de plus d'une décennie. Le navigateur a été conçu autour de lui. Markdown n'a toujours été qu'un raccourci.

Employé de bureau submergé par un texte markdown interminable sur son écran, tandis qu'un super-héros pointe vers une interface HTML claire avec tableaux organisés et boutons
Sortie Markdown : là où la lisibilité va mourir lentement et douloureusement.

Pourquoi Markdown a gagné : L'excuse des 8 192 tokens

En 2022, ChatGPT débarquait avec une fenêtre de contexte de 8 192 tokens. Pas énorme. Pour le même contenu, HTML brûle environ 3x plus de tokens que Markdown (les chiffres de web2md.org donnent environ 8 000 tokens pour du HTML contre 2 800 pour l'équivalent Markdown). Quand votre budget est de 8K et que votre sortie grignote votre entrée, chaque token économisé c'est un paragraphe qui survit.

Markdown a gagné ce combat sur les coûts.

Simon Willison, une des voix les plus fortes de la communauté dev IA, l'a admis publiquement la semaine dernière : il écrivait du Markdown pour les LLM depuis l'époque GPT-4 exactement pour cette raison. Il n'avait pas tort. Personne n'avait tort, vu les calculs de l'époque, et les calculs tenaient la route.

Plus maintenant. Les fenêtres de contexte en 2026 atteignent un million de tokens et ça continue. La contrainte qui rendait Markdown rationnel s'est évaporée. Le comportement, non. On a continué à bourrer nos projets de fichiers .md parce que c'est ce qu'on avait toujours fait, pas parce que c'était le bon choix pour ce qu'on fait maintenant.

Pure inertie à ce stade.

La communauté a déjà fait ça

La communauté IA adopte les formats par vagues. Quelqu'un essaie un truc, ça marche, ça se répand, et trois ans plus tard on lève la tête et on remarque que le choix évident depuis le premier jour était juste là.

Même cycle pour le Markdown dans les sorties d'agents : adopté vite, questionné tard.

Le même instinct m'avait poussé à argumenter, il y a quelques mois, que les CLI battent MCP pour les agents IA. La communauté avait sauté sur MCP parce que c'était nouveau et brillant, pendant que la solution stable et ennuyeuse tournait en production depuis des décennies. On fait ça tous les douze mois sans faillir.

La différence cette fois ? C'est quelqu'un de l'intérieur d'Anthropic qui sonne le tocsin.

Ce que fait vraiment un membre de l'équipe Claude Code

Thariq Shihipar, de l'équipe Claude Code chez Anthropic, vient de publier un post avec vingt exemples concrets. Pas de la théorie. De vrais prompts, de vraies sorties, et des artefacts que vous pouvez ouvrir dans votre navigateur maintenant.

La galerie montre ce qu'un agent peut vous livrer en HTML que Markdown ne peut structurellement pas faire. Une comparaison de specs côte à côte avec deux colonnes, des différences en couleur, et un verdict en bas. Un rapport de revue de code où le diff est annoté en ligne, des points de sévérité en rouge/orange/vert, des liens de saut vers chaque trouvaille. Ou l'éditeur jetable qui vient avec un bouton « copier en JSON » que vous n'avez jamais demandé mais que vous utilisez immédiatement.

Ce qu'apporte HTML : des tableaux qui s'affichent, des couleurs qui signifient quelque chose, des diagrammes SVG, des onglets, des layouts responsive, des éléments interactifs quand vous en avez besoin. Ce qu'apporte Markdown : un long scroll.

Ce qui compte n'est pas la beauté. C'est cette ligne du post de Thariq :

« Je me sens plus dans la boucle que jamais en utilisant HTML. J'ai honnêtement arrêté d'utiliser Markdown pour presque tout. »

Dans la boucle. C'est tout le jeu. Un agent qui a produit un plan parfait que vous n'avez pas lu est un agent qui n'a rien fait. La sortie existe au sens métaphysique, certes. La décision qu'elle documentait disparaît dès que vous fermez l'onglet. Un fichier Markdown que vous scrollez sans lire équivaut à aucun fichier. Un fichier HTML que vous ouvrez dans votre navigateur, partagez par lien, screenshotez pour Slack ? Ce fichier existe. Les gens le lisent. Vous le lisez. Vous restez au courant de ce que votre agent a décidé.

Le vrai débloquage c'est rester partie prenante du workflow. Les artefacts plus beaux sont un effet de bord.

Un plan qui n'est jamais lu est un plan qui n'a jamais été écrit.

Les vraies limites

HTML coûte plus de tokens. Le coût en tokens est tout le pushback contre le post de Thariq. Quand l'annonce est tombée, un compte sur X (@EXM7777) a répondu : « ouais bien sûr je vais dépenser 5x plus de tokens pour des fichiers texte jolis ». La réponse a pris parce qu'elle sonne juste.

Elle est juste, pour un cas spécifique. Elle est fausse pour le cas dont parle Thariq.

Si le lecteur principal de votre sortie est un autre LLM (un agent en aval qui va consommer le fichier, le parser et agir dessus), Markdown va bien. L'agent se fiche des couleurs. Il n'affiche pas les tableaux. Les tokens sont la seule chose qui compte. Même logique pour les sorties rapides que vous jetterez dans trois minutes, pour les pipelines haute cadence où vous générez deux cents fichiers par heure, pour tout ce où le coût par sortie domine la valeur de la sortie.

Si le lecteur principal de votre sortie est un humain (et vous, cher builder, êtes un humain, même le vendredi après-midi quand vous avez déjà mentalement décroché et que le bateau pour voir les dauphins part dans deux heures), le calcul s'inverse. Le coût c'est quelques centimes de plus en tokens. La valeur c'est si vous lisez vraiment le truc. Un plan à 5 centimes que vous lisez bat un plan à 1 centime que vous ignorez, à chaque fois.

L'autre vraie limite que Thariq admet lui-même : les fichiers HTML sont pénibles à differ dans git. Markdown se lit proprement dans une pull request. HTML emballe tout dans une soupe de tags qui rend la revue ligne par ligne misérable. Si l'artefact doit vivre dans un repo et être revu à travers les commits, Markdown gagne encore.

Cloudflare pousse aussi Markdown pour le flux d'entrée des agents, convertissant les pages web en Markdown pour que les agents puissent les consommer efficacement. Conversation différente. Web → agent c'est l'entrée. Agent → humain c'est la sortie. Les deux peuvent être vrais en même temps sans contradiction.

Si votre lecteur est un modèle, Markdown. Si votre lecteur c'est vous, HTML.

Un prompt. Pas de setup.

Tout le switch tient en une phrase à la fin de votre prompt :

« Fais ça comme un seul fichier HTML. »

C'est tout. Pas d'édition de CLAUDE.md, pas d'échafaudage de skill, pas de setup. Thariq est explicite là-dessus : ne sur-ingénierisez pas. Essayez le prompt sur votre prochaine tâche de planification. Voyez ce qui sort. Si vous vous retrouvez à l'utiliser trois fois de suite, alors peut-être pensez à une skill. Pas avant.

Même réflexe de ne-pas-sur-ingénieriser que quand un seul repo open-source a transformé Claude Code en architecte n8n fonctionnel. Le repo était le débloquage. Tout ce que j'ai essayé d'échafauder autour n'a fait que gêner.

La galerie a vingt exemples triés par cas d'usage : planification, revue de code, design, prototypage, diagrammes, présentations, recherche, rapports, éditeurs custom. Prenez celui qui se rapproche le plus de ce que vous faites demain. Piquez la structure du prompt. Expédiez.

Mon dernier plan s'est ouvert dans le navigateur avec des onglets, un diff en couleur, et un bouton « copier en JSON » que je n'avais jamais demandé. Je l'ai lu entièrement. Pour la première fois depuis longtemps, je savais exactement ce que mon agent avait décidé sans avoir à retourner le relire trois fois.

Essayez « fais ça comme un seul fichier HTML » sur votre prochain plan. Vous le lirez.

Sources