Il y a peu, de nombreuses entreprises ont commencé à mettre en œuvre activement des agents d’IA dans une grande variété de processus de travail. Très rapidement, le coût de leur utilisation est devenu un enjeu majeur pour les entreprises. De plus, cette question ne concerne pas uniquement le service financier : aux préoccupations budgétaires s’ajoutent des problèmes de fiabilité, de stabilité de fonctionnement ou encore de sécurité de l’information. En effet, le coût de l’automatisation d’un même processus varie considérablement d’un déploiement à l’autre, est imprévisible et peut être soumis à des facteurs externes.
De plus, pour un acteur malveillant qui s’en prend à une organisation, tout processus automatisé à l’aide de l’IA et vulnérable à des influences extérieures constitue, par essence, une cible de choix pour un « nouveau type d’attaque DDoS ». Les rapports d’erreurs d’application, les avis sur les produits ou les demandes d’assistance technique peuvent (tout comme n’importe quelle autre donnée externe traitée par une entreprise via l’IA) servir d’outil dans le cadre d’une attaque visant à augmenter la consommation de tokens (fragments de mots qui constituent l’unité de base des entrées et des sorties d’un LLM).
Une année de croissance fulgurante… surtout pour les factures
En 2026, les grandes entreprises ont, pour la première fois, largement dépassé leurs budgets consacrés aux systèmes d’IA. Uber avait déjà épuisé l’intégralité de son budget annuel dès le mois d’avril, tandis qu’une entreprise dont le nom n’a pas été divulgué n’avait pas fixé de limites de dépenses pour Claude et a dépensé 500 millions de dollars en un seul mois. Bien que les fournisseurs d’IA annoncent régulièrement des prix plus bas et des modèles plus efficaces, le passage des chatbots à des systèmes agents fonctionnant en continu et de façon autonome multiplie par centaines, voire par milliers, la consommation de jetons. Parallèlement, le modèle d’ « abonnement forfaitaire à 20 ou 100 dollars » destiné aux entreprises est en train de disparaître. Tous les principaux fournisseurs font désormais passer leurs clients professionnels à une facturation à l’utilisation.
En conséquence, les entreprises sont confrontées à un problème que les industries de l’hébergement cloud et des communications mobiles connaissent trop bien. En l’absence de systèmes spécialisés de comptabilité analytique et de gestion, une organisation ne connaît le coût d’un processus ou d’un projet donné qu’une fois celui-ci achevé. Dans les secteurs des télécommunications et du cloud, ce problème a finalement été résolu grâce au développement de systèmes de facturation avancés, et leurs clients ont même adopté le terme spécialisé FinOps. En matière d’IA, ce processus n’en est encore qu’à ses balbutiements. De plus, la nature probabiliste de l’IA générative complique la résolution du problème.
Consommation imprévisible de jetons
Pour comprendre pourquoi les coûts augmentent si rapidement et sont si difficiles à prévoir et à contrôler, il faut se rappeler comment fonctionne un modèle de langage et ce qui fait de lui un agent d’IA. Le modèle n’a pas de mémoire persistante : il ne conserve aucune information d’une interaction à l’autre. Chaque fois que l’agent passe à l’étape suivante, l’historique complet du travail effectué sur une tâche spécifique (le contexte) doit être renvoyé au modèle : la consigne initiale, le raisonnement précédent, le contenu des fichiers qu’il a lus et les réponses de tous les outils. À chaque étape, ce « récapitulatif » s’allonge, surtout si la tâche comporte des boucles itératives. Si une étape échoue, si la réponse n’est pas claire ou si un outil renvoie une erreur, l’agent tente simplement à nouveau l’opération, ce qui ne fait que gonfler davantage le contexte. Et si la tâche est effectuée non pas par un seul agent, mais par plusieurs, qui se répartissent le travail entre eux et échangent leurs résultats, ce volume est multiplié par leur nombre. Par conséquent, la consommation de jetons n’augmente pas progressivement mais par à-coups, et il est presque impossible de l’anticiper avant de commencer la tâche.
Lorsqu’on exécute deux sessions distinctes d’interaction avec un agent d’IA pour résoudre exactement la même tâche (deux tickets d’assistance technique, deux tâches d’analyse, etc.), le nombre de tokens utilisés peut varier (l’écart peut même être ). Cette variation dépend du nombre d’étapes, d’erreurs et de tentatives nécessaires pour résoudre la tâche. L’augmentation de la consommation de ressources ne dépend pas nécessairement de la complexité de la tâche. Il existe des cas bien connus où l’IA s’est retrouvée prisonnière d’une « boucle de réflexion » et a gaspillé une quantité absurde de ressources pour des tâches insignifiantes.
Les trois générations d’IA utilisées dans les systèmes d’entreprise consomment les ressources de manière totalement différente :
- Le machine learning classique. Il fonctionne généralement avec des données bien structurées et ne requiert pas forcément beaucoup de ressources informatiques. La consommation de ressources est prévisible et faible. Il s’agit d’un poste budgétaire fixe.
- Un chatbot ou tout autre assistant d’IA basé sur un LLM. Il consomme des jetons, mais le rythme est déterminé par un être humain : un employé lance manuellement une tâche, puis évalue le résultat et met le processus en pause. Le coût augmente à peu près proportionnellement au nombre d’utilisateurs actifs et peut être estimé de manière approximative en fonction du nombre de licences.
- Un agent d’IA autonome. Une personne se fixe un objectif puis se retire, et le système décide alors de lui-même de la marche à suivre et du nombre d’étapes nécessaires. Le compteur continue de tourner jusqu’à ce que la tâche soit considérée comme terminée, et il n’y a pas de plafond prévisible pour les coûts.
La tokenomics dans les attaques : le « déni de portefeuille », nouvelle forme d’attaque DDoS
Étant donné que les appels aux modèles de langage (LLM) sont nettement plus coûteux que les appels logiciels standard habituels, l’automatisation des tâches courantes en entreprise entraîne un coût inhabituellement élevé. Par exemple, Gartner estime que le traitement d’une seule demande d’assistance client à l’aide d’un LLM coûte environ 3 dollars. On imagine facilement comment des pirates pourraient inonder une entreprise de milliers de requêtes longues et complexes générées par un modèle LLM peu coûteux, causant ainsi un préjudice financier considérable. Comme le processus est automatisé, il se peut que certaines anomalies ne soient pas détectées immédiatement.
Si un pirate informatique sait quel système d’agent et quel LLM sont utilisés dans un processus opérationnel, il peut mener une attaque plus ciblée et causer des dommages bien plus importants. Les auteurs de l’étude GitInject ont estimé qu’un pirate capable de créer des tickets GitHub au sein d’une organisation utilisant des agents d’IA pour l’analyse des erreurs, par le biais d’une seule attaque (avant que les mécanismes de défense de GitHub ne se déclenchent), peut causer jusqu’à 111 dollars de dommages et dépenser 400 minutes de GitHub Actions sur le compte de la victime. Bien entendu, une telle attaque peut être répétée à plusieurs reprises, sans que cela ne coûte rien à l’attaquant.
Le risque le plus grave, bien que difficile à quantifier financièrement, provient des attaques qui poussent les modèles LLM à produire des raisonnements excessifs. Dans l’article intitulé OverThink, les auteurs ont démontré comment une tâche formulée en termes anodins, lorsqu’elle est soumise à un modèle linguistique, aboutit certes à un résultat correct, mais consomme, ce faisant, 46 (!) fois plus de tokens qu’elle ne le devrait. De plus, toutes les tâches testées par les chercheurs ont franchi avec succès les filtres de sécurité existants.
Dans la nouvelle version du guide OWASP Top Risks for Language Models, ce problème a atteint un niveau de priorité sans précédent : la consommation illimitée de tokens est désormais désignée sous le code LLM06:2026, et parmi ses variantes, l’attaque dite de « déni de portefeuille », qui épuise le budget de la victime destiné aux modèles LLM, est clairement mise en avant.
Comment ne pas devenir victime des « nouveaux DDoS »
Avant toute chose, vous devriez abandonner le principe consistant à « utiliser l’IA juste pour le plaisir de l’utiliser ». Il n’est pas judicieux de confier toutes les tâches à des agents autonomes. Il est judicieux de procéder régulièrement à une analyse coûts-avantages de l’utilisation de l’intelligence artificielle.
De plus, nous vous recommandons de limiter les autorisations et l’ensemble des outils mis à la disposition d’un agent d’IA autonome. Moins le système a accès à des actions, plus il fonctionne efficacement sur une tâche ciblée, moins il a d’occasions de faire grimper les coûts, et moins il y a de risques que quelqu’un parvienne à le « manipuler » pour entraîner des dépenses inutiles en jetons.
Nous recommandons également de fixer des limites strictes pour la consommation de jetons et de configurer un système de notification afin d’alerter les utilisateurs lorsque ces limites sont dépassées. Il est judicieux de mettre en place plusieurs limites en parallèle : une limite par tâche, une limite quotidienne, etc. Les alertes signalant des dépassements de limites doivent être immédiatement transmises au spécialiste en charge du système afin qu’il puisse décider en toute connaissance de cause s’il convient de poursuivre ou d’interrompre le processus.
Vérifiez rigoureusement les données externes non approuvées. Toute information traitée par l’IA provenant de sources externes (qu’il s’agisse de requêtes, de demandes de renseignements, de messages ou de commentaires, ou encore de divers champs techniques susceptibles de contenir du texte arbitraire, comme les enregistrements DNS, les en-têtes HTTP ou les noms de fichiers) peut non seulement entraîner une injection de requêtes, mais aussi gonfler délibérément la charge de travail. Il est donc recommandé d’en limiter la taille et de surveiller la charge qu’elles génèrent.
Calculez le coût unitaire des travaux et comparez les factures du prestataire avec vos propres données. Le coût par analyse, par demande ou par contrôle est le seul moyen de comprendre les frais encourus et de repérer les erreurs dans les factures.
