Contrôler les coûts LLM des workflows d’agents IA

Un appel LLM isolé est bon marché et facile à raisonner. Un workflow d’agent n’est ni l’un ni l’autre. Dès que vous enchaînez des appels, ajoutez une politique de retry et laissez un modèle décider combien de fois boucler, le coût cesse d’être un nombre lisible sur une page de tarifs pour devenir une distribution qu’il faut estimer.

C’est dans cet écart que les projets IA à prix fixe perdent leur marge. Ce guide explique comment mettre un chiffre sur un workflow avant son exécution, et quels contrôles empêchent réellement le dépassement plutôt que de simplement le constater.

Pourquoi les coûts d’agents sont imprévisibles

Un logiciel classique a un coût par requête essentiellement stable. Les workflows d’agents, non — pour trois raisons structurelles :

Le volume de tokens dépend du contenu, pas du nombre de requêtes. Deux utilisateurs exécutant le même workflow peuvent différer d’un facteur 20 parce que l’un a collé un contrat de 40 pages et l’autre un paragraphe.
Le flux de contrôle se décide à l’exécution. Une boucle de type ReAct tourne jusqu’à ce que le modèle se déclare satisfait. Rien dans le code ne la plafonne à trois itérations, sauf si vous avez écrit ce plafond.
Le contexte s’accumule. Dans une boucle naïve, chaque itération renvoie toute la conversation. Dix itérations d’un contexte croissant, ce n’est pas dix fois le premier appel — c’est plus proche du quadratique.

Conséquence pratique : le coût moyen d’un workflow ne vous apprend presque rien. Ce qui compte pour chiffrer un projet, c’est le p95 — le coût de l’exécution au 95^e centile — parce que c’est celle qui apparaîtra sur la facture non prévue.

Les quatre multiplicateurs de coût

Quand un workflow coûte 30 fois le montant annoncé, c’est presque toujours l’une de ces quatre causes, par ordre de fréquence des dégâts :

1. Boucles non bornées

Un agent qui replanifie jusqu’à satisfaction n’a aucun point d’arrêt naturel. Un nombre maximal d’itérations n’est pas un confort : c’est le chiffre le plus important du workflow. Définissez-le explicitement, et décidez de ce qui se passe quand il est atteint — échec bruyant, ou repli sur un chemin déterministe moins cher.

2. Retries sur les mauvaises erreurs

Rejouer une erreur de limitation de débit est correct. Rejouer une erreur de format avec exactement le même prompt revient généralement à payer deux fois le même échec. Séparez les retries de transport des retries sémantiques, et plafonnez les seconds à une ou deux tentatives avec un prompt modifié.

3. Renvoi du contexte

Si chaque étape transmet tout l’historique, vous payez les mêmes tokens plusieurs fois. Résumez entre les phases, transmettez un état structuré plutôt que des transcriptions brutes, et ne renvoyez les documents qu’à l’étape qui en a réellement besoin.

4. Modèles surdimensionnés sur des étapes triviales

Classification, routage, extraction et mise en forme n’ont presque jamais besoin de votre modèle le plus cher. Un workflow avec une étape de raisonnement lourde et six étapes légères ne devrait pas utiliser le même modèle pour les sept.

Chiffrer un workflow avant de l’exécuter

On peut estimer un workflow statiquement, sans l’exécuter, à condition de disposer de trois données par étape : le modèle, un nombre attendu de tokens en entrée et un nombre attendu en sortie. L’arithmétique n’a rien de remarquable — c’est la discipline de la faire avant de chiffrer le projet qui paie.

cout_etape = (tokens_in  / 1M × prix_in)
           + (tokens_out / 1M × prix_out)

cout_run   = Σ (cout_etape × iterations_attendues)
cout_p95   = Σ (cout_etape × iterations_max)

Comparez ensuite cout_p95 au prix que vous facturez. Si une seule exécution au p95 consomme plus de quelques pour cent des honoraires, c’est le workflow qu’il faut restructurer, pas le budget qu’il faut augmenter.

Type d’étape	Gamme de modèle	Plafond d’itérations
Routage / classification	Petit	1
Extraction documentaire	Petit–moyen	1 par document
Planification / raisonnement	Grand	3–5, plafond strict
Boucle d’outils	Moyen	5–8, plafond strict
Mise en forme finale	Petit	1

Des garde-fous qui tiennent vraiment

Il y a une différence réelle entre un tableau de bord qui signale un dépassement et un contrôle qui l’empêche. Le signalement est un indicateur retardé : quand il passe au rouge, l’argent est déjà parti. Les contrôles qui valent la peine sont ceux appliqués dans le code :

Plafond par exécution. Un budget strict en tokens ou en dollars pour une exécution unique. Épuisé, l’exécution s’arrête au lieu de continuer.
Plafond quotidien par client. Une limite glissante sur 24 heures par client ou espace de travail, pour qu’une entrée pathologique ne vide pas le mois.
Plafonds d’itérations à chaque boucle. Pas un plafond global — un par boucle, parce que les boucles s’imbriquent.
Liste blanche de modèles par étape. Empêche qu’un changement de configuration promeuve silencieusement une étape bon marché vers un modèle coûteux.
Échec fermé. Si le compteur de coûts est indisponible, le workflow doit refuser de démarrer, pas continuer sans mesure.

Quoi surveiller après le lancement

Trois chiffres suffisent à la plupart des équipes, et les trois sont des distributions plutôt que des moyennes :

Coût par résultat abouti — pas par appel d’API. Un workflow qui divise par deux ses appels mais double son taux d’échec s’est dégradé.
Distribution du nombre d’itérations. Une queue qui s’allonge est le signal le plus précoce que les entrées ont dérivé par rapport à ce pour quoi vous aviez conçu le système.
Part de la dépense par étape. Si une étape représente 80 % de la facture, c’est la seule qui mérite d’être optimisée.

Le contrôle des coûts sur les workflows d’agents n’est pas d’abord un problème d’optimisation. C’est un problème de conception : décidez du plafond d’abord, puis construisez le workflow qui tient dessous.