On parle beaucoup des agents IA en ce moment. Trop, probablement. Mais pas assez du bon sujet. L’attention se concentre sur ce qu’ils peuvent faire — les capacités, les gains de productivité, les démos impressionnantes. Beaucoup moins sur ce qu’ils coûtent réellement quand ils tournent en production.
Sans vouloir être alarmiste, sur les derniers mois, les dérapages financiers liés à des agents IA commencent à peser autant — voire parfois plus — que les classiques du genre, comme des clusters Kubernetes mal dimensionnés ou des environnements de dev oubliés qui tournent 24/7.
Le problème n’est pas l’IA. C’est l’autonomie sans gouvernance.
Un agent IA, ce n’est pas juste un appel API vers GPT-4 ou Claude. C’est une boucle. L’agent raisonne, appelle des outils, relance des requêtes, parfois s’auto-corrige, parfois boucle. Et chaque itération, c’est des tokens consommés. Des appels Azure OpenAI ou Amazon Bedrock facturés. Des fonctions Lambda déclenchées. Du compute qui tourne.
Le souci, c’est que contrairement à une application classique où l’on peut anticiper un volume d’appels, un agent autonome a un comportement fondamentalement non déterministe. On ne sait pas combien de boucles il va faire. Il est difficile d’anticiper précisément le nombre de tokens qu’il va consommer pour traiter une demande. Et surtout, on ne sait pas à quelle fréquence il va être sollicité une fois que les équipes métier vont commencer à l’utiliser pour de vrai.
Ce type d’écart commence à apparaître : un POC qui coûte 200 € par mois. Tout le monde est content. On passe en prod. Trois mois plus tard, la facture Azure est passée à 8 000 €, et personne ne comprend pourquoi. L’agent fonctionne bien. Il fait exactement ce qu’on lui a demandé. Mais il le fait 400 fois par jour au lieu de 15, avec des chaînes de raisonnement qui font parfois 30 allers-retours au lieu de 3.
L’angle mort qui revient le plus : l’absence de métriques de coût par exécution
Dans beaucoup de cas, les équipes qui déploient ces agents ont idée limitée ou inexistante du coût unitaire d’une exécution. Elles savent combien coûte l’infra globale à la fin du mois. Mais demandez-leur combien coûte un ticket traité par l’agent, une synthèse de document générée, une réponse client produite — silence.
C’est un problème structurel. Parce que sans coût unitaire, on ne peut pas piloter. On ne peut pas arbitrer. On ne peut pas dire « ce use case là, il est rentable » ou « celui-ci, il coûte plus cher que le process manuel qu’il remplace ».
Et c’est là que le FinOps entre en jeu, mais un FinOps adapté. Pas celui qu’on connaît sur le compute classique, avec des Reserved Instances et du rightsizing. Un FinOps qui intègre les tokens, les appels d’API, les chaînes d’orchestration, les boucles d’agents. Un FinOps qui parle en coût par tâche accomplie, pas en coût par VM.
Les erreurs que l’on rencontre souvent
Il y a des patterns qui reviennent assez systématiquement.
Le premier, c’est l’absence de limites sur les boucles d’agents. Pas de max iterations, pas de timeout financier, pas de circuit breaker. L’agent peut tourner indéfiniment si la tâche est ambiguë. Il arrive qu’un agent de classification documentaire boucle 40 ou 50 fois sur un PDF mal formaté avant de produire un résultat inutilisable. Coût d’une seule exécution de ce type : facilement 10 à 15 €. Multiplié par le volume quotidien, ça chiffre vite.
Deuxième pattern : le choix du modèle. La tentation est de mettre GPT-4o ou Claude Opus partout, y compris pour des tâches simples de routing ou d’extraction. On utilise un modèle à 15 $/million de tokens en entrée pour des jobs qu’un Haiku ou un GPT-4o-mini ferait probablement aussi bien à un dixième du prix. C’est un peu comme prendre un camion 38 tonnes pour livrer une pizza. Ça marche. Mais c’est difficile à justifier.
Troisième pattern, et celui-là est plus vicieux : le re-prompting massif. À chaque étape de la chaîne, on renvoie tout le contexte. L’historique complet. Les instructions système. Les exemples few-shot. On parle de 4 000, 8 000, parfois 15 000 tokens de contexte renvoyés à chaque appel. Sur une chaîne de 10 étapes, ça fait exploser la facture, et personne ne regarde parce que « ça fait partie du prompt ».
Des pistes pour limiter les dégâts
Il n’existe pas de solution magique. Mais certaines approches semblent bien fonctionner.
D’abord, instrumenter. Vraiment. Pas juste les métriques Azure Monitor ou CloudWatch de base. Il s’agit de tracer chaque exécution d’agent avec le nombre de boucles, le nombre de tokens in/out, le modèle utilisé, le temps total, et idéalement un tag business (quel use case, quel client, quel process). Des outils comme LangSmith ou Helicone commencent à bien couvrir ce besoin. Mais un middleware léger fait maison peut aussi suffire.
Ensuite, poser des garde-fous financiers. Un budget par exécution. Un nombre max de boucles. Un fallback vers un modèle moins cher quand la tâche est simple. Ce n’est pas de la sur-ingénierie, c’est plutôt de la survie budgétaire.
Et puis il y a le travail de fond : revoir l’architecture des prompts pour réduire le contexte inutile, utiliser du caching sémantique quand c’est pertinent, et surtout challenger systématiquement le choix du modèle à chaque étape de la chaîne. Un agent bien conçu, c’est sans doute un agent qui sait quand utiliser un gros modèle et quand un petit suffit.
Une intuition sur la suite
On est peut-être en train de reproduire avec les agents IA ce qu’on a fait avec le cloud il y a dix ans. On fonce. On déploie. On itère. Et on découvre la facture après. L’histoire du cloud nous a appris qu’il faut entre 3 et 5 ans à une entreprise pour mettre en place une gouvernance financière correcte. Avec les agents IA, ce luxe-là n’existera probablement pas. La vélocité des coûts est bien plus élevée, et les volumes vont exploser.
« Un agent IA qui fonctionne bien n’est pas forcément un agent IA maîtrisé. Tant qu’on ne connaît pas le coût de chaque tâche qu’il exécute, on pilote un peu à l’aveugle. »
« L’IA autonome sans FinOps, c’est un peu comme une carte bleue sans plafond donnée à quelqu’un de brillant mais sans notion de budget. »
Le sujet n’est pas de freiner l’adoption. Au contraire. C’est plutôt de s’assurer qu’on peut scaler ces agents sans que la facture devienne le principal frein, six mois après le déploiement.
C’est exactement le type de problématique accompagnée chez YopoConsulting — aider les équipes à déployer de l’IA en production avec une vision claire des coûts, des garde-fous concrets, et une gouvernance FinOps adaptée aux nouvelles briques cloud. Pour savoir où en est votre organisation sur ces sujets, un assessment de maturité FinOps gratuit est disponible — ça prend quelques minutes et ça donne déjà une bonne photo de départ. Si le sujet vous parle, on peut en discuter.