Si la FinOps Foundation a lancé la Tokenomics Foundation, ce n'est pas parce que la gestion des coûts de l'IA était un problème résolu auquel il ne manquait qu'un nom. Comme JR Storment l'a écrit, l'économie des tokens est la discipline qui permet de mesurer, d'attribuer et de relier la consommation IA aux résultats business — et la plupart des entreprises n'ont toujours aucun moyen fiable de le faire. On ne bâtit pas une nouvelle discipline autour d'un problème déjà maîtrisé.
Le réflexe naturel est de s'y attaquer comme les équipes ont toujours traité les problèmes de coûts cloud : taguer les ressources, encapsuler les appels dans un SDK, imposer des conventions de nommage. Cette méthode a fonctionné pour l'infrastructure traditionnelle. Elle ne fonctionne pas pour l'infrastructure IA, et les raisons sont architecturales, pas procédurales.
Une nouvelle catégorie d'approche, la mesure au niveau du kernel via eBPF, contourne totalement le problème d'instrumentation en observant la consommation directement au niveau du système d'exploitation, sans tags, sans SDK et sans modification de code. C'est ce que recouvre l'expression tokenomics sans tags, SDK ni modifications de code. Voici pourquoi l'approche par instrumentation atteint ses limites, et comment l'attribution au niveau du kernel fonctionne différemment.
Qu'est-ce que l'attribution des coûts IA (et pourquoi est-elle défaillante aujourd'hui) ?
L'attribution des coûts IA consiste à retracer les dépenses IA — cycles GPU, appels d'API de modèles, consommation de tokens — jusqu'au client, à la fonctionnalité, à l'équipe ou à l'agent qui en est à l'origine. C'est l'équivalent, à l'ère de l'IA, de l'allocation des coûts cloud, avec une différence de taille : l'infrastructure à mesurer ne reste pas immobile assez longtemps pour que les méthodes traditionnelles puissent la saisir.
L'allocation traditionnelle des coûts repose sur l'instrumentation. Taguez une ressource, et vous savez à qui elle appartient. Encapsulez un appel d'API dans un SDK, et vous savez quelle équipe l'a émis. Cette approche est imparfaite même dans les environnements cloud classiques — la couverture des tags est un chantier permanent —, mais elle suffit, car l'infrastructure sous-jacente est relativement statique et la propriété relativement claire.
L'infrastructure IA fait voler en éclats chacune de ces hypothèses.
Un même compte d'API de modèle managé sert des dizaines d'équipes en même temps. Un cluster GPU partagé exécute simultanément les workloads de plusieurs produits, sans aucune frontière au niveau des ressources. Une passerelle LLM agrège les requêtes provenant d'agents, de pipelines et d'utilisateurs humains en un unique flux sortant, en effaçant au passage l'identité de l'appelant. Un workload agentique peut engendrer des sous-agents qui déclenchent des coûts en aval — compute, mémoire, réseau — sans aucun lien traçable vers la ligne de facturation d'origine.
Aucun tag ne survit à un passage par un proxy LLM. Aucun SDK ne peut envelopper un GPU partagé. Et là même où l'instrumentation pourrait théoriquement fonctionner, les workloads IA évoluent plus vite qu'on ne peut la déployer : un agent peut engendrer un millier de sous-agents en une nuit, et la facture tombe bien avant que quiconque n'ait mis à jour le code de tracking.
Le déficit d'attribution des dépenses IA n'est pas un problème de processus. C'est une conséquence structurelle du fonctionnement même de l'infrastructure IA.
Pourquoi les approches traditionnelles atteignent un plafond
Les outils conçus pour résoudre ce problème se rangent généralement dans l'une de trois catégories.
Les outils au niveau de la facturation opèrent a posteriori, en réconciliant les factures des fournisseurs pour produire des rapports. Ils indiquent ce qui a été dépensé, de manière agrégée, bien après que le workload à l'origine du coût a fini de s'exécuter.
Les outils basés sur des agents Kubernetes instrumentent la couche d'orchestration, en suivant l'usage des ressources au niveau des pods et des conteneurs. Ils fonctionnent tant que le workload reste dans Kubernetes et à l'intérieur d'un même cluster. Ils perdent toute visibilité dès qu'une requête traverse une API managée, un GPU partagé ou une passerelle LLM.
Les outils d'inférence par métadonnées cherchent à se passer entièrement du tagging manuel en déduisant la propriété à partir des métadonnées disponibles et en proposant automatiquement des tags virtuels. C'est un vrai progrès par rapport au tagging manuel, mais ils se heurtent au même plafond : ils ne peuvent attribuer que ce que les métadonnées décrivent — et à la couche où se produit réellement la consommation IA, ces métadonnées n'existent pas.
Ces trois approches reconstruisent l'attribution après coup, à partir de signaux situés au-dessus de la couche où la consommation a véritablement lieu. Aucune ne voit à l'intérieur d'un GPU partagé. Aucune ne peut suivre un token à travers une passerelle jusqu'à l'agent qui l'a déclenché.
Les plateformes qui le peuvent sont celles qui mesurent sous ces trois couches, et non à leurs côtés : au niveau du kernel, où la consommation est observée directement, sans inférence.
Comment fonctionne l'attribution au niveau du kernel
Une approche au niveau du kernel repose sur un capteur eBPF déployé directement dans le système d'exploitation. Le déploiement prend généralement quelques minutes : aucune modification de code, aucun manifeste Kubernetes à éditer, aucun SDK à intégrer.
Une fois en fonctionnement, le capteur observe la consommation réelle en temps réel : chaque token, chaque requête de modèle, chaque cycle GPU, et rattache chaque unité au processus, au conteneur, au pod et à la requête responsables. Ces données runtime peuvent ensuite être rapprochées de la facturation des fournisseurs comme Anthropic, OpenAI, Google Gemini ou AWS Bedrock, en distinguant automatiquement les tokens mis en cache, les tokens de raisonnement, les tokens d'entrée et les tokens de sortie.
Résultat : une économie des tokens par client, par fonctionnalité et par agent, produite en continu, sans instrumentation, sans tagging ni modification de code. Comme le capteur opère au niveau du kernel, il voit la consommation directement. Rien à inférer, et rien derrière quoi un agent, une passerelle ou un GPU partagé pourrait se dissimuler.
Ce que l'attribution au niveau du kernel change pour chaque équipe
Pour les VP Engineering, l'attribution au niveau du kernel, c'est un chargeback défendable. Les coûts GPU sont rattachés au workload qui les a générés, ce qui met fin aux litiges de facturation entre équipes partageant une même infrastructure.
Pour les praticiens FinOps, c'est la fin du tableur orphelin. Les tags se dégradent. Les conventions de tagging deviennent obsolètes dès qu'un nouveau service est livré. La mesure au niveau du kernel, elle, ne dépend de la mémoire de personne.
Pour les CFO et les directions financières, cela apporte une visibilité sur le ROI reliée à des fonctionnalités et des segments clients précis, et non à des estimations agrégées au niveau du compte. Savoir qu'une fonctionnalité augmente la probabilité de renouvellement n'a rien à voir avec le fait de connaître la dépense mensuelle globale d'un compte.
Pourquoi c'est décisif maintenant
Le schéma se répète dans chaque catégorie de coûts cloud antérieure : optimisation du compute, gestion des commitments, allocation des coûts Kubernetes. Les organisations qui posent tôt les bonnes fondations de mesure prennent ensuite de meilleures décisions à chaque étape. Celles qui repoussent l'attribution jusqu'à ce que les factures aient déjà explosé passent des années à reconstruire un contexte qu'elles auraient pu avoir dès le premier jour.
Les dépenses IA progressent plus vite que dans toute catégorie précédente, et les données le confirment. Une étude Sapio Research menée auprès de 500 responsables financiers montre que 79 % des entreprises ont déjà subi des dépassements de coûts IA, et que seulement 15 % parviennent à calculer le ROI de l'IA sans obstacles majeurs. La fenêtre pour poser les bonnes fondations, c'est maintenant — pas après la prochaine facture surprise.
L'approche de DoiT
DoiT gère plus de 8 milliards de dollars de dépenses cloud pour 4 500 clients dans 27 pays, et a vu ce schéma de mesure se répéter dans chaque grande catégorie de coûts cloud. Attribute™ by DoiT met en œuvre l'approche au niveau du kernel décrite plus haut : un capteur eBPF qui se déploie en une quinzaine de minutes, sans tags, sans SDK et sans modification de code, produisant une économie des tokens par client, par fonctionnalité et par agent dès le jour de son installation.
DoiT est également partenaire marketing de la Tokenomics Foundation, aux côtés de JR Storment et de la FinOps Foundation, pour contribuer à définir des standards ouverts pour l'économie des tokens IA à mesure que cette catégorie se structure.
Réservez une démo pour voir Attribute™ à l'œuvre dans votre propre environnement.