---
title: Plafonner le coût d'un agent IA : de 200 000 tokens par jour à un budget mensuel
description: Mon agent IA s'arrêtait à 200 000 tokens par jour : la limite, le compteur qui ratait des appels facturés, puis le budget mensuel qui l'a remplacé.
category: SaaS & Product
format: article
pillar: ia-et-agents
tags: ia, agent, tokens, budget, anthropic, coûts
author: Charlie Dallier-Wood
publishedAt: 2026-10-29
updatedAt: 2026-11-05
canonical: https://sycode.fr/blog/plafonner-le-cout-d-un-agent-ia
---
Pour plafonner le coût d'un agent IA, compte ce que la facture compte, fais refuser l'agent net quand le plafond est atteint, et pose en plus une limite de dépense chez le fournisseur, parce que ton propre compteur peut se tromper. L'agent commercial de ce site s'arrêtait à 200 000 tokens par jour, puis renvoyait le visiteur vers un appel avec moi. Depuis la refonte de fin octobre 2026, il n'existe plus, et les fonctions IA qui l'ont remplacé partagent un budget mensuel calculé en euros.

Le 13 septembre 2026, j'ai passé la journée à régler ce que cet agent avait le droit de dépenser. C'était le seul poste facturé à l'usage du site, et je venais de diviser sa facture par une quinzaine en changeant de modèle et en allégeant son contexte. Restait à décider où il s'arrêtait.

## Compter des tokens, pas des appels

Mon premier plafond comptait des appels : 800 par jour et 40 par visiteur et par heure, que j'ai ramenés ce jour-là à 150 et 15. Il ne tenait de toute façon pas. Le compteur vivait en mémoire, donc repartait à zéro à chaque redémarrage du conteneur, c'est-à-dire à chaque déploiement. Il garantissait 800 appels depuis le dernier déploiement, et je déploie souvent. Je l'ai passé dans SQLite pour qu'il survive aux déploiements.

Restait l'unité, qui était mauvaise. Un appel n'a pas de prix fixe : le visiteur choisit la taille de son message, et cette entrée-là n'est pas mise en cache. À 2 000 caractères par message, seize messages pesaient environ 8 000 tokens d'entrée, le double du préfixe système. Cent cinquante appels courts et cent cinquante appels saturés ne se paient pas pareil. J'ai ramené le message à 600 caractères, et le vrai garde-budget est devenu un total de tokens par jour : 200 000, entrée fraîche et sortie additionnées. Les tokens relus en cache n'y comptaient pas, puisqu'ils sont facturés à un dixième et constants d'un appel à l'autre.

Les 200 000 venaient d'un ordre de grandeur : une conversation ordinaire tournait autour de 5 000 tokens facturés hors cache, donc une quarantaine de conversations pleines par jour. Je ne fais plus confiance à mes estimations à l'œil : le préfixe que j'avais compté à 3 900 tokens en pesait 7 400 une fois mesuré, le français coûtant 2,4 caractères par token. C'est pour ça que chaque appel écrivait sa consommation dans un journal.

Ce journal donne la réponse que les ordres de grandeur ne donnaient pas. Entre le 13 septembre et le 26 octobre, il a enregistré 34 appels, répartis sur cinq jours. Le jour le plus chargé est le 13 septembre lui-même, celui des réglages, avec 12 292 tokens comptés : 6 % du plafond.

## À la limite, un refus net et un bouton d'appel

Le contrôle passait au début de chaque requête, avant les limites par visiteur et avant tout appel au modèle : si les tokens consommés depuis minuit UTC atteignaient 200 000, la route répondait 429 avec « Le service a atteint son plafond du jour. Réserve un appel, on en parle de vive voix. ». La bulle affichait ce message et proposait de réserver l'appel. Il n'y avait ni modèle moins cher, ni réponse raccourcie : un refus ne coûte rien, alors qu'une réponse dégradée coûte encore. Le visiteur perdait la conversation en cours et gardait le bouton d'appel, ce vers quoi l'agent le conduisait de toute façon.

Minuit UTC tombe à 1 h du matin à Paris l'hiver et à 2 h l'été. Le compteur repartait à zéro quand personne ne regardait.

Le plafond n'a jamais été atteint en production.

Ce plafond était un seuil, pas un mur. Le contrôle se faisait avant l'appel et la comptabilité après : l'appel qui franchissait la ligne n'était pas refusé, ni ceux déjà partis au même moment. Chacun était borné en sortie à 2 000 tokens.

Il y avait aussi le cas où la base de comptage est injoignable. Le garde-budget sautait alors, et il restait les plafonds en appels, 150 par jour et 15 par visiteur et par heure. J'avais choisi de laisser passer : un plafond approximatif vaut mieux qu'une route morte. Le coût de ce choix était de retomber sur l'unité que j'avais abandonnée, avec ses défauts.

## Le compteur qui ne voyait pas ce que la facture voyait

Jusqu'au 26 octobre 2026, la route n'enregistrait la consommation d'un appel qu'à la fin du chemin réussi, juste avant de répondre. Tous les chemins qui sortaient avant, un refus du modèle, une sortie coupée par `max_tokens`, une réponse sans texte, un JSON illisible, étaient facturés par le fournisseur et absents du journal. Le garde-budget ne bornait donc que ce qu'il avait vu, et il est resté ainsi du 13 septembre, jour où je l'ai branché, au 26 octobre. Les 34 appels du journal sont donc un minimum.

Ces appels ratés sont de la même famille que celui du 13 septembre : j'avais descendu `max_tokens` à 600 « pour le coût ». Or ce réglage est un plafond, pas un budget : on ne paie que les tokens produits, donc l'abaisser n'économise rien sur une réponse courte et ne fait que couper les longues. Le tour de démonstration, le moment qui vend, sortait tronqué, `JSON.parse` levait une erreur et la route répondait 503. Je l'ai remonté à 2 000 le jour même. Mais une sortie tronquée reste un appel facturé, et le compteur ne la voyait toujours pas.

Je l'ai vu en comparant mon journal au relevé de la console Anthropic : la console comptait plus que moi. Depuis le 26 octobre, la consommation est enregistrée dès que la réponse du modèle arrive, avant toute branche de contrôle.

## Le plafond que mon code ne pose pas

Mes plafonds sont applicatifs. L'histoire du compteur montre pourquoi ils ne suffisent pas : un compteur peut se tromper, ou ne pas voir une catégorie d'appels pendant six semaines. Le seul plafond infranchissable est la limite de dépense de la console du fournisseur. J'en ai posé une sur la clé du site : mes compteurs sont les bretelles, elle est la ceinture.

Je me suis fait avoir de la même façon avec les minutes de CI d'asap.cool : une ressource facturée à l'usage que personne n'avait plafonnée, jusqu'au jour où le quota du mois était vide, comme je le raconte dans [ce que coûte vraiment ton infra](/blog/cout-reel-infrastructure-saas).

## Depuis la refonte : un budget mensuel, en euros

Fin octobre 2026, j'ai retiré l'agent du site. Les fonctions IA qui restent sont plus ciblées : le pré-cadrage d'une demande de contact, la recherche « Demander », le bouton « Approfondir » des leçons et des brouillons de réponse dans mon administration. Elles passent toutes par le même client et partagent un seul budget.

Ce budget n'est plus en tokens par jour mais en euros par mois. Un plafond en tokens additionne des tokens qui n'ont pas le même prix : chez Anthropic, un token de sortie coûte cinq fois un token d'entrée, et un token relu en cache dix fois moins. Le code multiplie donc chaque catégorie par son tarif, entrée, sortie, lecture et écriture du cache, et compte le dollar comme un euro. La dépense est légèrement surestimée, ce qui coupe plutôt trop tôt que trop tard. Et le mois est l'unité de ma facture : c'est elle que je veux borner, pas une journée.

À 80 % du budget, je reçois un e-mail, une seule fois par mois. Au-delà de 100 %, chaque fonction répond qu'elle est en pause jusqu'au mois prochain, que le reste du site fonctionne et que je lis la demande moi-même. Le principe du refus net n'a pas changé, ni la limite de la console derrière.

## La même idée sur un autre produit : le coût d'une facture

Sur [Optimo France](/case-studies/optimo-france), l'unité de budget n'est pas le mois mais la facture fournisseur lue par l'IA. Entre avril et mai 2026, j'ai écrit les critères avant le premier test du moteur : au moins 85 % des lignes reconnues, 95 % des totaux justes, moins de 10 secondes, moins de 0,10 € par facture. Un moteur qui dépasse le budget par facture est écarté avant d'être choisi, comme une fonction qui dépasse son budget du mois est coupée avant de coûter. Et la lecture propose, un humain valide : une virgule mal lue fausse tout le calcul de marge, et aucun plafond de coût ne la rattrape.

## Ce que je fais, moi

Je plafonne dans l'unité de la facture, je refuse net à la limite, et je mets la limite du fournisseur derrière. Sur [asap.cool](/case-studies/asap-cool), la question est ailleurs : le serveur MCP expose 58 outils à un modèle et transmet le jeton de l'utilisateur sans clé propre, donc l'agent ne peut rien faire que l'utilisateur ne puisse pas faire lui-même. Là-bas, il s'agit de ce que l'agent peut faire ; ici, de ce qu'il peut coûter. Avant de confier un agent à tes utilisateurs, je regarde les deux. Si tu pars de zéro, [lancer un SaaS](/blog/lancer-un-saas) donne l'ordre dans lequel je pose mes décisions ; le plafond de dépense d'un agent s'y ajoute dès qu'un visiteur peut déclencher un appel facturé.

Si tu as un agent à mettre devant tes utilisateurs et que tu veux regarder avec moi ce qu'il peut coûter avant de l'ouvrir, c'est le sujet de l'offre [IA en production](/services/ia-et-agents), et tu peux prendre un créneau de 30 minutes.