Le manifeste HTML d’Anthropic : une taxe sur l’intelligence déguisée en progrès

Le 8 mai 2026, Thariq Shihipar, ingénieur produit sur l’équipe Claude Code chez Anthropic, a publié un manifeste sur X qui circule depuis dans toute la nébuleuse des développeurs IA : abandonnez le markdown, passez au HTML pour vos specs, vos plans d’implémentation, vos rapports, vos comptes-rendus. L’article complet est hébergé sur sa galerie d’exemples GitHub Pages et défend la thèse en huit arguments, sept cas d’usage et une session FAQ qui cherche à désamorcer les objections évidentes.

Le texte est bien écrit. Il est intelligent. Et il est, par construction, un acte de marketing stratégique d’Anthropic qui se présente comme un retour d’expérience personnel. C’est cette double nature qui mérite qu’on s’y arrête, parce qu’un ingénieur d’une entreprise prêche rarement par hasard les pratiques qui maximisent la consommation de son propre produit.

Ce que le billet a de juste : l’interactivité jetable

Commençons par concéder ce qui mérite de l’être. Shihipar a raison sur un sous-périmètre étroit mais réel.

Son argument le plus convaincant porte sur ce qu’il appelle les custom editing interfaces : ces petits éditeurs HTML jetables qu’on demande à Claude de produire pour un usage précis et borné. Reprioriser trente tickets Linear avec un drag-and-drop en quatre colonnes, ajuster une courbe d’easing d’animation via des sliders, tester en temps réel une regex sur un jeu d’exemples, prototyper un checkout button avec des knobs pour explorer plusieurs variantes. Pour ces usages, l’interactivité du HTML n’est pas un nice-to-have esthétique. C’est précisément le cœur de la valeur. Tenter cela en markdown serait absurde, et le bouton final copy as JSON qui réinjecte le résultat dans Claude Code referme la boucle proprement.

De même, pour des prototypes purement visuels (design d’un composant, exploration de plusieurs variantes d’écran d’onboarding en grille comparable), la richesse du HTML produit un livrable qu’aucun markdown ne peut approcher.

Sur ce périmètre, qu’on peut estimer entre dix et quinze pour cent des usages réels d’un développeur, il a raison. C’est précisément ce qui rend la suite plus crédible à démonter : un argument vrai sur un sous-ensemble étroit, étendu sans précaution à tout le reste.

Le coût en tokens balayé d’un revers de main

Première charge. Shihipar admet textuellement dans sa FAQ que générer du HTML prend deux à quatre fois plus longtemps que du markdown. Et qu’il consomme proportionnellement plus de tokens. Voilà une phrase qui, dans n’importe quel contexte d’entreprise sérieux, devrait déclencher un débat budgétaire et une revue d’usage. Voilà comment l’auteur la traite : « avec la fenêtre de 1M de Claude Opus 4.7, l’augmentation de l’usage en tokens n’est pas vraiment perceptible dans la fenêtre de contexte ».

La phrase, lue attentivement, est un sophisme construit avec soin. Elle déplace l’objection (le coût) vers un terrain non concerné (la place disponible dans le contexte). Ce sont deux variables différentes. La fenêtre de contexte mesure ce que Claude peut lire en entrée à un instant donné. La facture mesure ce que vous payez pour ce que Claude écrit en sortie sur l’année. La première peut être généreuse pendant que la seconde explose. C’est précisément le cas ici : multiplier par deux à quatre la longueur de chaque artefact généré multiplie d’autant les tokens facturés, indépendamment du contexte disponible.

L’argument n’est défendable que dans un seul cas de figure : quand l’auteur ne paie pas ses tokens. Ce qui est, par construction, la situation d’un ingénieur d’Anthropic.

Le timing rend la chose plus piquante encore. En avril 2026, Anthropic a discrètement modifié les conditions de son prompt caching, en imposant un coefficient multiplicateur de deux sur l’option de TTL longue. Ce signal commercial est limpide : l’entreprise a besoin que la consommation grimpe, pas qu’elle baisse. Sur ce même mouvement, un article récent que j’ai consacré à Understand-Anything montre précisément la direction inverse, celle d’une communauté technique qui optimise les tokens en indexant la codebase localement. Deux mouvements simultanés, l’un éditeur, l’autre communautaire, qui poussent dans des directions opposées. Ce n’est pas un hasard. C’est la structure même du marché.

Le HTML présentationnel n’est pas le HTML sémantique

Voici l’angle qui me tient le plus à cœur, et qui n’a, à ma connaissance, été développé nulle part dans la critique du billet.

Quand on défend le HTML en général, on défend implicitement deux choses très différentes. D’un côté il y a le HTML sémantique : balises <article>, <section>, <nav>, <aside>, hiérarchie rigoureuse des <h1> à <h6>, microdata Schema.org, attributs ARIA. C’est ce HTML-là que j’ai défendu dans mon article sur la dette d’accessibilité IA comme rempart contre l’illisibilité du web moderne pour les LLM. Un HTML sémantique est lisible par une machine parce que la structure y est déclarée, pas simulée.

De l’autre côté, il y a le HTML présentationnel : piles de <div> agrémentés de classes Tailwind, CSS qui simule la structure plutôt que de la déclarer, SVG imbriqués qui ressemblent à des diagrammes mais ne s’analysent pas, JavaScript inline qui fait office de logique. C’est le HTML qu’on génère vite, qui rend joli, et qui est sémantiquement opaque. Un lecteur humain voit une mise en page propre ; une machine voit un sac de balises sans sens.

Or, le HTML que Claude produit pour ces fameuses specs riches est, dans l’écrasante majorité des cas, du HTML présentationnel. Regardez les exemples de la galerie de Shihipar : ce sont des artefacts visuellement soignés, structurés par CSS, sans véritable hiérarchie sémantique. Un grand <div class="..."> avec un <h2> perdu au milieu d’un sea de divs stylés. Les diagrammes SVG sont des dessins, pas des graphes interprétables.

C’est un retournement vertigineux. Pendant dix ans, l’industrie web a abandonné la sémantique pour la présentation, et il a fallu une décennie pour s’apercevoir que les moteurs de recherche, les lecteurs d’écran et désormais les LLM ne savaient plus lire ce qu’on produisait. On a inventé Schema.org, JSON-LD, les microdata, pour réinjecter du sens là où on l’avait drainé. Le HTML maximalisme tel que Shihipar le défend refait exactement le même mouvement, mais à l’intérieur du workflow d’un développeur. On sacrifie la sémantique d’un markdown clair pour la présentation d’un HTML stylé, et on appelle ça un progrès.

Le version control sacrifié pour des artefacts censés être revus

Le billet aborde la question du versionning dans sa FAQ, en deux phrases : « C’est honnêtement un des plus gros downsides du HTML, les diffs HTML sont bruyants et difficiles à revoir comparé au markdown ». Et puis l’auteur passe à autre chose.

Cette phrase, glissée dans une FAQ, est en réalité l’objection rédhibitoire. L’usage entier d’une spec, d’un plan d’implémentation, d’un rapport d’incident, d’un compte-rendu de PR, c’est d’être lu, amendé, revu, archivé. Tout cela passe par un système de versioning. Si le diff devient illisible, la collaboration s’effondre. On ne revoit plus le détail des changements, on revoit le rendu global, ce qui demande de relire chaque fois l’intégralité du document plutôt que ses différences. Sur une équipe de cinq personnes qui revoit dix specs par semaine, le coût cumulé est astronomique.

Sacrifier la reviewabilité d’un artefact dont la raison d’être est d’être revu, ce n’est pas un compromis défendable. C’est une renonciation au principe même de la collaboration asynchrone. Tout l’écosystème Git, des pull request reviews aux outils comme Reviewable en passant par les workflows que j’ai détaillés sur les hooks Claude Code, repose sur l’idée qu’on peut visualiser proprement ce qui a changé entre deux versions. Le HTML généré casse cette propriété.

La parade évidente serait de générer du HTML minimal et normalisé, dont les diffs resteraient lisibles. Mais c’est précisément ce que les exemples du billet ne sont pas. Ils sont au contraire des artefacts visuellement riches, denses en CSS, qu’un reflow de Claude rendra entièrement différents au commit suivant sans changement de fond.

L’auto-prophétie : « je ne lis plus le markdown »

Au détour d’un paragraphe, Shihipar lâche une phrase qui mérite d’être encadrée. « In practice, I’ve found I tend to not actually read more than a 100-line markdown file. » Sa solution proposée est d’enrober mieux ces fichiers en HTML, pour qu’ils deviennent plus appétissants à lire.

Cette inversion mérite qu’on s’y arrête. La question n’est pas pourquoi je ne lis plus mes specs en markdown ?. La question est pourquoi mes specs font-elles plus de cent lignes ?. Et la réponse, qui n’est pas dans le billet, est connue : parce que Claude Code, dont la directive systémique privilégie l’exécution avant la réflexion, produit des artefacts verbeux par défaut. Quand la pensée n’est pas condensée, le document s’allonge. Quand le document s’allonge, plus personne ne le lit.

La bonne réponse à cette dérive n’est pas d’enrober le fichier dans une présentation plus séduisante. C’est de demander une spec plus courte, mieux pensée, plus dense. Cinquante lignes de markdown qu’on lit valent mieux que trois cents lignes de HTML qu’on survole. L’industrie technique connaît cette règle depuis Brooks ; elle ne change pas parce qu’on a un nouvel outil de génération.

Enrober en HTML un symptôme de spec verbeuse, c’est traiter le pansement plutôt que la plaie. Et le pire, c’est que le pansement coûte deux à quatre fois plus cher.

Le risque de sécurité jamais évoqué

Une lacune frappe quand on lit le billet d’un œil sécurité : pas un mot sur l’exécution.

Un fichier markdown est un objet inerte. Vous l’ouvrez dans un lecteur, il s’affiche, c’est fini. Un fichier HTML, lui, est un objet actif : il contient potentiellement du JavaScript exécutable, des fetch vers des domaines arbitraires, des références d’images qui déclenchent des requêtes, du CSS qui peut leaker des informations via des sélecteurs d’attributs.

Et la chaîne de génération est porteuse de risques spécifiques. Claude Code lit votre code source, vos MCP Slack ou Linear, votre historique git, vos fichiers locaux, parfois vos secrets de configuration. Il produit ensuite un fichier HTML qu’on est invité à ouvrir dans un navigateur. Si une portion du contenu lu en amont contient une indirect prompt injection, c’est-à-dire des instructions cachées dans un ticket, un commentaire de code, une page web ingérée, alors l’agent peut, à l’insu de son utilisateur, intégrer dans le HTML généré une exfiltration silencieuse : un appel fetch vers un domaine contrôlé par l’attaquant, transportant en paramètre un fragment de cookie de session ou un extrait du contenu local.

Ce scénario n’est pas théorique. La famille des attaques par indirect prompt injection a été largement documentée par Simon Willison et plusieurs équipes de sécurité offensive depuis 2024. Le passage à des artefacts HTML générés par LLM, ouverts dans le navigateur de l’utilisateur final, ouvre une surface d’attaque qui n’existait pas avec des fichiers markdown rendus en lecture seule.

Que le billet officiel d’un ingénieur d’Anthropic ne mentionne pas une seule fois cette question, c’est en soi un signal. Ce n’est pas que l’auteur l’ignore : c’est qu’elle n’est pas dans le périmètre du message qu’il porte. Un manifeste produit ne s’embarrasse pas des angles morts de sécurité.

HTML pour Claude vers humain, mais qui paie pour Claude vers Claude ?

Un dernier angle, architectural celui-là. Le billet présente uniformément le HTML comme un format de communication Claude vers humain. Mais beaucoup, sans doute la majorité, des specs et plans générés ne sont pas lus une fois et jetés. Ils sont relus par un autre agent en début de session suivante, par un autre membre de l’équipe via son propre Claude Code, par un agent CI qui valide une implémentation, par un script d’analyse qui agrège plusieurs rapports.

Pour toutes ces consommations en aval, le HTML est un format hostile. Demander à Claude de re-parser un HTML stylé pour en extraire la sémantique, c’est lui imposer une étape de désembuagation qu’un markdown propre lui épargnait. Le markdown a une grammaire formelle, un parseur déterministe ; le HTML présentationnel est un sac de divs où la structure logique est noyée dans la mise en forme. Le coût de réingestion est mécaniquement plus élevé.

Cette logique est exactement celle que j’ai posée sur MCP comme question d’architecture plutôt que de protocole : le bon format de transport est celui qui sert le consommateur, pas celui qui flatte le producteur. Optimiser pour l’œil humain au détriment de la chaîne d’agents en aval, c’est faire le mauvais arbitrage si le document est destiné à être réingéré. Et dans un workflow Claude Code mature, presque tout document est destiné à être réingéré.

Le sous-texte stratégique : verrouillage par artefact

Reprenons les pièces. Anthropic a tout intérêt à ce que ses utilisateurs consomment plus de tokens. Anthropic a adouci les conditions du prompt caching long en imposant un facteur deux. Anthropic pousse Claude Design, le plugin frontend-design, les artefacts visuels riches. Anthropic pousse les Skills (dont j’ai documenté la mécanique par ailleurs) qui chargent du code spécialisé à la demande. Et un ingénieur de l’équipe Claude Code publie un manifeste qui prêche, sur les huit cas d’usage qu’il liste, le format de sortie le plus coûteux et le plus difficile à porter ailleurs.

Lisons ce dernier point sous l’angle du verrouillage. Un fichier markdown s’ouvre dans n’importe quel éditeur, se rend dans n’importe quel navigateur, se convertit en PDF, en docx, en présentation Reveal.js. Un fichier HTML généré avec Tailwind, des SVG imbriqués, du JavaScript interactif et des références à un design system propriétaire est de facto attaché à l’écosystème qui l’a produit. Il ne s’ouvre proprement que dans un navigateur récent ; il ne se modifie que via Claude Code, parce que personne ne va corriger à la main des centaines de classes utilitaires ; il ne se porte pas vers un autre outil sans réingestion coûteuse.

C’est précisément la dynamique de remplacement d’objets standards par des artefacts générés à la demande que j’ai décrite dans mon article sur Claude Opus 4.6 comme menace pour les SaaS. Sauf qu’ici, l’objet remplacé est encore plus universel : c’est le fichier texte. Le markdown était devenu le format pivot d’une décennie de productivité numérique, du README au RFC en passant par les notes Obsidian. Le HTML généré veut prendre cette place. Et chaque artefact ré-engage l’utilisateur dans la session Claude Code suivante, parce que la prochaine modification se fera nécessairement via l’agent qui l’a produit.

Le billet ne dit rien de tout cela. Il est sincèrement écrit, sans doute. Il n’en est pas moins, structurellement, un instrument de marketing produit. C’est le piège classique du content marketing de qualité : un expert publie un point de vue qui est aussi un argumentaire commercial, et la qualité du texte sert à masquer la fonction du texte. Cette grammaire est désormais omniprésente dans la nébuleuse IA, et j’ai déjà décrit ailleurs comment la bulle francophone reprend les manifestes anglo-saxons sans les passer au filtre minimal du cui bono.

La matrice de décision réelle

Voici la grille pragmatique que le billet aurait dû produire à la place de son enthousiasme uniforme.

Utilisez le HTML quand l’interactivité est la valeur : éditeurs jetables pour reprioriser, drag-and-drop, sliders pour ajuster des paramètres, playgrounds avec copy as prompt, prototypes d’animation avec exploration paramétrique. Pour ces usages, le HTML n’est pas un format, c’est un produit logiciel jetable, et il n’a pas de substitut.

Restez en markdown pour tout le reste : specs versionnées et revues en équipe, plans d’implémentation amendés au fil des sessions, rapports archivés, comptes-rendus de PR, documents lus une fois puis stockés, et surtout tout document destiné à être réingéré par un autre agent. Le markdown se diffe, se versionne, se porte, se transforme, se réingère. Il ne flatte pas l’œil, mais il sert la chaîne entière.

Ne générez jamais de HTML avec exécution JavaScript à partir d’un LLM ayant lu vos secrets de session, vos MCP authentifiés, vos fichiers locaux, sans audit préalable. La surface d’attaque par indirect prompt injection est trop réelle pour être ignorée. Au minimum, ouvrez ces fichiers dans un navigateur isolé, en mode incognito, sans extensions ni session active.

Et lisez les manifestes des ingénieurs d’Anthropic comme ce qu’ils sont : des signaux stratégiques bien écrits, dont la sincérité de l’auteur ne change rien à la fonction commerciale. Ce n’est pas une raison de les rejeter en bloc. C’est une raison de les passer au filtre que tout discours produit mérite, et que ma propre stack IA pour 2026 applique systématiquement avant d’adopter une pratique.

Le HTML maximalisme est une bonne idée appliquée à un mauvais périmètre, portée par un employé qui ne paie pas la facture qu’il prescrit. Sur les dix à quinze pour cent d’usages où il a raison, suivez le conseil. Sur les quatre-vingt-cinq pour cent restants, gardez votre markdown, gardez votre diff propre, gardez votre facture sous contrôle. Et gardez en tête que la prochaine best practice poussée par Anthropic mérite la même lecture critique que celle-ci.