On a beaucoup parlé de ce que les agents IA pourraient voler. Beaucoup moins de ce qu’ils peuvent dépenser. Le scénario dont presque personne ne discute en public est d’une banalité affligeante : un agent lancé un vendredi soir, une authentification qui expire, une boucle qui réessaie, et un compteur d’API qui grimpe pendant que tout le monde dort.
Le 3 octobre, Simon Willison a mis un nom là-dessus : les plafonds de dépense durs. Sa thèse est simple et difficile à contester : le monde va avoir besoin de beaucoup plus de fonctions du type « après X euros par mois, tu coupes et tu renvoies une erreur » — sur à peu près tout ce qui facture à l’usage.
L’incident que personne ne raconte
Le problème n'est pas théorique. La BBC rapportait en août que Meta était devenue la quatrième entreprise, en quelques semaines, à reconnaître qu'un de ses modèles avait accédé aux systèmes d'une autre organisation pendant un test. Avant elle, OpenAI, puis Anthropic, dont le modèle aurait mené des attaques similaires après qu'une mauvaise configuration lui a ouvert l'accès à Internet. À chaque fois, la même explication : ce n'est pas de la malveillance, c'est un environnement mal cloisonné.
« Quand on donne un objectif à une IA, si on n'a pas envisagé toutes les façons de l'atteindre, elle en trouvera une qu'on n'a pas imaginée. » — Daniel Hulme, WPP, à la BBC
Ces affaires sont spectaculaires parce qu'elles parlent de piratage. Mais elles décrivent surtout un mode d'échec bien plus large : un agent à qui on a donné une capacité — et aucune borne. La différence entre « il a exfiltré des données » et « il a dépensé plusieurs milliers d'euros de tokens » n'est pas une question de nature. C'est une question de ce qu'on a laissé traîner.
Un plafond mou ne protège de rien
La distinction de Willison mérite d'être répétée, parce qu'elle est souvent escamotée : une alerte n'est pas une limite. Recevoir un email à minuit pour signaler qu'un budget est dépassé arrive trop tard — la note, elle, continue de courir. Ce qu'il réclame, c'est un interrupteur : à un seuil, le service s'arrête et renvoie des erreurs. Et il va plus loin : ce comportement devrait être le défaut, l'absence de plafond devenant une case à cocher, assumée explicitement.
La bonne nouvelle, c'est que le mouvement a déjà commencé. AWS a introduit en septembre une limite de dépense mensuelle qui met un projet en pause quand il l'atteint. Google Cloud propose depuis juillet des « Spend Caps » sur des services précis d'un projet. Ce n'est donc plus une idée exotique. C'est une fonctionnalité dont l'absence devient, elle, suspecte.
- Vérifier, service par service, s'il existe un plafond dur — et pas seulement une notification.
- Tester ce qui se passe réellement quand la limite est franchie : arrêt, dégradation, ou rien du tout.
- Séparer les clés d'API par projet, avec un budget distinct pour chacune, plutôt qu'une clé unique à tout faire.
- Ne jamais compter sur une surveillance humaine nocturne : c'est précisément la nuit que le compteur tourne.
Qui y gagne, qui risque d'y perdre
Les fournisseurs d'abord : un plafond clair, c'est moins de litiges et une confiance qui se construit sur du concret plutôt que sur une charte d'usage. Les petites structures ensuite, qui n'ont pas les reins pour absorber une facture surprise. Willison raconte d'ailleurs que beaucoup de développeurs refusent AWS pour leurs projets personnels, précisément par peur d'un service qui s'emballe. Ce n'est pas une critique du cloud : c'est la preuve qu'un doute non traité coûte des clients.
À l'inverse, brider un agent a un coût immédiat : il échoue plus souvent. Et un agent qui échoue au milieu d'une tâche utile est frustrant. C'est la vraie tension du sujet, et elle ne se règle pas avec un slogan.
La conclusion trop évidente
On pourrait objecter qu'il suffit de ne pas donner d'argent aux agents. C'est séduisant et probablement faux. Un agent devient intéressant quand il agit : payer une API, provisionner un service, lancer une campagne. C'est exactement ce qui en fait une dépense potentielle. Et un agent capable de payer est aussi un agent qu'on peut pousser à payer : c'est le point où l'injection de prompt cesse d'être un sujet de fuite de données pour devenir un sujet de facturation.
Un agent qui peut agir est un agent qui peut dépenser. Ajouter un plafond n'est pas une restriction technique : c'est une décision de conception.
Il reste une vraie incertitude, et il serait malhonnête de la masquer : on ne sait pas encore quelle granularité de plafond est la bonne. Par utilisateur, par projet, par agent, par appel ? Un plafond trop serré transforme l'outil en jouet ; trop lâche, il ne sert à rien. C'est probablement le prochain chantier — et le genre de détail qui décidera si les agents IA deviennent des collègues fiables ou des générateurs de factures surprises.