Vous voyez votre facture IA. Vous pouvez même l'expliquer en partie. Mais impossible d'attribuer ces dépenses à vos clients, équipes ou utilisateurs. Résultat : vous ne pouvez pas dire si vos produits sont tarifés avec des marges saines. Cet écart - entre ce que vous dépensez et ce que vous pouvez justifier - c'est précisément le problème que résout Attribute™.
L'attribution des coûts cloud n'a jamais été simple, en particulier pour les ressources partagées. Depuis quinze ans, nous aidons plus de 4 000 clients à démêler leur infrastructure partagée, à faire respecter leurs politiques de tagging et à bâtir des modèles de refacturation qui tiennent la route. Le problème a toujours été ardu. L'IA l'a rendu encore plus complexe.
L'infrastructure sur laquelle tourne l'IA a été conçue pour la vitesse et l'échelle, pas pour l'attribution. Les approches d'attribution retenues par l'industrie dans le cloud (les tags) ne se transposent pas. C'est une réalité architecturale - qui appelait une réponse d'un autre ordre.
Le piège de l'instrumentation
La réponse classique à l'attribution des coûts a toujours été l'instrumentation. Taguer ses ressources. Encapsuler ses appels API dans un SDK. Imposer des conventions de nommage. Bâtir un pipeline qui agrège ces signaux dans un dashboard.
Pour l'infrastructure cloud traditionnelle, cette approche fonctionne, sans être parfaite. L'infrastructure partagée sous-jacente est relativement statique. Le modèle de propriété est relativement clair. On peut atteindre un niveau suffisamment bon, moyennant quelques concessions.
L'infrastructure IA fait voler en éclats toutes les hypothèses sur lesquelles cette approche repose.
Un même modèle managé sert plusieurs clients en simultané. Un cluster GPU partagé fait tourner en parallèle des modèles pour plusieurs produits. Une passerelle LLM agrège en un seul flux sortant des requêtes provenant d'agents, de harnesses et d'humains. Sans compter qu'un workload agentique peut engendrer des sous-agents qui déclenchent des coûts d'infrastructure sans lien visible avec la ligne de facture IA qui les a initiés.
On n'encapsule pas un GPU partagé dans un SDK. Aucun tag ne survit au passage par un proxy LLM. Et les workloads IA évoluent à un rythme que l'instrumentation ne peut pas suivre. Un agent peut engendrer un millier de sous-agents en une nuit. Le temps d'encapsuler les nouveaux schémas d'appel dans un SDK et de déployer la mise à jour, la facture est déjà tombée.
L'écart d'attribution dans les dépenses IA n'est pas un problème de processus que l'on résout à coups d'instrumentation. C'est une réalité architecturale du fonctionnement même de l'infrastructure IA.
" L'écart d'attribution dans les dépenses IA n'est pas un problème de processus que l'on résout à coups d'instrumentation. C'est une réalité architecturale du fonctionnement même de l'infrastructure IA. "
C'est ce constat qui nous a menés à Attribute™. Si l'architecture des workloads IA fait échouer l'instrumentation par construction, alors l'instrumentation n'est pas la bonne réponse. Il faut mesurer depuis une couche qui voit tout - avant toute abstraction, avant tout proxy, avant toute frontière de propriété. Il faut mesurer au niveau du noyau du système d'exploitation.
Une approche différente
Attribute™ déploie un capteur eBPF qui opère à l'intérieur du système d'exploitation. Il observe la consommation réelle - chaque token, chaque requête modèle, chaque cycle GPU - en temps réel, et rattache chaque unité au processus, au conteneur, au pod et à la requête responsables. Il croise ensuite ces données avec la facturation des fournisseurs Anthropic, OpenAI, Google Gemini et 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é, par agent — produite en continu, sans instrumentation, sans tagging, sans modification de code.
Les outils qui existent aujourd'hui (et il en existe de corrects) se répartissent en deux camps : 1. ceux qui demandent aux Engineers de définir la logique d'allocation dans le code, et 2. ceux qui recourent à l'inférence sur métadonnées pour proposer automatiquement des tags virtuels.
Les deux constituent de vrais progrès par rapport au tagging manuel. Mais aucun ne voit à l'intérieur d'un GPU partagé. Aucun ne peut suivre un token à travers une passerelle LLM jusqu'au client ou à l'utilisateur qui l'a déclenché. Le blocage ne vient pas de l'outil. Il vient de la méthode.
Toute approche qui s'appuie sur les métadonnées pour reconstituer l'attribution se heurtera au même mur, car ces métadonnées n'existent pas à la couche où la consommation se produit réellement.
La mesure au niveau du noyau n'est pas un détail technique. C'est la seule architecture qui produit une attribution complète sur toute la surface de l'infrastructure IA moderne.
Pourquoi la Tokenomics est le bon cadre
Avec cette nouvelle approche, nous contribuons activement à faire émerger la catégorie de la Tokenomics, et c'est quelque chose de bien précis. Ce n'est pas de la gestion de coûts IA - l'industrie est saturée de ce discours, et l'essentiel n'est que du vocabulaire FinOps cloud recyclé pour une nouvelle ligne de facture.
La Tokenomics, c'est la discipline qui consiste à comprendre ce que chaque token vaut réellement pour votre entreprise : qui l'a consommé, ce qu'il a produit, et si la dépense se justifiait par le résultat obtenu.
Cela exige une attribution au niveau du token. Pas au niveau du compte. Pas au niveau de l'équipe. Au niveau du token. Vous devez pouvoir constater qu'une session client précise a consommé 47 000 tokens sur trois modèles, que 31 000 d'entre eux l'ont été dans une fonctionnalité qui pèse pour 80 % dans la probabilité de renouvellement, et que les 16 000 restants concernaient une fonctionnalité expérimentale pas encore mise en production. Ce sont ces données qui permettent de décider intelligemment où investir et où lever le pied.
On n'obtient pas ces données via le tagging. Ni via des SDK. On ne les obtient qu'en mesurant à la couche où la consommation réelle se produit.
La Linux Foundation a récemment annoncé son intention de lancer la Tokenomics Foundation, en partenariat avec la FinOps Foundation, afin d'établir des standards industriels ouverts pour l'économie des tokens IA. JR Storment, Executive Director de la FinOps Foundation et partenaire proche de DoiT, l'a dit sans détour : nommer le problème, ce n'est pas le résoudre.
C'est exactement cela. La catégorie a désormais un nom et un ancrage institutionnel. Attribute™ est la couche de mesure qui la rend opérationnelle.
Pourquoi DoiT, et pourquoi maintenant ?
DoiT a géré plus de 20 milliards de dollars de dépenses cloud pour 4 500 clients répartis dans 27 pays. Nous avons vu émerger chacune des grandes catégories de coûts cloud : optimisation du compute, gestion des commitments, allocation des coûts Kubernetes. Les équipes 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 explosent passent des années à reconstituer un contexte qu'elles auraient pu avoir dès le premier jour.
Les dépenses IA progressent plus vite que toute catégorie précédente. Notre propre étude - menée auprès de 500 dirigeants finance - a révélé que 79 % des entreprises ont déjà subi des dépassements de coûts liés à l'IA, et que seulement 15 % déclarent pouvoir calculer précisément leur ROI IA sans blocages majeurs. Le moment de se doter des bons outils, c'est maintenant, pas après la prochaine facture-surprise.
Un second signal mérite d'être souligné. À mesure que l'IA passe de l'expérimentation à l'infrastructure de production, les questions changent. On ne demande plus " combien dépensons-nous " - on demande " combien coûte le service de chaque client ", " quelles fonctionnalités IA rognent nos marges " et " quels agents brûlent de la dépense sans rien produire en retour ". Votre conseil d'administration pose ces questions. Votre CFO aussi. Des données de dépense au niveau du compte produisent des réponses au niveau du compte. Une attribution au niveau du noyau - par client, par agent, par fonctionnalité - produit le type de réponses qui font réellement bouger les décisions.
Voilà pourquoi nous avons construit Attribute™. Et voilà pourquoi nous le lançons chez DoiT dès maintenant.
À propos d'Attribute™
Quinze minutes pour l'installer. Aucune instrumentation requise. Une économie des tokens disponible en fin de journée. Pour voir ce qu'Attribute™ donne dans votre propre environnement, réservez une démo ici.