Budget de tokens : éviter qu'un agent IA coûte cinq fois plus que prévu

Le coût tokens d’un agent IA dépasse presque toujours l’estimation faite sur un prototype, parce qu’un agent rappelle le modèle plusieurs fois par demande et renvoie à chaque appel tout son contexte. Un écart de cinq fois entre le budget prévu et la facture réelle s’explique en général par quatre causes mesurables : des boucles sans limite, un contexte qui grossit, un modèle trop puissant pour des tâches simples et l’absence de cache. Les quatre se corrigent avant la mise en production, à condition de mesurer le coût par tâche dès le premier jour.

Selon KPMG (2026), les revues de coûts et les budgets de tokens font désormais partie de l’approbation des projets IA en entreprise. Un comité de direction veut savoir combien coûte une demande traitée, pas le prix d’un million de tokens.

Un token est l’unité de texte facturée par les fournisseurs de LLM (grand modèle de langage). Chaque appel facture les tokens envoyés (prompt, historique, documents) et les tokens générés : dans l’IA agentique, l’enchaînement des appels fait la facture. Pour situer les tokens parmi les autres postes d’un projet, voir ce que coûte un agent IA en production, build, tokens et run compris.

Pourquoi le coût tokens d’un agent IA dérape-t-il en production ?

Le coût dérape parce qu’un agent IA multiplie les appels et renvoie à chaque fois un contexte de plus en plus long.

Les multiplicateurs les plus fréquents :

1. Les boucles de raisonnement. Un agent qui planifie, appelle un outil et recommence peut faire dix appels pour une seule demande.
2. Le contexte cumulé. Chaque appel renvoie le prompt système, la définition des outils (volumineuse avec MCP, le Model Context Protocol) et tout l’historique.
3. Le RAG trop généreux. Vingt extraits injectés là où trois suffisent.
4. Les relances automatiques. Une sortie JSON invalide relancée trois fois triple le coût.
5. Le mauvais modèle. Le modèle le plus puissant utilisé pour classer des e-mails.

Un cas typique : un agent de support estimé sur la base de deux appels par ticket en fait huit en moyenne une fois en production, avec un historique qui double à chaque échange.

Comment mesurer le coût par tâche, et pas seulement la facture mensuelle ?

La bonne unité est le coût par tâche réussie : le prix total des appels nécessaires pour traiter une demande, divisé par le nombre de demandes effectivement résolues.

Pour obtenir ce chiffre, chaque appel au modèle doit être tracé avec ses tokens d’entrée, ses tokens de sortie, le modèle utilisé et l’identifiant de la demande. Langfuse et LangSmith remplissent ce rôle : ils regroupent les appels d’une même exécution d’agent et calculent le coût de la trace complète. Le détail de la mise en place figure dans le guide d’observabilité LLM pour monitorer un agent en production.

Trois indicateurs suffisent pour piloter :

• le coût moyen par tâche, et surtout le 95e centile (les 5 % de demandes les plus chères, là où se cachent les boucles) ;
• le nombre moyen d’appels au modèle par tâche ;
• la part des tokens d’entrée dans le total, qui signale un contexte trop chargé.

Quels leviers réduisent la facture sans dégrader la qualité ?

Cinq leviers réduisent la facture, et chacun se vérifie par des evals (les tests qui mesurent la qualité des réponses sur vos cas réels) avant d’être déployé.

1. Le cache de prompt. La partie stable du contexte (prompt système, définition des outils, documents de référence) peut être mise en cache chez le fournisseur et refacturée à une fraction du prix normal. Anthropic documente ce mécanisme pour Claude dans sa documentation sur le prompt caching ; OpenAI applique un cache automatique sur les préfixes répétés. Placez tout ce qui ne change pas en début de prompt.
2. Le routage de modèles. Un petit modèle (Mistral Small, un modèle Qwen auto-hébergé, ou la version légère de Claude ou de GPT) traite la classification, l’extraction et la reformulation ; le modèle le plus capable est réservé au raisonnement difficile. Le routage se décide tâche par tâche, sur les evals.
3. La compaction du contexte. Résumer l’historique long, ne charger que les outils utiles à l’étape, limiter le RAG aux meilleurs extraits.
4. Les limites dures. Un plafond d’appels par tâche, un plafond de tokens par réponse, un délai maximal. LangGraph expose une limite de récursion qui arrête un graphe d’agent au-delà d’un nombre d’étapes ; un workflow n8n peut porter le même type de garde-fou sur une boucle. Une tâche qui atteint la limite passe à un humain au lieu de continuer à consommer.
5. Le bon outil pour la bonne tâche. Un appel d’API ou une règle métier coûte zéro token. Le comparatif RAG, agent ou automatisation n8n aide à réserver l’agent IA aux cas qui l’exigent.

Promptfoo rejoue le même jeu de cas sur deux configurations et compare qualité et coût : c’est le test qui autorise à passer sur un modèle moins cher.

Quelles alertes poser avant la mise en production ?

Il faut poser trois alertes avant la mise en production : un seuil de coût journalier, un seuil de coût par tâche et un seuil de nombre d’appels par tâche. Chacune déclenche une action définie à l’avance.

• Seuil journalier : au-delà de 150 % de la consommation habituelle, l’équipe technique est prévenue ; au-delà de 300 %, l’agent passe en mode dégradé (petit modèle seul, ou transfert systématique à un humain).
• Seuil par tâche : toute exécution qui dépasse dix fois le coût médian est journalisée pour analyse. Ce sont souvent des boucles.
• Plafond chez le fournisseur : les consoles d’API de la plupart des fournisseurs permettent de fixer une limite de dépense mensuelle. C’est le dernier filet, pas l’outil de pilotage.

Ces seuils se règlent sur deux à quatre semaines de trafic réel, puis se revoient à chaque changement de modèle. Un nouveau modèle peut produire des réponses plus longues que le précédent : l’article comparer les API de modèles au-delà du prix au token rappelle pourquoi le tarif affiché ne suffit pas.

Qui paie les tokens, et comment l’écrire dans le contrat ?

Les tokens sont un coût variable qui doit apparaître séparément du prix de construction et du run. Sur les projets d’agents IA qu’on construit, les tokens LLM sont refacturés au coût réel, sans marge, ou payés directement sur vos propres clés d’API : vous voyez la consommation chez le fournisseur et vous gardez la main sur le plafond.

Ce qu’un contrat d’agent IA devrait préciser :

• le coût par tâche estimé, avec l’hypothèse de volume ;
• le modèle retenu pour chaque étape et la règle de routage ;
• les limites dures configurées et le comportement de l’agent quand elles sont atteintes ;
• qui reçoit les alertes.

Le suivi des coûts fait partie de la maintenance, conseillée après la mise en production : 350 € par mois, l’équivalent d’une journée pour le monitoring, les correctifs et les ajustements, tokens en sus au coût réel.

Le chiffre à obtenir avant de signer

Avant de valider un projet d’agent IA, demandez un coût par tâche estimé sur vos propres cas, avec le 95e centile et le nombre d’appels par demande, plutôt qu’un forfait de tokens mensuel. Faites tourner le prototype sur cinquante demandes réelles, dont les plus longues et les plus ambiguës, et multipliez par votre volume mensuel : c’est la base réaliste du budget.

Le cadrage offert produit exactement ce chiffre, avec le coût de fonctionnement mensuel estimé et une proposition chiffrée ferme sous 5 jours. La grille tarifaire des agents IA et du run détaille ce qui est inclus dans chaque offre et la façon dont les tokens sont facturés.