En bref
- La Tokenomics tire son origine des cryptomonnaies, où elle décrit la conception économique d'un token : offre, distribution, incitations, gouvernance. Dans l'IA en entreprise et les opérations cloud, elle prend un tout autre sens.
- En cloud ops, FinOps et gestion des coûts IA, la Tokenomics est la discipline qui mesure, attribue et pilote la consommation de tokens IA à un niveau de granularité qui relie la dépense aux résultats business.
- Pas au niveau du compte. Pas au niveau de l'équipe. Par client, par fonctionnalité, par agent. En continu.
- Les tokens sont l'unité atomique de la consommation IA. Chaque réponse d'un modèle, chaque document traité, chaque action d'un agent en consomme, et ces tokens coûtent de l'argent.
- La plupart des entreprises sont incapables de dire de façon fiable quelles fonctionnalités ont consommé ces tokens, quels clients les ont générés, ni même si la dépense a produit quoi que ce soit qui justifie la facture. La Tokenomics est le cadre qui permet de répondre à ces questions.
Pourquoi ce terme existe
Les tokens sont l'unité atomique de la consommation IA. Chaque fois qu'un modèle génère une réponse, traite un document, déroule une chaîne de raisonnement ou route une requête via une passerelle LLM, il consomme des tokens - et ces tokens coûtent de l'argent. Aujourd'hui, dans la plupart des entreprises, personne n'est en mesure d'indiquer précisément quelles fonctionnalités les ont consommés, quels clients les ont générés, ni si la dépense a produit la moindre valeur à la hauteur de la facture.
C'est ce vide qui explique l'émergence de la catégorie Tokenomics. Comme l'a écrit JR Storment, la token economics est la discipline par laquelle la consommation IA est mesurée, attribuée et reliée aux résultats business. La Linux Foundation l'a officialisée en annonçant la Tokenomics Foundation, en partenariat avec la FinOps Foundation. Non pas parce que la gestion des coûts IA avait besoin d'un nouveau nom, mais parce que les cadres existants n'étaient pas conçus pour ce nouveau défi.
À mesure que la plupart des plateformes IA abandonnent la tarification forfaitaire, le token s'impose comme une nouvelle unité de facturation. L'infrastructure cloud se facture à l'heure de calcul, au gigaoctet, à l'appel d'API. Les tokens, eux, se facturent à l'inférence : le travail cognitif effectué par un modèle pour produire un résultat. Cette différence dans la logique de facturation appelle un modèle d'attribution différent.
Gartner prévoit des dépenses mondiales en IA de 2 590 milliards de dollars en 2026, soit une hausse de 47 % sur un an. Cette croissance accentue la pression sur toutes les équipes chargées de comprendre où va réellement cet argent.
Ce qui rend la dépense IA différente
La gestion traditionnelle des coûts cloud part du principe que l'on gère une infrastructure taguable. Une instance de calcul a un propriétaire. Un bucket de stockage a un nom. Un namespace Kubernetes correspond à une équipe. L'approche par instrumentation (taguer les ressources, encapsuler les appels d'API dans des SDK, imposer des conventions de nommage) fonctionne raisonnablement bien tant que l'infrastructure reste stable et que la propriété reste claire.
L'infrastructure IA fait voler en éclats chacun de ces postulats.
Un seul compte API de modèle managé sert des dizaines d'équipes en simultané. Un cluster GPU partagé exécute des modèles pour plusieurs produits à la fois. Une passerelle LLM agrège les requêtes provenant d'agents, de pipelines automatisés et d'utilisateurs humains en un flux sortant unique, l'identité de l'appelant ayant été effacée avant même que la requête ne quitte le système. Un workload agentique peut engendrer des sous-agents pendant la nuit, déclenchant des coûts d'infrastructure en cascade (charge base de données, mémoire, calcul, réseau) sans lien apparent avec la ligne de facture IA qui les a initiés.
Aucun tag ne survit au passage par un proxy LLM. Aucun SDK n'englobe un GPU partagé. Le déficit d'attribution des dépenses IA n'est pas un problème de process que l'on peut résoudre à coups d'instrumentation. Il reflète une réalité architecturale du fonctionnement de l'infrastructure IA.
C'est cette réalité qui fait de la Tokenomics une discipline à part entière, et non une simple version renommée du FinOps cloud. Les méthodes qui fonctionnent pour le compute et le stockage ne se transposent pas. La couche de mesure doit être différente.
Ce que la Tokenomics mesure réellement
L'attribution au niveau du token suit la consommation selon quatre dimensions essentielles à la prise de décision en entreprise.
Type de token. Chaque type de token a son propre coût. Les tokens d'entrée, de sortie, mis en cache et de raisonnement sont facturés à des tarifs différents chez tous les grands fournisseurs. Un cadre Tokenomics suit chaque type séparément et croise cette ventilation avec le workload qui l'a généré. Un agent qui effectue des recherches répétées sur un contexte mis en cache ne coûte pas la même chose qu'un agent qui génère de nouvelles chaînes de raisonnement à partir de zéro. Cette distinction est essentielle pour comprendre d'où vient la facture.
Fournisseur. Les entreprises qui exploitent l'IA à grande échelle utilisent rarement un seul fournisseur. Anthropic, OpenAI, Google Vertex AI et AWS Bedrock cohabitent souvent dans un même environnement de production, avec différents modèles pour différents cas d'usage. La Tokenomics normalise la consommation entre tous ces fournisseurs dans une couche d'attribution unifiée, ce qui évite aux équipes de rapprocher quatre exports de facturation distincts dans un tableur.
Origine du workload. Quel client a déclenché la requête ? Quelle fonctionnalité produit ? Quel agent ? Quel pipeline ? Ces questions sont au cœur de la Tokenomics, et les outils existants peinent systématiquement à y répondre. Dans la plupart des architectures, l'origine du workload disparaît au niveau du proxy, ce qui explique pourquoi la mesure doit intervenir avant cette frontière, pas après.
Contexte business. Le nombre de tokens ne suffit pas à lui seul. La Tokenomics relie la consommation au résultat : cette fonctionnalité consomme X tokens par session et pèse pour Y % dans la probabilité de renouvellement. Ce pipeline expérimental a consommé Z tokens et n'est toujours pas passé en production. Ce contexte change les décisions.
Ce que la Tokenomics exige
Une véritable Tokenomics exige une mesure à la couche où la consommation se produit réellement : avant toute abstraction, avant tout proxy, avant que la moindre frontière de propriété ne disparaisse. Cela implique d'opérer au niveau du kernel, pas au niveau applicatif.
Les outils qui reposent sur l'inférence de métadonnées ou sur une logique d'allocation définie dans le code se heurtent à un plafond structurel. Ils ne peuvent pas voir à l'intérieur d'un GPU partagé. Ils ne peuvent pas remonter un token à travers une passerelle LLM jusqu'au workload qui l'a généré. Le plafond ne vient pas de l'outil. Il vient de la méthode. Toute approche qui dépend de métadonnées pour reconstituer l'attribution se heurtera au même mur, parce que ces métadonnées n'existent pas à la couche où la consommation se produit.
Bien menée, la Tokenomics apporte :
- Une attribution par entité : quel client, quelle fonctionnalité, quel agent ou quel pipeline a consommé quels tokens, sur chaque modèle et chaque fournisseur
- Une granularité par type de token : tokens mis en cache, tokens de raisonnement, tokens d'entrée et tokens de sortie suivis et ventilés automatiquement
- Une unification des fournisseurs : tous les principaux fournisseurs normalisés dans une seule couche d'attribution
- Un résultat en continu : ni rapport mensuel, ni sprint de tagging. Une token economics disponible en temps réel, sans instrumentation
Ce que cela débloque
L'attribution au niveau du token rend trois choses possibles, jusque-là hors de portée.
Les équipes Engineers défendent leurs chargebacks sans discussion. Lorsqu'un litige surgit sur une facture GPU, la réponse n'est plus une estimation bricolée dans un tableur. C'est une comptabilité précise du workload consommé, vérifiable à la couche où la consommation a eu lieu. Les factures contestées et les rapprochements manuels entre chefs d'équipe cessent d'être la norme.
Les équipes finance calculent le ROI de l'IA fonctionnalité par fonctionnalité. Fini le "nous avons dépensé X dollars en IA ce trimestre" ; place au "cette fonctionnalité précise consomme 31 000 tokens par session et pèse pour 80 % dans la probabilité de renouvellement, quand cette fonctionnalité expérimentale a consommé 16 000 tokens sans être encore passée en production". Ces données étayent les décisions d'investissement au lieu d'imposer des coupes budgétaires réactives.
Les équipes produit prennent leurs décisions build-vs-buy avec de vraies données de coût sous les yeux. L'économie d'une fonctionnalité ne devrait pas se révéler après sa mise en production. L'attribution au niveau du token rend le coût réel de chaque fonctionnalité visible dès le développement, avant qu'il ne se transforme en problème budgétaire.
Les équipes finance gagnent aussi en qualité de données au niveau de l'infrastructure. De plus en plus d'entreprises injectent leurs données de dépense en tokens dans des data lakes et entrepôts centralisés à des fins de reporting et de prévision. Des données de dépense au niveau du compte produisent des réponses au niveau du compte. Une attribution au niveau du kernel (par client, par agent, par fonctionnalité) produit le signal granulaire qui change réellement la façon dont la Finance modélise l'investissement IA à venir.
L'état actuel de la Tokenomics en entreprise
La plupart des entreprises n'ont pas atteint ce niveau de visibilité. Une enquête menée par DoiT et Sapio Research auprès de 500 responsables Finance révèle que 79 % ont connu des dépassements de coûts IA au cours des 12 derniers mois, et que seuls 15 % parviennent à calculer le ROI de l'IA sans obstacles majeurs. 83 % attendent un retour quantifiable dans les 12 mois. La pression s'accélère plus vite que l'outillage.
La catégorie se structure rapidement. La Tokenomics Foundation bénéficie du soutien institutionnel de la Linux Foundation. JR Storment et la FinOps Foundation œuvrent à l'établissement de standards ouverts pour la token economics IA. Ces standards définissent ce à quoi ressemble un bon dispositif. Ils ne répondent pas à la question opérationnelle la plus difficile : comment mesurer au niveau du token dans un environnement de production, sur une infrastructure partagée, sans instrumentation ?
C'est précisément le problème que la Tokenomics, en tant que discipline, cherche à résoudre. Les entreprises qui posent dès maintenant les bonnes fondations de mesure, avant la prochaine facture surprise, prendront chacune de leurs décisions d'investissement IA suivantes avec de meilleures données à l'appui.
Tokenomics et attribution des coûts IA
La Tokenomics et l'attribution des coûts IA répondent à des questions liées mais distinctes. L'attribution des coûts IA remonte la dépense jusqu'au workload, à l'équipe ou au client qui l'a générée. La Tokenomics interroge ce que cette dépense a produit et si le résultat justifiait la facture. L'attribution pose les fondations. La Tokenomics vient s'y ajouter.
Pour aller plus loin sur la manière dont la technologie de capteur eBPF rend possible l'attribution au niveau du kernel, consultez Qu'est-ce qu'un capteur eBPF ?
Attribute™ by DoiT assure une attribution automatisée des coûts IA grâce à un capteur eBPF qui se déploie en une quinzaine de minutes. Sans tags, sans SDK, sans modification de code. Réservez une démo.