Avant d'être Field CTO chez DoiT, j'étais praticien FinOps. J'ai rédigé des politiques de tagging. J'ai traqué les ressources non taguées la semaine précédant une revue budgétaire. J'ai bâti des modèles de refacturation techniquement défendables qui déclenchaient malgré tout une bataille à chaque réunion, parce que le cluster partagé de l'un ne se découpait jamais comme son P&L.
Alors quand nous avons lancé Attribute™ cette semaine, j'ai bien compris pourquoi la conversation démarre par les tokens : input, output, cached, reasoning. Coût par requête, par client, par fonctionnalité, par agent. Ce cadrage est juste. Je le trouve simplement incomplet.
Compter les tokens est facile. La vraie question, c'est pourquoi ils ont été générés. Un client a-t-il adopté une nouvelle fonctionnalité IA ? Un workflow interne est-il discrètement passé à un modèle plus coûteux ? Un prompt consomme-t-il dix fois plus de tokens que nécessaire ? Un agent a-t-il déclenché des centaines de tâches en aval que personne n'a demandées ? Dans un rapport de coûts, ces quatre scénarios se ressemblent à s'y méprendre. Pour l'entreprise, ils n'ont pourtant rien à voir.
Le tagging n'a jamais été le but
Voici ce que les praticiens savent, mais qu'on formule rarement à voix haute : personne n'a jamais voulu de tags. Ce que nous voulions, c'était de la responsabilisation — que les bonnes personnes voient les bonnes informations de coût à temps pour agir. Le tagging n'était que la meilleure façon d'y parvenir compte tenu de l'architecture de l'époque. Quand une VM servait une seule application et qu'un compte correspondait à une équipe, propriété, consommation et responsabilité s'alignaient naturellement. Le tagging fonctionnait parce que l'architecture s'y prêtait.
Puis l'architecture a changé. Kubernetes a rendu l'infrastructure partagée. Le serverless l'a rendue abstraite. Les services managés ont déplacé la dépense vers des requêtes, des queries et des invocations. Vadim a expliqué pourquoi l'instrumentation ne tient plus et Josh a détaillé là où le tagging échoue, je ne vais donc pas refaire l'argumentaire ici. En résumé : ce qui est facturé et ce qui crée la demande se sont éloignés, et l'IA les a définitivement séparés. Un seul compte modèle ou une seule gateway peut agréger les requêtes de l'ensemble de vos produits, équipes, agents et employés. Au moment où la facture arrive, le contexte qui l'explique s'est déjà volatilisé.
Le même chiffre, quatre décisions différentes
C'est la partie qui me tient le plus à cœur, parce que c'est là que se joue la différence entre reporting et prise de décision.
Admettons que votre dépense IA ait bondi de 40 % le mois dernier. Fort de mes années sur le terrain, je peux vous dire ce que ce chiffre justifie à lui seul : rien. La suite dépend entièrement du pourquoi.
Si la hausse vient d'une fonctionnalité client qui alimente l'adoption et la rétention, vous investissez davantage. Ce n'est pas un problème de coût. C'est un signal de croissance déguisé en problème de coût.
Si elle vient d'un workflow interne qui utilise un modèle premium pour une tâche qu'un modèle plus léger traiterait très bien, vous optimisez. C'est un chantier d'ingénierie au retour mesurable.
Si elle vient d'un agent qui déclenche inutilement des appels en aval, vous encadrez : rate limits, budgets, contrôles.
Et si elle vient d'un client grand compte qui pèse de façon disproportionnée sur votre coût d'inférence, ce n'est même plus un sujet FinOps. C'est un sujet de pricing, de packaging et de marge — une discussion pour votre CFO et votre équipe produit.
Quatre causes. Quatre responsables. Quatre actions totalement différentes. Le chiffre de coût ne vous dit pas quelle réunion planifier. Le contexte, si.
Voilà ce que Attribute™ change réellement. Parce qu'il mesure la consommation réelle au niveau du kernel et la relie à la facturation du fournisseur, le pourquoi arrive avec le chiffre : ce client, cette fonctionnalité, cet agent, ce workflow. Non pas parce que compter les tokens serait l'objectif, mais parce que c'est l'attribution qui transforme un chiffre en décision.
Ce qui change pour la pratique
Dans notre enquête menée auprès de 500 responsables financiers, 79 % avaient déjà connu des dépassements de coûts IA, et seuls 15 % parvenaient à calculer le ROI de l'IA sans blocages significatifs. Je n'y vois pas un problème de discipline. Ces équipes ne ratent pas leur FinOps. Elles appliquent l'ancienne méthode à une architecture qui la met en échec.
Ce qui vient ensuite, à mon sens, et ce que je dis aux clients sur le terrain : le FinOps cesse d'être une fonction de reporting qui reconstitue le contexte après coup pour s'intégrer là où les décisions se prennent. Les Engineers voient les implications de coût au moment de concevoir, pas trente jours plus tard. Les équipes produit connaissent l'économie unitaire d'une fonctionnalité avant la discussion sur le pricing, pas après. La finance relie la dépense IA à la marge par client au lieu de contempler une ligne indivisible. Les équipes plateforme IA voient non seulement quels modèles ont tourné, mais quels cas d'usage ont créé de la valeur et lesquels ont créé du gaspillage.
Rien de tout cela ne fonctionne sans attribution. C'est la couche sur laquelle repose tout le reste du FinOps, et pour les workloads IA, c'est précisément celle qui nous manquait.
J'ai passé des années de ma carrière à reconstituer le contexte une fois la facture arrivée. La prochaine ère du FinOps, c'est de disposer de ce contexte avant que l'argent ne soit dépensé. Voilà ce que ce lancement représente pour moi.
Quinze minutes pour l'installation. Aucune instrumentation requise. L'économie des tokens dès la fin de journée. Réservez une démo pour voir Attribute™ dans votre propre environnement.