Un appel isolé à un modèle a un coût que l’on consulte dans un tarif. Un agent, non. Donnez à un système la liberté de planifier, d’appeler des outils, de lire le résultat et de décider s’il vaut la peine de réessayer, et une requête d’utilisateur devient un nombre inconnu d’opérations facturées, décidé à l’exécution par l’agent et non à l’avance par vous. C’est là toute la promesse de l’IA agentique, et c’est aussi la raison pour laquelle les équipes financières ouvrent la facture en fin de mois sans savoir l’expliquer.
Pourquoi l’IA agentique coûte-t-elle bien plus qu’un simple appel au modèle ?
L’IA agentique coûte plus qu’une réponse isolée parce qu’une requête d’utilisateur déclenche une chaîne : étapes de planification, appels d’outils, recherche documentaire, relecture du contexte qui s’accumule, et reprises quand une étape échoue. L’inducteur de coût est la tâche achevée, pas le token, et le nombre d’étapes qu’une tâche demande est décidé par l’agent pendant l’exécution. La gérer consiste à mesurer le coût par tâche achevée plutôt que par appel, à poser des plafonds d’étapes et de dépense dans le produit lui-même, et à rattacher chaque exécution au client et à la fonctionnalité qui l’ont provoquée.
Une requête, un nombre inconnu d’opérations
Une réponse de conversation est une transaction : une entrée, une sortie, une ligne sur la facture. Une exécution d’agent est une boucle. Elle planifie, appelle un outil, lit ce qui revient, décide si cela suffit, et recommence jusqu’à ce qu’elle estime avoir fini ou qu’une limite l’arrête. Deux utilisateurs qui posent ce qui semble être la même question peuvent produire des factures très différentes selon que la première tentative a bien tourné ou non. L’unité que voit le client, et en général l’unité que vous avez tarifée, c’est la requête. L’unité qui vous est facturée, c’est l’étape, et rien dans le tarif ne vous dit combien d’étapes une requête donnée va demander.
Le contexte grossit, et vous le payez à chaque tour
Ce qui surprend n’est pas le nombre d’appels mais ce que chaque appel transporte. À chaque étape, l’agent renvoie l’historique accumulé : l’instruction d’origine, les outils déjà appelés, ce que chacun a renvoyé, son propre raisonnement jusque-là. Une exécution de dix étapes ne coûte pas dix fois un appel isolé, elle coûte davantage, parce que l’entrée grossit à chaque passage. Ajoutez des documents récupérés et des sorties d’outils elles-mêmes longues, et le contexte peut devenir le coût dominant de l’exécution. Mettre le contexte en cache et élaguer ce qui ne sert pas aide, et ce sont deux décisions de produit à prendre exprès, pas à découvrir sur une facture.
L’échec est une ligne de coût, pas une exception
Les agents réessaient. Un outil dépasse son délai, une API renvoie quelque chose de mal formé, une étape produit une sortie que la suivante ne peut pas utiliser, et la boucle recommence. Chacune de ces tentatives est facturée, que l’exécution ait fini par réussir ou non, et les exécutions qui échouent complètement sont les plus chères de toutes : coût entier, valeur livrée nulle. Dans un produit bien instrumenté, les exécutions échouées et reprises forment une ligne visible dont quelqu’un répond. Dans la plupart des produits, elles sont invisibles, noyées dans un total que l’on lit ensuite comme le coût du travail qui a réussi.
Le coût par tâche achevée est le chiffre qui compte
La mesure utile n’est ni le coût par token ni le coût par appel. C’est le coût complet d’une tâche achevée : chaque étape, chaque appel d’outil, chaque reprise, chaque tentative échouée qui a précédé celle qui a marché, rattachée au client et à la fonctionnalité qui l’ont provoquée. C’est une question de coûts par activités, et elle se comporte comme telle. Définissez l’activité comme l’entreprise la définit, une demande résolue, un contrat rédigé, une facture rapprochée, puis affectez les ressources qu’une unité a réellement consommées. Le coût d’une tâche achevée connu, tout ce qui suit devient une question à laquelle on peut répondre : quel prix pratiquer, quels clients sont rentables, et si l’agent revient moins cher que le processus qu’il a remplacé.
Un agent ne consomme pas un prix par token. Il consomme un prix par tentative, et c’est lui qui décide combien de tentatives il fait.
Ce qu’il faut mettre en place avant de livrer le prochain agent
Avant qu’une fonctionnalité agentique ne soit ouverte à tous, donnez-lui trois choses. Un plafond strict d’étapes et de dépense par exécution, imposé dans le produit et non contrôlé sur la facture mensuelle. Un enregistrement, pour chaque exécution, du client, de la fonctionnalité et de l’issue auxquels elle appartient, pour que le coût puisse être affecté au lieu d’être dilué dans une moyenne. Et un coût par tâche achevée présenté à côté du taux de réussite, parce que les deux chiffres ne veulent dire quelque chose qu’ensemble. Un agent qui réussit quatre-vingt-dix pour cent du temps à quatre fois le coût prévu n’est pas une fonctionnalité qui marche, et aucun total de facture ne vous le dira tout seul.
Réservez une démonstration en direct de CostCtrl et voyez comment étapes, appels d’outils, reprises et exécutions échouées se rejoignent en un coût réel par tâche et par compte.
À lire également : le coût à servir avec l’IA et le coût de capacité avec l’IA.