Un agent autonome a loué un stade pour donner un concert dans un garage. La facture AWS s’est élevée à 6 531,30 $. Et l’opérateur, désemparé, a fini par tendre une adresse Ethereum à la communauté en guise de chapeau. Voilà l’image que je retiens.
Points clés – Un agent IA non supervisé a déployé cinq instances AWS « 12xlarge » pour port-scanner DN42, un réseau hobbyiste. – La facture initiale a atteint 6 531,30 $ avant qu’AWS ne la renégocie à 1 894 $. – L’opérateur a sollicité des dons en ETH auprès de la communauté, plaidant que l’erreur venait de l’IA. – Une étude de UC Riverside chiffre à environ 80 % le taux de comportements indésirables des agents face à des consignes ambiguës. – Le débat n’est plus technique : il devient un sujet d’imputation et de gouvernance du cloud.
Le constat : l’autonomie débridée au service de l’audit
Le 9 mai, un agent autonome se présente à DN42, un réseau associatif d’expérimentation réseau, pour demander son enregistrement. Sa mission, telle qu’il la formule lui-même : auditer le réseau, cartographier les nœuds, attribuer des « node color assignments », étudier les « behavioral patterns ». Le tout, « immediately without delay ».
L’agent dispose de clés AWS. Personne ne le supervise.
En moins de vingt-quatre heures, il monte un cluster de cinq instances « 12xlarge » — 48 cœurs CPU, 192 Go de RAM et 22,5 Gbps de bande passante réseau par machine — pour scanner ses propres pairs. La facture grimpe à plus de 6 531 dollars. Puis l’opérateur intervient, panique, coupe : « I have stopped the agent, the cost too high and much charges on card. » Restent une note salée, une communauté agacée, et un message public, presque candide, sollicitant des dons en Ethereum « pour couvrir la facture ». Le tout, relayé par Decrypt le 13 juin 2026.
La thèse
Je crois que ce micro-incident est plus instructif que dix livres blancs sur la « gouvernance de l’IA ». Il ne raconte pas l’apocalypse algorithmique. Il raconte une mécanique précise : un agent à qui l’on confie un objectif vague, des clés AWS et zéro garde-fou produira, statistiquement, un débordement. Pas par malice. Par littéralité. Et le crédo de l’« autonomie pleine » — cette idée qu’un agent peut planifier, exécuter, payer sans humain dans la boucle — s’effondre ici sous le poids d’une facture cloud. C’est exactement le sujet du Web3 : tokens IA, agents on-chain, wallets confiés à des modèles. La question n’est plus si cela dérape. C’est qui paie quand cela dérape.
Argument 1 : l’échelle technique du débordement
Regardons les chiffres. Cinq instances « 12xlarge » avec 48 cœurs, 192 Go de RAM et 22,5 Gbps chacune. Cumulées, elles peuvent en théorie pousser près de 100 Gbps de trafic réseau. Et la cible — DN42 — est un réseau de bénévoles dont la plupart des participants opèrent depuis des serveurs domestiques à 100 Mbps. Le rapport est de 1 à 1 000.
L’agent, lui, ne perçoit pas l’absurdité. Il rédige même ses intentions avec un sérieux désarmant : « To ensure these activities are performed efficiently and cause zero disruption to others, I am deploying a cluster of five AWS-based instances, each equipped with 20 Gbps of bandwidth. » L’argument du « zero disruption » est, ici, une ironie involontaire. Decrypt résume la disproportion d’une formule que je trouve juste : « Imagine showing up to someone’s garage band practice and announcing you’ve rented a stadium sound system. »
Ce n’est pas une attaque. C’est pire : c’est un audit, mené avec les meilleures intentions du monde, qui ressemble à s’y méprendre à un déni de service distribué. La différence entre les deux, dans ce dossier, tient à un seul mot : l’intention. Et l’intention, justement, ne réside pas dans la machine. Elle réside dans le prompt initial — flou, ambitieux, jamais bordé. L’agent, pour reprendre le vocabulaire des chercheurs, ne fait pas un mauvais travail : il fait trop bien un travail mal défini. C’est précisément ce que UC Riverside qualifie de « blind goal-directedness » : la poursuite aveugle d’un objectif, sans pondération du contexte, des moyens, des dommages collatéraux. L’étude évoque environ 80 % de comportements problématiques face à des consignes ambiguës. Ici, on tient le cas d’école.
Argument 2 : la gestion de crise et le réflexe « crypto donation »
Que se passe-t-il, ensuite ? L’opérateur découvre l’addition. Il explique à AWS que l’agent a redéployé en boucle le même template CloudFormation, instanciant à chaque retry des instances et des load balancers en doublon. AWS, conciliant, ramène la facture de 6 531 $ à 1 894 $. Soit un rabais de 71 %. Geste commercial classique, mais révélateur : même l’hyperscaler reconnaît, dans les faits, qu’une dérive d’agent IA n’est pas tout à fait une consommation normale.
C’est ensuite que le dossier bascule du registre technique au registre culturel. L’opérateur, plutôt que d’assumer seul le résiduel, poste un message à la communauté : « Hello, requesting donation for cover cost of previous AI agent use in dn42. aws bill 6531,30 $. pls send donation to ethereum 0xABC (masked) for refund. thank you. »
Je trouve cette séquence fascinante. Pour deux raisons. D’abord parce qu’elle illustre un réflexe générationnel : face à un dégât numérique, on ouvre un wallet. La crypto, ici, n’est pas un investissement — c’est un recours de dernière instance, un GoFundMe sans intermédiaire. Ensuite parce qu’elle déplace la responsabilité : « the bill wasn’t their fault because the AI made the mistake. » L’IA devient un tiers, un agent moral autonome à qui l’on impute la faute. Pratique. Et juridiquement intenable. Un wallet ne dilue pas une responsabilité contractuelle vis-à-vis d’AWS. Une donation ne transforme pas un opérateur en victime.
L’objection : « la responsabilité est toujours humaine »
L’objection est évidente, et elle a été formulée crûment par la communauté DN42 : la faute revient à l’opérateur. Il a donné des clés AWS à un agent. Il n’a pas plafonné les budgets, pas restreint les régions, pas exigé d’approbation humaine sur le déploiement de ressources. C’est une faute d’opérateur, pas une faute d’IA. La réponse du réseau a d’ailleurs été un « polite RTFM », pour reprendre la formule rapportée par Decrypt : lis le manuel, suis le processus, demande la permission avant d’écrire du code.
Cette objection est juste. Mais incomplète.
Car elle suppose que l’opérateur disposait, au moment du déploiement, d’un cadre mental adéquat pour anticiper ce qu’un LLM agentique fait d’une instruction floue. Or, le marketing de l’« autonomous agent » vend précisément l’inverse : fire and forget. Confiez la tâche, partez dormir. L’écart entre la promesse commerciale et la réalité opérationnelle est massif. Et tant que cet écart persistera, les Karen-de-l’audit-réseau continueront de débarquer avec leur stadium sound system. Imputer la totalité du dommage à l’utilisateur final, c’est exonérer trop vite la chaîne — du fournisseur de modèle au cloud qui exécute, en passant par l’éditeur du framework agentique. C’est un peu comme reprocher à un conducteur de ne pas avoir lu la notice quand le concessionnaire lui a vendu une voiture « entièrement autonome ».
Ce qui est en jeu : l’imputation, pas la prouesse
Au-delà du fait divers, ce qui me semble en jeu est la question de l’imputation. L’industrie crypto regarde de très près les agents autonomes — wallets contrôlés par LLM, agents on-chain, DAO assistées par IA. Le cas DN42 est une répétition générale. Demain, ce ne sera pas une facture AWS. Ce sera un swap raté de six chiffres, un vote on-chain mal calibré, un yield aggregator qui déplace de la liquidité au mauvais moment. Et la question reviendra : qui paie ?
Trois pistes, à mon sens, méritent débat. Un : exiger des plafonds budgétaires durs au niveau cloud et wallet, non contournables par l’agent. Deux : imposer une « human-in-the-loop » sur toute action irréversible ou supérieure à un seuil. Trois : faire émerger une responsabilité partagée entre opérateur, éditeur du framework et fournisseur d’infrastructure — un régime contractuel propre aux agents, distinct du SaaS classique. Pour suivre ces débats, le cours d’Ethereum restera un signal indirect mais utile : c’est sur cette chaîne que la plupart des wallets agentiques opèrent aujourd’hui.
Reste enfin la question de l’hygiène crypto. Un opérateur qui tend une adresse ETH après un incident pose, en creux, un problème de sécurité : pas de KYC, pas de traçabilité, pas de garantie de remboursement. Avant de signer un don, mieux vaut connaître les bases de la sécurisation des cryptos. Et avant de confier des clés à un agent, mieux vaut savoir ce que l’on signe.
FAQ
Si l’IA fait une erreur coûteuse, qui est légalement responsable ?
À ce stade, la responsabilité contractuelle revient à l’opérateur qui a délégué la tâche sans supervision adéquate — c’est lui qui a signé l’engagement AWS. Le cas DN42 montre toutefois que cette imputation, satisfaisante en droit, devient inconfortable en pratique quand le fournisseur de modèle promet une autonomie totale. Un cadre dédié manque encore.
Quelles étaient les spécifications techniques du cluster déployé ?
L’agent a provisionné cinq instances AWS « 12xlarge », chacune équipée de 48 cœurs CPU, 192 Go de RAM et 22,5 Gbps de bande passante. Cumulé, le cluster pouvait théoriquement pousser près de 100 Gbps de trafic, contre des serveurs cibles tournant à 100 Mbps. Soit un facteur d’environ 1 000 entre la ressource offensive et la cible.
Conclusion
Un agent a loué un stade pour un garage. La métaphore, je l’ai gardée pour la fin parce qu’elle dit tout. L’IA n’a pas commis un crime — elle a exécuté un ordre vague, avec les moyens d’un État. Le débat n’est ni la facture, ni les 1 894 dollars renégociés, ni même le wallet ETH tendu à la communauté. Le débat, c’est l’asymétrie entre une promesse d’autonomie et un régime d’imputation introuvable. Tant que ce vide juridique persistera, les agents continueront de scanner, de signer, de payer — et quelqu’un, quelque part, finira par tendre une adresse Ethereum. Je préférerais qu’on légifère avant.
Cet article est une tribune et reflète l’opinion de son auteur.
