Comment empêcher un agent IA de trop dépenser

La plupart des mauvaises surprises de facture IA ont la même cause : un agent sans plafond. Il a bouclé, il a réessayé, il a traîné une conversation qui grossissait, et personne ne l'a su avant la facture.

Le remède n'est ni un meilleur modèle ni un meilleur prompt. C'est une limite qui refuse l'appel suivant, et la plupart des choses qu'on appelle un budget ne font pas cela.

L'essentiel en bref

• Une alerte vous dit ce que vous avez déjà dépensé. Ce n'est pas une limite.
• Le plafond de dépense de votre fournisseur est en général une notification, pas un arrêt net.
• Aucun budget ne peut arrêter l'appel qu'il est en train de faire. Le vrai pire cas, c'est votre budget plus un appel.
• La plupart des frameworks d'agents ne livrent aucune limite de coût, ou une limite qui compte des appels plutôt que de l'argent.
• Le test qui compte : votre plafond a-t-il déjà refusé quoi que ce soit ?

Une alerte n'est pas une limite

Un moniteur tourne une fois l'argent parti. Une limite tourne avant l'appel suivant et dit non. Les deux sont utiles, mais un seul est un contrôle.

Voici un test réalisable aujourd'hui, et il ne demande aucun seuil : sortez les refus enregistrés par votre plafond actuel. A-t-il déjà refusé quelque chose ? Un chiffre qui n'a jamais refusé un seul appel n'est pas un contrôle, c'est un commentaire.

La dépense par agent, après coup. Exactement la bonne vue pour décider d'un plafond, et exactement la mauvaise chose sur laquelle compter pour arrêter une exécution.

Ce que fait vraiment le plafond de votre fournisseur

On suppose que le chiffre saisi dans le tableau de bord du fournisseur est un mur. C'est le plus souvent une sonnette.

Sources : le guide des spend limits d'OpenAI, l'API Spend Limits et les limites de débit d'Anthropic. La documentation d'Anthropic va plus loin et déconseille de s'appuyer sur son chiffre de dépense : il peut afficher zéro quand la lecture est indisponible, et doit être traité comme informatif.

Deux conclusions. Les plafonds fournisseur sont un filet de sécurité, pas votre première ligne de défense. Et un plafond mensuel à l'échelle de l'organisation a la mauvaise forme pour arrêter une seule exécution défaillante : quand il se déclenche, il emporte tout le reste avec lui.

Vous ne pouvez pas arrêter l'appel en cours

C'est la partie que tout article honnête sur les budgets doit dire.

On ne connaît le coût d'un appel qu'une fois terminé. Aucun budget en cours d'exécution ne peut donc empêcher un appel coûteux de faire sauter le plafond. Il ne peut empêcher que le suivant. Votre vrai pire cas est le budget plus un appel.

Cela a une conséquence pratique. Si un seul appel peut plausiblement coûter la moitié de votre budget, votre budget ne peut pas fonctionner. Un plafond ne se comporte comme un plafond que s'il est confortablement plus grand que le plus gros appel possible de l'agent, et une règle empirique de trois fois est un plancher raisonnable. Dimensionner cela correctement est un sujet en soi : quel budget accorder à un agent fait le calcul.

Cela veut dire aussi qu'une bonne implémentation prédit avant de dépenser. Elle regarde le coût des dernières étapes, leur vitesse de croissance, et le plus gros appel que ce modèle pourrait physiquement faire, puis refuse quand la projection casserait le plafond. Prédire est toute l'astuce, parce que mesurer arrive toujours trop tard.

Ce que plafonnent réellement les outils courants

Si vous supposez que votre framework vous couvre, vérifiez. La plupart plafonnent autre chose que de l'argent, et la plupart n'ont aucune limite par défaut.

Trois choses à retenir de ce tableau.

Presque tout est illimité par défaut. L'hypothèse sûre est que vous n'avez aucun plafond tant que vous n'en avez pas posé un.

Compter des appels n'est pas un budget. Dix appels peuvent coûter un centime ou dix euros selon la quantité de texte transportée. Le middleware de LangChain plafonne des nombres d'appels et n'a aucun budget en tokens ou en coût.

Un plafond qui n'atteint pas les sous-agents est décoratif. C'est la façon la plus courante dont un plafond se révèle factice : un parent est configuré avec une limite, il lance des enfants, et les enfants tournent avec les valeurs par défaut. Des cas documentés existent dans des frameworks très utilisés. Si vous ne retenez qu'une action de cet article, prenez celle-ci : posez une limite sur un parent, lancez un enfant, et prouvez que l'enfant en hérite.

Quatre règles pour un budget qui fonctionne

1. Plafonnez de l'argent ou des tokens, pas des étapes. Le prix d'une étape flotte. Celui d'un euro non.
2. Donnez un plafond à chaque étape, et un à l'exécution entière. Une exécution qui se déploie en cinquante branches parallèles peut rester dans chaque budget d'étape et coûter quand même cinquante fois ce que vous attendiez.
3. Réservez avant de lancer, n'interrompez pas en vol. Couper des branches à mi-parcours laisse un demi-résultat arbitraire. Refuser de démarrer est explicite et se réessaie.
4. Quand le plafond se déclenche, gardez le travail fait. Un arrêt qui jette tout ce qui a été produit transforme un problème de coût en perte totale, et c'est exactement pour cela que les équipes désactivent les plafonds.

Ce dernier point mérite une ligne à lui. Un arrêt budgétaire doit rendre ce que l'agent a produit, plus le détail de ce qu'il a dépensé et de la raison de l'arrêt, et il doit nommer le plafond qui s'est déclenché. Un arrêt qui dit seulement « budget dépassé » ne vous donne rien à faire.

À quel point cela dérape-t-il vraiment ?

Il n'existe aucun taux publié de fréquence des emballements en production : méfiez-vous de toute fréquence annoncée avec assurance. Ce qui est documenté, c'est l'ordre de grandeur, et il est plus modeste que la légende.

Les incidents recensés se situent entre quelques centaines et quelques milliers de dollars : environ 2 150 dollars de dépense non voulue dans un cas, 235 dollars en quatre jours pour un seul utilisateur, un dépassement de 70 % au-delà d'un budget fixé. Pendant ce temps, l'histoire la plus republiée du domaine, un anonyme « nous avons dépensé 47 000 dollars en agents IA », ne nomme aucune entreprise, ne montre aucune facture, et ses propres chiffres hebdomadaires totalisent 25 658 dollars, pas 47 000.

Le vrai risque n'est pas une facture spectaculaire. C'est une fuite discrète, récurrente, de quelques milliers d'euros, que personne n'attribue à rien, mois après mois.

Les questions qu'on nous pose

Définir un maximum de tokens plafonne-t-il mes coûts ?

Seulement la taille de chaque réponse. Cela ne fait rien contre le nombre de boucles de l'agent, qui est justement d'où vient l'emballement.

Faut-il utiliser le plafond de dépense de mon fournisseur ?

Oui, comme filet de sécurité, et activez la version stricte si votre fournisseur la propose. Ne le prenez simplement pas pour votre contrôle : il est en général mensuel, à l'échelle de l'organisation, et souple par défaut.

Quel budget de départ est raisonnable ?

Au moins trois fois le plus gros appel possible de l'agent, sinon il peut sauter avant même d'avoir eu l'occasion de refuser. Partez de là, puis ajustez avec de vraies exécutions.

Mon plafond ne s'est jamais déclenché. Bon signe ?

Cela veut dire qu'il n'a jamais été testé, pas qu'il fonctionne. Mettez un budget volontairement minuscule sur un agent de test et vérifiez que vous obtenez un refus propre et typé qui nomme la limite déclenchée.

Les détecteurs de boucle remplacent-ils les budgets ?

Non, ils répondent à une autre question. Un détecteur de boucle borne le nombre de répétitions. Un budget borne ce que ces répétitions peuvent coûter. Il vous faut les deux.

La prochaine étape

Vérifiez trois choses cette semaine : votre plafond porte-t-il sur de l'argent plutôt que sur un nombre d'appels, atteint-il les sous-agents, et a-t-il déjà refusé quelque chose. Choisissez ensuite le chiffre lui-même avec quel budget accorder à un agent IA.