La semaine dernière, l'ingénieur lead de Claude Code chez Anthropic a publié un essai intitulé "The Unreasonable Effectiveness of HTML". En 16 heures, 4,4 millions de vues. Deux camps se sont formés. Team HTML a dit que le Markdown était mort. Team Markdown a répondu que l'HTML posait des risques de sécurité et coûtait 5 fois plus de tokens.
Les deux camps ont raté la question centrale sur le format output Claude.
Ce que l'ingénieur d'Anthropic a vraiment dit
Thariq Shihipar n'a pas dit "abandonnez le Markdown". Il a montré 20 exemples concrets où l'HTML dépasse le Markdown pour des outputs destinés à être lus, partagés ou revisités : revues de code avec annotations colorées par sévérité, rapports avec sections repliables, comparaisons de design avec aperçus interactifs.
Sa thèse n'est pas un plaidoyer pour l'HTML. C'est une observation sur la lisibilité. Un fichier Markdown de plus de 100 lignes devient un mur de texte sans navigation. Personne ne le lit jusqu'au bout. Un fichier HTML équivalent, lui, se scanne, se partage et s'utilise.
Internet a entendu "HTML is better". Thariq a dit autre chose : "le format doit servir le lecteur, pas l'habitude."
Le seul critère qui compte : qui lit l'output ?
Le Markdown a conquis les outputs Claude par défaut pour une raison simple : les données d'entraînement en sont saturées. GitHub, wikis, documentation technique. Le modèle produit ce qu'il a le plus vu. Pas ce qui correspond le mieux à votre usage.
La vraie question n'est pas "Markdown ou HTML ?" Elle est : qui va lire cet output, et qu'est-ce qu'il va en faire ?
Un développeur qui relira l'output dans son éditeur et l'intégrera dans un dépôt git a besoin de Markdown. Un manager qui va ouvrir un lien sur son téléphone, survoler les sections importantes et partager la synthèse à son équipe sur Slack a besoin d'autre chose.
C'est le même modèle Claude. La même requête, ou presque. Le format change parce que le lecteur est différent.
Trois cas, trois réponses
Cas 1 : Un humain lit l'output. Votre interlocuteur ouvre un navigateur, cherche la section qui le concerne, copie un graphique pour une réunion, envoie un lien à un collègue. C'est le cas de figure que Thariq illustre : revues de code, rapports de projet, comparaisons d'options. HTML gagne ici parce que l'output est une destination. On le navigue, on le partage, on agit dessus.
Cas 2 : Un autre agent lit l'output. Votre output alimente un pipeline automatisé. Un second agent extrait des données structurées, prend une décision, déclenche l'étape suivante. Aucun humain ne voit jamais le fichier. Markdown gagne ici sans discussion : léger, parseable, diffable. Git le trace. Les pipelines CI/CD le traitent. Les autres modèles le consomment avec un minimum de tokens.
Cas 3 : Les deux lisent l'output. Vous générez une revue de PR. Vous la lisez vous-même. Vous voulez aussi qu'elle soit tracée dans le dépôt. Ou vous produisez un rapport hebdomadaire : les parties prenantes le consultent dans le navigateur, mais les données alimentent le planning de la semaine suivante. La réponse dans ce cas : source Markdown, artefact HTML. Le Markdown reste la source modifiable et versionnable. L'HTML est généré pour les lecteurs humains qui ont besoin de navigation et de clarté visuelle. Thariq lui-même le recommande explicitement.
Ce que ça change concrètement dans votre équipe
Si vous utilisez Claude pour produire des analyses, des synthèses de réunion ou des rapports destinés à des décideurs, demandez de l'HTML. Ajoutez une ligne à votre prompt : "Output en HTML avec résumé exécutif, sections repliables et actions prioritaires. Tous les styles en inline pour pouvoir ouvrir localement." Le résultat passe de "un document à lire" à "une page sur laquelle travailler".
Si Claude alimente un processus automatisé en arrière-plan, gardez le Markdown. Le coût en tokens de l'HTML (2 à 5 fois plus) n'est pas anodin à grande échelle, et un agent n'a pas besoin de navigation visuelle pour extraire des données.
La règle est simple. Elle n'est pas une question de technologie. C'est une question de lecteur.
Deux points à ne pas négliger si vous adoptez l'HTML par défaut. D'abord, l'HTML généré par Claude peut inclure du JavaScript — ce qui pose des questions de sécurité réelles si vous déployez ces fichiers dans des contextes sensibles. Demandez explicitement "aucun JavaScript, aucun appel réseau, polices système uniquement" si c'est votre cas. Ensuite, l'accessibilité : l'HTML produit par défaut n'est pas conforme WCAG. Si vos documents sont partagés à des équipes larges, précisez vos exigences dans le prompt.
Le Markdown n'est pas mort. Il change de rôle. Il quitte la couche d'affichage pour devenir un protocole d'échange entre agents et entre versions. Pour les humains qui lisent, naviguent et partagent, Claude peut faire mieux que du texte brut mis en forme.
Vous voulez identifier les processus de votre équipe où ce type d'output ferait une différence concrète ? C'est exactement ce qu'on explore dans le diagnostic gratuit de 30 minutes.
