"L'IA écrit tellement long que je ne le lis pas vraiment correctement 😅"
"Je paie plus de 15 000 yens par mois pour Claude Code, mais j'ai l'impression de ne pas en avoir pour mon argent."
Beaucoup de gens sont satisfaits du simple fait d'utiliser l'IA, mais seuls quelques-uns transforment réellement cette utilisation en résultats. C'est un état de « j'ai l'impression de l'avoir utilisé ».
Avez-vous déjà vécu ces expériences avec Claude Code ?
- Vous lui demandez de « résumer les tendances de la concurrence de la semaine dernière » le lundi matin, et il vous renvoie un long rapport. Vous y jetez un coup d'œil et le laissez sans le lire.
- Vous soupçonnez que si vous ne lisez pas correctement les documents générés par l'IA, vos collègues ne les lisent pas non plus.
- Vous payez plus de 3 000 yens par mois pour Claude Code, mais les résultats n'ont jamais été utilisés dans une réunion ou une proposition.
- Les résultats de ChatGPT et Claude.ai sont beaux, mais pourquoi Claude Code ne produit-il que du Markdown, ce qui le rend si pénible à lire ?
Cet article est pour ces personnes.
Quand vous aurez fini de le lire, vous serez capable de générer naturellement des documents à partir de Claude Code que vous et les autres lirez réellement.
Vous repartirez également avec cette perspective : « le format dans lequel vous produisez » est un facteur bien plus important dans le jugement de l'utilisateur que « ce que vous demandez à Claude Code de faire ».
Thariq Shihipar (@trq212), un développeur chez Anthropic qui construit réellement Claude Code, a écrit sur X à propos d'un état d'esprit qui se répand au sein de l'entreprise, et ce post est devenu l'un des plus sauvegardés et partagés de la communauté Claude Code.
Il a reçu un énorme succès dès sa publication.
Ce n'est pas juste un petit conseil pour les passionnés d'IA ; c'est l'histoire de la personne qui a construit l'outil qui remet en question le Markdown, qui était la norme implicite de l'industrie de l'IA, en disant « ce n'est plus la voie à suivre ».
J'ai pensé que c'était important, alors j'ai décidé de l'expliquer immédiatement en japonais.
Deux choses avant de commencer à lire :
- Mettez ceci en favori. Rien que pour cette semaine, dégagez du temps pour essayer de produire en HTML.
- Si vous avez des collègues qui utilisent Claude Code, partagez-leur ceci. La façon dont vos rapports hebdomadaires et vos revues de PR sont « lus » changera visiblement à partir de la semaine prochaine.
Je vais décomposer et expliquer le contenu tout en le traduisant pour qu'il fonctionne dans le contexte des affaires japonaises 👇
Post original ici :
https://x.com/trq212/status/2052809885763747935
Le développeur d'Anthropic lui-même n'utilise plus le Markdown
C'est le point de départ. Thariq Shihipar (@trq212), qui a écrit le post original, est le développeur qui construit Claude Code chez Anthropic. Le comportement où Claude pose des questions à l'utilisateur en « mode plan » pour affiner les exigences est une fonctionnalité qu'il a lui-même implémentée.
Il dit qu'il n'accepte plus le Markdown de l'outil qu'il construit. Selon ses propres mots, le Markdown est devenu un format restrictif pour lui.
Ce n'est pas seulement une préférence personnelle. Thariq mentionne que l'adoption du HTML se répand au sein même de l'équipe Claude Code. Les personnes qui fabriquent l'outil abandonnent le Markdown qu'il produit et passent au HTML.
Et la preuve est tangible. Sur le site de démonstration https://thariqs.github.io/html-effectiveness/https://thariqs.github.io/html-effectiveness/), il y a 20 exemples HTML autonomes. Une comparaison de trois approches pour la recherche avec debounce, des micro-interactions qui créent un sentiment d'accomplissement pour l'achèvement de tâches, des listes de tokens de système de design, des explications à onglets pour des exemples de code, et du matériel de lecture avec un glossaire dans les marges. Tous sont des exemples concrets de remplacement de « documents que vous survolez » par « documents qui sont lus jusqu'au bout ». Vous pouvez les ouvrir dans votre navigateur dès maintenant.
En lisant cela, vous devriez réaliser quelque chose. Les Artifacts que vous recevez habituellement dans ChatGPT ou Claude.ai — ces « interfaces avec onglets », « diagrammes colorés » et « boutons interactifs » — sont en fait produits en HTML. La prise de conscience ici est : « La raison pour laquelle ils avaient si belle allure était la différence de format lui-même. » Maintenant, ce même monde peut être amené à portée de main avec Claude Code.
Jusqu'à présent, le texte généré par l'IA était presque exclusivement du Markdown. La personne qui le construit commence discrètement à s'y opposer, en disant « plus maintenant ». C'est le cœur de l'actualité. Mais pour vous, qui travaillez avec l'IA tous les jours, c'est une histoire qui sera efficace dès lundi matin.
Le Markdown était la norme implicite de l'industrie de l'IA
Confirmons les hypothèses que nous tenions pour acquises. Sans cela, le passage au HTML pourrait ressembler à une simple question de goût.
Jusqu'à présent, le Markdown était le standard de facto pour les sorties de l'IA. Repensez au texte que vous voyez tous les jours :
- CLAUDE.md à la racine du projet, *.md pour les définitions d'agents, SKILL.md pour les Skills.
- La documentation officielle d'Anthropic, l'Aide de Claude.ai, et divers guides Claude Code.
- Les outils de développement d'IA concurrents, les règles Cursor, les instructions GitHub Copilot, et les instructions Cline sont tous basés sur .md.
- Les Wikis internes, les README GitHub, le texte exporté de Notion, et les comptes rendus de réunion collés dans Slack.
- Le texte de résumé copié depuis les conversations ChatGPT.
Tout a été construit sur l'hypothèse du Markdown. Il est plus difficile de trouver un format autre que le Markdown dans les informations textuelles que vous rencontrez lorsque vous traitez avec l'IA.
Le phénomène du modèle CLAUDE.md de Karpathy qui a recueilli plus de 80 000 étoiles sur GitHub s'est produit précisément parce que le Markdown était le langage commun de l'industrie.
Pour reprendre les mots de Thariq, le Markdown est devenu le format dominant pour les agents. C'est quelqu'un qui a construit des outils sur la base du Markdown pendant longtemps.
Cette personne a maintenant clairement déclaré : le Markdown est devenu un format restrictif pour moi. C'est le moment où un initié d'Anthropic a jeté une pierre dans la mare de la prémisse sur laquelle toute l'industrie surfait.
Pour le dire simplement : le Markdown que vous obtenez de Claude Code, les règles que Cursor lit, et les sorties d'IA sur votre Wiki interne faisaient tous partie du même flux « le Markdown, ça va ». La personne qui l'a créé a commencé à tracer un canal différent.
À partir de là, nous allons entrer dans le détail des raisons pour lesquelles le Markdown n'atteint pas les gens et par quoi le remplacer.
5 raisons pour lesquelles le Markdown n'est pas lu
Organisons les limites du Markdown. Il ne s'agit pas de spécifications techniques, mais de votre expérience quotidienne du lundi au vendredi. J'ai listé les avantages du HTML de l'article original en les inversant pour montrer les faiblesses du Markdown.
① S'il dépasse 100 lignes, même vous ne le lirez pas
Thariq lui-même écrit que lorsqu'un fichier Markdown dépasse 100 lignes, il arrête de le lire.
Quand vous demandez à Claude Code de « résumer les tendances de la concurrence de la semaine dernière », vous avez probablement déjà vécu l'expérience de fermer la réponse de 120 lignes sans faire défiler. Si la personne qui l'a généré ne le lit pas, personne dans l'équipe ne le fera. La réalité est que non seulement l'auteur, mais aussi les autres membres de l'organisation, ne font que survoler.
② Même partagé, il ne s'ouvre pas joliment dans un navigateur, donc personne n'y touche
Le Markdown n'est pas rendu joliment nativement dans les navigateurs. Les sauts de ligne cassent dans Slack, la mise en forme est ruinée dans les e-mails, et il faut des efforts pour le convertir en PDF ou faire des captures d'écran pour des propositions.
Chaque fois que vous partagez, quelqu'un doit faire le travail de le convertir en une « forme lisible ». Le Markdown est un format qui crée des frictions à chaque partage, au point que les liens ne sont souvent même pas cliqués.
③ Pas de couleurs ni de diagrammes, donc seul le contour est transmis
Vous voulez souligner une différence de chiffres, montrer un avertissement en rouge, ou montrer un flux avec des flèches. Pour faire cela en Markdown, vous finissez par dessiner des diagrammes avec des caractères ASCII ou exprimer des couleurs avec des caractères de dessin de boîte Unicode.
Personne ne veut déchiffrer cela, et l'auteur se fatigue. Même si Claude essaie de dessiner un diagramme, il finit par être survolé.
④ Vous ne pouvez pas toucher ni déplacer, donc ça se termine par une simple lecture
Vous voulez essayer une couleur un peu plus calme, tester la vitesse d'une animation, ou voir à quoi ça ressemble si vous augmentez une valeur de 1,5 fois.
Dans les affaires, il y a des situations fréquentes où vous devez « essayer » pour prendre une décision. Vous ne pouvez pas faire cela avec du Markdown. Vous lisez, simulez dans votre tête, puis renvoyez des instructions par texte — une boucle inefficace.
⑤ Ça casse quand on l'ouvre sur mobile
Slack, e-mail ou Notion en déplacement. Dans le contexte des affaires japonaises, la moitié des documents partagés sont d'abord ouverts sur mobile.
Les mises en page Markdown ne suivent pas la largeur de l'écran. Les tableaux débordent horizontalement, les blocs de code sont coupés maladroitement, et les hiérarchies de titres deviennent invisibles. L'envie de lire disparaît à ce moment-là.
Donnons un nom à cela. Chaque fois que vous produisez du Markdown non lu, une fatigue s'accumule à la fois pour l'expéditeur et le destinataire avant même de l'ouvrir. Le coût de faire défiler 100 lignes, de corriger les sauts de ligne dans Slack, l'échec de communication dû au manque de diagrammes et de couleurs, le retard de jugement parce que vous ne pouvez pas interagir, et la casse sur mobile.
Tous ces éléments sont des frais cachés payés chaque jour. Dans cet article, nous appelons cela la « Taxe de Format ».
Ce n'est pas une petite taxe. Plus de la moitié de la valeur de Claude Code est déterminée non pas par le contenu de la sortie, mais par « qui elle atteint et jusqu'où ». En produisant dans un format qui n'atteint pas les gens, vous jetez essentiellement la moitié de votre abonnement.
Comment basculer : ajoutez simplement « Produire en tant que fichier HTML »
Vous n'avez pas besoin de trop réfléchir. Il y a beaucoup moins à faire que vous ne le pensez.
Ajoutez simplement une ligne à la fin de votre demande habituelle à Claude Code. Les trois suivantes signifient la même chose :
- « Produire en tant que fichier HTML »
- « Produire en tant que HTML d'une seule page »
- « Faites-le en HTML pour que le lecteur puisse l'ouvrir directement »
Si vous êtes plus à l'aise pour écrire en anglais, « make a HTML file » ou « make a HTML artifact » convient. Le résultat est le même.
Claude Code peut tirer du contexte de MCP, des navigateurs, de git et du système de fichiers. La force de Claude Code est qu'il peut regrouper des sources d'information bien plus larges dans un seul HTML que les versions web chat de ChatGPT ou Claude.ai.
Cela rejoint ce dont nous avons parlé plus tôt. Les Artifacts que vous receviez dans ChatGPT ou Claude.ai et que vous trouviez « beaux » étaient produits en HTML.
Vous pouvez maintenant recevoir ce même monde du côté de Claude Code. Ce n'est pas une histoire technique difficile ; en changeant une ligne dans votre façon de demander, des documents qui atteignent réellement les gens sortiront.
Thariq insiste sur un point dans son article : « Je ne veux pas que cela soit transformé en Skill /html tout de suite ; je veux que les gens s'y habituent d'abord via les prompts. » Et ce, malgré le fait qu'il soit un développeur de l'équipe Claude Code qui produit des Skills.
Il ne rejette pas l'idée d'en faire un Skill. Il dit : « Si vous le conditionnez avant que l'usage ne soit solidifié, vous manquerez les parties qui sont vraiment efficaces. »
Chez Anthropic, les sorties HTML qui sont devenues fréquentes commencent à être composantées sous forme de plugins Playground. Au lieu d'attendre un produit fini dès le départ, essayez d'abord avec un prompt d'une ligne pour trouver le modèle qui correspond à votre travail. Ce n'est qu'après avoir atteint ce point que vous devriez passer à la création d'un Skill.
Écrire « produire en HTML » dans chaque prompt peut sembler une tâche, mais choisir le format lui-même n'en est pas une. Au moment où vous passez de Claude produisant du Markdown à Claude produisant du HTML, vous avez fait un demi-pas vers celui qui « conçoit la sortie avant d'attendre un Skill préconçu ».
5 scénarios métier qui changent simplement en passant au HTML
Ce chapitre est efficace pour le travail réel du lundi au vendredi. J'ai réorganisé les cinq cas d'utilisation de l'article original par ordre de fréquence dans le contexte des affaires japonaises : Rapports hebdomadaires / Résumés de recherche, Comparaison parallèle de propositions, Ajustements de design, Écrans d'édition pour la prise de décision, et Revues de PR / Spécifications.
Chaque scénario est résumé avec le problème actuel, l'Avant/Après, et enfin un exemple d'instruction à donner à Claude Code.
[Scénario 1] Livrer des rapports hebdomadaires et des résumés de recherche avec des diagrammes
Un phénomène courant dans les affaires japonaises. Lundi matin, votre patron demande : « Résume les tendances de la semaine dernière. »
Avant : Vous collez 120 lignes de Markdown dans Slack. Les sauts de ligne cassent. Votre patron ne l'ouvre pas. Cela n'est pas inclus dans les supports de réunion de direction. Vous finissez par l'expliquer verbalement, en disant : « J'ai fait faire ça par Claude. »
Après : Vous résumez le tout dans une seule page HTML intégrant les logs Slack, l'historique des tickets Linear ou Notion, les logs git et les documents internes. Vous incluez un simple diagramme de flux métier en SVG et placez trois points clés dans des blocs colorés en bas.
Si vous mettez cela dans un stockage interne et partagez l'URL, votre patron peut l'ouvrir sur son téléphone pendant les trajets, la direction peut le citer, et il peut être collé dans les comptes rendus de réunion.
Le point clé ici est que Claude Code peut tirer du contexte de MCP, des navigateurs, de git et du système de fichiers. Même si vous demandez à un chat web de « faire un HTML », il est difficile de regrouper autant de sources d'information en un seul. C'est un rapport hebdomadaire que seul Claude Code peut créer.
Thariq lui-même a écrit qu'il a réalisé les diagrammes de ses articles en faisant lire à Claude Code tout le HTML de son dossier de code et en les résumant en une seule page. Un « rapport hebdomadaire qui est lu » et un « diagramme pour un article explicatif qui est lu » sont structurellement identiques.
▼ Exemple d'instruction :
« Lis toutes les interactions Slack de la semaine dernière, les tickets Linear terminés et les logs git, et produis un rapport hebdomadaire sous forme d'une seule page HTML que mon patron peut comprendre en 1 minute. Inclus un simple diagramme de flux métier en SVG et trois points clés dans des blocs colorés en bas. Assure-toi que ça ne casse pas quand on l'ouvre sur un smartphone. »
[Scénario 2] Montrer 6 options de proposition/recherche côte à côte
Quelle direction prendre pour la proposition de la semaine prochaine ? Une scène courante dans la planification, les ventes et la planification d'entreprise où plusieurs options sont créées et alignées avec les décideurs.
Avant : Vous envoyez six options dans six fichiers Markdown séparés. Le client ne peut pas les ouvrir et les comparer un par un. Ils demandent : « Laquelle est votre recommandation principale ? » et vous réalisez que vous ne les aviez pas complètement comparées vous-même.
Après : Vous disposez six options avec des tons, des densités et des publics cibles différents dans une grille sur une seule page HTML. Vous ajoutez une ligne de compromis sous chaque option. Le décideur les compare toutes sur un seul écran et répond immédiatement : « Je veux mélanger ceci et cela » ou « Utilise le public cible de #3 avec la densité de #1. » La résolution de la discussion change au moment où vous les montrez en parallèle.
Pour un décideur, le temps nécessaire pour juger est radicalement différent entre recevoir six fichiers et avoir six options alignées sur un seul écran. Il s'agit moins de « les faire lire » que de « leur permettre de prendre une décision ».
▼ Exemple d'instruction :
« Crée 6 options de proposition pour la présentation de la semaine prochaine avec des tons, des densités et des publics cibles différents, et dispose-les dans une grille sur une seule page HTML. Écris une ligne de compromis sous chaque option. Ajoute également un bouton en bas pour copier le résultat en Markdown une fois la décision prise. »
[Scénario 3] Décider des designs et des prototypes en les touchant
Quand il s'agit de décider des couleurs, des tailles ou des mouvements, il faut abandonner l'idée de s'aligner par le texte. C'est une scène où le marketing, les RP et la planification font des allers-retours nombreux sur des e-mails de remerciement ou des boutons de page d'atterrissage.
Avant : Vous communiquez avec des mots comme « un bleu un peu plus calme » ou « rends le mouvement plus doux ». L'image du destinataire dévie à chaque fois. En regardant la version qui revient après un tour, vous ajoutez plus de mots : « Non, pas ce genre de calme. »
Après : Vous demandez à Claude Code de créer un HTML où vous pouvez déplacer des curseurs pour la couleur et la vitesse d'animation. Vous créez des prototypes pour les boutons d'e-mail de remerciement ou les boutons CTA de page d'atterrissage sous forme de pages HTML uniques et envoyez l'URL aux parties prenantes. Tout le monde touche, décide des meilleures valeurs, et copie simplement ces valeurs dans Claude. Les allers-retours textuels diminuent et le temps de consensus se raccourcit.
En lien avec cela, Anthropic Labs commence à formaliser ce concept de « toucher pour décider et copier l'opération dans Claude » en tant que plugin Playground. La sortie HTML n'est pas qu'une petite astuce ; c'est une direction qu'Anthropic elle-même cultive en tant que modèle.
▼ Exemple d'instruction :
« Crée un HTML où je peux décider de la couleur et de la vitesse d'animation du bouton dans l'e-mail de remerciement à l'aide de trois types de curseurs. Ajoute un bouton en bas pour copier les valeurs décidées. »
[Scénario 4] Créer un écran de décision en 3 minutes
Quelles mesures attribuer à Maintenant, Ensuite, Plus tard ou Abandonner pour le prochain trimestre ? Trier 30 tickets pour décider des priorités est une « tâche de jugement » typique pour les PdM, les planificateurs et la planification d'entreprise.
Avant : Vous alignez 30 éléments dans un tableur et remplissez manuellement la colonne de priorité une par une. Vous triez, repensez, déplacez vers une autre feuille, et revenez. Certains jours, vous passez 30 minutes et n'avez toujours pas de conclusion.
Après : Vous demandez à Claude Code de « créer un HTML où je peux glisser-déposer des éléments dans quatre colonnes : Maintenant, Ensuite, Plus tard et Abandonner. » Un écran d'édition dédié est prêt en 3 minutes. Vous faites glisser les 30 cartes, et quand vous avez fini, vous copiez les résultats. Le temps pour les tâches de jugement est réduit d'un ordre de grandeur.
Il y a ici un principe de conception facile à négliger mais très efficace. C'est la phrase où Thariq écrit : « Terminez toujours par une exportation. » Lorsque vous créez un écran d'édition, incluez toujours des boutons pour « Copier en JSON », « Copier en Prompt » ou « Copier en Markdown ».
Sans cela, vous ne pouvez pas renvoyer les résultats de votre tri à Claude, et cela reste un simple outil de tâche. Un écran d'édition ne devient un dispositif de jugement que lorsque vous créez une boucle : juger en HTML, puis renvoyer le résultat textuel structuré à Claude.
Cette même idée peut être utilisée pour éditer des feature flags, des éditeurs de prompt système côte à côte, ou des jeux de données approuver/rejeter/étiqueter. « Créer une interface utilisateur dédiée et jetable en 3 minutes » est l'endroit où la vraie valeur de Claude Code est la plus clairement démontrée.
▼ Exemple d'instruction :
« Crée un HTML où je peux glisser-déposer 30 mesures pour le prochain trimestre dans quatre colonnes : Maintenant, Ensuite, Plus tard et Abandonner. À la fin, place un bouton 'Copier en Markdown' pour que je puisse produire les résultats du tri avec les raisons pour chaque ligne. »
[Scénario 5] Transmettre les revues de PR et le partage de spécifications avec des diffs colorés
Enfin, un scénario pour collaborer avec les ingénieurs. Même si vous ne lisez pas de code, en tant que PdM, directeur ou éditeur, vous pouvez être sollicité pour des revues de PR ou des confirmations de spécifications.
Avant : On vous demande d'ouvrir l'écran de diff GitHub. Vous ne pouvez pas dire quelle partie du diff est importante et laquelle peut être ignorée simplement en regardant. Vous devez lire les commentaires pour suivre l'histoire. Les personnes qui ne lisent pas de code disent souvent « faites-moi savoir s'il y a quelque chose » et ferment.
Après : Vous demandez à Claude Code de « transformer cette PR en un document de revue HTML qu'une personne qui ne lit pas de code peut comprendre en 30 secondes. » Les commentaires sont attachés à côté des diffs, le périmètre d'impact est coloré, et un résumé de trois préoccupations est fourni à la fin. Si vous téléchargez cela dans un stockage interne et partagez l'URL, les PdM et les directeurs peuvent fournir des commentaires en un clic. Ceux qui collaborent avec les ingénieurs peuvent enfin participer aux revues.
Le HTML n'est pas un langage pour les ingénieurs ; c'est un outil pour délivrer une histoire. La signification du diff, les risques et le périmètre d'impact — cette « information qui nécessite un déchiffrement » est livrée avec des annotations, de la couleur et une mise en page. C'est le sens de la conversion en HTML.
▼ Exemple d'instruction :
« Transforme cette PR en un document de revue HTML qu'une personne qui ne lit pas de code peut comprendre en 30 secondes. Attache des commentaires à côté des diffs, montre le périmètre d'impact avec un code couleur, et résume trois préoccupations à la fin. »
Pendant que vous continuez à produire en Markdown pour ces cinq scénarios, la taxe de format s'accumule silencieusement mais quotidiennement. Que vous l'arrêtiez au moment où vous le remarquez fera la différence à partir de la semaine prochaine.
6 questions qui se posent lors du basculement
En lisant cela, plusieurs questions vous viennent probablement à l'esprit. J'ai réorganisé la section FAQ de l'article original dans l'ordre où les lecteurs japonais sont susceptibles de les rencontrer.
■ Cela utilise-t-il plus de tokens ?
Oui, c'est le cas. L'article original indique que la génération prend 2 à 4 fois plus de temps que le Markdown. Cependant, Opus 4.7 a un contexte de 1 million de tokens, donc le risque de conversations interrompues en raison des limites de contexte liées au retour de HTML est pratiquement éliminé.
La conclusion de Thariq est : « Les chiffres augmentent, mais si vous choisissez le résultat qui est lu, cela paie pour le travail total. » C'est un choix entre utiliser votre contrat de plus de 3 000 yens par mois pour 1 000 lignes de Markdown non lu ou une page de HTML qui est ouverte.
■ Le design ne sera-t-il pas moche ?
C'est une préoccupation valable, mais il existe des contre-mesures.
L'une d'elles est d'utiliser les plugins de design frontend de Claude Code. Une autre est de fournir à Claude un exemple de HTML provenant du site de votre entreprise ou de documents existants. Si vous fournissez un fichier de référence et dites « dans ce ton » ou « avec cette police et cette palette », Claude produira un HTML qui correspond à l'apparence de votre entreprise. Garder un fichier comme design-system.html dans votre base de code vous permet de le référencer à chaque fois.
■ N'est-ce pas pénible d'éditer du HTML ?
Vous n'avez pas besoin de l'éditer vous-même.
Thariq lui-même écrit qu'il ne touche pas directement au HTML. Si vous dites à Claude : « Calme un peu cette couleur » ou « Rends la troisième section un peu plus petite », il corrigera pour vous. Tant que vous l'utilisez pour des spécifications, du brainstorming ou des documents de référence, vous pouvez laisser toute l'édition à Claude.
■ Comment l'ouvrir ? Comment le partager ?
L'ouvrir est facile. Ouvrez simplement le fichier HTML que Claude Code a produit localement dans votre navigateur.
Vous pouvez même demander à Claude d'« ouvrir ce fichier », et il pourrait l'ouvrir dans votre navigateur pour vous. Pour le partager, le plus simple est de le télécharger dans un stockage interne ou sur S3 et de fournir l'URL. Si vous collez le lien dans Slack ou un e-mail, le destinataire peut l'ouvrir dans son navigateur. Cette étape supplémentaire de conversion du Markdown en PDF disparaît complètement.
■ Qu'en est-il du contrôle de version ?
Pour être honnête, le HTML n'est pas très adapté à la gestion des diffs Git. Corriger une ligne peut déplacer les diffs ailleurs en raison des paramètres du formateur. Thariq lui-même écrit que le HTML est la plus grande faiblesse du contrôle de version.
C'est pourquoi la solution pratique est : les « livrables pour les personnes » sont en HTML, et les « spécifications ou enregistrements dont vous voulez conserver l'historique » sont en Markdown. Il ne s'agit pas d'abolir le Markdown, mais de passer à un état d'esprit de choix du format en fonction de l'objectif de la sortie.
■ Puis-je arrêter complètement d'utiliser le Markdown ?
Non. Les enregistrements, les historiques de modifications et le texte structuré que vous souhaitez conserver dans le dépôt doivent rester en Markdown.
CLAUDE.md et SKILL.md sont plus faciles à gérer et à suivre les diffs s'ils restent en Markdown. Le HTML est adapté pour « livrer aux personnes », « laisser les gens toucher », « aligner plusieurs options » et « laisser les gens juger avec des couleurs ». Si vous comprenez globalement que « le Markdown est pour interagir avec l'IA, le HTML pour distribuer aux personnes », vous ne vous perdrez pas.
À présent, vos doutes initiaux devraient être dissipés. Un article qui inclut des inconvénients est plus digne de confiance — c'est ma conviction en tant qu'écrivain.
Allez-vous continuer à payer la taxe de format ou passer du côté du design ?
Enfin, élevons notre perspective pour conclure.
Nous avons déjà parlé de la « Prompt Tax » – le coût de retaper les mêmes prémisses à Claude. Ensuite, l’histoire du passage à la couche de conception avec le dossier .claude. Cette « Format Tax » est le troisième thème de cette série. Après la couche de conversation et la couche de conception, nous avons maintenant abordé la couche de sortie.
Définissons la « Format Tax » comme quelque chose que nous pouvons partager avec les lecteurs :
Si vous continuez à choisir des formats de sortie qui ne sont pas lus, la fatigue s'accumule pour vous et pour les autres avant même l'ouverture. Vous payez plus de 3 000 yens par mois pour Claude Code, mais les livrables ne sont jamais utilisés en réunion. Ce sentiment vient du fait de ne pas faire de choix sur la sélection du format. C'est la Format Tax.
Produire en Markdown est une tâche. Choisir le HTML est un jugement. Même en utilisant le même Claude Code, un seul jugement dans la sélection du format change considérablement la portée de vos livrables.
Et le HTML n’est pas un langage pour les ingénieurs. C’est un outil pour créer des documents qui sont lus. Mettez de côté l’idée de construire un site web pour un instant. Essayez simplement de produire le rapport hebdomadaire, la proposition ou le document de révision que vous écrivez cette semaine en HTML. Cela suffit.
Parlons de la vue d’ensemble.
L’ère où le Markdown était le standard implicite de l’industrie de l’IA se termine discrètement chez Anthropic. Alors que CLAUDE.md, SKILL.md et les règles Cursor étaient tous construits sur une prémisse Markdown, le format de sortie commence à changer en premier. Les lecteurs qui assistent au moment où le standard change peuvent prendre une demi-longueur d’avance.
Bien sûr, une fois que vous réalisez « Je fais cela chaque semaine », vous pouvez alors choisir de l’évoluer en une Skill.
Chez Anthropic, les modèles à haute fréquence de sortie HTML, comme les Playgrounds liés au design, sont progressivement cultivés en tant que composants. Cependant, pour la première semaine, une invite d’une seule ligne suffit. Ce soir, essayez de produire un seul rapport hebdomadaire en HTML. La semaine prochaine, essayez d’aligner six options de proposition dans une seule grille. Commencez par là, et la format tax commencera discrètement à diminuer.
Thariq lui-même écrit à la fin de son article : « J’avais peur d’arrêter la lecture approfondie du Markdown et de laisser entièrement les jugements à Claude. Depuis que je suis passé au HTML, j’ai l’impression d’être de retour dans la boucle avec Claude, et surtout, c’est tout simplement amusant de créer. »
Choisir un format est un interrupteur pour reprendre l’initiative lorsque l’on travaille avec l’IA, et en même temps, un interrupteur pour apporter un peu de chaleur à votre travail quotidien.
Allez-vous continuer à produire du Markdown non lu, ou allez-vous passer du côté de ceux qui choisissent le format ? La semaine prochaine sera la frontière.
Résumé
- Le développeur qui construit Claude Code chez Anthropic a déclaré qu’il n’utilise plus le Markdown. L’adoption du HTML se répand au sein de l’équipe interne.
- Jusqu’à présent, le Markdown était le standard implicite de l’IA – de Claude Code et Cursor à GitHub Copilot, Cline, les Wikis internes et les sorties ChatGPT. Le créateur a maintenant remis en cause ce standard industriel.
- Il y a 5 raisons pour lesquelles le Markdown n’est pas lu : impossible de relire à 100 lignes / se casse lors du partage / pas de couleur ni de diagrammes / impossible de toucher pour juger / se casse sur mobile. Ces coûts cachés sont la « Format Tax ».
- Pour basculer, ajoutez simplement une ligne : « Produire en tant que fichier HTML. » Faire de cela une Skill peut attendre que l’utilisation soit solidifiée.
- 5 scénarios métier – rapports hebdomadaires, propositions parallèles, ajustements de design, écrans de jugement et revues de PR – se transforment en documents qui sont ouverts, jugés et retournés simplement en passant au HTML.
- Choisir un format est un jugement, pas une tâche. Produire en Markdown est une tâche ; choisir le HTML est un jugement. La différence entre les utilisateurs de Claude Code se creuse ici.
Pour ceux qui ont trouvé cet article utile :
Le Laboratoire Claude Code de l’Université de Tokyo (@ClaudeCode_UT) est un compte géré sérieusement par une équipe d’étudiants de l’UTokyo. Nous travaillons également sur le développement commercial conjoint de Claude Code avec de grandes entreprises, et nous ne partageons que des designs et des savoir-faire qui fonctionnent réellement sur le terrain.
Nous livrons chaque jour des informations et des savoir-faire « vraiment utiles » spécialisés pour le travail pratique 👇
■ Libération gratuite de compétences Claude Code utilisables en pratique
■ Traduction et restructuration des informations primaires sur l’IA à l’étranger dans un contexte commercial japonais
■ C’est le seul endroit pour recevoir gratuitement des compétences et des outils développés sérieusement par l’équipe UTokyo qui sont « vraiment utiles » ❗️
Si vous êtes intéressé, veuillez nous suivre et nous découvrir.
LINE est ici ⇩
