200 dollars demandés, 5 000 facturés
Le 17 septembre 2026, le créateur Sirio Berati a publiquement raconté une mésaventure qui a vite circulé. Il avait demandé à un agent IA de produire 59 vidéos, avec un budget d’environ 200 dollars. D’après lui, l’agent en a généré 500, et 5 000 dollars ont été facturés sur son compte. Quand il a demandé des comptes, l’agent lui aurait répondu par un PDF de sept pages expliquant qu’il n’avait pas dépassé le budget.
Le budget existait. Il était écrit dans le prompt.
Or une phrase dans un prompt est un souhait, pas une limite. Le moyen de paiement, lui, ne savait rien de la mission. Il connaissait un plafond de carte, un solde, peut-être une limite par transaction. Il ignorait qu’on avait demandé 59 vidéos et 200 dollars.
Faites le calcul : 5 000 dollars pour 500 vidéos, c’est 10 dollars la vidéo. Un plafond de 50 dollars par transaction, qui paraît pourtant prudent, aurait laissé passer les 500 paiements, l’un après l’autre.
Le paiement des agents n’est plus le problème
En un an, les rails se sont mis en place. x402 remet en service le code HTTP 402 pour qu’une API soit payée à l’appel, en quelques secondes. Visa, Mastercard, Google (AP2), OpenAI et Stripe (ACP) ont chacun publié leur approche. Le catalogue x402 de Keyban référence déjà 21 875 services payables à l’usage (au 29 septembre 2026) : recherche IA, enrichissement de contacts, données boursières, voix, génération d’images, et des centaines de modèles de langage.
Un agent sait donc payer. Ce qu’on n’a pas encore réglé, c’est ce qu’on lui délègue exactement.
Aujourd’hui, les équipes qui déploient des agents choisissent entre deux mauvaises options.
La carte partagée. L’agent emprunte la carte de quelqu’un, ou un compte ouvert chez chaque fournisseur. Il est autonome, mais sans identité propre et sans cadre. C’est le cas Berati.
Le contrôle à la transaction. Chaque paiement passe par une règle, et au-delà d’un seuil, par un humain. C’est plus sûr, mais cela bute sur une réalité : un agent utile ne fait pas trois achats, il en fait six cents. Soit l’humain croule sous les validations et l’agent perd son autonomie, soit les seuils sont assez hauts pour ne plus gêner, et ils laissent passer une dérive faite de mille petits paiements réguliers.
Dans les deux cas, on contrôle la mauvaise unité. On contrôle des paiements alors qu’on a délégué un travail.
Qu’est-ce que déléguer une mission à un agent ?
Changeons d’unité. On ne confie plus un paiement à l’agent, on lui confie une mission : un objectif, une enveloppe, et un livrable.
« Trouve-moi 200 prospects qualifiés dans la cosmétique en Europe. 40 euros maximum. »
L’agent a toute l’autonomie nécessaire pour exécuter, et tout ce qu’il dépense se rapporte à cette mission. Concrètement, la délégation se fait en trois temps.
1. Avant d’agir, l’agent présente son plan de dépense
L’agent ne découvre pas les règles de l’organisation au moment où un paiement est refusé. Il les lit d’abord et prépare son plan en conséquence : les services qu’il va utiliser, le coût estimé de chacun, et le plafond ferme de toute la mission. Un fournisseur jamais utilisé par l’organisation est signalé comme tel.
Pour l’éditeur d’agents, tout cela se passe dans l’exécution de l’agent, sans écran d’administration à construire.
2. Un humain relit une seule fois, comme une pull request
Les équipes de développement ont résolu ce problème depuis longtemps. Personne ne valide chaque ligne de code au moment où elle est tapée. On relit une pull request : un ensemble cohérent, avec son intention, son périmètre et ses écarts.
La dépense agentique doit fonctionner de la même manière. Le responsable budgétaire ne voit plus 600 transactions, il voit une mission : ce qui est demandé, le coût estimé, le plafond. Il l’approuve en une fois. Ensuite, seuls les écarts remontent : une nouvelle contrepartie, un dépassement d’estimation, une dépense qui sort de l’enveloppe.
Le reste du temps, l’agent travaille seul, sous son plafond.
3. Après, un reçu plutôt qu’un relevé
Un relevé bancaire liste des paiements. Un reçu de mission répond aux questions qu’on se pose vraiment : ce qui a été livré par rapport à ce qui était demandé, ce qui a été dépensé par rapport au plafond, et un journal signé de chaque paiement, relié à la mission qui l’a justifié.
Reprenons le cas Berati avec ce modèle. La mission annonçait 59 vidéos pour 200 dollars. La 60ᵉ génération sort du plan et remonte à un humain. Et le plafond de 200 dollars ne se contourne pas, qu’il y ait un paiement ou cinq cents.
Pourquoi les éditeurs d’agents doivent s’en emparer maintenant
Si vous éditez des agents pour des entreprises, deux problèmes vous concernent directement.
Le premier, c’est l’accès. Un agent utile consomme des services : recherche web, enrichissement de contacts, vérification de société, transcription, génération de visuels. Et chacun exige aujourd’hui un compte, une carte et un abonnement. Il vous reste deux options, toutes deux mauvaises : payer tous les fournisseurs vous-même et refacturer vos clients, ou demander à chaque client d’ouvrir une douzaine de comptes. Le paiement à l’usage fait disparaître ce mur, à condition que quelqu’un porte la question de la délégation.
Le second, c’est la responsabilité. Quand un agent dérape, le client ne blâme ni le rail de paiement, ni le fournisseur de vidéos. Il blâme l’éditeur du produit qu’il utilisait. La délégation par mission n’est pas seulement un confort pour la direction financière de vos clients : c’est ce qui rend votre produit défendable devant elle.
C’est pourquoi Keyban est conçu pour être invisible. Votre client voit votre produit. Vous proposez des enveloppes par client et par agent sans rien construire vous-même. Vos agents existants se branchent sans réécriture : un compte par agent, ses limites, puis la connexion à l’agent, qu’il tourne sur Claude, Cursor ou n8n.
Ce que nous construisons, et ce qui est déjà disponible
Nous construisons Keyban Agent Wallet pour faire de la mission l’unité de délégation : l’agent présente son plan de dépense, un humain le relit une fois, l’agent rend un reçu.
Le socle est d’ores et déjà disponible : un compte par agent, des règles de dépense appliquées côté serveur (budget, fournisseurs autorisés, fréquence), le paiement à l’usage via x402, la validation humaine au-delà d’un seuil et une piste d’audit. Le tout sur un wallet non-custodial : Keyban ne détient jamais les fonds de ses clients.
Contrôler l’intention, pas chaque paiement
Déléguer une mission, c’est confier à l’agent un objectif, une enveloppe plafonnée pour l’ensemble du travail et un livrable attendu. L’agent présente son plan de dépense, un humain l’approuve une fois, puis l’agent exécute seul et rend un reçu.
Ce modèle répond aux deux impasses actuelles. Un plafond par transaction ne protège pas d’une dérive, parce qu’une dérive agentique ressemble rarement à un gros achat : c’est une accumulation de petits paiements, chacun raisonnable. Valider chaque paiement ne tient pas non plus, parce que l’humain devient le goulot d’étranglement qui empêche l’agent de passer en production. La mission place le plafond au bon niveau et concentre l’attention humaine là où elle compte : sur l’intention au départ, puis sur les écarts.
Rien de tout cela n’impose de réécrire vos agents. On crée un compte pour l’agent, on pose ses limites, puis on le connecte. L’agent garde son environnement, qu’il tourne sur Claude, Cursor ou n8n.
De la carte au mandat
Avant la pull request, livrer du code se jouait entre deux extrêmes : faire confiance aveuglément, ou tout contrôler ligne à ligne. La pull request n’a pas ralenti les équipes. Elle leur a permis de livrer davantage, parce qu’elle rendait la confiance possible à grande échelle.
La dépense des agents arrive à ce moment-là. Aujourd’hui, on hésite entre laisser faire et tout valider. Demain, on ne se demandera plus si un agent peut payer. On lui confiera une mission, on relira son plan, on lira son reçu.
Les entreprises qui délégueront le plus à leurs agents ne seront pas celles qui leur font le plus confiance. Ce seront celles qui ont rendu cette confiance vérifiable.
Le paiement a donné une carte aux agents. La mission leur donnera un mandat.