Coût d'un agent IA : tenir la facture un jour de pic

La facture d'un agent IA explose un jour de pic parce que chaque message déclenche un ou plusieurs appels payants au modèle, et que rien ne s'interpose entre le volume et la dépense. Pour la tenir, j'empile cinq protections : trier sans IA ce qui n'en a pas besoin, servir depuis un cache ce qui a déjà été répondu, profiter de la mise en cache des prompts chez le fournisseur, router le simple vers un petit modèle, et poser un plafond de dépense journalier avec alerte.

Je suis développeur Sylius et Symfony indépendant, et je construis des agents IA pour des boutiques en ligne. Je ne donnerai pas de montant ici, il dépend de votre volume, de vos textes et du fournisseur. En revanche, la mécanique est toujours la même, et elle se règle avant le jour où vous en avez besoin.

Pourquoi la facture grimpe-t-elle autant un jour de pic ?

Les fournisseurs de modèles facturent au token, un petit morceau de mot, à la fois sur ce que le modèle lit et sur ce qu'il écrit. Or un agent lit beaucoup : son prompt système, les règles du commerçant, l'historique du client, parfois plusieurs documents. Un message court du client peut donc déclencher une lecture longue, plusieurs fois si l'agent enchaîne des outils.

Un jour de soldes, ou quand un transporteur prend du retard, le nombre de messages se multiplie, et la dépense suit mécaniquement. L'OWASP, fondation de référence en sécurité applicative, a même fait de la consommation non bornée l'un des dix risques majeurs des applications à base de modèles de langage. Elle décrit le « déni de portefeuille », un afflux de requêtes qui exploite la facturation à l'usage, et recommande quotas, limites et surveillance des consommations anormales. Un pic légitime produit le même effet qu'une attaque : il faut s'y préparer de la même manière.

Quels messages n'ont pas besoin d'IA du tout ?

La première économie est de ne pas appeler le modèle. Sur l'agent de service après vente que je construis en ce moment pour une boutique sous Sylius 2, les notifications automatiques, les simples remerciements et les rebonds de messagerie sont triés par des règles classiques, sans IA. Ils ne coûtent rien.

De même, retrouver le client se fait par le code, sur son adresse e-mail exacte : c'est plus fiable qu'une déduction du modèle, et c'est gratuit. Lire ses commandes et ses expéditions est une requête en base de données. Le modèle n'intervient que pour ce qu'il sait faire mieux qu'une règle : comprendre une demande formulée librement et proposer une réponse adaptée.

Comment fonctionne un cache de réponses sans fuite entre clients ?

Un cache est une mémoire de réponses déjà calculées. Quand la même question revient, on sert la réponse prête au lieu de repayer le modèle. « Où en est ma commande ? » est l'exemple type : la question revient sans cesse, et la réponse repose sur une donnée que le code sait lire.

La règle absolue est qu'une réponse contenant des données personnelles est rangée sous l'identité du client, et ne peut jamais être servie à quelqu'un d'autre. Ce qui se partage, ce sont les parties communes : la formulation d'une règle de retour, l'explication d'un délai. Un cache mal clé, qui confond deux clients, transforme une économie en fuite de données, ce qui rejoint la question des accès par rôle.

Qu'est-ce que la mise en cache des prompts chez le fournisseur ?

C'est un second cache, géré par le fournisseur du modèle. Quand le début de votre requête est identique d'un appel à l'autre, le fournisseur réutilise le travail déjà fait sur ce début, et le facture moins cher. Pour un agent, ce début stable, c'est le prompt système et les règles, qui sont les mêmes pour chaque message.

Chez Anthropic, la documentation sur le prompt caching indique une durée de vie par défaut de cinq minutes, rafraîchie à chaque utilisation, avec une option d'une heure plus chère à l'écriture, et une lecture depuis le cache facturée à un dixième du prix normal des tokens d'entrée, voire moins sur certains modèles. Chez OpenAI, la documentation équivalente précise que la mise en cache est activée par défaut sur les modèles compatibles, qu'elle exige que tout le début de la requête soit identique, et annonce une réduction pouvant aller jusqu'à 95 % sur les tokens réutilisés.

La conséquence pratique est simple : placez toujours ce qui ne change pas en tête de la requête, et ce qui varie, le message du client et ses données, à la fin. Un horodatage glissé au début suffit à casser le cache. Un jour de pic, les messages se suivent de près, et c'est justement là que ce cache est le plus rentable.

À quoi sert un routeur de modèles ?

Les fournisseurs proposent des modèles de tailles différentes : les petits sont rapides et peu chers, les gros raisonnent mieux sur les cas difficiles. Un routeur est un aiguillage qui décide, message par message, lequel utiliser. Une demande de suivi claire part vers un petit modèle. Un client mécontent dont la commande mélange un retour, un échange et un code promo part vers un gros.

Le routeur doit lui-même être testé : s'il envoie un dossier délicat vers un petit modèle, l'économie se paie en réponses fausses. C'est pour cela que je rejoue des cas de référence avant chaque réglage, comme je l'explique dans l'article sur les tests d'un agent. Pour comparer les familles de modèles, l'article sur le choix d'une IA donne des repères.

Que faire quand le plafond est atteint ?

Le plafond de dépense journalier est le dernier filet. Sur l'agent que je construis, il est fixé par jour et déclenche une alerte. Quand il est atteint, l'agent ne doit ni s'arrêter en silence ni continuer : les messages restent dans la file, marqués pour un traitement humain, et la personne responsable est prévenue.

Ces protections font partie des huit couches d'un agent solide, présentées dans l'article de fond. Si vous voulez savoir comment votre agent se comporterait un jour de soldes, je propose un diagnostic IA offert : je vous rappelle sous 24 heures ouvrées et je regarde précisément où part chaque appel.