Le trimestre dernier, une CFO a posé une question simple à sa responsable financière : quel client fait exploser notre facture OpenAI ? Cette dernière disposait d'une stratégie de tagging, d'un outil FinOps et d'une facture mensuelle d'OpenAI. Elle n'a pourtant pas su répondre. La facture affichait un seul chiffre. Le système de tagging n'avait rien à quoi se raccrocher. Le code applicatif appelait l'API directement et renvoyait une complétion. Pas de centre de coût. Pas d'ID client. Pas de feature flag. Juste des tokens en entrée, des tokens en sortie, et une ligne de facture en fin de mois.
C'est précisément le fossé d'attribution que les dépenses IA ont creusé au sein du FinOps Framework. La capacité d'Allocation a été pensée pour le compute et le stockage, où chaque ressource est associée à un tag, un projet ou un compte. Un appel de tokens, lui, n'a rien de tout cela. L'unité de dépense — une requête API — ne porte pas les métadonnées dont dépend le tagging. Si les équipes FinOps veulent répondre aux questions de coût par client, par fonctionnalité ou par agent, l'attribution doit passer de la couche de facturation à la couche de trafic.
Pourquoi le tagging ne peut-il pas résoudre l'attribution des coûts IA ?
Le tagging échoue face aux dépenses IA parce qu'un appel de tokens n'offre aucun libellé auquel rattacher un tag. L'Allocation cloud traditionnelle fonctionne ainsi : vous taguez une instance EC2 avec team=platform, et chaque heure d'exécution de cette instance impute son coût à la plateforme. Le tag vit sur la ressource. La ressource génère le coût. La chaîne est ininterrompue.
Les appels d'API IA ne fonctionnent pas ainsi. Lorsque votre application appelle openai.chat.completions.create(), il n'y a aucune ressource à taguer. Il y a une requête, une réponse et un décompte de tokens enregistré côté OpenAI. Votre fournisseur cloud ne le voit jamais. Votre système de tagging n'y touche jamais. En fin de mois, OpenAI vous envoie une facture par organisation, parfois ventilée par modèle, et voilà l'intégralité des informations dont vous disposez.
La FinOps Foundation définit l'Allocation comme une capacité fondamentale, mais le framework présuppose l'existence d'une unité taguable. Pour les fournisseurs d'IA en mode SaaS, ce n'est pas le cas. Anthropic et Bedrock présentent la même configuration. Les dashboards des fournisseurs ventilent les dépenses par clé API ou par modèle, jamais par client ou par fonctionnalité à l'origine de la requête. Même en segmentant vos clés API par équipe, impossible de les segmenter par client sans créer des milliers de clés et les gérer comme un service d'annuaire.
Voilà pourquoi les praticiens FinOps qui transposent la logique de tagging d'EC2 à OpenAI aboutissent au même constat que la CFO au départ : un total. Aucune allocation.
Trois équipes, trois questions, une seule facture
La même facture IA suscite trois questions différentes au sein d'une entreprise, et aucune ne trouve de réponse dans les seules données de facturation du fournisseur.
La finance veut des unit economics. Combien coûte le service rendu à chaque client ? Si un client premium génère 40 $ d'appels Claude par mois et paie 99 $ d'abonnement, la marge n'a rien à voir avec celle d'un client qui n'en génère que 2 $. Sans attribution par client, les calculs de marge brute relèvent de l'estimation.
Le produit veut un ROI par fonctionnalité. Quelles fonctionnalités justifient leur consommation de tokens ? Une fonctionnalité de résumé peut soutenir la rétention pour 8 000 $ par mois. Un agent expérimental peut coûter 22 000 $ par mois et n'être utilisé que par 40 personnes. Le produit ne peut pas prioriser sans savoir quelle fonctionnalité pèse pour quelle part de la facture.
La CFO, elle, veut comprendre pourquoi le chiffre a bougé. Quand la facture Anthropic double d'un mois à l'autre, quelqu'un doit l'expliquer. Un nouveau client ? Un changement de prompt ? Un agent qui s'emballe en boucle ? La facture ne le dit pas. Elle affiche seulement le total.
Les données brutes de facturation ingérées dans un dashboard FinOps ne répondent à aucune de ces questions. Elles se contentent de rejouer la facture. C'est une couche de reporting, pas une couche d'Allocation. Le FinOps Framework considère Automation, Tools, & Services comme le logiciel qui rend possibles les Capabilities, dont l'Allocation pour les nouvelles catégories de dépenses. Côté IA, cette automatisation doit descendre jusqu'à la requête elle-même, car c'est là que réside le contexte métier.
Que fait concrètement l'attribution au niveau du trafic ?
L'attribution au niveau du trafic lit chaque requête IA en temps réel et associe le décompte de tokens au client, à la fonctionnalité et à l'agent qui l'ont déclenchée. Plutôt que de reconstruire l'attribution à partir d'une facture agrégée, elle capture le contexte au moment même où la requête est émise, avant qu'il ne disparaisse.
Concrètement, voici comment cela se passe. Votre application appelle Claude avec un prompt. La requête passe par une gateway ou un proxy qui inspecte le payload et la tague avec l'ID client issu du token d'authentification, le nom de la fonctionnalité tiré du chemin de la requête et l'identifiant d'agent du service appelant. La requête poursuit sa route vers Anthropic. La réponse revient. La gateway enregistre les décomptes de tokens en regard des dimensions taguées. En fin de mois, vous n'avez plus un chiffre unique venu d'Anthropic, mais des milliers d'événements attribués, regroupés selon l'unité métier de votre choix.
Cela fonctionne sur OpenAI, Anthropic et Bedrock parce que le schéma de trafic est identique. Chaque fournisseur renvoie des décomptes de tokens dans sa réponse. Chaque requête transporte un contexte applicatif. La logique d'attribution s'intercale entre votre code et le fournisseur, ce qui vous évite de réécrire du code applicatif pour ajouter des tags. Un coût par client ? Vous l'obtenez. Un coût par agent ? Vous l'obtenez aussi.
Cette approche s'apparente davantage au fonctionnement de l'observabilité qu'à celui du tagging. C'est aussi ce qui explique la différence d'outillage. Un outil FinOps par tags cherche à ingérer un fichier CUR. Un outil d'attribution au niveau du trafic doit s'installer sur le chemin de la requête. Architecture différente, capacité différente. Pour approfondir cette évolution, consultez notre analyse précédente : Pourquoi le FinOps traditionnel atteint ses limites face aux workloads IA.
Comment cela s'inscrit dans le FinOps Framework
L'attribution des coûts IA n'est pas un nouveau dashboard. C'est une nouvelle Capacité d'Allocation pour une catégorie de dépenses qui ne cadre pas avec les hypothèses existantes d'Enterprise Architecture. Le FinOps Framework a été pensé pour des ressources taguables. Compute, stockage, réseau, base de données : tous disposent d'identifiants sur lesquels les outils peuvent regrouper les coûts. Pas les dépenses d'API IA. L'unité de consommation est le token, et les tokens vivent au sein des requêtes, pas sur des ressources.
L'attribution IA relève donc de la couche Automation, Tools, & Services du framework, mais selon un modèle d'implémentation différent de celui de l'Allocation par tags. Au lieu d'ingérer des exports de facturation et de regrouper par tag, l'outillage lit le trafic en direct et génère des enregistrements d'attribution qui viennent alimenter la Capacité d'Allocation. Le résultat est identique pour un utilisateur finance : un coût par équipe, par client, par fonctionnalité. Le mécanisme sous-jacent, lui, diffère.
Cela change la façon dont les praticiens FinOps planifient leur toolchain. Bâtir une pratique FinOps IA sur un outil par tags, c'est se heurter au même mur que la responsable financière de la CFO. Si vous évaluez un outil d'attribution IA, la question n'est pas "ingère-t-il ma facture OpenAI ?". Tous les outils le font. La bonne question est "attribue-t-il ma facture OpenAI ?". Cela exige une instrumentation au niveau du trafic, et non une ingestion de facturation.
La page Capabilities du FinOps Framework mérite d'être relue à la lumière des workloads IA. Anomaly Management, Allocation et Forecasting présupposent tous l'existence d'une attribution. Pour les dépenses IA, l'attribution est précisément l'entrée manquante.
Frequently asked
questions
Comment attribuer les dépenses OpenAI ou Anthropic à un client précis ?
Il faut capturer l'ID client au moment où la requête est émise, car la facture du fournisseur ne l'inclut pas. Cela suppose d'instrumenter le trafic entre votre application et le fournisseur — via une gateway, un proxy ou un wrapper SDK — afin que chaque décompte de tokens soit enregistré en regard d'un identifiant client.
Pourquoi le tagging ne peut-il pas résoudre l'attribution des coûts IA ?
Le tagging nécessite une ressource à laquelle se rattacher. Les appels de tokens vers OpenAI, Anthropic ou Bedrock ne créent aucune ressource taguable dans votre compte cloud : il n'y a donc rien sur quoi le tag puisse se fixer. Le coût apparaît sous la forme d'une seule ligne agrégée sur la facture du fournisseur.
Quel est le coût par fonctionnalité d'un produit IA ?
C'est la somme des coûts de tokens générés par les requêtes issues de cette fonctionnalité, répartie sur les clients ou sessions qui l'ont utilisée. Vous ne pouvez le calculer que si vous capturez l'identifiant de fonctionnalité sur chaque requête au moment où elle a lieu, puisque les données de facturation du fournisseur n'incluent pas ce contexte.
Comment les équipes FinOps répartissent-elles les dépenses LLM entre clients et fonctionnalités ?
Elles déplacent l'attribution de la couche de facturation vers la couche de trafic. Plutôt que de ventiler une facture agrégée a posteriori, elles capturent le contexte de chaque requête — client, fonctionnalité, agent — au moment de l'appel API, puis consolident ces événements dans des rapports de coûts.
Comment suivre la consommation de tokens par agent ou par workflow ?
Il faut une instrumentation qui identifie l'agent ou le workflow appelant à chaque requête. Cela passe par des en-têtes de requête, des identifiants de service ou une gateway qui inspecte le pattern d'appel, puis rattache les décomptes de tokens renvoyés par le fournisseur à l'agent qui les a déclenchés.
Les dépenses IA ont fait voler en éclats le modèle du tagging : un appel de tokens n'offre rien à taguer. La finance, le produit et la CFO posent tous des questions auxquelles les factures des fournisseurs ne peuvent pas répondre, et aucune ingestion de facturation n'y changera rien. L'attribution doit se déplacer vers la couche de trafic, là où chaque requête transporte encore le contexte client, fonctionnalité et agent qui donne du sens au chiffre.