L’une des plus grandes surprises pour ceux qui mettent l’IA en production n’est généralement pas la qualité des réponses. C’est la facture des tokens.
Beaucoup de gens considèrent encore le coût d’un LLM comme s’il s’agissait de la licence d’un logiciel SaaS, avec une valeur relativement prévisible par utilisateur. En pratique, toutefois, la logique est totalement différente.
Pour la plupart des fournisseurs d’IA générative, la facturation est basée sur le nombre de tokens traités. Cela inclut les tokens envoyés au modèle, tels que les invites, les instructions système, l’historique de la conversation et le contexte récupéré par le RAG, ainsi que les tokens générés dans la réponse. Si un agent effectue plusieurs appels au modèle pour accomplir une tâche, chaque inférence représente une nouvelle consommation.
Le problème est que cette consommation augmente de manière peu intuitive. Imaginez un utilisateur ne posant qu’une seule question. En coulisse, l’agent peut interroger un index vectoriel, récupérer plusieurs documents, appeler des APIs, accéder à la mémoire, solliciter l’aide d’autres agents, effectuer plusieurs inférences intermédiaires et ne produire une réponse qu’ensuite. L’utilisateur ne perçoit qu’une seule interaction. Le système peut avoir effectué dix ou vingt appels au modèle.
Dans les architectures multiagents, cet effet est encore plus fort. Un agent spécialisé peut en consulter un autre, qui en interroge un troisième, qui réécrit une réponse avant de la restituer à l’utilisateur. Chaque étape consomme de nouveaux tokens. Sans observabilité, personne ne perçoit où le coût est réellement généré.
Un autre facteur peu évoqué est la taille du contexte. Beaucoup d’équipes pensent que l’envoi de plus de documents améliore automatiquement la qualité des réponses. Pas toujours. Outre l’augmentation des coûts, un contexte excessif peut réduire la précision du modèle, qui se retrouve à traiter des informations non pertinentes ou contradictoires. On parle ici de ce qu’on appelle la diluation du contexte (« context dilution ») : plus d’informations ne signifie pas nécessairement plus de qualité.
Il existe aussi un aspect comportemental. Pendant le développement, on teste généralement le système avec peu de requêtes. En production, des centaines ou des milliers d’utilisateurs posent des questions simultanément, beaucoup d’entre elles inattendues. De petites inefficacités deviennent de grands multiplicateurs de coût. Un flux qui gaspille seulement quelques centimes par exécution peut représenter des dizaines ou des centaines de milliers de dollars sur une année.
Le plus grand problème est que, dans la plupart des organisations, cette consommation demeure une boîte noire.
Peu d’entreprises parviennent à répondre à des questions relativement simples : quel agent est responsable de la plus grande partie de la consommation ? Quel processus présente le pire coût-bénéfice ? Combien coûte l’assistance à un client spécifique ? L’augmentation de la facture provient-elle de la croissance de la demande ou d’une dégradation de l’architecture ? Quelle part du coût provient du modèle et quelle part résulte d’un contexte excessif ou d’appels inutiles ?
Sans ces réponses, toute tentative d’optimisation devient essais et erreurs. C’est précisément pour cela que l’idée d’IA FinOps commence à gagner en importance.
Tout comme le FinOps est apparu pour maîtriser les dépenses variables dans le cloud, l’IA exige une discipline similaire. Il ne suffit pas de savoir combien a été dépensé au cours du mois. Il faut comprendre pourquoi cette dépense s’est produite.
Cela exige de surveiller la consommation par agent, par processus, par utilisateur et par unité de métier, d’établir des budgets et des alertes, de créer des indicateurs du coût par tâche exécutée et de suivre en continu la relation entre coût, qualité et valeur livrée.
Il faut aussi repenser l’architecture. Toutes les tâches n’ont pas besoin de passer par un LLM. Les règles métier, les consultations dans les bases de données, les calculs et les validations déterministes continuent d’être exécutés de manière bien plus rapide, économique et prévisible par des logiciels traditionnels. Le modèle ne doit être utilisé que lorsqu’il apporte réellement une capacité cognitive.
Une autre pratique importante consiste à réduire le contexte au minimum nécessaire. Un bon mécanisme de récupération d’informations n’est pas celui qui envoie tous les documents disponibles au modèle, mais celui qui ne livre que les preuves réellement pertinentes pour cette requête.
Il convient également d’adopter des modèles différents selon la complexité de la tâche. De nombreuses entreprises utilisent systématiquement le modèle le plus puissant et le plus cher, alors qu’une grande partie des demandes pourraient être satisfaites par des modèles plus petits, spécialisés ou même locaux, réduisant considérablement les coûts sans perte perceptible de qualité.
Enfin, les agents doivent être surveillés en continu. Comme nous surveillons le CPU, la mémoire ou la latence dans les systèmes traditionnels, nous devons suivre des métriques telles que la consommation de tokens, le coût par exécution, le nombre d’inférences par tâche, le taux de réussite, la qualité des réponses et l’impact des modifications apportées aux invites, aux modèles ou aux bases de connaissances.
Le plus grand problème ne réside que rarement dans le prix du token. Il s’agit surtout de comprendre pourquoi il est consommé. Dans l’IA d’entreprise, contrôler les coûts ne signifie plus seulement négocier des contrats avec les fournisseurs. Cela exige une visibilité sur la manière dont les agents, les modèles, le contexte, les outils et les processus interagissent pendant l’exécution de chaque tâche.
Le défi n’est pas de consommer menos de tokens. Il s’agit de s’assurer que chaque token consommé apporte une valeur concrète à l’entreprise.
