🚀 Coût agents IA : 10 M$ en jetons ? (2026)
Découvrez comment Peter Steinberger estime 10 M$ de jetons IA : coûts des agents, infrastructure cloud et sécurité des agents IA en 2026.
Dix millions de dollars de jetons IA : le vrai coût des agents autonomes
Dix millions de dollars de jetons IA en un mois : le chiffre surprend. Peter Steinberger, créateur de l'agent open source OpenClaw et désormais salarié d'OpenAI, l'a évoqué lors de la conférence Cloudflare Connect, à San Francisco, d'après The Register. Mais il a ajouté une précision qui change tout : une partie de cette consommation ne sert à rien.
Autrement dit, on ne peut pas lire ce montant comme un tarif « à copier » pour créer un agent, ni comme une estimation fiable de ce qu'une entreprise française paierait. Le sujet, c'est plutôt ce qui se passe quand on multiplie les appels à des modèles, les essais et les tâches confiées à des agents. Tant que le système n'est pas assez solide pour livrer une valeur stable, le coût peut monter très vite.
Pour comprendre l'enjeu, il faut regarder au-delà du chiffre : comment les jetons sont facturés, pourquoi l'infrastructure locale reste un point sensible, et quelles protections deviennent indispensables quand un agent agit sans surveillance constante. Voilà une grille simple pour évaluer ces systèmes sans confondre puissance, dépense et efficacité.
Ce que recouvre réellement le chiffre de 10 millions
Un jeton est une unité utilisée par les fournisseurs d'IA pour mesurer le texte traité par un modèle. En pratique, le calcul porte sur ce qu'on envoie au modèle (instructions, historique, documents) et sur ce que le modèle renvoie en réponse. Les tarifs changent selon le modèle, le type de jeton et les conditions du fournisseur. Au final, le coût dépend à la fois du volume... et de la façon dont l'application est conçue.
Dans le cas de Steinberger, il est question d'environ 10 millions de dollars sur un mois. Il faut lire ça comme une déclaration faite lors d'une conférence, reprise par The Register, pas comme un état comptable détaillé. Les informations disponibles ne donnent pas le périmètre exact de l'estimation : quels modèles, quelle part d'essais, quel usage « en production », etc.
Et cette absence de détail compte. Un chiffre isolé ne dit pas grand-chose : une équipe peut consommer beaucoup avec des requêtes courtes et faciles, tandis qu'une autre peut dépenser la même somme sur un nombre réduit de tâches longues, avec beaucoup d'allers-retours entre plusieurs modèles. À montant égal, les réalités sont très différentes.
Un budget élevé ne signifie pas une efficacité élevée
Steinberger a lui-même tempéré le propos : « tout cela n'est pas utile », selon les éléments rapportés. Ce n'est pas un détail de communication, c'est le cœur du sujet. Dans un système d'agents, certaines étapes servent à préparer le travail, d'autres à vérifier un résultat, d'autres encore à corriger une erreur. Oui, parfois c'est nécessaire. Mais ça peut aussi tourner en rond sans améliorer la sortie finale.
Un agent qui relit plusieurs fois un document, recommence une tâche après une mauvaise interprétation, ou demande à un autre modèle de valider chaque décision consomme davantage. Si le résultat n'est pas plus fiable, ni plus rapide, alors la dépense supplémentaire ressemble surtout à du gaspillage opérationnel.
Une organisation devrait donc suivre des indicateurs concrets, pas uniquement le total mensuel :
- le coût moyen par tâche réellement terminée ;
- le taux de tâches qui nécessitent une reprise humaine ;
- le nombre d'appels au modèle par résultat exploitable ;
- le temps gagné, comparé au coût de supervision et de correction ;
- la part des requêtes qui échouent ou ne mènent à aucune action utile.
Ce sont ces mesures qui permettent de trancher : est-ce un investissement, ou le symptôme d'un système mal réglé.
Pourquoi le montant ne se transpose pas à une entreprise française
Si une entreprise évalue un agent pour le support client, la documentation interne ou le traitement de dossiers administratifs, elle ne peut pas prendre ces 10 millions comme repère. Le contexte rapporté concerne un créateur disposant, d'après les échanges sur scène, de moyens très élevés en jetons. Ça ne décrit pas un déploiement standard, ni une recommandation d'achat.
Même avec une référence plus « proche du réel », il faut rester prudent. The Register mentionne qu'Accenture plafonne à 29 dollars par mois les dépenses de ses employés sur Claude. C'est une approche de maîtrise des coûts, mais ce plafond ne devient pas un prix universel : les usages autorisés et les conditions commerciales varient.
Pour une équipe française, la bonne démarche est pragmatique : définir un cas d'usage précis, puis mesurer la consommation sur un échantillon représentatif. Et surtout : inclure les tests et la supervision, pas uniquement le coût des requêtes « réussies ». Une expérimentation limitée, avec un budget plafonné et des critères de sortie clairs, donne une base de décision bien plus solide qu'un chiffre spectaculaire vu ailleurs.
Pourquoi les agents font grimper la consommation
Un chatbot répond généralement à une demande, même si la conversation comporte des échanges. Un agent, lui, peut découper une tâche, appeler des outils, produire une première version, la vérifier, puis recommencer. À chaque étape, il peut solliciter un modèle. Et comme l'objectif affiché est l'autonomie, le nombre d'appels grimpe vite si le périmètre n'est pas cadré.
Résultat : le coût d'un agent est moins prévisible que celui d'une fonctionnalité classique. Une recherche dans une base de données a souvent un coût stable. À l'inverse, une demande du type « prépare une analyse et vérifie les informations » peut déclencher un nombre d'étapes variable, selon la qualité des données, les instructions, et la manière dont le modèle gère la tâche.
Le coût se construit dans la boucle de travail
Une tâche « autonome » n'est pas forcément une seule requête. Elle peut ressembler à une séquence comme celle-ci :
- interpréter la demande et la transformer en étapes ;
- chercher des informations dans des fichiers ou des services ;
- demander au modèle de produire un résultat ;
- vérifier ce résultat avec un autre appel (ou un autre agent) ;
- corriger, reformater, ou demander une validation humaine.
Le coût dépend donc bien plus que du modèle choisi. Il dépend aussi de la longueur du contexte renvoyé à chaque étape, du nombre de reprises, et du niveau de vérification. Si l'agent renvoie tout l'historique à chaque appel, les mêmes informations peuvent être facturées plusieurs fois. Si le système continue sans limite claire, un problème mineur peut déclencher une boucle coûteuse.
C'est pour ça que l'optimisation ne consiste pas à choisir le modèle le moins cher. Un modèle moins performant peut exiger plus d'essais et finir par coûter plus cher. À l'inverse, un modèle plus coûteux peut rentabiliser son prix s'il termine plus vite et réduit les corrections. Le bon critère, c'est le coût par résultat fiable, pas le tarif affiché au jeton.
DĂ©finir des limites avant de passer Ă l'Ă©chelle
Avant de laisser un agent tourner longtemps, il faut décider ce qu'il peut consommer et à quel moment il doit s'arrêter. Les garde-fous simples sont souvent les plus utiles : plafonner le nombre d'étapes, limiter la taille du contexte, fixer un budget par tâche, et prévoir une revue humaine au-delà d'un seuil.
Il faut aussi séparer les environnements. Les essais de développement, les tests de qualité et le service rendu aux clients ne devraient pas être mélangés dans un seul indicateur. Sinon, on ne saura pas si la dépense améliore le produit... ou si elle sert juste à le faire fonctionner.
Dans un suivi opérationnel, on peut distinguer :
- le coût de développement, lié aux essais et aux comparaisons de modèles ;
- le coût d'exécution, pour les tâches traitées en production ;
- le coût de contrôle, qui inclut les validations et les reprises humaines ;
- le coût d'échec, quand l'agent consomme des ressources sans livrer un résultat exploitable.
Cette séparation évite un piège classique : montrer une démo réussie sans compter les tentatives nécessaires pour y arriver. Une démonstration peut être impressionnante et pourtant économiquement difficile à reproduire à grande échelle.
Le cloud simplifie le déploiement, pas les arbitrages
Lors de la discussion avec Dane Knecht, directeur technique de Cloudflare, Steinberger a soulevé une question concrète : pourquoi l'agent continue-t-il d'utiliser l'ordinateur de l'utilisateur, alors qu'il pourrait fonctionner dans le cloud ? L'idée est simple : un agent hébergé à distance peut continuer à travailler sans dépendre d'une machine personnelle allumée, et être accessible depuis plusieurs appareils.
Mais déplacer l'exécution dans le cloud ne supprime pas les contraintes. Il faut toujours gérer les coûts de calcul, les appels aux modèles, les secrets d'accès, les journaux, la disponibilité et la séparation des données. Le cloud aide à industrialiser certaines opérations ; il ne transforme pas automatiquement une tâche mal définie en service rentable.
Agent local ou agent hébergé : un choix de contraintes
L'exécution locale est intéressante quand la confidentialité, le contrôle des données ou l'accès direct à des fichiers sur le poste priment. Elle peut aussi convenir à des tâches ponctuelles, si l'utilisateur accepte que son ordinateur reste impliqué. En contrepartie, les performances dépendent du matériel, de la configuration et du fait que la machine soit disponible.
L'hébergement cloud facilite les traitements continus et l'accès à des ressources partagées. Il simplifie aussi parfois le déploiement des mises à jour. Mais il ajoute des dépendances : des coûts récurrents, un contrôle d'accès à cadrer, des questions de résidence des données, et la gestion des incidents. En contexte RGPD, il faut aussi préciser quelles données sont envoyées, vers quels services, pour quelles finalités, et avec quelles garanties contractuelles.
Le matériel local suit aussi la tendance. Le contenu source mentionne les nouveaux ordinateurs portables RTX Spark de Nvidia, pensés pour exécuter des agents localement. Ce n'est pas une preuve que l'exécution locale conviendra à tous les projets. Le matériel peut réduire certaines dépendances, mais il faut comparer son prix, sa maintenance et ses limites de capacité avec les coûts d'une solution hébergée.
Choisir Ă partir du cas d'usage
La décision doit partir de la tâche, pas de la plateforme. Posez-vous trois questions : l'agent doit-il tourner en continu ? Accède-t-il à des données sensibles sur le poste ? Le coût d'une interruption ou d'une indisponibilité est-il acceptable ?
Si l'agent automatise une action interne pas trop critique, une configuration simple et supervisée peut suffire. S'il doit traiter des demandes en continu ou s'intégrer à plusieurs services, une architecture cloud peut mieux convenir, à condition de mesurer le coût par tâche et de mettre des contrôles. Et si des données sensibles sont concernées, l'analyse sécurité et conformité doit précéder le choix du fournisseur.
Il n'y a pas de réponse universelle « local contre cloud ». Une solution techniquement élégante peut être un problème en pratique si l'équipe n'est pas en mesure de la maintenir. Et un agent local n'est pas automatiquement plus sûr : les permissions accordées, le risque de poste compromis, et l'accès aux données restent des menaces bien réelles.
Sécurité et code ouvert : déléguer sans perdre le contrôle
La question des permissions est au centre des agents autonomes. À la conférence, Knecht a demandé comment décider quelles données donner à un agent. Steinberger a répondu que ça dépend en partie du modèle, et a expliqué qu'il ne donnerait pas toutes les permissions à un agent, même si des risques comme l'injection de prompt sont réduits.
Sa proposition : ajouter un autre agent chargé d'accorder (ou de refuser) les autorisations. Le premier agent « négocie » alors avec ce système de contrôle. D'après Steinberger, les agents finissent souvent par renoncer à une action ou trouver une alternative plus simple dans les limites fixées. Ce mécanisme peut renforcer la confiance, mais il ne faut pas le prendre pour une garantie de sécurité.
SĂ©parer l'action et l'autorisation
Le principe est logique : l'agent qui exécute une tâche ne devrait pas être le seul juge de ses propres permissions. Un contrôle séparé peut réduire les risques d'une instruction malveillante, d'une mauvaise interprétation, ou d'une action trop large.
En production, ce contrôle doit reposer sur des règles vérifiables, pas uniquement sur une discussion entre deux modèles. Par exemple :
- autoriser seulement les outils nécessaires à la tâche ;
- limiter les actions irréversibles ou exiger une confirmation ;
- appliquer des permissions différentes selon l'utilisateur et le contexte ;
- journaliser les décisions importantes et les appels aux outils ;
- prévoir un arrêt immédiat et une procédure de révocation des accès.
Cette séparation est importante. Un « deuxième agent » peut aider à interpréter une demande, mais il peut aussi partager certaines limites du premier, surtout s'il repose sur des modèles et des données similaires. Les contrôles techniques - droits minimaux, validation humaine, limites d'action - restent indispensables.
Pour une entreprise européenne, la sécurité ne se résume pas à empêcher une fuite de données. Il faut aussi savoir qui est responsable d'une action, garder les traces nécessaires, et vérifier que le traitement respecte les obligations applicables. Plus l'agent agit seul, plus la gouvernance doit être claire.
Rendre le raisonnement inspectable pour le code ouvert
Steinberger a aussi évoqué la réaction de mainteneurs de logiciels libres qui refusent désormais du code écrit par l'IA. Il estime que le processus doit évoluer : les contributeurs expliquent rarement comment ils sont arrivés à leur proposition. À ses yeux, voir le chemin entre le problème et le résultat augmente la confiance.
L'idée est utile, mais il faut garder une distinction : transparence n'est pas preuve de qualité. Une explication détaillée peut aider un mainteneur à examiner une modification, sans garantir que le code est correct, sûr ou conforme au projet. Un raisonnement peut convaincre tout en reposant sur une hypothèse fausse.
Le contrôle devrait donc porter sur des éléments vérifiables : les changements proposés, les tests qui passent, les cas limites, les dépendances ajoutées, et la justification fonctionnelle. Une contribution générée avec l'aide d'un modèle devient plus facile à évaluer si l'auteur indique ce qui a été produit, vérifié et corrigé manuellement.
La règle pratique rejoint celle des agents en production : déléguer ne supprime pas la responsabilité. Qu'il s'agisse d'un accès à un service ou d'une modification de code, l'humain doit comprendre le périmètre de l'action et pouvoir évaluer les conséquences importantes.
Conclusion : mesurer la valeur avant d'augmenter le budget
Les quelque 10 millions de dollars évoqués par Peter Steinberger ne servent pas de budget à copier. Ils pointent un problème plus intéressant à regarder : les agents peuvent consommer beaucoup de ressources sans que chaque appel améliore réellement le résultat. Le coût dépend du nombre d'étapes, des reprises, des contrôles, et de la valeur obtenue.
Pour évaluer un projet, commencez par une tâche limitée, fixez un budget, puis mesurez le coût par résultat fiable. Ensuite seulement, ajoutez les contraintes d'infrastructure, de sécurité et de conformité. Si l'agent apporte un gain mesurable et reste contrôlable, vous pouvez élargir le périmètre. Sinon, plus de jetons ne corrigera pas un problème de conception.
Pour approfondir le contexte, consultez le compte rendu de The Next Web sur les propos de Peter Steinberger.