Combien coûte réellement un agent IA en production ?

Le prix du modèle ne donne pas le coût de l’agent

Le coût réel d’un agent IA dépend du nombre d’étapes qu’il exécute, du contexte qu’il transporte, des outils qu’il appelle, de ses boucles de vérification et de l’infrastructure nécessaire à son fonctionnement.

Un tarif par million de tokens décrit le prix d’un appel, pas le coût d’un résultat. Entre les deux s’intercalent le nombre d’étapes que l’agent enchaîne pour aboutir, le volume de contexte qu’il relit à chacune d’elles et le nombre de fois qu’il recommence avant de produire quelque chose d’exploitable. C’est dans cet intervalle que se creuse l’écart entre deux architectures affichant le même prix catalogue.

Une étude publiée en avril 2026 par Bai et al. en donne l’ordre de grandeur. En analysant les traces d’exécution de huit LLM frontier sur le benchmark SWE-bench Verified, ses auteurs mesurent une consommation environ mille fois supérieure pour les tâches de coding agentique par rapport à des tâches de code reasoning ou de chat, et identifient les tokens d’entrée, et non les tokens de sortie, comme le principal moteur du coût. Deux exécutions d’une même tâche peuvent par ailleurs varier jusqu’à 30 fois en volume de tokens.

Cette variabilité n’est pas un artefact de mesure, c’est une propriété du système : un budget calculé sur une exécution moyenne ne dit rien de ce que coûtera la même demande demain. La même étude ajoute que la dépense supplémentaire n’achète pas de la qualité, la précision plafonnant à un niveau de coût intermédiaire avant de se dégrader lorsque la consommation continue d’augmenter. Un agent qui consomme beaucoup est plus souvent un agent qui s’égare qu’un agent qui approfondit.

Ces chiffres proviennent d’un dispositif précis, la résolution de tickets logiciels sur un benchmark public, et ne se transposent pas tels quels à un agent de support client ou de back-office. Ils indiquent en revanche où regarder : ce n’est pas le prix du modèle qui creuse l’écart, c’est la mécanique d’exécution qui l’entoure.

Ce qui détermine réellement la facture d’un agent

Le coût se forme à plusieurs niveaux, et ces niveaux ne s’additionnent pas sagement : le contexte alimente les boucles, les boucles multiplient les appels d’outils, et un échec relance la chaîne entière. Ce sont ces effets de composition, davantage que le détail de chaque ligne de facture, qui expliquent que deux agents rendant le même service présentent des factures sans commune mesure.

Le modèle fixe un tarif, pas un coût

Le prix des tokens d’entrée et de sortie reste le point de départ, mais un modèle moins cher à l’unité n’est pas nécessairement moins cher pour accomplir une tâche : s’il exige davantage d’itérations, il consomme plus d’appels, plus de contexte et plus de temps de supervision. L’étude d’avril 2026 observe d’ailleurs que les écarts d’efficacité entre modèles sur des tâches identiques pèsent plus lourd que la difficulté attribuée à ces tâches par des annotateurs humains. La seule métrique comparable devient donc le coût par tâche correctement accomplie, que nous replaçons parmi les autres critères de sélection dans notre décryptage sur le choix d’un LLM.

Le contexte est le principal moteur de consommation

À chaque étape, l’agent ne repart pas de zéro. Il relit l’historique de la conversation, ses instructions système, les documents qu’il a récupérés, les résultats renvoyés par les outils, sa mémoire de travail et les schémas des API qu’il peut appeler. Rien de tout cela n’est payé une seule fois : ces tokens sont refacturés à chaque appel, si bien qu’une étape supplémentaire ne coûte pas un appel de plus, mais un appel de plus chargé de tout ce qui précède.

C’est ce mécanisme que l’étude de Bai et al. rend visible en désignant les tokens d’entrée comme le moteur principal de la consommation : dans son dispositif, les tokens d’entrée relus depuis le cache dominent à la fois le volume et le coût, alors même que les tokens de sortie sont facturés bien plus cher à l’unité. Un contexte mal maîtrisé alourdit donc la facture sans produire une ligne de réponse supplémentaire, ce qui fait de la sélection de l’information transmise une décision d’architecture, traitée dans notre décryptage sur le context engineering.

Les boucles et la vérification coûtent plus que la génération

Un agent répond rarement en un appel. Il planifie, appelle un outil, analyse le retour, corrige, appelle un second outil, vérifie, puis recommence si le résultat ne tient pas. Chaque tour ajoute un appel au modèle et, comme il transporte l’état accumulé, le coût marginal d’une itération augmente à mesure que la trajectoire s’allonge. Les échecs et les reprises ne sont pas des cas particuliers à écarter d’un budget : ce sont des exécutions complètes, facturées comme les autres, qui ne produisent aucun résultat utilisable.

Une étude de janvier 2026 chiffre ce déséquilibre. En analysant les traces de 30 tâches de développement exécutées par le framework multi-agents ChatDev avec le modèle de raisonnement GPT-5, ses auteurs attribuent en moyenne 59,4 % des tokens à la phase itérative de code review, quand la conception en absorbe 2,4 % et la génération initiale du code 8,6 %. Ces résultats sont présentés par leurs auteurs comme préliminaires et limités à un seul framework et à un seul modèle, ce qui interdit d’en faire une loi générale. Le sens de l’écart rejoint néanmoins l’étude précédente : ce n’est pas la première production qui coûte, c’est ce qu’il faut faire ensuite pour qu’elle devienne acceptable.

La conséquence opérationnelle est directe. Optimiser le prompt de la génération initiale n’offre presque aucun levier économique ; encadrer la boucle de correction en offre un considérable.

Autour du modèle : les outils, l’infrastructure et l’humain

La facture LLM ne constitue qu’une partie du total. Un agent utile appelle rarement le modèle seul : il interroge un moteur de recherche, une base vectorielle dont l’indexation et les requêtes se paient, des API métier parfois facturées à l’appel, un service d’OCR, du stockage, une base de données et une couche de monitoring. Chacun de ces appels est déclenché par une décision de l’agent, ce qui rend leur volume aussi variable que celui des tokens. Le coût se mesure donc au niveau du workflow complet, jamais du seul modèle.

Restent les postes que peu de business cases inscrivent au départ : l’orchestration, les journaux, les traces, les évaluations récurrentes et le temps humain de validation ou de reprise. Une étude de cas publiée en juillet 2026, retraçant douze semaines de développement menées par un ingénieur expérimenté travaillant avec des agents de codage, décrit précisément ce déplacement : la production de code devient abondante et peu coûteuse, tandis que le jugement d’ingénierie nécessaire pour la rendre inspectable et maintenable devient la ressource rare. C’est un récit d’expérience unique et non une mesure généralisable, mais il rejoint une logique simple : plus un agent produit vite, plus la revue humaine devient le poste dimensionnant.

Comment réduire le coût sans dégrader la qualité ?

Les leviers efficaces portent sur la mécanique d’exécution, rarement sur le tarif négocié. Quatre d’entre eux se mettent en place sans refonte de l’architecture.

Router les tâches vers le bon modèle

Toutes les étapes n’exigent pas le modèle le plus puissant. Classer une demande, extraire un champ ou reformuler une requête relèvent d’un modèle léger ; les décisions complexes justifient un modèle frontier. Le routage consiste à décider ce qui va où, en arbitrant ensemble qualité, coût et latence plutôt qu’en imposant un modèle unique à tout le parcours. Comme les écarts d’efficacité entre modèles restent importants à tâche égale, cet aiguillage peut produire davantage d’économies qu’une renégociation tarifaire.

Transporter moins de contexte

Transmettre « tout ce qui pourrait servir » revient à payer, à chaque étape, une information qui ne sera pas utilisée. Le travail consiste à ne fournir à chaque appel que ce dont il a besoin : un historique résumé plutôt que la conversation intégrale, les extraits pertinents plutôt que les documents entiers, des résultats d’outils filtrés plutôt que des réponses d’API brutes. Le gain est double, puisqu’un contexte plus court réduit la facture et limite la dispersion du modèle.

Encadrer les boucles

Une boucle agentique doit avoir une fin définie ailleurs que dans le raisonnement du modèle. Un plafond d’itérations empêche une trajectoire de s’étendre indéfiniment. Un budget de tokens et un budget monétaire par exécution transforment le coût en contrainte explicite plutôt qu’en constat de fin de mois. Des conditions d’arrêt formulées à l’avance évitent qu’un agent poursuive une piste déjà invalidée. Une stratégie de repli, escalade vers un humain ou retour à un traitement déterministe, garantit enfin qu’atteindre la limite ne revient pas à échouer sans réponse.

Ces garde-fous doivent rester externes à l’agent. L’étude d’avril 2026 montre en effet que les modèles prédisent mal leur propre consommation : la corrélation entre coût annoncé et coût constaté ne dépasse pas 0,39, et les modèles sous-estiment systématiquement la dépense réelle. Un agent n’est pas en mesure de tenir son propre budget.

Mesurer par workflow, pas en moyenne

Une moyenne globale en euros par million de tokens ne permet jamais d’identifier quel agent ou quel parcours détruit l’économie du système. La granularité utile suit la chaîne réelle : cas d’usage, agent, étape, modèle, tokens, outils, résultat, coût. C’est le même socle de traces que celui décrit dans notre décryptage sur l’observabilité des agents, interrogé ici avec une question financière.

Tableau de bord FinOps minimal

Sept indicateurs suffisent pour commencer. Les premiers expliquent la consommation, le dernier permet de l’arbitrer.

Le p95 mérite une attention particulière. Lorsque deux exécutions d’une même tâche peuvent varier d’un facteur 30, la moyenne masque exactement ce qui met un budget en défaut.

À retenir

Comparer deux agents revient à comparer deux chaînes de production, pas deux tarifs. Le prix du modèle n’en est qu’une entrée ; le reste se joue dans le contexte transporté, la longueur des trajectoires, le nombre d’outils sollicités, la part des exécutions qui échouent et le temps humain qu’il faut y consacrer. Le seul chiffre qui autorise un arbitrage reste le coût par tâche correctement accomplie, mesuré sur un volume réel plutôt que sur une démonstration.

Ce changement de perspective devient déterminant au moment où un agent quitte le prototype, un passage dont nous détaillons les écarts dans notre décryptage sur l’industrialisation.