Markdown ou HTML avec l'IA : quel format pour quel usage ?

Depuis quelques semaines, on lit partout que le HTML serait devenu le nouveau format pour « parler » à l'IA. C'est à moitié vrai, et la moitié fausse peut vous coûter cher en tokens et en clarté. La bonne règle tient en une ligne : le Markdown sert à nourrir l'IA, le HTML sert à présenter à un humain.

Je suis formateur IA et facilitateur chez MAIjin, et c'est cette distinction que j'ai posée dans l'édition de L'hebdo de MAIjin que j'ai signée en mai 2026. Je la développe ici avec mes exemples et mes outils, parce qu'elle répond à une question que beaucoup de professionnels se posent sans la formuler.

D'où vient la confusion entre Markdown et HTML ?

Le point de départ est un article publié le 20 mai 2026 sur le blog de Claude par Thariq Shihipar, membre de l'équipe technique d'Anthropic : « Using Claude Code: The unreasonable effectiveness of HTML ». Il y explique pourquoi il demande de plus en plus souvent à Claude Code de produire des fichiers HTML plutôt que des documents Markdown.

Comme souvent, la nuance s'est perdue en route. Certains titres ont résumé l'idée en « cet ingénieur utilise du HTML pour piloter l'IA ». Le lecteur pressé retient : « le HTML est le nouveau prompt ».

Or c'est exactement l'inverse. Je le souligne : le HTML est le format que l'IA génère pour qu'un humain comprenne mieux, pas un format que l'IA lirait mieux. Cette inversion change complètement la façon de s'en servir.

Markdown : le format d'entrée pour donner du contexte à l'IA

Quand vous transmettez du contexte à un LLM ou à un agent (une consigne, une base de connaissances, une fiche client, une procédure), le Markdown reste le meilleur choix. Il est léger, structuré par des titres et des listes, facile à analyser pour le modèle et peu coûteux en tokens.

C'est d'ailleurs le format qu'utilisent les assistants comme ChatGPT ou Claude pour formater leurs propres réponses, et celui des fichiers d'instructions qui pilotent les agents, à commencer par les skills. Si vous construisez vos propres skills IA pour automatiser vos tâches métier, vous écrivez déjà en Markdown sans forcément le savoir.

À l'inverse, donner un fichier HTML brut à un modèle est une mauvaise idée. Je le rappelle : Claude va le lire comme du texte, balises comprises. Le rendu visuel est ignoré, et vous brûlez des tokens pour rien. Pour l'entrée, la règle est donc simple : ne remplacez pas le Markdown par du HTML.

HTML : le format de sortie quand un humain doit lire et décider

Là où le HTML devient puissant, c'est en sortie. Demandez à Claude de produire un fichier HTML autoporteur (un seul fichier, styles inclus, qui s'ouvre dans n'importe quel navigateur) pour synthétiser un sujet, et vous obtenez une véritable interface : hiérarchie visuelle, couleurs qui portent du sens, encadrés, onglets, sections dépliables.

Thariq Shihipar avance plusieurs arguments dans son article :

• la densité d'information : tableaux, schémas SVG, mises en page spatiales, ce que le Markdown ne permet pas ;
• la lisibilité : il reconnaît lui-même ne presque jamais lire un fichier Markdown au-delà d'une centaine de lignes ;
• le partage : un lien se transmet et s'ouvre plus facilement qu'une pièce jointe ;
• l'interactivité : on peut ajuster des paramètres, cocher des options, puis renvoyer le résultat à l'agent.

Il a d'ailleurs publié une galerie de vingt exemples : comparatifs d'options, revues de code annotées, prototypes cliquables, rapports, présentations. Sa recommandation de départ est désarmante de simplicité : demander à Claude de « faire un fichier HTML », puis construire peu à peu ses propres modèles.

En résumé, les deux formats ne s'opposent pas. Ils s'empilent : Markdown à l'entrée, HTML à la sortie.

Le vrai changement : des interfaces jetables

L'autre point que je juge crucial est culturel. Pendant des années, produire une interface visuelle coûtait cher : un designer, un développeur, des allers-retours, un livrable qu'on gardait précieusement.

Avec les modèles actuels, le coût de production d'une interface utilisable devient quasi nul. On peut donc la penser comme jetable :

• un tableau de bord pour une décision unique, supprimé une fois la décision prise ;
• une page de synthèse pour une réunion de 30 minutes, archivée ensuite ;
• une page explicative pour un client, partagée par lien puis oubliée.

On n'écrit plus « le document de référence » qu'il faudra entretenir. On produit un artefact pour une tâche, une conversation, un interlocuteur. C'est la même logique que celle que MAIjin décrit à propos des sites web créés en un prompt, appliquée cette fois aux documents de travail du quotidien.

Deux cas concrets tirés du terrain

J'ai partagé dans l'édition deux artefacts produits pour des clients, anonymisés. Ils illustrent deux usages très différents du même format.

Une page de décision plutôt qu'un PDF de 8 pages

Un client devait choisir entre deux architectures d'automatisation. Au lieu d'un PDF de 8 pages qu'il n'aurait probablement pas lu, j'ai généré en quelques prompts une page web d'un seul écran : un bandeau qui rappelle le contexte, les deux options côte à côte avec coûts estimés, prérequis et impact, puis un bouton de validation.

Le résultat : ce qui demandait habituellement une réunion d'une heure s'est réglé en 5 minutes de lecture suivies d'un appel de validation.

Un mode d'emploi imprimable

Pour un assistant Claude personnalisé déployé chez un menuisier, j'ai produit un mode d'emploi au format A4, en mode clair, pensé pour être imprimé et posé sur le bureau. Aucune interactivité ici : ce que l'assistant sait faire, comment formuler une demande, quoi vérifier avant d'utiliser la réponse.

Le HTML servait de format de travail facile à modifier, l'export PDF de livrable final. Même format, registre opposé : interactif pour décider, statique pour se souvenir.

Comment mettre cette méthode en place dans votre équipe

Donner une signature visuelle à vos artefacts

Pour que mes pages gardent une cohérence, j'ai créé une skill Claude personnelle, baptisée artifact-signature. Ma méthode : faire lire à Claude l'article d'Anthropic et la galerie d'exemples, puis ajouter mes propres consignes de design. Je me suis par exemple inspiré du jeu vidéo Apex Legends pour un code couleur strictement sémantique (bleu informatif, doré important, rouge critique, vert confirmé) et du film Passengers pour l'espace négatif et la respiration de la page.

Le détail des inspirations importe peu. Ce qui compte, c'est le principe : un modèle ou une skill réutilisable, pour ne pas repartir de zéro à chaque fois. Je l'utilise désormais jusqu'à suivre l'avancement de la newsletter elle-même. Si vous débutez avec l'outil, notre guide complet pour débuter avec Claude Code vous donne les bases.

Partager en une URL avec here.now

Reste la question du partage. here.now transforme un fichier HTML en page web accessible par lien, et fonctionne avec les agents capables d'envoyer des requêtes web, dont Claude Code. Deux modes :

• sans compte, la page est en ligne immédiatement mais expire au bout de 24 heures, idéal pour une présentation ponctuelle ;
• avec un compte gratuit, la page devient permanente et peut être protégée par mot de passe, utile pour des contenus clients plus sensibles.

Lors de mes essais, la publication s'est faite de bout en bout avec Claude Code, mais une intervention manuelle en ligne de commande a été nécessaire avec Claude Cowork. Et si la décision est prise, on imprime la page en PDF pour l'archiver.

Pour une PME : par où commencer ?

L'enjeu n'est pas technique. Il s'agit d'apprendre à vos équipes à distinguer ce qu'on donne à l'IA de ce qu'on lui demande de produire, puis de standardiser quelques modèles d'artefacts (page de décision, synthèse de réunion, mode d'emploi). C'est précisément ce type de réflexe que nous travaillons dans les formations et accompagnements de MAIjin, où j'interviens comme formateur IA et facilitateur, avec plus de 4 500 professionnels formés dans plus de 150 organisations : partir des documents que vos collaborateurs produisent déjà, et identifier ceux qui gagneraient à devenir des artefacts jetables.

Un dernier garde-fou, que j'ai glissé dans la même édition : avant une question importante, ajoutez « Avant de répondre… Est-ce vraiment la question que je devrais poser ? ». Une belle interface ne remplace pas un bon cadrage, et déléguer trop vite fragilise notre propre jugement, un sujet que Jean-Baptiste Berthoux, co-fondateur de MAIjin, explique dans son article sur l'AI brain fry.

Ce qu'il faut retenir

• Le Markdown reste le format roi pour donner du contexte à une IA : léger, structuré, économe en tokens.
• Le HTML autoporteur s'impose en sortie, dès qu'un humain doit lire, comprendre ou décider.
• Donner du HTML brut à un modèle en entrée gaspille des tokens sans aucun bénéfice.
• Pensez vos interfaces comme jetables : un artefact par tâche, pas un document de référence à entretenir.
• Une skill ou un modèle personnel, plus un outil de partage comme here.now, ferment la boucle du prompt à l'URL.

Articles recommandés