Pendant trois ans, Markdown a été la lingua franca entre les LLM et les humains. Chaque interface de chat, chaque agent de code, chaque workflow autonome partait du même postulat par défaut : rendre la réponse du modèle en Markdown, l'envoyer dans un navigateur, et passer à autre chose.
Ce postulat se fissure. En mai 2026, un tweet de Thariq Shihipar, ingénieur chez Anthropic, affirmant que HTML est un meilleur format de sortie que Markdown, est passé de 326 publications à plus de 15 000 en 24 heures, propulsé par un appui d'Andrej Karpathy. En une semaine, "structurez votre réponse en HTML" est devenu l'un des patterns de prompt les plus partagés sur le Twitter des développeurs — et le débat sur la manière dont les agents IA devraient réellement parler aux humains a connu sa première vraie ligne de fracture.
Voici ce qui se passe, pourquoi cela compte pour quiconque construit avec des LLM, et comment penser les arbitrages.
L'argument : bande passante, densité, interactivité
La thèse de Shihipar repose sur trois affirmations difficiles à balayer.
Densité d'information. Un tableau Markdown plafonne à quelques colonnes avant de devenir illisible. Un tableau HTML peut être triable, filtrable, paginé, codé en couleurs, et intégrer des sparklines dans ses cellules. La même réponse, qui pèse 800 tokens en HTML, peut transmettre 3 à 5 fois plus de structure exploitable que son équivalent Markdown.
Lisibilité pour les documents longs. L'expérience citée par Karpathy : demandez au LLM de "structurer sa réponse en HTML", ouvrez le fichier dans un navigateur, et une réponse de 4 000 mots devient parcourable avec sections repliables, navigation interne et diagrammes SVG intégrés. La même réponse en Markdown brut est un mur de texte que les utilisateurs survolent puis abandonnent.
Interaction bidirectionnelle. C'est là le vrai coin enfoncé. Le Markdown est en lecture seule. Le HTML transporte des formulaires, des boutons, des curseurs et des gestionnaires d'événements. Quand un agent renvoie une réponse HTML contenant un formulaire, l'action utilisateur suivante devient une soumission structurée plutôt qu'un nouveau prompt en texte libre. Cela élimine des catégories entières de tours de clarification.
Karpathy a élargi le cadre dans sa publication originale : la vision est le canal d'entrée à plus haute bande passante dont disposent les humains. Le texte est le canal de sortie à plus basse bande passante qu'un LLM peut produire. Pousser la sortie modèle vers des artefacts visuels — diaporamas, dashboards, HTML interactif — est une montée en bande passante, pas un choix de style.
Le contre-argument : tokens, sécurité, pollution des pipelines
Le contre-argument n'a pas tardé. La version la plus claire est venue de praticiens opérant des pipelines d'agents en production.
Coût en tokens. Les balises imbriquées du HTML sont du poids mort quand le consommateur est un autre LLM. Un wrapper div class rounded-lg p-4 bg-gray-100 coûte environ 12 tokens dont l'équivalent Markdown se passe. Dans une boucle d'agent multi-étapes où chaque sortie devient l'entrée de l'étape suivante, ces tokens s'accumulent vite — les fenêtres de contexte se remplissent, la latence monte, les coûts explosent.
Surface de sécurité. Le HTML peut s'exécuter. Dès qu'un agent émet du HTML et qu'une surface en aval le rend sans assainissement, vous avez un risque d'injection de script. La grammaire étroite du Markdown est précisément l'une des raisons pour lesquelles il est devenu le défaut — il peut faire très peu de mal à un lecteur.
Bruit dans les diffs et le versioning. Les diffs HTML sont catastrophiquement plus bruyants que les diffs Markdown. Pour les agents qui écrivent du code ou des documents dans un dépôt, cela compte : chaque petit changement touche chaque balise enveloppante, et la revue de code devient de l'archéologie.
La synthèse la plus propre est venue de Tony, un praticien qui a remis en cause le cadrage lui-même : Markdown gère la pensée et le transport. HTML gère la présentation finale. Garder chacun dans son couloir, c'est simplement du bon génie logiciel. Utilisez Markdown à l'intérieur du pipeline d'agent — entre les appels d'outils, dans les scratchpads, dans le raisonnement intermédiaire. Convertissez en HTML uniquement à l'étape finale de rendu, quand un humain va réellement regarder la sortie.
Ce que cela signifie pour le tooling développeur
Ce n'est pas vraiment un débat sur la syntaxe. C'est un débat sur le moment où la sortie d'un agent cesse d'être une transcription et devient une UI.
Pendant trois ans, le contrat implicite était : le modèle écrit du texte, votre application le rend. La poussée HTML brise ce contrat — le modèle écrit l'UI directement. Claude Code, Cursor et la plupart des IDE basés sur le chat penchent déjà dans cette direction avec les artefacts et les aperçus en ligne. La question est de savoir si le format de sortie par défaut de chaque appel LLM doit être HTML, ou si HTML doit rester une surface opt-in pour le dernier kilomètre.
Quelques enseignements pratiques tirés de la semaine de discussion :
-
Pour les réponses destinées aux utilisateurs finaux, le prompt "structurez votre réponse en HTML" est une amélioration gratuite. Ajoutez des classes Tailwind, un mode sombre, des boutons de copie, et vous transformez un mur de texte en dashboard interactif sans aucune modification d'infrastructure.
-
Pour la communication agent-à-agent, restez sur Markdown ou JSON. Le coût en tokens est réel, le bénéfice de rendu est sans objet quand le consommateur est un autre modèle.
-
Pour les sorties d'outils développeur — logs d'erreurs, résultats de requêtes, diffs de fichiers — HTML l'emporte sur l'utilisabilité. Un test en échec rendu en HTML repliable avec les stack frames en nœuds expansibles est réellement plus rapide à déboguer que le même contenu en Markdown.
-
Pour le contenu long — rapports de recherche, explications techniques approfondies, réponses multi-sections — HTML l'emporte sur la lisibilité, mais uniquement si vous ouvrez effectivement le fichier dans un navigateur. La même réponse dans une bulle de chat est pire, pas meilleure.
Le virage plus profond : le format de sortie comme décision produit
Ce qui est intéressant, c'est qu'il a fallu cinq ans pour que ce débat émerge. Markdown a gagné par défaut en 2021 parce qu'il était suffisant et que tous les frameworks le supportaient. Personne ne l'a choisi — c'est simplement arrivé.
Nous sommes maintenant au point où le format de sortie est une décision produit délibérée. Certains agents émettront du HTML par défaut. D'autres émettront un schéma UI piloté par JSON personnalisé que l'application hôte rend en widgets natifs. D'autres émettront des diagrammes Mermaid, des diaporamas ou de l'audio. La "réponse" cesse d'être une chaîne de caractères et devient un artefact structuré dont la forme est choisie par le modèle selon ce qu'il essaie de communiquer.
C'est un véritable changement, et cela explique pourquoi le tweet de deux phrases de Karpathy a touché un nerf. Le défaut est silencieusement faux depuis des années. Le correctif tient en une ligne à la fin d'un prompt — et les implications remontent jusqu'à la conception des frameworks d'agents, des IDE et des surfaces de chat.
Essayez aujourd'hui
Si vous construisez avec des LLM, l'expérimentation la moins chère de la semaine est celle-ci : prenez un prompt que vous lancez régulièrement, ajoutez "structurez votre réponse en HTML avec un mode sombre et une mise en page propre", sauvegardez la sortie dans un fichier .html, et ouvrez-le dans votre navigateur. Voyez ce qui change.
Si la réponse est "rien" — votre cas d'usage est bien en Markdown, expédiez. Si la réponse est "c'est nettement plus utile" — vous avez un indice sur la direction que le format de sortie de votre produit devrait prendre.
Dans tous les cas, la conversation est désormais ouverte. Dans deux ans, "cet agent doit-il renvoyer du Markdown ou du HTML ?" sera une question normale de revue de design. Aujourd'hui, c'est une discussion Twitter avec 15 000 quote tweets. C'est généralement ainsi que ces virages commencent.
Chez Noqta, nous construisons des expériences web pilotées par agents pour les entreprises MENA — depuis des outils internes qui renvoient des dashboards interactifs au lieu d'exports CSV, jusqu'aux chatbots publics qui transforment les réponses en formulaires réservables. Si vous réfléchissez à la manière dont vos surfaces IA devraient réellement se présenter aux utilisateurs, contactez-nous.