HTML est le format que veulent les agents d’IA

Le 8 mai 2026, Thariq Shihipar, ingénieur travaillant sur Claude Code chez Anthropic, a publié sur son site personnel une collection de 20 artefacts HTML produits par un agent dans 9 catégories de travail intellectuel, avec une idée centrale : dès qu’une réponse porte une structure spatiale, une interaction ou une preuve visuelle, HTML surpasse Markdown.¹²

HTML surpasse Markdown pour les sorties d’agents parce que la structure spatiale, l’interaction et les preuves visuelles transmettent des informations que la prose aplatit. Le format émis par l’agent est la surface de contrôle que l’humain inspecte, pas un simple emballage autour d’elle.

L’article est paru 6 jours avant qu’un article arXiv du 14 mai montre que la qualité de recherche d’un agent se joue dans l’environnement d’exécution, pas dans le récupérateur.³ Le même motif apparaît : le format et l’environnement d’exécution sont le socle, pas l’emballage. Le composant ne compte vraiment qu’une fois la surface qui l’entoure capable de transformer la sortie du modèle en quelque chose qu’une personne peut vérifier.

TL;DR

Thariq Shihipar a publié un site compagnon avec 20 exemples HTML couvrant la revue de code, les systèmes de design, le prototypage, l’exploration, les schémas, la recherche, les rapports et les surfaces d’édition.¹ Sa thèse : Markdown linéarise des informations qui arrivent de manière spatiale. Les diffs, les graphes d’appels, les comparaisons côte à côte et les prototypes interactifs portent un sens que la prose aplatit. L’époque du lancement de GPT-4 avec 8K tokens a imposé Markdown comme option par défaut économe en tokens ; la documentation actuelle de Claude sur les fenêtres de contexte mentionne des modèles à 200K tokens et 1M token, ce qui change l’arbitrage pour de nombreuses tailles d’artefacts.⁴⁵ Pour les piles web sans build, rendues côté serveur, comme FastAPI avec HTMX, l’article apporte l’argument côté agent : HTML est à la fois le format que le modèle veut produire et celui que le navigateur sait déjà rendre. Passer par Markdown ajoute une étape de traduction qui fait perdre en fidélité aux deux extrémités.⁶

Points clés

Pour les créateurs d’agents : - Cessez d’utiliser Markdown par défaut pour les sorties d’agents quand la réponse est une comparaison, un diff, un organigramme ou une structure navigable. Demandez du HTML et laissez l’agent s’engager dans une mise en page spatiale.¹ - Traitez le format de sortie du modèle comme une partie de la surface de l’outil. Un artefact rendu d’un seul tenant s’inspecte mieux qu’une transcription qui défile et disparaît.⁷

Pour les designers d’interface : - HTML est le médium dans lequel votre système de design est déjà livré. Passer par Markdown introduit une étape de traduction qui perd en fidélité, puis une seconde au rendu.¹ - La surface de contrôle, c’est ce que produit l’agent. Si l’humain ne peut pas voir ce que l’agent a vu, cette surface est cassée.⁷

Pour les équipes qui utilisent des piles sans build rendues côté serveur : - Le pari de HTML plutôt qu’un pipeline de build est désormais validé côté agent. Le format que le modèle veut produire et celui que le navigateur rend déjà sont identiques.⁶ - Un site rendu côté serveur retire deux fois une couche de traduction : une fois à l’étape de build, une fois à l’étape de sortie de l’agent. Les deux suppressions se renforcent.

Ce que Thariq a vraiment soutenu

Shihipar travaille sur Claude Code chez Anthropic ; l’article se trouve sur son site personnel, pas sur le blog officiel d’Anthropic.² La galerie compagnon contient 20 fichiers HTML autonomes produits par un agent, regroupés en 9 catégories de travail où HTML surpasse structurellement Markdown.¹

Ses affirmations centrales :

La deuxième affirmation est décisive pour quiconque construit une infrastructure web. Si le système de design livre du HTML, l’agent doit produire du HTML. Tout autre choix introduit un aller-retour avec perte.

Les 20 exemples sont l’argument

Les catégories de la galerie de Shihipar couvrent le travail que beaucoup confient désormais à un agent de codage :¹

• Revue de code : diffs annotés avec notes en ligne codées par gravité ; cartes de modules avec chemins d’appels mis en évidence.
• Exploration : approches de code côte à côte ; options de design visuel disposées pour être choisies plutôt que lues séquentiellement.
• Design : pages vivantes de système de design ; planches de variantes de composants qui rendent réellement les variantes.
• Prototypage : bacs à sable d’animation avec de vraies courbes d’assouplissement ; parcours interactifs qui réagissent aux clics.
• Schémas : figures SVG intégrées ; organigrammes annotés ; croquis d’architecture en boîtes et flèches.
• Recherche : sections repliables ; explications interactives de concepts avec démonstrations en direct.
• Rapports : frises chronologiques et graphiques mis en forme où la structure porte le sens.
• Éditeurs : interfaces personnalisées avec fonctionnalité d’export intégrée à l’artefact.

Chacun est une page HTML produite par le modèle en une seule passe. Le motif commun : la réponse est spatiale ou interactive, et l’artefact rendu préserve ce qu’une réponse Markdown devrait décrire en prose.

Pourquoi Markdown était le choix par défaut

Markdown s’est imposé comme format par défaut des sorties d’agents pour 2 raisons qui ne tiennent plus.

D’abord, la génération GPT-3.5 et GPT-4 travaillait avec des fenêtres de contexte de 4K à 8K tokens au moment où la convention de sortie par chat s’est consolidée.⁴ La concision de Markdown était une contrainte réelle : un token dépensé dans <div class="..."> n’était plus disponible pour l’analyse. La documentation actuelle de Claude sur les fenêtres de contexte mentionne des contextes à 200K tokens pour de nombreux modèles et à 1M token pour Opus 4.1 et Sonnet 4.6.⁵ Pour beaucoup d’artefacts d’inspection, l’argument de l’efficacité en tokens s’est affaibli.

Ensuite, les rendus de terminal et les fenêtres de chat affichent Markdown sans effort, tandis que HTML exige une webview ou un onglet de navigateur. Cette commodité de surface a maintenu Markdown comme voie de moindre résistance, même après l’érosion de l’argument des tokens.

L’article de Shihipar a du poids parce que son auteur travaille sur Claude Code chez Anthropic. Les 20 exemples sont des artefacts concrets, pas des affirmations abstraites.² La couverture de Simon Willison le même jour a reproduit le motif avec une explication d’un exploit de sécurité Linux rendue sous forme de page HTML interactive, plutôt que comme un article Markdown.⁸

Ce que HTML préserve et que Markdown perd

4 propriétés portent l’argument :

Chaque propriété correspond à une classe de tâches d’agent qui devient plus difficile quand vous aplatissez la sortie en prose. Un diff est une comparaison spatiale ; un organigramme est un graphe ; une revue de système de design est un jugement visuel. Les forcer à passer par Markdown oblige le lecteur à reconstruire ce que le moteur de rendu aurait pu montrer.

Le lien avec l’environnement d’exécution

La qualité de recherche des agents se joue dans l’environnement d’exécution, pas dans le récupérateur. Cet article soutenait que la méthode de récupération compte moins que le cadre qui l’entoure : forme du prompt, surface d’outil, formatage de la transcription, livraison des résultats, comportement de nouvelle tentative.³

L’argument HTML étend ce cadre à la sortie. Le modèle peut produire la bonne réponse dans n’importe quel format. Le format que vous demandez fait partie du contrat d’exécution. Des formats différents produisent des surfaces vérifiables différentes :

• Livraison Markdown : l’utilisateur lit de haut en bas, décide de ce qui compte et reconstruit mentalement la structure.
• Livraison HTML : le modèle s’engage dans une structure, le rendu la rend parcourable, et l’utilisateur inspecte au lieu de lire.

Mêmes données, surface de contrôle différente. Concevoir pour les agents, c’est concevoir des surfaces de contrôle. Le format émis par l’agent fait partie de cette surface ; ce n’est pas un emballage autour d’elle.⁷

Ce que cela signifie pour la pile sans build

Le guide FastAPI avec HTMX de ce site défend le HTML rendu côté serveur plutôt qu’un pipeline de build JavaScript.⁶ L’article de Shihipar apporte l’argument côté agent :

• Le modèle veut produire du HTML.
• Le navigateur veut rendre du HTML.
• Insérer Markdown ou JSX entre les deux ajoute 2 étapes de traduction avec perte.

Un site sans build rendu côté serveur retire la traduction au moment du build. Produire directement du HTML depuis l’agent retire la traduction au moment de la sortie. Le gain se cumule : le même format circule du modèle à la route puis au navigateur, sans formes intermédiaires.

Cela ne revient pas à dire que React ou Markdown sont toujours mauvais. Cela signifie que le coût des étapes de traduction est désormais visible aux deux extrémités, et qu’une pile qui les évite des deux côtés devient plus simple d’autant.

Le format compte. L’environnement d’exécution compte. Les deux sont le socle.

L’article sur la recherche agentique et l’article sur HTML sont arrivés à 8 jours d’intervalle et dessinent la même forme :¹³

• Le récupérateur est un composant. L’environnement d’exécution est le socle.
• Le modèle est un composant. Le format de sortie est le socle.

Penser en composants pousse vers des améliorations locales : changer de récupérateur, ajouter de la mémoire, remplacer le modèle, affiner le prompt. Penser en socle change la surface que l’utilisateur voit et celle que l’agent produit. Les deux constats de cette semaine poussent le travail vers le second cadre.

Le geste pratique : quand une réponse d’agent porte une information spatiale, demandez du HTML. Quand l’agent tourne dans un cadre d’exécution, instrumentez ce cadre avant d’instrumenter le modèle. Les deux gestes se renforcent. Aucun n’est une solution miracle à lui seul.

FAQ

Anthropic a-t-il publié cet article ?

Non. Thariq Shihipar l’a publié sur son site personnel, thariqs.github.io/html-effectiveness/.¹ Il travaille sur Claude Code chez Anthropic, ce qui constitue un signal d’autorité fort, mais l’article n’est pas une publication d’Anthropic.²

L’argument vaut-il pour toutes les tâches d’agent ?

Non. L’article vise explicitement les travaux où la structure spatiale, l’interaction ou la preuve visuelle portent du sens. Pour les réponses factuelles courtes ou les sorties destinées au terminal, Markdown reste un bon choix par défaut.¹

Et le coût en tokens ?

L’argument de coût en faveur de Markdown était lié aux petites fenêtres de contexte. La documentation actuelle de Claude sur les fenêtres de contexte mentionne des modèles à 200K tokens et 1M token, ce qui modifie l’arbitrage lié à la verbosité de HTML pour les tailles d’artefacts mises en avant par l’article.⁵

Cela casse-t-il les paramètres Markdown existants de Claude Code ?

Non. L’argument porte sur les sorties que vous demandez au modèle de produire à la demande pour inspection, pas sur la transcription ou la sortie terminal. Vous pouvez toujours demander du HTML dans un simple prompt et recevoir un artefact autonome en retour.¹

Quel est le lien avec l’article sur l’environnement d’exécution de la recherche agentique ?

Les deux arguments pointent vers le socle autour du modèle plutôt que vers le modèle lui-même. La qualité de recherche dépend du cadre d’exécution ; la qualité de sortie dépend du format. Le composant est nécessaire ; le socle est ce qui rend ce composant fiable.³

Que doit faire une équipe FastAPI avec HTMX ?

Traitez HTML comme une cible de sortie de premier ordre pour toute fonctionnalité d’IA que vous livrez. Le même format circule du modèle à la route puis au navigateur, et la pile sans build optimise déjà ce chemin.⁶

Références