Un article sur un format de fichier a fait 11 millions de vues cette semaine. Si tu trouves ça surprenant, c’est exactement pourquoi tu devrais le lire — il dit quelque chose de précis sur l’endroit où en sont les agents IA aujourd’hui.
Au programme :
🔥 HTML > Markdown pour tes agents : pourquoi le format de sortie de Claude vient de changer pour de bon
Les 5 business models de 2026 activés par les agents — thread de Greg Isenberg
DeepSeek V4 Flash en local : l’IA edge commence vraiment
→ En vrac : pré-mortem Claude, chirurgien ophtalmo + Claude Code, Vera (le langage conçu pour les IA), Understand-Anything
Bonne nouvelle le sponsoring de la newsletter reprend. J’ai eu pas mal de demandes dernièrement et beaucoup de mails d’intérêt pour cette newsletter hebdomadaire. Elle me prend pas mal de temps chaque semaine à écrire donc si vous voulez soutenir mon travail et mettre en avant votre produit, je vous propose de cliquer sur le lien ci-dessous si cela vous intéresse de sponsoriser cette newsletter.
11 millions de vues, 15 000 likes. Un ingénieur de l’équipe Claude Code publie la thèse qui change comment il travaille.
Thariq Shaukat, de l’équipe Claude Code chez Anthropic, a publié cette semaine un article intitulé “The Unreasonable Effectiveness of HTML”. En 48 heures, il a cumulé 11 millions de vues. Ce n’est pas un bruit de fond de Twitter tech — c’est un signal clair.
La thèse est simple : depuis l’émergence des agents, Markdown est devenu le format dominant pour les outputs de Claude. C’est portable, simple à éditer, et Claude s’en sort bien même pour les diagrammes ASCII. Mais Markdown a un problème structurel : il ne scale pas. Personne ne lit vraiment un fichier Markdown de plus de cent lignes. Toi non plus.
Et pourtant, les agents produisent maintenant des specs, des plans, des rapports, des revues de code — de plus en plus longs, de plus en plus riches. Si le format de sortie ne suit pas, la valeur se perd dans un document que tu ne liras jamais vraiment.
L’alternative proposée : HTML. Et c’est plus radical qu’il n’y paraît.
HTML permet à Claude de produire des tableaux, des SVG, des animations, des interactions, des layouts adaptatifs. Il peut organiser visuellement 600 lignes d’un plan d’implémentation avec des onglets, des couleurs, des liens — quelque chose qu’on a envie de lire, qu’on peut partager en un lien (upload vers S3), et qu’on peut même rendre interactif (sliders, knobs pour ajuster un design, bouton “copier en JSON”).
Ce que Thariq observe dans sa propre pratique : il a arrêté d’utiliser Markdown pour presque tout. Specs, plans d’implémentation, revues de code, rapports — tout est devenu HTML. Non pas parce que c’est plus court à générer (ça prend 2 à 4 fois plus de temps), mais parce que la probabilité qu’il lise vraiment le document est beaucoup plus haute.
La conséquence pratique qui m’a frappé : il attache un HTML explainer à chaque PR qu’il fait, plutôt que de compter sur la vue diff de GitHub. Le contexte est plus riche, les annotations plus lisibles, et les reviewers comprennent réellement ce qu’ils relisent.
Pour toi en tant que builder : tu n’as pas besoin d’une skill ou d’un prompt système élaboré pour démarrer. Tu dis simplement à Claude “fais-moi un fichier HTML” ou “génère un artefact HTML”. La vraie question est de savoir ce que tu veux que ce document fasse — et ça, ça vient avec la pratique.
Les cas d’usage concrets : exploration de designs, plan d’implémentation avec mockups, revue de PR annotée, rapport de recherche interactif, éditeur ad hoc pour trier des tickets ou ajuster des configurations. Pour chaque cas, la règle est la même : finir par un bouton “copier” qui te permet de réinjecter les modifications dans Claude Code.
Ce que ça change pour toi :
🟢 Maintenant : la prochaine fois que tu demandes un plan ou une spec à Claude, remplace “écris-moi un fichier markdown” par “génère un fichier HTML”. Ouvre-le dans ton navigateur. Observe la différence de lisibilité. C’est tout ce qu’il faut pour comprendre le concept.
🟡 À surveiller : l’émergence de design systems HTML personnalisés — des fichiers de référence qui donnent à Claude ton style pour tous ses outputs. Thariq en parle dans son article, c’est une pratique qui va se normaliser rapidement.
⚪ Pas encore : refaire tous tes workflows autour de HTML. La bascule se fait naturellement, cas d’usage par cas d’usage.
→ Lire l’article complet de Thariq Shaukat
Greg Isenberg (@gregisenberg) a publié cette semaine un thread centré sur une question précise : quels business models fonctionnent maintenant parce que les agents peuvent réellement faire des choses ?
Le point de départ est une bascule de question : au lieu de se demander “quelle app puis-je construire ?”, la bonne question devient “quel workflow douloureux un agent peut-il prendre en charge de bout en bout ?” Ce n’est pas une nuance — c’est un changement de grille de lecture complet.
Les 5 modèles qu’il identifie :
1. Outcome bounties — Tu trouves une niche avec un SaaS existant, tu te positionnes non pas sur l’outil mais sur le résultat. Pas “$99/mois pour accès au logiciel” mais “résultat livré, on te facture”. L’agent fait le travail ; toi, tu arbitres la qualité et tu gères la relation.
2. Shadow spreadsheet replacement — Chaque entreprise a un tableur qui pilote en secret une partie de son activité. Un tableur que tout le monde connaît, que personne ne comprend vraiment, et que “seulement Jean-Pierre sait maintenant faire tourner”. L’idée : trouver ce tableur, le transformer en “agent desk” — une interface qui fait la même chose, automatiquement, avec supervision humaine là où c’est nécessaire.
3. Data refinery — La plupart des entreprises ont leurs données dans un état qui les rend inutilisables pour des agents. Trop bruyantes, pas structurées, dans des formats obsolètes. Le job : transformer cette “soupe de données” en quelque chose que des agents peuvent lire et sur lequel ils peuvent agir. C’est une mission de consulting très concrète.
4. Agents de veille réglementaire — Déployer des agents qui surveillent les évolutions de règles, de lois, de normes sectorielles — et prévenir le client quand quelque chose change. On vend de la tranquillité d’esprit, pas un abonnement à un outil.
5. Agent trust layer — Les agents ne sont pas encore entièrement fiables. Le modèle : faire office de superviseur humain sur les actions critiques des agents de tes clients. Un “bouclier de confiance” entre l’agent et la décision finale.
À retenir : ce qui unit ces cinq modèles, c’est qu’ils sont tous construits autour d’un agent qui fait — et d’un humain qui valide et clarifie. Ce n’est pas du SaaS classique. C’est une nouvelle couche de valeur que les outils traditionnels ne savent pas encore occuper.
→ Voir le thread original de Greg Isenberg
antirez — le créateur de Redis — publie DS4, un moteur d’inférence spécialisé pour faire tourner DeepSeek v4 Flash sur Mac Metal.
Salvador Sanfilippo, connu sous le pseudo antirez et fondateur de Redis, a publié cette semaine DS4 : un moteur d’inférence local, léger et spécialisé pour DeepSeek v4 Flash, optimisé pour fonctionner sur le GPU Apple Silicon via Metal.
Ce que ça veut dire concrètement : DeepSeek v4 Flash tourne en local sur ton MacBook, sans cloud, sans API, sans que tes données quittent ta machine.
Le projet s’appuie sur llama.cpp et GGML — les fondations habituelles des moteurs d’inférence locaux — mais l’approche est spécialisée. Antirez l’a conçu spécifiquement pour ce modèle, pas pour un usage généraliste. Le résultat : des performances adaptées, avec une empreinte mémoire maîtrisée.
Pourquoi c’est un signal important : depuis deux ans, “IA en local” rimait souvent avec compromis de qualité. Llama 3, Mistral, Phi — des modèles capables, mais qui ne rivalisaient pas vraiment avec les API frontier pour les usages avancés. DeepSeek v4 Flash change l’équation. Et quand le créateur de Redis décide de passer son week-end à optimiser son moteur d’inférence pour ce modèle, ce n’est pas anodin.
L’IA edge — des modèles puissants, locaux, embarqués sur l’appareil — n’est plus une promesse lointaine. C’est ce qui arrive.
À retenir : si tu as des cas d’usage où la confidentialité des données compte (clients dans des secteurs réglementés, contenus sensibles, données propriétaires), DS4 vaut le coup d’être testé. L’install est technique — il faut compiler depuis les sources — mais la documentation est là.
→ [Claude / Technique pré-mortem] Guillermo Casaus a partagé une prompt technique puissante : demander à Claude de “voyager 6 mois dans le futur” et d’expliquer exactement pourquoi ton projet va échouer. L’IA cesse d’être optimiste par défaut et commence à identifier les risques, les erreurs d’hypothèse, les points faibles structurels — avant que tu aies écrit la première ligne de code. Un usage counter-intuitif mais particulièrement utile en phase de cadrage.
→ [Claude Code / Site web médical] Anthony Chiche, chirurgien ophtalmologiste, a reçu un devis à 12 000 € pour refondre le site de son cabinet. Il a refusé et l’a fait lui-même avec Claude Code en une à deux semaines — charte graphique, contenu sourcé sur les recommandations HAS, arborescence, développement, audit SEO et conformité RGPD final. Coût total : un abonnement mensuel. L’exemple est daté, il circulait cette semaine sur LinkedIn, et il dit quelque chose d’important : l’autonomie numérique est désormais accessible à des profils non-techniques. — Ce sujet rejoins celui de la newsletter précédente où j’expliquais que l’autonomie technique des clients changeait la donne dans le service.
→ [Vera] Laurent Eschenauer pointe un projet qui mérite l’attention : Vera, un langage de programmation conçu non pas pour être lisible par des humains, mais pour être écrit par des IA. Pas de noms de variables — à la place, des références indexées. Préconditions et postconditions obligatoires, prouvées mathématiquement à la compilation. Pour un humain, illisible. Pour un LLM, optimal. Si les agents deviennent les principaux auteurs de code, les outils qui les entourent vont s’adapter à leurs contraintes, pas aux nôtres. — Vera sur GitHub
→ [Understand-Anything / Claude Code] Plugin Claude Code open source testé par Thierry Templier : 5 agents travaillent en parallèle pour cartographier une codebase de 200 000 lignes en moins de 2 minutes. Résultat : un dashboard React Flow interactif avec recherche sémantique (”quelles parties gèrent l’auth ?”), diff impact avant chaque commit, et tours guidés ordonnés par dépendance. Si tu récupères du code vibe-codé par un client ou si tu prends en main un projet existant, ça peut sauver beaucoup de temps. Open source, MIT. — Understand-Anything sur GitHub
C’est tout pour cette semaine.
Si un sujet t’a parlé, si tu veux challenger une idée ou juste dire que tu étais là — réponds directement à cet email. Je lis tout et je réponds à tout.
Et si tu as un projet à développer — une app, un outil interne, une V1 à finaliser — c’est exactement pour ça que je suis là. Un message suffit pour qu’on en parle.
Si cette édition t’a apporté quelque chose, le meilleur coup de pouce que tu puisses me donner, c’est de la partager à quelqu’un qui en ferait quelque chose 👇
Tu peux aussi me retrouver sur LinkedIn pour suivre ce que je construis en dehors des éditions.
À la semaine prochaine.
— Milan
Aucun post
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.