Le FinOps a donné aux équipes une véritable méthode pour maîtriser les coûts cloud : taguer ses ressources, suivre les unit economics, bâtir des modèles de refacturation qui responsabilisent engineering et finance sur les mêmes chiffres. Ça fonctionne. La plupart des organisations cloud matures s'appuient aujourd'hui sur une variante de cette approche.
L'infrastructure d'IA fait voler cette méthode en éclats, et la plupart des équipes n'ont pas encore pris la mesure du phénomène.
Ce que recouvre le FinOps pour l'IA aujourd'hui
Le FinOps pour l'IA prolonge naturellement la discipline de gestion financière du cloud vers les workloads de machine learning et d'IA générative. L'objectif reste le même que pour le FinOps traditionnel : rattacher chaque dépense à l'équipe, au produit ou au client qui la génère, afin que finance et engineering décident à partir des mêmes chiffres. Ce qui change, c'est l'infrastructure sous-jacente. Comprendre les mécaniques réelles du traitement d'une requête par un LLM est un bon point de départ si cette infrastructure ne vous est pas familière.
En pratique, le FinOps pour l'IA couvre généralement quelques capacités clés, chacune empruntée au FinOps traditionnel et adaptée à un nouveau type de workload.
Allocation des coûts. Taguer les instances GPU comme on taguerait une VM. Rattacher les clés d'API, les modèles et les projets à des équipes, produits ou clients. Bâtir la même carte de propriété pour un cluster d'entraînement que pour un namespace Kubernetes.
Showback et chargeback. Produire des rapports qui indiquent à une équipe le coût d'un run d'entraînement, ou la dépense d'inférence d'une fonctionnalité sur le mois écoulé — comme le showback le fait depuis des années pour le compute et le stockage.
Unit economics. Traduire la dépense brute en une métrique actionnable pour le business : coût par inférence, coût par utilisateur actif, coût par fonctionnalité — la même logique qui existe de longue date pour le coût par transaction ou par requête.
Budgets, alertes et détection d'anomalies. Poser des seuils par équipe ou par modèle, et recevoir une alerte en cas de pic inattendu de consommation de tokens ou de longueur de prompt, à l'image des outils devenus standard en cloud cost management.
Gouvernance et application des politiques. Définir qui peut lancer quoi, avec quel modèle et sous quel plafond de coût — l'équivalent IA des quotas de ressources et des politiques de tagging.
Pour une part significative des workloads d'IA, cette approche fonctionne encore très bien. Un cluster d'entraînement dédié avec un propriétaire clair. Un endpoint d'inférence mono-tenant qui sert un seul produit. Un modèle au pattern d'appel prévisible et traçable. On tague, on suit, l'affaire est réglée.
Là où la méthode tient, et là où elle craque
Les ennuis commencent avec les workloads qui ne rentrent pas dans ce cadre — et c'est désormais la majorité.
L'infrastructure partagée casse le modèle de propriété
Un compte API de modèle managé sert couramment des dizaines d'équipes depuis une seule ligne de facturation. Aucune frontière par équipe n'apparaît dans la facture elle-même, seulement ce qu'on parvient à reconstituer après coup à partir de métadonnées plus ou moins fiables. Un cluster GPU partagé exécute l'inférence de plusieurs produits en parallèle, avec des cycles de calcul entrelacés à un niveau qu'aucun tag ne peut atteindre.
Les gateways effacent le signal dont dépend le tagging
Un gateway LLM agrège les requêtes d'agents, de pipelines automatisés et d'utilisateurs humains en un flux sortant unique, et efface au passage l'identité de l'appelant avant que la requête n'atteigne le fournisseur. Au moment où la requête arrive au modèle, le contexte qui permettrait de la rattacher à une équipe ou à une fonctionnalité a le plus souvent déjà disparu. Les tags appliqués en amont ne survivent pas au saut.
Les workloads agentiques génèrent des coûts qu'aucun SDK n'a instrumentés
Un workload agentique peut engendrer des sous-agents qui déclenchent de véritables coûts d'infrastructure — compute, mémoire, réseau, charge base de données — sans aucun lien avec la ligne de facturation IA d'origine. Aucun tag ni convention de nommage ne les relie à la requête qui a lancé la chaîne, tout simplement parce que cette chaîne n'était pas anticipée quand l'instrumentation a été mise en place.
L'instrumentation ne peut pas suivre le rythme de l'infrastructure IA
Le problème de couverture n'est que la moitié de l'histoire. Les workloads d'IA évoluent à un rythme que l'instrumentation ne peut pas tenir. Un agent peut engendrer un millier de sous-agents en une nuit. Le temps que l'engineering identifie le nouveau pattern d'appel, l'enveloppe dans un SDK et livre la mise à jour, la facture est déjà tombée. Ce n'est pas un problème de discipline de tagging qu'une meilleure gouvernance ou des conventions de nommage plus strictes résoudront. C'est une réalité architecturale du fonctionnement réel de l'infrastructure IA, et elle s'applique quelle que soit la rigueur de la pratique FinOps en place.
Le problème des dépenses orphelines
Parlez à n'importe quel praticien FinOps six mois après le lancement d'un programme de coûts IA et vous entendrez une variante de la même histoire : une ligne de dépense qui a grimpé de 40 % d'un mois sur l'autre, sans propriétaire identifiable. Les tags pointent vers un compte de service partagé entre trois équipes. La convention de nommage qui fonctionnait pour les VM n'a jamais été appliquée aux endpoints d'inférence. Quelqu'un a monté un tableur pour reconstituer la propriété à la main, et il est déjà obsolète avant même d'être terminé.
Cette dépense n'est pas sans propriétaire. Elle n'est pas attribuée, parce que la méthode utilisée pour la retrouver a été conçue pour une infrastructure qui ne bouge pas, ne partage rien et ne génère pas ses propres enfants à l'exécution. L'infrastructure IA fait les trois à la fois.
FinOps pour l'IA face au FinOps cloud traditionnel
| FinOps cloud traditionnel | FinOps pour l'IA | |
|---|---|---|
| Méthode d'attribution principale | Tags, conventions de nommage, structure de comptes | Les tags fonctionnent jusqu'à l'entrée en jeu d'une infrastructure partagée ou d'un gateway |
| Stabilité de l'infrastructure | Relativement statique ; propriété généralement claire | Très dynamique ; la propriété peut basculer en cours de requête |
| Angles morts | Essentiellement une question de discipline de tagging | Architectural : certains workloads ne peuvent tout simplement pas être tagués |
| Rythme de changement | Cycles prévisibles et gouvernés | Peut basculer du jour au lendemain, plus vite que l'instrumentation ne peut être mise à jour |
| Où ça casse | Cas particuliers, ressources legacy | Clusters GPU partagés, gateways LLM, workloads agentiques et multi-agents |
La suite : mesurer sous la couche du tag
Si l'architecture des workloads d'IA met l'instrumentation en échec par conception, alors l'instrumentation est la mauvaise couche pour mesurer. L'alternative : mesurer depuis un endroit que l'instrumentation ne peut ni contourner, ni effacer, ni distancer — le kernel.
C'est l'architecture qui sous-tend Attribute™ by DoiT. Un capteur eBPF est déployé au sein du système d'exploitation et observe la consommation réelle — chaque token, chaque requête modèle, chaque cycle GPU — au moment où elle se produit, en rattachant chaque unité au processus, au conteneur et à la requête responsables. Pas de tags. Pas de SDK. Aucun changement de code. Ces données sont ensuite croisées avec la facturation des fournisseurs — Anthropic, OpenAI, Google Gemini et AWS Bedrock — en séparant automatiquement les tokens en cache, de raisonnement, d'entrée et de sortie.
C'est la couche à laquelle la Tokenomics devient opérationnelle : une économie au niveau du token, attribuée automatiquement, pour les workloads que le tagging n'allait jamais atteindre. De la Tokenomics sans tags, sans SDK et sans changement de code.
Pourquoi c'est important dès maintenant
Notre étude — un sondage mené par Sapio Research auprès de 500 responsables financiers — révèle que 79 % des entreprises ont déjà connu des dépassements de coûts IA, et seulement 15 % parviennent à calculer le ROI de l'IA sans obstacles majeurs. Cet écart n'est pas un problème de process que les équipes n'auraient pas encore eu le temps de corriger. C'est un problème de mesure qui exige une couche différente pour être résolu.
DoiT gère plus de 8 milliards de dollars de dépenses cloud pour 4 500 clients dans 27 pays, et nous avons déjà vu ce schéma se répéter dans chaque grande catégorie de coûts — optimisation du compute, gestion des commitments, allocation des coûts Kubernetes. Les équipes qui posent tôt de bonnes fondations de mesure prennent ensuite chaque décision avec plus de justesse. Celles qui attendent passent des années à reconstruire un contexte qu'elles auraient pu avoir dès le premier jour.
Nous travaillons avec la Tokenomics Foundation, aux côtés de JR Storment et de la FinOps Foundation, pour aider à définir à quoi ces fondations doivent ressembler pour l'industrie.
FAQ
Qu'est-ce que le FinOps pour l'IA ?
Le FinOps pour l'IA, c'est l'application des pratiques de gestion financière du cloud — allocation des coûts, showback et chargeback, unit economics, budgets et détection d'anomalies — aux workloads de machine learning et d'IA générative. Il étend à une nouvelle catégorie de dépenses la discipline qui a fait ses preuves sur l'infrastructure cloud traditionnelle.
Pourquoi le tagging ne fonctionne-t-il pas pour l'attribution des coûts IA ?
Le tagging repose sur une relation stable et traçable entre une ressource et son propriétaire. Les clusters GPU partagés, les gateways LLM et les workloads agentiques rompent cette relation par conception : les gateways effacent l'identité de l'appelant, l'infrastructure partagée n'a pas de frontière de propriété nette, et les chaînes agentiques génèrent des coûts sur lesquels aucun tag n'a jamais été apposé.
Quelle est la différence entre FinOps pour l'IA et Tokenomics ?
Le FinOps pour l'IA désigne la pratique consistant à appliquer une discipline de gestion des coûts aux workloads d'IA. La Tokenomics est la discipline de mesure sous-jacente : comprendre ce que vaut chaque token, qui l'a consommé et si la dépense se justifie par le résultat obtenu — que le workload puisse être tagué ou non.
Peut-on faire du FinOps pour l'IA sans instrumentation ?
Oui. La mesure au niveau du kernel, via des technologies comme eBPF, observe la consommation au niveau du système d'exploitation plutôt que de dépendre de tags ou de SDK. Elle permet d'attribuer des workloads que l'instrumentation traditionnelle ne peut pas atteindre, notamment les clusters GPU partagés et le trafic routé par un gateway.
À qui revient le FinOps pour l'IA au sein d'une organisation ?
Cela varie selon les entreprises, mais le FinOps pour l'IA se situe généralement à l'intersection de l'équipe FinOps ou cloud cost existante, du platform ou infrastructure engineering, et — de plus en plus — des équipes qui construisent directement les produits d'IA. Comme la dépense IA évolue plus vite et touche davantage d'équipes que la dépense cloud traditionnelle, la pratique exige une collaboration plus étroite entre finance et engineering que le FinOps legacy, aucun des deux camps n'ayant à lui seul une visibilité complète.
En quoi l'allocation des coûts IA diffère-t-elle de l'allocation des coûts cloud ?
L'allocation des coûts cloud rattache généralement une dépense à une ressource dont le propriétaire est relativement stable : une instance, un bucket, un namespace. L'allocation des coûts IA doit gérer une consommation qui franchit les frontières de propriété au sein d'une même requête — un GPU partagé qui sert plusieurs produits, un gateway qui route le trafic de plusieurs équipes, un agent qui génère des coûts dans des services qu'il n'a jamais touchés directement. L'objectif de fond est le même. Les mécaniques pour y parvenir ne le sont pas.
Quelles métriques un programme de FinOps pour l'IA doit-il suivre ?
La plupart des programmes suivent une combinaison de coût par token, coût par inférence, coût par fonctionnalité et coût par client ou par compte, aux côtés des répartitions de tokens d'entrée, de sortie, en cache et de raisonnement, qui varient selon les fournisseurs. Le bon dosage dépend du public visé : l'engineering, qui veut généralement du détail au niveau workload, ou la finance, qui préfère des agrégats au niveau compte ou fonctionnalité, rattachés aux données de revenu ou de renouvellement.
Prêt à connaître votre véritable coût de service IA ?
Quinze minutes pour l'installer. Aucune instrumentation requise. Une économie au niveau du token dès la fin de la journée.