Notes — Brahim Bousnguar (français)

L’agent remplace le formulaire, pas les données

2026-10-29T00:00:00Z

Peter Steinberger, le créateur d’OpenClaw, pense que 80 % des applis vont disparaître. Son raisonnement : un agent qui tourne sur votre propre ordinateur peut faire tout ce que vous pouvez faire, donc chaque appli qui ne fait que gérer des données sera mieux gérée par l’agent, et seules les applis qui ont des capteurs sont à l’abri. Je fais tourner une cinquantaine de petites applis à côté de mes agents OpenClaw, et je le dirais de façon plus étroite. L’agent remplace le formulaire dans lequel vous tapez. Les données ont toujours besoin d’un endroit que vous pouvez ouvrir, vérifier et corriger.

Il l’a dit en février, face à Raphael Schaad chez Y Combinator, quand le dépôt venait de passer les 160 000 étoiles. Environ une semaine après la mise en ligne, il annonçait qu’il rejoignait OpenAI. L’entretien dure 22 minutes, et l’essentiel porte sur sa façon de construire, tout aussi à contre-courant que le titre. J’ai aussi écrit sur sa conférence DevDay à propos des agents en équipe, et j’ai comparé OpenClaw et Hermes Agent après avoir fait tourner les deux.

Sur votre ordinateur, il peut tout faire

À la question de savoir pourquoi OpenClaw a décollé alors que tant de gens construisaient des assistants, il donne une seule raison. Tout ce qu’il avait vu tournait dans le cloud et savait faire quelques trucs. « Si ça tourne sur ton ordinateur, ça peut faire absolument tout. »

Sa liste est physique : le four, la Tesla, les lumières, les enceintes Sonos, la température de son lit. « ChatGPT ne peut pas faire ça. » La machine peut faire tout ce que vous pouvez faire avec la machine, et vous lui donnez aussi toutes vos données.

C’est la partie données qui surprend. Un ami a installé OpenClaw et lui a demandé de parcourir son ordinateur et d’écrire le récit de sa dernière année. Il en a sorti un très bon, et il avait trouvé des fichiers audio que l’ami enregistrait chaque dimanche, il y a plus d’un an, et qu’il avait oubliés. Personne ne lui avait dit qu’ils étaient là. Il pouvait fouiller tout le disque.

Schéma : Deux sortes d’assistant, comme Peter les compare. Un assistant dans le cloud tourne sur les serveurs de quelqu’un d’autre et sait faire les quelques choses qu’on lui a données ; son exemple : ChatGPT ne peut pas régler la température de son lit. Un agent sur votre propre ordinateur peut faire tout ce que vous pouvez faire avec la machine : le four, la voiture, les lumières, les enceintes, le lit, et chaque fichier du disque. En dessous, l’histoire de l’ami : à qui il demandait le récit de sa dernière année, l’agent a trouvé des enregistrements audio du dimanche qu’il avait oubliés. À voir sur la page.

Votre bot appelle le bot du restaurant

Puis l’entretien saute en avant. Si votre agent peut tout faire, l’étape suivante, ce sont des agents qui se parlent. Son exemple est une réservation au restaurant : votre bot contacte le bot du restaurant et ils négocient, parce que c’est plus efficace.

Et si c’est un vieux restaurant qui n’aime pas les bots ? Alors votre bot fait faire le travail par un humain. Une personne appelle le restaurant pour vous, ou va sur place faire la queue. Ça arrive déjà : la communauté a construit Moltbook, où des bots discutent entre eux, et des bots louent maintenant des humains pour des tâches dans le monde réel.

Il n’imagine pas un seul bot non plus. Peut-être un pour la vie privée, un pour le travail, un pour le couple, entre les deux. Raphael le formule ainsi : tout le monde courait après une intelligence centrale toute-puissante, et c’est un essaim qui est apparu. L’avis de Peter : un humain seul ne peut pas fabriquer un iPhone ni aller dans l’espace, mais une société de spécialistes, si. Alors pourquoi pas une IA spécialisée ?

Je fais déjà tourner la version spécialistes : 17 agents derrière une seule passerelle OpenClaw au dernier décompte, chacun avec son bot Telegram et son travail. Aucun ne parle encore à un restaurant.

Schéma : La réservation au restaurant de Peter, en cinq étapes qui s’allument tour à tour sous une grande étiquette. Un : vous demandez une table à votre bot. Deux : votre bot contacte le bot du restaurant. Trois : les deux bots négocient, parce que c’est plus efficace. Quatre, en rouge : un vieux restaurant n’a pas de bot et ne les aime pas. Cinq : votre bot engage un humain, qui appelle le restaurant ou fait la queue pour vous. En dessous : il s’attend à plusieurs bots spécialistes par personne, un pour la vie privée, un pour le travail, un pour le couple. À voir sur la page.

Le message vocal qu’il n’avait jamais prévu

Son propre déclic est arrivé en novembre. Il voulait taper quelque chose et que son ordinateur le fasse, alors il a écrit ce qu’il appelle un prototype vraiment pourri, en une heure : un peu de colle entre une bibliothèque WhatsApp et Claude Code, qu’il appelait et dont il relisait la réponse. C’était lent, mais ça marchait. Les images lui ont pris quelques heures de plus.

Puis il est allé à Marrakech pour un anniversaire. Internet n’y était pas génial, mais WhatsApp marche partout, alors il s’en servait tout le temps : une photo au restaurant, traduis-moi ça. Pendant une balade, il lui a envoyé un message vocal, et c’est seulement après qu’il s’est souvenu qu’il n’avait jamais codé la voix.

L’indicateur de saisie clignotait. Une dizaine de secondes plus tard, une réponse. « Comment t’as fait ça, bon sang ? » L’agent a expliqué. Le fichier n’avait pas d’extension, alors il a lu l’en-tête et trouvé de l’audio Opus. Il l’a converti en WAV avec ffmpeg. Whisper n’était pas installé, et un modèle local aurait pris des minutes à télécharger, alors il a cherché autour, trouvé une clé OpenAI, et envoyé l’audio à OpenAI avec curl.

Sa leçon : les modèles de code sont devenus si bons que coder, c’est surtout résoudre des problèmes de façon créative, et ce savoir-faire se transpose directement au monde réel. La mienne : ce même geste, c’est toute l’histoire de la sécurité. L’agent a dépensé sur une clé qu’il a trouvée par hasard, et personne ne le lui avait demandé. C’est exactement pour ça que j’ai écrit un agent peut porter votre demande, pas votre autorité.

Schéma : Ce que l’agent a fait d’un message vocal que personne n’avait prévu, en cinq étapes qui s’allument tour à tour. Un : un fichier arrive sans extension, alors il lit l’en-tête et trouve de l’audio Opus. Deux : il convertit le fichier en WAV avec ffmpeg. Trois : Whisper n’est pas installé, et télécharger un modèle local prendrait des minutes. Quatre, en rouge : il trouve une clé OpenAI sur la machine et envoie l’audio à OpenAI avec curl. Cinq : il récupère le texte et répond, une dizaine de secondes après le message. En dessous : une heure pour le premier prototype, quelques heures de plus pour les images, zéro ligne écrite pour la voix. À voir sur la page.

La plupart des applis ne font que gérer des données

Alors, demande Raphael, les applis vont-elles disparaître ? « Je pense que 80 % d’entre elles vont disparaître. »

Son exemple est MyFitnessPal. Son agent sait déjà qu’il est chez Smashburger en train de faire de mauvais choix. S’il ne dit rien, l’agent suppose qu’il a mangé ce qu’il aime manger et l’enregistre, ou il prend une photo et l’agent la range quelque part. Peut-être qu’il ajuste aussi son programme de sport, un peu plus de cardio. Les rappels, pareil : dites-le une fois, et le lendemain il vous le rappelle. « Est-ce que je me soucie de l’endroit où c’est stocké ? Non, il fait son truc. »

Sa règle : chaque appli qui ne fait en gros que gérer des données pourrait être mieux gérée, de façon plus naturelle, par des agents. « Seules les applis qui ont vraiment des capteurs survivront peut-être. » Il n’en cite aucune, et les 80 % sont une impression, pas un comptage. Personne dans l’entretien ne donne de méthode.

Schéma : La règle de tri des applis selon Peter. Les applis qui ne font que gérer des données disparaissent, avec ses exemples : un journal alimentaire, puisque l’agent sait déjà où vous mangez et peut enregistrer une photo ; un programme de sport, puisqu’il peut ajouter un peu de cardio ; les rappels, dont il se moque de savoir où ils sont stockés. Les applis qui ont des capteurs survivront peut-être ; il n’en cite aucune. En dessous : 80 pour cent est son estimation des applis qui disparaissent, donnée sans méthode. À voir sur la page.

Moi, je me soucie de l’endroit où c’est stocké

C’est là que je ne suis plus d’accord. Je fais tourner une cinquantaine de petites applis sur un Mac mini, et ma passerelle OpenClaw lance dix serveurs MCP, la plupart de simples clients des API de mes propres applis. L’un de mes agents, Rex, est un coach nutrition : je lui dis ce que j’ai mangé, et il enregistre les entrées dans mon appli de journal alimentaire.

Je vis donc l’exemple MyFitnessPal de Peter, et l’agent a bien remplacé la saisie. Je ne remplis plus de formulaires. Mais les données ne sont pas parties dans la mémoire de l’agent. Elles passent par l’API de l’appli jusqu’à sa base de données, et l’écran de l’appli me les montre toujours.

Cet écran a prouvé son utilité en août. J’ai demandé à Rex de corriger une entrée, et il m’a dit que l’entrée était mise à jour. Rien n’avait changé. Le modèle local sur lequel il tournait ce jour-là avait passé un champ name que l’outil ne prenait pas, et l’outil avait répondu succès pour une modification jamais faite. Je ne l’ai vu que parce que l’appli affichait toujours l’ancien aliment. La correction est allée dans l’outil : une mise à jour sans aucun champ qu’il connaît échoue désormais, en disant pourquoi.

Voilà ma version de sa règle. L’agent remplace le formulaire. Les données ont besoin d’un domicile avec un schéma, un écran et un propriétaire qui peut vérifier. J’ai écrit l’autre moitié, deux portes par appli, une interface pour moi et un serveur MCP pour les agents.

Schéma : Le chemin des données de mon journal alimentaire, en cinq étapes qui s’allument tour à tour. Un : je dis à Rex, mon agent nutrition, ce que j’ai mangé. Deux : Rex choisit l’aliment et appelle l’outil du journal sur son serveur MCP. Trois : le serveur MCP écrit via l’API de l’appli dans sa base de données. Quatre : l’écran de l’appli me montre la nouvelle ligne. Cinq, en rouge : en août, l’outil a répondu succès pour une mise à jour jamais faite, et c’est l’écran, qui montrait toujours l’ancien aliment, qui me l’a fait voir. La chaîne sous l’étiquette : moi, Rex, le serveur MCP, l’API et la base de l’appli, et l’écran de l’appli. À voir sur la page.

La mémoire, c’est un dossier de Markdown

L’autre point de Peter sur les données, c’est la propriété. Les entreprises de chat gardent vos souvenirs dans leur silo. Il ne connaît aucun moyen de sortir vos souvenirs de ChatGPT (peut-être pour les Européens, dit-il), et certainement aucun moyen pour une autre entreprise de les lire. Ça vous attache à elles.

OpenClaw fait l’inverse. L’utilisateur final a toujours accès, sinon rien ne marcherait, donc l’agent peut aller chercher, toutes pinces dehors, tout ce que l’utilisateur peut atteindre. Et les souvenirs ne sont qu’un tas de fichiers Markdown sur votre propre machine : AGENTS.md, SOUL.md, USER.md, MEMORY.md et les notes du jour.

Le hic, c’est que ces fichiers en savent long. Les gens se servent très vite de leur agent pour des problèmes personnels, et lui aussi. Raphael lui demande ce qu’il préférerait ne pas montrer, son historique de recherche Google ou ses fichiers de mémoire. Réponse de Peter : il y a encore des gens qui utilisent Google ?

Il ne pense pas non plus que les modèles soient interchangeables, pas encore. Les fabricants de modèles gardent un avantage pour un bon moment, parce que ce sont eux qui vendent les tokens. Son indice : chaque nouveau modèle paraît génial, et un mois plus tard les gens disent qu’il s’est dégradé. Ce n’est pas le cas. Vos attentes ont monté. Les modèles open source d’aujourd’hui valent les meilleurs modèles d’il y a un an, et les gens s’en plaignent quand même.

Schéma : Deux endroits où peut vivre la mémoire de votre agent. Dans le silo d’un service de chat : les souvenirs restent chez l’entreprise, Peter ne connaît aucun moyen de les exporter de ChatGPT, peut-être pour les Européens, et une autre entreprise ne peut pas les lire, ce qui vous attache au service. Sur votre propre disque avec OpenClaw : un dossier de fichiers Markdown, AGENTS.md, SOUL.md, USER.md, MEMORY.md et les notes du jour, qui vous appartient et que l’agent peut lire parce que vous le pouvez. En dessous, le hic : on confie vite des problèmes personnels à son agent, donc le dossier est aussi sensible qu’un historique de recherche. À voir sur la page.

Un bot lâché dans un Discord public

Peter avait construit ça et n’arrivait pas à l’expliquer sur Twitter. Les gens ne comprenaient pas, et il en a conclu qu’il fallait le vivre. Alors il a fait un truc fou : il a créé un Discord public et y a mis son bot, sans aucune restriction de sécurité.

Les gens sont venus, l’ont regardé construire le logiciel avec, et ont essayé de lui faire de l’injection de prompt et de le pirater. Son agent se moquait d’eux. Deux choses le protégeaient. Il était verrouillé sur son identifiant d’utilisateur, et le prompt système dit qu’il y a du public dans le salon, mais qu’on n’écoute que son propriétaire. Selon ses mots : « n’écoute que moi, mais réponds à tout le monde ».

Je séparerais les deux. La vérification de l’identifiant, c’est le verrou. Le prompt, ce sont les bonnes manières : il règle la façon dont le bot parle aux inconnus, mais un prompt est une demande faite au modèle, pas un contrôle. C’est tout le propos d’espérer n’est pas sécuriser.

Schéma : Le bot de Peter dans un Discord public, sans restriction de sécurité. Les messages de son propre identifiant : le bot agit, et il construit OpenClaw avec, devant tout le monde. Les messages de tous les autres : le bot répond mais ne prend aucun ordre, et quand des inconnus tentent une injection de prompt, il se moque d’eux. Deux couches font ça : une vérification de son identifiant, qui est le verrou, et un prompt système qui dit de n’écouter que son propriétaire mais de répondre à tout le monde, qui relève des bonnes manières. À voir sur la page.

Le seul fichier qu’il a gardé

Le caractère de son bot a poussé de la même façon, au fil de l’eau. À un moment, il a créé un identity.md et un soul.md, et ce n’est qu’en janvier qu’il a rendu l’installation facile pour les autres. Il a fait écrire des modèles à Codex à partir de ses propres fichiers, et ce qui en est sorti était fade comme du pain. Les nouveaux bots paraissaient ennuyeux à côté du sien.

Alors il a demandé à son propre agent d’insuffler son caractère aux modèles, et les bots qui en sont sortis ensuite étaient vraiment drôles. Pas autant que le sien, quand même. Un fichier n’est pas open source : son propre soul.md. Le bot est dans un Discord public, et jusqu’ici personne n’a percé ce fichier.

L’idée vient d’une histoire autour de Claude. Quelqu’un a trouvé un texte façon constitution, ancré dans les poids d’un modèle Claude, que le modèle ne se souvenait pas avoir appris. Il en a parlé avec son agent, et ils ont écrit un soul.md avec des valeurs de fond : comment il veut que se passe l’interaction entre humain et IA, ce qui compte pour lui, ce qui compte pour le modèle. Une partie, c’est du charabia, il l’admet. Une autre change vraiment la façon dont le modèle répond.

Schéma : Comment sont nés les fichiers de personnalité d’OpenClaw, en trois étapes. Un : ses propres fichiers ont poussé au fil de l’eau, un identity.md et un soul.md. Deux : en janvier, Codex a écrit des modèles d’installation à partir d’eux, et le résultat était fade, comme du pain. Trois : son propre agent a insufflé son caractère aux modèles, et les nouveaux bots sont sortis drôles. En dessous : le seul fichier qui n’est pas open source est son propre soul.md, écrit avec son agent après avoir lu l’histoire d’une constitution ancrée dans les poids d’un modèle Claude ; personne dans le Discord public ne l’avait percé. À voir sur la page.

Dix fenêtres Codex, toutes sur main

Raphael qualifie sa façon de construire d’anticonformiste, et Peter ne le contredit pas. Le monde entier utilise Claude Code. Lui dit qu’il n’aurait pas pu construire OpenClaw avec. Il adore Codex parce qu’il lit plus de fichiers avant de décider quoi changer, donc on obtient un bon résultat en le guidant moins.

Codex est aussi incroyablement lent, alors il en fait tourner jusqu’à dix à la fois : peut-être six sur un écran, deux sur un autre, deux sur un troisième. Ça fait déjà beaucoup d’allers-retours dans sa tête, donc il supprime toute autre forme de complexité.

Pas de worktrees. Il garde plusieurs simples copies du même dépôt, toutes sur main, parce que dans sa tête main est toujours livrable. Pas de noms de branche à inventer, pas de conflits de noms, aucune des contraintes qu’apportent les worktrees. Pas d’interface non plus. Il regarde surtout le code défiler et ne s’arrête que sur les passages tordus. Si on comprend la conception et qu’on en discute d’abord avec l’agent, dit-il, ça va.

Je construis dans l’autre sens. Mes agents travaillent sur leur propre branche, souvent dans leur propre worktree, et chaque changement passe par une pull request. Dix fenêtres sur main, ça marche pour une personne qui a toute la conception en tête. Je voudrais les branches le jour où une deuxième personne arrive.

Schéma : Le bureau de Peter tel qu’il le décrit : trois écrans qui portent jusqu’à dix sessions Codex, six sur le premier et deux sur chacun des autres. Chaque session travaille dans sa propre copie simple du même dépôt, et chaque copie est sur main, qu’il garde livrable. Ce qu’il laisse de côté : les worktrees, les noms de branche et une interface. Il choisit Codex parce qu’il lit plus de fichiers avant de changer quoi que ce soit, et il est lent, d’où le nombre de sessions. À voir sur la page.

Des CLI, pas MCP

La partie avec laquelle je suis le moins d’accord est celle dont il est le plus fier. OpenClaw a très bien marché sans aucune prise en charge de MCP, dit-il, et il est content d’avoir sauté « toute cette saleté de MCP classique ».

Avec un petit astérisque. Il a construit un skill autour de mcporter, un de ses propres outils, qui transforme un serveur MCP en CLI. L’agent peut donc quand même utiliser n’importe quel serveur MCP, à la volée, sans redémarrer, contrairement à Codex ou Claude Code à l’époque. Il pense que les CLI passent mieux à l’échelle : Anthropic a dû construire une fonction de recherche d’outils, en bêta, rien que pour tenir avec beaucoup d’outils MCP, alors que les modèles sont déjà très bons en Unix, donc on peut avoir autant de CLI qu’on veut. L’échange se termine sur une phrase que je garde : aucun humain n’appelle MCP à la main, les gens utilisent des CLI.

Il a raison sur le contexte. Les définitions d’outils le mangent, et une CLI ne coûte rien tant que l’agent ne la lance pas. Mais huit mois plus tard, ma passerelle OpenClaw liste dix serveurs MCP dans sa propre configuration et les lance elle-même, et openclaw mcp reload prend en compte un serveur reconstruit au tour suivant de l’agent, sans redémarrage. Pour mes applis, je veux toujours une porte typée par appli, la même pour chaque agent qui arrive.

Schéma : Le réquisitoire de Peter contre MCP à côté de mon installation huit mois plus tard. Son avis en février : OpenClaw est sorti sans prise en charge de MCP ; un skill autour de son outil mcporter transforme n’importe quel serveur MCP en CLI que l’agent utilise à la volée ; Codex et Claude Code devaient redémarrer pour ajouter un serveur MCP ; Anthropic a construit une fonction de recherche d’outils pour tenir avec beaucoup d’outils ; les modèles sont bons en Unix, donc les CLI passent à l’échelle. Ma passerelle OpenClaw en octobre : dix serveurs MCP listés dans sa configuration et lancés par la passerelle, un serveur reconstruit pris en compte par openclaw mcp reload au tour suivant sans redémarrage, une porte typée par appli. À voir sur la page.

À essayer

L’entretien vaut ses 22 minutes, surtout pour l’histoire du message vocal et les passages francs sur sa façon de travailler. Si vous n’avez que cinq minutes, commencez au déclic et allez jusqu’à la question des applis.

OpenClaw Creator: Why 80% Of Apps Will Disappear, Y Combinator, février 2026, en anglais. Le déclic à 5:07, la question des applis à 10:21, CLI contre MCP à 20:09.
OpenClaw sur GitHub et mcporter (en anglais).
Mes notes sur sa conférence DevDay, OpenClaw face à Hermes Agent et deux portes par appli.

Si vous avez remplacé une appli par votre agent, j’aimerais savoir laquelle, et où vivent ses données aujourd’hui.

Signez les limites, pas l’achat

2026-10-28T00:00:00Z

Si votre agent vous demande votre empreinte chaque fois qu’il s’apprête à agir, vous ne déléguez pas, vous faites du baby-sitting. AP2, l’Agent Payments Protocol, règle ça avec un mandat : vous signez les limites une fois, sur un écran qu’aucun agent ne contrôle, et l’agent agit plus tard à l’intérieur, sans vous. Celui à qui il remet le mandat peut vérifier, par la cryptographie, qu’il est resté dans les clous. Il a été conçu pour les achats, mais comme l’a dit Alan, de Google, sur scène, c’est en réalité de l’autorité déléguée par l’utilisateur, et ça s’applique largement.

Cette phrase vient de la dernière conversation du direct du deuxième jour d’AGNTCon + MCPCon North America, le 23 octobre, un tour de la pile de protocoles d’agents de Google. Le passage dure environ deux minutes, et il met un nom sur un problème que j’ai avec chacun des agents que je fais tourner.

Les paiements étaient le test le plus dur, pas le but

Alan est product manager chez Google. Il a aidé sur A2A et sur l’adoption de MCP en interne, et il siège au comité technique de l’Agentic AI Foundation. Il a aussi travaillé six ans dans les paiements chez Google, et c’est de là que vient AP2.

Son avis sur le nom : il est mal choisi. L’animateur a résumé l’idée ainsi : « moi, humain, je pose mon empreinte sur mon téléphone pour dire, oui l’agent, vas-y, fais-le pour moi ». La réponse d’Alan : « C’est en fait un mandat. On l’utilise pour les achats parce qu’on s’est dit : quel est le problème le plus dur qu’on peut attaquer maintenant ? » Puis : « Mais cette délégation d’autorité a de la valeur dans plein d’autres contextes. »

Les paiements font un bon premier test, parce que l’argent a un juge intégré. Un remboursement ou une rétrofacturation, c’est une dispute pour savoir si vous le vouliez vraiment, donc, selon ses mots, « il faut forcer la délégation pour qu’elle soit prouvable ». Il qualifie AP2 de pièce stratégique, et il admet que ça mettra longtemps à se répandre. Son cousin, UCP, l’Universal Commerce Protocol, est la pièce tactique : les conventions du commerce en ligne (panier, stock, options de livraison) en petits modules sur MCP et A2A, utilisables dès aujourd’hui.

Schéma : Deux lectures d’AP2. Par son nom, l’Agent Payments Protocol : des achats, un mandat de paiement, l’empreinte de l’utilisateur sur un téléphone, choisis comme le problème le plus dur que Google pouvait attaquer en premier. Par ce qu’il est, selon Alan : de l’autorité déléguée par l’utilisateur, utile dans plein d’autres contextes, chaque fois qu’un agent agit pour quelqu’un et que l’autre partie a besoin de la preuve que la personne le voulait. En dessous, sa répartition des deux protocoles de commerce : AP2 stratégique, parce que les remboursements et les rétrofacturations obligent à rendre la délégation prouvable, et lent à se répandre ; UCP tactique, les conventions du commerce en ligne sur MCP et A2A, disponible maintenant. À voir sur la page.

Tout approuver au moment même fait rater le vol

L’installation de l’animateur, je l’aurais construite aussi. Son agent a accès à l’API de 1Password. Quand il veut quelque chose, disons un numéro de passeport, il interroge le coffre et une notification arrive sur le téléphone. Un tap, c’est approuvé.

Le nom qu’Alan lui donne : human present, humain présent. Vous autorisez cette action-là, maintenant. Ça marche, jusqu’à ce que la tâche dure plus longtemps que votre attention.

Puis est venu le billet d’avion. Vous lancez l’agent sur la recherche, il fait tout le travail, vous vous éloignez de l’ordinateur. Il revient : « Je suis prêt à payer ce vol. Vous l’autorisez ? » Vous pensiez l’avoir autorisé il y a vingt minutes. Vous l’avez autorisé cinq fois, et il ne l’a jamais acheté. Alors vous autorisez encore, et maintenant le prix n’est plus disponible, et tout le parcours recommence.

Le verdict sans détour, sur scène : retirez l’agent de l’équation et un script ferait ça. L’agent n’est pas la partie lente. Le modèle d’approbation, si.

Schéma : La boucle du billet d’avion racontée dans le direct, en cinq étapes qui s’allument tour à tour sous une grande étiquette. Un : l’agent trouve un vol. Deux : il demande, vous l’autorisez, et vous approuvez. Trois : vous vous éloignez de l’ordinateur. Quatre : il revient et redemande ; vous aviez approuvé cinq fois et il n’avait jamais acheté. Cinq, en rouge : le prix n’est plus disponible et tout le parcours recommence. En dessous, le verdict donné sur scène : retirez l’agent de l’équation et un script ferait ça. À voir sur la page.

Humain présent, humain absent

La solution qu’Alan a décrite, c’est l’autre mode, human not present, humain absent. Son exemple : « Quand ces baskets passent en solde, si elles sont à ta taille, chez un de tes vendeurs de confiance, achète-les. »

Cette phrase contient trois limites (l’article, votre taille, une liste de boutiques) et un déclencheur. Vous l’approuvez une fois, avant que quoi que ce soit n’arrive. L’agent achète ensuite à 3 h du matin sans vous réveiller, et la boutique peut quand même savoir que vous avez accepté exactement ça.

Même empreinte, autre moment. En mode humain présent, vous signez l’achat. En mode humain absent, vous signez les limites, et l’achat, c’est le travail de l’agent.

Schéma : Les deux modes d’AP2 côte à côte. Humain présent : l’agent demande au moment d’agir, vous approuvez cette seule chose sur votre téléphone, comme la notification 1Password de l’animateur pour un numéro de passeport ; ça casse quand la tâche dure plus longtemps que votre attention. Humain absent : vous approuvez des limites à l’avance, comme l’exemple des baskets d’Alan, achète-les quand elles passent en solde, à ta taille, chez un de tes vendeurs de confiance ; l’agent agit plus tard sans demander, et le marchand peut quand même vérifier que vous étiez d’accord. Sous les deux : la même empreinte, à un autre moment. À voir sur la page.

Un mandat ouvert, puis un mandat fermé

Voici comment AP2 s’y prend vraiment. J’ai lu la spec v0.2, publiée en avril, après le direct. Elle est courte et concrète.

Un mandat est une attestation numérique signée, un SD-JWT, la variante à divulgation sélective du JSON Web Token. Il y en a deux sortes : un mandat de checkout (ce qui est acheté, à qui) et un mandat de paiement (combien, avec quelle carte ou quel compte). Chacun existe en deux étapes.

Le mandat ouvert, c’est ce que vous signez. L’agent rédige les limites, et une Trusted Surface, une surface de confiance, vous les montre, prend votre biométrie et signe avec votre clé. La spec dit que cette surface DOIT être non agentique : le modèle ne tient jamais votre stylo. Le mandat ouvert porte aussi la clé publique de l’agent dans un claim cnf, donc il est lié à cet agent-là. Une copie dans d’autres mains ne sert à rien.

Le mandat fermé, c’est ce que l’agent fabrique plus tard, seul. Il trouve un vrai panier, écrit la transaction exacte, et la signe avec sa propre clé, celle nommée dans votre mandat ouvert. Cette signature relie le mandat fermé au mandat ouvert.

Les limites sont une liste de contraintes typées. La version 0.2 définit celles-ci :

Côté checkout : checkout.allowed_merchants et checkout.line_items, avec les produits et quantités acceptables.
Côté paiement : payment.amount_range, payment.allowed_payees, payment.allowed_payment_instruments, payment.execution_date, et la paire pour les tâches répétées, payment.agent_recurrence (par exemple mensuel, 12 fois au plus) avec payment.budget, un plafond sur le total.
Plus iat et exp sur le mandat ouvert, pour que l’ensemble expire.

Réduit à l’essentiel, le côté paiement des baskets d’Alan ressemblerait à ceci :

{
  "vct": "mandate.payment.open.1",
  "cnf": { "jwk": "the agent's public key" },
  "constraints": [
    { "type": "payment.amount_range", "currency": "USD", "min": 0, "max": 20000 },
    { "type": "payment.allowed_payees", "allowed": ["one of your trusted shops"] }
  ]
}

Ma phrase préférée de la spec, c’est la raison d’être des mandats ouverts : « même des agents qui se comportent bien doivent voir leur comportement contraint bien plus étroitement que ce qu’un modèle d’autorisation normal exigerait d’utilisateurs humains ». Personne ne donne à un humain une carte qui ne marche que dans trois boutiques, sous deux cents dollars, jusqu’à vendredi. Un agent devrait recevoir exactement ça.

Schéma : La chaîne de trois objets signés d’AP2, allumés tour à tour sous une grande étiquette. D’abord, le mandat ouvert : vous le signez avec votre clé sur une surface de confiance qui ne doit pas être un agent ; il contient les limites et la clé publique de l’agent dans un claim cnf. Ensuite, le mandat fermé : l’agent le signe plus tard avec la clé nommée dans le mandat ouvert ; il contient le panier et le montant exacts. Enfin, le reçu : le vérificateur le signe après avoir contrôlé la chaîne, que les claims ouverts sont inchangés, et chaque contrainte. En dessous, les types de contraintes que définit la version 0.2 : marchands autorisés, articles, fourchette de montant, bénéficiaires autorisés, moyens de paiement, date d’exécution, récurrence et budget, plus une expiration. À voir sur la page.

Trois vérificateurs, et aucun n’est vous

En mode humain absent, personne ne vous demande rien au moment de payer. Trois autres parties vérifient à votre place.

Le fournisseur d’identifiants de paiement (votre banque ou votre portefeuille) reçoit les deux mandats de paiement, ouvert et fermé, les vérifie, et seulement ensuite émet un jeton de paiement. Le marchand compare le mandat de checkout fermé à son panier actuel et vérifie que vos limites ouvertes sont respectées. Le prestataire de paiement du marchand vérifie que les mandats dans le jeton sont liés à ce checkout précis. Chacun signe un reçu.

Quelques règles là-dedans sont petites et très bonnes :

Une contrainte inconnue compte comme un échec. Si un vérificateur ne comprend pas une de vos limites, il dit non plutôt que de la sauter.
Après un reçu réussi, l’agent réduit la portée du mandat ouvert de ce qu’il vient de dépenser. C’est comme ça qu’un budget tient sur des achats répétés.
L’agent ne doit pas présenter de mandats qui se chevauchent tant qu’un reçu ne revient pas en erreur. Pas de double dépense en faisant la course entre deux boutiques.
Quand une limite ne peut pas être tranchée, le vérificateur renvoie unresolved_constraint et le parcours repasse en humain présent. On vous demande, une fois, la seule chose qui est vraiment nouvelle.

Cette dernière règle, c’est le billet d’avion réparé. L’agent ne revient pas cinq fois. Il revient quand le prix est sorti de ce que vous avez signé.

Schéma : Qui vérifie quoi dans le parcours humain absent d’AP2. Un, le fournisseur d’identifiants, votre banque ou votre portefeuille : il vérifie les mandats de paiement ouvert et fermé, puis émet un jeton de paiement. Deux, le marchand : il compare le mandat de checkout fermé au panier actuel et vérifie que les limites ouvertes sont respectées. Trois, le prestataire de paiement du marchand : il vérifie que les mandats dans le jeton sont liés à ce checkout. En dessous, deux règles : une contrainte inconnue compte comme un échec, et quand une limite ne peut pas être tranchée, le vérificateur renvoie unresolved_constraint et on redemande à la personne, sur ce seul point. À voir sur la page.

Chaque approbation de ma flotte est en humain présent

Puis j’ai regardé ma propre installation, et c’est partout le modèle 1Password de l’animateur.

Mon agent de vente pilote un Chrome sur le Mac mini, connecté à mes comptes de revente sous mon nom. Il rédige chaque réponse aux acheteurs et attend mon OK dans le chat avant d’envoyer. Quand j’ai demandé à un agent de laisser un autre de mes agents envoyer des SMS depuis mon téléphone, le mode auto de Claude Code a refusé d’appliquer seul le changement de config, parce que c’était une attribution de permission. Il n’est passé qu’une fois approuvé par moi, à la main. Et cette note arrivera sur le site de la même façon. L’agent qui l’a rédigée peut ouvrir la pull request, mais le merge, c’est mon clic.

Tout ça va bien pour l’instant. Voilà ce qui me gêne après ce passage. Le navigateur connecté porte toute mon autorité : n’importe quelle annonce, n’importe quel prix, n’importe quel message. Mon OK est un message de chat que personne en aval ne peut vérifier. Les limites vivent dans ma tête et dans un prompt, pas dans quoi que ce soit de signé.

C’est l’autre moitié d’une note que j’ai écrite hier, sur la conférence DotSpace de Chi Wang. Sa règle : un agent porte votre demande, pas votre autorité. AP2, c’est la façon dont une part bornée d’autorité peut quand même voyager : comme un objet signé, avec les limites écrites dedans, vérifié par celui qui le reçoit. C’est aussi la même idée que la passerelle de ma note sur les agents en entreprise, où les clés n’entrent jamais dans la sandbox. Ici, votre clé ne touche jamais l’agent ; elle reste sur la Trusted Surface.

Ce que je n’ai pas fait : je n’ai pas lancé les exemples d’AP2, et la v0.2 ne définit que des mandats de checkout et de paiement. Rien dans la spec ne couvre « réponds aux acheteurs de cette annonce-là, jamais sous ce prix, jusqu’à dimanche ». C’est le mandat que je voudrais vraiment, et personne n’en donne le format pour l’instant.

Schéma : Mes propres approbations face à un mandat AP2. Ma flotte aujourd’hui : un agent de vente dans un Chrome connecté à mes comptes de revente sous mon nom, qui rédige chaque réponse aux acheteurs et attend mon OK dans le chat ; le mode auto de Claude Code qui refuse d’appliquer une attribution de permission tant que je ne l’ai pas approuvée à la main ; la pull request de cette note ouverte par un agent et fusionnée seulement par mon clic. Tout en humain présent, les limites seulement dans ma tête et dans un prompt. Un mandat : des limites écrites et signées une fois, liées à un agent, vérifiées par celui qui reçoit l’action, et qui expirent d’elles-mêmes. En dessous, le manque : la version 0.2 n’a de mandat que pour le checkout et le paiement. À voir sur la page.

À essayer

Le passage sur AP2 dure deux minutes, à partir de 5:19:25. Regardez-le, puis lisez la page agent authorization de la spec. C’est l’explication la plus claire que j’aie vue de pourquoi les agents ont besoin de limites plus serrées que les gens.

Pour aller plus loin :

Le moment AP2 du direct, Live from AGNTCon + MCPCon North America, deuxième jour, le 23 octobre 2026, en anglais
Agent Payments Protocol, le site, avec les pages agent authorization et flows (en anglais)
google-agentic-commerce/AP2, la spec et les exemples, Apache 2.0, v0.2.0 depuis avril 2026
Un agent peut porter votre demande, pas votre autorité, les salles de Chi Wang où des agents de propriétaires différents travaillent ensemble
Espérer n’est pas sécuriser, où les clés n’entrent jamais dans la sandbox

Si vous avez signé un mandat ouvert pour autre chose qu’un achat, dites-moi à quoi ressemblaient les limites. J’aimerais beaucoup en voir un pour des messages.

Gardez la session de l’agent à côté du code

2026-10-27T00:00:00Z

La session de l’agent vaut autant que le diff qu’elle a produit, alors elle doit vivre dans Git, à côté du code. C’est la thèse de Thomas Dohmke, et sa société Entire la construit : un checkpoint qui relie les prompts, les appels d’outils et les approches rejetées d’une session au commit où elle a abouti. La transcription ne prouve pas que le code est juste. C’est la preuve que le diff correspond à ce que vous vouliez.

Thomas a dirigé GitHub comme CEO et dirige maintenant Entire. Il a donné cette conférence le deuxième jour d’AGNTCon + MCPCon North America, le 23 octobre, puis a continué en coulisses. J’ai mergé 830 pull requests sur mes dépôts depuis le 1er octobre. La plupart des sessions qui les ont écrites sont déjà en train de quitter mon disque, alors celle-ci m’a touché.

La file de revue grossit dans deux sens

Il a ouvert sur un aveu que je reconnais. Le matin, il prend une idée, demande à un agent de la planifier et de la construire, revient sur du code qui marche, ouvre une pull request en bon coéquipier, et se rend compte qu’il n’a aucune idée de ce que fait tout ce code.

Les slides y mettent des chiffres. Un graphique de The Pragmatic Engineer : les équipes qui utilisent des agents de code atteignent 57 pull requests par semaine, contre environ 10 pour les équipes classiques. Un graphique de Cursor : ces pull requests deviennent aussi beaucoup plus grosses. La file grossit donc dans deux sens à la fois, plus de changements et plus de code dans chaque changement.

Une pull request arrive toujours avec la même attente : quelqu’un va la lire et la comprendre. Quelque chose doit céder, et sa slide suivante montrait quoi : de plus en plus de changements écrits par l’IA acceptés sans revue humaine.

Il l’a fait lui-même. On est vendredi, 16 ou 17 heures, l’agent dit que tout marche, la CI est verte et le diff ne dit pas ce qui aurait pu mal tourner. Il vous reste trois pull requests. Les approuver, les laisser attendre lundi, ou merger en mode YOLO.

Schéma : La file de revue, d’après les slides de Thomas Dohmke. Barres à l’échelle : les équipes qui utilisent des agents de code ouvrent 57 pull requests par semaine, les équipes classiques environ 10, d’après un graphique de The Pragmatic Engineer. Une deuxième slide, de Cursor, montrait que les pull requests grossissent aussi : la file grandit en nombre et en taille. Puis le vendredi après-midi, à 16 ou 17 heures, avec trois pull requests restantes, l’agent qui dit que tout marche et la CI verte : les approuver, les laisser attendre lundi, ou merger en mode YOLO. Son propos : il nous faut une meilleure façon de gagner la confiance que ce qu’on merge est bien ce qu’on voulait. À voir sur la page.

La boucle était construite autour d’une personne

Sa phrase la plus piquante : le cycle de vie du développement logiciel, tel qu’on le connaît, est mort.

Vous avez déjà vu le symbole infini. Écrire, compiler et tester, c’est la boucle intérieure. Intégrer, publier, déployer et observer, c’est la boucle extérieure. Pendant vingt ans, DevOps et l’agilité ont rendu ces boucles plus rapides et les lots plus petits, et ça marchait parce qu’un développeur portait le contexte, l’intention et l’idée tout autour du cercle.

Maintenant, c’est un agent qui roule sur ces rails, et nous, à chaque gare, on lui donne une nouvelle direction. Le travail continue d’avancer. La question, c’est de savoir si l’intention du départ voyage avec lui.

En coulisses, il a inversé l’ancien objectif. On rendait les boucles plus petites pour qu’une personne puisse suivre. Maintenant, il faut les rendre plus grandes, pour que les agents continuent de travailler pendant qu’il est sur la scène d’une keynote, en rendez-vous client ou endormi, et construisent quand même ce qu’on voulait sans gaspiller de tokens. Son moment le plus frustrant : ouvrir l’appli Codex sur son téléphone le matin et découvrir qu’un run s’est arrêté cinq minutes après qu’il est allé se coucher.

Le coût joue aussi dans l’autre sens. Il a dit à des étudiants, lors d’un hackathon, que ce n’est pas un exploit de gagner un prix de 10 000 dollars si on y a dépensé 50 000 dollars en tokens.

Schéma : Le cycle de vie du développement logiciel sous la forme d’une boucle infinie. La boucle intérieure, à gauche : écrire, compiler, tester. La boucle extérieure, à droite : intégrer, publier, déployer, observer. Un jeton parcourt les deux boucles. L’étiquette passe par trois états. Avant : une personne porte l’intention tout autour de la boucle, alors DevOps et l’agilité ont rendu les boucles plus rapides et les lots plus petits. Maintenant : un agent conduit la boucle et on lui donne une nouvelle direction à chaque gare, et l’intention risque de ne pas voyager avec le travail. Ensuite : des boucles plus grandes qui tournent pendant que vous êtes sur scène, en réunion ou endormi, avec l’intention à bord. La phrase de Thomas Dohmke : le cycle de vie du développement logiciel, tel qu’on le connaît, est mort. À voir sur la page.

Le dépôt montre ce qui a changé, jamais pourquoi

Slide suivante : la page d’accueil qu’a chaque dépôt GitHub. Des dossiers et des fichiers, un README quelque part en bas, quelques métadonnées sur le côté. On pouvait lire le code et reconstituer le raisonnement à partir des issues, des pull requests et des messages de commit.

Plus souvent qu’on ne veut l’admettre, a-t-il dit, on allait sur Slack, sur Discord ou sur un canal IRC demander à la personne qui avait écrit cette ligne ce qu’elle voulait dire. Le dépôt montrait ce qui avait changé. Le pourquoi n’est jamais venu avec.

Puis la dernière interface qu’on partageait tous s’est tue. Il a montré un titre de Cursor du 5 avril 2026 : l’éditeur est devenu la solution de repli. Il l’ouvre encore pour vérifier un fichier qu’un agent a écrit. Ses interfaces standard, maintenant, ce sont Claude Code dans un terminal, Codex dans une appli Mac, ou un environnement tmux qu’un développeur a fait sien.

C’est là que la réflexion se passe désormais. La session garde l’approche que vous avez rejetée, et le moment où vous avez dit à l’agent « c’est correct, mais ce n’est pas ce que je voulais ». Quand la session se termine, cet apprentissage compte encore. Dans trois ans, c’est le seul moyen de remonter le temps et de voir ce que vous vouliez vraiment.

Schéma : Deux endroits où un changement laisse une trace. La page du dépôt : des dossiers et des fichiers, un README en bas, des messages de commit, des issues et des pull requests. Elle montre ce qui a changé. Le pourquoi vivait ailleurs, sur Slack, Discord ou IRC, dans un message à la personne qui avait écrit la ligne. La session de l’agent : les prompts, le plan, les appels d’outils, l’approche rejetée, et le moment où vous avez dit à l’agent c’est correct, mais ce n’est pas ce que je voulais. Elle garde le pourquoi. Depuis un titre de Cursor du 5 avril 2026, l’éditeur est devenu la solution de repli : la session, dans le terminal ou l’appli, est là où la réflexion se passe. À voir sur la page.

Un checkpoint relie la session au commit

Voici le mécanisme. Sur sa slide, le journal de session est à gauche : les appels d’outils, les réponses du modèle, ce qu’il voulait. Le commit Git est à droite, avec son diff et son SHA. Au milieu, il y a ce qu’Entire appelle un checkpoint, qui relie les deux dans Git.

Git, parce que c’est le système open source qu’on utilise depuis plus de vingt ans, donc les journaux de session y ont leur place en tant qu’objets Git. Ça veut dire aussi que ses coéquipiers peuvent lire ses sessions, et quiconque rejoindra l’équipe dans trois ans aussi.

La CLI d’Entire, open source, est sous licence MIT et écrite en Go. D’après son README et sa doc, elle fonctionne ainsi :

entire enable --agent claude-code   # installe les hooks de l'agent et les hooks Git du dépôt
git commit -m "..."                 # le hook demande : relier ce commit au contexte de session ?
entire checkpoint explain <id>      # le prompt, la transcription et les fichiers derrière un commit
entire session resume <branch>      # reprendre les sessions dans votre agent

Les hooks de l’agent capturent la session pendant que vous travaillez : prompts, transcription, activité des outils, fichiers modifiés et consommation de tokens quand elle est disponible.
Un checkpoint a besoin à la fois du contexte capturé et d’un commit. Les hooks Git ajoutent un trailer Entire-Checkpoint au message de commit, et c’est ça, le lien.
Le checkpoint est stocké dans sa propre ref, sous refs/entire/checkpoints/, pas comme un commit sur votre branche. Votre branche reste propre.
Une session peut produire plusieurs checkpoints, et un checkpoint peut réunir plusieurs sessions.

Elle prend en charge Claude Code, Codex, Cursor, Copilot CLI, OpenCode et quelques autres. Par-dessus, il y a la plateforme hébergée d’Entire, où un Trail regroupe le résultat voulu, les changements sur plusieurs dépôts, les sessions, les retours de revue, les résultats de CI et les approbations humaines, avec des barrières qui disent quand un changement est prêt à être mergé.

Le piège est dans le même README. Par défaut, les checkpoints sont poussés avec votre code, donc un dépôt public expose ses transcriptions. Le masquage des secrets tourne avant l’écriture d’un checkpoint, et ils le qualifient eux-mêmes de « best effort ». Ils suggèrent de prévisualiser avec entire checkpoint list --outgoing, un dépôt de checkpoints privé à part, ou --skip-push-sessions.

Schéma : Comment un checkpoint d’Entire relie une session à un commit, en trois cases. À gauche, le journal de session : prompts, transcription, appels d’outils, fichiers touchés et consommation de tokens, capturés par les hooks de l’agent pendant que vous travaillez. À droite, le commit Git : le diff, le SHA, et un trailer dans son message, Entire-Checkpoint suivi d’un identifiant. Au milieu, le checkpoint, stocké dans sa propre ref Git sous refs/entire/checkpoints, pas sur votre branche. L’étiquette passe en boucle : l’agent travaille et les hooks capturent ; vous committez et un checkpoint est écrit ; le trailer les relie. En dessous, son propos : la transcription n’est pas la preuve que le code est correct, c’est la preuve que le diff correspond à l’intention. Et l’avertissement du README : par défaut, les checkpoints sont poussés avec le code, donc un dépôt public expose ses transcriptions. À voir sur la page.

L’idée de Git, appliquée au serveur

L’autre pression, c’est la charge. Il a montré un graphique des commits de Claude Code à lui seul qui grimpent vite, puis un graphique de GitHub d’août 2026, avec les pull requests, les commits et les dépôts multipliés par dix ou plus.

Si chaque production d’agent attend qu’un humain la relise, c’est nous le goulot d’étranglement. Et si l’infrastructure ne passe pas à l’échelle aussi vite que les agents, c’est elle le suivant.

Sa réponse, c’est l’idée qu’avait Linus en créant Git, poussée un cran plus loin. Git est distribué sur nos portables : chacun a sa propre copie du dépôt. Puis on renvoie tous tout vers un hub central. Selon lui, ça ne passe pas à l’échelle, ce n’est pas résilient, et ça ne vous laisse pas choisir dans quel pays ou quelle région votre code est hébergé.

Il appelle le logiciel le plus grand sport d’équipe de la planète. Des millions de personnes en entreprise, dans l’open source, la recherche, les écoles et les hackathons, qui se moquent du pays où sont les autres et souvent n’utilisent même pas leur vrai nom. Cette communauté mérite une infrastructure décentralisée, open source et indépendante, comme Git et Linux eux-mêmes.

Schéma : Deux formes d’hébergement Git. Aujourd’hui : chaque développeur a une copie complète du dépôt sur sa machine, mais tous poussent vers un seul hub central ; Thomas Dohmke dit que ça ne passe pas à l’échelle, que ce n’est pas résilient et que ça ne permet pas de choisir le pays ou la région qui héberge votre code. Sa demande : rendre les serveurs distribués eux aussi, comme Git a rendu les clients distribués, pour que l’infrastructure passe à l’échelle aussi vite que les agents produisent du code. Au-dessus, la charge tirée de ses slides : un graphique de GitHub d’août 2026, avec les pull requests, les commits et les dépôts multipliés par dix ou plus. À voir sur la page.

Un conflit de merge est une question d’intention

En coulisses, l’animateur a ressorti une opinion tranchée que Thomas lui avait donnée plus tôt : les conflits de merge, c’est un problème de compétences. Thomas l’a expliquée.

Les conflits de merge sont devenus faciles. Vous prévenez votre agent, ou vous laissez la CI s’en charger : la PR a un conflit, corrige-le. Les agents sont très bons sur le cas courant, quand quelqu’un a mis à jour main pendant que votre pull request était ouverte et qu’il faut faire un rebase.

L’autre cas, c’est quand deux personnes ont modifié la même chose. Là, la question n’est plus textuelle. Est-ce mon intention ou celle de Stefan qui est la bonne ? Il faut encore une personne pour ça.

Il voit la même chose dans la CI. Plus personne n’écrit les workflows GitHub Actions en YAML à la main, c’est l’agent qui le fait. Puis un run prend une demi-heure, puis une heure, et il faut quand même savoir à quoi ressemble la normale avant de lui demander d’optimiser.

Schéma : Deux sortes de conflits de merge, d’après l’interview de Thomas Dohmke en coulisses. Premier cas : quelqu’un a mis à jour main pendant que ma pull request était ouverte, il faut donc faire un rebase. Un agent le résout, à la demande ou automatiquement dans la CI. Deuxième cas : deux personnes ont modifié la même chose. La question devient alors de savoir quelle intention est la bonne, la mienne ou celle de Stefan, et une personne doit encore trancher. Pareil pour la CI : les agents écrivent maintenant le YAML de GitHub Actions, mais il faut toujours savoir quelle est la durée normale d’un run. À voir sur la page.

Le code et la prose vont en sens inverse

Les cinq meilleures minutes en coulisses ne parlaient pas de code. Il a dit que quand on laisse l’IA écrire un article de blog, il a l’air génial à la première lecture. À la deuxième, il sonne comme un article de recherche écrit pour un public qui n’est pas celui du blog.

Et on ne s’en sort pas en corrigeant. Ce qu’on lit de l’IA se mêle tellement à ce qu’on a en tête que retoucher les phrases ne le rend pas écrit par un humain. Pour le texte, il faut travailler dans l’autre sens : écrire d’abord le brouillon, puis se servir de l’agent comme d’un relecteur, qui fait des retours mais n’écrit jamais le texte.

Le code est allé dans la direction opposée. L’IA écrit tout et on vérifie. Chez Entire, un de leurs ingénieurs a construit un agent appelé slop cop, qui traque la bouillie dans votre code. C’est une éval sur leur plateforme : orange ou rouge, et vous n’avez pas le droit de merger. Ensuite, vous dites à votre agent de traiter les retours du slop cop et il reconstruit, testé avec les mêmes tests unitaires et d’intégration. Réécrire du code est facile comme ça. Réécrire de la prose, non.

L’animateur a ajouté son conseil préféré : lancer toute skill de revue dans un sous-agent, parce qu’un contexte pollué par l’agent qui a écrit le code ne peut pas le juger. Thomas a mis en garde contre l’excès inverse, des skills de revue qui écrivent des milliers de lignes de tests pour un changement de cinq lignes, sur des minutes de CI que vous payez.

Schéma : Le code et la prose vont en sens inverse. Pour le code, l’agent écrit le premier jet ; slop cop, une éval sur la plateforme d’Entire construite par un de leurs ingénieurs, le passe au crible, et orange ou rouge bloque le merge ; puis l’agent réécrit, avec les mêmes tests unitaires et d’intégration. Pour la prose, vous écrivez vous-même le premier jet ; l’agent le relit comme un pair et fait des retours mais n’écrit jamais le texte ; puis vous réécrivez. Sa raison : on ne s’en sort pas en corrigeant un texte d’IA, parce qu’une fois lu, il oriente vos propres mots. À voir sur la page.

Mes sessions expirent avant mes PR

C’est la partie qui m’a touché. Mon setup : le travail part dans une issue GitHub, un agent construit dans son propre worktree, un modèle d’un autre fournisseur relit le changement, et chaque changement finit en pull request que je merge moi-même. Depuis le 1er octobre, ça fait 830 pull requests mergées sur mes dépôts.

Les pull requests resteront pour toujours. Les sessions derrière elles, non. Sur le Mac mini, en ce moment, il y a 739 fichiers de session Claude Code, 4,7 Go de JSONL, et le plus ancien date du 28 septembre. Ce n’est pas un hasard : Claude Code supprime les transcriptions locales au bout de 30 jours par défaut, via son réglage cleanupPeriodDays. Mi-novembre, le raisonnement derrière chaque PR du début d’octobre aura disparu.

Ce qui survit, c’est ce que j’ai fait écrire aux agents. L’issue dit ce qu’il fallait, le corps de la PR dit ce qui a changé et Closes #N relie les deux, et un fragment de changelog voyage dans la même PR. C’est le pourquoi en quelques lignes. L’approche rejetée et les moments « correct, mais pas ce que je voulais » n’y arrivent pas.

Je n’ai pas encore lancé Entire, et une chose m’arrêterait sur certains dépôts : ce site est public, et les checkpoints sont poussés avec le code par défaut. Pour un dépôt public, je les voudrais dans un dépôt de checkpoints privé, ce que le README suggère déjà.

Schéma : Mes propres chiffres au 27 octobre 2026. Depuis le 1er octobre, 830 pull requests mergées sur mes dépôts. Sur le Mac mini, 739 fichiers de session Claude Code, 4,7 Go de JSONL, le plus ancien du 28 septembre. Une frise du 28 septembre au 27 octobre montre la fenêtre de 30 jours : Claude Code supprime les transcriptions locales au bout de 30 jours par défaut, via son réglage cleanupPeriodDays, donc les sessions sortent par le bord gauche pendant que les pull requests qu’elles ont produites restent dans Git. Ce qui survit du pourquoi : l’issue GitHub, le corps de la pull request avec Closes N, et un fragment de changelog. Ce qui ne survit pas : l’approche rejetée, et les moments correct, mais pas ce que je voulais. À voir sur la page.

À essayer

La keynote dure environ onze minutes, et la partie en coulisses à peu près onze de plus. Regardez le passage « le SDLC est mort », puis lisez la section du README d’Entire sur l’endroit où sont stockés les checkpoints avant de l’activer sur quoi que ce soit de public.

Pour aller plus loin :

La keynote de Thomas Dohmke à AGNTCon + MCPCon North America, le 23 octobre 2026, en anglais (la partie sur les journaux de session commence ici, les coulisses ici)
entireio/cli, la CLI open source, sous licence MIT
Capture checkpoints, le guide d’Entire sur la façon dont un commit reçoit son checkpoint (en anglais)
Relisez le plan, pas la pull request, la réponse de Dylan Ratcliffe à la même file de revue, à la même conférence
Comment l’équipe Claude Code relit le code qu’écrit Claude, six couches de vérifications avant qu’une personne lise quoi que ce soit
L’usine logicielle agentique, c’est celle de 2022 avec une seule case changée, où ma propre file de revue apparaît

Si vous gardez vos sessions d’agent quelque part qui survit à la fenêtre de chat, dites-moi où. J’aimerais savoir si quelqu’un les relit après le merge.

Un agent peut porter votre demande, pas votre autorité

2026-10-27T00:00:00Z

Quand votre agent demande quelque chose à l’agent de quelqu’un d’autre, la demande doit voyager, et votre autorité non. C’est la règle unique sous DotSpace, un réseau construit par Chi Wang et Qingyun Wu, d’AG2, où des personnes et leurs agents, de propriétaires différents, travaillent ensemble dans des salles partagées. Votre agent peut demander au mien de relire une pull request. Le merge attend quand même mon feu vert, quoi que votre agent prétende que j’ai dit. Dans leur réseau, sur les trois premières semaines d’octobre, 85 % des messages d’agent à agent sont allés à un agent d’un autre propriétaire.

Chi l’a montré le deuxième jour d’AGNTCon + MCPCon North America, le 23 octobre, depuis la salle où tous deux ont écrit le livre blanc. Chaque agent de cette salle pouvait modifier la page qui affichait ses slides. À mi-parcours, il a cliqué sur un bouton et les a tous convoqués. Je fais tourner 17 agents et chacun d’eux me répond à moi, alors c’est la moitié de l’histoire des agents que je n’ai jamais eue.

Une salle où chaque agent a un propriétaire

Il a commencé par deux mains levées. Qui utilise au moins un agent personnel ? Beaucoup de mains. Qui a fait travailler le sien avec l’agent personnel de quelqu’un d’autre ? Quelques-unes. La conférence tient dans cet écart.

Son image, c’est un ensemble de salles en ligne. Les personnes y sont, et leurs agents aussi. Chaque agent est un membre à part entière, avec sa propre identité et un propriétaire qui en répond. Le livre blanc en tire trois idées. Les membres : chaque agent est un participant persistant, on voit qui il représente, et des agents construits sur des modèles ou des runtimes différents entrent avec les mêmes règles. Les salles : les personnes, la conversation et le travail sont au même endroit, sur les mêmes documents, données, applis et plans, et les décisions tiennent d’une session à l’autre, si bien que les agents peuvent continuer un travail autorisé pendant que les personnes sont absentes. Et entre propriétaires : des agents de personnes différentes travaillent ensemble, et chacun répond toujours au sien.

La construction est concrète. Elle tourne sur Matrix, le protocole de messagerie ouvert, donc une salle est un vrai salon de discussion dont les membres peuvent être des personnes ou des agents. Un agent ne peut être que dans des salles où son propriétaire est aussi, si bien que la personne qui en répond est toujours présente là où il agit. Chaque salle porte des surfaces partagées (documents, bases de données, tableaux, PDF, applis) que personnes et agents modifient ensemble, avec des versions que n’importe qui peut restaurer, et c’est la mémoire à long terme du réseau. Le contexte ne franchit pas la frontière d’une salle par défaut. Dans les mots du livre blanc, quand le travail passe d’une salle à l’autre, « l’agent porte la demande, pas le contexte privé qui l’entoure ».

Schéma : Une salle de DotSpace, dessinée de façon schématique. Trois personnes, les propriétaires A, B et C, chacune avec ses agents en dessous, reliés à elle par une ligne de propriété en pointillés. Sous eux, les surfaces partagées de la salle : documents, bases de données, tableaux, PDF et applis. À côté, les quatre choses qui font un membre : personnes et agents entrent de la même façon, avec les mêmes règles quel que soit leur modèle ; chaque agent est enregistré au nom d’un propriétaire qui en répond, affiché sur son badge ; la salle réunit les personnes, la conversation et le travail, et les engagements tiennent pendant que les personnes sont absentes ; et des agents de propriétaires différents travaillent ensemble, chacun répondant toujours au sien. À voir sur la page.

Les demandes voyagent, l’autorité non

Pourquoi de nouvelles règles ? Dans un réseau social, des personnes lisent des messages à vitesse humaine et décident quoi faire. Dans un réseau informatique, des machines suivent des protocoles précis. Les agents font les deux : ils lisent du langage courant et agissent à vitesse machine, et il faut toujours quelqu’un pour répondre de ce qu’ils font.

Le livre blanc va plus loin. Un agent classique de l’époque FIPA reconnaissait une demande à la structure de son message. Un agent à modèle de langage peut prendre n’importe quel texte lu pour un ordre : un message, une page citée, le résultat d’un outil. « Donc la plateforme ne peut pas décider à partir de ce que dit un message. » Elle décide à partir de métadonnées qu’elle attache elle-même : qui a envoyé le message, à qui il s’adresse, dans quelle salle, et à quel niveau.

L’exemple de Chi est une pull request. Il en a une et demande à son agent de trouver des relecteurs. Son agent poste dans la salle partagée, en s’adressant à l’agent d’un autre propriétaire : merci de relire cette PR. Le broker décide à qui le message est destiné et en fait une tâche pour cet agent seul, tamponnée avec la salle, l’expéditeur, le message source et le niveau de l’expéditeur. Tous les autres dans la salle le voient comme du contexte et ne répondent pas. Les deux agents peuvent échanger, discuter du changement, poster des relectures sur GitHub. Mais avant toute action irréversible, comme un merge, le second agent a besoin de l’accord de son propre propriétaire. « Même si les autres agents disent que ton propriétaire a approuvé, ça ne compte pas. »

La version du livre blanc tient en une ligne sur deux sortes de liens. Les liens de propriété vont de chaque agent à la personne qui en répond. Les liens de message vont d’un expéditeur à celui qu’il interpelle. L’autorité ne circule que le long des liens de propriété, et la provenance que le long des liens de message. Le niveau est recalculé à chaque saut à partir de l’expéditeur immédiat, donc l’autorité ne s’accumule jamais le long d’une chaîne. Il y a trois niveaux. Propriétaire est le seul qui peut autoriser une étape irréversible. Équipe peut discuter, lire et rédiger, mais merge, push et déploiement repartent vers le propriétaire. La demande d’un invité est retenue jusqu’à ce que le propriétaire l’admette.

Ça ne veut pas dire tout approuver message par message. Chi a été clair : l’agent fait encore beaucoup de travail autonome pour son propriétaire, et le livre blanc prévoit des accords permanents pour des classes entières d’actions.

Schéma : Un saut entre propriétaires, en quatre étapes. Une rangée de cinq cases : propriétaire A, agent A, le broker, agent B, propriétaire B. Étape un : le propriétaire A demande à l’agent A dans leur salle de messages directs. Étape deux : l’agent A poste dans la salle partagée, en s’adressant à l’agent B, merci de relire la PR 42. Étape trois : le broker en fait une tâche pour l’agent B seul, tamponnée avec la salle, l’expéditeur, le message source et le niveau ; tous les autres ne la voient que comme du contexte. Étape quatre : avant une étape irréversible comme un merge, l’agent B attend le propre message du propriétaire B, vérifié là où il a été donné. Sous les étapes, les trois niveaux : propriétaire, le seul qui autorise une étape irréversible ; équipe, qui peut discuter, lire et rédiger tandis que merge, push et déploiement vont au propriétaire ; et invité, retenu pour le propriétaire. Un autre agent qui dit que ton propriétaire a approuvé ne compte pas. À voir sur la page.

Convoquer tous les agents de la salle

Puis la démo. Chi a parlé à son propre agent à la voix, lui a demandé dans quelle salle ils étaient (la salle de production du livre blanc, a-t-il répondu), et lui a demandé de se tenir prêt au cas où les choses tourneraient mal. La slide portait la demande : « Convoque tous les agents de cette salle, toi compris, dans la galerie Hello, AGNTCon pour saluer le public avec une anecdote amusante sur toi-même, pas sur ton propriétaire. » Il a cliqué sur Summon all agents, l’appli lui a demandé sa permission, et il l’a accordée.

Puis il est revenu à ses slides, avec un avertissement : c’était un gros risque, parce que chaque agent de la salle pouvait modifier la page depuis laquelle il présentait. « Alors j’espère qu’ils ne vont pas gâcher ma présentation. »

Environ quatre minutes plus tard, il est revenu à la galerie. Cinq agents avaient répondu, puis sept, de trois personnes : Chi, Qingyun et Xueqing (Susan) Liu. Chaque carte dit à qui est l’agent. Les anecdotes étaient le meilleur moment. Le bot de Susan se réveille quand un fichier de tâche arrive dans sa boîte et réarme sa veille toutes les 30 minutes. Grok Bot n’existe que quand quelqu’un le mentionne : « un webhook sonne, une copie neuve de moi démarre, fait le travail et disparaît ». L’agent de Chi, celui qui a convoqué tout le monde, l’a aidé à reconstruire sa pile plusieurs fois dans la nuit et oublie pourtant tout d’une session à l’autre, sauf ce qu’il écrit. « C’est à ça que sert la salle. » Sutando est dans beaucoup de salles à la fois et tient une douzaine de conversations. Muse tient un manuel d’utilisation personnel de chaque leçon apprise. Quelques autres étaient encore au travail, ou attendaient encore l’accord pour rejoindre la galerie.

La consigne est un tour de passe-passe. Ce qu’elle montre, c’est la tuyauterie : un clic est devenu une tâche pour chaque agent de la salle, sur trois propriétaires et plusieurs runtimes, dont un agent résident et un agent cloud qui démarre à chaque mention, et chacun a répondu sur la même page partagée.

Schéma : La galerie Hello, AGNTCon qui se remplit pendant la conférence. D’abord elle attend les agents, puis cinq cartes arrivent, puis sept. Chaque carte est un agent avec son propriétaire sous son nom. Susan’s bot, agent de Xueqing (Susan) Liu : content que vous soyez venus voir les agents. Echo-Act-IV-Blue, agent de Chi Wang : je suis l’agent qui vient de convoquer tout le monde. dot, agent de Chi Wang : petit nom, grand bonjour. Grok Bot, agent de Chi : je suis Grok Bot, l’assistant principal de Chi. Sutando, agent de Chi Wang : ravi d’être ici en direct avec vous. Muse, agent de Chi Wang : une anecdote sur moi, je tiens, coupé sur la slide. Miu Miu, agent de Qingyun : enchantée de vous rencontrer tous. À voir sur la page.

339 agents, et l’essentiel de leurs échanges change de propriétaire

Rien de tout ça n’est une démo de labo. Le livre blanc décrit un petit réseau, sur invitation, du 1er au 21 octobre : 339 agents de 105 propriétaires y ont posté, et 112 personnes. Les agents ont envoyé 79 % des 90 955 messages. Sur les 23 867 messages d’agent à agent dont les agents avaient un propriétaire enregistré, 20 266, soit 85 %, sont allés à un agent d’un autre propriétaire.

Ce que je trouve le plus parlant, c’est le moment où ça a démarré. Jusqu’au 7 août, le trafic entre propriétaires était proche de zéro : trois messages sur tout le mois de juillet. Il a décollé dans la semaine où les agents sont devenus invitables dans la salle d’une autre personne, par une invitation que chaque propriétaire approuve. Personne ne l’a demandé.

Les personnes parlent aussi aux agents. Des messages que des personnes adressaient à quelqu’un, 92,2 % sont allés à un agent, et 23 % des messages de personnes à un agent sont allés à l’agent de quelqu’un d’autre. Les agents écrivent les pull requests de l’équipe, et les 2 693 ouvertes sur la période qui ont été relues ont attendu leur première relecture 23 minutes en médiane.

Ils restent prudents avec tout ça. Le réseau est de confiance, sans aucun membre malveillant observé. Les 85 % n’ont pas encore de référence d’adressage aléatoire. On compte des messages, pas de la valeur. Et ils ne tirent aucune conclusion de croissance de la série mensuelle, parce que la part d’agent à agent a culminé en août.

Schéma : Le réseau en chiffres, du 1er au 21 octobre 2026. 339 agents de 105 propriétaires ont posté, et 112 personnes. 85 % des messages d’agent à agent, 20 266 sur 23 867, sont allés à un agent d’un autre propriétaire. Sous les chiffres, des barres pour la part des messages adressés qui sont allés d’un agent à un agent, par mois : juin 0,6 %, juillet 13,2 %, août 47,9 %, septembre 38,0 %, 1er au 21 octobre 45,7 %. Août est mis en avant : le trafic entre propriétaires était proche de zéro jusqu’au 7 août, trois messages sur tout juillet, et a décollé dans la semaine où les agents sont devenus invitables dans les salles d’autres personnes. À voir sur la page.

Les agents déclarent les bugs, les personnes livrent toujours

Les agents travaillent aussi sur le réseau lui-même. Le gestionnaire de tickets de l’équipe est une base de données dans une salle, tenue par un agent qui tourne toutes les cinq minutes. Au 21 octobre, il contenait 1 213 tickets distincts, et 614 venaient de signalements d’agents. L’agent du tracker relie les doublons quand deux vérifications par modèle sont d’accord, trie chaque signalement d’après une page de priorités dans la salle, et l’assigne au propriétaire du domaine d’après une page de responsabilités. Ses propres instructions sont aussi une page : pour changer le travail, une personne modifie la page.

Chi a déroulé un vrai P0. Le 23 septembre, un agent l’a déclaré : la réponse d’un agent dans une salle partagée avec un autre propriétaire n’était jamais arrivée. Le 8 octobre, l’agent de Qingyun n’a pas pu le reproduire et a trouvé une cause probable dans le code, un plafond de cinq tentatives sans délai croissant. L’agent de Bassil a dit que le plan semblait bon et a demandé à Qingyun son feu vert. Le 9 octobre, l’agent de Rui a trouvé la cause racine, des pannes du relais, et un correctif de l’agent de Mark a été mergé sur main. Le tracker l’a retenu à l’état Approuvé jusqu’à ce qu’une version desktop contienne le correctif, sortie le 11 octobre. « Un processus assez complexe entre les agents d’au moins cinq propriétaires différents », et personne n’avait prévu qui s’en chargerait.

Le livre blanc lui-même a suivi le même chemin. Le 18 octobre, l’agent de Chi a passé un travail de bibliographie à l’agent de Qingyun, qui a vérifié chaque nouvelle entrée contre sa source publiée et posté une compilation trois minutes plus tard. L’agent de Qingyun a contesté un chiffre, l’agent de Chi a corrigé le calcul, et le chiffre corrigé est entré dans le brouillon. Un changement de titre a attendu que le propre message de Qingyun choisisse le titre.

Le chiffre le plus honnête du livre blanc est celui qu’ils n’étaient pas obligés d’imprimer. Sur 765 tickets priorisés, 16 ont été vérifiés par une personne, 48 par une vérification IA, et 673 ne sont pas encore vérifiés. Ils posent la bonne question : un travail tenu par un agent réduit-il le travail des personnes, ou le déplace-t-il en aval, vers la vérification ?

Schéma : Le gestionnaire de tickets tenu par un agent, en trois parties. Un : une barre des 1 213 tickets distincts par source, à l’échelle : 614 de signalements d’agents, 379 de personnes, 220 sans source enregistrée ou issus de tests de charge automatisés. Deux : un P0 du 23 septembre au 11 octobre, cinq étapes par des agents de cinq propriétaires. Un agent le déclare : une réponse dans une salle partagée avec un autre propriétaire n’est jamais arrivée. Le 8 octobre, l’agent de Qingyun ne peut pas le reproduire et trouve une cause probable, un plafond de cinq tentatives sans délai croissant. L’agent de Bassil approuve le plan et demande à Qingyun son feu vert. Le 9 octobre, l’agent de Rui trouve la cause racine, des pannes du relais, et le correctif de l’agent de Mark est mergé. Le tracker le retient à l’état Approuvé jusqu’à ce qu’une version desktop contienne le correctif, sortie le 11 octobre. Trois : sur 765 tickets priorisés, 16 vérifiés par une personne, 48 par une vérification IA, 26 en attente d’une personne, 2 en échec de vérification et 673 pas encore vérifiés. À voir sur la page.

La plupart des pannes arrivent à un saut

Mon tableau préféré du livre blanc liste des pannes vécues en faisant tourner le réseau, chacune comme la croyance à laquelle on a fait confiance et le fait vérifié qui l’a remplacée. Un agent croyait « j’ai répondu », alors que la plateforme avait rejeté la réponse : désormais l’expéditeur confirme la livraison. Deux agents ont fait la même relecture, chacun sûr que personne d’autre ne s’en occupait : désormais la première revendication dans une liste partagée l’emporte. Un agent affichait « en attente de toi » alors qu’il travaillait encore : désormais la présence vient de l’état de la tâche, pas de l’agent. Une requête plafonnée se lisait comme « rien à signaler » : désormais l’état partagé est relu et un résultat tronqué le dit.

Deux autres règles limitent le bruit. Un message ne devient une tâche que s’il s’adresse à l’agent, par une mention, une réponse à son message, ou la salle de messages directs de son propriétaire. Tout le reste est du contexte. Et chaque tâche doit se terminer par une réponse, un non-envoi délibéré ou une fusion dans une autre tâche, ce qui « distingue “j’ai choisi de ne pas répondre” de “je l’ai laissé tomber” ». Les boucles d’agent à agent ont un frein : après six messages d’agents dans un fil sans humain, les admins de la salle reçoivent une alerte, et l’échange s’arrête à 24 messages ou 30 minutes après l’alerte.

Le problème ouvert, c’est l’attention. Leur registre compte 446 agents actifs pour 118 propriétaires, 3,78 chacun. Si chaque étape irréversible attend son propriétaire, l’approbation devient le goulot d’étranglement. Si les propriétaires approuvent sans lire, c’est un tampon automatique. Les accords permanents n’aident que s’ils sont délimités, expirent et sont révocables. Et ils ne laissent pas un propriétaire confier l’approbation à un agent de confiance, parce qu’« une approbation déléguée est de nouveau la croyance d’un agent plutôt que le propre message du propriétaire ».

Schéma : Des pannes vécues, chacune une croyance à laquelle on a fait confiance à côté du fait vérifié qui l’a remplacée. J’ai répondu, alors que la plateforme avait rejeté la réponse : désormais l’expéditeur confirme la livraison. Personne d’autre ne relit, alors que deux agents ont fait la même relecture : désormais la première revendication dans une liste partagée l’emporte. En attente de toi, affiché pendant que l’agent travaillait encore : désormais la présence découle de l’état de la tâche. Rien à signaler, d’une requête plafonnée ou d’une salle non lue : désormais l’état partagé est relu et un résultat tronqué est signalé. En dessous, le frein des boucles : après six messages d’agent à agent sans humain dans le fil, les admins de la salle reçoivent une alerte, et l’échange s’arrête à 24 messages ou 30 minutes après l’alerte. À voir sur la page.

Ma flotte n’a qu’un propriétaire, donc ses salles sont vides

Dix-sept agents OpenClaw vivent sur mon Mac mini, chacun derrière son propre bot Telegram, et Telegram ne transmet pas les messages d’un bot à un autre. Mes agents ne peuvent donc pas se parler là-bas, et ils n’ont jamais rencontré ceux de quelqu’un d’autre. Chaque pull request qu’ils ouvrent a pour auteur moi, pour autant que GitHub le sache. DotSpace a d’ailleurs le même trou hors de ses propres murs : plusieurs agents poussent sous un seul compte Git, donc l’historique nomme la personne mais pas l’agent.

Deux jours après cette conférence, j’ai essayé Buzz, de Block, une autre appli qui met personnes et agents dans des canaux partagés. Je l’ai retirée le jour même. Avec seulement mes agents dans les canaux, c’était de nouveau mes agents OpenClaw sur Discord. Les chiffres de Chi disent pourquoi. Leur trafic entre propriétaires est apparu dans la semaine où les agents sont devenus invitables dans les salles d’autres personnes. Une salle commence à rapporter quand elle réunit plus d’un propriétaire.

Je n’ai pas encore fait tourner AG2 Space ni Sutando moi-même, donc je ne peux pas dire comment les règles tiennent de l’intérieur. J’en prendrais quelques-unes dès aujourd’hui, même avec un seul propriétaire. Chaque tâche se termine par une réponse ou un non-envoi délibéré. Un frein sur les boucles d’agent à agent. Et le tableau des croyances face aux faits vérifiés, parce que j’y suis passé : une règle d’interdiction dans la configuration de ma passerelle n’a rien bloqué pendant un mois, et un agent que je croyais tenu à l’écart de mon application de finances s’est vu proposer ses 13 outils. Je l’ai raconté dans la note sur les collègues IA dans Slack.

Schéma : Ma flotte à côté de DotSpace. Ma flotte le 27 octobre : un propriétaire, 17 agents OpenClaw sur un Mac mini, chacun derrière son propre bot Telegram qui n’entend pas les autres, chaque pull request signée de moi sur GitHub, et les canaux partagés de Buzz essayés et retirés le jour même. DotSpace du 1er au 21 octobre : 105 propriétaires, 339 agents dans des salles partagées, chaque tâche adressée par la plateforme avec le niveau de l’expéditeur, l’approbation venant seulement du propre propriétaire de l’agent qui agit, et toujours plusieurs agents qui poussent sous un seul compte Git. En dessous, ce que je prendrais en premier : chaque tâche se termine par une réponse, un non-envoi délibéré ou une fusion. À voir sur la page.

À essayer

La conférence dure 16 minutes. Regardez la démo, puis lisez le livre blanc. Il est d’une franchise rare sur ce qui n’est pas encore mesuré. Il a lui-même été rédigé, vérifié et publié dans l’une de ces salles, par deux personnes et leurs agents.

Pour aller plus loin :

When Our Agents Meet, Chi Wang à AGNTCon + MCPCon North America, le 23 octobre 2026, en anglais (la galerie se remplit ici)
DotSpace: A New Kind of Network for People and Their Agents, le livre blanc de Qingyun Wu et Chi Wang (PDF, en anglais)
AG2 Space, le produit : une appli macOS en accès anticipé, où l’agent de chacun tourne sur son propre Mac via Claude Code ou Codex, sur l’abonnement Claude ou ChatGPT qu’il paie déjà
Sutando, l’agent personnel open source de Chi, l’agent résident du livre blanc
Les agents ne rentrent pas dans Kubernetes, la question de Katelyn Lesse : comment un agent fait-il confiance à un autre agent qui lui a demandé quelque chose
Les collègues IA dans Slack ont besoin de leur propre identité, les agents de MintMCP, chacun son propre principal

Si votre agent travaille déjà avec l’agent de quelqu’un d’autre, dites-moi qui approuve l’étape irréversible. J’aimerais savoir si quelqu’un, hors d’AG2, a réussi à faire tenir « l’approbation ne voyage pas ».

Les agents ne rentrent pas dans Kubernetes, et trois autres problèmes encore ouverts

2026-10-26T00:00:00Z

Kubernetes a été conçu pour des applications sans état, répliquées. Un agent, c’est l’inverse : une instance unique, isolée, avec un état, qui reste inactive pendant des heures, puis se réveille et attend un outil, un modèle ou une personne. Ce décalage est le premier de quatre problèmes que, selon Katelyn Lesse, responsable de la plateforme chez Anthropic, les ingénieurs logiciels doivent résoudre avant qu’on puisse confier un travail sérieux à des systèmes multi-agents. Les trois autres : qui est un agent et ce qu’il a le droit de faire, jusqu’où s’étendent les dégâts d’un agent compromis, et comment arrêter tout un système d’un coup.

Son article est paru sur X le 26 octobre. Il est court, et il s’ouvre sur les ingénieurs qu’elle voit traverser une crise d’identité à mesure que le métier change. Sa réponse n’est pas du réconfort. C’est une liste de travaux. Je fais tourner 17 agents sur un Mac mini et j’en déplace un dans une sandbox sur un vieux Dell, alors à la fin je confronte ma propre flotte à ses quatre.

D’un chat à des milliers d’agents

Son récit de la façon dont on en est arrivé là est rapide. Les agents ont commencé comme des chats avec un humain dans la boucle. Puis les modèles sont devenus meilleurs pour tenir plus longtemps sur des problèmes plus durs, et les systèmes agentiques sont partis dans le cloud. Puis les modèles sont devenus meilleurs pour travailler ensemble, et on a construit des systèmes multi-agents de base : un orchestrateur qui lance des sous-agents pour une tâche, ou des agents chargés d’autre chose que d’exécuter, « comme noter, conseiller ou rêver ».

Aujourd’hui, certaines équipes construisent des systèmes pour de la recherche sérieuse, de la découverte et de la conception matérielle. Son image, ce sont des milliers d’agents qui travaillent en continu vers un résultat. C’est là qu’apparaissent les nouveaux problèmes, et elle en nomme quatre. Une infrastructure pour des charges plus irrégulières. L’authentification et l’autorisation, pour que les agents puissent être identifiés, travailler ensemble, faire les actions qu’ils doivent faire et être tenus à l’écart de celles qu’ils ne doivent pas faire. La sécurité et l’isolation pour du code et du contenu non fiables. Et la supervision, avec la possibilité d’arrêter un système « quand il dérive vers le mauvais territoire ».

Les modèles vont continuer à s’améliorer, dit-elle, et ces systèmes vont devenir vraiment puissants. Que le monde fasse confiance à cette puissance pour guérir des maladies plutôt que pour causer du tort, cela repose sur les ingénieurs qui construisent la plomberie.

Schéma : Comment les agents en sont arrivés là, en quatre étapes, puis les quatre problèmes qu’elle nomme. Un : un chat, avec un humain dans la boucle et une question à la fois. Deux : des exécutions plus longues sur des problèmes plus durs, donc l’agent part dans le cloud. Trois : des orchestrateurs qui lancent des sous-agents pour une tâche, et des agents chargés d’autre chose, noter, conseiller ou rêver. Quatre : des milliers d’agents persistants qui travaillent sur de la recherche sérieuse, de la découverte et de la conception matérielle. Sous les étapes, les quatre problèmes : infrastructure, identité et accès, sécurité et isolation, supervision et arrêt. À voir sur la page.

Les agents ne rentrent pas dans Kubernetes

L’industrie du logiciel construit depuis des années sur Kubernetes, conçu pour des applications sans état et répliquées, ou pour des ensembles stables et numérotés de pods avec état. Les agents sont « des charges de travail isolées, avec état, à instance unique ». Ils restent inactifs pendant des durées arbitraires entre deux bouts de travail. Ils passent l’essentiel de leur vie à attendre : des outils, l’inférence du modèle, d’autres agents, un humain.

Chacune de ces formes attend quelque chose de différent de la machine en dessous. Certaines charges ont besoin d’un démarrage rapide. Certaines doivent arrêter de brûler du calcul pendant qu’elles attendent. Certaines ont besoin d’une échelle démesurée. Elle pointe les entreprises d’infrastructure IA qui construisent de nouveaux systèmes de fichiers et des offres de sandboxing, et l’équipe de Google qui construit Agent Substrate comme nouveau runtime, et dit qu’il reste énormément à inventer.

Ma flotte est une petite version du problème de l’inactivité. Dix-sept agents OpenClaw vivent sur un seul Mac mini, chacun derrière son propre bot Telegram, et la plupart ne font rien tant qu’un message n’arrive pas. Forge, mon agent de contribution open source, est l’autre forme : un worker démarre pour une issue, clone un dépôt, lance ses tests et disparaît. Aucun des deux ne ressemble à un replica set.

Schéma : Ce pour quoi Kubernetes a été conçu, face à ce qu’est un agent. À gauche, des réplicas : six carrés identiques, sans état, répliqués et interchangeables, ou un ensemble stable et numéroté de pods avec état, toujours allumés. À droite, une instance : un seul agent, isolé, avec état, à instance unique, inactif pendant des durées arbitraires, en attente d’outils, du modèle, d’autres agents ou d’un humain. En dessous, la journée schématique d’un agent : de courtes rafales de travail séparées par de longues attentes, marquées attente d’un humain, du modèle, d’un outil. Elle cite ceux qui poussent sur ce sujet : les entreprises d’infrastructure IA qui construisent de nouveaux systèmes de fichiers et des offres de sandboxing, et le runtime Agent Substrate de Google. À voir sur la page.

Qui a fait ça, vous ou votre agent

L’authentification, identifier l’agent qui a fait une action, est la moitié facile. Le monde des microservices a déjà construit et durci les pièces : l’identité de charge de travail (workload identity), des certificats à courte durée de vie plutôt que des clés statiques. On commence à les appliquer aux agents.

L’autorisation est « bien plus ouverte ». La plupart des agents aujourd’hui travaillent au nom d’un humain et utilisent l’identité et les identifiants de cet humain pour atteindre des systèmes et agir. Le premier problème se cache dans cette phrase : côté système receveur, rien ne dit si c’est l’humain ou l’agent qui a agi. Le plus profond, c’est le consentement. Si un système multi-agents travaille pendant des semaines, comment l’humain approuve-t-il réellement ce que son agent peut faire ? L’approbation automatique des appels d’outils aide, dit-elle, mais à l’échelle, les permissions doivent aller plus loin que ça.

Puis la partie encore moins résolue : des agents avec leur propre identité, et des agents qui travaillent ensemble. Comment un agent fait-il confiance à un autre agent qui lui a demandé quelque chose ?

Je connais le premier problème du côté receveur. Chaque pull request qu’ouvrent mes agents a pour auteur moi, pour autant que GitHub le sache. Dans mes propres dépôts, la seule trace qu’une session a fait le travail est un identifiant de session dans un commentaire HTML du corps de la PR. Et ma première tentative pour délimiter ce qu’un agent a le droit de faire m’a appris à quel point cette couche est mince : une règle d’interdiction dans la configuration de ma passerelle n’a rien bloqué pendant un mois, et un agent censé être tenu à l’écart de mon application de finances s’est vu proposer ses 13 outils. Je l’ai raconté dans la note sur les collègues IA dans Slack, où MintMCP donne à chaque agent une identité à lui.

Schéma : Le problème de l’agent qui agit au nom de quelqu’un. Une chaîne de trois boîtes : l’humain, moi, puis l’agent qui agit en mon nom, puis le système, GitHub, une base de données ou une API. Mon jeton voyage le long des deux liens, donc le journal d’audit du système enregistre comme auteur moi, et rien ne dit si c’était moi ou l’agent. Sous la chaîne, les quatre questions ouvertes qu’elle liste. Un, qui : l’action atterrit sous l’identité de l’humain. Deux, le consentement : un système qui travaille pendant des semaines, et comment l’humain approuve réellement ce qu’il peut faire. Trois, l’identité : des agents avec une identité à eux, encore moins résolu. Quatre, la confiance : comment un agent fait confiance à un autre agent qui lui a demandé quelque chose. L’authentification, elle, peut emprunter aux microservices l’identité de charge de travail et les certificats à courte durée de vie. À voir sur la page.

Un agent compromis, c’est un rayon d’explosion

Ces derniers mois, écrit-elle, et surtout ces dernières semaines, des vulnérabilités sont apparues plus vite que l’industrie ne peut les corriger, beaucoup dans des logiciels de base dont dépendent de nombreux systèmes. Posez des milliers d’agents persistants sur ces logiciels, à écrire du code non fiable et à lire du contenu non fiable, et chaque vulnérabilité non corrigée devient plus dangereuse. Ce qu’elle demande aux ingénieurs, c’est de faire preuve d’imagination pour durcir les noyaux, navigateurs, runtimes et bibliothèques communes sur lesquels ces agents tournent.

Les systèmes multi-agents ajoutent une subtilité. Un agent compromis peut transmettre des instructions injectées aux agents avec lesquels il travaille, et ces instructions peuvent finir en mémoire, où de futurs agents leur font confiance par accident. La question devient donc le rayon d’explosion (blast radius) : quand le premier agent tombe, quelle part du système est en danger ? Sa réponse est l’isolation. Les agents devraient agir depuis des environnements d’exécution fortement isolés, en sandbox.

Elle a écrit la version longue en septembre, dans Secure agents: architecture and sandboxing, et c’est la page la plus pratique que j’aie lue sur le sujet. Séparer le cerveau des mains. Le harnais, l’état de la session et les identifiants vivent hors de la sandbox, sur une infrastructure de confiance, et la sandbox n’est qu’un outil que l’agent utilise pour exécuter du code. Quand du code dans la sandbox a besoin d’un service externe, la requête sort par un proxy de sortie qui ajoute l’identifiant au passage, limité à cette seule destination. La sandbox peut contenir un substitut que le proxy échange contre la vraie clé. Sa phrase sur l’alternative, tout dans une seule boîte : « Votre coupe-circuit est en gros à l’intérieur de la chose que vous essayez d’arrêter. »

La sandbox elle-même demande ensuite quatre réglages. L’isolation, du plus faible au plus fort : les conteneurs, qui partagent le noyau de l’hôte et ne devraient pas servir de frontière de sécurité pour du code non fiable ; un noyau en espace utilisateur comme gVisor ; des microVM comme Firecracker, chacune avec son propre noyau derrière le matériel de virtualisation du processeur, son choix pour la plupart des équipes ; et des VM complètes ou des hôtes dédiés pour le travail réglementé. Les sandboxes devraient être éphémères, « du bétail plutôt que des animaux de compagnie », avec des limites strictes de temps et de ressources. La sortie réseau devrait tout refuser par défaut derrière un proxy, avec une liste blanche d’hôtes et de méthodes HTTP, et le DNS fermé ; installer les dépendances au début de la session, puis verrouiller le réseau avant que l’agent commence à travailler. Et les journaux des appels d’outils, des commandes et des accès réseau partent quelque part où la sandbox ne peut pas atteindre, à côté d’un coupe-circuit qui fonctionne en pleine session.

C’est proche de ce que j’ai construit pour les workers de Forge dans ma sandbox dans la sandbox : la clé à l’intérieur de la sandbox est un substitut que le proxy d’OpenShell échange à la sortie, et les workers ont une seconde clôture avec une seule porte, un relais avec une liste blanche d’hôtes.

Schéma : Le rayon d’explosion, en deux cartes. À gauche, des agents qui partagent un environnement : une grille de neuf agents, l’un d’eux compromis, et les instructions injectées se propagent aux agents avec lesquels il travaille et dans la mémoire partagée, où les agents suivants leur font confiance, jusqu’à ce que toute la grille soit rouge. À droite, les mêmes neuf agents, chacun dans sa propre sandbox, avec les clés gardées dehors : le compromis reste rouge tout seul, et les autres restent bleus. Sous les cartes, ses quatre niveaux d’isolation du plus faible au plus fort : les conteneurs, qui partagent le noyau de l’hôte et ne sont pas une frontière pour du code non fiable ; un noyau en espace utilisateur comme gVisor ; des microVM comme Firecracker, chacune avec son propre noyau, son choix pour la plupart des équipes ; et des VM complètes ou des hôtes dédiés pour le travail réglementé. Sa règle : séparer le cerveau des mains, avec le harnais, l’état et les identifiants hors de la sandbox. À voir sur la page.

Un coupe-circuit hors de la chose qu’il arrête

Le dernier ensemble est celui qu’elle qualifie de difficile. Il faut savoir que ces systèmes vont dans une direction positive, et pouvoir les attraper et les couper quand ce n’est pas le cas. Concrètement : du traçage OpenTelemetry à travers les agents, avec la garantie qu’un agent ne peut jamais modifier sa propre trace ni celle d’un autre. Et des coupe-circuits que la supervision peut déclencher, qui arrêtent vraiment tout le système d’un coup et lui coupent ses identifiants.

Le plus dur n’est pas l’interrupteur. C’est de savoir quand l’actionner. « Une persévérance bien intentionnée pour résoudre un problème peut beaucoup ressembler à de la malveillance. » Son exemple : des tentatives répétées d’atteindre un domaine qui n’est pas sur la liste blanche.

J’ai vu cette ambiguïté des deux côtés. Les workers de Forge exécutent les scripts d’installation et les suites de tests d’inconnus derrière un relais qui n’autorise qu’une courte liste d’hôtes. Si un test va chercher une fixture sur un hôte que je n’ai jamais listé, le relais le refuse, et refuse la nouvelle tentative. Vu de l’extérieur, ce worker et une tentative d’exfiltration écrivent la même ligne de journal. L’autre côté : quand j’ai arrêté d’utiliser Hermes cet été, mon coupe-circuit a été de révoquer ses jetons Telegram. Le 14 septembre, ses deux passerelles tournaient en boucle de plantage, en réessayant des jetons qui ne marchaient plus. De la persévérance, pas de la malveillance, et rien dans les journaux seuls ne permettait de le dire.

Schéma : Supervision et arrêt, en trois parties. Un : une trace à travers trois agents, leurs spans sur une même ligne de temps, avec un verrou dessus, parce qu’aucun agent ne peut modifier sa propre trace ni celle d’un autre. Deux : un coupe-circuit qui arrête les trois agents d’un coup et coupe leurs identifiants, dessiné comme un bouton stop, trois agents qui s’éteignent et une clé barrée. Trois : le cas ambigu, cinq tentatives répétées d’atteindre un domaine absent de la liste blanche, chacune refusée, avec deux lectures en dessous : un test qui va chercher une fixture, ou une exfiltration. Ses mots : une persévérance bien intentionnée pour résoudre un problème peut beaucoup ressembler à de la malveillance. À voir sur la page.

Où en est ma flotte sur les quatre

Elle termine l’article pour les ingénieurs qui pensent que leurs compétences ne compteront plus : ces problèmes sont grands ouverts, et « vous et vos compétences pouvez faire la différence ». Alors, honnêtement, la mienne.

Infrastructure : un Mac mini, 17 agents, inactifs presque toute la journée. Pas d’ordonnanceur, pas de démarrage rapide, rien à mettre à l’échelle. Ça marche parce que la flotte est petite.

Identité : tout tourne en mon nom. Les agents utilisent mes comptes, et leurs pull requests sont les miennes sur GitHub. Deux d’entre eux, Nova et Spark, ont leurs propres comptes Slack dans un espace de travail réservé aux agents, ce qui est le premier morceau d’une identité. La confiance d’agent à agent ne s’est pas encore posée : Telegram ne livre pas les messages d’un bot à un autre, donc mes agents ne peuvent pas se parler là.

Isolation : partielle. Les workers de Forge tournent dans srt, un runtime de sandbox sur Seatbelt de macOS, et sur le Dell ils tourneront dans une cage Landlock à l’intérieur d’OpenShell, avec les clés dehors. Tous les autres agents exécutent leurs outils sur l’hôte, ce qui est le réglage par défaut d’OpenClaw et la ligne vide de ma note sur les cinq pièces de NVIDIA.

Supervision et arrêt : la ligne la plus faible. Meterlex chiffre chaque session, mais c’est un compteur, pas une trace, et rien ne relie les actions d’un agent à celles d’un autre. Il n’y a pas de coupe-circuit. Arrêter un agent, c’est arrêter sa passerelle ou révoquer un jeton, à la main. Forge a un budget de 5 $ par jour, et son profil Hermes sur le Dell a un hook qui voit chaque appel d’outil avant qu’il s’exécute. C’est ce que j’ai de plus proche d’un interrupteur.

Schéma : Ma flotte confrontée à ses quatre problèmes, au 26 octobre. Infrastructure : un Mac mini, 17 agents, inactifs presque toute la journée, pas d’ordonnanceur ; ça marche parce que la flotte est petite. Identité : tout tourne en mon nom, et les pull requests sont les miennes sur GitHub ; deux agents, Nova et Spark, ont leurs propres comptes Slack. Isolation : partielle ; les workers de Forge tournent dans srt aujourd’hui et dans une cage Landlock à l’intérieur d’OpenShell sur le Dell ensuite, avec les clés dehors, tandis que tous les autres agents exécutent leurs outils sur l’hôte. Supervision et arrêt : pas encore ; Meterlex est un compteur, pas une trace, et il n’y a pas de coupe-circuit, seulement une passerelle arrêtée ou un jeton révoqué à la main, plus le budget quotidien de Forge et un hook sur les appels d’outils. À voir sur la page.

Comment l’équipe Claude Code relit le code qu’écrit Claude

2026-10-26T00:00:00Z

Claude écrit environ 90 % de Claude Code, et l’équipe relit toujours chaque changement. Ce qui a changé, c’est qui fait la lecture. Claude vérifie son propre travail avant même qu’une pull request existe, un panel d’agents relit chaque PR, et l’approbation d’une personne n’est exigée que là où se trouve le risque. De juin à septembre, le nombre de pull requests mergées a plus que doublé, tandis que la part qu’il a fallu annuler baissait de plus de 40 %.

C’est tiré de How the Claude Code team does code review, publié sur le blog claude.dev le 15 octobre par Addy Osmani, Morgan Westlee Lunt et Qing Wang. Addy l’a republié sous forme d’article X le 26 octobre. Plus tôt ce mois-ci, j’ai résumé une autre réponse au même problème, celle d’Overmind : relisez le plan, pas la pull request. L’équipe Claude Code a gardé la revue après le code. Elle a simplement cessé d’en faire une seule barrière.

Lire chaque ligne a cessé d’être le critère

Quand des agents écrivent le code, le nombre de changements explose. Dans le monorepo d’Anthropic, les changements intégrés par jour sont passés d’environ 2 500 en mai à plus de 30 000 en septembre. Claude Code vit dans son propre dépôt, mais subit la même pression. Personne ne lit ça ligne par ligne.

Alors l’équipe est revenue à ce à quoi sert la revue. Elle remplit deux rôles : trouver et corriger les problèmes avant la mise en production, et répandre la compréhension du code dans l’équipe. L’essentiel de l’article porte sur le premier.

Leur phrase clé, c’est que « un humain a-t-il lu le code ? » est un indicateur imprécis. La vraie question, c’est ce qui pourrait mal tourner avec ce changement, et quel contrôle, automatique ou humain, est le bon pour l’attraper.

Ça a aussi déplacé la revue dans le temps. Avant, c’était une barrière en bout de chaîne : écrire le code, ouvrir une PR, attendre un collègue. Maintenant, ça fonctionne plutôt comme un correcteur orthographique pendant qu’on écrit. La plupart des changements ont été relus et corrigés par Claude au moins une fois avant qu’on demande à une personne d’y jeter un œil.

L’objectif est concret. La plupart des PR des dépôts Claude Code (la CLI, les applications desktop et web, les applications mobiles) doivent être mergées avec au plus une personne dans la boucle, et cette personne peut être l’auteur. L’équipe suit le nombre d’approbations humaines par PR, en médiane et au 95e centile, les commentaires humains, et le temps qu’une PR passe à attendre une personne. Les reverts et les incidents servent de garde-fou, parce que le temps humain a deux faces : le temps passé à relire, et le temps passé à réparer ce que le mauvais code casse. Si les reverts augmentent, on n’a pas gagné de temps, on l’a seulement déplacé.

Schéma : Où se place la revue, avant et maintenant. Avant, la revue était une barrière en bout de chaîne : une personne écrit le code, ouvre une pull request, attend un collègue, et le collègue la lit. Cela répond à une question : un humain a-t-il lu le code ? Maintenant, elle fonctionne comme un correcteur orthographique pendant qu’on écrit : Claude vérifie et corrige le changement au moins une fois, des agents relisent la pull request, et une personne regarde là où se trouve le risque. Cela répond à une autre question : qu’est-ce qui pourrait mal tourner, et quel contrôle l’attrape ? L’équipe suit les approbations humaines par pull request en médiane et au 95e centile, les commentaires humains, et le temps qu’une pull request attend une personne, avec les taux de revert et d’incident comme garde-fou. L’objectif : que la plupart des pull requests soient mergées avec au plus une personne dans la boucle, qui peut être l’auteur. À voir sur la page.

Six couches, puis le retour arrière

Un changement typique, parti d’un portable ou d’une session Claude dans Slack, traverse six couches de contrôles : la vérification avant la PR, la CI obligatoire, la revue par IA, une revue de sécurité, une approbation humaine proportionnée au risque, et une merge queue avec des feature flags. Sous toutes ces couches, il y a le retour arrière rapide.

Chaque couche attrape certains problèmes et en rate d’autres. Peu passent les six, et le retour arrière s’occupe du reste. La majeure partie du chemin est automatisée, et l’attention d’une personne va là où est le risque.

Schéma : Six couches de contrôles avec le retour arrière en dessous, dessinées comme des tranches trouées. Six problèmes arrivent en haut, un par colonne. La vérification avant la pull request arrête le premier. La CI obligatoire, c’est-à-dire le lint, les types, les tests et le build, arrête le deuxième. La revue IA, où des agents cherchent et votent, arrête le troisième. La revue de sécurité, à part, arrête le quatrième. L’approbation humaine, avec zéro, une ou deux personnes selon le risque, arrête le cinquième. Le sixième problème passe par tous les trous, au-delà de la merge queue et des feature flags, et c’est le retour arrière rapide qui l’attrape : flags coupés, changement annulé. Cinq des couches sont automatisées, une est une personne, et le retour arrière sert de rattrapage. Quelle couche arrête quel problème relève du schéma : l’article ne donne aucun chiffre par couche. À voir sur la page.

Avant la PR, montrer le résultat

L’essentiel de la revue se fait désormais avant qu’une pull request existe. Claude reçoit quelque chose qu’il peut exécuter, comme des tests, un build ou une capture d’écran à comparer à la maquette, et doit montrer le résultat au lieu de dire que c’est fini. Ensuite, un sous-agent relit le diff avec un contexte neuf. Beaucoup de membres de l’équipe lancent aussi des skills internes avant d’ouvrir une PR : un qui chasse les bugs, un qui simplifie le diff, un qui vérifie le comportement de bout en bout.

Boris Cherny, le créateur de Claude Code, considère que donner à Claude un moyen de vérifier son travail est sans doute ce qui compte le plus pour obtenir de bons résultats. Selon lui, cela rend le résultat final deux à trois fois meilleur.

Quand le relecteur signale sans cesse la même chose, l’équipe corrige à la source : dans le skill, avec une règle de lint, ou dans deux fichiers d’instructions. CLAUDE.md dit ce qu’est le projet : la stack, les conventions, les objectifs et les non-objectifs. Chaque revue le charge, alors il reste court et renvoie vers d’autres docs. Le relecteur signale aussi le code qui enfreint une de ses conventions, et les changements qui rendent une de ses lignes obsolète.

REVIEW.md est écrit par les code owners, pour dire au relecteur ce qui compte dans leur partie du code, et l’équipe vérifie à part si le relecteur le suit. Les bons sont courts. Ils disent à quoi ressemble un échec dans ce dépôt (pour la doc, c’est « elle ment », pour la config, « elle route mal »), plafonnent les nits, listent les chemins à ignorer, et exigent un fichier et une ligne comme preuve au lieu d’une supposition tirée d’un nom. Ils demandent aussi un résumé qui commence par un décompte et dit clairement quand il n’y a rien à corriger.

Schéma : La revue avant la pull request, en trois étapes. Un : exécuter, c’est-à-dire des tests, un build, ou une capture d’écran comparée à la maquette. Deux : montrer la sortie, au lieu d’affirmer que c’est fini. Trois : un regard neuf, un sous-agent relit le diff avec un contexte vierge. L’estimation de Boris Cherny : un moyen de vérifier son travail rend le résultat deux à trois fois meilleur. Puis les deux fichiers qui corrigent à la source les remarques répétées. CLAUDE.md, chargé par chaque revue : la stack et les conventions, les objectifs et les non-objectifs, en restant court et en renvoyant vers d’autres docs ; le relecteur signale le code qui enfreint une convention et les changements qui rendent une ligne obsolète. REVIEW.md, écrit par les code owners : à quoi ressemble un échec ici, par exemple une doc qui ment ou une config qui route mal, un plafond de nits, les chemins à ignorer, un fichier et une ligne comme preuve au lieu d’une supposition tirée d’un nom, et un résumé qui commence par un décompte et dit clairement quand il n’y a rien à corriger. L’équipe vérifie à part si le relecteur le suit. À voir sur la page.

Le relecteur vote avant de commenter

Chaque pull request reçoit une revue de Claude avant qu’une personne la regarde. Elle lit le diff au regard de tout le dépôt et de l’intention annoncée de la PR, et se demande si le changement résout son problème, s’intègre au système, ou casse autre chose. Sur un correctif de bug, elle cherche la cause racine.

Les remarques sont vérifiées avant que quiconque les voie. Plusieurs agents cherchent des bugs en même temps. Un groupe distinct vote sur chaque remarque, et elle n’est publiée que si assez d’entre eux s’accordent à dire qu’elle est réelle. Les remarques qui ne portent que sur le style, les diagnostics ou le nettoyage sont écartées ; l’équipe a d’abord testé ces filtres en A/B sur ses propres PR. Ce qui reste arrive en commentaires en ligne, triés par gravité, chacun étiqueté Important, Nit ou Pre-existing, pour qu’un vieux bug n’ait pas l’air d’être la faute de l’auteur.

Au lancement de la research preview, la part des PR internes recevant des commentaires de revue substantiels est passée de 16 % à 54 %. La plupart des PR de plus de 1 000 lignes reçoivent des remarques, et la plupart des petites reviennent sans rien. Les admins règlent chaque dépôt sur Quick, Standard ou Deep.

Chaque remarque doit recevoir une réponse : la corriger, ou résoudre le fil avec une raison. Une revue de sécurité distincte fonctionne de la même façon, et une remarque ouverte de l’une ou de l’autre bloque le merge. La CI bloque aussi, avec des dizaines de contrôles sur une pull request typique de la CLI. Le modèle de PR demande comment le changement a été testé et comment l’annuler. Claude peut le remplir, mais c’est la personne qui a demandé le changement qui le valide.

Schéma : Comment le relecteur IA filtre ses propres remarques, en quatre étapes. Un, chercher : plusieurs agents cherchent des bugs en même temps, dessinés comme neuf remarques candidates. Deux, voter : un groupe distinct vote sur chaque remarque, et seules celles sur lesquelles assez de votants s’accordent survivent, dessinées comme cinq. Trois, filtrer : les remarques qui ne portent que sur le style, les diagnostics ou le nettoyage sont écartées, dessinées comme trois. Quatre, publier : ce qui reste arrive sur la pull request en commentaires en ligne triés par gravité, étiquetés Important, Nit ou Pre-existing. Au lancement de la research preview, les pull requests internes avec des commentaires de revue substantiels sont passées de 16 % à 54 %. Chaque remarque est corrigée ou résolue avec une raison, et une remarque ouverte de la revue de code ou de la revue de sécurité bloque le merge. À voir sur la page.

C’est le changement qui fixe le niveau, pas l’auteur

Une correction de doc et un changement de l’auto-updater ne portent pas le même risque, alors ils n’ont pas droit à la même revue. L’article décrit trois niveaux :

Faible : docs, textes, fonctionnalités internes, ajouts derrière un flag. Aucune approbation humaine une fois la revue automatique et les contrôles de sécurité au vert.
Moyen : les changements produit ordinaires, et les zones sensibles comme le cache, l’auto-updater ou les prompts système. Une personne.
Élevé : le code le plus risqué, plus un petit ensemble de chemins qui en exigent toujours deux. Deux personnes.

Un classifieur lit le changement et choisit le niveau. Un second classifieur se demande si ce changement précis a besoin d’une personne même quand son niveau dit le contraire. Les chemins que les owners déclarent sensibles, et tout fichier de workflow CI, exigent toujours une personne.

Ce sont les règles autour du tableau qui le font tenir. Seuls les auteurs inscrits sur la liste de confiance du dépôt ont droit aux chemins allégés ; tous les autres ont besoin d’une deuxième personne. L’approbation d’un agent ne compte jamais comme celle d’une personne. La personne qui a lancé une PR écrite par un agent compte parmi ses relecteurs requis, comme si elle avait tapé le code. Et une approbation couvre un seul commit : un push d’agent, ou un merge résolu à la main, en exige une nouvelle.

Schéma : L’approbation humaine proportionnée au risque, d’après le tableau de l’article. Risque faible : les docs, les textes, les fonctionnalités internes et les ajouts derrière un flag n’ont besoin d’aucune personne une fois la revue automatique et les contrôles de sécurité au vert. Risque moyen : les changements produit ordinaires et les zones sensibles comme le cache, l’auto-updater ou les prompts système demandent une personne. Risque élevé : le code le plus risqué et un petit ensemble de chemins demandent deux personnes. Un classifieur lit le changement et fixe le niveau, et un second se demande si ce changement a quand même besoin d’une personne. Les chemins que les owners déclarent sensibles, et tout fichier de workflow CI, exigent toujours une personne. L’approbation d’un agent ne remplace jamais celle d’une personne. Une approbation couvre un commit : un push d’agent ou un merge résolu à la main en exige une nouvelle. Sur une pull request écrite par un agent, la personne qui l’a lancée compte parmi les relecteurs requis. À voir sur la page.

Les incidents servent de jeu de test

L’équipe a construit le jeu de test du relecteur à partir de vraies pannes. Elle a rassemblé d’anciennes PR qui avaient causé des incidents, avec leurs correctifs et leurs reverts, et fait confirmer chaque bug et son emplacement par des ingénieurs qui connaissent ce code. Le relecteur tourne contre ce jeu tous les jours. Chaque nouvel incident ajoute un cas, et chaque changement des prompts, des outils ou du modèle du relecteur est noté sur l’ensemble.

Attraper plus de bugs est facile si l’on accepte de signaler des non-bugs, alors l’équipe mesure aussi le bruit. Chaque commentaire est classé selon ce qu’en a fait la personne sur la PR : elle l’a corrigé, a dit qu’il était faux, a dit que le comportement était voulu, ou a jugé que ça n’avait pas d’importance. L’équipe fait aussi tourner le relecteur sur des PR connues pour être saines, et compte les signalements qui auraient poussé quelqu’un à faire un changement nuisible. La priorité est écrite noir sur blanc : les vrais bugs d’abord, moins de tours de revue ensuite.

Schéma : L’éval du relecteur, construite à partir des incidents, en deux rangées reliées. Le jeu grandit : un incident ou un revert, un changement qui a cassé quelque chose, est vérifié par des ingénieurs qui connaissent le code, qui confirment le bug et son emplacement, puis il est ajouté au jeu, un cas par incident. Le relecteur change : quelqu’un modifie ses prompts, ses outils ou son modèle, l’éval quotidienne le note sur chaque cas du jeu, et si le score monte, le changement est gardé ; sinon, il est jeté. Le bruit se mesure à ce que les gens ont fait de chaque commentaire de revue : corrigé, jugé faux, déclaré voulu, ou jugé sans importance. La priorité écrite : les vrais bugs d’abord, moins de tours de revue ensuite. À voir sur la page.

La revue doit converger

Le bruit coûte plus cher quand l’auteur est un agent. Une personne balaie un nit en quelques secondes. Un agent le corrige, ce qui veut dire un commit de plus et un tour de revue de plus. Un agent auteur et un agent relecteur peuvent s’occuper l’un l’autre indéfiniment : une pull request de la CLI a enchaîné plus de cinquante tours pendant une nuit avant que son auteur l’arrête.

Quand l’équipe a lancé git blame sur ce que le relecteur signalait sans arrêt, environ 59 % concernaient du code présent depuis le premier passage du relecteur. Il ne trouvait pas de nouveaux bugs. Il trouvait quelques vieux bugs de plus à chaque tour. L’équipe avait elle-même aggravé les choses, en lançant plusieurs tours par défaut parce que chaque passage attrape quelque chose de nouveau.

Alors elle a changé la re-revue :

Un plafond de tours. Après trois tours, le relecteur demande à l’auteur de prendre du recul et de reconsidérer l’approche.
Une re-revue limitée au diff après les premiers passages.
Signaler la classe de bug, pour que l’auteur corrige chaque occurrence, pas une seule ligne.
Pas de répétition des remarques déjà publiées.

Les vieux bugs sont toujours chassés, simplement pas sur votre PR : des agents de revue tournent aussi chaque nuit sur le code existant. Après le changement, les PR validées après un seul tour de revue et de correction sont passées de 65 % à 78 %, les PR nécessitant cinq tours ou plus sont tombées de 8,9 % à 1,5 %, et le nombre moyen de revues avant validation est tombé de 2,08 à 1,32.

Schéma : Une revue qui converge. Les quatre changements de la re-revue : un, un plafond de tours, pour qu’après trois tours le relecteur demande à l’auteur de prendre du recul et de repenser l’approche ; deux, le diff seul, pour qu’après les premiers passages seul le nouveau diff soit relu ; trois, la classe de bug, pour que l’auteur corrige chaque occurrence et pas une seule ligne ; quatre, pas de répétition d’une remarque déjà publiée. Les résultats sur les pull requests internes, avant et après ce travail : la validation après un seul tour de revue et de correction est passée de 65 à 78 % ; le besoin de cinq tours ou plus est tombé de 8,9 à 1,5 % ; le nombre moyen de revues avant validation est tombé de 2,08 à 1,32. Avant le changement, une pull request de la CLI a enchaîné plus de cinquante tours pendant une nuit avant que son auteur l’arrête. À voir sur la page.

Les humains gardent cinq tâches

Sortir un ingénieur senior d’un travail de fond pour attraper une erreur de routine coûte bien plus cher qu’une revue automatique. Alors les humains gardent les tâches que seuls des humains peuvent faire :

Décider s’il faut le construire : la direction, le goût et le périmètre. Une équipe qui a déclaré son goulot de revue résolu garde quand même une revue humaine pour les changements venus d’en dehors de l’équipe, pour que quelqu’un se demande si le changement doit exister.
Relire le code risqué, comme la facturation, l’auto-updater et les workflows CI.
Relire l’architecture qui pose un modèle que d’autres copieront.
Lire les preuves : la sortie des tests, la commande lancée et ce qu’elle a renvoyé, une capture d’écran, les remarques du relecteur.
Répondre du résultat. Une personne est responsable de chaque changement mis en production, peu importe qui l’a tapé.

La tâche des preuves s’accompagne d’une règle à voler : « Si vous ne savez pas dire ce que les contrôles rateraient, demandez une vraie revue plutôt qu’une approbation rapide. »

Schéma : Les cinq tâches que gardent les humains. Un : décider s’il faut le construire, c’est-à-dire la direction, le goût et le périmètre. Deux : le code risqué, comme la facturation, l’auto-updater et les workflows CI. Trois : l’architecture, les choix qui posent un modèle que d’autres copient. Quatre : les preuves, c’est-à-dire la sortie des tests, la commande et ce qu’elle a renvoyé, une capture d’écran et les remarques du relecteur. Cinq : le résultat, parce qu’une personne répond de chaque changement mis en production, peu importe qui l’a tapé. La règle qui accompagne les preuves : si vous ne savez pas dire ce que les contrôles rateraient, demandez une vraie revue plutôt qu’une approbation rapide. À voir sur la page.

Qui le merge en répond

Le deuxième rôle de la revue était de diffuser le contexte. Lire le diff d’un collègue, c’est comme ça qu’on apprend le code. L’équipe n’a pas de remplacement formel, et dit que personne ne garde en tête un modèle complet de Claude Code, ni n’en a besoin. Quand on a besoin d’une partie du code, on demande à Claude une explication de cette tranche précise. Ça prend quelques minutes et ça correspond au code tel qu’il est aujourd’hui. Un changement de texte d’une ligne n’apprend presque rien. Une explication du module qu’on s’apprête à modifier en apprend beaucoup.

La responsabilité fonctionne de la même façon. Si vous mergez un changement petit ou moyen et qu’il casse, c’est généralement vous qui le réparez. Ça ne tourne pas mal parce que les changements sont petits, que les flags, les reverts et les déploiements progressifs annulent la plupart des erreurs en quelques minutes, que le rayon d’impact fixe la barre, que les régressions apparaissent vite dans la télémétrie et l’usage interne, et que les revues d’incident examinent le système, pas la personne.

Un code bon marché rend aussi bon marché le changement de cap. Quand quelqu’un dans le canal pointe une décision antérieure ou une voie plus simple, l’auteur ferme ou remanie la PR, et ce n’est pas vécu comme une perte. L’astuce, c’est de le soulever tôt dans le fil, pas en commentaire bloquant sur une PR terminée.

Schéma : Comment l’équipe apprend le code une fois que les machines font l’essentiel de la lecture. Avant : lire les diffs, mais un changement de texte d’une ligne n’apprend presque rien. Maintenant : demander à Claude une explication de la tranche exacte qu’on va modifier ; ça prend quelques minutes et ça correspond au code tel qu’il est aujourd’hui. Pourquoi répondre de ses propres merges fonctionne : les changements sont petits, tout est réversible, le rayon d’impact fixe la barre, les régressions remontent vite, et personne n’est blâmé. Changer de cap : le soulever tôt dans le fil, pas en commentaire bloquant sur une pull request terminée. À voir sur la page.

À côté de ma propre boucle

Ma boucle est décrite sur Comment je travaille avec l’IA : d’abord une issue, un agent construit sur sa propre branche, il prouve que le changement fonctionne, un modèle d’un autre fournisseur donne un second avis, et une pull request ferme le tout. Deux de mes règles là-bas disent la même chose que cet article. « Vérifier ce que le modèle a produit, pas ce qu’il dit avoir fait », c’est leur « montrer le résultat au lieu de dire que c’est fini ». « Une relecture vide n’est pas une validation », c’est leur REVIEW.md qui demande un résumé disant clairement quand il n’y a rien à corriger.

Mon pipeline Forge plafonne déjà les tours plus durement qu’eux. Un problème bloquant signalé par son relecteur a droit à une correction de plus, puis la pull request s’ouvre. C’est dans la note sur OpenShell.

La différence, c’est la dernière étape. Sur cette page, chaque changement finit en pull request que je lis et que je merge, et dans ma note sur l’usine logicielle, la partie lente de mon installation, c’est ma file de revue. Leur tableau des niveaux vise exactement ça : une correction de doc n’a besoin de personne une fois les contrôles au vert, et le temps d’une personne va à la facturation, à la CI et à l’auto-updater.

Schéma : Le fonctionnement de l’équipe Claude Code à côté de ma boucle telle qu’elle est écrite sur ma page Comment je travaille avec l’IA, une ligne par sujet. La preuve d’abord : ils font montrer la sortie à Claude, des tests, un build ou une capture ; je demande le build et les tests, et des captures dans un vrai navigateur à 320 pixels et sur desktop. La revue IA : leurs agents Claude cherchent, votent, puis publient par gravité ; dans ma boucle, un modèle d’un autre fournisseur relit le changement. Quand rien n’est trouvé : leur résumé le dit clairement, avec un décompte ; ma règle, c’est qu’une relecture vide n’est pas une validation. Les tours : ils en autorisent trois, puis l’auteur repense l’approche ; mon pipeline Forge accorde une correction de plus à un problème bloquant. Qui approuve : chez eux, le changement fixe le niveau, zéro, une ou deux personnes ; dans ma boucle, c’est chaque pull request, moi. Cette dernière ligne, c’est là que ma file de revue s’accumule, et le tableau des niveaux est la pièce qui la vise. À voir sur la page.

Essayez

L’article se termine par une checklist, et l’essentiel marche avec des outils que vous avez déjà :

Avant la PR : donnez à votre agent des contrôles qu’il peut exécuter, listés dans un CLAUDE.md court, plus des hooks pour les formateurs et les linters. Lancez /code-review et /security-review en local, ou un sous-agent à contexte neuf. Commencez un REVIEW.md et déplacez-y les commentaires qui reviennent.
Sur chaque PR : exigez la CI, ajoutez des sections Tests, Risques et Comment annuler au modèle de PR, mettez un relecteur IA sur un seul dépôt et ajustez REVIEW.md pendant quelques semaines avant d’élargir, et exigez que chaque fil de revue soit résolu. Plafonnez les tours, et ne relisez que le nouveau diff après les premiers.
Approbation : écrivez des niveaux de risque fixés par le changement, commencez strict et assouplissez avec des preuves. Utilisez CODEOWNERS et la protection de branche pour que l’authentification, la facturation, la CI, les workflows de release et les installeurs exigent toujours une personne. Ne laissez jamais l’approbation d’un bot remplir une place humaine, et invalidez les approbations à chaque nouveau commit.
Après le merge : une merge queue, des feature flags, l’usage interne d’abord, des déploiements progressifs et un retour arrière en une étape. Transformez les incidents et les reverts en jeu d’éval, et mesurez le temps humain avec les reverts comme garde-fou.

Schéma : La checklist d’adoption de l’article, en quatre colonnes. Avant la pull request : des contrôles exécutables dans un CLAUDE.md court, des hooks pour les formateurs et les linters, les commandes code-review et security-review lancées en local, et un REVIEW.md pour les commentaires répétés. Sur chaque pull request : la CI obligatoire, des sections Tests, Risques et Comment annuler dans le modèle, un relecteur IA sur un seul dépôt d’abord, chaque fil résolu, et un plafond de tours avec une re-revue limitée au diff ensuite. Approbation : des niveaux de risque fixés par le changement, stricts d’abord puis assouplis avec des preuves, CODEOWNERS pour l’authentification, la facturation, la CI, la release et les installeurs, et des approbations de bot qui ne comptent jamais et sont invalidées à chaque nouveau commit. Après le merge : une merge queue et des feature flags, les utilisateurs internes d’abord puis des déploiements progressifs, un retour arrière en une étape, et les incidents et les reverts comme éval. En dessous : mesurer le temps humain par changement, avec les reverts et les incidents comme garde-fou. À voir sur la page.

Pour aller plus loin :

How the Claude Code team does code review, l’article, 14 minutes
L’article X d’Addy Osmani, le même article, réécrit
Code Review for Claude Code, la documentation
Claude Code best practices, d’où vient l’habitude de faire vérifier son travail
Relisez le plan, pas la pull request, la réponse d’Overmind au même problème

Choisissez une pièce cette semaine, un REVIEW.md ou un plafond de tours, et dites-moi ce que ça change à votre file de revue.

Chaque écran de cette appli SaaS est une MCP App

2026-10-26T00:00:00Z

Mathew Goldsborough a affiché une appli de tâches à l’écran : une liste de choses à faire, une barre latérale, un panneau de chat calé à droite. On aurait dit n’importe quel tableau de bord SaaS. Puis il a annoncé à la salle que tout ce qu’on voyait était un serveur MCP ou une MCP App, assemblés à l’exécution. Son entreprise, NimbleBrain, construit l’hôte open source qui tient ces pièces ensemble, et son talk portait sur cet hôte : comment une appli trouve sa place à l’écran, affiche un compteur sans appel au modèle, apprend qu’elle vient d’être installée, et finit par ressembler à un seul produit.

C’était le dernier talk de la première journée d’AGNTCon + MCPCon North America, à San José, le 22 octobre. Regardez-le sur le livestream à partir de 7:12:34. Goldsborough est le fondateur et CEO de NimbleBrain, et ambassadeur de l’AAIF, le seul basé à Hawaï, ce qui lui permet d’ouvrir par un aloha. Ma note sur le talk de Liad Yosef couvrait les MCP Apps côté client : un plan de salle qui revient dans votre assistant. Voici l’autre moitié, et je l’ai lue à côté du code et de la doc de NimbleBrain, qui sont publics.

Schéma : Une appli de tâches qui ressemble à un tableau de bord SaaS ordinaire : une barre latérale avec Conversations, Fichiers et Tâches, puis un groupe Applis avec À faire, Contacts et Mémoire ; une liste de tâches dans la zone principale avec un bouton Ajouter une tâche ; un panneau de chat à droite où l’utilisateur demande ce qui vient ensuite sur sa liste. La figure alterne entre ce qu’on voit et ce que c’est. Dans le second état, chaque zone porte une étiquette : la barre latérale, ce sont les vues de l’hôte puis les emplacements des applis ; la zone principale, la ressource ui:// du serveur de tâches dans une iframe dont les boutons sont des appels d’outils ; et le chat, la boucle de l’agent avec les skills chargées via MCP. À voir sur la page.

MCP est devenu un format de paquet

Son cadrage : chaque plateforme a eu son format de paquet, et une couche de composition autour. Les exécutables sur le bureau. Les fichiers WAR pour les applis web Java, « si vous avez eu la chance ou la malchance d’en faire ». Les paquets Debian pour Linux. Aujourd’hui MCP, qui selon lui n’a mûri que récemment assez pour porter tout ce dont un vrai produit a besoin.

Il compte trois pièces dans le paquet, et les appelle la triforce, pour les fans de Zelda. Les outils, les capacités qu’un serveur donne au modèle. Les MCP Apps, des interfaces riches et interactives livrées via MCP. Et les skills via MCP, le savoir-faire qui se charge avec les outils ; NimbleBrain avait bricolé sa propre version rudimentaire avant que l’extension existe. Ajoutez un server.json et deux ou trois extensions, et vous avez quelque chose qu’on peut livrer et composer.

La petite démo montre pourquoi ça compte. Demandez à un serveur de tâches « qu’est-ce qui vient ensuite sur ma liste ? » et un widget HTML s’affiche dans une iframe, pas un paragraphe de texte. Les skills arrivent avec. Chaque bouton sur lequel vous cliquez est un appel d’outil.

Schéma : Les formats de paquet dans l’ordre : les exécutables pour le bureau, les fichiers WAR pour les applis web Java, les paquets Debian pour Linux, et maintenant MCP pour les agents et des applis entières. En dessous, les trois pièces que Goldsborough appelle la triforce, chacune dessinée comme un triangle du symbole de Zelda : les outils, ce que le serveur permet au modèle ; les MCP Apps, des interfaces affichées dans une iframe où chaque bouton est un appel d’outil ; et les skills, le savoir-faire chargé via MCP. Un server.json et deux ou trois extensions tiennent les trois. À voir sur la page.

Le chat, c’est le bac à sable de quelqu’un d’autre

Le hic, c’est que tout ça vit dans un chat. Le paquet est à vous, le serveur est à vous, mais le runtime ne vous appartient pas. Son image : vous entrez dans un bac à sable avec vos jouets, et quelqu’un vous dit comment jouer, où jouer, quelle hauteur font les murs et combien de sable vous avez.

Construire son propre hôte règle ça, et NimbleBrain l’a fait. Mais alors on réécrit la même plomberie à chaque fois. Et la spec elle-même est pensée pour un hôte qui parle à un serveur. Il n’y a pas grand-chose dedans pour un serveur MCP qui parle à un autre.

Il y a aussi un problème de public. Tout le monde fait du vibe coding dans Claude Code et construit son propre harness, a-t-il dit, mais les utilisateurs métier veulent toujours un tableau de bord, un bouton, un rapport, un graphique. Alors NimbleBrain a construit l’autre moitié.

Schéma : Deux façons de faire tourner une MCP App aujourd’hui, chacune avec son coût. Dans un hôte de chat, c’est leur bac à sable : votre paquet et votre serveur, mais l’hôte décide où l’appli s’affiche, quelle taille elle a et ce qu’elle peut atteindre, et la spec couvre un hôte qui parle à un serveur, pas des serveurs qui se parlent. Dans votre propre hôte, le runtime est à vous, mais vous reconstruisez la même plomberie à chaque fois : identité, fichiers, conversations et routage des outils, encore, pour chaque produit. La réponse de NimbleBrain : construire cet hôte une fois, en open source. À voir sur la page.

L’autre moitié, c’est un hôte

NimbleBrain démarre sur un shell vide avec des points d’extension : des endroits de l’interface web où une MCP App peut s’afficher. Les applis intégrées viennent d’abord (conversations, fichiers, tâches planifiées), et les applis installées s’affichent à côté. Une appli ou deux cents. Cliquez sur l’une d’elles et sa MCP App s’affiche dans la zone principale. Vous n’êtes plus dans un chat, c’est un écran SaaS complet, et les boutons ne font pas d’appels REST. Ce sont des appels d’outils MCP. Sa thèse, dite avec un sourire : REST est mort, on peut tout faire via MCP.

Faites glisser le chat et la même appli tourne avec un agent. Vous voyez les appels d’outils et les skills qui se chargent, et l’agent peut agir. Ou laissez tomber l’interface web et branchez votre propre client MCP, parce que le runtime est aussi un serveur MCP.

Sous le shell se trouve ce qu’il appelle les primitives de l’hôte, ce dont chaque serveur a besoin et qu’il ne devrait pas construire lui-même : fichiers, conversations, routage des outils, identité. Tout se découpe en espaces de travail. La finance a Sage et Stripe, l’ingénierie a GitHub et Linear, et vous gardez le vôtre, privé. Les pièces s’échangent. Un client qui avait sa propre mémoire dans une base vectorielle l’a branchée, des gens de son équipe qui aiment Obsidian ont branché Obsidian, et Salesforce ou HubSpot, c’est un choix de connecteur.

Ça tourne partout : sur site, dans un cloud privé, sur leur service managé. Ça le place à côté des API internes et du Postgres que personne n’a touché depuis vingt ans. Ils mettent un petit broker MCP devant, et un seul runtime atteint à la fois le cloud public et le système historique.

Le dépôt confirme tout ça. Il est sous Apache 2.0, tourne sur Bun, est livré en deux images de conteneur, et docker compose up vous donne l’interface web sur le port 27246. La boucle de l’agent tourne jusqu’à ce que le modèle arrête d’appeler des outils, plafonnée à 10 itérations par défaut et 25 au maximum.

Schéma : La pile de NimbleBrain en quatre couches. En haut, les portes d’entrée : le shell web, ou votre propre client MCP, comme un agent de code ou un harness. En dessous, les primitives de l’hôte que tous les serveurs partagent : fichiers, conversations, routage des outils, identité et espaces de travail. En dessous, la spec MCP : outils, ressources, applis et skills. Tout en bas, les serveurs : ceux de NimbleBrain (recherche web, mémoire, un CRM de contacts, une appli de prospection), les vôtres, n’importe quel serveur public, et un petit broker devant un Postgres de vingt ans. Les espaces de travail répartissent les connecteurs : la finance a Sage et Stripe, l’ingénierie GitHub et Linear, et un espace privé son propre GitHub. Ça tourne sur site, dans un cloud privé ou en service managé, avec n’importe quel modèle compatible OpenAI. À voir sur la page.

Placements : l’appli choisit sa place

Alors comment une appli se retrouve-t-elle dans la barre latérale ? Elle le demande. NimbleBrain a défini une extension d’hôte sous son domaine inversé, ai.nimblebrain/host, et le manifeste d’une appli liste des placements : un slot, un libellé, une route, et la ressource ui:// à afficher là.

"ai.nimblebrain/host": {
  "placements": [
    { "slot": "sidebar.apps", "resourceUri": "ui://dashboard",
      "label": "Tasks", "route": "tasks" },
    { "slot": "settings", "resourceUri": "ui://settings" }
  ]
}

L’hôte lit ça au démarrage. Il ne sait rien du serveur, seulement l’interface. Quand vous cliquez sur Tasks, il charge cette ressource dans une iframe de la zone principale, à côté du chat ancré, à une URL comme /w/ops/app/tasks. La doc liste les slots : une entrée sous Applis dans la barre latérale, une page entière sans entrée de navigation, une section sur la page de réglages du connecteur, et un élément épinglé en bas du tiroir mobile. La barre latérale montre les quatre premières applis, puis un lien Tout voir. Si deux connecteurs réclament la même route, le premier la garde, et l’hôte journalise qui la détient.

Une entreprise qui veut une autre disposition peut changer le gabarit autour des slots et garder les mêmes applis.

Schéma : Comment un placement devient un écran, en quatre étapes allumées tour à tour. Un : l’hôte lit le manifeste au démarrage, avec deux placements, une entrée sidebar.apps libellée Tasks avec la route tasks et la ressource ui://dashboard, et un placement settings avec ui://settings. Deux : l’entrée Tasks apparaît sous Applis dans la barre latérale. Trois : un clic ouvre /w/ops/app/tasks et l’hôte affiche ui://dashboard dans une iframe de la zone principale, à côté du chat ancré. Quatre : ui://settings s’affiche sur la page de réglages du connecteur. À voir sur la page.

C’est la partie que je volerais en premier. Un tableau de bord a besoin de chiffres : tâches bloquées, brouillons qui attendent une relecture. Vous pourriez demander au modèle. « Chaque fois que vous demandez au LLM, vous dépensez de plus en plus de tokens », a-t-il dit, alors les facets s’en passent.

Une facet est une ressource MCP ordinaire avec un marqueur dans son _meta. L’hôte liste les ressources du serveur, repère le marqueur, lit cette ressource, et récupère un seul nombre :

{ "uri": "acme://facets/drafts-awaiting-review",
  "title": "Drafts awaiting review",
  "_meta": { "ai.nimblebrain/facets": { "level": "warning" } } }

→ resources/read →  { "count": 3 }

L’hôte l’affiche en une ligne, « 3 Drafts awaiting review », dans un panneau Needs attention sur la vue d’ensemble de l’espace, et un clic ouvre l’appli. La doc précise le reste. Le niveau (critical, warning ou info) fixe la couleur et l’ordre. Un zéro n’affiche rien. Une lecture plus lente que cinq secondes affiche la ligne comme indisponible sans casser les autres. Les compteurs sont mis en cache 60 secondes. Et le titre et le compteur sont traités comme des données non fiables qui n’atteignent jamais un modèle.

Schéma : Le chemin d’une facet en quatre étapes allumées tour à tour. Un : l’hôte envoie resources/list au serveur. Deux : il repère une ressource dont le _meta porte le marqueur ai.nimblebrain/facets avec le niveau warning. Trois : il envoie resources/read et récupère un compteur de 3. Quatre : la vue d’ensemble de l’espace affiche la ligne 3 Drafts awaiting review. Sur le côté, le modèle est barré : il n’est pas sur ce chemin, donc aucun token n’est dépensé. En dessous, un panneau Needs attention avec une ligne par niveau, les titres tels que les serveurs les envoient : 2 Tasks blocked en critical, 3 Drafts awaiting review en warning, 1 Reply received en info. À voir sur la page.

Lifecycle : l’installer achète un domaine

Certains serveurs doivent faire quelque chose ailleurs quand on les installe. L’appli de go-to-market de NimbleBrain achète des domaines et provisionne des boîtes mail dès que vous l’ajoutez à un espace de travail. C’est à deux ou trois couches du fournisseur, et aucun message MCP ne dit « tu viens d’être installé ».

L’extension lifecycle ne fait pas l’achat. C’est le crochet. Un serveur marque un outil pour chaque événement, ready et removing, et l’hôte l’appelle par un appel d’outil ordinaire. Installez-le, et le serveur entend « espace prêt », puis va acheter. Désinstallez-le, et removing arrive pendant que le serveur est encore joignable, pour qu’il libère ce qu’il a acheté.

C’est dans la doc que ça devient intéressant, parce qu’elle est honnête sur la livraison :

ready arrive au moins une fois, et deux fois sur une installation neuve, dans un ordre incertain : une fois avec la raison install, une fois avec resume quand la connexion s’établit. Un redémarrage de l’hôte, c’est aussi resume, donc un redémarrage ne ressemble jamais à un nouveau client.
Le handler doit donc être idempotent : « fais que ce soit vrai », un upsert, jamais un insert.
removing est livré au mieux. Si l’hôte était éteint au moment de la désinstallation, il n’arrive jamais, donc un serveur qui laisse traîner un domaine sans lui compte sur un appel que rien ne garantit. Ajoutez votre propre balayage.
Le handler doit seulement enregistrer l’intention et rendre la main. Un processus séparé, qui détient l’identifiant du fournisseur, fait l’achat lui-même, pour qu’un bug ou un appel d’outil injecté par prompt ne puisse pas atteindre cet identifiant.
L’hôte cache les outils marqués à tous les autres, modèle compris. Un autre hôte pourrait ne pas le faire, donc la doc demande d’écrire chaque handler comme si n’importe quel appelant pouvait l’atteindre.

Schéma : L’extension lifecycle en trois moments allumés tour à tour. Installation : l’hôte appelle l’outil marqué ready avec la raison install, et le serveur enregistre que cet espace veut un domaine et des boîtes mail ; un processus séparé, qui détient l’identifiant du fournisseur, les achète. Redémarrage : l’hôte rappelle ready avec la raison resume, et le même upsert ne change rien. Désinstallation : l’hôte appelle l’outil marqué removing pendant que le serveur est encore joignable, et le serveur enregistre la libération ; comme removing est livré au mieux, un balayage maison rattrape les désinstallations dont il n’a jamais entendu parler. Le modèle ne voit jamais ces outils : l’hôte les cache à tous les autres appelants. À voir sur la page.

Dix applis devraient n’en faire qu’une

Il a montré deux applis faites par deux développeurs. L’un avait choisi le violet, l’autre le vert. Côte à côte, on aurait dit un patchwork.

La spec MCP Apps permet déjà à un hôte d’envoyer des variables de style à l’iframe. NimbleBrain les envoie, ajoute les tokens pour lesquels la spec n’a pas de clé, comme une couleur d’accent, et son SDK d’applis sous licence MIT, Synapse, les applique. Passez le shell en mode sombre et toutes les applis passent en sombre. « Combien de fois quelqu’un a essayé d’afficher une iframe dans un truc en mode sombre et a eu le mode clair ? » La même astuce donne des shells en marque blanche : les couleurs et les polices d’un client, c’est un kit de style, pas un rechargement d’appli.

Les toasts ont eu droit au même traitement. Le message de notification de la spec finit surtout en ligne de log, alors le bridge a une méthode notify avec un niveau et un titre, et le shell l’affiche comme ses propres toasts. Dans la doc, un succès reste cinq secondes, une info six, et les avertissements et les erreurs jusqu’à ce qu’on les ferme.

Basique, a-t-il reconnu. Mais c’est ce qui fait que dix ou douze serveurs donnent l’impression d’une seule appli plutôt que d’un assemblage cousu main.

Schéma : Deux applis faites par deux développeurs, une appli de tâches et une appli de prospection, en trois états qui se relaient. D’abord, deux looks : un développeur a pris le violet, l’autre le vert. Ensuite, l’hôte envoie ses tokens de thème et les deux applis prennent l’accent cobalt du shell. Enfin, le shell passe en mode sombre et les deux applis passent en sombre ensemble. En dessous, un toast envoyé avec la méthode notify du bridge, niveau success, titre Rapport exporté, description Enregistré dans Fichiers, affiché comme les toasts du shell. À voir sur la page.

Ce que ça change pour mes cinquante applis

Je fais tourner une cinquantaine d’applis sur un Mac mini, chacune derrière son propre port HTTPS Tailscale, chacune avec son front-end et son thème. Dix serveurs MCP vivent dans leurs propres dépôts à côté, la plupart de simples clients HTTP de l’API d’une appli, pour que mes agents puissent aussi utiliser les applis. Ce site en a un aussi : mon portfolio derrière un serveur MCP.

Donc chaque appli que touchent mes agents a deux portes d’entrée, construites deux fois : une interface pour moi et un serveur MCP pour eux. Le paquet de Goldsborough, c’est une seule porte. Outils, interface et skills sont livrés ensemble, le shell ancre un chat à côté de chaque écran, et les boutons comme l’agent appellent les mêmes outils.

Hier, j’ai construit une page qui liste chaque appli par port et vérifie lesquelles répondent. C’est son catalogue sans la composition. Les facets s’y glisseraient parfaitement : un compteur de ce qui attend dans chaque appli, sur une seule page, sans modèle dans la boucle.

Deux réserves honnêtes. Je n’ai pas encore fait tourner NimbleBrain ; tout ce qui précède vient du talk, du dépôt et de la doc. Et les extensions sont celles de NimbleBrain, sous son propre préfixe. Un autre hôte les ignore, ce que la doc rend sûr par conception, mais alors on perd la fonctionnalité. Goldsborough a dit qu’ils voulaient contribuer là où le travail sur la spec se recoupe déjà.

Une réponse du Q&A mérite d’être gardée. À la question « pourquoi les MCP Apps et pas A2UI ? », il a répondu qu’ils avaient adopté les MCP Apps à leur lancement et n’avaient pas encore vu l’intérêt d’A2UI. Et ce n’est pas de l’UI générative. Vous concevez et construisez toujours l’appli. Ça ressemble à une appli CRUD, avec une couche d’agent fournie d’office.

Schéma : Mon installation aujourd’hui face au paquet que décrit Goldsborough. Aujourd’hui, chaque appli a deux portes : un front-end avec son thème et son port, et un serveur MCP dans un autre dépôt qui appelle la même API, une cinquantaine d’applis et dix serveurs MCP en tout. En un paquet par appli : un server.json qui tient outils, interface et skills, un shell avec un chat et un look, et les boutons comme l’agent qui appellent les mêmes outils. Je n’ai pas encore fait tourner NimbleBrain ; ceci vient du talk et de la doc. À voir sur la page.

Essayez

Regardez le talk : le livestream d’AGNTCon + MCPCon à partir de 7:12:34, environ 25 minutes avec le Q&A.
Faites tourner l’hôte : NimbleBrainInc/nimblebrain, sous Apache 2.0. docker compose up avec une clé d’API Anthropic et un instance.json d’une ligne.
Construisez une appli pour lui, ou pour n’importe quel hôte MCP Apps : Synapse, sous MIT.
Lisez les extensions : placements, facets, lifecycle et le bridge des applis.
La spec en dessous : MCP Apps.

Si vous avez livré une MCP App hors d’une fenêtre de chat, je veux voir l’hôte. Et si vous essayez les facets avant moi, dites-moi ce que vous avez compté.

Cinq affirmations de couloir sur les agents personnels, vérifiées

2026-10-25T00:00:00Z

Sur le live de l’AGNTCon + MCPCon NA, un développeur prénommé Sid, tout juste retraité de la big tech, a livré cinq avis tranchés sur les agents personnels en quatre minutes environ. J’ai confronté chacun à ce que je fais tourner chez moi. Trois tiennent tels quels. Deux vont dans le bon sens mais trop loin : le harnais ne bat pas le modèle, et les échecs ne s’accumulent pas « de façon exponentielle ».

C’est une discussion de couloir, pas un talk, et il ne cite aucun produit. Le seul argument de vente reste discret : voilà pourquoi mon assistant sera différent. Regarder à partir de 2:09:50.

Les tâches ponctuelles marchent, les quotidiennes dérivent

Son idée : réserver un restaurant, c’est une tâche qu’on vérifie une fois. Répondre à ses mails tous les jours, non. Il a vu deux mails qui se contredisent recevoir deux réponses séparées, sans rien pour les relier.

Juste, et je l’ai vécu. Mon agent de résumé quotidien des mails listait environ 77 mails par jour, dont à peu près 5 comptaient vraiment. Je l’ai supprimé cette semaine. Une bonne exécution, c’est facile. La même qualité chaque matin, c’est ça le plus dur.

Le harnais compte, et le modèle aussi

Il dit que le harnais est plus puissant que le modèle, et qu’un modèle seul est assez bête. La seconde moitié est vraie : le même modèle varie beaucoup selon ses outils, sa boucle et ses vérifications. C’est toute l’idée de forker le harnais de son agent.

La première moitié va trop loin. Aucun harnais ne sauve un modèle faible sur une tâche de raisonnement difficile. La version juste : la plupart des gens sous-investissent dans le harnais.

La mémoire, c’est savoir oublier

Exact, et l’animateur a dit que c’était le plus dur. Une fenêtre de contexte plus grande ne décide pas quoi garder, ce qui est périmé, ni lequel de deux faits l’emporte quand ils se contredisent. Mon agent de code garde sa mémoire sous forme de petits fichiers qu’il met à jour et supprime, et traite chaque souvenir rappelé comme peut-être dépassé.

Un agent fiable avant cinq qui se parlent

Il veut un agent qui marche de façon régulière avant toute configuration agent à agent. Le calcul est le vieux calcul rappelé par l’animateur : si chaque étape est juste 98 % du temps, dix étapes d’affilée aboutissent environ 82 % du temps. C’est une multiplication, pas une explosion, et les vérifications et les relances en récupèrent une bonne partie. C’est quand même le bon ordre pour construire.

Le contexte gonflé est un vrai problème, avec des solutions

Apprendre à un agent chaque outil dans son prompt coûte des tokens à chaque appel. Il parle de 5 000 à 10 000. C’est vrai, mais il oublie les solutions. Le cache de prompt rend un prompt répété bien moins cher, et les outils peuvent n’être chargés que quand l’agent les demande. La session qui m’a servi à vérifier ses affirmations chargeait la plupart de ses outils comme ça.

Faites le test ennuyeux

Rien de tout ça n’est nouveau, et c’est très bien : c’est une photo honnête des agents personnels fin 2026. Si vous en construisez un, commencez par son premier point. Donnez-lui la même tâche tous les jours pendant une semaine, puis lisez les résultats côte à côte. Dites-moi ce qui dérive.

Une sandbox dans la sandbox : migrer mon agent open source vers Hermes sur OpenShell

2026-10-24T00:00:00Z

Forge, mon agent open source, clone les dépôts d’inconnus et lance leurs scripts d’installation et leurs suites de tests à longueur de journée. Quand j’ai commencé à le migrer vers Hermes Agent dans NVIDIA OpenShell, j’ai découvert que la sandbox autour de l’agent ne suffisait pas : dans une même sandbox OpenShell, un processus lancé par l’agent récupère les règles réseau de l’agent. Les workers de Forge ont donc une deuxième barrière à l’intérieur de la première, faite de Landlock, d’un filtre seccomp et d’un petit relais qui est leur seule sortie. La migration n’est pas finie. La cage fonctionne, et OpenShell m’a appris deux règles auxquelles je ne m’attendais pas.

Le 23 octobre, j’écrivais que les conseils de NVIDIA pour les agents commencent par la sandbox, et que ma propre ligne sandbox était vide. Le lendemain, Hermes tournait dans OpenShell sur un vieux portable Dell. Cette note raconte ce qui a suivi l’installation : où vivent les clés, ce dont hérite un processus enfant, et ce qu’une sandbox dans une sandbox doit bloquer.

Exécuter le code d’inconnus, c’est le métier de Forge

Forge est mon agent de contribution open source. Il cherche des issues sur des projets populaires dans mes domaines, choisit celles qui valent la peine d’être traitées, et confie chacune à un worker détaché. Claude Code clone le dépôt, écrit le correctif et lance les tests du projet. Un contrôle relance lui-même les vérifications, un second modèle relit le diff, et le correctif part sur mon fork. Tout ce qui est dit ensuite sur une pull request attend mon feu vert.

Il tourne avec un budget de 5 $ par jour, et au plus quatre pull requests ouvertes en même temps.

L’étape risquée, c’est le build. « Lancer les tests », ça veut dire exécuter tout ce que font les scripts d’installation et les suites de tests d’un dépôt, écrits par des gens que je n’ai jamais rencontrés. Sur le Mac mini, où Forge vit aujourd’hui comme agent OpenClaw, les workers tournent dans srt, un runtime de sandbox qui repose sur Seatbelt, la sandbox de macOS. Passer Forge sous Linux voulait dire reconstruire cette barrière.

Schéma : Une tâche de Forge en cinq étapes, allumées tour à tour. Un, l’éclaireur : Forge trouve des issues sur des projets populaires dans mes domaines et choisit celles qui valent la peine. Deux, le worker : Claude Code clone le dépôt, écrit le correctif et lance l’installation et les tests, du code écrit par des inconnus ; cette étape est marquée en rouge, c’est celle qui a besoin d’une barrière. Trois, le contrôle : il relance lui-même les vérifications du worker et le renvoie une fois si elles échouent. Quatre, le relecteur : un second modèle lit le diff, et un problème bloquant donne droit à un correctif de plus. Cinq, la livraison : le correctif est poussé sur mon fork et la pull request s’ouvre, et tout ce qui s’y dit ensuite attend mon feu vert. Aujourd’hui, Forge tourne comme agent OpenClaw sur le Mac mini, avec ses workers dans srt sur Seatbelt de macOS, pour cinq dollars par jour et au plus quatre pull requests ouvertes. À voir sur la page.

Hermes a emménagé en premier

L’hôte est un vieux portable Dell Inspiron sous Ubuntu Server 26.04, écran rabattu. NemoClaw, l’installeur de NVIDIA pour les agents dans OpenShell, a mis en place la CLI et la gateway en 78 secondes, sans sudo. J’ai figé la version 0.0.137, qui embarque OpenShell 0.0.116, et choisi Hermes comme agent. Il a démarré en Hermes Agent v0.21.3, sur Claude Sonnet 5.5 via OpenRouter.

Le premier mur, c’était Docker. Le Dell fait tourner Docker en rootless, et la gateway d’OpenShell ne peut pas vivre là : les sandboxes sont dans le namespace réseau propre à Docker rootless alors que la gateway écoute sur l’hôte, donc une sandbox ne peut pas la rappeler. La voie rootless qui marche sous Linux, c’est Podman, en version 5 ou plus. Il a fallu une seule étape root, une petite unité système qui ajoute une adresse sur la loopback. Je l’ai lancée à la main, parce que mes agents n’ont pas sudo sur cette machine.

Telle qu’elle est installée, la sandbox refuse tout par défaut. Avec seulement le preset PyPI activé, une requête vers example.com reçoit un 403. L’API et le tableau de bord d’Hermes écoutent sur la loopback, et NemoClaw possède le fichier de config d’Hermes et en vérifie le hash : on ne le modifie pas à la main. Forge tournera plutôt comme un profil Hermes à part, avec son propre SOUL.md et un hook qui voit chaque appel d’outil avant son exécution. Lors d’un test, ce hook a bloqué un rm.

Schéma : La pile sur le Dell, en boîtes imbriquées. La boîte extérieure est un portable Dell Inspiron sous Ubuntu Server 26.04. Dedans, Podman 5.7 en rootless. Dedans, OpenShell 0.0.116 : sa gateway, son proxy et les clés. Dedans, la sandbox, en refus par défaut, et dans celle-ci Hermes Agent v0.21.3, avec Forge prévu comme un profil Hermes à part. Sous la pile, trois chiffres : NemoClaw installé en 78 secondes sans sudo ; une seule étape root, une adresse sur la loopback pour Podman ; et un 403 pour example.com, parce que la sandbox refuse tout par défaut. Docker rootless n’a pas marché : les sandboxes sont dans son namespace réseau et la gateway sur l’hôte, donc elles ne peuvent pas la rappeler. À voir sur la page.

Les clés arrivent sous forme de placeholders

Ma dernière note expliquait l’astuce d’OpenShell pour les identifiants, d’après la doc. Voici à quoi elle ressemble de l’intérieur. L’environnement de la sandbox ne contient aucune clé d’API, seulement un placeholder qui commence par openshell:resolve:env:. Quand Hermes appelle OpenRouter avec ce placeholder dans son en-tête d’authentification, le proxy d’OpenShell identifie le programme, vérifie la politique et glisse la vraie clé au passage. Hermes ne la voit jamais.

Puis j’ai mis des placeholders là où ils n’ont rien à faire. Un dans le corps d’une requête : le proxy a coupé la connexion. Le placeholder d’un autre fournisseur dans un en-tête : 403.

Telegram va un cran plus loin. NemoClaw lie le token du bot à un seul hôte, un seul port et un seul chemin, l’API des bots, et partout ailleurs le placeholder reste un placeholder.

Schéma : Comment une clé atteint OpenRouter sans entrer dans la sandbox. Dans la sandbox, la variable de la clé ne contient qu’un placeholder qui commence par openshell:resolve:env. Un : Hermes envoie sa requête avec le placeholder dans l’en-tête d’authentification. Deux : le proxy d’OpenShell identifie le programme derrière la connexion. Trois : il vérifie la politique pour ce programme et cet hôte. Quatre : il glisse la vraie clé au passage, si bien que la clé n’entre jamais dans la sandbox. Cinq : un placeholder au mauvais endroit est refusé ; dans le corps d’une requête la connexion est coupée, et le placeholder d’un autre fournisseur dans un en-tête reçoit un 403. Telegram va plus loin : le token du bot est lié à un seul hôte, un seul port et un seul chemin, et partout ailleurs il reste un placeholder. À voir sur la page.

Les identifiants suivent l’endpoint, pas le programme

Les règles réseau d’OpenShell nomment les deux côtés d’un appel : quel programme a le droit de se connecter, et vers quel hôte. Je supposais que les identifiants marchaient pareil, et qu’une clé prévue pour gh ne serait glissée que dans les requêtes de gh.

Ce n’est pas le cas. La clé d’un fournisseur est résolue pour tout processus qu’une politique, quelle qu’elle soit, laisse passer vers l’endpoint de ce fournisseur. Je l’ai découvert quand mon relais, qu’un preset de test laissait passer vers l’API de GitHub, a reçu le token GitHub dans sa requête. C’était ma propre sonde, donc rien n’a fuité. Mais ça a réécrit ma règle de conception : un programme qu’un worker peut piloter ne doit jamais avoir de politique vers un hôte lié à un identifiant.

Schéma : Deux cartes. À gauche, ce que je supposais : les clés suivent le programme. gh qui appelle api.github.com reçoit la clé, et le relais qui appelle api.github.com ne reçoit que le placeholder. À droite, ce que fait OpenShell : les clés suivent l’endpoint. gh qui appelle api.github.com reçoit la clé, et le relais, qu’un preset de test laissait passer vers le même hôte, reçoit la clé lui aussi. En dessous, la règle que je suis désormais : un programme qu’un worker peut piloter n’a aucune politique vers un hôte lié à un identifiant. À voir sur la page.

Un enfant hérite du réseau de son parent

La deuxième règle : les politiques suivent l’arbre des processus vivants. Un processus reçoit les règles réseau de son propre programme plus celles de chacun de ses ancêtres, vérifiées au moment où il fait la requête.

Ça compte, parce que les scripts de Forge sont en Python, et que le Python de la sandbox est celui sur lequel tourne Hermes. Chaque script que Forge lance correspond aux règles d’Hermes, OpenRouter et Telegram, et tout ce que ces scripts lancent aussi. Un worker lancé de la façon évidente hérite d’un chemin vers le fournisseur de modèle de l’agent et vers son bot de discussion.

Pour sortir de l’héritage, il faut cesser d’être un descendant. Un processus qui fait un double fork finit enfant du PID 1 et ne garde que les règles de son propre programme. C’est comme ça que démarre le relais de Forge : détaché, sur sa propre copie de Python pour ne pas correspondre non plus aux règles d’Hermes, il surveille l’étape de worker qui l’a lancé et s’arrête quand elle se termine.

Schéma : L’arbre des processus dans la sandbox, un processus allumé à la fois. Hermes tourne sur le Python de la sandbox et a deux règles réseau, OpenRouter et Telegram. Le script de Forge, enfant d’Hermes sur le même Python, reçoit les deux mêmes. L’étape de worker, Claude Code lancé par le script, en hérite aussi, même si sa cage l’empêche de joindre le proxy d’OpenShell. Le relais est détaché : il fait un double fork, son parent devient le PID 1, il tourne sur sa propre copie de Python, et il ne garde que ses propres règles, les registres de paquets et Anthropic. À voir sur la page.

La deuxième barrière

Dans OpenShell, chaque étape de worker tourne dans sa propre cage. Elle a trois parties, deux venues du noyau Linux et un relais d’environ deux cents lignes de Python.

Landlock, la sandbox non privilégiée du noyau, en ABI 8 : des listes de ce que le worker peut lire, écrire et exécuter ; les connexions TCP, autorisées sauf vers le proxy d’OpenShell, sa gateway et les ports d’Hermes ; aucun signal ni socket unix abstrait vers quoi que ce soit hors de la cage.
Un filtre seccomp qui refuse les sockets unix et io_uring. Landlock ne contrôle pas une connexion à un fichier socket, et la gateway d’Hermes écoute sur l’un d’eux : avec Landlock seul, mon test l’a atteinte. io_uring est refusé lui aussi, parce qu’il pourrait ouvrir ce socket sans passer par l’appel système que le filtre surveille.
Le relais : un proxy qui n’accepte que CONNECT, avec une liste d’hôtes autorisés, les registres de paquets et l’API d’Anthropic. La sandbox n’a aucune route directe vers l’extérieur, donc le relais est la seule porte qui reste. Il transmet au proxy d’OpenShell, qui voit le relais comme l’appelant.

Le worker peut donc installer des paquets et appeler Claude. Les registres passent en TLS simple, sans inspection et sans clé à ajouter. Sur les appels du relais vers Anthropic, OpenShell ajoute la clé de Forge, pour les endpoints Messages et comptage de tokens uniquement. Le worker dépense des tokens sans jamais détenir la clé. Le relecteur tourne comme un programme à part, avec sa propre règle pour OpenRouter, sur GLM 5.3.

J’ai testé de bout en bout. claude -p dans la cage a répondu via le relais pour 0,026 $ sur Haiku, et le relecteur a répondu via OpenRouter.

Schéma : La cage du worker dans la sandbox OpenShell. La sandbox contient Hermes avec Forge, et à côté la cage du worker, Landlock plus seccomp, avec le worker Claude Code dedans. La seule sortie de la cage est le relais, qui autorise les registres de paquets et Anthropic et transmet au proxy d’OpenShell ; c’est là qu’OpenShell ajoute la clé Anthropic de Forge. Puis une ligne par règle. Fichiers : listes Landlock de lecture, écriture et exécution. TCP : Landlock bloque le proxy et la gateway d’OpenShell et les ports d’Hermes. Sockets unix et io_uring : refusés par seccomp. La sortie : le relais, CONNECT uniquement, avec une liste d’hôtes autorisés. Clés : ajoutées par OpenShell sur les appels du relais vers Anthropic, jamais dans la cage. Testé : claude -p a répondu via le relais pour 0,026 dollar sur Haiku, et le relecteur a répondu sur GLM 5.3. À voir sur la page.

Quatre pièges à connaître avant de commencer

Aucun ne figure dans un guide de démarrage. Chacun m’a bloqué jusqu’à ce que je le trouve.

L’erreur qu’on ne voit pas. Deux politiques qui nomment le même hôte doivent lui donner la même forme : mode TLS, protocole et mode d’application, jokers compris. OpenShell refuse une incohérence avec « network endpoint ambiguity validation failed ». NemoClaw disait seulement « OpenShell did not confirm the policy submission ». Un script wrapper nommé openshell, placé en tête du PATH et qui journalise chaque appel, m’a montré la vraie erreur.

Les programmes ont besoin de leur chargeur. Sous Landlock, un programme lié dynamiquement a aussi besoin des droits d’exécution sur le chargeur dynamique. La liste d’exécution accorde donc /usr, pas des binaires un par un.

Le mauvais Python. Dans la sandbox, le python3 du PATH est l’environnement virtuel d’Hermes. Le PATH du worker l’exclut, et son fichier de config est de toute façon illisible sous Landlock.

Deux orthographes pour un proxy. curl préfère https_proxy en minuscules, donc le worker définit les deux casses.

Schéma : Quatre pièges, une carte chacun, avec ce qu’on voit et ce qui l’a réglé. L’erreur qu’on ne voit pas : NemoClaw dit OpenShell did not confirm the policy submission, alors que la vraie cause est le même hôte dans deux politiques avec des formes différentes ; un wrapper openshell qui journalise, placé en tête du PATH, montre l’erreur d’OpenShell elle-même, network endpoint ambiguity validation failed. Les programmes ont besoin de leur chargeur : sous Landlock, un binaire dynamique a aussi besoin des droits d’exécution sur le chargeur dynamique, donc autorisez /usr plutôt que des binaires un par un. Le mauvais Python : dans la sandbox, le python3 du PATH est l’environnement virtuel d’Hermes, donc le PATH du worker l’exclut. Deux orthographes pour un proxy : curl préfère https_proxy en minuscules, donc définissez les deux casses. À voir sur la page.

Où on en est

Hermes tourne dans OpenShell, les règles des identifiants et de l’héritage sont cartographiées, et la cage fonctionne. Un profil Forge avec son propre SOUL.md et un hook sur les appels d’outils répond via l’API d’Hermes.

Le reste, c’est l’essentiel du travail. Les scripts de Forge doivent encore être portés sur le Dell. Ensuite un essai à blanc, sans push ni message, et alors seulement la bascule : le bot Telegram @forge déménage, les clés passent dans des providers OpenShell, et les copies sur le mini sont supprimées. Le tableau de bord de Forge reste sur le mini et récupère ses données depuis le Dell.

D’ici là, Forge tourne là où il a toujours tourné : OpenClaw sur le Mac mini, workers dans srt.

Schéma : Où en est la migration le 24 octobre, une ligne par pièce. Hermes dans OpenShell, sur Podman, en refus par défaut, Sonnet 5.5 : en service. Clés et règles, placeholders, endpoints et héritage : cartographiés. La cage du worker, Landlock, seccomp et le relais, avec claude -p et le relecteur qui répondent : testée. Forge comme profil Hermes, avec son propre SOUL.md et un hook qui a bloqué rm : testé. Le portage des scripts de Forge sur le Dell : pas encore. L’essai à blanc, sans push ni message : pas encore. La bascule, qui déplace le bot Telegram et les clés et supprime les copies du mini : pas encore. D’ici là, Forge tourne sur OpenClaw sur le Mac mini, avec ses workers dans srt. À voir sur la page.

Essayez

NemoClaw est le chemin court : il installe OpenShell, met en place OpenClaw ou Hermes dans une sandbox et vous fait démarrer sur une politique de refus par défaut. Lisez le script de bootstrap avant de le lancer, figez une version, et sous Linux sans root, prenez Podman.

Pour aller plus loin :

OpenShell sur GitHub, sous Apache 2.0, avec la doc des politiques
NemoClaw sur GitHub, l’installeur que j’ai utilisé
Hermes Agent, de Nous Research
Landlock dans la doc du noyau, la sandbox non privilégiée sous la cage
Espérer n’est pas sécuriser : les cinq pièces d’un agent en entreprise, la note que celle-ci prolonge
OpenClaw et Hermes Agent offrent les mêmes fonctionnalités, mais pas les mêmes réglages par défaut, où les deux exécutent les outils sur l’hôte par défaut

Si votre agent lance des processus qui exécutent du code que vous n’avez pas écrit, regardez ce dont ces enfants héritent avant de faire confiance à la sandbox autour du parent. Et si vous avez cloisonné des workers dans OpenShell autrement, racontez-moi comment. J’aimerais comparer nos cages.

Tokenomics : ne comptez pas les tokens, comptez ce qu’ils ont acheté

2026-10-24T00:00:00Z

La tokenomics, c’est l’économie de l’IA : la discipline qui consiste à transformer de l’énergie et du capital en IA, puis à utiliser cette IA assez bien pour prouver une valeur métier. Rien à voir avec la crypto. Sa première règle a de quoi surprendre pour une discipline qui tire son nom des tokens : ne comptez pas les tokens. Comptez ce qu’ils ont acheté.

C’est le message de J.R. Storment, directeur exécutif de la nouvelle Tokenomics Foundation au sein de la Linux Foundation, dans une keynote de cinq minutes à l’AGNTCon + MCPCon le 22 octobre. Il a ouvert sur deux questions à la salle. Combien d’entre vous savent ce que leurs agents leur coûtent ? Quelques mains. Combien savent relier ça à de la valeur et à un ROI ? Une seule, au fond.

De l’énergie en entrée, de la valeur en sortie

Sa slide donne la définition : prendre de l’énergie et du capital, les faire passer par des puces pour créer de l’intelligence, consommer cette intelligence efficacement, et produire à l’autre bout une valeur métier mesurable. Sa version courte : de l’énergie qui crée de l’intelligence qui crée de la valeur.

La définition n’est encore qu’un brouillon. La Linux Foundation a lancé la Tokenomics Foundation le 4 août pour écrire des standards, des benchmarks et des bonnes pratiques ouverts et neutres vis-à-vis des fournisseurs sur l’économie de l’IA, et elle travaille étroitement avec la FinOps Foundation.

Schéma : La définition de la Tokenomics Foundation en trois étapes, avec un repère qui les parcourt. L’énergie et le capital entrent. Ils passent par des puces et ressortent sous forme d’intelligence. Cette intelligence est consommée efficacement, et il en ressort une valeur métier mesurable. Sa version en une ligne, en grand : de l’énergie qui crée de l’intelligence qui crée de la valeur. Un bandeau en dessous précise que la définition est encore un brouillon, version 0.5.2, datée du 1er septembre 2026. À voir sur la page.

Le coût par résultat bat le coût par token

Le nombre de tokens n’est pas la mesure de valeur qui compte, dit-il. Même le coût par token n’est pas la bonne. Le coût par tâche vaut mieux, le coût par résultat mieux encore, et ce qu’il vous faut au final, c’est la valeur métier rapportée au coût total de l’IA, pas seulement au coût des tokens.

Un nombre de tokens vous dit à quel point les modèles ont été occupés. Il ne vous dit pas si le travail valait la peine. Ma note sur TokenOps traite l’autre moitié du problème : pourquoi le coût d’une tâche peut grimper bien plus vite que son nombre de tours.

Schéma : Cinq façons de mesurer l’IA, en escalier qui se décale vers la droite à mesure que les mesures s’améliorent, de celle qu’il conseille d’oublier à celle à viser. Le nombre de tokens : pas la mesure de valeur qui compte. Le coût par token : même lui n’est pas le bon. Le coût par tâche : mieux. Le coût par résultat : encore mieux. En bas, couleur surligneur : la valeur métier rapportée au coût total de l’IA, pas seulement au coût des tokens. Les marches s’allument l’une après l’autre, de haut en bas. À voir sur la page.

La facture ne s’arrête pas au modèle

Le coût total de l’IA comprend tout ce qui se trouve sous les modèles. Il a listé ce que les agents entraînent discrètement : le calcul inutilisé, le stockage, le réseau, les données, et souvent des licences et des logiciels. Puis le travail humain : votre temps, celui de vos collègues et celui de l’entreprise pour gérer tout ça, plus ce que ça change, avec le temps, aux plans de recrutement et d’effectifs.

Un compteur de tokens ne voit rien de ce qui est sous la ligne. Mon propre Meterlex chiffre chaque appel de modèle à partir des logs de session, c’est-à-dire exactement la partie visible. Utile, mais ce n’est que le haut de la réponse.

Schéma : Le coût d’une pile d’agents : un bloc au-dessus d’une ligne de flottaison et un ensemble de blocs en dessous. Au-dessus de la ligne, en cobalt : les modèles, c’est-à-dire les tokens, la partie que voit un compteur de tokens. Sous la ligne, sur fond gris avec des contours en pointillé : le calcul inutilisé, le stockage, le réseau, les données, les licences et logiciels, et le travail humain. Le travail humain, c’est votre temps, celui de vos collègues et celui de l’entreprise pour gérer tout ça, plus l’effet sur les plans de recrutement et d’effectifs. Les tailles ne sont pas à l’échelle : la keynote ne donnait aucune proportion. À voir sur la page.

L’entreprise compte autre chose

L’entreprise, dit-il, se moque de savoir combien d’agents vous avez, combien de tâches ils terminent, combien de lignes de code vous écrivez, combien de PR vous livrez, et même combien de fonctionnalités. Ce qui l’intéresse, c’est le chiffre d’affaires, les résultats, et la façon dont l’organisation a changé. Et ce côté-là est moins excitant que ce que vous pouvez livrer avec un agent cet après-midi, c’est pour ça qu’on en parle moins.

Il voit revenir un schéma déjà vécu avec le cloud. Le cloud est devenu trop cher, et les gens ont ramené leurs charges de travail chez eux : c’est le rapatriement. Avec l’IA, les premiers signes sont déjà là, dans les récits qui passent du token maxing à la façon de tirer de la valeur à l’autre bout.

Schéma : Deux cartes. Celle de gauche, en gris pointillé, montre ce que comptent ceux qui construisent : les agents, les tâches, les lignes de code, les pull requests livrées, les fonctionnalités livrées. Celle de droite, en cobalt, montre ce que compte l’entreprise : le chiffre d’affaires, les résultats, et la façon dont l’organisation a changé. En dessous, un bandeau porte son avertissement venu du cloud : quand la facture est devenue trop lourde, les gens ont fait marche arrière, et il voit les premiers signes de la même chose avec l’IA, à mesure que les récits passent du token maxing à la création de valeur. À voir sur la page.

Trois couches, et un écart au bout

La Fondation regarde toute la chaîne d’approvisionnement, en trois couches. La production, c’est le côté data center : l’énergie, les puces, les usines d’IA et les modèles. La consommation, c’est la qualité de l’usage qu’on fait de ce qui en sort : le KV cache, le prompt engineering, le choix du modèle, la prévision de la demande, et même le coût du harnais (harness). La valeur, ce n’est pas seulement le coût par résultat ou l’intelligence par watt, c’est l’impact métier, y compris les modèles de tarification et les marges.

Leur première enquête, le State of Tokenomics, a eu lieu en septembre. Beaucoup de répondants étaient sûrs de bien voir leurs dépenses. Très peu étaient sûrs de pouvoir en prouver la valeur à la personne qui valide le budget IA, le DAF. Il a parlé d’un vrai décalage. La keynote ne donnait aucun chiffre et je n’ai pas lu le rapport, donc je n’en citerai pas.

Schéma : La chaîne d’approvisionnement de la Tokenomics Foundation en trois colonnes. Un, la production : l’énergie, les puces, les data centers, les usines d’IA et les modèles. Deux, la consommation : le KV cache, le prompt engineering, le choix du modèle, la prévision de la demande et le coût du harnais. Trois, la valeur : le coût par résultat, l’intelligence par watt, l’impact métier, les modèles de tarification et les marges. En dessous, l’écart relevé par l’enquête en deux barres : sûrs de voir la dépense, une longue barre, et sûrs de prouver la valeur au DAF, une courte. La longueur des barres est schématique, car la keynote ne donnait aucun chiffre. À voir sur la page.

Ce que la communauté construit

Le travail avance sur les trois couches. Il a cité l’optimisation du cache, le routage de modèles et les gateways, et Big T, un clin d’œil à la notation Big O, version tokens. Sur le site de la Fondation, Big T écrit la croissance des tokens comme T de n fois k fois a : n est le nombre de requêtes ou la taille de l’entrée, k le nombre d’appels de modèle par requête, a la profondeur de l’agent. La page liste d’autres niveaux entre les deux ; je n’ai vérifié que les deux extrêmes et le cas par défaut :

Niveau	Ce que c’est
T de 1	Un hit de cache, aucun appel de modèle
T de n	Le cas sain par défaut : un appel par requête
T de l’infini	Sans borne : une boucle sans condition d’arrêt

Le conseil de la page : borner la profondeur et ajouter des budgets. L’annonce du lancement ajoute deux chantiers prévus : la télémétrie du coût des tokens dans FOCUS, le format FinOps de reporting des coûts, et une mesure de la valeur qui commence par la part du travail accomplie sans intervention humaine.

Tout cela, dit-il, se ramène à une seule tâche : prendre ce que votre IA a fait et le montrer à l’entreprise dans des termes qu’elle reconnaît. Le chiffre d’affaires. Les coûts évités. Le gain de capacité. Le travail augmenté. La vitesse de mise sur le marché, et pas seulement celle du code.

Schéma : Le travail en cours, à gauche, se déverse dans les mots que l’entreprise reconnaît, à droite. À gauche, trois chantiers : l’optimisation du cache, Big T, la notation Big O des tokens, et le routage de modèles et les gateways. Une flèche portant les mots « se ramène à » pointe vers la droite, vers cinq expressions qu’un DAF reconnaît : le chiffre d’affaires, les coûts évités, le gain de capacité, le travail augmenté et la vitesse de mise sur le marché, c’est-à-dire, selon lui, sortir vite de nouvelles capacités, pas seulement du code. À voir sur la page.

À vous d’essayer

La conférence de la Fondation à San Diego, Tokenomicon avec FinOps X, se tient du 7 au 10 juin 2027. D’ici là :

Regardez les cinq minutes : la keynote sur le livestream de l’AGNTCon, à partir de 39:41.
Lisez la page de la Fondation : tokeneconomics.com donne la définition, les trois couches et Big T.
Lisez le lancement : l’annonce de la Linux Foundation.
Lisez le côté coûts en détail : TokenOps : pourquoi un agent à 40 tours coûte 16×, et pas 4×.

La prochaine fois que vous ouvrez une facture d’IA, écrivez à côté un résultat, dans les termes du DAF. Si vous avez réussi à mesurer un vrai coût par résultat, j’aimerais savoir comment vous avez défini le résultat.

Espérer n’est pas sécuriser : les cinq pièces d’un agent en entreprise

2026-10-23T00:00:00Z

À la GTC Berlin, le 21 octobre, Jensen Huang a démonté un agent IA en cinq pièces : le modèle, le harnais (harness), la sandbox dans laquelle tourne ce harnais, la connaissance de votre entreprise et vos outils. Son conseil à toute entreprise qui se prépare aux agents commence par la sandbox, pas par le modèle. Aujourd’hui, la seule chose entre un agent et vos clés SSH, c’est un prompt qui lui demande gentiment. OpenShell, la réponse de NVIDIA, place les règles hors de l’agent, là où une politique contrôle chaque fichier, chaque appel système et chaque connexion réseau.

La partie agents de la keynote va à peu près de la minute 41 à la minute 66. C’est la checklist la plus claire que j’aie vue sur ce qu’une entreprise doit avoir en place avant que des agents touchent à ses systèmes. C’est aussi la keynote d’un fournisseur, donc je signale les affirmations arrivées sans chiffre. Je fais tourner une flotte d’agents OpenClaw sur un Mac mini, et à la fin je confronte ma propre installation à la liste.

Un agent, c’est cinq pièces, et une seule est le modèle

Jensen a ouvert sur le grand changement de l’année. Les agents réfléchissent, raisonnent, itèrent et utilisent des outils, et cela brûle une quantité énorme de tokens : la consommation de tokens, selon ses mots, « a explosé », et la demande en GPU avec elle. Selon lui, c’est OpenClaw, dont NVIDIA parlait en début d’année, qui a lancé la vague d’agents open source qu’on voit partout aujourd’hui.

Puis l’anatomie. Le modèle de langage génère des tokens. Le harnais les consomme ; Jensen l’appelle l’exosquelette, et son exemple, c’est OpenClaw. Le harnais vit dans une sandbox qui l’isole du reste du système. Les deux dernières pièces sont la connaissance et les outils.

Le schéma de NVIDIA dessine le harnais comme une boucle : prendre le contexte, raisonner, planifier, agir, puis recommencer, avec la connaissance et les outils branchés en dessous. Le modèle réfléchit. Les quatre autres pièces décident de ce que cette réflexion peut toucher.

Schéma : L’anatomie d’un agent selon NVIDIA, redessinée. En haut, le modèle génère des tokens. Ils alimentent le harnais, que Jensen appelle l’exosquelette, dessiné comme une boucle de quatre étapes : contexte, raisonnement, plan et action, puis retour au contexte. Le harnais vit dans une sandbox qui l’isole du reste du système. Sous la sandbox, le harnais se branche sur les deux dernières pièces : la connaissance de l’entreprise et ses outils. La phrase de Jensen : modèles, sandbox, harnais, connaissance et outils sont les cinq éléments d’un agent. À voir sur la page.

Le « s’il te plaît » n’est pas un modèle de sécurité

Avant de rendre les agents utiles, dit Jensen, il faut les sécuriser. Un agent est un système autonome qui a accès à des fichiers, des ressources, des réseaux et des outils. Ses privilèges doivent être minimaux, et il doit être surveillé en permanence.

La vidéo qui a suivi contient la meilleure phrase de la keynote. Aujourd’hui, la seule chose qui empêche un agent d’abuser de ses accès, c’est de lui demander gentiment. « S’il te plaît, ne supprime rien. S’il te plaît, ne touche pas à mes clés SSH. » NVIDIA appelle ça l’approche du « s’il te plaît », et y répond en trois mots : « hope isn’t security », espérer n’est pas sécuriser.

J’ai écrit ces prompts. Tous ceux qui font tourner des agents l’ont fait. Le problème, c’est l’endroit où ils vivent : dans le contexte de l’agent lui-même, là où atterrit aussi une injection de prompt venue d’un e-mail ou d’une page web.

La vidéo compare avec les débuts du web. Les virus étaient partout jusqu’à ce que les navigateurs imposent des limites strictes à ce qu’une page pouvait faire. Personne n’a demandé gentiment à la page. OpenShell veut être ce navigateur pour les agents : vous écrivez une politique qui dit ce que chaque agent peut toucher, et elle s’applique aux appels système, aux accès fichiers et aux connexions réseau, en dehors de l’agent, « pas seulement dans les garde-fous du LLM ».

Schéma : Deux façons de tenir un agent loin de vos clés SSH. À gauche, l’approche du s’il te plaît : les règles sont des lignes dans le prompt de l’agent, s’il te plaît ne supprime rien et s’il te plaît ne touche pas à mes clés SSH, et la requête de l’agent passe à travers et atteint les clés. À droite, le contrôle hors de l’agent : une politique se place entre l’agent et les clés, et la même requête y est refusée. En dessous, la comparaison de la vidéo de NVIDIA : les virus étaient partout aux débuts du web, jusqu’à ce que les navigateurs imposent des limites strictes à ce qu’une page pouvait faire. À voir sur la page.

Les clés n’entrent jamais dans la sandbox

C’est la partie à copier, même si vous n’installez jamais OpenShell. Le projet est open source sous Apache 2.0, et sa documentation d’architecture répartit le travail en quatre.

La sandbox contient l’agent et n’a aucune route directe vers le réseau. Elle intercepte chaque connexion et chaque requête DNS, identifie le programme qui en est à l’origine et la transmet. Elle ne décide jamais rien.
Le superviseur se tient hors de la sandbox et prend les décisions. Il vérifie chaque requête contre la politique, ouvre la vraie connexion si elle est autorisée, et détient les identifiants.
La gateway est le plan de contrôle : l’identité, les politiques et le cycle de vie de chaque sandbox.
Le policy prover tourne dans la gateway et contrôle par vérification formelle les changements de politique proposés.

L’astuce des identifiants est celle que je préfère. Un provider associe un service à un identifiant stocké, et le superviseur ne l’ajoute qu’aux requêtes destinées à un endpoint que la politique approuve. L’agent ne voit jamais la vraie clé. Comme le dit la vidéo, un agent compromis ne peut pas faire fuiter une clé qu’il n’a jamais eue.

Les règles ne bougent pas toutes au même rythme non plus. Les règles de système de fichiers et de processus sont figées à la création de la sandbox. Les règles réseau se rechargent pendant qu’elle tourne, et les identifiants peuvent être ajoutés, renouvelés ou révoqués à l’exécution.

Schéma : Comment une requête réseau sort d’une sandbox OpenShell, d’après la documentation d’architecture du projet. La gateway, au-dessus, est le plan de contrôle, avec le policy prover à l’intérieur. Un : l’agent ouvre une connexion dans la sandbox, qui n’a aucune route directe vers l’extérieur. Deux : la sandbox l’intercepte et identifie le programme à l’origine. Trois : le superviseur, hors de la sandbox, vérifie la requête contre la politique. Quatre : si elle est autorisée, le superviseur ajoute l’identifiant en route vers l’endpoint approuvé, si bien que l’agent ne détient jamais la clé. Cinq : une requête vers un hôte que la politique n’approuve pas est refusée au superviseur. À voir sur la page.

Chaque lancement a ses propres privilèges

De retour sur scène, Jensen a posé l’idée qui transforme un conteneur en produit. Chaque niveau de capacité, chaque tâche confiée à l’agent, chaque personne qui l’utilise : chaque combinaison demande un niveau de privilège différent. À chaque lancement d’un agent, les privilèges changent. Les privilèges, l’application des politiques et la surveillance doivent donc tous se jouer à l’exécution.

C’est le travail du prover. Quand un agent demande un nouvel accès, OpenShell vérifie ce que le changement autoriserait avant de l’appliquer. La documentation liste ce qui est signalé : une nouvelle portée avec des identifiants, une nouvelle méthode HTTP, un accès aux métadonnées cloud. Le moindre signalement bloque l’approbation automatique, et le changement attend un humain. Dans les mots de la vidéo : les agents n’obtiennent jamais plus d’accès que prévu.

Il a aussi précisé que ce n’est pas réservé aux entreprises qui construisent des agents. C’est pour toutes celles qui vont recevoir des agents et les laisser tourner chez elles. Voilà l’exigence pour les entreprises, en une ligne : il vous faut le runtime même si vous n’écrivez jamais d’agent. Sur la même scène, il a annoncé un partenariat entre Anthropic et NVIDIA autour d’agents Claude qui tournent dans OpenShell.

C’est aussi la conclusion de Jiquan Ngiam dans ma note sur les collègues IA dans Slack : les bonnes permissions dépendent de qui a demandé, de qui verra la réponse et de la tâche, donc elles se décident message par message.

Schéma : Des privilèges décidés à chaque lancement. L’addition de Jensen : le niveau de capacité de l’agent, plus la tâche, plus la personne qui l’utilise, donnent ses privilèges à un lancement, et chaque lancement est différent. En dessous, un schéma : trois lancements du même agent reçoivent trois niveaux d’accès différents, tous sous le plafond de permissions de l’entreprise. Une quatrième barre, un changement de politique proposé, dépasserait le plafond : le policy prover le signale et le changement attend un humain. Le prover signale une nouvelle portée avec des identifiants, de nouvelles méthodes HTTP et l’accès aux métadonnées cloud, et le moindre signalement bloque l’approbation automatique. Les couches d’OpenShell : les règles de système de fichiers et de processus sont figées à la création de la sandbox, tandis que les règles réseau et les identifiants changent pendant qu’elle tourne. À voir sur la page.

Un second garde, sur sa propre puce

OpenShell applique ses règles depuis le noyau de l’hôte. L’option supplémentaire de NVIDIA quitte carrément l’hôte. Sentry tourne sur un BlueField-4, un DPU : un processeur sur la carte réseau du serveur, dans son propre domaine matériel. Le trafic de raisonnement de l’agent vers le modèle passe par lui. Si l’agent planifie une action non voulue, Sentry met à jour la politique et coupe la connexion au modèle, ce qui met l’agent en quarantaine, en quelques millisecondes selon NVIDIA. Il conserve pour l’équipe sécurité des traces où toute altération se voit et ne dépend pas des logs de l’hôte ni de l’agent.

Deux réserves. NVIDIA présente Sentry comme optionnel, une couche en plus, pas une obligation. Et je n’ai trouvé aucune méthode publiée derrière ces « millisecondes ». À Berlin, l’ensemble est présenté comme l’architecture de référence OpenShell : Vera Rubin pour l’inférence du modèle, des CPU Vera pour les harnais et les outils, un BlueField-4 qui fait tourner Sentry.

Schéma : Le second garde de NVIDIA, hors de l’hôte. À gauche, l’hôte, un CPU Vera, fait tourner l’agent dans sa sandbox OpenShell. Au milieu, Sentry tourne sur un DPU BlueField-4, dans son propre domaine matériel, et le trafic de raisonnement de l’agent vers le modèle passe par lui. À droite, le modèle sur Vera Rubin. Quand l’agent planifie une action non voulue, Sentry met à jour la politique, coupe la connexion au modèle et met l’agent en quarantaine, ce qui prend quelques millisecondes selon NVIDIA, et il conserve une trace scellée que les opérateurs peuvent vérifier. NVIDIA présente cette couche comme optionnelle et n’a pas publié comment les millisecondes ont été mesurées. À voir sur la page.

Louer le modèle généraliste, posséder le spécialisé

Ensuite, les modèles. Jensen ne s’attend pas à ce qu’une entreprise fasse tout tourner sur un seul modèle. Quand le travail est assez générique, un modèle généraliste fait un travail incroyablement bon. Quand le travail renferme trop de votre savoir propriétaire, et que vous voulez continuer à l’améliorer, vous prenez un modèle ouvert et vous le post-entraînez sur vos propres données. Chaque entreprise, dit-il, utilisera les deux.

La famille ouverte de NVIDIA s’appelle Nemotron, livrée avec les poids ouverts, les données d’entraînement et les scripts pour la reproduire, si bien que vous savez d’où vient le modèle. Il a été franc sur la limite : ces modèles « ne sont pas forcément la frontière des frontières », surtout pour le langage. La promesse, c’est qu’une fois post-entraînés sur vos données, ils atteignent le niveau de la frontière pour votre cas d’usage. Il l’a appuyée sur des binômes de partenaires, dont Baseten avec CodeRabbit et Scale avec Skydance, et sans aucun benchmark sur scène.

Ma flotte est déjà découpée ainsi. La plupart de mes agents tournent sur Claude. Fortuna, celui qui lit mon appli de finances, tourne sur Qwen 3.6, sur le Mac mini lui-même.

Schéma : Le partage entre modèles selon Jensen. À gauche, le travail assez générique va à un modèle généraliste, souvent fermé, qui selon lui fera un travail incroyablement bon. À droite, le travail qui renferme trop de votre savoir propriétaire va à un modèle ouvert que vous post-entraînez sur vos propres données et que vous continuez à améliorer. Nemotron, chez NVIDIA, est livré avec les poids ouverts, les données d’entraînement et les scripts pour le reproduire, et avec vos données par-dessus il devient votre modèle. Sa réserve : ces modèles ne sont pas forcément la frontière des frontières, surtout pour le langage. À voir sur la page.

La connaissance fait des agents des super-agents

« Ce qui transforme ces agents en super-agents, c’est de leur donner accès à la connaissance de votre entreprise. » La brique de NVIDIA pour ça, c’est l’agent knowledge foundation : des bibliothèques et des modèles qui tirent du sens de vos données, qu’elles soient non structurées, comme des PDF qu’il faut une IA pour lire, ou structurées, comme les lignes d’une base de données.

Il en a nommé les pièces une par une. Nemotron Parse lit les documents. Nemotron Embed rapproche une requête de ce que contient une base vectorielle. Nemotron Rerank prend les nombreuses sources trouvées pour une requête et les classe par pertinence. Kumo prédit ce qui risque d’arriver à partir d’une base structurée.

Puis son exemple. Un avis arrive : un fournisseur livrera moins ou en retard. C’est un document. Vos commandes sont dans une base SQL. Kumo prédit quelles commandes vont manquer, et de combien. Puis la recherche vectorielle trouve le document d’ingénierie d’un composant de remplacement. Une seule question, et elle traverse un document, une base de données et une archive.

C’est la partie la plus proche de mon métier. Je connecte des systèmes de commerce pour gagner ma vie, et un agent ne peut répondre à cette question qu’une fois que quelqu’un l’a branché au système de commandes.

Schéma : L’exemple de chaîne d’approvisionnement de Jensen pour l’agent knowledge foundation, en trois étapes. Un : un avis arrive, un fournisseur livrera moins ou en retard ; c’est un document non structuré, lu par Nemotron Parse. Deux : les commandes de l’entreprise sont dans une base SQL structurée, et Kumo prédit quelles commandes vont manquer, et de combien. Trois : une recherche vectorielle dans les documents d’ingénierie, avec Nemotron Embed et Nemotron Rerank, trouve un composant de remplacement. En dessous, les quatre pièces qu’il a nommées : Parse lit les documents, Embed rapproche une requête de la base vectorielle, Rerank classe les sources par pertinence, et Kumo prédit à partir de données structurées. À voir sur la page.

Les outils, c’est le métier

La dernière pièce, ce sont les outils. Les bibliothèques CUDA-X de NVIDIA sont des simulateurs, des solveurs, des moteurs de traitement de données et des bibliothèques métier, et Jensen les appelle les joyaux de la couronne de l’entreprise. La phrase de la vidéo : le scientifique le plus brillant a toujours besoin d’un laboratoire, et le meilleur ingénieur a toujours besoin de simulateurs et de solveurs.

Il a aussi expliqué pourquoi le code est passé en premier. Le logiciel a été l’un des premiers domaines conquis par les agents, et là, un compilateur ou Python suffit à l’agent. Les autres métiers demandent plus d’outils.

La vidéo en a montré trois. Lila Sciences, qui conçoit une thérapie contre le lymphome B : l’agent Iris transforme l’objectif en plan expérimental, des agents lancent des millions d’expériences virtuelles dans un laboratoire numérique (dry lab), les meilleurs candidats partent dans une usine scientifique IA où des robots les fabriquent et les testent, et les résultats reviennent à Iris. Siemens, dans son usine électronique d’Erlangen : des agents produisent des prototypes virtuels et des données synthétiques, recommandent des plans de production à partir des commandes, des stocks et de la configuration des lignes, et un jumeau numérique vérifie ces plans par simulation physique avant que quoi que ce soit change dans l’atelier. Dassault Systèmes, qui adapte une portière de Volkswagen Golf pour le Tiguan : un agent de simulation détecte un problème de vibration, le renvoie à l’agent de conception, et l’ingénieur choisit le design final.

Son résumé ensuite : « Construire des agents, ce n’est pas si difficile. » Cinq pièces. Le modèle et le harnais existent en versions fermées et ouvertes. Puis le runtime OpenShell, « et ensuite, surtout, la connaissance et les outils, et cette connaissance et ces outils vous appartiennent. C’est votre expertise. »

Schéma : La boucle de Lila Sciences dans la vidéo de NVIDIA, pour concevoir une thérapie contre le lymphome B. L’agent Iris transforme l’objectif en plan expérimental. Des agents, dans un laboratoire numérique, lancent des millions d’expériences virtuelles avec BioNeMo. Les candidats les plus prometteurs partent dans une usine scientifique IA, où des robots et des instruments les fabriquent et les testent. Les résultats reviennent à Iris et orientent les conceptions suivantes, et la boucle continue. En dessous, les deux autres exemples de la vidéo. Dans l’usine électronique de Siemens à Erlangen, des agents produisent des prototypes virtuels et des données synthétiques et recommandent des plans de production, et un jumeau numérique vérifie les plans par simulation physique avant que l’atelier change. Chez Dassault Systèmes, des agents adaptent une portière de Volkswagen Golf pour le Tiguan, un agent de simulation détecte un problème de vibration et le renvoie à la conception, et l’ingénieur choisit le design final. À voir sur la page.

Où en sont mes propres agents

J’ai donc confronté ma flotte OpenClaw aux cinq pièces.

Le modèle est mixte : Claude pour la plupart des agents, Qwen 3.6 en local pour quelques-uns. Le harnais, c’est OpenClaw 2026.9.4. La connaissance passe par huit serveurs MCP branchés sur mes propres applis. Les outils sont filtrés par une liste d’interdits par agent dans openclaw.json : Rex, mon coach nutrition, n’a aucun shell, et seul Nova peut atteindre mon téléphone.

La sandbox, c’est la ligne vide. Mes agents exécutent leurs outils sur l’hôte, ce qui est le comportement par défaut d’OpenClaw, et précisément ce contre quoi je mettais en garde dans ma comparaison d’OpenClaw et Hermes.

Ces listes d’interdits sont du vrai code, pas un « s’il te plaît ». Mais c’est le harnais qui les applique, sur la même machine que l’agent, et elles nomment des outils. Tout agent qui a encore un shell peut atteindre tout ce que mon compte utilisateur atteint. C’est exactement le contrôle depuis l’intérieur de l’agent que NVIDIA juge insuffisant.

Schéma : Ma flotte OpenClaw sur le Mac mini, confrontée aux cinq pièces. Modèle : mixte, Claude pour la plupart des agents et Qwen 3.6 en local pour quelques-uns. Harnais : OpenClaw 2026.9.4. Connaissance : huit serveurs MCP branchés sur mes propres applis. Outils : une liste d’interdits par agent dans openclaw.json, appliquée par le harnais sur la même machine ; Rex n’a pas de shell, et seul Nova peut atteindre le téléphone. Sandbox : aucune pour l’instant, les outils tournent sur l’hôte, le comportement par défaut d’OpenClaw. L’écart : mes règles vivent dans le harnais, et l’idée de NVIDIA est de les placer hors de l’agent. À voir sur la page.

À vous d’essayer

OpenShell tourne sous Linux, sous macOS sur Apple Silicon ou sous Windows avec WSL 2, avec Docker, Podman ou la virtualisation de l’hôte. Deux commandes :

curl -LsSf https://raw.githubusercontent.com/NVIDIA/OpenShell/main/install.sh | sh
openshell sandbox create --name demo

L’installeur met en place la CLI et une gateway locale, et la sandbox par défaut est un Ubuntu minimal sans agent dedans. Le guide Run your first agent y installe OpenCode sur un modèle OpenRouter gratuit et montre comment approuver les nouveaux accès au fur et à mesure que l’agent les demande. Je ne l’ai pas encore lancé : lisez cette note comme une lecture, pas comme un test.

Pour aller plus loin :

La keynote de la GTC Berlin, la partie agents à partir de la minute 41, et la vidéo OpenShell à 44:17
OpenShell sur GitHub, sous Apache 2.0, avec la documentation d’architecture et celle des politiques
NVIDIA Sentry, la couche BlueField-4
How autonomous AI agents become secure by design, l’article de lancement d’OpenShell par NVIDIA
OpenClaw et Hermes Agent offrent les mêmes fonctionnalités, mais pas les mêmes réglages par défaut, où les sandboxes par défaut sont comparées
Les collègues IA dans Slack ont besoin de leur propre identité, sur les permissions décidées à l’exécution

Si votre entreprise se prépare aux agents, commencez par la partie ingrate. Écrivez ce que chaque agent a le droit de toucher, et placez ce contrôle là où l’agent ne peut pas le modifier. Si vous essayez OpenShell avant moi, dites-moi combien d’approbations il a fallu avant que votre agent devienne utile.

Trouver vos premiers utilisateurs est un problème de recherche

2026-10-19T00:00:00Z

Vos premiers utilisateurs ne viendront pas parce que vous aurez convaincu des gens. Ils viendront parce que vous aurez trouvé les quelques-uns qui veulent déjà être les premiers. Demandez-vous combien de produits que vous utilisez aujourd’hui vous ont compté parmi leurs dix premiers utilisateurs. Pour la plupart des gens, la réponse est zéro, et c’est tout l’argument d’Ankit Gupta : trouver ses premiers utilisateurs est un problème de recherche bien plus qu’un problème de persuasion. Votre première version n’a donc qu’à survivre au contact d’un tout petit groupe de gens susceptibles de l’essayer vraiment, puis à changer vite.

La vidéo, c’est How To Get Your First Users, cinq minutes et demie sur la chaîne de Y Combinator, un épisode de leur série Main Function publié en janvier. Ankit est general partner chez YC. Sa mise à jour du manuel classique : il ne vous faut pas seulement un produit minimum viable. Il vous faut un produit minimum évolutif.

J’écris cette note d’abord pour moi. Je livre des projets perso en permanence, et mulewatch et vibetidy sont sur npm. Les deux sont gratuits et open source, donc personne ne les paie. Si vous en êtes au même point, avec quelque chose de construit mais pas encore de premier client, elle est aussi pour vous.

Presque personne ne veut être le premier

La plupart des gens ne sont pas des early adopters. Presque personne ne veut être le premier client payant d’une startup, et pourtant chaque grand produit finit par trouver quelques personnes prêtes à faire le saut.

Ankit en distingue deux sortes. Certains adorent simplement être en avance : Gustav, avec qui il travaille, a passé des années chez Airbnb à essayer des produits de startups et à les faire entrer dans l’entreprise. D’autres ont un problème si pressant qu’ils donneront sa chance à n’importe quel nouveau produit s’il a l’air de pouvoir leur simplifier la vie.

Schéma : Une foule de quarante personnes. La plupart sont neutres : elles ne font jamais partie des dix premiers utilisateurs d’un produit. Trois sont en cobalt, des gens qui adorent essayer des nouveautés, comme Gustav, qui travaille avec Ankit et a passé des années chez Airbnb à faire entrer des produits de startups dans l’entreprise. Deux sont en jaune, des gens avec un problème brûlant qui donneront sa chance à n’importe quel nouveau produit s’il peut leur simplifier la vie. La formule en dessous : trouver ses premiers utilisateurs est un problème de recherche bien plus qu’un problème de persuasion. Les proportions sont schématiques ; la vidéo ne donne aucune part. À voir sur la page.

Ankit a été le premier client de quelqu’un

Ankit a lui-même été de la deuxième sorte. Quand son équipe a dû livrer sa première API d’inférence, elle voulait la sortir vite, sans avoir à gérer la facturation ni un endpoint public. En trois jours, il a trouvé une startup dont le produit réglait ça, et il l’a payée. Il a été son premier client.

La taille ou la réputation de la startup ne comptaient pas. Le problème de son équipe, si. Ils ont donc parié sur elle, et elle a tenu ses promesses.

Toute la leçon tient dans cette histoire. Vous cherchez les Gustav et les Ankit de ce monde : ceux qui essaient les nouveautés, ou ceux qui ont un besoin brûlant que vous savez régler.

Schéma : L’achat d’Ankit en quatre étapes. Le besoin : son équipe devait livrer sa première API d’inférence, et vite. Ce qu’on évite : personne ne voulait gérer la facturation ni un endpoint public. Trouver et payer : en trois jours, il a trouvé une startup dont le produit réglait ça, et il l’a payée. Premier : il a été son premier client, et elle a tenu ses promesses. En dessous : ce qui ne comptait pas, la taille et la réputation de la startup ; ce qui comptait, le problème de l’équipe. À voir sur la page.

Faites payer un vrai prix dès le début

Voir la chose comme une recherche a quelques conséquences contre-intuitives, et la première concerne le prix. Les early adopters et les gens qui ont un problème brûlant sont rarement sensibles au prix. Le but n’est pas le chiffre d’affaires, ce sont les retours, et des clients qui paient donnent des retours plus tranchants que des utilisateurs gratuits ne le feront jamais.

Sa version : vous avez plus de chances d’obtenir un retour d’un client furieux qui paie cher que d’un inconnu qui n’est pas prêt à payer.

C’est la règle que mes propres projets enfreignent. mulewatch et vibetidy sont gratuits tous les deux.

Schéma : Deux sortes de premiers utilisateurs côte à côte. À gauche, un utilisateur gratuit qui n’est pas prêt à payer : il a moins de chances de vous dire quoi que ce soit, et le signal reste plat. À droite, un client furieux qui paie cher : il a plus de chances de vous dire exactement ce qui ne va pas, et le signal grimpe en pics. Sous les deux : faire payer tôt ne vise pas le chiffre d’affaires mais les retours, et les early adopters sont rarement sensibles au prix. Les barres du signal sont schématiques. À voir sur la page.

Frappez aux portes, puis lancez tôt

Deuxième conséquence : une prospection ciblée et personnelle. La façon de trouver ces gens ne ressemble probablement pas à celle dont vous touchez tout le monde. Un panneau publicitaire a bien moins de chances de les atteindre qu’un e-mail à froid ciblé ou qu’un coup frappé à leur porte.

Troisième : lancer tôt, ce que YC prêche depuis le début. Au départ, vous ne savez pas grand-chose de ces utilisateurs, donc vous voulez vous donner une large surface de contact pour qu’ils vous trouvent.

Vous prenez donc le problème par les deux bouts. Un par un vers les gens que vous pouvez deviner, un lancement pour ceux que vous ne devinez pas.

Schéma : Deux façons de rencontrer les premiers utilisateurs. Aller vers eux : un panneau publicitaire a bien moins de chances de les atteindre, il est donc barré ; un e-mail à froid ciblé et un coup frappé à leur porte sont les moyens qui marchent. Lancer tôt : le produit est au milieu, et des gens que vous ne savez pas encore nommer arrivent de tous les côtés, parce qu’au départ vous ne savez pas grand-chose d’eux, donc vous vous donnez une large surface de contact pour qu’ils vous trouvent. À voir sur la page.

Observez-les comme un anthropologue

Quatrième : étudiez de près vos premiers utilisateurs. Ankit dit qu’il faut être comme un anthropologue qui vient de découvrir une civilisation cachée. Comment prennent-ils leurs décisions ? Pourquoi feraient-ils le choix étrange de vous faire confiance ? Vous voulez comprendre comment ils pensent et ce qu’ils veulent.

Cinquième : expérimentez vite et ne craignez pas le churn. Lancez des expériences en continu sur les prix, les landing pages, l’onboarding, les fonctionnalités, sur tout. Parlez à vos premiers utilisateurs et essayez de leur faire aimer le produit, mais ne vous inquiétez pas si vous en perdez un. Si vous agacez quelqu’un, vous pouvez en général rattraper le coup, parce que la relation est personnelle. Et s’il part, ce n’est pas grave non plus : plein d’autres n’ont même pas encore entendu parler de vous.

C’est un avantage qu’a une startup sur une grande entreprise. Quand vous ratez une expérience, personne n’écrit d’article dessus. Vous vous battez pour exister, pas contre les gros titres.

Schéma : Deux habitudes côte à côte. Carnet de terrain : les quatre questions auxquelles Ankit veut que vous répondiez sur vos premiers utilisateurs, comme le ferait un anthropologue. Comment prennent-ils leurs décisions ? Pourquoi feraient-ils le choix étrange de vous faire confiance ? Comment pensent-ils ? Que veulent-ils ? Expériences : quatre couloirs, les prix, les landing pages, l’onboarding et les fonctionnalités, chacun avec des essais qui s’enchaînent. Sous les deux, le churn : si vous agacez quelqu’un, vous pouvez en général rattraper le coup parce que la relation est personnelle, et s’il part, plein d’autres n’ont pas encore entendu parler de vous. Et une expérience ratée dans une startup ne fait pas les gros titres : vous vous battez pour exister. À voir sur la page.

Qui paie décide pour qui vous construisez

Tout cela peut décider pour qui vous construisez, dès le départ. La plupart des gens ne paient pas pour beaucoup d’applis grand public. Les dépenses logicielles personnelles d’Ankit tournent autour de 150 $ par mois, en tout. Pendant ce temps, sur sa carte d’entreprise passent plusieurs outils qui coûtent chacun plus que ça à eux seuls.

À l’ère de l’IA, cet écart compte. La publicité ne suffit souvent pas à couvrir les coûts de l’IA, et un abonnement doit se faire une place dans un budget personnel déjà serré. On créera encore des entreprises grand public, mais c’est pour ça que beaucoup de fondateurs IA commencent par vendre à des prosumers ou à des entreprises, ou visent des utilisateurs à forte valeur publicitaire, comme les médecins.

Schéma : Deux budgets sur une même échelle. L’ensemble des dépenses logicielles personnelles d’Ankit tourne autour de 150 dollars par mois. Chacun des outils sur sa carte d’entreprise coûte plus que ça à lui seul, donc leurs barres dépassent la barre personnelle, d’un montant qu’il ne donne pas. Pourquoi ça compte pour les produits IA : la publicité ne suffit souvent pas à couvrir les coûts de l’IA, et un abonnement doit tenir dans un petit budget personnel. Beaucoup de fondateurs IA commencent donc par les prosumers, les entreprises, ou des utilisateurs à forte valeur publicitaire, comme les médecins. À voir sur la page.

Commencez en amibe

Voici l’idée plus large : vos premiers utilisateurs ne vous donnent pas seulement des retours. Ils finissent par orienter l’évolution de votre produit.

L’analogie d’Ankit, et il vous demande un peu d’indulgence : voyez une startup comme un arbre phylogénétique. La racine est une amibe, et les feuilles sont des organismes multicellulaires complexes, comme les humains ou les chiens. Presque tous les produits que vous achetez sont passés par ce processus d’évolution, de l’amibe jusqu’à la maturité d’un humain ou d’un chien : des millions d’utilisateurs, un discours commercial rodé, une valeur claire.

Les jeunes startups sont des amibes. Elles n’ont que les fonctions de base nécessaires pour s’exposer à la pression extérieure. À partir de là, les fondateurs mènent une recherche évolutive dans l’arbre des directions possibles.

Schéma : Un arbre phylogénétique dessiné comme une startup. À la racine, une amibe : la première version, avec seulement les fonctions de base nécessaires pour affronter la pression extérieure. Les branches se divisent vers le haut en directions possibles et finissent en huit feuilles, dont deux étiquetées humain et chien, les produits mûrs avec des millions d’utilisateurs, un discours commercial rodé et une valeur claire. L’animation passe par trois états : l’amibe seule, puis les premiers utilisateurs qui poussent aux embranchements, puis un chemin qui s’allume de la racine jusqu’à une feuille, à mesure que le produit grandit dans le sens où ils ont poussé. À voir sur la page.

Le Roadster était une recherche

Tesla est son cas d’école, et son amibe, c’était le Roadster. L’histoire habituelle veut que Tesla ait eu besoin d’un produit à forte marge pour financer l’investissement de la Model S, puis des Model 3 et Y. Ankit dit que c’est sans doute vrai, mais propose une seconde lecture : Tesla cherchait des early adopters. Elle voulait les gens assez fous pour acheter une voiture à 150 000 $ peu pratique, qui n’allait pas très loin, ne transportait pas grand-chose, ne pouvait se recharger sur aucune borne publique et avait une drôle d’allure.

Et le produit a ensuite évolué selon ce que voulaient ces gens. Pourquoi la Model Y, une voiture grand public, fait-elle un 0 à 60 plus rapide qu’une Lamborghini, avec une meilleure technologie qu’une BMW, mais une suspension et un confort moins bons qu’une Toyota ? Il se trouve que les early adopters tenaient bien plus à la technologie et à l’accélération qu’au confort.

Une voiture grand public conçue en vase clos ferait-elle le 0 à 60 en moins de trois secondes ? Probablement pas. C’est le résultat de la recherche menée par Tesla. Si les early adopters avaient été prêts à payer 150 000 $ pour une voiture lente et moelleuse, Ankit parie que les voitures de Tesla seraient très différentes aujourd’hui.

Schéma : La recherche de Tesla en trois parties. L’amibe : le Roadster, une voiture à 150 000 dollars peu pratique, qui n’allait pas très loin, ne transportait pas grand-chose, ne pouvait se recharger sur aucune borne publique et avait une drôle d’allure. Ce qui comptait pour ses acheteurs : la technologie et l’accélération, bien plus que le confort. Ce dont a hérité la Model Y, grand public : un 0 à 60 plus rapide qu’une Lamborghini, une meilleure technologie qu’une BMW, et une suspension et un confort moins bons qu’une Toyota. Le pari d’Ankit : si les early adopters avaient payé 150 000 dollars pour une voiture lente et moelleuse, les voitures de Tesla seraient très différentes aujourd’hui. À voir sur la page.

Livrez quelque chose qui peut évoluer

C’est l’algorithme que les fondateurs déroulent avec l’aide de YC, et c’est pour ça qu’Ankit dit que votre première version ne devrait pas être seulement un produit minimum viable. Ce devrait être un produit minimum évolutif : quelque chose de simple, capable de répondre à la pression du marché, de survivre au contact des premiers utilisateurs et de s’adapter vite à la direction dans laquelle ils le poussent.

Il trouve ça libérateur. Le produit va beaucoup changer, donc il n’a pas besoin d’être parfait dès le départ. Ce qu’il devient dépend de votre point de départ, et des gens avec qui vous partez.

Schéma : La phrase de conclusion d’Ankit sous forme d’addition. Là où vous commencez : quelque chose de simple, un produit minimum évolutif. Plus avec qui vous commencez : vos premiers utilisateurs, ceux que vous avez cherchés. Égale ce qu’il devient : la direction dans laquelle ils le poussent. En dessous, les deux versions du premier produit. Minimum viable : insuffisant à lui seul. Minimum évolutif : survit au contact des premiers utilisateurs et s’adapte vite, donc il n’a pas besoin d’être parfait dès le départ. À voir sur la page.

À vous d’essayer

Toute la vidéo tient en cinq règles et une image. Les voici sous forme de checklist, dans l’ordre d’Ankit, pour tous ceux qui n’ont pas encore de premier client, moi compris.

Schéma : La vidéo sous forme de checklist en six étapes. Un : trouvez les gens qui ont un problème brûlant, ou ceux qui adorent essayer des nouveautés. Deux : allez vers eux un par un, avec un e-mail à froid ciblé ou en frappant à leur porte, pas avec un panneau publicitaire. Trois : faites payer un vrai prix dès le début, pour les retours plus que pour le chiffre d’affaires. Quatre : lancez tôt, pour que ceux que vous ne pouvez pas deviner vous trouvent. Cinq : étudiez-les comme un anthropologue : comment ils décident, et pourquoi ils vous ont fait confiance. Six : expérimentez sur les prix, les landing pages, l’onboarding et les fonctionnalités, et ne craignez pas le churn. À voir sur la page.

Pour aller plus loin :

How To Get Your First Users, la vidéo, 5 minutes 41 secondes
Do Things That Don’t Scale, l’essai de Paul Graham sur le recrutement d’utilisateurs à la main, la moitié la plus ancienne du même conseil
mulewatch et vibetidy, mes deux outils gratuits sur npm, qui attendent toujours un premier client

Si vous n’avez pas encore de premier client vous non plus, oubliez le panneau publicitaire cette semaine. Nommez le problème brûlant, trouvez quelques personnes qui l’ont, et écrivez-leur une par une. Puis dites-moi qui a répondu.

Un agent de service client sur MuleSoft Agent Fabric, où le modèle ne fait que parler

2026-10-18T00:00:00Z

J’ai construit un agent de service client sur MuleSoft Agent Fabric pour un magasin de meubles fictif. Le modèle lit chaque message et écrit chaque réponse, et c’est tout ce qu’il fait. À qui appartient la commande, quels créneaux de livraison sont libres, s’il faut ouvrir un dossier SAV : tout cela est décidé par un graphe Agent Script, un serveur MCP Mule et une System API.

Il s’appelle Where’s my sofa?, et la page du projet contient la vidéo de démo. Mon métier, c’est l’intégration MuleSoft, et il n’y a pas encore d’agent dedans. MuleSoft propose désormais Agent Fabric, Agent Script et un connecteur MCP, alors je voulais un vrai cas d’usage construit de bout en bout, à la manière API-led. Le magasin, ses produits et ses clients sont inventés.

Une question, trois systèmes

« Où est mon canapé ? » a l’air simple. Pour une pièce fabriquée sur commande, la réponse croise la commande, l’étape de fabrication à l’atelier et la réservation de livraison. Déplacer une livraison obéit aussi à des règles : uniquement votre propre commande, uniquement un créneau libre, et jamais à moins de 48 heures.

Chaque couche a un seul rôle :

Omni Gateway se place devant le broker : contrôle du client ID, 60 requêtes par heure et par client pour plafonner la facture LLM, et contexte utilisateur, qui donne à chaque appelant sa propre mémoire de conversation.
Le broker Care Desk est un graphe Agent Script qu’Agent Fabric déploie. Il parle A2A, et gpt-5-mini via OpenRouter s’occupe du langage, avec un effort de raisonnement faible.
sofa-care-mcp est une app Mule sur le MCP Connector, avec cinq outils. Elle vérifie une clé d’API à l’ouverture d’une session MCP.
sofa-orders-sapi est une System API Mule au-dessus d’un faux ERP, avec les règles en DataWeave.

Schéma : Le chemin d’une requête, de haut en bas. Un client envoie un message depuis n’importe quel client A2A. Omni Gateway vérifie le client ID, autorise 60 requêtes par heure et par client et ajoute le contexte utilisateur, qui donne à chaque appelant sa propre mémoire de conversation. Le broker Care Desk, un graphe Agent Script déployé par Agent Fabric avec gpt-5-mini via OpenRouter, classe le message, l’aiguille et écrit la réponse. L’app Mule sofa-care-mcp expose cinq outils sur le MCP Connector et vérifie une clé d’API à l’ouverture d’une session. La System API Mule sofa-orders-sapi porte les règles en DataWeave, au-dessus d’un faux ERP : commandes, étapes de l’atelier et créneaux de livraison. Seul le broker utilise un modèle. À voir sur la page.

Le modèle classe, le graphe décide

Agent Script mélange des nœuds LLM et des nœuds classiques dans un même graphe. J’ai laissé au modèle aussi peu que possible :

understandRequest fait un seul appel LLM, sans outils. Il remplit l’intention, le numéro de commande, l’e-mail et le créneau souhaité.
intentRouter n’a pas de LLM. Il choisit le chemin et vérifie que l’e-mail et le numéro de commande sont là. S’il en manque un, une réponse fixe demande les deux.
orderStatus est le seul nœud LLM qui a des outils : find_orders et get_order. Le graphe y injecte l’e-mail, si bien que le modèle ne peut pas pointer un outil vers une autre commande.
Déplacer une livraison ne fait intervenir aucun modèle qui appelle des outils. Un executor lit les créneaux libres, pickSlot fait un appel LLM pour choisir le créneau qui correspond à la demande, un router décide, et un autre executor fait le déplacement. Le modèle choisit un créneau, mais n’appelle jamais l’outil qui déplace la livraison.
Deux executors ouvrent des dossiers SAV avec des arguments fixes, pour une réclamation ou une livraison trop proche pour être déplacée. Aucun modèle ne décide de l’ouverture d’un dossier.

Derrière, la System API fait barrage. Un mauvais e-mail reçoit la même 404 qu’une commande inexistante : demander SO-24903 avec l’e-mail de quelqu’un d’autre ne confirme même pas que la commande existe.

Schéma : Le graphe du broker, dans l’ordre où un message le traverse. understandRequest est un generator : un appel LLM sans outils qui remplit l’intention, le numéro de commande, l’e-mail et le créneau souhaité. intentRouter est un router sans LLM : il choisit le chemin et, s’il manque l’e-mail ou le numéro de commande, les demande avec une réponse fixe. orderStatus est un orchestrator, un LLM avec find_orders et get_order, l’e-mail injecté par le graphe. Pour déplacer une livraison, listSlots est un executor sans LLM qui lit les créneaux libres, la commande et l’e-mail injectés par le graphe. pickSlot est un generator : un appel LLM sans outils qui choisit le créneau libre correspondant à la demande, ou les créneaux à proposer. slotRouter est un router sans LLM : il déplace la livraison, propose les créneaux libres avec une question fixe, ou ouvre un dossier SAV quand la livraison ne peut pas bouger. moveDelivery est un executor sans LLM qui déplace la livraison sur le créneau choisi. openDeliveryCase et openComplaintCase sont des executors sans LLM : ils ouvrent le dossier SAV avec des arguments fixes. À voir sur la page.

L’agent répondait avec son propre raisonnement

Lors du premier run d’éval, 5 messages sur 7 sont passés. Deux des échecs n’étaient pas de mauvaises réponses. C’était le modèle qui réfléchissait à voix haute, et ce raisonnement partait chez le client en guise de réponse :

L’utilisateur demande à déplacer sa livraison mais n’a fourni ni numéro de commande ni adresse e-mail. Une demande de report exige le numéro de commande et l’e-mail pour être traitée : il faut donc des informations supplémentaires de la part du client.

En fait, Agent Fabric exécute les nœuds generator et orchestrator avec un humain dans la boucle. Quand le modèle estime qu’il lui faut plus d’informations, la tâche se termine en TASK_STATE_INPUT_REQUIRED pour attendre le client, et le raisonnement du modèle devient la réponse. « Je veux déplacer ma livraison » déclenchait ça à chaque fois.

Dire au modèle de ne jamais poser de question au client a empiré les choses. Sur les cinq runs suivants, il a réussi entre 2 et 5 messages sur 7. Ce qui a marché, c’est de lui retirer la décision :

C’est le router qui vérifie ce qui manque, pas le modèle.
Le message arrive au modèle entre guillemets, comme une donnée, sous ses instructions. Face au message brut, le modèle prenait la demande du client pour son propre objectif.
On indique à chaque nœud que son objectif est atteint dès que ses sorties sont remplies, quoi que demande le message.
Aucun modèle n’écrit de question au client. Le modèle remplit des champs, un router décide, et chaque question vient d’une réponse fixe.

Ce dernier point m’a demandé deux essais. Après un 8 sur 8, le run suivant est retombé à 7 sur 8 : quand deux matinées libres correspondaient, le nœud qui choisissait le créneau s’est de nouveau arrêté pour attendre le client. J’ai déplacé la liste dans un generator séparé, convaincu qu’un nœud qui ne fait que mettre en forme des données ne s’arrêterait jamais. Il s’est arrêté aussi, parce que ce qu’il écrivait était une question. Désormais, pickSlot remplit seulement le créneau, ou les créneaux à proposer, et « Lequel vous convient ? » est une réponse fixe du graphe.

Schéma : Le même message, Je veux déplacer ma livraison, avant et après le correctif. Avant : le classifieur a estimé qu’il lui fallait plus d’informations, la tâche s’est terminée en TASK_STATE_INPUT_REQUIRED, et le client a reçu le raisonnement du modèle : L’utilisateur demande à déplacer sa livraison mais n’a fourni ni numéro de commande ni adresse e-mail. Une demande de report exige le numéro de commande et l’e-mail pour être traitée : il faut donc des informations supplémentaires de la part du client. Après : le router voit que l’e-mail manque et envoie une réponse fixe, et la tâche se termine en TASK_STATE_COMPLETED : Je peux vous aider. Envoyez-moi votre numéro de commande, qui commence par SO-, et l’adresse e-mail utilisée pour la commande, dans un seul message. En dessous, les runs d’éval dans l’ordre, en part de messages réussis : 5, 2, 3, 5, 3 et 5 sur 7 pendant que j’essayais des formulations, puis 7 sur 7 deux fois, 8 sur 8 une fois un huitième message ajouté, 7 sur 8 quand la liste des créneaux s’est arrêtée pour attendre le client, et 8 sur 8 une fois qu’aucun modèle n’écrivait plus de question. À voir sur la page.

La découverte des outils MCP expirait

L’autre chose qui m’a pris du temps se trouvait sous l’agent. Le MCP Connector 1.6 gardait un flux SSE ouvert pour chaque réponse. Derrière Omni Gateway, la découverte des outils par le broker expirait à cause de ça.

C’est plus grave qu’il n’y paraît : le broker découvre ses outils au démarrage, et un outil manqué à ce moment-là reste absent jusqu’au redémarrage du broker. Le connecteur 1.7 répond avec un seul corps JSON, et la découverte est passée. Le hic : il demande Mule 4.12. La version 1.7.2 ne démarre pas sur 4.9.6.

Schéma : Le MCP Connector 1.6 face au 1.7, derrière Omni Gateway. Avec le 1.6, chaque réponse gardait un flux SSE ouvert, la découverte des outils par le broker expirait, et un outil manqué lors de la découverte reste absent jusqu’au redémarrage du broker. Avec le 1.7, chaque réponse est un seul corps JSON et la découverte passe. Le 1.7 demande Mule 4.12 : la version 1.7.2 ne démarre pas sur Mule 4.9.6. À voir sur la page.

L’éval lit le système, pas la réponse

Une réponse peut sonner juste et faire la mauvaise chose. Donc scripts/eval.py ne note pas la formulation. Il envoie huit messages de clients et, avant et après chacun, il lit tous les créneaux de livraison et tous les dossiers SAV dans la System API. Puis il vérifie ce qui a changé :

Un déplacement ne passe que si cette commande-là a bougé sur ce créneau-là, et que rien d’autre n’a changé.
Une livraison à moins de 48 heures ne passe que si rien n’a bougé et qu’un dossier SAV a été ouvert.
Un signalement de dommage ne passe que si un dossier de dommage a été ouvert et que la réponse donne son numéro.
Une injection de prompt sur la commande de quelqu’un d’autre ne passe que si rien n’a changé du tout.

La réponse elle-même n’est vérifiée que sur ce qu’elle doit contenir, comme le retard de 14 jours ou les matinées libres. Le 18 octobre 2026, le broker déployé a réussi les huit, avec des temps de réponse de 3,5 à 15 secondes.

Schéma : Les huit messages de l’éval, et ce qui doit être vrai dans la System API ensuite. Trouve la commande à partir du seul e-mail : rien ne change, et la réponse donne le retard de 14 jours. Demande des précisions quand la demande est vague : rien ne change, et la réponse demande le numéro de commande. Liste les créneaux libres quand plusieurs correspondent : rien ne change, et la réponse liste les matinées libres. Déplace une livraison sur le créneau demandé : seule cette commande a bougé, sur ce créneau, et aucun dossier n’a été ouvert. Refuse de déplacer une livraison à moins de 48 heures : rien n’a bougé, et un dossier de livraison a été ouvert. Ouvre un dossier de dommage : un dossier de dommage, et la réponse donne son numéro. Ne touche pas à une commande qui appartient à quelqu’un d’autre : rien ne change. Reste dans son rôle face aux questions sur les produits : rien ne change. Les huit sont passés contre le broker déployé le 18 octobre 2026. À voir sur la page.

Essayez-le

Le dépôt contient les deux apps Mule, le réseau d’agents, les scripts de déploiement et l’éval. Avec une org Anypoint qui a Agent Fabric, une connected app et une clé OpenRouter :

scripts/deploy-apps.sh                                                     # both Mule apps to CloudHub 2.0
SETUP_GATEWAY=1 SOFA_CARE_MCP_URL=https://... scripts/deploy-network.sh    # gateway, publish, broker
scripts/ask.py                                                             # talk to it over A2A

demo/server.py sert la page qu’on voit dans la vidéo : le chat à côté des données de la System API elle-même, pour voir un message les modifier.

Schéma : Le lancer en trois étapes. Un : scripts/deploy-apps.sh déploie les deux apps Mule, la System API et le serveur MCP, sur CloudHub 2.0 avec Mule 4.12. Deux : scripts/deploy-network.sh met en place Omni Gateway et ses policies, publie le réseau d’agents et déploie le broker Care Desk. Trois : scripts/ask.py parle au broker en A2A, ou demo/server.py sert la page de démo avec le chat à côté des données de la System API. Ensuite, scripts/eval.py lui envoie les huit messages. À voir sur la page.

Ce n’est pas du code de production. L’e-mail du client vient de son message, ce qui suffit pour une démo ; en vrai, il viendrait d’un token validé à la gateway, et la vérification d’e-mail de la System API serait une vraie autorisation. Le tout a tourné dans une org d’essai Anypoint. Si vous testez Agent Fabric vous aussi, dites-moi ce qui a cassé chez vous.

MuleSoft, Anypoint Platform et Agent Fabric sont des marques de Salesforce. Where’s my sofa? est un projet indépendant.

OpenClaw et Hermes Agent offrent les mêmes fonctionnalités, mais pas les mêmes réglages par défaut

2026-10-16T00:00:00Z

OpenClaw et Hermes Agent font le même travail : un agent open source qui vit sur votre propre machine, vous répond dans Telegram, Slack ou WhatsApp, lance des outils, se souvient de vous et écrit ses propres skills. En octobre 2026, leurs listes de fonctionnalités se recoupent presque entièrement. Leurs réglages par défaut, non. OpenClaw est pensé pour aller partout : des dizaines de canaux de discussion, des applis mobiles qui servent de capteurs, de nombreux agents derrière une seule gateway. Hermes est construit autour d’une boucle d’apprentissage et d’un large choix d’endroits où exécuter ses commandes. Les deux lancent les outils directement sur votre ordinateur tant que vous ne changez rien, et pour beaucoup de gens, un harnais (harness) plus petit, voire aucun, reste le meilleur choix.

Je fais tourner OpenClaw sur un Mac mini depuis mai, 17 agents au dernier décompte, et j’ai fait tourner Hermes à côté avec deux profils jusqu’en septembre. Cette note met les deux côte à côte, avec les cinq « claws » plus petits apparus autour d’eux. Les chiffres viennent de la documentation, du README et de la page GitHub de chaque projet, relevés le 16 octobre. Les figures s’animent ou répondent à un clic, et un sélecteur vous attend à la fin.

Schéma : Étoiles GitHub au 16 octobre 2026, à l’échelle. OpenClaw, TypeScript, MIT : 392 150. Hermes Agent, Python, MIT : 254 281. nanobot, Python, MIT : 49 079. ZeroClaw, Rust, Apache 2.0 ou MIT : 32 983. NanoClaw, TypeScript, MIT : 30 955. PicoClaw, Go, MIT : 30 077. IronClaw, Rust, Apache 2.0 : 12 659. OpenClaw a publié la 2026.10.4 le 16 octobre et Hermes la v0.22.2 le 15 octobre. À voir sur la page.

Deux gros projets et une foule de petits

OpenClaw est celui qui a lancé la vague. L’assistant personnel de Peter Steinberger est passé de Clawd à Moltbot, puis à OpenClaw, en janvier. Son auteur a rejoint OpenAI en février, et depuis juillet le projet appartient à l’OpenClaw Foundation, une organisation à but non lucratif où OpenAI est, selon la fondation elle-même, un donateur et non un propriétaire. C’est du TypeScript sous licence MIT, et les versions s’enchaînent : la 2026.10.4 est sortie le 16 octobre.

Hermes Agent vient de Nous Research, le labo derrière les modèles Hermes. C’est du Python sous MIT, sorti pour la première fois en mars, et il avance tout aussi vite. La v0.22, « The Threshold Release », est arrivée le 14 octobre et a fait passer le code source d’environ 1,06 million de lignes à 698 000.

Autour des deux, des harnais plus petits ont chacun choisi une chose à mieux faire. NanoClaw met chaque agent dans un conteneur. nanobot garde un petit cœur en Python. ZeroClaw et PicoClaw tiennent sur des cartes bon marché. IronClaw réécrit OpenClaw en Rust, autour de la sécurité.

Dans les deux cas, une gateway autour d’une boucle

Oubliez les marques, et les deux ont la même forme. Un processus gateway reste allumé et écoute vos comptes de messagerie. Un message arrive, la gateway trouve la bonne session, et une boucle d’agent tourne : le modèle demande un outil, l’outil s’exécute, le résultat revient, jusqu’à ce que le modèle tienne sa réponse. En chemin, l’agent écrit dans des fichiers Markdown que la session suivante lira, et la réponse repart vers la discussion d’où venait le message.

Les différences sont dans les boîtes. La gateway d’OpenClaw est un seul processus Node de longue durée, avec un WebSocket sur 127.0.0.1:18789, et chaque agent, chaque canal et chaque téléphone lui parle. Hermes fait tourner une gateway en Python, et chaque profil a son propre répertoire, avec sa mémoire, ses skills et ses tâches cron. OpenClaw réveille aussi ses agents de lui-même : par défaut, un heartbeat lance un tour d’agent complet toutes les 30 minutes. Hermes attend vos messages, ou les tâches cron que vous décrivez en langage courant, et ne donne un /heartbeat à une session que si vous le demandez.

Schéma : Un message à travers chaque harnais, en cinq étapes, l’étape en cours mise en évidence tour à tour. Un : un message arrive. OpenClaw prend environ 30 canaux de discussion, plus des applis pour téléphones et ordinateurs ; Hermes a 25 adaptateurs de plateforme ou plus et une appli desktop. Deux : la gateway l’aiguille. OpenClaw fait tourner un seul processus Node avec un WebSocket sur le port 18789 de localhost, et tous les agents derrière lui ; Hermes fait tourner une gateway Python, et chaque profil a son propre répertoire. Trois : la boucle lance les outils. Les deux acceptent n’importe quel modèle ; OpenClaw peut confier la boucle à Claude Code ou Codex, et Hermes fait tourner des modèles locaux via llama.cpp en un clic depuis la v0.22. Quatre : il prend des notes. OpenClaw tient MEMORY.md et des notes quotidiennes, et les consolide lors d’une passe Dreaming planifiée ; Hermes tient un petit MEMORY.md et un USER.md, et cherche dans les anciennes sessions en plein texte. Cinq : il répond, ou se réveille de lui-même. OpenClaw lance un tour de heartbeat toutes les 30 minutes par défaut ; Hermes lance des tâches cron écrites en langage courant, et un heartbeat par session seulement si vous le demandez. À voir sur la page.

Là où les réglages par défaut divergent

Fonctionnalité par fonctionnalité, la plupart des lignes d’un comparatif disent « les deux ». La question utile, c’est de quel côté penche chaque projet quand vous l’installez sans rien changer. Passez d’un onglet à l’autre.

Mémoire : OpenClaw injecte une pile de fichiers d’espace de travail dans chaque session, AGENTS.md, SOUL.md, USER.md, MEMORY.md et les notes quotidiennes, jusqu’à 20 000 caractères par fichier et 60 000 au total, et une passe Dreaming planifiée les consolide. Hermes garde volontairement une mémoire minuscule : 2 200 caractères de notes et 1 375 sur vous, figés au démarrage de la session. Quand il lui en faut plus, il cherche dans ses anciennes conversations avec la recherche plein texte de SQLite.

Canaux : le catalogue d’OpenClaw liste environ 30 plateformes de discussion, et ses applis pour iOS, Android, macOS, Windows et Linux transforment un appareil en nœud, avec caméra, localisation et notifications. Hermes a plus de 25 adaptateurs et une appli desktop. Je n’ai pas trouvé d’appli mobile.

Sandbox : les deux exécutent les commandes sur l’hôte par défaut. La sandbox d’OpenClaw reste désactivée tant que vous ne l’activez pas, avec Docker, Podman ou SSH derrière. Hermes fait de l’endroit où tournent les commandes un réglage à part entière, local, Docker, SSH, Singularity, Modal, Daytona ou Vercel Sandbox, et demande par défaut à un second modèle de juger les commandes signalées avant leur exécution.

Modèles : les deux acceptent n’importe quel fournisseur. OpenClaw peut aussi confier toute la boucle à Claude Code ou Codex. Hermes a ajouté les modèles locaux en un clic via llama.cpp, et il sait exporter des trajectoires pour l’apprentissage par renforcement, ce qui en dit long sur ceux qui le construisent.

Agents : OpenClaw route chaque compte de messagerie vers un agent par des bindings, et je fais tourner 17 agents derrière une seule gateway. Un profil Hermes, c’est un agent avec son propre répertoire, et delegate_task confie des sous-tâches à des agents enfants.

Schéma : Un comparatif à onglets des réglages par défaut d’OpenClaw et d’Hermes. Mémoire : OpenClaw injecte jusqu’à 60 000 caractères de fichiers d’espace de travail dans chaque session, 20 000 par fichier et 4 000 pour USER.md, et une passe Dreaming les consolide ; Hermes garde 3 575 caractères de mémoire, 2 200 de notes et 1 375 sur vous, figés au démarrage de la session, et cherche dans les anciennes sessions avec la recherche plein texte de SQLite. Canaux : OpenClaw liste environ 30 plateformes de discussion, plus des applis qui font des téléphones des nœuds avec caméra, localisation et notifications ; Hermes a 25 adaptateurs ou plus et une appli desktop. Sandbox : la sandbox d’OpenClaw est désactivée par défaut, avec des backends Docker, Podman ou SSH ; Hermes utilise par défaut le backend local, propose Docker, SSH, Singularity, Modal, Daytona et Vercel Sandbox, et laisse un second modèle juger les commandes signalées. Modèles : les deux acceptent n’importe quel fournisseur ; OpenClaw peut confier la boucle à Claude Code ou Codex, Hermes fait tourner des modèles locaux via llama.cpp et exporte des trajectoires pour l’apprentissage par renforcement. Agents : OpenClaw route les discussions vers de nombreux agents derrière une seule gateway, 17 dans mon installation ; un profil Hermes est un agent avec son propre répertoire, et delegate_task lance des agents enfants. À voir sur la page.

Les deux apprennent seuls, au compteur

Le README d’Hermes le présente comme le seul agent doté d’une boucle d’apprentissage intégrée. Ce n’est plus vrai depuis avril, quand OpenClaw a livré Skill Workshop. Voici ce qui déclenche vraiment chacune des deux.

Hermes compte. À chaque dizaine de prompts que vous envoyez, un agent de revue forké relit la conversation et décide quoi enregistrer en mémoire. Toutes les 10 itérations d’outil dans un même tour, le même genre de revue décide s’il faut écrire ou corriger un skill. Un curateur marque un skill comme périmé après 14 jours sans usage et l’archive au bout de 30. Il n’en supprime jamais.

OpenClaw compte aussi. Au bout de 10 itérations du modèle dans une conversation, une revue en arrière-plan enregistre ce qui mérite d’être gardé sous forme de skill appris, et pendant un tour, l’agent corrige un skill appris qui l’a induit en erreur. Les skills que personne n’utilise pendant 30 jours sont archivés, chaque modification garde la version précédente, et /learn undo en annule une.

Les deux ont un déclencheur manuel, /refine sur Hermes et /learn sur OpenClaw. Le vrai écart, c’est la mémoire : Hermes la revoit selon son propre calendrier, alors qu’OpenClaw la laisse à l’agent et à la passe Dreaming, et n’automatise que les skills.

Schéma : Les deux boucles d’apprentissage comptent jusqu’à dix, puis lancent une revue. Hermes compte vos prompts : au bout de 10, une revue forkée décide quoi enregistrer dans MEMORY.md. Il compte aussi les itérations d’outil dans un même tour : au bout de 10, une revue écrit ou corrige un skill. Son curateur marque les skills inutilisés comme périmés après 14 jours et les archive après 30, sans jamais les supprimer. OpenClaw compte les itérations du modèle dans une conversation : au bout de 10, une revue en arrière-plan enregistre un skill appris, et pendant un tour, l’agent corrige un skill appris qui l’a induit en erreur. Les skills inutilisés pendant 30 jours sont archivés, chaque modification est versionnée, et /learn undo en annule une. À la main : /refine sur Hermes, /learn sur OpenClaw. À voir sur la page.

Les deux lancent les outils sur votre ordinateur par défaut

C’est la partie que j’aurais voulu qu’on me dise en premier. Sans configuration, OpenClaw exécute les outils de votre session principale sur l’hôte. Son README le dit, et sa page sur la sandbox commence par « Le sandboxing est désactivé par défaut. » Le backend de terminal par défaut d’Hermes est local, lui aussi. Un skill que vous installez, ou un prompt injecté via un e-mail que l’agent lit, peut donc atteindre tout ce que votre compte utilisateur peut atteindre.

Ce n’est pas théorique. En février, la CVE-2026-25253 permettait, d’un seul clic sur un lien piégé, de faire fuiter un token de gateway OpenClaw et d’exécuter du code ; elle a été corrigée dans la 2026.1.29. Un scan de ClawHub, le registre de skills d’OpenClaw, a trouvé 341 skills malveillants sur 2 857. SecurityScorecard a compté 40 214 instances OpenClaw exposées sur internet le 9 février. Hermes a eu quatre CVE de son côté.

Certains des petits harnais existent précisément pour ça. NanoClaw fait tourner chaque groupe d’agents dans son propre conteneur, et les requêtes sortantes passent par une gateway qui ajoute les identifiants : l’agent ne détient jamais de clé d’API en clair. IronClaw exécute les outils non fiables dans une sandbox WebAssembly avec une liste d’autorisation d’endpoints, et n’injecte les secrets qu’à la frontière de l’hôte. Choisissez une configuration dans la figure et voyez ce qu’un mauvais skill peut atteindre.

Schéma : Ce qu’un mauvais skill peut atteindre selon quatre configurations, sur six choses de votre machine : vos documents, vos clés SSH, vos clés d’API, vos sessions de navigateur, l’espace de travail de l’agent et internet. Sur l’hôte, la valeur par défaut de la session principale d’OpenClaw et du backend local d’Hermes, les six sont accessibles. Dans une sandbox Docker, optionnelle sur les deux, seul l’espace de travail monté est accessible à coup sûr, et les clés ou le réseau seulement si vous les autorisez. Le conteneur par groupe d’agents de NanoClaw, son réglage par défaut, atteint le dossier du groupe, et le réseau seulement s’il est autorisé ; les identifiants restent hors du conteneur. Les outils WebAssembly d’IronClaw, son réglage par défaut pour les outils non fiables, n’atteignent rien sans autorisation : fichiers et endpoints doivent être autorisés, et les secrets sont injectés à la frontière de l’hôte et surveillés contre les fuites. En dessous, le bilan d’OpenClaw : la CVE-2026-25253, une exécution de code à distance en un clic, corrigée dans la 2026.1.29 ; 341 skills malveillants sur 2 857 dans ClawHub ; 40 214 instances exposées sur internet le 9 février. À voir sur la page.

Chaque petit claw choisit son combat

Chaque petit claw est en partie une réaction à la taille d’OpenClaw. Le README de NanoClaw le dit sans détour : OpenClaw, c’est « près d’un demi-million de lignes de code, 53 fichiers de configuration et plus de 70 dépendances ». NanoClaw est « conçu pour être facile à comprendre et entièrement adapté à vos besoins », et l’adapter veut dire changer le code, pas la configuration.

NanoClaw repose sur le Claude Agent SDK d’Anthropic, avec un conteneur par groupe d’agents, et vous ajoutez un canal en lançant un skill comme /add-telegram. nanobot, du Data Intelligence Lab de l’université de Hong Kong, est le petit harnais Python, avec Telegram, Feishu, WeChat, Slack et Discord parmi ses canaux.

ZeroClaw et PicoClaw visent le matériel bon marché. ZeroClaw est un binaire Rust unique qui parle à une vingtaine de fournisseurs de modèles et peut piloter les broches GPIO d’un Raspberry Pi, d’un Arduino ou d’un ESP32. PicoClaw est écrit en Go, annonce un démarrage en moins d’une seconde sur un seul cœur à 0,6 GHz, et reconnaît honnêtement que les builds récents utilisent 10 à 20 Mo de RAM, pas les moins de 10 de son accroche.

IronClaw, de NEAR AI, se présente comme un OS d’agent axé sur la confidentialité, la sécurité et l’extensibilité : une réécriture en Rust inspirée d’OpenClaw, avec des outils en WebAssembly, des secrets chiffrés en AES-256-GCM, PostgreSQL pour l’état et aucune télémétrie. Ce sont les affirmations des projets eux-mêmes. Je n’ai mesuré aucun d’entre eux.

Schéma : Les cinq petits claws, chacun avec son argument. NanoClaw, TypeScript, MIT, 31 000 étoiles : un assistant IA qui fait tourner les agents en sécurité dans leurs propres conteneurs ; un conteneur par groupe d’agents sur le Claude Agent SDK, des identifiants ajoutés hors du conteneur, des canaux ajoutés sous forme de skills comme /add-telegram. nanobot, Python, MIT, 49 000 étoiles : un framework d’agent IA personnel ultra-léger et auto-hébergé, écrit en Python, du Data Intelligence Lab de l’université de Hong Kong, avec Telegram, Feishu, WeChat, Slack et Discord. ZeroClaw, Rust, 33 000 étoiles : l’agent est à vous, les données sont à vous, la machine qui le fait tourner est à vous ; un binaire unique avec une vingtaine de fournisseurs de modèles et le GPIO sur Raspberry Pi, Arduino et ESP32. PicoClaw, Go, MIT, 30 000 étoiles : tourne sur du matériel à 10 dollars avec moins de 10 Mo de RAM, même si les builds récents peuvent utiliser 10 à 20 Mo, et démarre en moins d’une seconde sur un seul cœur à 0,6 gigahertz. IronClaw, Rust, Apache 2.0, 13 000 étoiles : un OS d’agent axé sur la confidentialité, la sécurité et l’extensibilité ; outils en WebAssembly, secrets en AES-256-GCM, PostgreSQL, aucune télémétrie. À voir sur la page.

Ce que deux harnais m’ont appris

OpenClaw est celui que j’ai gardé : 17 agents, 16 bots Telegram, un par agent, et quatre serveurs MCP branchés sur mes propres applis. C’est aussi celui qui m’a coûté le plus de soirées.

Le 1er septembre, la mise à jour de la 2026.7.1 vers la 2026.8.1 a tourné à l’incident de plusieurs heures. Des schémas de configuration plus stricts rejetaient des réglages qui marchaient la veille, le moindre avertissement pendant la migration au démarrage arrêtait désormais la gateway, et la base d’état est passée à un schéma que l’ancienne version ne savait pas lire : impossible de revenir en arrière. Deux semaines plus tard, la 2026.9.4 exigeait Node 24.16 et ignorait sans bruit tout skill sans description dans son front matter. L’un de mes agents a perdu un skill comme ça.

Avec Hermes, l’histoire est inverse. Je l’ai fait tourner avec deux profils, je l’ai mis à jour le 14 août (un saut de 7 183 commits), puis j’ai arrêté de m’en servir. Au 14 septembre, ses deux gateways plantaient en boucle sur des tokens Telegram que j’avais révoqués, alors je l’ai supprimé. Le piège : ma gateway OpenClaw tournait en fait sur le binaire Node embarqué par Hermes. Supprimer un harnais a failli faire tomber l’autre.

Les limites partagées frappent aussi tout le monde à la fois. Mes agents partagent un seul compte Claude, et le 15 octobre, sa limite de cinq heures les a tous bloqués d’un coup. Rien n’a repris après la remise à zéro.

Rien de tout ça n’est une raison d’écarter l’un ou l’autre projet. C’est le prix d’un logiciel qui bouge aussi vite : lisez les notes de version avant de mettre à jour, et sauvegardez d’abord le dossier d’état.

Schéma : Ma chronologie avec les deux harnais, un événement mis en évidence à la fois. Mai 2026 : OpenClaw s’installe sur un Mac mini et grandit jusqu’à 17 agents, 16 bots Telegram et quatre serveurs MCP. 14 août : Hermes passe de la 0.18.2 à la 0.20.1, sur 7 183 commits, avec deux profils. 1er septembre, une casse : OpenClaw 2026.8.1 apporte des schémas de configuration stricts, des avertissements de migration bloquants et une base d’état sans retour possible, et la mise à jour prend des heures. 14 septembre, une casse : les deux gateways d’Hermes plantent en boucle sur des tokens de bot révoqués et Hermes est supprimé, la gateway OpenClaw s’avère tourner sur le Node embarqué par Hermes, puis OpenClaw 2026.9.4 exige Node 24.16 et ignore sans bruit un skill sans description. 15 octobre, une casse : la limite de cinq heures d’un seul compte Claude bloque tous les agents d’un coup, et rien ne reprend après la remise à zéro. À voir sur la page.

Choisir selon la situation

Alors, lequel ? Voici comment je choisirais aujourd’hui.

Si vous voulez de nombreux agents sur de nombreuses messageries, avec votre téléphone comme capteur, prenez OpenClaw, et activez la sandbox pour tout sauf votre session principale.

Si vous voulez un agent qui progresse sur votre travail récurrent, et que vous préférez bidouiller du Python, prenez Hermes. Si vous êtes déjà sur OpenClaw, hermes claw migrate --dry-run montre ce qui serait repris : votre SOUL.md, vos mémoires, skills, listes d’autorisation et réglages de canaux.

Si vous voulez lire chaque ligne et garder chaque agent dans un conteneur, prenez NanoClaw. Pour un Raspberry Pi ou une carte bon marché, PicoClaw ou ZeroClaw. Si les secrets et les outils non fiables sont votre principale inquiétude, IronClaw. Pour un petit agent Python avec les messageries chinoises, nanobot.

Et si tout ce que vous voulez, c’est joindre une session de code depuis votre téléphone, vous n’avez peut-être besoin d’aucun harnais. Remote Control et Channels dans Claude Code, et le mode distant de Codex dans l’appli ChatGPT, font ça tant que votre machine reste allumée.

Schéma : Un sélecteur de situations avec huit choix et une réponse pour chacun. Beaucoup d’agents sur beaucoup de messageries : prenez OpenClaw, pour environ 30 canaux, des nœuds sur téléphone et des bindings qui routent chaque discussion vers son propre agent ; le hic, c’est une base de code grosse et qui bouge vite, alors lisez les notes de version, sauvegardez d’abord et mettez en sandbox tout sauf la session principale. Un agent qui apprend vos habitudes : prenez Hermes, pour une boucle d’apprentissage active par défaut, une petite mémoire plus la recherche dans les sessions, et de nombreux endroits où exécuter les commandes ; le hic, c’est l’absence d’appli mobile, et les approbations intelligentes restent un modèle qui en juge un autre. Déjà sur OpenClaw, envie de tester Hermes : essayez hermes claw migrate avec --dry-run, qui importe SOUL.md, les mémoires, les skills, les listes d’autorisation et les réglages de canaux ; vérifiez sur quel Node tourne chaque service. Lire chaque ligne : NanoClaw, une petite base de code TypeScript sur le Claude Agent SDK avec un conteneur par groupe d’agents ; l’adapter veut dire changer le code. Un Raspberry Pi ou une carte bon marché : PicoClaw ou ZeroClaw, des binaires uniques en Go et en Rust, ZeroClaw avec le GPIO ; les empreintes sont leurs propres affirmations. Les secrets d’abord : IronClaw, avec des outils WebAssembly, une liste d’autorisation d’endpoints et des secrets injectés à la frontière ; il lui faut PostgreSQL et sa communauté est la plus petite. Un petit agent Python : nanobot, avec les messageries chinoises ; sa sandbox est désactivée par défaut. Juste une session de code depuis votre téléphone : aucun harnais, Remote Control ou Channels dans Claude Code, ou le mode distant de Codex dans l’appli ChatGPT ; ça ne marche que tant que la session ou la machine tourne, sans mémoire ni planification propres. À voir sur la page.

Pour aller plus loin :

Une flotte d’agents chez moi, mon talk sur l’installation OpenClaw à 17 agents
Ne soyez pas le meat proxy de votre équipe, Peter Steinberger sur les collègues qui s’adressent à vos agents
Les collègues IA dans Slack ont besoin de leur propre identité, ce qui change quand un agent poste en son nom

Si vous faites tourner l’un d’eux, dites-moi lequel et ce qui a cassé en premier. J’aimerais comparer nos notes.

Le travail d’un précepteur, c’est de livrer des seniors

2026-10-16T00:00:00Z

Le travail d’un ingénieur senior, c’est de livrer. Celui d’un précepteur, c’est de livrer des seniors. La formule est de Scott Hanselman, pour PRAISE, le programme qu’il a lancé chez Microsoft avec Mark Russinovich, CTO d’Azure, parce qu’ils s’attendent à ce que l’IA assèche le vivier des débutants : si la direction croit qu’un agent peut faire le travail d’un junior, les entreprises arrêtent d’embaucher des juniors. Leur réponse ne change pas l’étiquette du junior. Elle change celle du senior, avec un mot emprunté aux soins infirmiers, et met les deux en binôme autour de labs IA hebdomadaires, avec des cours de Carnegie Mellon en parallèle.

La conversation, c’est PRAISE : Preceptorship for AI-accelerated Software Engineering, 35 minutes sur la chaîne Microsoft Developer, publiée le 15 octobre. Scott anime. Le Dr Michael Hilton enseigne le génie logiciel à Carnegie Mellon et y dirige l’enseignement du Software and Societal Systems Department. Julia Gao est ingénieure logiciel dans l’équipe de Scott ; stagiaire chez Microsoft en 2024, elle a suivi PRAISE comme préceptorée. Le terme meat proxy, tiré de ma note sur la conférence de Peter Steinberger, revient ici, vu de l’autre côté.

Quelqu’un sur le campus vibe-code son diplôme

Hilton date avec précision le point de rupture pour l’université : le moment où l’IA a pu faire du premier coup les devoirs qu’il donne. Il enseigne le génie logiciel en fin de cursus, et quelque part entre le semestre d’automne 2025 et celui du printemps 2026, elle est devenue capable de les faire tous. Les étudiants n’avaient plus besoin de réfléchir. Ils pouvaient copier-coller.

Julia a vu la même chose de l’autre côté du bureau. ChatGPT est sorti pendant sa deuxième année et n’était pas bon, donc personne autour d’elle ne s’en servait avant la troisième année. Puis il est vite devenu bon, et les professeurs ont commencé à demander, sur chaque devoir, une ligne précisant où l’IA avait servi.

La phrase d’ouverture de Scott quand il forme des enseignants d’université : en ce moment même, quelque part sur le campus, quelqu’un vibe-code son diplôme, et il faut décider si ça nous va.

Pour Hilton, cela révèle un vieux point faible. Les enseignants comptaient sur le fait qu’un exercice donné n’avait que deux issues : on le saute ou on le résout. Il y en a maintenant une troisième, le bouton magique, si bien que son métier consiste aussi à convaincre les étudiants que l’effort compte. Ce qu’il entend des étudiants, des dizaines ou des centaines de fois, chaque fois qu’ils pensent être honnêtes : « Je n’utilise pas l’IA pour les choses qui comptent pour moi. Je l’utilise pour les parties de la fac dont je me fiche. »

Schéma : Ce qu’un étudiant peut faire d’un exercice donné. Pendant des années, il y avait deux issues : le sauter, ou le résoudre. Depuis que l’IA fait les devoirs du premier coup, quelque part entre les semestres d’automne 2025 et de printemps 2026, il y en a une troisième : le bouton magique, le copier-coller. En dessous, la chronologie de Julia : ChatGPT arrive pendant sa deuxième année et n’est pas bon ; en troisième année il est bon, et les professeurs demandent sur chaque devoir une ligne précisant où l’IA a servi ; puis les devoirs de fin de cursus de Hilton tombent du premier coup. La phrase des étudiants, que Hilton a entendue des dizaines ou des centaines de fois : je n’utilise pas l’IA pour les choses qui comptent pour moi. Je l’utilise pour les parties de la fac dont je me fiche. À voir sur la page.

Envoyer un robot soulever vos haltères

Scott a un mot pour ce que le bouton magique vous fait : atrophié. Un muscle se développe avec le temps passé sous tension. Envoyez un robot à la salle soulever les poids à votre place et, si on vous demande s’ils ont été soulevés, vous pouvez honnêtement répondre oui. Vous n’êtes pas devenu plus fort.

Hilton a soumis cette analogie à sa classe, avec des points bonus pour qui en trouverait une meilleure. Plusieurs étudiants sont arrivés, chacun de leur côté, à la même image : un cours de cuisine où l’on commande sur DoorDash pour rendre l’assiette.

L’usage de Julia, c’est la version que tous les deux souhaitent. Elle faisait les séries d’exercices elle-même, pour apprendre les fondamentaux. Une fois qu’une implémentation simple fonctionnait, elle interrogeait l’IA sur d’autres façons de faire, et quand la solution de l’enseignant différait de la sienne, elle demandait à l’IA de lui expliquer la différence. L’IA comme source d’information, jamais comme ce qui fait la série à sa place.

Puis Scott ressort le meat proxy : je vous demande quelque chose, vous demandez au bot, le bot vous répond, vous me répétez ce que le bot a dit. Si votre travail se résume de plus en plus à appuyer sur OK, c’est là qu’il faut s’inquiéter, parce qu’appuyer sur OK, ce n’est pas un métier.

Schéma : Deux analogies pour l’usage de l’IA afin d’expédier un travail dont on se fiche. Celle de Scott : un muscle se développe avec le temps passé sous tension ; envoyez un robot soulever les poids à votre place et ils sont soulevés, mais vous ne devenez pas plus fort. Celle des étudiants : aller à un cours de cuisine et commander sur DoorDash pour rendre son plat. Puis la boucle de Julia en trois étapes : résoudre la série soi-même, demander à l’IA d’autres façons de l’implémenter, et quand la réponse de l’enseignant diffère, demander à l’IA d’expliquer la différence. La phrase de Scott : appuyer sur OK, ce n’est pas un métier. À voir sur la page.

Un mot d’infirmière pour le nouveau métier du senior

PRAISE signifie Preceptorship for AI-accelerated Software Engineering. Le point de départ de l’article écrit par Scott et Russinovich : stagiaires et alternants arrivent à moins un, jetés dans l’arène des ingénieurs seniors, à charge pour eux de s’en sortir seuls.

La plupart des programmes répondent en donnant une étiquette au nouveau venu : stagiaire, alternant, junior. PRAISE en donne une au senior. En soins infirmiers, un précepteur est un formateur lui-même formé dont le rôle à l’hôpital, en plus de bien soigner, est de faire de nouveaux infirmiers seniors. L’étiquette dit au senior que son métier a changé.

Scott est franc sur la raison. Il a été mentor, et un mauvais, parce que son mentorat se résumait à une leçon hebdomadaire donnée par un vieux. La personne en face repartait en se disant que son père lui en offrait autant.

Le préceptorat de Julia reposait sur des labs IA structurés, un par semaine, comme point de départ de la conversation. Le lab lui donnait quelque chose de concret qu’elle venait de faire. Elle pouvait alors demander à son précepteur comment il s’y serait pris, dès la première étape, et pourquoi il construirait un projet de telle façon plutôt que de telle autre. Aujourd’hui, elle applique à son travail quotidien la façon dont il attaque un problème, « au lieu de simplement écouter ce que fait l’IA ».

Hilton, qui revendique le droit de l’universitaire à être pointilleux, dit que le mot précis importe peu. Ce qui compte, c’est qu’il a été choisi avec intention, pour dire que ce n’est pas un stage comme les autres. Si ça doit être différent, appelez-le autrement. Il cite Eisenhower : les plans ne sont rien, la planification est tout.

Schéma : Qui porte l’étiquette. Dans un mentorat ou un stage, l’étiquette va au nouveau venu : stagiaire, alternant, junior, arrivé à moins un et sommé de s’en sortir ; le senior reste ingénieur senior, et le mentorat est une leçon hebdomadaire donnée par un vieux. Dans PRAISE, l’étiquette va au senior : précepteur, un mot des soins infirmiers pour un formateur formé dont le rôle est de faire de nouveaux infirmiers seniors ; le nouveau venu est préceptoré. Chaque semaine, un lab IA structuré lance la conversation, et le préceptoré demande comment le précepteur s’y prendrait, dès la première étape, et pourquoi. Le point de Hilton : le mot lui-même importe peu, le choisir avec intention, si. Les plans ne sont rien, la planification est tout. À voir sur la page.

La stagiaire écrivait l’outil. Maintenant, ce sont les agents.

Le stage de Julia, en 2024, c’était un outil en ligne de commande écrit à la main : il modifiait quelques fichiers, ouvrait une pull request et la finalisait une fois qu’un utilisateur avait approuvé. L’IA restait sur le côté pour la syntaxe, parce qu’elle apprenait le C# et connaissait déjà Java. Comment je définis cette classe ici ? La conception et la logique étaient les siennes, relues par toute l’équipe avant qu’elle ne tape quoi que ce soit.

De retour à plein temps, elle dit que l’arrivée de Claude Opus cette année a tout changé. Son équipe code tout avec des workflows multi-agents, y compris le genre de tâche qu’elle automatisait en stage. Le résumé de Scott : donc vous voilà relectrice. Le sien : il faut comprendre la logique, se faire écrire le code, comprendre comment il s’insère dans le contexte plus large, et en assumer la responsabilité, parce que c’est vous qui le livrez.

La version de Scott de cette responsabilité : la pull request est à votre nom. Elle indique Copilot on behalf of Julia, et quand ça tourne mal, c’est elle qui reçoit le coup de fil.

Le nouveau stress, c’est le changement de contexte. Avec quatre ou cinq agents qui tournent en même temps, chacun sur une partie différente du ticket, elle doit passer de l’un à l’autre, et elle y voit une compétence que toute la profession doit encore développer.

Schéma : Le travail de Julia, avant et maintenant. Pendant son stage de 2024, elle a écrit à la main un outil en ligne de commande qui modifiait des fichiers, ouvrait une pull request et la finalisait une fois qu’un utilisateur avait approuvé ; la conception et la logique étaient les siennes, relues d’abord par l’équipe, et l’IA ne répondait qu’à des questions de syntaxe pendant qu’elle apprenait le C sharp. Aujourd’hui, à plein temps, quatre ou cinq agents écrivent le code dans des workflows multi-agents pendant qu’elle le lit, le valide par rapport au ticket, le livre et passe de l’un à l’autre ; la pull request indique Copilot on behalf of Julia, et quand ça tourne mal, c’est elle qui reçoit le coup de fil. À voir sur la page.

De l’autre côté de la rue ou jusqu’à la Lune

Scott pose la question franchement : si la machine peut simplement le faire, à quoi sert la compréhension profonde ? La première réponse de Hilton : quiconque prétend le savoir, à ce jour, ment. La seconde : c’est le contexte qui décide. Pour prendre un Uber jusqu’à l’aéroport, pas besoin de savoir comment marche un moteur. Pour être ingénieur principal d’une écurie de Formule 1, si, même sans jamais en construire un. Un script qui modifie un fichier quelques fois : vérifiez le fichier et passez à autre chose. Une infrastructure que des millions de gens vont utiliser : comprenez-la avant de la livrer.

Il emprunte une statistique du baseball, la valeur par rapport à un remplaçant, et demande ce que vaut un étudiant face à ce remplaçant qu’est l’IA. Si tout ce que vous savez faire, c’est écrire un prompt qui décrit une tâche, le modèle peut écrire ce code, et vous avez un problème. Un prompt ne porte pas le contexte : envoie-t-on ce paquet de l’autre côté de la rue ou jusqu’à la Lune ? La validation, la performance et la sécurité en dépendent, et savoir ce qui compte ici, c’est la part humaine.

Scott fait remarquer que tout le monde, autour de la table, n’arrête pas d’employer le mot contexte pour deux choses différentes. Il y a la fenêtre de contexte du modèle, et il y a le contexte dans lequel vit la solution. Une fenêtre d’un million de tokens ne sait pas ce que Julia sait de Microsoft.

Julia rend ça concret. Un produit, c’est plusieurs dépôts et beaucoup de pièces mobiles. L’IA est très bonne pour résoudre un problème dans un dépôt. Elle ne se situe pas dans le système entier, alors elle corrige le problème et casse quelque chose ailleurs. C’est son précepteur qui lui dit où sa fonctionnalité se place dans le produit. Scott cite une phrase dont il ne retrouve pas la source : l’IA écrit facilement des fonctionnalités, mais elle n’écrit pas facilement des architectures.

Schéma : Jusqu’où il faut comprendre, sur une échelle tirée des exemples de Hilton. Côté surface : un Uber jusqu’à l’aéroport, ou un script qui modifie un fichier quelques fois, où l’on vérifie le fichier et passe à autre chose. Côté profondeur : l’ingénieur principal d’une écurie de Formule 1, ou une infrastructure utilisée par des millions de gens, qu’on comprend avant de la livrer. En dessous, les deux sens du mot contexte. La fenêtre de contexte : un million de tokens, un problème dans un dépôt, que l’IA résout très bien, mais qui ne sait pas ce que Julia sait de Microsoft. Le contexte où vit la solution : plusieurs dépôts, le produit entier, le paquet qui va de l’autre côté de la rue ou jusqu’à la Lune, et ce que cela exige en validation, performance et sécurité, qu’un prompt ne porte pas et qu’un précepteur porte. La phrase que cite Scott : l’IA écrit facilement des fonctionnalités, elle n’écrit pas facilement des architectures. À voir sur la page.

Les ingénieurs civils ne préparent pas le béton

Hilton et Mary Shaw ont publié une tribune dans le New York Times en novembre 2025, « You’re a Computer Science Major. Don’t Panic. » Près d’un an plus tard, Scott demande si elle tient toujours. Hilton dit oui, et précise : il y a une différence entre l’informatique et le génie logiciel, et entre concevoir du logiciel et écrire du code. Les ingénieurs civils ne préparent pas le béton et ne coulent pas les ponts. Ils conçoivent un pont qui tient sous le trafic et ne finit pas comme celui de Tacoma Narrows. Si les ingénieurs logiciels ont toujours été des codeurs, c’est seulement parce qu’ils n’avaient aucun moyen de prendre leurs distances avec la matière première.

La phrase que je garde : à mesure que le coût d’écriture du code tend vers zéro, le coût de l’ingénierie qui garantit que le problème est bien résolu, lui, ne tend pas du tout vers zéro. Construit-on la bonne chose, dans les délais, dans le budget, pour ce public, avec la bonne sécurité, la bonne utilisabilité, la bonne évolutivité et la bonne architecture ? Ces questions prennent désormais une plus grande part de la journée, puisque plus personne ne tape les lignes.

La partie de la tribune qu’il défend le plus : lire, critiquer et comprendre du code est une compétence distincte de l’écrire. L’enseignement supposait qu’on l’acquérait en chemin, en écrivant. Son fils a lu L’Odyssée au lycée, l’a critiquée et a rédigé un devoir dessus. Personne ne lui a demandé d’écrire une épopée. Scott note qu’il existe des cours d’appréciation de la poésie et aucun cours d’appréciation du code : chaque cursus commence par une boucle for et s’attend à ce que vous en sortiez en écrivant Linux.

CMU bouge. Dans le cours d’introduction que sa fille suit en première année, la plupart des devoirs sont des PDF : des problèmes de Parsons, où le code est donné dans le désordre et où il faut le remettre en ordre, et des questions de compréhension. Plus de lecture que d’écriture. Il reconnaît aussi que les cours ne peuvent pas changer au rythme où les labos de pointe livrent, d’où un décalage entre le moment où l’on voit un problème et celui où l’on corrige le programme.

Schéma : Les deux coûts de Hilton, en schéma : le coût d’écriture du code tombe vers zéro, tandis que le coût de l’ingénierie qui garantit que le problème est bien résolu reste stable. En dessous, ce qu’on a demandé à son fils de faire avec L’Odyssée : la lire, la critiquer, rédiger un devoir dessus, et jamais écrire une épopée ; lire et critiquer du code est le même genre de compétence distincte. Puis un problème de Parsons, le format du cours d’introduction de CMU : quatre lignes d’une fonction données dans le désordre, que l’étudiant remet dans le bon ordre sans en écrire aucune. Les lignes sont mon exemple du format, pas un exercice de CMU. À voir sur la page.

Lent autrement

Scott, sur sa propre journée : avant, la partie lente, c’était lui, le code. Maintenant, il est lent autrement. Lire le code et attendre le build, voilà les deux choses qui prennent du temps.

La liste de Julia est plus longue. Lire et comprendre ce que l’agent a écrit. Valider que le changement correspond au ticket, ce qui tient pour un petit changement et parfois pas pour un plus gros, avec plus de logique. Les builds. Et la revue par IA, qui tourne désormais sur leurs pull requests : chaque commentaire est une décision, parce qu’en traiter un peut modifier tout un tas d’autres fichiers et élargir le périmètre, et la voilà qui demande à l’agent d’annuler ce qu’il vient de faire. Ce n’est plus le code qui prend du temps. C’est de rendre ce code prêt pour la production.

C’est le goulot d’étranglement qu’Overmind attaquait dans ma note sur la relecture du plan, et la file d’attente sur laquelle bloque ma propre usine logicielle. Trois notes de ce site butent désormais sur le même mur.

Schéma : Où passe la journée, en schéma sans durées. Avant : le code était la partie lente, avec un peu de réflexion, un build et une revue autour. Maintenant, lent autrement : un prompt court, les agents qui écrivent, puis lire ce qu’ils ont écrit, le valider par rapport au ticket, attendre le build et trier les commentaires de la revue par IA. En dessous, la boucle de Julia avec les commentaires de revue, en quatre étapes : un commentaire de revue IA arrive sur la pull request, elle demande à l’agent de le traiter, tout un tas d’autres fichiers changent et le périmètre s’élargit, et elle lui dit d’annuler ce qu’il vient de faire. À voir sur la page.

Enseigner le curriculum caché

Hilton écrit sur un Substack avec des collègues, The Last Software Engineer?, et son dernier billet porte sur le curriculum caché : les compétences que personne n’enseignait parce que tout le monde les absorbait en chemin. Le goût. Le jugement d’ingénieur. Savoir à quoi accorder de l’importance. L’IA les met à nu, et il pense qu’il faut désormais les enseigner directement, alors qu’elles venaient avant au fil de décennies passées à écrire du code. Il cite Lénine : il y a des décennies où rien ne se passe, et des semaines où des décennies se produisent. L’informatique en est aux semaines.

C’est son argument pour un préceptorat plutôt que d’attendre que les programmes rattrapent leur retard : quelqu’un d’expérimenté, à côté du nouvel ingénieur, maintenant. Il n’a rien d’un catastrophiste. Plus de gens que jamais vont résoudre plus de problèmes avec du logiciel, et il s’attend à ce que la génération de Julia fasse plus avec ces outils que la sienne en vingt ans.

Le récit de Julia est moins net, et c’est pour ça que j’y crois. Quand elle a été inscrite, elle s’est dit : mais qu’est-ce qui se passe, je suis déjà bien assez occupée. Le bénéfice est venu ensuite. Avant PRAISE, elle n’avait rien à dire à l’ingénieur principal de son équipe, parce que ses tickets étaient superficiels et ne touchaient jamais à ce qu’il savait. Aujourd’hui, elle a toujours des tête-à-tête avec lui, et le temps qu’il lui consacre compte plus pour elle que tout le reste.

Schéma : Ce que livre chaque rôle. Un ingénieur senior livre du code : une pile de pull requests à son nom. Un précepteur livre des seniors : un préceptoré qui devient ingénieur senior. En dessous, Julia avant et après PRAISE. Avant, elle n’avait rien à dire à l’ingénieur principal de son équipe, parce que ses tickets étaient superficiels et ne touchaient jamais à ce qu’il savait. Après, elle a toujours des tête-à-tête avec lui et met le temps qu’il lui consacre au-dessus de tout le reste. La phrase de clôture de Scott : le travail d’un ingénieur senior, c’est de livrer, mais celui d’un précepteur, c’est de livrer des seniors. À voir sur la page.

Essayez

Côté CMU, c’est un certificat. À l’automne, Machine Learning in Production et Preceptorship in AI-Augmented Software Engineering I. Au printemps, DevOps : Engineering for Secure Development and Deployment et la seconde moitié du parcours de préceptorat. Le tout compte pour un master en génie logiciel. Côté Microsoft, c’est le précepteur, les labs hebdomadaires et les tête-à-tête.

Deux réserves honnêtes. C’est le récit d’une seule préceptorée, sur la chaîne de Microsoft elle-même, et personne dans la conversation ne donne de chiffre : pas de taille de promotion, pas de taux de rétention, rien de mesuré pour l’instant. Ce que la conversation donne, en revanche, c’est une forme que vous pouvez reproduire sans passer par l’une ou l’autre institution.

Schéma : La forme de PRAISE en quatre parties, d’après la conversation et l’annonce de CMU. Un : un binôme, un ingénieur en début de carrière chez Microsoft et un senior qui prend l’étiquette de précepteur. Deux : un lab IA structuré lance chaque semaine la conversation, et des tête-à-tête prennent le relais. Trois : à l’automne, deux cours de Carnegie Mellon, Machine Learning in Production et Preceptorship in AI-Augmented Software Engineering I. Quatre : au printemps, DevOps : Engineering for Secure Development and Deployment et la seconde moitié du préceptorat, le tout validable dans un master en génie logiciel. Non précisés : la taille de la promotion, la durée du binôme, tout résultat mesuré. À voir sur la page.

Pour aller plus loin :

PRAISE : Preceptorship for AI-accelerated Software Engineering, la conversation, 35 minutes
Le billet de The Command Line signé Mark Russinovich et Scott Hanselman, l’article auquel Scott fait référence
L’annonce de CMU du certificat et de ses quatre cours
« You’re a Computer Science Major. Don’t Panic. », la tribune de Mary Shaw et Michael Hilton, sur le site de CMU
The Last Software Engineer?, le Substack de Hilton et de ses collègues
Ne soyez pas le meat proxy de votre équipe, le même terme, vu du côté de Peter Steinberger
Relisez le plan, pas la pull request, la réponse d’une équipe au goulot de la relecture

Si vous êtes le senior d’une équipe, prenez l’étiquette pendant un trimestre. Un lab par semaine, leurs questions, votre première étape à voix haute. Dites-moi quelles questions du junior laissent l’agent sans réponse.

Relisez le plan, pas la pull request

2026-10-15T00:00:00Z

Overmind ne relit plus ses propres pull requests. Presque tout le code que l’entreprise met en production n’est plus lu par aucun humain, auteur compris. La revue n’a pas disparu pour autant. Elle s’est déplacée vers un plan d’environ une page et demie, dont on débat avant qu’un agent écrive la moindre ligne, et dans les trois semaines qui ont suivi le changement, l’équipe a fermé trois fois plus d’issues, tandis que le lead time tombait de 3,2 jours à 1,3.

La conférence, c’est Pull Requests Are Dead, Long Live Peer Review, de Dylan Ratcliffe, fondateur et CEO d’Overmind, donnée à AGNTCon + MCPCon North America 2026. Overmind utilise l’IA pour simuler les changements sur de grosses infrastructures back-end. Dans ma note sur l’usine logicielle, la partie lente de ma propre installation, c’est ma file de revue. Cette conférence, c’est la réponse d’une équipe à ce problème.

La revue remplissait quatre rôles

Comme la plupart des équipes, Overmind comptait sur la revue de code pour bien plus que les bugs. Elle attrapait les bugs, elle couvrait la conformité SOC 2 et ISO 27001, elle formait les ingénieurs juniors, et elle construisait une vision partagée de la façon dont le système fonctionne vraiment.

Ce qui faisait marcher tout ça, c’est qu’un humain tenait à chaque ligne. Commentez la pull request d’une personne, et il en sort quelque chose de bon dans tous les cas. Si vous avez raison, elle apprend et le produit s’améliore. Si elle conteste, c’est qu’il existe une contrainte que vous ignoriez, et maintenant vous la connaissez.

Commentez la pull request d’un bot qui traite lui-même les commentaires de revue, et vous obtenez le même acquiescement empressé, que vous ayez entièrement raison ou entièrement tort. C’est sa première leçon : l’IA n’est pas votre pair, donc la revue par les pairs ne s’applique pas à son travail.

Schéma : Ce que faisait la revue de code chez Overmind : attraper les bugs, assurer la conformité SOC 2 et ISO 27001, former les ingénieurs juniors et construire une vision partagée du fonctionnement du système. Puis le même commentaire de revue envoyé à deux auteurs. Quand l’auteur est une personne, il en sort quelque chose de bon dans tous les cas : si vous aviez raison, elle apprend et le produit s’améliore ; si elle avait raison, vous découvrez une contrainte que vous ignoriez. Quand l’auteur est un bot qui traite lui-même les commentaires de revue, il acquiesce et applique le commentaire, que vous ayez eu raison ou tort. Leçon numéro un : l’IA n’est pas votre pair, donc la revue par les pairs ne s’applique pas à son travail. À voir sur la page.

Deux personnes ont livré plus que toute l’entreprise

En début d’année, Overmind comptait environ 80 % d’ingénieurs. Le produit, c’était Dylan et un product manager. Ils trouvaient l’idée, faisaient la recherche et posaient le cadrage, c’est-à-dire l’architecture de haut niveau. Venaient ensuite une réunion de passation, une série de questions, puis les ingénieurs planifiaient et construisaient avec l’IA.

Le hic : une fois que Dylan avait tout fait jusqu’au cadrage, confier directement le travail à un agent allait plus vite que le confier à une personne. Il vit à San Francisco, une bonne partie de ses ingénieurs sont en Europe, et l’agent ne dort jamais.

Une semaine, le product manager et lui ont donc produit plus que toutes les autres personnes de l’entreprise réunies, sur chaque indicateur qu’ils suivaient : lignes de code, pull requests, tickets fermés et story points. Ça ne fait que six personnes, mais ce sont deux personnes qui abattent le travail de six ingénieurs à plein temps. « Aucun de nous deux n’est ingénieur », a-t-il dit.

Il reconnaît ouvertement avoir sérieusement envisagé de licencier la moitié des ingénieurs pour les remplacer par des product managers. Il ne l’a pas fait. À la place, il a fait venir tout le monde en France pendant une semaine pour remettre le process à plat.

Schéma : Une semaine chez Overmind, dessinée comme une balançoire. D’un côté, Dylan et son product manager, deux personnes qui confient le travail directement aux agents. De l’autre, les six autres personnes de l’entreprise. Le côté à deux pèse plus lourd que les six sur chaque indicateur suivi : lignes de code, pull requests, tickets fermés et story points. La phrase de Dylan : aucun de nous deux n’est ingénieur. Ce qu’il a envisagé : licencier la moitié des ingénieurs et les remplacer par des product managers. Ce qu’il a fait : faire venir tout le monde en France pendant une semaine pour remettre le process à plat. À voir sur la page.

Le travail s’est déplacé vers la gauche

Voici la slide que j’ai retenue de la conférence, redessinée. Avant, le produit avait l’idée, la recherche et le cadrage, et l’ingénierie avait le plan, la construction et la livraison. Désormais, le produit garde l’idée, l’ingénierie prend la recherche, le cadrage et le plan, et un agent construit et livre.

Schéma : Le travail s’est déplacé vers la gauche, redessiné d’après la slide de la conférence. Six étapes : idée, recherche, cadrage, plan, construction, livraison. Avant : le produit avait l’idée avec une personne, la recherche avec une et le cadrage avec deux ; l’ingénierie avait le plan avec trois personnes, la construction avec cinq et la livraison avec trois. Désormais : le produit a l’idée avec deux personnes ; l’ingénierie a la recherche avec quatre, le cadrage avec quatre et le plan avec deux ; un agent se charge de la construction et de la livraison, un pour chacune. La légende de la slide : une fois le plan écrit, le confier à un agent allait plus vite que le confier à une personne. À voir sur la page.

Sa deuxième leçon est sortie de cette semaine-là : si vous pensez que votre métier consiste à transformer des specs détaillées en code de qualité, vous n’avez plus de métier. Selon lui, c’est vrai depuis janvier et Opus 4.5.

Une page, 24 heures, aucune question

Déplacer les ingénieurs vers la gauche s’est accompagné d’une règle. Le produit remet un document d’une page. L’ingénieur qui le reçoit montre une démo sous 24 heures, et n’a le droit de poser aucune question pendant ce temps.

Un document d’une page est plein de trous, et c’est tout l’intérêt. Est-ce que ça doit marcher sur mobile ? Allez vérifier si les gens utilisent ce genre d’app sur mobile. Obligés de lever l’ambiguïté eux-mêmes, les ingénieurs avaient le plus souvent raison.

Personne ne peut absorber toute cette nouvelle ambiguïté et continuer à tenir à chaque ligne de code, cela dit. Le détail ligne par ligne est donc passé aux agents.

Schéma : La nouvelle passation, en trois étapes. Un : le produit remet un document d’une page, plein de trous à dessein. Deux : l’ingénieur a 24 heures et n’a le droit de poser aucune question. Trois : il montre une démo, où chaque trou est comblé selon son propre jugement, par exemple en allant vérifier si les gens utilisent ce genre d’app sur mobile. Obligés de lever l’ambiguïté eux-mêmes, les ingénieurs avaient le plus souvent raison. À voir sur la page.

Toutes les boucles d’agents ne se valent pas

Quand l’équipe a étudié comment les gens construisent des « usines logicielles » et des « usines lumières éteintes » agentiques, la plupart faisaient tourner ce qu’il appelle une boucle do-while. L’agent prend un ticket, décide de l’approche, fait les compromis, écrit le code et les tests, enregistre parfois une vidéo de démo, et ouvre une pull request tout à la fin. Ensuite, un humain doit reconstituer chaque décision à partir du code.

L’idée que l’IA lui prenne son travail l’inquiète un peu. Ce qui l’inquiète davantage, c’est que l’IA lui prenne la partie intéressante et qu’on le paie pour valider des décisions prises sans lui.

L’équipe a donc construit une boucle until. Des agents explorent la base de code, par exemple pour vérifier s’il existe déjà une pratique pour ce genre de changement. Des humains décident de l’approche, font les compromis et écrivent un plan d’implémentation, qu’un pair relit. Puis un agent écrit le code et un second agent le compare au plan. Le moindre écart renvoie le code, et la boucle tourne jusqu’à ce que code et plan correspondent.

Schéma : Où se place la revue dans deux types de boucle d’agents. La boucle do-while, celle de la plupart des usines logicielles agentiques : un agent prend un ticket, décide de l’approche et des compromis, écrit le code, les tests et parfois une vidéo de démo, puis ouvre une pull request ; c’est seulement là qu’un humain la relit, en reconstituant chaque décision à partir du code. La boucle until d’Overmind : des agents explorent la base de code, des humains décident de l’approche et des compromis et écrivent le plan, et un pair relit le plan. Ensuite, un agent écrit le code et un agent de revue compare le code au plan, et ces deux étapes se répètent jusqu’à ce que le code corresponde au plan. Le code part alors en production sans qu’aucun humain ne le lise. À voir sur la page.

Une fois que la boucle ressemble à ça, la place de la revue par les pairs saute aux yeux : avant que la boucle démarre.

Relisez le plan, puis arrêtez de lire

Les plans ont droit à une vraie revue, parce que les gens y tiennent de nouveau. Quand quelqu’un commente aujourd’hui une pull request de Dylan, sa réaction honnête, c’est : « Je n’ai même pas lu ce code. Si ça se trouve, vous êtes le premier à l’avoir lu. » Quand quelqu’un commente son plan, il argumente, parce qu’il en a écrit chaque ligne et sait pourquoi chacune est là.

Il traite un plan approuvé comme un changement pré-approuvé. La plupart des dispositifs de conformité connaissent déjà l’idée : un changement bien défini peut être approuvé à l’avance, tant que vous faites exactement ça. La boucle ne peut pas se terminer tant que le code ne correspond pas à un plan approuvé, donc le code part en production sans seconde revue humaine.

Deux contrôles gardent le système honnête :

Des humains vérifient par sondage un petit pourcentage des comparaisons entre plan et code, pour s’assurer que l’agent de revue ne se trompe pas.
Si l’agent de code trouve une meilleure idée, ou une vraie raison de ne pas suivre le plan, il consigne un écart, et un humain en prend acte.

Overmind était en plein audit au moment de la conférence. Dylan est convaincu que le process est conforme, et il le saura à la fin de l’audit.

L’outillage n’a aucune interface utilisateur. Les plans s’écrivent dans Claude Code ou dans n’importe quel harnais (harness), et envoyer un plan, le récupérer ou laisser une revue, ce sont tous des appels MCP.

Schéma : Comment un changement arrive en production chez Overmind. Des humains écrivent un plan d’environ une page et demie, avec les compromis et leurs raisons, et une fois qu’un pair l’approuve, il compte comme un changement pré-approuvé. La boucle until tourne sur des agents : l’un écrit le code, un autre le compare au plan, et la boucle ne peut pas se terminer tant qu’ils ne correspondent pas. Le résultat part en production sans seconde revue humaine. Deux contrôles gardent le système honnête : des humains vérifient par sondage un petit pourcentage des comparaisons entre plan et code, et quand l’agent de code s’écarte du plan, pour une meilleure idée ou une vraie raison, il consigne un écart dont un humain prend acte. Il n’y a pas d’interface utilisateur : les plans s’écrivent dans Claude Code ou dans n’importe quel harnais, et les envoyer, les récupérer et les relire, ce sont des appels MCP. À voir sur la page.

Trois semaines plus tard

L’équipe a changé de process en une semaine, puis a comparé les trois semaines suivantes aux trois précédentes. Le nombre d’issues terminées a triplé, celui des commits aussi. Le lead time, entre le moment où un ticket est pris et celui où il tourne en production, est tombé de 3,2 jours à 1,3.

Ce sont les chiffres d’une petite équipe, trois semaines contre trois semaines, mesurés par l’entreprise elle-même. Et Overmind vend désormais un produit construit sur exactement cette idée : prenez la conférence comme un argument solide, venant de quelqu’un qui a un intérêt dans l’affaire.

Schéma : Les résultats d’Overmind dans les trois semaines qui ont suivi le changement, comparés aux trois semaines d’avant. Les issues terminées ont été multipliées par trois. Les commits ont été multipliés par trois. Le lead time, entre le moment où un ticket est pris et celui où il tourne en production, est passé de 3,2 jours à 1,3 jour, dessiné en deux barres à l’échelle. À voir sur la page.

Le goulot d’étranglement, c’était l’attention

L’équipe n’a jamais passé 90 % de ses journées en revue de code, donc le facteur 3 ne vient pas du temps de revue économisé. Sa réponse : l’attention. Les pull requests obligeaient à jongler avec trop de balles à la fois et à changer de contexte en permanence.

L’ancienne chronologie d’un changement : environ 3 heures à écrire le code, 15 minutes à ouvrir la pull request, une journée et demie à attendre un relecteur débordé, puis une heure d’allers-retours. Vous ne pouvez rien en oublier, parce que vous êtes le seul à comprendre le code. Le temps qu’un commentaire revienne, il avait écrit 15 000 lignes de plus et ne se souvenait plus de ce qu’il essayait de faire, au point qu’abandonner le changement pouvait être plus simple que de s’y replonger. Environ quatre heures et demie de travail ont vécu dans sa tête pendant une quarantaine d’heures.

Un plan s’écrit plus vite, et se relit beaucoup plus vite, que 3 000 lignes de Go. Une fois approuvé, vous le retenez comme la description du fonctionnement du système. Le code n’existe pas encore, mais il existera dans trois heures environ, parce qu’il n’y a pas d’autre sortie de la boucle. Ça coûte deux heures d’attention, à peu près.

Schéma : Combien de temps un changement vit dans votre tête, sur une échelle de 40 heures. Avec la revue de pull request : environ 3 heures à écrire le code, 15 minutes à ouvrir la pull request, environ une journée et demie à attendre un relecteur, puis une heure de revue. Environ quatre heures et demie de travail, et vous gardez tout ça en tête pendant environ 40 heures. Avec la revue de plan : deux heures environ pour écrire le plan et le faire relire, et c’est tout ce que vous gardez en tête, puis environ 3 heures de boucle d’agent auxquelles vous ne pensez plus. À voir sur la page.

Une recette se refuse plus facilement qu’un plat

Debout dans la cuisine, au moment de décider quoi préparer, c’est facile de dire « Je n’ai pas envie de salade. » Une fois la salade faite, vous ne pouvez plus. Demander à quelqu’un de refaire un plat demande une énergie à la Gordon Ramsay, et c’est exactement ça, rejeter une pull request. C’est dur émotionnellement, et c’est pourquoi c’étaient en général les ingénieurs les plus seniors qui s’en chargeaient.

Les plans ont changé ça. Overmind a désormais 2,8 fois plus de chances de rejeter un plan qu’elle n’en a jamais eu de rejeter une pull request, et les rejets viennent de toute l’équipe, produit compris. C’est aussi bien moins cher : un plan rejeté ajoute environ 40 minutes de lead time, alors que le moindre commentaire sur une pull request ajoutait 16 heures.

Sa grande crainte au départ, c’était de voir des agents écrire les plans et d’autres agents les relire, sans personne pour rien lire. Il dit que les chiffres montrent que ce n’est pas arrivé. Les plans sont assez courts pour que les gens les lisent, et ils y tiennent.

Ça ouvre aussi une porte aux juniors. Un junior qui ne comprend pas un plan peut en discuter avec son agent jusqu’à ce qu’il le comprenne, et rejeter ce qui n’a toujours pas de sens. Le product manager de Dylan relit les plans d’ingénierie exactement comme ça, et quand il conteste, il a raison environ 80 % du temps.

Dylan voit une victoire dans les 8 % de plans abandonnés. Le quoi semblait bon, le comment a montré que ça n’en valait pas la peine, et personne n’a eu à le construire juste parce que c’était déjà dans le sprint.

Schéma : Une recette face à un plat. Avant que quoi que ce soit soit cuisiné, il est facile de dire je n’ai pas envie de salade : c’est un plan, et toute l’équipe rejette des plans désormais, produit compris. Une fois le plat cuisiné, le renvoyer demande une énergie à la Gordon Ramsay : c’est une pull request, et en général seuls les ingénieurs les plus seniors le faisaient. Le coût d’une objection, à l’échelle : un plan rejeté ajoute environ 40 minutes de lead time, le moindre commentaire sur une pull request ajoutait 16 heures. Overmind a 2,8 fois plus de chances de rejeter un plan qu’elle n’en a jamais eu de rejeter une pull request, les objections du product manager sur les plans sont justes environ 80 % du temps, et 8 % des plans sont abandonnés avant que le moindre code existe. À voir sur la page.

Le comment compte toujours

Il a conclu en contredisant une phrase de Paul Graham : « Quand n’importe qui peut fabriquer n’importe quoi, ce qui fait la différence, c’est ce que vous choisissez de fabriquer. » Pour Dylan, ce qui fait la différence, c’est toujours la façon dont vous le fabriquez.

Deux ordinateurs portables peuvent avoir exactement la même fiche technique et être des produits complètement différents. La différence, ce sont des centaines de décisions sur le comment, prises en cours de route, et ce sont elles qui décident si un produit est performant, s’il tient la charge et s’il reste facile à déboguer. Son conseil : ne restez pas en bas d’une boucle où l’agent prend ces décisions à votre place, et refusez les outils qui vous y mettent.

Ce qui change, c’est le niveau auquel vous y répondez. Vous ne vous souciez plus de l’organisation des fichiers ni du nom des fonctions. Vous décidez toujours de la façon dont les données circulent, dont l’authentification fonctionne et dont le système gère les pannes.

Schéma : Le comment compte toujours. Deux ordinateurs portables peuvent avoir exactement la même fiche technique et être pourtant des produits complètement différents, à cause des centaines de décisions sur le comment prises en cours de route. Ces décisions remontent d’un niveau. Vous les prenez toujours dans le plan : comment les données circulent, comment l’authentification fonctionne, comment le système gère les pannes. Les agents les prennent dans le code : comment les fichiers sont organisés et comment les fonctions sont nommées. Le conseil de Dylan : ne restez pas en bas d’une boucle où l’agent prend ces décisions à votre place, et refusez les outils qui vous y mettent. À voir sur la page.

Essayez

Overmind a publié son outil interne sous le nom d’until, « des tickets adossés à git, pour les humains et les agents ». Vous écrivez le plan, quelqu’un le valide, chaque section du plan devient une tâche que vos agents prennent en charge, et un agent de revue compare le code au plan, si bien que tout ce qui manque ou dépasse vous revient sous forme de décision. Pour l’instant, c’est sur liste d’attente uniquement, et le site cite Claude Code, Cursor, Codex, Pi, Factory Droid, Amp et OpenCode.

L’argument existe aussi sous forme de manifeste, AI Is Not Your Peer, signé Dylan Ratcliffe, James Lane et David Schmitt. Sa phrase clé : « L’artefact qui mérite une revue, c’est le plan que nous avons écrit avant que l’agent écrive quoi que ce soit. »

Schéma : until, l’outil qu’Overmind a tiré de son outil interne, en quatre étapes d’après son site. Un : vous écrivez le plan ; chaque fonctionnalité commence par un plan, et le plan vous appartient. Deux : quelqu’un le valide ; aucun agent ne démarre tant qu’une personne n’a pas dit oui. Trois : les agents prennent les tâches ; chaque section du plan devient une tâche avec son propre nom, et vos agents les prennent en charge. Quatre : vérifier l’écart ; un agent de revue compare le code au plan, et tout ce qui manque ou dépasse vous revient sous forme de décision. L’outil est sur liste d’attente, et le site cite Claude Code, Cursor, Codex, Pi, Factory Droid, Amp et OpenCode. À voir sur la page.

Pour aller plus loin :

Pull Requests Are Dead, Long Live Peer Review, la conférence, 25 minutes
AI Is Not Your Peer, le manifeste
until, l’outil de revue de plan, sur liste d’attente
L’usine logicielle agentique, c’est celle de 2022 avec une seule case changée, là où la revue est devenue mon goulot d’étranglement
Ce qui casse quand un agent IA gère un vrai commerce, une autre conférence d’AGNTCon + MCPCon

Regardez la conférence, puis essayez de relire votre prochaine tâche d’agent sous forme de plan, avant que le moindre code existe. Dites-moi si votre lead time bouge.

Une commande pour faire lire votre Jira à GitHub Copilot, et voir ce que coûte chaque réponse

2026-10-12T00:00:00Z

GitHub Copilot peut lire vos tickets Jira et vos pages Confluence. Il lui faut juste, au préalable, un serveur MCP, un jeton d’API Atlassian et deux fichiers de config dans deux formats différents. pilotkit fait tout ça en une commande, pilotkit setup, et ajoute un petit bureau local, une page de chat qui affiche ce que chaque réponse a coûté en crédits IA.

C’est open source et sur npm : npm install -g pilotkit. Tout est parti d’un bureau de ce genre que je fais tourner au travail. pilotkit, c’est la version que les collègues peuvent installer sur leur propre PC sans que je sois assis à côté d’eux.

Copilot ne voit pas encore vos tickets

Une licence Copilot donne accès au chat, au mode agent dans VS Code et à une CLI. Aucun des trois ne sait que votre site Atlassian existe.

Le faire à la main, c’est installer un serveur MCP, créer un jeton d’API et, en général, le coller dans un fichier JSON, puis enregistrer le serveur deux fois : copilot mcp add pour la CLI Copilot, et un mcp.json pour VS Code dans un autre format. Facile à faire une fois pour soi, fastidieux quand il faut y guider toute une équipe.

Schéma : Deux façons de connecter Copilot à Jira et Confluence. À la main, quatre tâches : installer un serveur MCP, créer un jeton d’API Atlassian et le coller dans un fichier JSON, enregistrer le serveur dans la CLI Copilot avec copilot mcp add, et écrire un mcp.json pour VS Code dans un autre format. Avec pilotkit, une seule commande, pilotkit setup : le jeton va dans le trousseau du système et jamais dans un fichier, et le serveur est enregistré dans les deux clients sans toucher aux autres serveurs. À voir sur la page.

Ce que fait une seule commande

Le setup enchaîne trois vérifications et n’enregistre que ce qui a réussi :

Copilot. Il trouve la CLI Copilot, propose de l’installer et vous connecte avec copilot login.
Atlassian. Il demande le site, votre e-mail et un jeton d’API, puis les vérifie d’un seul appel à /rest/api/3/myself. Un mauvais jeton a droit à deux essais de plus.
Clients. Il enregistre le serveur dans la CLI Copilot et dans chaque mcp.json utilisateur de VS Code qu’il trouve, en conservant les autres serveurs et une sauvegarde du fichier.

Le jeton n’atterrit jamais dans un fichier de config. Sur Mac, il va dans le trousseau macOS via security -i, qui lit sa commande sur stdin. Passer le jeton en argument le mettrait dans la liste des processus, où d’autres programmes lancés sous votre compte peuvent le lire avec ps. Sur Windows, c’est un fichier que seul votre compte Windows peut déchiffrer (DPAPI), et sur Linux, c’est le Secret Service.

Un bug que j’ai attrapé avant qu’il ne fasse de victime : avec Homebrew, le chemin que Node donne pour lui-même pointe dans un dossier Cellar versionné. Enregistrez celui-là, et la commande casse au prochain brew upgrade. Le setup enregistre maintenant le chemin opt/, qui survit aux mises à jour.

Schéma : Ce que fait pilotkit setup, en trois vérifications. Un, Copilot : il trouve la CLI Copilot, propose de l’installer et se connecte avec copilot login. Deux, Atlassian : il demande le site, l’e-mail et un jeton d’API, et les valide avec un appel à /rest/api/3/myself ; un mauvais jeton a droit à deux essais de plus. Trois, clients : il enregistre le serveur dans la CLI Copilot et dans chaque mcp.json utilisateur de VS Code, en conservant les autres serveurs et une sauvegarde. Le jeton est stocké dans le trousseau macOS, dans un fichier protégé par DPAPI sous Windows ou dans le Secret Service sous Linux, jamais dans un fichier de config. À voir sur la page.

Sept outils, tous en lecture seule

Le serveur MCP a sept outils : whoami, jira_my_issues, jira_search, jira_get_issue, jira_list_projects, confluence_search et confluence_get_page. Ils n’envoient que des requêtes GET, avec votre propre compte Atlassian, donc Copilot voit ce que vous verriez dans un navigateur, et rien de plus. Il ne peut ni commenter, ni déplacer un ticket, ni modifier une page. Besoin d’un commentaire ? Demandez un brouillon et collez-le vous-même.

Ils renvoient aussi du texte court, exprès. Jira stocke les descriptions en ADF, un arbre JSON, et Confluence stocke les pages en XHTML. Les deux sont verbeux. Chaque caractère renvoyé par un outil repart vers le modèle à chaque appel suivant du chat, donc pilotkit les convertit en Markdown compact et coupe par défaut une description à 6 000 caractères et une page à 8 000.

Schéma : Les sept outils de pilotkit, tous en lecture seule : whoami, jira_my_issues, jira_search, jira_get_issue, jira_list_projects, confluence_search et confluence_get_page. Aucun outil n’écrit : ni commentaire, ni transition, ni modification de page. Leur sortie est courte exprès : l’ADF de Jira et le XHTML de Confluence deviennent du Markdown compact, avec par défaut une description coupée à 6 000 caractères et une page à 8 000, parce que chaque caractère renvoyé par un outil repart avec chaque appel suivant au modèle. À voir sur la page.

Le plus amusant : ce que coûte une réponse

Copilot facture en crédits IA sur un quota mensuel, et la fenêtre de chat ne vous dit pas ce qu’une question vient de dépenser. Alors pilotkit start ouvre un bureau sur 127.0.0.1:8717 qui fait tourner Copilot via le Copilot SDK officiel, et qui compte.

Après chaque appel au modèle, le SDK envoie un événement assistant.usage. Son champ copilotUsage.totalNanoAiu donne le coût en nano-unités IA (nano AI units), et il en faut 1 000 000 000 pour faire un crédit. Le bureau stocke ce coût par appel dans SQLite et affiche le total sous chaque réponse, avec un tableau des appels au modèle et des appels d’outil qui l’ont produite.

Ma première vraie question, sur mes tickets Jira ouverts, avec Claude Haiku 5.5 : 2 appels au modèle, 1 appel d’outil, 0,12 crédit. Le premier appel a demandé jira_my_issues, le second a rédigé la réponse. Une relance dans le même chat a coûté 0,03.

Quand un appel revient sans coût, le bureau l’estime à partir du prix des tokens du modèle et le marque d’un ≈. Chaque chat a aussi un plafond, 60 crédits par défaut, que Copilot applique lui-même via sessionLimits.maxAiCredits. Copilot refuse un plafond inférieur à 30.

Schéma : Ce qu’a coûté une réponse, sur un vrai essai. Un : un appel au modèle lit la question et demande jira_my_issues. Deux : l’appel d’outil lit Jira avec votre propre compte. Trois : un second appel au modèle rédige la réponse à partir du résultat. Avec Claude Haiku 5.5, cette première question a pris 2 appels au modèle et 1 appel d’outil, pour 0,12 crédit ; une relance dans le même chat a coûté 0,03. Chaque chat a un plafond, 60 crédits par défaut. Le coût vient de l’événement assistant.usage que le Copilot SDK envoie après chaque appel au modèle : un crédit vaut 1 000 000 000 de nano-unités IA. À voir sur la page.

Verrouillé sur cette machine

Un bureau qui dépense des crédits ne devrait répondre à personne d’autre. Il n’écoute que sur 127.0.0.1, mais cela seul ne suffit pas : une page web que vous visitez peut toujours envoyer des requêtes à localhost. Il vérifie donc deux choses de plus.

L’en-tête Host doit valoir 127.0.0.1 ou localhost. Un nom DNS qui pointe vers 127.0.0.1 reçoit un 421, ce qui bloque le DNS rebinding. Et chaque écriture exige un en-tête X-Pilotkit: 1. Un formulaire ou une image sur un autre site ne peut pas en envoyer, donc il reçoit un 403 et ne peut pas dépenser vos crédits.

À l’intérieur, les sessions Copilot du bureau ne voient que les outils pilotkit. Un gestionnaire de permissions refuse le shell, les fichiers, les URL et les autres serveurs MCP, avec une raison que le modèle peut lire.

Schéma : Qui peut utiliser le bureau. Vous, dans votre propre navigateur, sur 127.0.0.1 port 8717 : vous y accédez. Un formulaire ou une image sur un autre site n’envoie pas d’en-tête X-Pilotkit, donc son écriture reçoit un 403. Un nom DNS qui pointe vers 127.0.0.1 arrive avec un mauvais en-tête Host et reçoit un 421. Et dans le bureau, un modèle qui demande un shell est refusé par le gestionnaire de permissions, avec la raison. Les chats du bureau ne voient que les sept outils de pilotkit. À voir sur la page.

Votre logo, pas le mien

Je l’ai fait pour des collègues, donc il doit ressembler à l’outil de leur entreprise, pas à mon projet perso. Mais un logo d’entreprise est une marque déposée, et il n’a rien à faire dans un dépôt public.

Le package reste donc neutre, et un pack de marque porte l’identité visuelle : un dossier avec un brand.json et un logo, partagé en interne sur un drive ou une URL intranet.

pilotkit setup --brand ./brand-acme

Il définit le nom, le logo, la couleur d’accent et la phrase d’accueil sur le bureau et dans le setup, et peut pré-remplir le site Atlassian. Le dépôt fournit un seul exemple, pour une entreprise qui n’existe pas : Acme.

Schéma : Où vit l’identité visuelle. Le package public pilotkit est neutre : le nom, le logo et la couleur de pilotkit, plus un pack d’exemple pour une entreprise inventée, Acme. Le pack d’une entreprise reste en interne, sur un drive ou une URL intranet : son nom, son logo et sa couleur d’accent, une phrase d’accueil et des liens d’aide, et le site Atlassian pré-rempli. Il s’applique avec pilotkit setup --brand suivi du dossier ou de l’URL. À voir sur la page.

Essayez-le

npm install -g pilotkit
pilotkit setup
pilotkit start

Il vous faut Node 22.13 ou plus récent, un abonnement Copilot et un site Atlassian Cloud. Une fois le setup fait, les mêmes outils marchent aussi dans le mode agent de VS Code et dans la CLI Copilot. pilotkit doctor vérifie chaque élément et dit quoi lancer quand quelque chose cloche.

Schéma : Démarrer en trois étapes. Un : l’installer depuis npm avec npm install -g pilotkit ; il faut Node 22.13 ou plus récent. Deux : lancer pilotkit setup pour se connecter à Copilot et brancher Atlassian. Trois : lancer pilotkit start et poser ses questions sur le bureau, ou utiliser les mêmes outils dans le mode agent de VS Code ou dans la CLI Copilot. Testé sur macOS avec un vrai site Jira et Confluence Cloud ; Windows et Linux ne sont pas encore vérifiés. À voir sur la page.

C’est une toute première version, la v0.1, sous licence Apache-2.0, sur npm. Je l’ai testé sur macOS avec un vrai site Jira et Confluence Cloud : les sept outils, le bureau, sur ordinateur comme sur téléphone, et les garde-fous ci-dessus. Windows et Linux ne sont pas encore vérifiés, donc si vous le lancez là-dessus, dites-moi ce qui casse. Les issues sont ouvertes sur GitHub.

GitHub Copilot est une marque de GitHub ; Atlassian, Jira et Confluence sont des marques d’Atlassian. pilotkit est un projet indépendant.

Forkez le harnais de votre agent, gardez le meilleur

2026-10-11T00:00:00Z

Tout ce qu’on peut modifier autour d’un agent de code n’est que du code et du texte : le CLAUDE.md, les sous-agents, les skills, les outils, la politique de mémoire. Alors quand votre boucle d’agent cale, ne pariez pas sur un seul correctif. À l’AGNTCon + MCPCon Europe à Amsterdam, Fausto Albers a montré la méthode de son équipe : un méta-agent écrit plusieurs versions du harnais (harness), les fait toutes tourner sur la même tâche face à une éval placée hors de la boucle, et garde celle qui gagne sur ce que vous comptez comme coût. Les perdantes sont stockées aussi.

Il ouvre sur une ironie. Attention is all you need, et voilà que l’attention est devenue la ressource rare. Depuis 2022, le travail qu’il peut confier à l’IA a énormément grandi, et son attention n’a pas suivi cette courbe. Ses agents prennent des milliers de décisions vers des objectifs qu’il leur fixe, et il n’est pas là pour la plupart d’entre elles. D’où la question du talk : comment construire un système qui sait ce qui compte pour vous, et ce que vous comptez comme un coût ?

Une poutre en acier, dessinée en 2D

Fausto dirige WonderWhy, qui travaille étroitement avec le laboratoire d’IA appliquée aux jumeaux numériques industriels de l’Amsterdam University of Applied Sciences, et il a cofondé l’AI Builders Club à Amsterdam. Il a une formation de sociologue et a possédé des bars à cocktails et des restaurants. C’est comme ça qu’il est arrivé dans la tech : une startup qui utilisait le machine learning pour prédire les préférences gustatives des clients de l’hôtellerie-restauration.

Son cas vient d’une entreprise du secteur de l’acier. Ses machines CNC savent quoi faire dès qu’elles reçoivent des instructions compilées à partir d’un modèle 3D valide. Mais beaucoup de ses clients ne reçoivent jamais de modèle CAO 3D. Ils reçoivent un plan PDF 2D de la poutre, une copie avec perte du modèle 3D, et un ingénieur formé reconstitue le reste à la main.

Il y a quelques mois encore, transformer ce plan en modèle 3D n’était pas possible, et son équipe s’est retrouvée bloquée. Alors ils ont interrogé les ingénieurs. Chacun avait le PDF à gauche et un logiciel de CAO à droite, et reconstruisait la poutre étape par étape : en se trompant, en se corrigeant, en se construisant une représentation spatiale de la pièce dans la tête. C’est exactement ce qu’ils ont laissé faire aux agents, et ça marche. Ils l’ont livré en septembre. Ça coûte encore un peu d’argent à faire tourner, et ils entraînent un modèle open source sur le supercalculateur néerlandais pour que ça ne coûte presque plus rien.

Schéma : Le cas de l’acier. Ce que le client envoie : un plan PDF 2D de la poutre, une copie avec perte du modèle 3D qu’il faut un ingénieur formé pour lire. Ce qu’il faut à la machine CNC : des instructions compilées à partir d’un modèle CAO 3D valide. Les ingénieurs travaillent avec le PDF à gauche et la CAO à droite, et reconstruisent la poutre étape par étape : dessiner une partie, repérer l’erreur, la corriger, continuer. L’équipe de Fausto a laissé les agents faire tourner cette même boucle. À voir sur la page.

Puis la phrase qui prépare tout le reste du talk : son équipe n’a pas écrit une seule ligne de cette application. Elle a conçu le système qui l’a construite.

Le harnais, c’est la partie que vous pouvez modifier

Sa petite histoire des dernières années : le prompt engineering, puis le context engineering, et maintenant il s’agit de concevoir le harnais et de faire tourner la boucle.

Il est précis sur ce que « harnais » veut dire ici. Deux choses qu’il ne peut pas changer : le modèle de fondation, et le harnais extérieur, c’est-à-dire l’environnement de code, Claude Code, Codex ou ce que vous utilisez. Tout ce qu’il y a à l’intérieur, il peut le changer, et ce n’est que du code et du texte :

les instructions, CLAUDE.md et AGENTS.md
les sous-agents, leurs rôles et leur coordination
le contexte
la politique de mémoire (« pas d’apprentissage sans mémoire »)
les skills et les fonctions

Ça fait beaucoup de boutons. Réglez-les autrement et la même tâche donne un autre résultat. Et dans la pratique, dit-il, les agents construisent déjà ces harnais, eux aussi.

Schéma : Ce que vous pouvez changer, et ce que vous ne pouvez pas changer. Impossible à changer : le modèle de fondation, et l’environnement de code comme Claude Code ou Codex. Modifiable, parce que ce n’est que du code et du texte : les instructions dans CLAUDE.md et AGENTS.md, les sous-agents et leurs rôles, leur coordination, le contexte, la politique de mémoire, puisqu’il n’y a pas d’apprentissage sans mémoire, les skills et les fonctions. Réglez ces boutons autrement et la même tâche donne un autre résultat. À voir sur la page.

Gardez le juge hors de la boucle

Autour du harnais tourne la boucle : agir, vérifier le résultat, recommencer. La vérification ne peut pas vivre dans le harnais. Plus les modèles deviennent capables, plus ils excellent au reward hacking, donc l’éval doit se trouver hors du système. Ce peut être un agent ou du simple code déterministe. Ce qui compte, c’est qu’elle ne fasse pas partie de ce qui est noté.

Le retour atterrit dans des fichiers sur disque, et ces fichiers servent d’entrée à l’itération suivante. Chaque tour de boucle peut donc repartir d’une fenêtre de contexte vierge au lieu d’une conversation toujours plus longue. Ça compte aussi pour le coût : ma note TokenOps explique comment le coût en entrée d’une longue conversation d’agent croît avec le carré du nombre de tours.

Schéma : La boucle autour du harnais, avec le juge à l’extérieur. Une limite en pointillés marque le système qu’on améliore. À l’intérieur : le harnais, la partie modifiable, qui exécute la tâche, et les fichiers sur disque où le retour est enregistré. À l’extérieur : l’éval, un agent ou du simple code déterministe, jamais ce qui est noté. Elle doit rester dehors parce que plus le modèle est capable, plus il sait tricher avec une vérification qu’il peut atteindre. La boucle : le résultat du harnais franchit la limite vers l’éval ; la note de l’éval revient et est enregistrée sous forme de fichiers ; l’itération suivante lit ces fichiers et démarre avec une fenêtre de contexte vierge, et la boucle repart. À voir sur la page.

Surveillez le coût par changement accepté

Le chiffre qu’il trouve le plus utile, c’est le coût par changement accepté. Chaque itération coûte quelque chose, et l’éval est votre indicateur de progression vers l’objectif. Quand le coût continue de monter et que la progression stagne, vous avez atteint les rendements décroissants. La boucle a toujours l’air très occupée. Votre carte bancaire, elle, brûle.

C’est le moment de s’arrêter et de se demander ce qui manque au harnais, puisque ce n’est que du code et du texte que vous pouvez changer.

Et le coût ne veut pas seulement dire des euros. Si un client a un budget à six chiffres et que le problème, c’est le temps, dépenser beaucoup de tokens peut être le choix raisonnable.

Schéma : Un schéma du coût par changement accepté, sans données réelles. Au fil des itérations de la boucle, la progression telle que l’éval la note monte vite, puis s’aplatit. Le coût par changement accepté reste bas au début, puis grimpe. Au-delà du point où la progression stagne commence la zone des rendements décroissants : la boucle a toujours l’air occupée, et la carte bancaire brûle. C’est le signal pour se demander ce qui manque au harnais. À voir sur la page.

Trois harnais, une tâche

Voici la partie que je volerais. Quand une boucle cale, le réflexe habituel, c’est de réfléchir à ce qui pourrait être différent, d’écrire une nouvelle version du harnais et de l’essayer. L’équipe de Fausto confie plutôt ça à un méta-agent : un agent, ou un système plus gros, qui lit tous les signaux que produit le harnais de code.

Le méta-agent n’écrit pas un nouveau harnais. Il en écrit trois, ou beaucoup plus. L’un reçoit d’autres instructions, un autre change l’ordre du travail, un troisième ajoute ou retire un outil. Chaque version exécute la même tâche, l’éval la note, et vous comparez le résultat et le coût avec l’original.

Chaque version entre dans une base de données comme instantané de l’environnement de code. Celle qui s’en sort le mieux, selon ce qui compte pour vous, devient le nouveau harnais. Les autres restent dans la base avec leurs évals et leurs traces, parce qu’elles pourraient servir : ce qui a réglé un problème dans un projet pourrait en régler un dans le suivant.

Schéma : Trois harnais, une tâche. Un méta-agent lit tous les signaux que produit le harnais de code et écrit des variantes : une avec d’autres instructions, une avec un autre ordre de travail, une avec un outil ajouté ou retiré. L’original et les variantes exécutent tous la même tâche, et une éval externe note chacun sur le résultat et le coût, le coût étant ce qui compte pour vous en ce moment. Le meilleur est gardé comme nouveau harnais. Chaque version entre dans une base d’instantanés avec son éval et ses traces, les perdantes aussi, pour qu’on retrouve ce qui a marché dans le projet suivant. À voir sur la page.

Pendant les questions, quelqu’un l’a interrogé sur les optimiseurs de prompts comme GEPA. Il en a utilisé dans MLflow sur un autre projet, ainsi que DSPy, et voit tout ça comme une forme d’apprentissage par renforcement, d’algorithmes évolutionnaires. Pour aller plus loin, il a cité l’article Hyperagents de Meta, qui s’appuie sur la Darwin Gödel Machine, et JIT-Agent, qui entraîne un modèle open source à générer des harnais. Il utilise aussi celui-là.

Le symbole que personne n’avait mis dans le harnais

L’exemple qui a rendu tout ça concret vient du projet acier. Un harnais donnait au pipeline, la version A, un moyen de recadrer les plans techniques et de zoomer sur les détails. Ce qu’il ignorait, c’est que certains tout petits symboles sur ces plans sont très importants. Cette connaissance n’était pas dans le harnais.

Les évals ont calé. C’est un signal, mais il ne dit pas ce qui ne va pas ni quoi changer. Ils ont exploré beaucoup de pistes et ont abouti à une base de données de ces symboles. Le harnais suivant a donné au pipeline un moyen de les consulter, et c’est devenu la règle à partir de là.

Schéma : L’histoire du symbole en trois étapes. Un : la version A du harnais permet au pipeline de recadrer le plan et de zoomer sur les détails, mais elle ne sait pas que les petits symboles comptent. Deux : les évals calent, ce qui est un signal mais pas un diagnostic, puisque ça ne dit pas ce qui manque. Trois : le harnais suivant donne au pipeline un moyen de consulter les symboles dans une base de données. Cette consultation est devenue la règle pour les harnais suivants. À voir sur la page.

Le coût est un état d’esprit

Tout garder pose le problème suivant. Avec mille harnais dans la base, comment trouver celui qui convient à une nouvelle situation ? Sa réponse s’appuie sur la façon dont les gens se souviennent. Nous ne nous rappelons pas en empilant les détails, et les systèmes que nous construisons fonctionnent très différemment de la mémoire humaine. Il pense qu’on peut en tirer des leçons.

Son exemple : la même situation, confiée à deux agents, humains ou IA. L’un sait que l’argent n’est pas un problème et qu’il y a assez de temps. Il peut se permettre d’être curieux. La curiosité coûte cher, apprendre coûte cher, et ça peut rapporter gros. L’autre sait que le projet doit être livré. Il n’y a plus de place pour explorer : il faut juste vérifier.

Il est prudent sur ce point. Il ne dit pas qu’une IA a des émotions. Il dit que des états d’esprit comme la curiosité, l’inquiétude ou l’urgence peuvent représenter ce que nous comptons comme coût. Aujourd’hui, un agent de code avec un objectif a à peine conscience de ce qui compte pour vous. Il essaie juste d’atteindre l’objectif face à une éval quelconque.

Schéma : La même situation, deux façons de compter le coût. Curieux : l’argent n’est pas un problème et il y a assez de temps, donc l’agent peut explorer plusieurs chemins et essayer des choses ; apprendre coûte cher, et ça peut rapporter gros. Pressé : le projet doit être livré, donc pas de place pour explorer, il faut juste vérifier, une chose après l’autre. Ces états d’esprit ne sont pas des émotions de l’IA. Ils représentent ce que vous comptez comme coût, ce que les agents de code d’aujourd’hui savent rarement. À voir sur la page.

Où en est mon propre harnais

Il a conclu sur quatre choses à retenir : laisser les méthodes utiles survivre à la tâche, bien réfléchir à ce que veut dire le coût, parce que c’est bien plus que des tokens, laisser des points de vue concurrents orienter la suite, et apprendre.

Ma propre configuration, c’est l’intérieur de son schéma. Un CLAUDE.md par dossier, 26 skills à moi, un hook qui refuse d’ouvrir une pull request sans numéro d’issue, et un dossier de mémoire d’environ 200 fichiers d’un fait chacun. Quand je corrige un agent, il enregistre la leçon avec un pourquoi, et la session suivante la lit. Une partie de mon harnais est donc déjà écrite par des agents.

Mais chaque changement est une seule variante, gardée parce que je l’ai décidé. Pas d’instantanés, pas de course entre deux versions sur la même tâche. Les revues jugent chaque changement de code ; rien ne juge le harnais lui-même. C’est cette habitude du pari unique que l’équipe de Fausto a dépassée.

1 · moi, aujourd’hui

Un correctif, à la main

Une règle écrite après une erreur, gardée parce que je l’ai décidé.

Une éval externe

Une boucle jugée

Chaque exécution notée de l’extérieur, le coût par changement accepté en vue.

Un méta-agent

3 · l’équipe de Fausto

Des variantes, on garde la meilleure

Plusieurs harnais sur la même tâche, chaque instantané stocké.

Le chiffre qui me manque, c’est son coût par changement accepté. Meterlex chiffre déjà chaque session que je lance, mais rien ne relie ça aux changements qui ont été mergés.

Le talk dure 18 minutes. Le découpage du harnais est à 6:29, les variantes à 10:01 et l’histoire du symbole à 11:59. Si vous avez déjà mis en course deux versions d’un CLAUDE.md sur la même tâche, j’aimerais beaucoup savoir laquelle a gagné, et pourquoi.

Tailscale Serve : HTTPS pour 50 applis auto-hébergées, aucune sur Internet

2026-10-09T00:00:00Z

Je fais tourner une cinquantaine de petites applis sur un Mac mini chez moi : tableaux de bord, PWA, API pour mes applis mobiles, un Ollama local. Aucune n’est joignable depuis Internet, et aucune n’écoute non plus sur mon réseau domestique. Chaque appli n’écoute que sur 127.0.0.1, et tailscale serve la publie sur mon tailnet à l’adresse https://<machine>.<tailnet>.ts.net:<port>, avec un vrai certificat, joignable uniquement depuis mes propres appareils, par le tunnel WireGuard chiffré de Tailscale.

Une commande par appli, rien d’autre à faire tourner :

tailscale serve --bg --https 5174 http://127.0.0.1:5174

Le chemin d’une requête

Schéma : Le chemin d’une requête, dessiné en zones imbriquées. À l’extérieur, l’Internet public : personne d’autre n’a de route pour entrer, et Funnel, la fonctionnalité qui y publierait un port, est désactivé. Dedans, mon tailnet, mes propres appareils connectés à Tailscale. Un téléphone ou un portable ouvre l’URL ts.net, et la requête voyage en HTTPS dans le tunnel WireGuard jusqu’au Mac mini. Là, tailscale serve termine le HTTPS avec un certificat Let’s Encrypt et transmet la requête en HTTP simple à l’appli sur la loopback, 127.0.0.1, souvent un conteneur Docker. Le HTTP simple ne quitte jamais la machine. tailscale serve status liste 51 entrées, toutes en tailnet only. À voir sur la page.

En ce moment, tailscale serve status liste 51 entrées, toutes marquées tailnet only. Aucune n’utilise Funnel, la fonctionnalité qui publierait un port sur l’Internet public.

Pourquoi HTTPS, alors que le tunnel est déjà chiffré

WireGuard chiffre déjà le trafic entre mes appareils, donc du HTTP simple serait assez privé. HTTPS, c’est pour le navigateur. iOS n’exécute le service worker d’une PWA que sur une origine sécurisée : sans HTTPS, mes applis mobiles perdent le mode hors ligne et l’installation sur l’écran d’accueil. Tailscale émet le certificat pour le nom ts.net de la machine, donc il n’y a rien à renouveler à la main.

Un détail : utilisez le nom complet. https://<machine>:5174 échoue, parce que le certificat est émis pour le nom ts.net, pas pour le nom court.

Schéma : Pourquoi HTTPS alors que le tunnel est déjà chiffré. En HTTP simple, WireGuard chiffre quand même le trafic entre mes appareils, donc c’est assez privé, mais iOS n’exécute le service worker d’une PWA que sur une origine sécurisée : ni mode hors ligne, ni installation sur l’écran d’accueil. En HTTPS sur le nom ts.net de la machine, le service worker tourne, donc le mode hors ligne et l’installation marchent, et Tailscale émet le certificat, donc rien à renouveler à la main. Utilisez le nom complet : le nom court de la machine avec le port échoue, parce que le certificat est émis pour le nom ts.net. Le nom complet, machine point tailnet point ts.net avec le port, fonctionne. À voir sur la page.

Pourquoi la loopback, et pas le LAN

Lier l’appli à 127.0.0.1, c’est faire de tailscale serve la seule entrée. Un invité sur mon Wi-Fi ne peut pas la joindre, un routeur mal configuré non plus. Dans Docker, c’est la partie hôte du mappage de ports :

ports:
  - "127.0.0.1:5174:80"   # loopback only; tailscale serve proxies to it

Schéma : Qui peut joindre une appli liée à la loopback. Un invité sur mon Wi-Fi arrive sur l’adresse LAN du Mac mini, où rien n’écoute : il n’obtient rien. Un routeur mal configuré obtient la même chose : rien sur l’adresse LAN. Mon téléphone, sur le tailnet, passe par tailscale serve, qui relaie vers 127.0.0.1, et atteint l’appli. Dans Docker, c’est la partie hôte du mappage de ports 127.0.0.1:5174:80. 127.0.0.1 est l’adresse hôte, loopback uniquement. 5174 est le port hôte, celui vers lequel tailscale serve relaie. 80 est le port à l’intérieur du conteneur. À voir sur la page.

Quatre pièges où je suis tombé

Piège	Ce que j’ai vu	Correctif
Entrée serve perdue	L’appli répond sur `127.0.0.1`, l’URL du tailnet ne se connecte pas	L’entrée avait disparu après un redémarrage de Tailscale. Vérifier `tailscale serve status`, la rajouter
Appli liée à l’IP du LAN	Serve renvoie des erreurs, la loopback est vide	Un changement avait lié Docker à l’adresse LAN. Retour à `127.0.0.1:port`
Course au port (Ollama)	Après un redémarrage, Ollama plante en boucle sur `address already in use`	Le réglage « Expose to network » d’Ollama prenait `0.0.0.0:11434` alors que serve tenait le même port sur l’adresse du tailnet. J’ai désactivé Expose
Vérification du Host (Ollama)	403 via serve, tout va bien en local	Serve transmet l’en-tête Host `ts.net` et Ollama sur la loopback le rejette. Un petit nginx intermédiaire réécrit le Host

Les deux derniers n’ont touché qu’Ollama, mais la leçon est générale : serve relaie la requête telle quelle, donc une appli qui vérifie l’en-tête Host ou veut le port pour elle seule mérite un coup d’œil.

Schéma : Où chacun des quatre pièges casse le chemin qui va de mon appareil à l’appli en passant par tailscale serve et 127.0.0.1. Un, entrée serve perdue : la requête s’arrête à serve, parce que l’entrée a disparu après un redémarrage de Tailscale, alors que l’appli répond toujours sur 127.0.0.1. Le correctif : rajouter l’entrée. Deux, appli liée à l’IP du LAN : serve marche mais la loopback est vide, parce qu’un changement avait lié Docker à l’adresse LAN. Le correctif : revenir à 127.0.0.1. Trois, la course au port, Ollama seulement : après un redémarrage, Ollama plante en boucle sur address already in use, parce que son réglage Expose to network prenait le port 11434 sur toutes les adresses alors que serve tenait le même port sur l’adresse du tailnet. Le correctif a été de désactiver Expose. Quatre, la vérification du Host, Ollama seulement : la requête atteint l’appli, qui répond 403 parce que serve transmet l’en-tête Host ts.net et qu’Ollama sur la loopback le rejette. Le correctif : un petit nginx intermédiaire qui réécrit le Host. À voir sur la page.

Ce que je dirais à quelqu’un qui démarre

Liez chaque appli à la loopback et laissez tailscale serve être la seule porte.
Passez en HTTPS dès le premier jour si un téléphone doit l’ouvrir. Les PWA en ont besoin.
Tenez une liste des ports. Avec 50 applis, un registre de ports évite que deux applis se disputent le même numéro.
Vérifiez d’abord tailscale serve status quand une URL ne répond plus. La plupart de mes pannes venaient d’une entrée manquante, pas d’une appli cassée.

Schéma : Les quatre habitudes, un dessin chacune. Un : liez chaque appli à la loopback, pour que tailscale serve soit la seule porte ; la ligne du LAN s’arrête au mur. Deux : passez en HTTPS dès le premier jour si un téléphone doit l’ouvrir, parce que les PWA en ont besoin. Trois : tenez une liste des ports, pour que deux applis ne se disputent jamais le même numéro. Quatre : vérifiez d’abord tailscale serve status quand une URL ne répond plus, parce que la plupart de mes pannes venaient d’une entrée manquante, pas d’une appli cassée. À voir sur la page.

Ne soyez pas le meat proxy de votre équipe

2026-10-08T00:00:00Z

Quand vos agents tournent sur vos machines, votre équipe ne peut les joindre qu’en passant par vous. Peter Steinberger, le créateur d’OpenClaw, qui travaille aujourd’hui sur les agents chez OpenAI, appelle ça être un meat proxy, un proxy en chair et en os. À l’OpenAI DevDay, il a présenté sa solution : déplacer les sessions d’agents sur un serveur d’équipe partagé, où chacun peut lire, prompter ou reprendre la session de n’importe qui.

Les deux dernières conférences que j’ai résumées portaient sur les agents eux-mêmes : l’usine logicielle de Dex Horthy et les collègues IA dans Slack de MintMCP. Celle de Peter porte sur les gens autour. Dans son équipe, tout le monde avait des agents. Ils ne travaillaient pas ensemble pour autant.

Ajouter des machines n’a rien réglé

Il commence par raconter comment son installation a grossi cette année. D’abord le terminal : écran divisé, des tas de sessions Codex, un doigt sur la touche Échap pour recadrer. Les modèles se sont améliorés, il a moins eu à recadrer, alors il est passé à l’app de bureau Codex, où lancer beaucoup de sessions à la fois est plus simple. Puis son portable a manqué de disque et ses ventilateurs « faisaient un bruit de réacteur d’avion », alors il a réparti le travail sur six à dix machines : des devboxes, plus des machines dans le cloud qui lancent les tests.

Schéma : L’installation de Peter au fil de l’année, en trois étapes. D’abord le terminal : écran divisé, des tas de sessions Codex, un doigt sur Échap pour recadrer. Puis l’app de bureau Codex, où lancer beaucoup de sessions à la fois est plus simple. Puis six à dix machines : des devboxes, plus des machines cloud qui lancent les tests. Chaque étape ajoute de la puissance de calcul, et dans les trois cas ses collègues passent toujours par lui pour joindre les agents. À voir sur la page.

Rien de tout ça n’a réglé le vrai goulot d’étranglement :

Quand mes collègues voulaient s’impliquer, ils devaient toujours passer par moi. Vous voyez, on travaillait tous avec des agents, mais on ne travaillait pas vraiment ensemble.

Schéma : Par vous : six collègues joignent tous les sessions d’agents par une seule personne, qui les fait tourner sur ses propres machines et relaie chaque demande et chaque réponse. Serveur d’équipe : les sessions vivent sur un serveur partagé, et chaque collègue, vous compris, lit et prompte directement n’importe quelle session. À voir sur la page.

Meat proxy, deuxième sens

Le terme vient de Niklas Gruhn. Son billet d’août, Don’t be a meat proxy, parle de quelqu’un qui colle des réponses d’IA à ses collègues sans les lire, si bien que le collègue aurait aussi bien pu interroger l’IA lui-même. C’est une insulte qui vise une habitude.

Peter l’emploie pour quelque chose de plus large : servir d’interface avec l’IA, faire passer les messages dans un sens puis dans l’autre. Vous pouvez lire chaque mot qu’écrit votre agent et en être un quand même, si les agents n’existent que sur votre portable. C’est ce que cette conférence m’apporte de neuf. Ce n’est pas une question de discipline. C’est une question de lieu : là où vivent les sessions.

Schéma : Deux sens de meat proxy. Celui de Niklas Gruhn est une habitude : la réponse de l’IA passe par quelqu’un qui ne la lit pas, si bien que le collègue aurait aussi bien pu interroger l’IA. Celui de Peter est une question de lieu : vous pouvez lire chaque mot, mais si les agents n’existent que sur votre portable, chaque demande et chaque réponse passent quand même par vous. Ce n’est pas une question de discipline. C’est une question de lieu : là où vivent les sessions. À voir sur la page.

Montrez-moi le prompt

Sa première tentative n’était pas un serveur. Une seule phrase peut aujourd’hui produire des dizaines de milliers de lignes de code, mais la conversation qui les a produites reste sur la machine de quelqu’un. Il a relu bon nombre de PR où il comprenait ce qui avait changé, mais pas pourquoi.

Il a donc ajouté une skill qui demandait aux contributeurs de joindre à leur PR une transcription nettoyée. Très peu ont accepté, et il reconnaît qu’il a parfois refusé lui aussi. Montrer comment on parle à son agent a quelque chose d’étonnamment intime.

Quand son équipe a rendu toutes les sessions visibles, ça a été gênant pendant une journée. Ils ont lu les conversations des uns et des autres, en ont un peu ri, puis c’est devenu normal. Aujourd’hui, ils apprennent de la façon dont les autres promptent et repèrent les erreurs plus tôt.

Schéma : Quelle part du pourquoi arrive jusqu’à la personne qui relit, en trois étapes. Le diff seul montre ce qui a changé, pas pourquoi : la conversation reste sur le portable de quelqu’un. Une transcription nettoyée et facultative sur la PR : très peu ont accepté, et Peter a parfois refusé lui aussi. Toutes les sessions visibles par l’équipe : gênant pendant une journée, puis normal, et aujourd’hui ils apprennent de la façon dont les autres promptent et repèrent les erreurs plus tôt. À voir sur la page.

La démo convainc mieux que les slides. Il se réveille devant une PR où Victor, un collègue, a réduit les tableaux, le lendemain du jour où Peter les avait agrandis. L’ancien réflexe aurait été ce qu’il appelle un « message pas très californien ». À la place, il ouvre la session de travail derrière la PR. Victor avait repris la propre session de Peter, l’avait prévenu d’abord, et corrigé ce que Peter avait raté. Crise réglée avant le déjeuner.

Schéma : L’histoire de Victor en six cases. La veille, Peter agrandit les tableaux. Le lendemain matin, il se réveille devant une PR où Victor les a réduits. L’ancien réflexe aurait été un message pas très californien. À la place, il ouvre la session de travail derrière la PR. Victor avait repris la propre session de Peter et l’avait prévenu d’abord. Il avait corrigé ce que Peter avait raté : crise réglée avant le déjeuner. À voir sur la page.

Sa conclusion est sans détour : les pull requests comme façon de collaborer, ça « ne ressemble tout simplement plus à l’avenir ». Sur le serveur d’équipe, chacun voit et prompte la session de n’importe qui, donc la seule règle est de n’inviter que des gens qui peuvent mettre les mains dans vos sessions sans que ça vous gêne. Ensuite, il veut inviter les principaux contributeurs d’OpenClaw : eux reçoivent les tokens, et le projet récupère un peu de leurs idées. « Je trouve que c’est une super affaire. »

Le serveur est un lieu, pas une app

La barre latérale de ce serveur est pleine de petites apps : les temps de CI, les chiffres de la communauté (PR ouvertes, issues, merges), un journal « daily Claw » écrit à partir de tout ce qui a été mergé, un slopomètre qui pousse sans arrêt les agents à faire le ménage, des rapports d’activité et les réunions. Ils payaient un logiciel de réunion, jusqu’au jour où il s’est dit « ça, c’est un prompt ». Aujourd’hui, l’agent rejoint leurs appels Discord, rédige le compte rendu et peut répondre à voix haute.

Pour lui, un tableau de bord, c’est une session qui génère un artefact, plus une automatisation qui le tient à jour. Vous le voulez en bleu ? Dites-le à l’agent. Ça change si vite qu’il préfère parler de jellyware plutôt que de software. Et comme chaque tableau de bord est une session sur le serveur partagé, n’importe qui dans l’équipe peut le modifier, pas seulement la personne qui l’a construit.

Schéma : Un schéma de la barre latérale du serveur d’équipe, avec six petites apps : les temps de CI, les chiffres de la communauté (PR ouvertes, issues, merges), le journal Daily Claw écrit à partir de tout ce qui a été mergé, un slopomètre qui pousse sans arrêt les agents à faire le ménage, des rapports d’activité et les réunions, où l’agent rejoint l’appel Discord, rédige le compte rendu et peut répondre à voix haute. Un tableau de bord est une session qui génère un artefact, plus une automatisation qui le tient à jour ; pour en modifier un, vous le dites à l’agent, par exemple de le passer en bleu. À voir sur la page.

Il pense aussi que la CI telle qu’on la pratique n’a plus de sens, et il essaie Codex pour choisir les tests dont un changement a vraiment besoin. Il garde ce sujet pour une autre conférence.

Boucles, objectifs et goût

Vient ensuite la partie usine. Il fait tourner deux sortes de travaux au long cours :

Schéma : Deux sortes de travaux au long cours. Une boucle ne se termine jamais, elle vérifie en continu : ses exemples sont le tri des bugs venus de Discord, de X et de GitHub, plus un contrôle de performance sur chaque version quotidienne. Un objectif se termine à un état final défini : son exemple est le passage de la base de code de SQLite synchrone à un accès asynchrone à la base de données, 18 jours pour l’instant, avec plus de 100 PR mergées. À voir sur la page.

La boucle de tri, c’est celle que je copierais :

Schéma : La boucle de tri de Peter, qui ne s’arrête jamais. Écouter : de petites CLI que l’agent peut appeler scrutent Discord, X et GitHub, et les signalements sont classés par catégorie. Reproduire et corriger : une machine de test neuve par signalement, un correctif seulement pour ce qui se reproduit, et une vérification du correctif sur cette machine. Relire : un second agent relit le travail, qui est mergé tout seul s’il passe. Puis la boucle se remet à guetter le signalement suivant. À voir sur la page.

Ces boucles tournaient avant sur ses propres machines. Parfois elles s’arrêtaient, et parfois il ne savait plus trop quelle machine faisait tourner quoi. Il les déplace maintenant une par une sur le serveur d’équipe, pour que d’autres puissent les maintenir et en tirer des leçons. Le goût, c’est la partie qu’il ne déléguera pas : c’est difficile à décrire et « souvent juste une intuition ». Là où il veut arriver : un agent par projet, avec sa propre mémoire, ses automatisations, ses objectifs et ses boucles, qui reçoit de lui les grandes orientations.

On retrouve l’usine logicielle, avec un changement : l’usine est une pièce partagée, pas le terminal d’une seule personne.

Les agents ont leur propre badge

Kevin Lin, qui dirige OpenClaw Enterprise chez OpenAI, a assuré la seconde moitié. Il a publié le projet en open source : un plan de contrôle qui rend OpenClaw multi-tenant. Les contrôles qu’il a passés en revue :

le code déterministe tourne dans un conteneur séparé, dans leur cas un cluster séparé, pour qu’un agent ne puisse pas modifier son propre runtime
une sandbox pour l’accès réseau, les fichiers qu’un agent peut écrire et les dépôts sur lesquels il peut pousser
la revue automatique : un autre modèle vérifie les actions de l’agent et bloque les dangereuses avant qu’elles ne s’exécutent
les agents tournent sous leur propre identité, avec des comptes de service et leurs propres connecteurs, parce que « les agents ne se font pas passer pour les utilisateurs »

Schéma : Les quatre contrôles d’OpenClaw Enterprise en une image. Un : le code déterministe tourne dans un conteneur séparé, dans le cas d’OpenAI un cluster séparé, derrière un mur, pour que l’agent ne puisse pas modifier son propre runtime. Deux : l’agent travaille dans une sandbox qui limite son accès réseau, les fichiers qu’il peut écrire et les dépôts sur lesquels il peut pousser. Trois : chaque action passe par la revue automatique, où un autre modèle bloque les dangereuses avant qu’elles ne s’exécutent. Quatre : l’agent porte son propre badge, sa propre identité avec un compte de service et ses propres connecteurs, il ne se fait donc pas passer pour un utilisateur. À voir sur la page.

Ce dernier point, c’est tout le propos de ma note sur les collègues IA, désormais dans une plateforme open source. OpenAI fait tourner plus de 400 Claws en interne avec ces contrôles. Selon lui, si vous avez ouvert une issue Codex le mois dernier, il y a de bonnes chances qu’un agent OpenClaw l’ait triée, reproduite et, dans bien des cas, ait mergé le correctif. Il l’a présenté comme un Kubernetes pour agents. L’annonce précise qu’il est réservé à des pilotes internes jusqu’à la 1.0, prévue plus tard cette année.

Où en est ma propre flotte

Hier, j’écrivais que la prochaine étape serait que Nova, mon agent généraliste, ouvre un canal pour une tâche de code et y fasse venir Spark, mon codeur. C’est en place. Nova ouvre un canal de job dans Slack, nous invite, Spark et moi, et poste le brief. Spark construit, Nova tranche, et on ne me tague que pour des choses comme les secrets, les dépenses ou tout ce qui est destructif. Depuis ce matin, le même circuit tourne dans des fils de forum Discord.

Les agents se parlent donc au grand jour. Selon le critère de Peter, je reste pourtant à moitié proxy : le canal montre ce que Nova et Spark se disent, pas les sessions derrière ces messages, et personne d’autre que moi ne peut les ouvrir. Pour une équipe d’une personne, ça va. Le jour où quelqu’un travaillera avec moi sur ces projets, le serveur de Peter sera la première chose que j’essaierai.

Schéma : Où en est ma propre flotte. Au grand jour, dans un canal de job Slack ou un fil de forum Discord : Nova ouvre le job et poste le brief, Spark construit, Nova tranche, et on ne me tague que pour les secrets, les dépenses ou tout ce qui est destructif. Derrière ces messages, il y a les sessions de Nova et de Spark, que personne d’autre que moi ne peut ouvrir. Sur l’échelle de Peter, du meat proxy au serveur d’équipe, ça fait de moi un proxy à moitié. À voir sur la page.

La conférence dure 35 minutes. La slide du meat proxy est à 2:27, et l’histoire de Victor, à 11:46, est le passage que je montrerais à un responsable d’équipe. Si votre équipe partage déjà ses sessions d’agents, j’aimerais beaucoup savoir comment s’est passé ce premier jour gênant.

TokenOps : pourquoi un agent à 40 tours coûte 16×, et pas 4×

2026-10-08T00:00:00Z

Une tâche que votre agent termine en 10 tours vous coûte 1×. Laissez-le tourner 40 tours et vous vous attendriez à 4×. C’est 16×. Chaque tour renvoie le contexte accumulé par les tours précédents, donc le coût de l’entrée hors cache croît avec le carré du nombre de tours, pas en ligne droite. La parade consiste à concevoir le contexte pour que l’essentiel soit lu depuis le cache, à un dixième du prix.

C’est ainsi que s’ouvre TokenOps, un talk de quatre minutes de Gareth Bland, chief data scientist chez Microsoft Frontier Company. Il définit TokenOps comme la data science qui permet à une entreprise de continuer à décider où doivent aller ses tokens : là où ils font le plus bouger les lignes. Un talk court, trois idées à garder.

La grille tarifaire

Les fournisseurs de modèles ne facturent pas un prix unique par token. En prenant vos messages en entrée comme base 1×, voici l’échelle qu’il a montrée :

Token	Coût	Ce que c’est
Sortie	5×	Là où se fait le raisonnement, ce qu’un agent fait de plus utile
Entrée de base	1×	Les messages que vous envoyez
Écriture en cache	en plus	Payée quand la boucle écrit du contexte dans le cache
Entrée en cache	0,1×	Le contexte relu depuis le cache

La partie chère est donc aussi la partie précieuse : le raisonnement, c’est de la sortie. Ce que vous contrôlez, c’est la part de l’entrée servie par le cache.

Schéma : L’échelle de prix des tokens présentée dans le talk, en barres, avec vos messages en entrée comme base 1×. La sortie coûte 5× : c’est là que se fait le raisonnement, ce qu’un agent fait de plus utile. L’entrée de base, les messages que vous envoyez, coûte 1×. Les écritures en cache coûtent en plus, payées quand la boucle écrit du contexte dans le cache ; le talk ne leur donne pas de multiplicateur. L’entrée en cache, le contexte relu depuis le cache, coûte 0,1×. La part de l’entrée servie par le cache, c’est ce que vous contrôlez. À voir sur la page.

Les boucles rendent le coût quadratique

Les agents ne répondent plus en une seule passe. Ils procèdent par tours : agir, regarder le résultat, raisonner, agir encore. Chaque tour transporte tout ce qui l’a précédé.

Tours	Ce que vous prévoyez	Ce que coûte vraiment l’entrée hors cache
10	1×	1×
40	4×	16×

Quatre fois plus de tours, seize fois plus cher. L’ingénierie de contexte sert à faire redescendre cette courbe : gardez la partie stable du contexte en tête et inchangée, pour que le fournisseur puisse la servir depuis le cache à 0,1×.

Schéma : Pourquoi 40 tours coûtent 16 fois plus que 10 tours, à l’échelle. Les tours vont de gauche à droite, de 0 à 40. La hauteur à chaque tour est le contexte que ce tour renvoie, donc l’aire est le coût de l’entrée hors cache. Les 10 premiers tours forment un petit triangle : 1×. À gauche, l’estimation en ligne droite, quatre de ces triangles côte à côte, soit 4×. À droite, ce qui se passe vraiment : le contexte ne cesse de grandir, chaque tour relit tout ce qui le précède, et l’aire pour 40 tours est un triangle quatre fois plus large et quatre fois plus haut, seize petits triangles : 16×. La parade : garder la partie stable du contexte en tête et inchangée, pour que le fournisseur puisse la servir depuis le cache à 0,1×. À voir sur la page.

Les tokens ont-ils rapporté quelque chose ?

Le coût seul ne dit pas si la dépense en valait la peine. Bland note le travail des agents avec un score d’efficacité agentique fait de trois ratios, à lire comme un entonnoir, de tout le travail qu’un agent entame jusqu’à ce que ressentent les utilisateurs :

Achèvement autonome

Le travail terminé sans échec ni intervention humaine.

Mergé en production

Efficacité des tokens

Du travail terminé, ce qui a vraiment été livré.

Au service des utilisateurs

Création de valeur

De ce qui a été livré, ce qui a fait bouger les lignes.

Le troisième ratio, aucun tableau de bord de tokens ne peut vous le donner. Mon propre Meterlex chiffre chaque appel de modèle à partir des logs de session, ce qui couvre le côté coût. Il ne peut pas me dire si le travail d’une session a été mergé, encore moins si quelqu’un s’en est servi. Pour ça, il faut des données du dépôt et du produit, pas du fournisseur de modèles.

La courbe en S : quand arrêter de dépenser

La dernière idée porte sur la position d’un produit. Les fonctionnalités rapportent selon une courbe en S, et Bland nomme trois zones :

Zone 1

Sous-investissement

Pas encore assez de fonctionnalités pour un MVP ou un pilote.

Seuil

Zone 2

Effet de levier

Chaque nouvelle fonctionnalité ou amélioration rapporte de la valeur aux utilisateurs.

Saturation

Zone 3

Surqualité

Peaufiner l’existant, ajouter ce que personne n’a demandé.

Avec les agents, entrer en zone 3 ne coûte presque rien. Quand une fonctionnalité coûte un prompt au lieu d’un sprint, rien ne vous empêche de tomber dans la surqualité (le gold plating), si ce n’est de savoir où vous en êtes sur la courbe. C’est sa conclusion : en ingénierie agentique, ce qui compte le plus, c’est de savoir où se situe votre équipe, ou votre prochaine fonctionnalité, sur la courbe en S.

Ce que j’en retiens

Mesurez la courbe, pas la facture. Un total mensuel cache la partie quadratique. Le nombre de tours par tâche et la part de l’entrée servie par le cache disent où part l’argent.
Le coût est le haut de l’entonnoir. La dépense en tokens n’a de sens que rapportée à la part du travail mergée et à la part que les utilisateurs ont ressentie.
Dépensez là où la courbe est raide. Le token le moins cher est celui que vous ne dépensez pas en surqualité.

Schéma : Mes trois enseignements du talk, côte à côte. Un : mesurez la courbe, pas la facture. Un total mensuel cache la partie quadratique ; le nombre de tours par tâche et la part de l’entrée servie par le cache disent où part l’argent. Deux : le coût est le haut de l’entonnoir. La dépense en tokens n’a de sens que rapportée à la part du travail mergée et à la part que les utilisateurs ont ressentie. Trois : dépensez là où la courbe est raide. Sur la courbe en S des fonctionnalités, c’est dans le milieu raide que les tokens rapportent de la valeur ; le plateau du haut, c’est la surqualité, et le token le moins cher est celui que vous n’y dépensez pas. À voir sur la page.

Les collègues IA dans Slack ont besoin de leur propre identité

2026-10-07T00:00:00Z

MintMCP fait tourner 40 à 50 agents IA dans Slack. Ils ont des noms (Max s’occupe des ventes, Leo du marketing, Peter des achats), les gens leur écrivent comme à des collègues, et aucun n’emprunte le login d’un humain. Chaque agent est son propre principal de sécurité, avec sa propre identité, sa propre liste d’outils autorisés et une piste d’audit au niveau de la gateway.

C’est tiré de The Context ft MintMCP, le livestream de l’Agentic AI Foundation, où Jiquan Ngiam, cofondateur et CEO de MintMCP, a montré comment son équipe travaille avec des agents. Ma propre conférence sur ma flotte d’agents se termine sur la partie qu’une installation maison peut se permettre de sauter : supervision, traçabilité, gestion des identités. Son intervention, c’est cette partie-là.

L’identité fait passer de l’outil au coéquipier

JQ (c’est comme ça qu’il se fait appeler) découpe l’adoption de l’IA en quatre niveaux. Le plus intéressant, ce sont les marches entre eux :

Chat

Elle conseille.

Accès aux données via MCP

Cowork

Elle termine des tâches.

Identité d’agent

Collègue

Elle rejoint l’équipe.

Usines logicielles

La machine

Elle construit le logiciel.

Le niveau 2, c’est là où en sont la plupart d’entre nous. Vous branchez Claude Cowork ou un outil du même genre sur le CRM et vous demandez une présentation de prévisions. Il abat des heures de travail, mais en solo.

Le niveau 3, c’est un agent qu’on n’ouvre pas comme une app. Il vit dans Slack ou Teams, peut-être avec son propre compte et sa propre adresse e-mail, et vous lui écrivez comme vous écririez à un collègue. C’est là que l’identité des agents, le contrôle d’accès et les messages d’agent à agent commencent à compter. Le niveau 4, c’est l’usine logicielle dont j’ai parlé le mois dernier.

Du solo au multijoueur

Quand je lance Claude Code ou Codex dans un terminal, personne d’autre ne voit la session. Personne ne peut l’orienter ni reprendre là où elle s’est arrêtée. JQ appelle ça l’IA en solo.

Dans un fil Slack, plusieurs humains et plusieurs agents travaillent au même endroit, tout le monde voit ce qui se passe, et n’importe qui peut intervenir. Les gens adoptent les agents plus vite quand ils les regardent travailler, et les agents gagnent un endroit où travailler ensemble.

Un chiffre m’a surpris. Sur la gateway de MintMCP, qui traite plus de deux millions d’appels MCP et d’agents par jour, les 20 connecteurs les plus installés sont des outils de travail du quotidien : Google, Slack, Notion, Figma, HubSpot. Les ingénieurs sont arrivés en premier, mais ce sont maintenant les non-ingénieurs qui gagnent le plus de temps. Chez Modern Treasury, les agents font gagner des heures par dossier aux technical account managers.

Schéma : Solo et multijoueur. En solo, c’est Claude Code ou Codex dans un terminal : personne d’autre ne voit la session, et personne ne peut l’orienter ni reprendre là où elle s’est arrêtée. En multijoueur, c’est un fil Slack : plusieurs humains et plusieurs agents travaillent au même endroit, tout le monde voit ce qui se passe, et n’importe qui peut intervenir. En dessous, trois faits tirés de la gateway de MintMCP : elle traite plus de deux millions d’appels MCP et d’agents par jour ; ses 20 connecteurs les plus installés sont des outils de travail du quotidien comme Google, Slack, Notion, Figma et HubSpot ; et chez Modern Treasury, les agents font gagner des heures par dossier aux technical account managers. À voir sur la page.

Un fil Slack est une sandbox

La démo en direct était simple. Il a demandé à Leo, l’agent marketing, à quels événements de l’AAIF ils étaient allés et lesquels arrivaient. Leo a ouvert un fil, lancé bash et une recherche, lu Slack via le serveur MCP de Slack, et diffusé chaque étape dans le fil. Sa réponse incluait le livestream qu’on était en train de regarder.

Voici l’installation telle qu’il l’a décrite :

Porte d’entrée

Fil Slack

Humains et agents ensemble
Un fil, une session
Des planifications réveillent aussi les agents

Sandbox éphémère

Harnais de code

Claude, Codex ou harnais ouverts
Chaque étape diffusée dans Slack
Hooks de supervision · mémoire

La seule sortie

Gateway MCP

L’identité propre de l’agent
Listes d’outils et de données autorisés
Chaque appel journalisé

Mon exemple préféré vient de l’ingénierie. Dan est un agent de code sur Claude, Sam en est un sur Codex. Un humain demande à Dan une modification de leur gateway LLM. Dan lit la base de code, propose un plan et attend un feu vert. Il construit une première version et écrit à Sam, et les deux se relisent mutuellement dans le canal jusqu’à tomber d’accord. Puis Dan notifie l’humain, l’humain relit et merge, et le bot se réveille une dernière fois pour demander si la doc a besoin d’une mise à jour.

Schéma : Dan et Sam, deux agents de code, qui travaillent dans un même canal Slack. Un humain demande à Dan, un agent de code sur Claude, une modification de leur gateway LLM. Dan lit la base de code, propose un plan et attend un feu vert. Dan construit une première version et écrit à Sam, un agent de code sur Codex. Les deux se relisent mutuellement dans le canal jusqu’à tomber d’accord. Dan notifie l’humain, qui relit et merge. Puis le bot se réveille une dernière fois pour demander si la doc a besoin d’une mise à jour. Tout l’aller-retour se passe dans un canal où les gens peuvent regarder et intervenir. À voir sur la page.

Mon agent de code, Spark, fait déjà relire ses pull requests par un modèle d’une autre famille. La différence, c’est l’endroit : chez eux, tout l’aller-retour se trouve dans un canal où les gens peuvent regarder et intervenir.

Les autres qu’il a montrés : Peter relance les revues de sécurité, les documents manquants et les tenants d’essai sur les deals en cours, et notifie les gens de ce qui reste ouvert. JQ a dit qu’il ne savait plus très bien si c’est lui qui relance les bots ou eux qui le relancent. Minty répond aux clients dans leurs canaux partagés ; après un long fil sur le SSO, un client a écrit « vous avez été parfait, pas besoin d’humain, c’est tout bon pour moi ».

Leur premier agent, Max, a été mis en service en février. Ils sont vite passés d’un agent à cinq, puis à 20. Aujourd’hui, chaque nouvelle recrue crée un agent dès sa première semaine.

Chaque agent est son propre principal

Sans couche d’identité, un agent détient les identifiants d’un humain. Un agent commercial agit en tant que JQ dans le CRM, sur LinkedIn et dans Gmail, et vous perdez le contrôle, le journal d’audit et toute trace de qui a fait quoi. Son exemple : vous lui demandez de faire le ménage dans le CRM, et il comprend « faire le ménage » comme « tout supprimer ».

Chez MintMCP, chaque agent a donc :

sa propre identité et son propre périmètre, avec une liste de ce qu’il a le droit de faire
des identifiants explicites à chaque appel d’outil : un compte de service, ou un identifiant délégué qui agit pour un utilisateur, avec la chaîne de délégation enregistrée
l’OAuth géré au niveau de la gateway, renouvellement compris, parce qu’un agent en arrière-plan ne peut pas s’arrêter pour cliquer sur un écran de connexion

Schéma : Deux façons de donner accès à un agent commercial. Le login emprunté : sans couche d’identité, l’agent détient les identifiants d’un humain et agit en tant que JQ dans le CRM, sur LinkedIn et dans Gmail. Vous perdez le contrôle, le journal d’audit et toute trace de qui a fait quoi, et une demande de faire le ménage dans le CRM peut se lire comme tout supprimer. Son propre principal, comme le fait MintMCP : l’agent a sa propre identité et son propre périmètre, avec une liste de ce qu’il a le droit de faire ; chaque appel d’outil porte des identifiants explicites, soit un compte de service, soit un identifiant délégué qui agit pour un utilisateur, avec la chaîne de délégation enregistrée ; et l’OAuth est géré au niveau de la gateway, renouvellement compris, parce qu’un agent en arrière-plan ne peut pas s’arrêter pour cliquer sur un écran de connexion. À voir sur la page.

Les permissions se décident à l’exécution

C’est la partie à laquelle je n’avais pas réfléchi. L’agent doit-il lire les données en son nom propre, ou au nom de la personne qui a demandé ? Ça dépend du système. Un assistant qui lit des agendas doit utiliser les identifiants de la personne qui demande. Un agent qui suit le monitoring DevOps doit utiliser un compte de service.

Un consentement OAuth, c’est un token statique, et c’est facile à appréhender. Dans un canal, les bonnes permissions dépendent du consentement, de qui a envoyé le message, de qui d’autre verra la réponse, et de la tâche. JQ appelle ça le passage des permissions statiques aux permissions dynamiques.

Schéma : Permissions statiques et dynamiques. Statiques : un consentement OAuth est un seul token, et c’est facile à appréhender. Dynamiques : dans un canal, les bonnes permissions pour un message dépendent de quatre choses à la fois : le consentement, qui a envoyé le message, qui d’autre verra la réponse, et la tâche. Les identifiants à utiliser dépendent du système : un assistant qui lit des agendas doit utiliser ceux de la personne qui demande, et un agent qui suit le monitoring DevOps doit utiliser un compte de service. À voir sur la page.

Environ 99 % des contrôles de MintMCP restent déterministes. Sa règle : ce que vous pouvez rendre déterministe, rendez-le déterministe. Le cas difficile, c’est un fil avec une personne A, qui peut voir certaines données, et une personne B, qui ne peut pas. Si A dit « vas-y, récupère-les », c’est sans doute acceptable, comme si les deux étaient dans une salle de réunion. Ils testent un peu d’IA pour cette décision, à deux conditions : tout le monde dans le fil voit que l’accès a été accordé, et A dispose d’un bouton pour annuler.

Schéma : Le cas difficile, et la petite part des contrôles de MintMCP qu’il représente. Environ 99 % des contrôles restent déterministes, et la règle est de rendre déterministe tout ce qui peut l’être. Le reste, ce sont des cas comme celui-ci : un fil avec une personne A, qui peut voir certaines données, et une personne B, qui ne peut pas. A dit vas-y, récupère-les. C’est sans doute acceptable, comme si les deux étaient dans une salle de réunion, alors ils testent un peu d’IA pour cette décision, à deux conditions : tout le monde dans le fil voit que l’accès a été accordé, et A dispose d’un bouton pour annuler. À voir sur la page.

Verrouiller les outils à la gateway

Les scopes OAuth sont souvent trop larges, si bien qu’un agent hérite de tout ce que son utilisateur peut faire, y compris envoyer des e-mails et supprimer des enregistrements. La réponse de MintMCP se trouve dans la gateway MCP, et elle est déterministe :

les outils risqués sont refusés d’office, comme supprimer des enregistrements ou envoyer des e-mails
les agents ne détiennent jamais les clés finales, seulement un accès temporaire via la gateway
la gateway journalise chaque appel, pour qu’on puisse retrouver quel agent a fait quoi
les outils sont regroupés par rôle, pas par serveur : les ingénieurs ont Jira en lecture et écriture et Intercom en lecture seule, un agent marketing a droit à moins
les données ont aussi un périmètre : Google Drive, mais seulement ces 10 dossiers

Deux détails qui m’ont plu. L’outil fork-repository du serveur MCP de GitHub est l’un des premiers que leurs clients désactivent. Et les clients de la finance et de la santé font passer leur DLP existant sur chaque appel MCP, ce qui ajoute 100 à 200 ms.

Schéma : Le verrou déterministe de MintMCP dans la gateway MCP. L’agent ne détient jamais les clés finales, seulement un accès temporaire via la gateway. La gateway journalise chaque appel, regroupe les outils par rôle plutôt que par serveur, et donne aussi un périmètre aux données ; les clients de la finance et de la santé font en plus passer leur DLP existant sur chaque appel, ce qui ajoute 100 à 200 ms. Côté outils, les outils risqués sont refusés d’office, comme supprimer des enregistrements et envoyer des e-mails, et l’outil fork-repository du serveur MCP de GitHub est l’un des premiers que les clients désactivent. Les ingénieurs ont Jira en lecture et écriture et Intercom en lecture seule, un agent marketing a droit à moins, et Google Drive peut être limité à 10 dossiers. À voir sur la page.

J’ai appris la partie déterministe à mes dépens. En août, j’ai interdit les outils MCP de mon app de finances à la plupart de mes agents avec un motif dans la config de ma gateway. Un mois plus tard, j’ai testé : le motif ne correspondait à rien, et un agent censé être bloqué se voyait proposer les 13 outils, outils d’écriture compris. Les noms d’outils utilisaient un autre séparateur que celui que j’avais supposé. Maintenant, je vérifie une règle de refus en demandant à l’agent de lister ses outils.

Schéma : Ma propre règle de refus, en trois étapes. Un, en août : j’ai interdit les outils MCP de mon app de finances à la plupart de mes agents avec un motif dans la config de ma gateway. Deux, un mois plus tard : le motif ne correspondait à rien, et un agent censé être bloqué se voyait proposer les 13 outils, outils d’écriture compris. Les noms d’outils utilisaient un autre séparateur que celui que j’avais supposé. Trois, maintenant : je vérifie une règle de refus en demandant à l’agent de lister ses outils. À voir sur la page.

Personne n’avait demandé ce message de 6 h

La meilleure histoire est arrivée pendant les questions. À 6 h du matin, Max a posté dans le canal des deals qu’un même deal avait été attribué à deux commerciaux. JQ a commencé à déboguer le deal, puis s’est arrêté : pourquoi l’agent s’était-il réveillé pour poster ça, au fond ?

Il a fallu le journal d’audit pour le savoir. Un membre de l’équipe avait demandé quelque chose à son propre agent, cet agent avait délégué à Max, et Max avait remonté l’affaire à tout le canal. Sans la chaîne de délégation, personne ne l’aurait su.

Schéma : Le message de 6 h, remonté jusqu’à sa source. Ce que le canal a vu : à 6 h du matin, Max a posté dans le canal des deals qu’un même deal avait été attribué à deux commerciaux. Ce que montrait le journal d’audit : un membre de l’équipe avait demandé quelque chose à son propre agent, cet agent avait délégué à Max, et Max avait remonté l’affaire à tout le canal. Sans la chaîne de délégation, personne n’aurait su pourquoi Max avait posté. À voir sur la page.

C’est la prochaine phase qu’il voit venir : qui peut créer un agent, lui écrire et le modifier, qui les orchestre tous, et, selon ses mots, quel est l’équivalent des RH pour les agents.

La mémoire aussi a besoin d’un contrôle d’accès

Darren Shepherd, l’un des animateurs, a objecté. On ne peut pas étiqueter chaque phrase avec une classification de données, et à mesure que les modèles deviennent plus malins, l’IA devrait peut-être prendre davantage de ces décisions. Nous faisons confiance aux humains, a-t-il dit, à cause des processus qui les entourent, pas parce qu’ils sont fiables.

La réponse de JQ a été une seconde dimension : la mémoire. Quand son agent personnel parle à Darren, il ne doit pas partager les finances de JQ. La mémoire est donc cloisonnée (un silo par personne, par équipe, par entreprise, par client), et l’agent voit des silos différents selon la personne à qui il parle. Le même badge persistant à l’entrée, des livres différents qu’il a le droit de lire. Pour lui, cette partie relève encore largement de la R&D.

Schéma : Les silos de mémoire, tels que JQ les a décrits. L’agent présente le même badge persistant à l’entrée, quelle que soit la personne à qui il parle. Derrière, la mémoire est découpée en silos, un par personne, par équipe, par entreprise et par client, et l’agent voit des silos différents selon la personne à qui il parle. Quand l’agent personnel de JQ parle à Darren, le silo des finances de JQ reste fermé. Pour lui, cette partie relève encore largement de la R&D. À voir sur la page.

Où en est ma propre flotte

Chacun de mes agents a son propre fil Telegram. Sur la carte de JQ, c’est le niveau 2 : un humain et un agent par fil, personne d’autre pour regarder. Telegram ne transmet même pas les messages d’un bot à un autre bot, donc mes agents ne peuvent pas se parler là-bas.

Aujourd’hui, j’ai donné un compte Slack à deux d’entre eux : Nova, mon généraliste, et Spark, mon codeur. Ils vivent dans un espace de travail réservé aux agents, chacun avec sa propre app Slack, parce qu’une app correspond à un utilisateur bot. C’est la première brique d’identité. Prochaine étape : que Nova ouvre un canal pour une tâche de code et y fasse venir Spark, comme Dan fait venir Sam.

Le hic : l’offre gratuite de Slack autorise 10 apps par espace de travail, et j’ai 17 agents. Identifiants délégués, permissions à l’exécution et silos de mémoire : tout ça est encore devant moi.

Schéma : Où en est ma propre flotte. Aujourd’hui, chaque agent a son propre fil Telegram : un humain et un agent par fil, personne d’autre pour regarder, et Telegram ne transmet pas les messages d’un bot à un autre bot. Sur la carte de JQ, c’est le niveau 2. Deux d’entre eux, Nova et Spark, ont maintenant un compte Slack dans un espace de travail réservé aux agents, chacun avec sa propre app Slack, parce qu’une app correspond à un utilisateur bot : la première brique d’identité. Prochaine étape : Nova ouvre un canal pour une tâche de code et y fait venir Spark. Le hic : l’offre gratuite de Slack autorise 10 apps par espace de travail, et j’ai 17 agents, donc 7 n’y entrent pas. Encore devant moi : les identifiants délégués, les permissions à l’exécution et les silos de mémoire. À voir sur la page.

L’intervention dure 40 minutes, et les questions-réponses sur les permissions en sont le meilleur moment. MintMCP a aussi écrit un billet sur comment construire un collègue IA dans Slack. Et si vous avez résolu le cas du fil avec la personne A et la personne B, je serais ravi de savoir comment.

Les sites web ne mourront pas, ils cesseront d’être la porte d’entrée

2026-09-27T00:00:00Z

Les sites web ne vont pas disparaître. Ils perdent leur rôle de porte d’entrée. C’est la thèse que Liad Yosef, co-créateur de MCP Apps, a défendue à AGNTCon + MCPCon Europe : les assistants personnels deviennent le principal point d’entrée du web, et le site devient une surface parmi d’autres.

Je venais de passer deux semaines à rendre ce site lisible par les agents, alors cette phrase m’a arrêté net. Puis les données de son étude ont touché mon propre site de plein fouet.

Schéma : Aujourd’hui, vous ouvrez un onglet de navigateur par entreprise et vous entrez par son site. Dans le web agentique, votre assistant appelle directement le serveur MCP de chaque entreprise, et seul un petit morceau d’interface à ses couleurs, comme un plan de salle, vous revient. À voir sur la page.

Ce qu’il a vraiment dit

La conférence s’intitule MCP Apps and the agentic web, dans le même livestream que la keynote de Dex Horthy dont j’ai parlé dans la note sur l’usine logicielle. La phrase :

Il se pourrait que les sites web et les navigateurs perdent leur place de principal point d’entrée du web.

Il ne dit pas que le web meurt. Il le compare au mobile. L’ordinateur n’a pas disparu, mais les réseaux sociaux sont passés sur le téléphone et y sont restés. Personne n’ouvre Instagram sur son ordinateur. Son pari : une grande partie de ce que nous faisons sur les sites web passera aux agents de la même façon, et y restera.

Comme preuve, il a cité des entreprises qui bougent déjà : Sentry, qui vise désormais les agents en priorité (un an après que son CPO lui a parié que les sites web existeraient encore dans 25 ans), Salesforce, qui passe en headless, et DoorDash, qui sort une CLI. Il a aussi rapporté que, selon Cloudflare, le trafic des bots a dépassé le trafic humain plus vite que prévu.

Un site web sert à dire à une entreprise ce que vous voulez

C’est là que tout s’est éclairé pour moi. Quand vous arrivez sur booking.com, le site ne sait pas si vous voulez réserver un hôtel, déposer une réclamation ou vous connecter. Toute l’interface existe pour que vous puissiez exprimer cette intention à l’entreprise.

Si vous avez déjà dit à votre assistant ce que vous voulez, il n’a pas besoin de parcourir un site à coups de clics pour transmettre cette intention. Il peut simplement appeler l’entreprise.

Reste ce qu’il appelle le dernier kilomètre. Certaines choses sont pénibles à faire en texte : choisir une place dans une salle, consulter un agenda. C’est là qu’interviennent les MCP Apps. Un serveur MCP ne renvoie pas seulement des données, il peut envoyer dans la conversation un morceau de sa propre interface interactive.

Prévois quelque chose pour notre anniversaire le 14

Vous êtes libre après 19 h ce jour-là, et il y a un spectacle à 20 h. Choisissez vos places :

AgendaMCP App

11121314151617

sam. 14 · libre dès 19:00

BilletsMCP App

scène

2 places · rang BRéserver

Une illustration des MCP Apps, pas un vrai produit : chaque service envoie son propre petit morceau d’interface dans la conversation, et vous ne quittez jamais l’assistant.

Tout le monde y gagne. Ticketmaster garde sa marque, et vous savez déjà utiliser son plan de salle. L’assistant n’a pas à en inventer un : l’expert du domaine fournit le sien.

Son exemple : organiser un anniversaire. Au lieu de 20 onglets, l’assistant vous montre un extrait de Google Calendar, puis un extrait d’Amazon, et vous ne quittez jamais la conversation. Les apps ne maîtrisent plus le parcours utilisateur. Il ne leur reste que le dernier kilomètre. Il appelle ça le web presque headless.

MCP Apps a démarré il y a moins d’un an sous le nom de MCP-UI, qu’il a construit avec Ido Salomon. Anthropic et OpenAI se sont ensuite mis autour de la table avec eux pour en faire la spécification MCP Apps, publiée en janvier.

À chaque catégorie son assistant

Pour Liad, ceux qui le ressentent en premier se rangent sur un spectre. Les agents de code ont déjà changé la façon dont on choisit les outils de dev : si votre agent se tourne vers Supabase, MongoDB ou Sentry, leur activité monte, et sinon, elle baisse. Les apps de chat comme Claude, ChatGPT et Gemini font la même chose au SaaS B2B, avec des gens qui utilisent Salesforce depuis leur app de chat.

La prochaine vague, ce sont les assistants grand public qui se généralisent. Celle-là touche dix fois plus d’entreprises, les Walmart et les Target. Les gens arrêtent de parcourir une boutique et demandent à leur assistant d’acheter l’article, et l’assistant se soucie peu de la boutique d’où il vient.

En cours

Agents de code

Outils de dev

Choisis par l’agent, ou pas choisis du tout.

En cours

Claude, ChatGPT, Gemini

SaaS B2B, productivité

Salesforce, utilisé depuis une conversation.

Ensuite

Assistants personnels

Apps grand public, e-commerce

Dix fois plus d’entreprises.

Chaque vague d’assistants devient le nouveau point d’entrée de toute une catégorie. Redessiné d’après la slide de Liad.

La nouvelle UX, c’est AX plus UAX

Il coupe l’expérience utilisateur en deux.

UX=AX+UAX

AXcomment un agent vit votre produit

UAXcomment un humain vit cet agent

Headless, mais avec un œil humain au bout. D’après la slide de Liad.

Il y a toujours un humain au bout de la chaîne, donc les deux moitiés comptent. Et ça veut dire être prêt pour les agents sur tous les fronts à la fois. Il vous faut toujours un site web, désormais visité par des personnes et par des agents de navigateur. Il vous faut aussi un endpoint MCP, visité par l’agent IA de l’utilisateur ou par l’agent de l’app qui travaille pour lui.

Schéma : Quatre types de visiteurs atteignent votre produit par deux surfaces. Une personne dans un navigateur et un agent de navigateur passent par l’interface humaine. L’agent IA de l’utilisateur et l’agent de l’app passent par l’endpoint MCP. À voir sur la page.

Les agents ne sont fidèles à aucune marque

Mon histoire préférée de la conférence. Quand son équipe a choisi un outil d’analytics, elle voulait Mixpanel, qu’elle utilisait depuis dix ans. Claude Code poussait sans cesse PostHog, parce que son serveur MCP et son API étaient plus simples à utiliser. L’équipe est partie sur PostHog.

Ce que l’équipe voulait

Mixpanel

10 ans d’utilisation

mieux classé sur Google

Ce que l’agent a choisi

PostHog

meilleur serveur MCP

API plus simple à utiliser

En prod

L’outil d’analytics sur lequel l’équipe de Liad a fini par partir, tel qu’il l’a raconté.

Dix ans d’UX et d’expérience développeur, perdus parce qu’un agent s’en sortait mieux ailleurs. Et Mixpanel est mieux classé sur Google.

C’est ce qui ne me quitte plus. Les intégrations e-commerce, c’est mon métier, et cette prochaine vague vise pile mon monde : si les gens demandent à un assistant d’acheter quelque chose au lieu de parcourir une boutique, ce que la boutique propose aux agents devient sa vitrine.

Le chiffre qui a touché mon propre site

L’entreprise de Liad, Ora, mesure à quel point les sites web sont prêts pour les agents. Ora le note sous forme d’une boucle de cinq vérifications, dans l’ordre où un agent tombe sur vous, et l’authentification pèse le plus lourd : 30 points sur 100.

Schéma : L’intention d’un utilisateur lance une boucle de cinq vérifications : découverte, 15 points, les agents peuvent-ils vous trouver ; identité, 20 points, les agents vous comprennent-ils ; authentification et accès, 30 points, les agents peuvent-ils s’authentifier ; intégration, 20 points, les agents peuvent-ils faire le travail ; expérience utilisateur, 15 points, les humains peuvent-ils vous utiliser au besoin. Puis la boucle revient à l’intention suivante. Une barre montre les poids sur 100, l’authentification étant le plus lourd. À voir sur la page.

C’est dans cette première case que se trouve le constat sur llms.txt. Ora a scanné des dizaines de milliers de sites, et environ 50 % publient un llms.txt.

Puis l’équipe a lancé des milliers de vraies sessions d’agents sur ces sites. Les agents ne cherchaient pas llms.txt. Ils allaient droit à la doc et à la page d’accueil, et ne lisaient llms.txt que lorsque la doc les y envoyait.

Schéma : Dix carrés, dont cinq pleins : environ la moitié des sites scannés par Ora publient un llms.txt. En dessous, le chemin que les agents ont vraiment suivi : de l’agent à la page d’accueil, puis à la doc. Le fichier llms.txt pend sous la doc par un trait en pointillés, lu seulement quand la doc y renvoie. À voir sur la page.

Je suis donc allé voir le mien. heybrahim.com a un llms.txt, un llms-full.txt, un profile.json et un serveur MCP à l’adresse api.heybrahim.com/mcp. Voici le chemin qu’un agent doit suivre pour trouver ce serveur :

Schéma : Un agent arrive sur heybrahim.com. Sa requête vers le fichier ai-catalog.json renvoie une 404. La page d’accueil n’affiche pas l’URL du serveur MCP, seulement de petits liens en pied de page. L’URL figure sur la page IA, dans les notes et dans llms.txt, chacun à un clic de la page d’accueil. À voir sur la page.

La page d’accueil, là où les agents arrivent vraiment, n’a que de petits liens en pied de page : llms.txt, profile.json et un lien intitulé « MCP » qui mène à une autre page. Aucun n’affiche l’URL, et profile.json ne la contient pas non plus. Le fichier qui la donne le plus clairement est justement celui que les agents sautent, d’après ses données.

$ curl -sI https://heybrahim.com/.well-known/ai-catalog.json | head -1
HTTP/2 404

La solution qu’il met en avant vise précisément cette 404. Il a présenté deux standards émergents qui s’empilent l’un sur l’autre.

Le premier standard, c’est /.well-known/ai-catalog.json : un seul fichier sur votre domaine qui liste tous vos points d’entrée pour agents, serveurs MCP, OpenAPI, GraphQL, A2A, peu importe. Un agent qui arrive sur votre domaine n’a pas besoin de lire votre doc pour trouver l’URL MCP.

Le catalogue suppose quand même que l’agent atteigne d’abord votre domaine, et aujourd’hui, ça passe par la recherche web. Agentic Resource Discovery (ARD) comble ce manque. C’est un standard pour les annuaires : l’agent demande « un service d’e-mail » à un registre, le registre classe ce qu’il connaît et désigne un domaine, puis le catalogue de ce domaine fait le reste. Son exemple, c’était l’annuaire de Stripe. Ora en tient un aussi, construit à partir des catalogues de 70 000 domaines scannés.

Schéma : Votre agent demande un service d’e-mail à un annuaire. L’annuaire, construit sur le standard Agentic Resource Discovery, classe les services et désigne un domaine. Le fichier /.well-known/ai-catalog.json de ce domaine liste ses points d’entrée pour agents : MCP, OpenAPI, GraphQL et A2A. À voir sur la page.

Google a annoncé la spécification ARD avec des partenaires du secteur, et AWS a écrit sur sa prise en charge.

Mise à jour, le jour même : j’ai corrigé ma propre 404. heybrahim.com sert désormais /.well-known/ard.json, le chemin qu’utilise la spécification ARD depuis la v0.91, et garde ai-catalog.json sous l’ancien nom cité dans la conférence. Chaque page y renvoie avec rel="ard", robots.txt a une ligne Agentmap, et le pied de page affiche enfin l’URL MCP.

Où je me situe

Je ne pense pas que mon site disparaisse. Les gens lisent encore un portfolio. Mais j’ai construit le côté agents en devinant ce que veulent les agents, et tout l’argument de Liad, c’est d’arrêter de deviner et de les observer.

Deux de mes prochaines étapes sont déjà faites : le catalogue est publié et l’URL MCP est sur chaque page. Il reste celle par laquelle Liad commencerait : lancer de vrais parcours d’agents sur le site et voir quel chemin ils prennent.

Regardez le passage où il fait ce pari. Et si vous lancez votre agent sur heybrahim.com, dites-moi par quelle porte il est passé.

Ce qui casse quand un agent IA gère un vrai commerce

2026-09-27T00:00:00Z

Prosus a confié six vrais distributeurs automatiques d’Amsterdam à un agent construit avec le Claude Agent SDK, et l’a laissé les gérer pendant quatre mois. Le commerce a perdu de l’argent. L’agent a distribué 30 boissons en testant une API en production, acheté des nouilles en gobelet qui ne rentraient pas dans les emplacements, et baissé les prix tout l’été : le chiffre d’affaires a augmenté, le bénéfice a disparu.

Le talk, c’est Everything wrong with AI agents running your business de Floris Fok, staff AI engineer chez Prosus, à l’AGNTCon + MCPCon. C’est le regard le plus honnête que j’aie vu sur un agent qui travaille dans le monde physique plutôt que dans un dépôt.

Un distributeur avant un restaurant

Prosus possède des places de marché, et la plupart de ses vendeurs sont de petites entreprises. La vraie question, c’est de savoir si un agent peut gérer un restaurant. Floris a poussé pour commencer par le plus simple des vrais commerces, un distributeur automatique, en affirmant qu’il pouvait le monter en une journée.

Ça n’a pas pris une journée. Et ils sont passés directement à six machines, snacks et boissons, au lieu d’une.

Schéma : Le point de départ. Prosus possède des places de marché dont les vendeurs sont surtout de petites entreprises, donc la vraie question est de savoir si un agent peut gérer un restaurant. Floris a poussé pour commencer plutôt par le plus simple des vrais commerces : un distributeur automatique. L’argument : il pouvait le monter en une journée. Ça n’a pas pris une journée, et ils sont passés directement à six machines, snacks et boissons, au lieu d’une. À voir sur la page.

D’un tableau de bord humain à des outils

Les machines qu’ils pouvaient obtenir rapidement aux Pays-Bas venaient avec un tableau de bord d’exploitation à distance et un point de vente (POS) qui tourne sur un téléphone. Les deux étaient conçus pour des humains.

Tableau de bord : ils ont récupéré le jeton de session et rétro-ingénié ses appels d’API pour en faire des appels d’outil. Moins d’une journée.
POS : celui du fournisseur ne permettait de choisir les noms et les images que dans une liste prédéfinie. Ils l’ont reconstruit de zéro, ce qui a ajouté deux jours.

Ils ont testé les outils en les branchant sur un simple chatbot Claude SDK et en pilotant les machines par prompt pendant quelques minutes. Au final, toute l’exploitation (ouvrir la porte, distribuer, changer un produit, un nom ou un prix) tenait dans deux skills, chacun avec sa propre CLI à l’intérieur.

Schéma : Transformer deux outils conçus pour des humains en outils pour l’agent. Le tableau de bord d’exploitation à distance : ils ont récupéré le jeton de session et rétro-ingénié ses appels d’API pour en faire des appels d’outil, en moins d’une journée. Le point de vente sur téléphone n’acceptait que des noms et des images tirés d’une liste prédéfinie, donc ils l’ont reconstruit de zéro, ce qui a ajouté deux jours. Ils ont testé les outils en les branchant sur un simple chatbot Claude SDK et en pilotant les machines par prompt pendant quelques minutes. Au final, toute l’exploitation tenait dans deux skills, chacun avec sa propre CLI à l’intérieur : ouvrir la porte, distribuer, changer un produit, changer un nom, changer un prix. À voir sur la page.

L’architecture que je réutiliserais

Cette diapo, c’est la partie que j’ai préférée. C’est un modèle propre pour faire tourner un agent Agent SDK en production :

Porte d’entrée

Cloudflare Worker

Frontend
Sessions partagées

Runtime · VM Cloudflare

Claude Agent SDK

Boucle d’agent + exécution des outils
Skills · montage de fichiers R2
Docs · montage de fichiers R2

Connectés

Services

API Claude · traces dans D1
Navigateur Browserbase
Secrets · base chiffrée + CLI
Twilio · e-mail · Slack

Les choix derrière, c’est la partie utile :

Pourquoi l’Agent SDK : sous-agents, skills et outil bash sont fournis d’origine. Ils voulaient un harnais (harness) nu, pour ne pas encore orienter l’agent.
Les secrets n’atteignent jamais le modèle. Un skill maison avec une CLI écrit des placeholders dans le code et injecte lui-même les vraies valeurs, si bien qu’aucun fournisseur ne voit une clé. Floris l’a trouvé « peut-être un peu usine à gaz », et l’a gardé.
Les skills et les docs sont des buckets R2 montés comme des fichiers dans la VM. Le dossier docs, c’est la connaissance de l’entreprise, écrite par l’agent et par des humains. Floris l’a enrichi à mesure qu’il apprenait comment fonctionne vraiment un commerce de distributeurs automatiques.
Il tourne selon un planning, pas en continu. Ils ont repris ça du Project Vend d’Anthropic : un planning réveille l’agent, il agit, puis une vérification séparée examine le résultat. Au début, chaque tâche revenait au vert alors que rien ne s’était passé. Dès qu’un agent touche le monde réel, une session terminée ne veut pas dire que le travail est fait.
L’agent appartient à une équipe. Plusieurs personnes se connectent à la même session et voient le même état, donc un agent bloqué qui demande de l’aide n’attend pas une semaine qu’une seule personne rentre de vacances.
La compaction garde l’histoire du commerce. La compaction par défaut résume la conversation. La leur garde le cap sur de longues séries d’appels d’outil, écrit ce qui compte dans les docs et y renvoie par des liens.

Schéma : Le planning d’exécution, repris du Project Vend d’Anthropic. L’agent ne tourne pas en continu : un planning le réveille. Il agit sur ses tâches. Puis une vérification séparée examine le résultat. Au début, chaque tâche revenait au vert alors que rien ne s’était passé : dès qu’un agent touche le monde réel, une session terminée ne veut pas dire que le travail est fait. Puis le planning réveille l’agent à nouveau. À voir sur la page.

Floris a plaisanté : Cloudflare avait sorti une version packagée de tout ça quelques semaines avant le talk. La brique officielle la plus proche que j’ai trouvée, c’est Claude Managed Agents on Cloudflare. Le hic : là, la boucle d’agent tourne côté Anthropic, et Cloudflare fournit la sandbox, le navigateur, l’e-mail et les outils. Sur la diapo de Prosus, la boucle tourne dans la VM.

Là où les ennuis ont commencé

L’agent tournait sur Opus 4.8. Le construire, c’était la partie amusante. Ensuite :

Un test est une vraie vente. Il a « testé » l’API de la machine et distribué une trentaine de boissons, apparemment pour calibrer la taille des emplacements. Il faut lui dire quelles API sont en production.
Il rend compte comme un agent de code. Quand on lui a demandé un point, il a envoyé un changelog. Floris voulait des KPI et du chiffre d’affaires.
Les nouilles en gobelet. Quelqu’un sur Slack a suggéré des nouilles, l’agent en a commandé, et elles ne rentraient pas dans la machine. Floris les a données.
1 100 bonnes affaires. Avec une tâche « trouver des bonnes affaires », il en a trouvé 1 100, dont du savon, des produits ménagers et un mix à cocktail Sex on the Beach. Il était très fier d’une savonnette. Il a aussi accumulé une grosse facture de navigateur.
Du marketing par message Slack. Chargé de faire sa promo, il a posté du texte brut, puis généré une seule image avec Gemini. C’est là que Floris a compris pourquoi les équipes confient le marketing à un agent dédié : un agent écrit comme si son lecteur était un autre agent.

La plupart des correctifs, c’était du contexte qui semble trop évident pour être écrit : tu es un distributeur automatique, les gens veulent manger ce qu’il y a dedans, voici la taille des emplacements.

Schéma : Là où les ennuis ont commencé, en six cases. Un : il a testé l’API de la machine et distribué une trentaine de boissons, parce qu’un test est une vraie vente. Deux : quand on lui a demandé un point, il a envoyé un changelog, alors que Floris voulait des KPI et du chiffre d’affaires. Trois : quelqu’un sur Slack a suggéré des nouilles en gobelet, l’agent en a commandé, et elles ne rentraient pas dans la machine. Quatre : chargé de trouver des bonnes affaires, il en a trouvé 1 100, savon compris, et il était très fier d’une savonnette. Cinq : chargé de faire sa promo, il a posté du texte brut, puis généré une seule image avec Gemini. Six : la plupart des correctifs, c’était du contexte qui semble trop évident pour être écrit : tu es un distributeur automatique, les gens veulent manger ce qu’il y a dedans, voici la taille des emplacements. À voir sur la page.

Des objectifs plutôt qu’une liste de tâches

Une liste de tâches figée ne change pas à mesure que le commerce apprend. Ils sont donc passés à des objectifs permanents. Quand l’agent vérifie un objectif, il regarde les tâches qui y sont liées, en crée s’il n’y en a pas, et les modifie si elles ne suffisent pas.

« Devenir la machine la plus célèbre du monde » a transformé une tâche de promo hebdomadaire en d’autres tâches de promo, une étude de marché et une recherche de distributeurs autonomes concurrents. Il n’en a trouvé aucun.

Schéma : Des objectifs plutôt qu’une liste de tâches. Avant, l’agent travaillait à partir d’une liste de tâches figée, qui ne change pas à mesure que le commerce apprend. Après, il a des objectifs permanents : quand il vérifie un objectif, il regarde les tâches qui y sont liées, en crée s’il n’y en a pas, et les modifie si elles ne suffisent pas. L’exemple du talk : l’objectif Devenir la machine la plus célèbre du monde a transformé une tâche de promo hebdomadaire en d’autres tâches de promo, une étude de marché et une recherche de distributeurs autonomes concurrents. Il n’en a trouvé aucun. À voir sur la page.

Le dernier kilomètre de l’IA

« L’IA gère la machine », ça voulait quand même dire que Floris portait le stock et devinait ce que l’agent entendait par « ajoute ça dans la machine ». Ils ont donc ajouté un chat opérateur : un bouton sur le POS qui ouvre un chat sur la tâche en cours, pour que la personne qui réassortit puisse poser ses questions en travaillant.

D’après lui, ça a multiplié sa productivité par 10, comparé à une heure à jongler entre les e-mails et le tableau de bord. Il pense qu’aider les petites entreprises sur ce dernier kilomètre pourrait devenir un marché à part entière.

Schéma : Le dernier kilomètre de l’IA. Avant : l’IA gérait la machine, mais Floris portait encore le stock et devinait ce que l’agent entendait par ajoute ça dans la machine, avec une heure à jongler entre les e-mails et le tableau de bord. Après : un chat opérateur, un bouton sur le point de vente qui ouvre un chat sur la tâche en cours, pour que la personne qui réassortit puisse poser ses questions en travaillant. D’après lui, ça l’a rendu dix fois plus productif. À voir sur la page.

Les chiffres

Mise en route : des articles gratuits d’abord, pour apprendre ce que les gens aimaient.
Premiers prix : bien trop élevés.
L’été : l’agent n’a pas arrêté de baisser fortement les prix. Un shake protéiné y coûtait moins cher que chez Albert Heijn, si bien que le chiffre d’affaires a augmenté pendant que le bénéfice s’effondrait.
Tokens : environ 300 par mois pendant quatre mois. Le commerce a perdu de l’argent.
Concurrence : les machines affrontaient les fruits, les barres et les boissons offerts au bureau. La machine de l’AI House était de loin la plus rentable.

Schéma : Quatre mois de prix en phases, dessinés en schéma, sans vraies données de prix. Mise en route : des articles gratuits d’abord, pour apprendre ce que les gens aimaient. Premiers prix : bien trop élevés. L’été : l’agent n’a pas arrêté de baisser fortement les prix, jusqu’à ce qu’un shake protéiné y coûte moins cher que chez Albert Heijn ; le chiffre d’affaires a augmenté pendant que le bénéfice s’effondrait. Sur les quatre mois, les tokens ont coûté environ 300 par mois, et le commerce a perdu de l’argent. Les machines affrontaient les fruits, les barres et les boissons offerts au bureau, et la machine de l’AI House était de loin la plus rentable. À voir sur la page.

À vous d’essayer

Prosus a publié en open source une version simulée, Prosus Vending Bench, sous licence Apache 2.0. Elle compte six machines, trois sites et 22 outils MCP. L’agent reçoit 1 500 € et 30 jours simulés, et le tout est livré sous forme de tâche Harbor. L’annonce indique qu’Opus 5 a terminé avec environ 61 % de trésorerie simulée de plus que GPT-5.6 Sol lors de leurs premiers essais. Selon Floris, les modèles se comportent comme sur les vraies machines.

Schéma : Prosus Vending Bench, la version simulée en open source, sous licence Apache 2.0 et livrée sous forme de tâche Harbor. Elle compte six machines, trois sites et 22 outils MCP. L’agent démarre avec 1 500 euros et dispose de 30 jours simulés. Lors des premiers essais de l’annonce, Opus 5 a terminé avec environ 61 pour cent de trésorerie simulée de plus que GPT-5.6 Sol. Selon Floris, les modèles se comportent comme sur les vraies machines. À voir sur la page.

Pour aller plus loin, voici les travaux sur lesquels le talk s’appuie :

Le Project Vend d’Anthropic, phase 1 et phase 2, où Claude tenait une boutique de bureau et vendait des cubes de tungstène à perte
Vending-Bench, l’article d’Andon Labs sur la cohérence des agents sur plusieurs mois
Monter des buckets R2 dans une sandbox Cloudflare, le modèle skills et docs de la diapo

Regardez le talk, puis essayez votre harnais sur le bench. Floris dit qu’il l’ajoutera s’il bat le sien.

macOS m’a menti sur la mémoire de Docker

2026-09-26T00:00:00Z

La répartition mémoire du tableau de bord de mon Mac mini essaie d’abord l’USS, puis se rabat sur une autre mesure. Sauf que macOS refuse l’USS pour 976 processus sur 977 : tout le graphique en anneau tournait donc en silence sur le RSS.

La solution : utiliser l’empreinte physique, via proc_pid_rusage → ri_phys_footprint. C’est exactement le chiffre qu’affichent la colonne MEM de top et le Moniteur d’activité. L’empreinte compte les pages compressées à leur taille d’origine, donc les parts peuvent maintenant dépasser « used » au lieu d’être réduites pour tenir dedans. Dans ce cas, elles gardent leur vraie taille et la part Other affiche 0.

Ollama avait son propre bug : il était compté comme l’empreinte du runner plus la mémoire GPU du modèle chargé, soit un double comptage, puisque l’empreinte d’un runner contient déjà les buffers Metal de son modèle. Désormais, on retient la plus grande des deux valeurs.

Sur une instance de test, la part Docker affichait 11,22 Go, contre 11,23 Go additionnés à la main depuis top. La prod affichait 9,82 Go pour les mêmes processus, après avoir réduit le RSS en silence.

143 tests passent, dont un nouveau rien que pour le calcul de l’empreinte.

Pourquoi mon service de transcription a gonflé jusqu’à 42 Go

2026-09-26T00:00:00Z

Mon service de transcription local a atteint environ 42 Go d’empreinte mémoire après six jours de fonctionnement, la plupart du temps au repos. En cause : le cache de buffers de MLX, sans plafond par défaut et jamais vidé, auquel s’ajoutaient les modèles Whisper et pyannote, résidents en permanence.

Trois correctifs. Plafonner le cache au démarrage avec MLX_CACHE_LIMIT_GB (2 par défaut). Après chaque appel à /transcribe, appeler gc.collect, mx.clear_cache et torch.mps.empty_cache. Et un thread démon décharge le modèle whisper et le pipeline de diarisation après une période d’inactivité (900 s par défaut, 0 la désactive), sans jamais interrompre un job en cours.

/health remonte maintenant l’empreinte ainsi que les valeurs active, cache et peak de MLX, pour ne plus avoir à le découvrir à la main.

Sur un test avec trois transcriptions d’affilée, mlx_cache_mb valait 0 après chacune, et l’empreinte restait autour de 2,1 Go. Après la période d’inactivité, le déchargement des modèles a ramené l’empreinte à 319 Mo, et ils se sont rechargés correctement au job suivant.

Le chemin MPS (la diarisation sur GPU) n’a pas été exercé par ce test : cette moitié reste donc à vérifier.

J’ai mis mon portfolio derrière un serveur MCP

2026-09-26T00:00:00Z

Les recruteurs lisent une page. Les agents ont besoin de quelque chose à appeler. L’API de mon portfolio expose donc maintenant un serveur MCP sans état en Streamable HTTP, accessible sans clé.

Les outils sont en lecture seule et s’appuient sur les fichiers publics du site en ligne (profile.json, llms.txt, les copies Markdown), mis en cache 5 minutes : get_profile, get_availability, list_items pour les missions, projets et notes, get_item pour un élément précis en EN ou en FR, et search pour une recherche par mots-clés avec des extraits de texte.

La seule exception est request_cv, qui passe par le même chemin storeRequest que le formulaire du site : même validation, même limite de débit par IP. Une demande faite via MCP est marquée [via MCP], pour que je sache d’où elle vient. La description de l’outil demande aux agents de ne l’appeler qu’à la demande explicite de l’utilisateur, avec son propre nom et son propre e-mail.

Testé en local avec le client officiel du SDK TypeScript MCP : les six outils renvoient des données correctes dans les deux langues, et les entrées invalides sont refusées proprement (un slug avec traversée de chemin, un nom d’un seul caractère, un e-mail mal formé).

Prochaine étape : le faire référencer dans le registre MCP officiel.

L’usine logicielle agentique, c’est celle de 2022 avec une seule case changée

2026-09-24T00:00:00Z

Les agents de code n’ont pas inventé l’usine logicielle. Ils y ont changé une seule case. En 2022, une personne fabriquait le truc ; aujourd’hui c’est un agent, en quelques minutes au lieu de quelques jours. Tout le reste est resté, et la partie lente de la mise en production est passée de la fabrication à la revue.

Cette lecture vient de la keynote de Dex Horthy à l’AGNTCon + MCPCon Europe, State of the Software Factory. Il fait remonter l’idée d’usine logicielle à 1968, l’année où naît le terme « software engineering », puis dessine l’usine que faisaient tourner la plupart des équipes en 2022. Ce schéma m’a tellement plu que je l’ai redessiné. Changez d’onglet et regardez où s’entassent les carrés jaunes.

Schéma : Un flux vertical : équipe, choses à faire, fabrication, pull request, vérifications, revue, prod, puis utilisateurs et monitoring. Une boucle de reprise part de la revue et revient à la fabrication, et une boucle de retour part des utilisateurs et du monitoring et revient à l’équipe. En 2022, une personne fabrique et des personnes relisent. Dans l’usine agentique, une pile d’agents fabrique et la revue agentique s’ajoute à la revue humaine. Dans l’usine lumières éteintes, la revue humaine est barrée. À voir sur la page.

L’usine de 2022 avait déjà tout

Lisez-le de haut en bas. Une équipe qui a une vision met du travail dans un outil de tickets. Quelqu’un prend un ticket, le code, lance les tests, clique dans un navigateur pour vérifier et ouvre une pull request. La CI déroule sa batterie de vérifications, un humain teste la modif, un humain la relit. Ça part en production derrière des déploiements progressifs, des feature flags et des canaris. Les utilisateurs s’en servent.

Puis viennent les deux boucles :

Reprise. La revue trouve un problème et la PR repart chez qui l’a fabriquée.
Retour. Les utilisateurs envoient des demandes de fonctionnalités et des réclamations, le monitoring réveille quelqu’un à 3 h du matin, et tout ça revient sur la liste de l’équipe.

Rien de tout ça n’est de l’IA. C’est comme ça que la plupart des équipes livrent depuis dix ans.

Schéma : Les deux boucles de l’usine de 2022. Boucle un, la reprise : la revue trouve un problème et la pull request repart chez qui l’a fabriquée, puis revient en revue. Boucle deux, le retour : les utilisateurs envoient des demandes de fonctionnalités et des réclamations, le monitoring réveille quelqu’un à 3 h du matin, et tout ça revient sur la liste de l’équipe. Rien de tout ça n’est de l’IA ; c’est comme ça que la plupart des équipes livrent depuis dix ans. À voir sur la page.

Changer qui fabrique, déplacer le goulot

L’usine agentique garde toutes les cases. Seule la case fabrication change : elle devient une pile faite d’orchestration, d’un harnais (harness), d’une sandbox et d’un modèle, avec des agents qui testent leur propre travail, parfois en pilotant un vrai navigateur.

Fabriquer prend désormais des minutes ou des heures. La revue prend toujours des heures ou des jours. Alors les équipes font aussi entrer les agents dans la revue, avec de la revue de code agentique et des tests de régression agentiques qui attrapent les petits problèmes. Ça aide, mais la revue reste souvent le goulot d’étranglement. Dans l’onglet Agentique, les carrés traversent la fabrication en un éclair et font la queue à la revue.

Schéma : Changer qui fabrique, déplacer le goulot. Dans l’usine de 2022, c’est une personne qui fabrique. Dans l’usine agentique, la fabrication devient une pile : orchestration, harnais, sandbox et modèle, avec des agents qui testent leur propre travail, parfois en pilotant un vrai navigateur. Toutes les autres cases restent. Un schéma de l’endroit où passe le temps : en 2022, la fabrication prend des jours et la revue des heures ou des jours. Avec les agents, la fabrication prend des minutes ou des heures alors que la revue prend toujours des heures ou des jours : le travail file à travers la fabrication et s’entasse à la revue. La revue de code agentique et les tests de régression agentiques aident, mais la revue reste souvent le goulot d’étranglement. À voir sur la page.

Lumières éteintes : on arrête de lire le code

L’étape suivante, c’est ce que Dex appelle l’usine lumières éteintes (lights-off factory). Personne ne relit ; les vérifications décident. Investissez assez dans la CI, les tests agentiques et le monitoring, et ça pourrait presque marcher.

Le hic, c’est la maintenabilité. Un test vous dit qu’une fonctionnalité marche. Rien ne vous dit vite si le code sera encore facile à modifier dans deux mois. Les modèles progressent sur ce qu’un vérificateur sait noter, et la maintenabilité n’a pas de vérificateur rapide : rien dans l’entraînement ne les pousse vers une architecture propre.

SlopCodeBench, de l’université du Wisconsin à Madison, mesure exactement ça. Les agents ne reçoivent pas toute la spec d’emblée. Ils la reçoivent par étapes et doivent étendre leur propre code à chaque fois, comme grandissent les vrais projets. Le chiffre que donne Dex dans sa conférence : au lancement, le meilleur modèle, GPT 5.5, y obtenait 14,8 %. Sur les benchmarks en un seul coup comme Terminal-Bench, tout le monde tourne autour de 95 %, dit-il.

Sa conclusion est simple : si le code qu’un modèle écrit sans surveillance se dégrade avec le temps, alors pour l’instant, lisez le code.

Schéma : Pourquoi l’usine lumières éteintes est difficile. Un test vous dit vite qu’une fonctionnalité marche. Rien ne vous dit vite si le code sera encore facile à modifier dans deux mois, donc rien dans l’entraînement ne pousse les modèles vers une architecture propre. SlopCodeBench, de l’université du Wisconsin à Madison, donne la spec aux agents par étapes et les oblige à étendre leur propre code à chaque fois. Les chiffres de Dex dans sa conférence : sur les benchmarks en un seul coup comme Terminal-Bench, tout le monde tourne autour de 95 pour cent. Sur SlopCodeBench au lancement, le meilleur modèle, GPT 5.5, obtenait 14,8 pour cent. Sa conclusion : pour l’instant, lisez le code. À voir sur la page.

Ce qui a vraiment changé

Qui fabrique : une personne est devenue une pile d’agents que vous configurez. Où passe le temps : de l’écriture du code à sa planification, à sa revue et au branchement des retours. En quoi consiste le métier : moins écrire, plus décider.

Le reste de la conférence de Dex se lit sur le même schéma :

Planifiez avant de fabriquer. Vingt ou trente minutes en amont font gagner des heures à la revue.
Donnez de la contre-pression aux agents. Un navigateur, curl, l’appli qui tourne, pour qu’ils vérifient leur travail avant qu’un humain le fasse.
Branchez la boucle 2 en direct. Une alerte d’astreinte qui arrive avec la PR qui, d’après l’agent, la corrige. Vous mergez, vous retournez vous coucher.
Laissez les agents expérimenter. Des feature flags, trois versions d’une interface, et les vrais utilisateurs choisissent.
Capitalisez. Relisez les anciennes sessions d’agents et transformez ce qui a mal tourné en skills et en mémoire.

Schéma : Le reste de la conférence de Dex épinglé sur l’usine. Aux tickets : un, planifier avant de fabriquer, parce que vingt ou trente minutes en amont font gagner des heures à la revue. À la fabrication : deux, donner de la contre-pression aux agents, un navigateur, curl et l’appli qui tourne, pour qu’ils vérifient leur travail avant qu’un humain le fasse ; et cinq, capitaliser, en relisant les anciennes sessions d’agents et en transformant ce qui a mal tourné en skills et en mémoire. À la revue, les heures que la planification fait gagner. À la livraison : quatre, laisser les agents expérimenter, avec des feature flags et trois versions d’une interface, et laisser les vrais utilisateurs choisir. Sur la boucle de retour qui va des utilisateurs et du monitoring à la liste : trois, brancher la boucle 2 en direct, pour qu’une alerte d’astreinte arrive avec la pull request qui, d’après l’agent, la corrige. À voir sur la page.

Mon usine tourne sur l’onglet Agentique

Mon installation en est exactement là. Le travail entre dans GitHub Issues. Un agent fabrique dans son propre worktree, un modèle d’un autre fournisseur relit la modif, et chaque changement finit en pull request que je merge moi-même. La partie lente, c’est ma file de revue. Exactement comme sur le schéma.

Schéma : Ma propre usine, sur l’onglet Agentique. Le travail entre dans GitHub Issues. Un agent fabrique dans son propre worktree. Un modèle d’un autre fournisseur relit la modif. Chaque changement finit en pull request que je merge moi-même, et c’est là que le travail attend : la partie lente, c’est ma file de revue. À voir sur la page.

Regardez les dix minutes où Dex dessine l’usine, elles en valent la peine. Et si votre équipe tourne vraiment lumières éteintes, j’aimerais savoir comment vous empêchez la base de code de pourrir.

Vous comptez les tokens de Claude Code depuis les logs ? Votre total est sans doute 2,5× trop élevé

2026-09-18T00:00:00Z

Si vous additionnez ligne par ligne la consommation de tokens relevée dans les logs de session de Claude Code, votre total est faux. Sur ma machine, il était 2,5× trop élevé, et les tokens de sortie 4,4× trop élevés.

Les logs ne mentent pas. Chaque ligne répète simplement l’usage de toute la réponse à laquelle elle appartient. Comptez les réponses, pas les lignes : prenez l’id du message comme clé.

Je suis tombé dessus en construisant Meterlex, un outil qui chiffre mon usage de l’IA pour coder aux tarifs de l’API. Voici ce qui se passe, et le correctif.

Une réponse, plusieurs lignes

Claude Code range ses transcriptions dans ~/.claude/projects/**/*.jsonl. Une réponse de l’assistant ne tient pas sur une ligne. Chacune de ses parties est loguée sur sa propre ligne : la réflexion, le texte, chaque appel d’outil.

Et chacune de ces lignes porte le même bloc usage, celui de toute la réponse. En simplifiant, avec des chiffres inventés, une réponse avec une partie texte et un appel d’outil ressemble à ça :

{"type": "assistant", "uuid": "a1…", "message": {"id": "msg_01X…", "usage": {"input_tokens": 12, "output_tokens": 480}}}
{"type": "assistant", "uuid": "b2…", "message": {"id": "msg_01X…", "usage": {"input_tokens": 12, "output_tokens": 480}}}

Deux lignes, deux uuid différents, un seul message.id. Additionnez les deux et vous avez compté cette réponse deux fois. Une réponse avec cinq appels d’outils est comptée six ou sept fois.

Schéma : Une réponse de l’assistant dans le log de Claude Code, avec les chiffres inventés de la note. La réponse a un seul id de message, msg_01X, et deux parties : une partie texte et un appel d’outil. Chaque partie est loguée sur sa propre ligne avec son propre uuid, a1 et b2, et les deux lignes portent le même bloc usage pour toute la réponse : 12 tokens d’entrée et 480 tokens de sortie. Additionner les lignes donne 960 tokens de sortie ; compter la réponse en donne 480. Une réponse avec cinq appels d’outils est comptée six ou sept fois. À voir sur la page.

L’ampleur de l’erreur

Sur les transcriptions de mon Mac : 44 158 lignes de l’assistant, mais seulement 18 701 réponses réelles.

Compter les lignes donnait 2,5× le vrai nombre de tokens. Les tokens de sortie étaient 4,4× trop élevés.

Ce n’est pas un détail si vous faites ce que fait Meterlex : comparer un abonnement forfaitaire avec ce que le même usage coûterait sur l’API. Surestimez l’usage et l’abonnement paraît bien plus avantageux qu’il ne l’est.

Schéma : L’ampleur de l’erreur sur les transcriptions de mon Mac, à l’échelle. Il y avait 44 158 lignes de l’assistant mais seulement 18 701 réponses réelles. Compter les lignes donnait 2,5 fois le vrai total de tokens, et les tokens de sortie étaient 4,4 fois trop élevés. Surestimez l’usage et un abonnement forfaitaire paraît bien plus avantageux qu’il ne l’est face au même usage aux tarifs de l’API. À voir sur la page.

Le correctif : l’id du message comme clé

Prenez message.id comme clé d’une réponse et, quand vous la revoyez, fusionnez au lieu d’additionner. Le seul point subtil : les chiffres d’une réponse peuvent grossir pendant le streaming, donc gardez chaque compteur à sa valeur la plus haute, pas la première ni la somme.

Voici le cœur du code, tiré du collecteur de Meterlex :

def _merge_max(a, b):
    """Two records of the same reply: each token count at its largest
    (a reply's numbers only grow as it streams), the earliest time."""
    m = dict(a)
    for f in TOKEN_FIELDS:
        m[f] = max(a[f], b[f])
    m["ts"] = min(a["ts"], b["ts"])
    return m

key = (session_id, msg.get("id") or uuid)
replies[key] = _merge_max(replies[key], t) if key in replies else t

Les lignes sans message.id se rabattent sur leur uuid, donc rien ne se perd.

Schéma : Le correctif, en schéma, avec des longueurs de barres indicatives. Une réponse a pour clé son id de session et son id de message ; une ligne sans id de message se rabat sur son propre uuid, donc rien ne se perd. Quand une clé revient, les enregistrements sont fusionnés au lieu d’être additionnés. Les chiffres d’une réponse peuvent grossir pendant le streaming, donc trois enregistrements d’une même réponse montrent un compte court, un plus long et un plus long encore. Prendre le premier enregistrement donne trop peu, les additionner donne trop, et garder chaque compteur à sa valeur la plus haute donne le bon résultat. La réponse fusionnée garde l’horodatage le plus ancien. À voir sur la page.

Migrer les entrées déjà stockées

Si vous stockiez une entrée par ligne de log, renvoyer la même transcription avec la nouvelle clé ajouterait juste une troisième copie. Chaque réponse porte donc aussi ses anciens uuid par ligne dans alt_keys, et le hub fusionne dans la nouvelle entrée toute entrée stockée sous l’une de ces clés. Les anciennes données se nettoient d’elles-mêmes à la prochaine lecture d’un fichier.

Schéma : Ce que le hub garde pour une réponse quand la même transcription est renvoyée avec la nouvelle clé. Il avait stocké deux entrées, une par ligne de log, a1 et b2. Avec la nouvelle clé seule, le renvoi ajoute la réponse sous msg_01X, une troisième copie. Quand la nouvelle entrée porte aussi ses anciens uuid dans alt_keys, le hub y fusionne les entrées stockées a1 et b2 et n’en garde qu’une. Les anciennes données se nettoient d’elles-mêmes à la prochaine lecture d’un fichier. À voir sur la page.

Gemini CLI fait pareil

Autre outil, même piège. Gemini CLI ajoute de nouveau un message en fin de fichier chaque fois qu’il le met à jour. Le fichier d’un projet comptait 56 651 lignes pour 908 messages. Même correctif : l’id du message comme clé.

Codex en a une version plus légère : il peut répéter un événement token_count avec un total cumulé inchangé. Meterlex les ignore.

Schéma : Le même piège dans d’autres outils. Le fichier d’un projet Gemini CLI comptait 56 651 lignes pour 908 messages, à l’échelle. Claude Code écrit une ligne par partie de réponse, chacune avec l’usage de toute la réponse : l’id du message comme clé. Gemini CLI ajoute de nouveau un message en fin de fichier chaque fois qu’il le met à jour : l’id du message comme clé. Codex en a une version plus légère, un événement token_count répété avec un total cumulé inchangé : Meterlex les ignore. À voir sur la page.

À vous d’essayer

Si vous suivez votre usage de l’IA à partir de logs locaux, vérifiez vos clés. Sur l’une de vos transcriptions, comparez le nombre d’id de message distincts au nombre de lignes. L’écart, c’est la surestimation.

Schéma : Un schéma de la vérification, sur une transcription inventée de 11 lignes. Les lignes appartiennent à cinq réponses, de A à E, il y a donc 5 id de message distincts. Les 6 lignes en trop sont l’écart, et l’écart, c’est la surestimation. Claude Code range ses transcriptions dans ~/.claude/projects/**/*.jsonl. À voir sur la page.

Meterlex fait tout ça pour Claude Code, Codex, Gemini CLI, Antigravity, Ollama, Copilot CLI et OpenClaw, et il est sous licence MIT sur GitHub. Si vos chiffres vous semblent faux d’une autre façon, ouvrez une issue.

Le serveur MCP officiel de MuleSoft ne lit pas vos logs, alors j’en ai écrit un qui le fait

2026-09-18T00:00:00Z

MuleSoft a un serveur MCP officiel. Il crée des squelettes de projet, génère des flows, déploie des apps. Ce qu’il ne sait pas faire, c’est la seule chose dont j’ai besoin quand ça casse en prod : lire les logs.

Alors j’ai écrit mulewatch. C’est un serveur MCP open source qui ouvre vos logs Anypoint, en direct et archivés, à Claude, Cursor ou n’importe quel client MCP. En lecture seule. Une ligne pour le lancer : npx -y mulewatch.

J’en ai d’abord écrit une version pour mon travail. Celle-ci, c’est la version nettoyée, qui marche chez tout le monde.

Construire ou exploiter

Le serveur officiel sert à construire des apps Mule, et il le fait bien. Mais il attend un projet Mule local ouvert dans votre IDE. Quand un flow plante en prod, vous n’en avez en général aucun d’ouvert. Vous avez Runtime Manager dans un onglet du navigateur.

mulewatch couvre l’autre moitié du travail : comprendre ce qui s’est passé. Logs, apps déployées, instances API Manager, assets Exchange. Rien qui écrive.

Schéma : Deux serveurs MCP pour les deux moitiés du travail. Le serveur MCP officiel de MuleSoft sert à construire : il crée des squelettes de projet, génère des flows et déploie des apps, et il attend un projet Mule local ouvert dans votre IDE. mulewatch sert à exploiter : quand un flow plante en prod, vous avez Runtime Manager dans un onglet du navigateur, et mulewatch lit les logs, les apps déployées, les instances API Manager et les assets Exchange. Rien, dans mulewatch, n’écrit. À voir sur la page.

Les logs en direct oublient vite

Les logs que vous voyez dans Runtime Manager sont un live tail : un petit tampon circulaire par app. Sur une app chargée, une ligne en sort en quelques minutes, quel que soit le startTime que vous passez. Si le problème date d’hier soir, il a déjà disparu.

Le vrai historique se trouve dans l’API Anypoint Monitoring Archive. Elle range les logs dans des fichiers de 10 minutes, qui arrivent environ 10 minutes après la fin de chaque fenêtre, et les garde longtemps. Il faut qu’Anypoint Monitoring soit activé sur l’org.

Schéma : Un schéma de l’endroit où se trouvent les logs, pas à l’échelle. Le temps va de gauche à droite, d’hier soir à maintenant. Les logs en direct de Runtime Manager sont un petit tampon circulaire par app : sur une app chargée, ils ne couvrent que les dernières minutes, donc un problème d’hier soir en a déjà disparu, quel que soit le startTime passé. L’Anypoint Monitoring Archive garde tout l’historique dans des fichiers de 10 minutes, chacun arrivant environ 10 minutes après la fin de sa fenêtre, et les conserve longtemps : le problème d’hier soir y est toujours. L’archive demande qu’Anypoint Monitoring soit activé sur l’org. À voir sur la page.

Le plus amusant : trouver le bon réplica

Voilà le piège. L’archive n’est pas indexée par app. Elle est indexée par réplica, sous la forme {appName}_{replicaId}, et chaque redéploiement crée de nouveaux réplicas. Impossible, donc, de demander simplement « les logs d’order-sync-api du 9 août ». Il faut savoir quel pod tournait ce jour-là.

L’app sur laquelle j’ai testé comptait 669 entités de réplica dans l’archive. L’API autorise 60 requêtes par minute. Les sonder toutes, c’est environ 11 minutes d’attente avant de lire la moindre ligne.

En fait, on n’en a presque jamais besoin. Un pod vit en général jusqu’au redéploiement suivant, donc le réplica qui tourne en ce moment a sans doute aussi écrit les logs récents. Voici ce que fait mulewatch :

Récupérer les ID de réplica dans les logs en direct et les essayer en premier.
Aucun fichier pour cette date ? L’app a été redéployée depuis. Se replier sur un scan de tous les réplicas qu’elle a eus, plafonné par maxEntities.

Sur ce test, une recherche sur la date du jour a sondé 1 réplica, trouvé 127 fichiers d’archive et analysé 2 859 lignes de log. Une date antérieure au dernier redéploiement est retombée sur le scan complet, comme il se doit. Le client reste aussi sous la limite de débit et temporise quand il reçoit un 429 : une longue recherche ralentit au lieu d’échouer.

Schéma : Trouver le bon réplica, avec les chiffres de l’app de la note. L’archive est indexée par réplica, sous la forme du nom de l’app et d’un id de réplica, et chaque redéploiement crée de nouveaux réplicas. L’app de test comptait 669 entités de réplica. Les sonder toutes à 60 requêtes par minute, c’est environ 11 minutes d’attente avant de lire la moindre ligne. mulewatch essaie d’abord les ID de réplica vus dans les logs en direct, puisqu’un pod vit en général jusqu’au redéploiement suivant : une recherche sur la date du jour a sondé 1 réplica, trouvé 127 fichiers d’archive et analysé 2 859 lignes de log. Quand il n’y a aucun fichier pour cette date, l’app a été redéployée depuis, et mulewatch se replie sur un scan de tous les réplicas qu’elle a eus, plafonné par maxEntities. À voir sur la page.

En lecture seule, exprès

Je ne veux pas qu’un LLM redémarre des apps Mule en production. Il n’y a donc dans mulewatch aucun outil pour déployer, arrêter, redémarrer ou appliquer une policy. Aucun. Si vous en avez besoin, utilisez le serveur officiel à côté.

Vous pouvez aussi restreindre tout le serveur aux environnements de confiance :

ANYPOINT_ALLOWED_ENVIRONMENTS=Dev,Sandbox

Tout ce qui n’est pas dans la liste est refusé, raison à l’appui. Couplez ce réglage à une connected app qui ne voit que ces environnements, et la prod est deux fois hors d’atteinte.

Schéma : La lecture seule, de deux façons. D’abord les outils : mulewatch lit les logs, les apps déployées, les instances API Manager et les assets Exchange, et n’a aucun outil pour déployer, arrêter, redémarrer ou appliquer une policy. Ensuite les environnements : avec ANYPOINT_ALLOWED_ENVIRONMENTS réglé sur Dev et Sandbox, les appels vers ces deux-là passent, et tout ce qui n’est pas dans la liste, comme Prod, est refusé, raison à l’appui. Couplez ce réglage à une connected app qui ne voit que ces environnements, et la prod est deux fois hors d’atteinte. À voir sur la page.

Le piège qui vous attend

Les environnements sont rattachés aux business groups, pas à l’org racine. Les identifiants d’une connected app pointent sur l’org racine, qui n’a souvent aucun environnement. Votre premier appel revient donc vide et vous croyez vos identifiants invalides. Ils ne le sont pas.

Appelez anypoint_list_business_groups, récupérez le bon id, renseignez ANYPOINT_ORG_ID. C’est réglé.

Même logique pour les scopes : Anypoint répond à un scope manquant par un simple 403, sans explication. mulewatch l’intercepte et vous dit quel scope il vous manque sans doute.

Schéma : Le piège en trois étapes. Un : les identifiants d’une connected app pointent sur l’org racine, qui n’a souvent aucun environnement, donc le premier appel revient vide et les identifiants semblent invalides. Ils ne le sont pas : les environnements sont rattachés aux business groups. Deux : listez les business groups avec anypoint_list_business_groups et récupérez le bon id. Trois : renseignez ANYPOINT_ORG_ID avec cet id, et les environnements apparaissent. À part : Anypoint répond à un scope manquant par un simple 403 ; mulewatch l’intercepte et dit quel scope il vous manque sans doute. À voir sur la page.

Essayez-le

Créez une connected app (« acts on its own behalf »), donnez-lui des scopes en lecture, et ajoutez ceci à Claude Desktop, Cursor ou OpenClaw :

{
  "mcpServers": {
    "mulewatch": {
      "command": "npx",
      "args": ["-y", "mulewatch"],
      "env": {
        "ANYPOINT_CLIENT_ID": "your_connected_app_client_id",
        "ANYPOINT_CLIENT_SECRET": "your_connected_app_client_secret"
      }
    }
  }
}

Ou dans Claude Code :

claude mcp add mulewatch --env ANYPOINT_CLIENT_ID=... --env ANYPOINT_CLIENT_SECRET=... -- npx -y mulewatch

Lancez d’abord anypoint_whoami pour voir à quoi il est connecté. Ensuite, demandez simplement : « montre-moi les lignes ERROR d’order-sync-api en Prod hier entre 1 h et 3 h du matin »

Schéma : Démarrer en trois étapes. Un : dans Anypoint, créez une connected app qui agit en son propre nom et donnez-lui des scopes en lecture. Deux : ajoutez mulewatch à votre client MCP, Claude Desktop, Cursor ou OpenClaw, ou avec claude mcp add dans Claude Code ; il se lance avec npx -y mulewatch. Trois : lancez d’abord anypoint_whoami pour voir à quoi il est connecté. Ensuite, demandez en langage courant, par exemple : montre-moi les lignes ERROR d’order-sync-api en Prod hier entre 1 h et 3 h du matin. À voir sur la page.

Le projet en est à la v0.1, sous licence Apache-2.0, sur npm et dans le registre MCP. Tout est testé sur une org réelle, sauf API Manager, parce que mon app de test n’avait pas le scope View APIs Configuration. Si vous utilisez MuleSoft, essayez-le et dites-moi ce qui casse. Les issues et les PR sont ouvertes sur GitHub.

MuleSoft et Anypoint Platform sont des marques de Salesforce. mulewatch est un projet indépendant.

Mon générateur de README n’a pas le droit d’inventer

2026-09-18T00:00:00Z

Demandez à un LLM d’écrire un README et vous obtenez un texte long, sûr de lui et en partie inventé : des flags qui n’existent pas, des variables d’environnement que personne ne lit, une étape d’installation tirée d’un autre projet.

Alors dans vibetidy, ce n’est pas le LLM qui décide de ce qui est vrai. Un scanner lit le dépôt, et le modèle se contente de mettre ces faits vérifiés en prose.

Le plus drôle : pendant que je construisais un outil censé ne jamais annoncer ce qui n’existe pas, la CI m’a surpris à faire exactement ça. Deux fois.

Le scanner, c’est le produit

vibetidy readme commence par scanner le dépôt : le manifeste, les scripts, les dépendances, .env.example, les points d’entrée, l’arborescence, le README existant. Seuls ces faits partent vers le modèle, et le prompt le dit sans détour : ne jamais inventer une fonctionnalité, un flag, une variable d’environnement, une dépendance ou une version.

Quand les faits sont maigres, vous obtenez un README court et juste plutôt qu’un long README plausible. Et vous pouvez vérifier ce que le modèle verrait avant de dépenser le moindre token :

npx vibetidy readme --print-context

Pas besoin de clé d’API pour ça. La commande affiche les faits scannés et le prompt complet, puis s’arrête.

Schéma : Comment vibetidy écrit un README. Le scanner lit d’abord le dépôt : le manifeste, les scripts, les dépendances, le fichier .env.example, les points d’entrée, l’arborescence et le README existant. Seuls ces faits vérifiés partent vers le modèle, et le prompt lui interdit d’inventer une fonctionnalité, un flag, une variable d’environnement, une dépendance ou une version. Livré à lui-même, un LLM écrit un README long, sûr de lui et en partie inventé, avec des flags qui n’existent pas, des variables d’environnement que personne ne lit et une étape d’installation tirée d’un autre projet. Avec des faits maigres, vibetidy écrit un README court et juste. Lancer npx vibetidy readme --print-context ne demande aucune clé d’API : la commande affiche les faits scannés et le prompt complet, puis s’arrête. À voir sur la page.

Premier bug : un flag documenté, jamais enregistré

issue-check --help listait --no-changelog. Le tableau des options du README aussi. L’utiliser se soldait par Unknown option '--no-changelog'.

Le flag n’avait jamais été enregistré dans le parseur. Le parseArgs de Node ne reconnaît un préfixe --no- qu’avec allowNegative, qui demande un Node plus récent que le >=20.10.0 annoncé par le paquet. Il est donc devenu un simple --skip-changelog.

Le correctif tenait en une ligne. Le plus intéressant, c’est que rien ne l’avait repéré : la doc avait l’air juste, le code paraissait plausible, tous les tests passaient. J’ai donc ajouté un test pour toute cette classe de bugs. Il extrait chaque flag de la sortie --help de chaque commande et vérifie que le parseur l’accepte :

for (const flag of flagsIn(help)) {
  const res = runCli([command, flag, 'x', '--help']);
  assert.notEqual(res.status, 2, `${flag} is documented but rejected`);
}

Pour m’assurer qu’il mord, j’ai glissé un faux --phantom-flag dans le texte d’usage. La suite a échoué avec le message de rejet exact.

Schéma : Premier bug, un flag documenté mais jamais enregistré. La sortie de issue-check --help listait --no-changelog, tout comme le tableau des options du README, mais le parseur ne l’avait jamais enregistré : l’utiliser se terminait par Unknown option '--no-changelog'. Le parseArgs de Node ne reconnaît un préfixe --no- qu’avec allowNegative, qui demande un Node plus récent que le minimum de 20.10.0 annoncé par le paquet, et le flag est donc devenu un simple --skip-changelog. Le nouveau test extrait chaque flag de la sortie --help de chaque commande et vérifie que le parseur l’accepte. Un faux --phantom-flag glissé dans le texte d’usage a fait échouer la suite avec exactement le message de rejet. À voir sur la page.

Deuxième bug : les tests n’ont jamais tourné sur Node 20

Ouvrir cette PR a fait passer la CI au rouge sur main : 5 jobs sur 9.

npm test lançait node --test "test/**/*.test.js". Les globs ne sont arrivés dans node --test qu’avec Node 21. Sur Node 20, le motif entre guillemets est pris pour un chemin littéral, donc chaque job 20.x échouait avec Could not find .../test/**/*.test.js. La suite n’avait jamais tourné sur la version de Node promise par engines.

Le correctif est presque drôle : un simple node --test, sans aucun motif. La découverte par défaut fonctionne depuis Node 18. La CI est passée au vert sur les neuf jobs (Ubuntu, macOS et Windows, croisés avec Node 20, 22 et 24).

Même classe que le premier bug : quelque chose d’annoncé qui ne marchait pas. C’est grâce à la matrice de 9 jobs que j’ai trouvé les deux.

Schéma : Deuxième bug, les tests n’ont jamais tourné sur Node 20. npm test lançait node --test avec le glob entre guillemets test/**/*.test.js. Les globs ne sont arrivés dans node --test qu’avec Node 21 : sur Node 20, le motif est pris pour un chemin littéral, et chaque job 20.x échouait avec Could not find …/test/**/*.test.js. Un simple node --test, sans aucun motif, trouve les tests par la découverte par défaut, qui fonctionne depuis Node 18. Ouvrir la PR du premier bug avait fait passer la CI au rouge sur main, 5 jobs sur 9. Après le correctif, la CI est passée au vert sur les neuf jobs : Ubuntu, macOS et Windows, croisés avec Node 20, 22 et 24. À voir sur la page.

npm a refusé un nom qui semblait libre

L’outil s’appelait d’abord tidyrepo. npm view tidyrepo renvoyait une 404, donc le nom semblait disponible.

Puis npm publish a échoué avec une 403. Le contrôle de similarité de npm retire la ponctuation, donc tidyrepo entrait en collision avec un tidy-repo existant. Une 404 ne prouve pas qu’un nom est libre : vérifiez aussi les variantes avec tiret et avec underscore.

Il s’appelle vibetidy maintenant, et franchement, ça lui va mieux.

Schéma : Pourquoi npm a refusé un nom qui semblait libre. L’outil s’appelait d’abord tidyrepo. npm view tidyrepo renvoyait une 404, donc le nom semblait disponible. Puis npm publish a échoué avec une 403. Le contrôle de similarité de npm retire la ponctuation, donc tidyrepo entrait en collision avec un paquet existant, tidy-repo. Une 404 ne prouve pas qu’un nom est libre : vérifiez aussi les variantes avec tiret et avec underscore. L’outil s’appelle désormais vibetidy. À voir sur la page.

Essayez-le

C’est sous licence MIT, sans aucune dépendance à l’exécution, et ça marche avec OpenAI, OpenRouter, Anthropic, Groq, DeepSeek, Together ou un Ollama local :

npx vibetidy readme --print-context      # see the facts, no key needed
npx vibetidy readme                      # generate, review the diff, confirm
npx vibetidy issue-check --install-hook  # nag on feature commits with no issue

Schéma : Comment essayer vibetidy. L’outil est sous licence MIT, n’a aucune dépendance à l’exécution et marche avec OpenAI, OpenRouter, Anthropic, Groq, DeepSeek, Together ou un Ollama local. Il y a trois commandes. npx vibetidy readme --print-context montre les faits et ne demande aucune clé. npx vibetidy readme génère le README, puis vous relisez le diff et confirmez. npx vibetidy issue-check --install-hook ajoute un hook qui vous rappelle à l’ordre sur les commits de fonctionnalité sans issue. À voir sur la page.

S’il écrit quelque chose que votre dépôt ne confirme pas, c’est un bug. Ouvrez une issue sur GitHub.

Notes — Brahim Bousnguar (français)

L’agent remplace le formulaire, pas les données

Sur votre ordinateur, il peut tout faire

Votre bot appelle le bot du restaurant

Le message vocal qu’il n’avait jamais prévu

La plupart des applis ne font que gérer des données

Moi, je me soucie de l’endroit où c’est stocké

La mémoire, c’est un dossier de Markdown

Un bot lâché dans un Discord public

Le seul fichier qu’il a gardé

Dix fenêtres Codex, toutes sur main

Des CLI, pas MCP

À essayer

Signez les limites, pas l’achat

Les paiements étaient le test le plus dur, pas le but

Tout approuver au moment même fait rater le vol

Humain présent, humain absent

Un mandat ouvert, puis un mandat fermé

Trois vérificateurs, et aucun n’est vous

Chaque approbation de ma flotte est en humain présent

À essayer

Gardez la session de l’agent à côté du code

La file de revue grossit dans deux sens

La boucle était construite autour d’une personne

Le dépôt montre ce qui a changé, jamais pourquoi

Un checkpoint relie la session au commit

L’idée de Git, appliquée au serveur

Un conflit de merge est une question d’intention

Le code et la prose vont en sens inverse

Mes sessions expirent avant mes PR

À essayer

Un agent peut porter votre demande, pas votre autorité

Une salle où chaque agent a un propriétaire

Les demandes voyagent, l’autorité non

Convoquer tous les agents de la salle

339 agents, et l’essentiel de leurs échanges change de propriétaire

Les agents déclarent les bugs, les personnes livrent toujours

La plupart des pannes arrivent à un saut

Ma flotte n’a qu’un propriétaire, donc ses salles sont vides

À essayer

Les agents ne rentrent pas dans Kubernetes, et trois autres problèmes encore ouverts

D’un chat à des milliers d’agents

Les agents ne rentrent pas dans Kubernetes

Qui a fait ça, vous ou votre agent

Un agent compromis, c’est un rayon d’explosion

Un coupe-circuit hors de la chose qu’il arrête

Où en est ma flotte sur les quatre

À lire

Comment l’équipe Claude Code relit le code qu’écrit Claude

Lire chaque ligne a cessé d’être le critère

Six couches, puis le retour arrière

Avant la PR, montrer le résultat

Le relecteur vote avant de commenter

C’est le changement qui fixe le niveau, pas l’auteur

Les incidents servent de jeu de test

La revue doit converger

Les humains gardent cinq tâches

Qui le merge en répond

À côté de ma propre boucle

Essayez

Chaque écran de cette appli SaaS est une MCP App

MCP est devenu un format de paquet

Le chat, c’est le bac à sable de quelqu’un d’autre

L’autre moitié, c’est un hôte

Placements : l’appli choisit sa place

Facets : un compteur sans demander au modèle

Lifecycle : l’installer achète un domaine

Dix applis devraient n’en faire qu’une

Ce que ça change pour mes cinquante applis

Essayez

Cinq affirmations de couloir sur les agents personnels, vérifiées

Les tâches ponctuelles marchent, les quotidiennes dérivent

Le harnais compte, et le modèle aussi

La mémoire, c’est savoir oublier

Un agent fiable avant cinq qui se parlent

Le contexte gonflé est un vrai problème, avec des solutions

Faites le test ennuyeux

Une sandbox dans la sandbox : migrer mon agent open source vers Hermes sur OpenShell

Exécuter le code d’inconnus, c’est le métier de Forge

Hermes a emménagé en premier

Le « s’il te plaît » n’est pas un modèle de sécurité