Plafonner le coût d’un agent IA dans n8n : circuit breaker et garde-fous budgétaires

Un agent IA qui appelle un modèle de langage n’a pas de compteur de coût intégré : il exécute ce qu’on lui demande, autant de fois qu’il le faut, jusqu’à ce que la tâche soit terminée ou qu’une erreur l’arrête. Tant que le volume reste faible, cette absence de plafond ne se voit pas. Le jour où un pic de trafic, un outil qui boucle ou simplement un mois plus chargé fait dérailler la facture, il est déjà trop tard : l’argent est dépensé. Notre guide sur le suivi du coût des appels IA dans n8n explique comment journaliser cette dépense après coup. Celui-ci va plus loin : comment empêcher activement le dérapage, avec un vrai circuit breaker budgétaire qui coupe l’agent avant que la facture ne s’envole.

Un coût qui ne se prédit pas à l’avance

L’intuition la plus répandue — « on connaît le prix du modèle, donc on peut estimer le coût » — ne tient pas pour un agent qui enchaîne raisonnement et appels d’outils. Une étude du Stanford Digital Economy Lab menée avec Microsoft Research, publiée en 2026 (arXiv 2604.22750, voir sur Google Scholar), a mesuré la consommation de tokens de huit modèles frontières sur des tâches agentiques identiques. Résultat : sur une même tâche, deux exécutions peuvent afficher un écart allant jusqu’à 30 fois le nombre de tokens consommés — et les modèles eux-mêmes, interrogés pour estimer par avance leur propre coût, se trompent systématiquement, avec une corrélation faible entre l’estimation et la réalité. Un agent qui interroge un outil de recherche RAG, relance une requête mal formée ou tombe sur un document plus long que prévu peut coûter dix fois plus cher que l’exécution voisine, sans qu’aucun signal ne le prévienne en amont.

Cette imprévisibilité est le cœur du problème : on ne peut pas se contenter de calculer un budget mensuel moyen et espérer que la réalité s’y conforme. Il faut un mécanisme qui réagit à la dépense réelle, en direct, pas un budget qu’on découvre dépassé le mois suivant.

Pourquoi le suivi seul ne protège de rien

Journaliser chaque appel — tokens d’entrée, tokens de sortie, coût estimé — dans une table Supabase, comme décrit dans notre guide sur le suivi des coûts IA, est une base indispensable. Mais un journal est passif : il répond à « qu’a-t-on dépensé ? », jamais à « peut-on encore dépenser ? ». Un dashboard qui affiche une courbe qui grimpe ne stoppe rien tout seul ; quelqu’un doit le regarder, comprendre, et couper le workflow manuellement — souvent après la fin du mois, quand la facture est déjà là.

Le circuit breaker inverse cette logique : c’est un garde-fou actif, consulté avant chaque appel coûteux, qui peut interrompre l’exécution de lui-même.

Le pattern circuit breaker, appliqué au budget

Le circuit breaker est un pattern classique de fiabilité logicielle, popularisé pour protéger un système d’appels réseau défaillants en coupant l’accès à un service qui échoue trop souvent plutôt que de continuer à le solliciter en pure perte. Une revue de littérature de Falahah, Surendro et Sunindyo (« Circuit Breaker in Microservices: State of the Art and Future Prospects », IOP Conference Series: Materials Science and Engineering, 2021, voir sur Google Scholar) formalise ses trois états : fermé (le trafic passe normalement), ouvert (le trafic est coupé net, sans même tenter l’appel), et semi-ouvert (un appel test est autorisé pour vérifier si la reprise est possible). Le même raisonnement s’applique presque tel quel à un budget IA : au lieu de couper un service qui échoue, on coupe un agent qui a atteint son plafond de dépense — le principe de protection active est identique.

Trois niveaux de garde-fou, pas un seul

Il faut distinguer trois échelles de protection, qui se complètent :

• Par exécution : le paramètre Max Iterations du node AI Agent, détaillé dans notre guide des erreurs courantes de l’AI Agent, borne le nombre d’allers-retours outils à l’intérieur d’une seule exécution. Il empêche une boucle infinie locale, mais ne voit rien de ce qui se passe dans les autres exécutions du jour.
• Par période (jour ou mois) : le circuit breaker budgétaire décrit ici, qui raisonne sur la dépense cumulée toutes exécutions confondues et coupe l’accès au modèle une fois le plafond atteint.
• Manuel : un interrupteur qu’un humain peut actionner en urgence — un incident détecté (dérive de prompt, attaque par saturation) n’attend pas que le compteur budgétaire rattrape son retard.

Construire le circuit breaker dans n8n

La brique centrale est une table Supabase qui porte à la fois le compteur et l’état, mise à jour par une fonction Postgres atomique — c’est le point technique qui distingue un vrai circuit breaker d’un simple compteur approximatif :

create table budget_tracker (
  id text primary key,
  period_start date not null default current_date,
  spent_usd numeric(10,4) not null default 0,
  cap_usd numeric(10,4) not null,
  state text not null default 'closed'
);

create or replace function increment_budget(p_id text, p_amount numeric)
returns table(spent_usd numeric, cap_usd numeric, state text) as $$
  update budget_tracker
  set spent_usd = spent_usd + p_amount,
      state = case
        when spent_usd + p_amount >= cap_usd then 'open'
        else state
      end
  where id = p_id
  returning budget_tracker.spent_usd, budget_tracker.cap_usd, budget_tracker.state;
$$ language sql;

Le point important : cet incrément et cette vérification se font en une seule requête SQL, exécutée côté Postgres. Si le compteur était lu puis réécrit depuis deux nœuds n8n via un cycle SELECT/UPDATE séparé, deux exécutions concurrentes pourraient toutes les deux lire un solde encore sous le plafond avant que l’une des deux n’ait eu le temps d’écrire sa mise à jour — et passer toutes les deux, alors qu’une seule aurait dû être bloquée. C’est une variante du même problème d’état partagé que décrit notre guide sur l’idempotence des webhooks n8n : dès que plusieurs exécutions touchent la même ressource, seule une opération atomique côté base de données évite les doublons.

Dans le workflow, la séquence devient :

1. Juste avant l’appel au node AI Agent, un node Supabase (ou HTTP Request) appelle increment_budget avec le coût estimé de l’appel à venir.
2. Un node IF teste l’état renvoyé : state = 'open' route vers la branche d’arrêt, state = 'closed' laisse passer vers l’agent.
3. Sur la branche d’arrêt, deux options selon le contexte : un node Stop and Error (voir notre guide dédié) pour un traitement interne par lot, où un échec net et journalisé est acceptable ; ou une réponse de repli sans appel modèle pour un chatbot public, où mieux vaut dégrader que rompre la conversation.
4. À 80 % du plafond, une branche parallèle envoie une alerte préventive — par exemple dans Slack, avec notre guide du bot Slack IA — pour agir avant la coupure plutôt que la découvrir a posteriori.

La reprise automatique : l’état semi-ouvert

Un circuit resté ouvert indéfiniment n’est plus un garde-fou, c’est juste un service cassé. La reprise doit être automatique et prévisible : un Schedule Trigger déclenché à minuit (ou en début de mois, selon la granularité du plafond) réinitialise spent_usd à zéro et repasse state à 'closed' pour la nouvelle période. C’est l’équivalent du test de reprise du circuit breaker classique, simplifié : plutôt qu’un appel test ponctuel, la fenêtre temporelle elle-même sert de minuteur de réinitialisation.

Où l’appliquer en priorité

Ce garde-fou a le plus de valeur sur les workflows exposés à un trafic qu’on ne contrôle pas entièrement soi-même : un chatbot RAG public comme celui du Pack Assistant RAG (119 €), qui peut recevoir un pic de questions un jour donné, ou une boîte de tri automatique comme dans le Pack Inbox IA (79 €), exposée à un afflux inhabituel d’emails (spam, campagne virale). Dans les deux cas, le circuit breaker ne remplace pas le suivi des coûts — il s’appuie dessus — mais il transforme un budget mensuel en promesse tenue plutôt qu’en espoir.

En résumé

Le coût d’un agent IA n’est pas prévisible à l’avance : la recherche récente montre des écarts de consommation de tokens allant jusqu’à 30x sur une tâche identique, et les modèles eux-mêmes ne savent pas estimer leur propre coût. Journaliser la dépense (voir notre guide de suivi des coûts) reste indispensable mais reste passif. Un circuit breaker budgétaire — compteur atomique côté Postgres, vérification avant chaque appel, arrêt ou dégradation gracieuse une fois le plafond atteint, réinitialisation automatique à la période suivante — transforme ce suivi en protection active, en complément du Max Iterations qui protège chaque exécution individuellement. Trois lignes de défense, trois échelles différentes, et un budget qui ne dérape plus en silence.