Cloud Intelligence™
Des rapports que la finance valide enfin
Cette page est également disponible en English, Deutsch, Español, Italiano, 日本語 et Português.
About Devorah Klartag
Marketing director. 15+ years turning marketing vision into infrastructure that actually scales - GTM, demand gen, ops, and the AI-powered systems that keep the whole thing moving. At Attribute, I built the marketing function from the ground up and hit top-3 AI search rankings on competitive FinOps queries in ChatGPT, Perplexity, and Claude.
Previously: senior growth and marketing ops at D-ID (led the self-service studio launch that hit #1 Product of the Day on Product Hunt and landed coverage in TechCrunch, Fast Company, and Forbes), digital marketing at CyberProof, and $7M campaigns at McCann Tech for NICE and Amdocs. Earlier, hospitality marketing across NYC restaurants and cruise lines.
Ex-New Yorker in Tel Aviv. Still misses the bagels most.
My personal pageVous avez passé des mois à construire des rapports et des dashboards. Coûts par équipe, coûts par workload, refacturation par entité métier. Tout semble correct aux yeux des ingénieurs. Puis la finance assiste à la revue et demande : Pouvez-vous prouver ces chiffres ?
C'est compliqué. Vos outils reposent sur des exports de facturation, des moteurs de règles et une couverture de tags complète à 70 %. Ce n'est pas assez solide pour prendre des décisions business, établir des prévisions et des projections.
PerfectScale™ for Kubernetes
Ready to optimize?
Get your free Kubernetes savings analysis
Pourquoi les chiffres ne tiennent pas la route
Les outils FinOps ont été conçus pour lire le fichier de facturation généré par votre fournisseur cloud, le découper à l'aide de règles et de tags, puis afficher le résultat dans un dashboard.
La finance et la direction posent leurs questions sous un autre angle. Combien coûte le service rendu au client X ? Lequel de nos produits dégage une marge positive ? La plupart des outils FinOps vous donnent une réponse. Très peu vous en donnent une auditable.
Ce que bon à jeter veut vraiment dire
Quand une partie prenante qualifie un rapport de coûts de bon à jeter, c'est soit parce que les chiffres ne correspondent pas à ce qu'elle sait être vrai, soit parce qu'elle ne comprend pas comment ils ont été obtenus.
En pratique, cela se résume généralement à trois causes :
Des règles autrefois pertinentes, mais devenues obsolètes.
Vos règles d'allocation ont été définies il y a 18 mois. Trois migrations et deux rebrandings produit plus tard, elles pointent toujours vers des services et des labels qui n'ont plus le même sens qu'à l'époque. Les chiffres paraissent cohérents dans le dashboard parce que les règles s'exécutent de façon cohérente. Personne n'a vérifié si elles étaient encore correctes. Chacun pensait que le nettoyage relevait de quelqu'un d'autre.
Des tags qui n'ont jamais atteint une couverture complète.
L'attribution basée sur les tags ne couvre que les ressources taguées. Les 30 % que l'engineering n'a jamais tagués sont soit ignorés, soit répartis via un découpage artificiel. Quand la finance demande ce que contient le poste non alloué, la réponse honnête est : une part significative des dépenses réelles. L'inférence IA aggrave la situation : la plupart des équipes ne savent pas du tout comment taguer les appels de modèles, encore moins par fonctionnalité ou par client.
Des données périmées dans le modèle. D'anciens comptes, des services décommissionnés, des contrats arrivés à échéance, mais dont les données historiques figurent toujours dans le modèle.
Le problème du P&L produit
Le problème de confiance s'amplifie quand les équipes FinOps tentent de répondre à la véritable question de la finance : non pas combien coûte ce workload, mais combien coûte ce produit, par région, par segment de clientèle ?
Cette question exige plus que des données de coûts. Un client qui exploite trois produits dans cinq régions se moque de savoir quel namespace Kubernetes porte la dépense. Ce qui compte, c'est de savoir si le client est rentable. Il faut savoir quel workload sert quel produit, quels clients consomment quels workloads, et comment l'infrastructure partagée se répartit entre tout cela. Les outils FinOps classiques peuvent s'en approcher avec suffisamment de tagging et de règles. Mais les approximations ne résistent pas à un VP qui demande la méthodologie sous-jacente.
Ce que la finance veut réellement, c'est le cost-to-serve au niveau du client et du produit, composantes fixes et variables comprises, y compris les dépenses SaaS tierces comme Snowflake ou Twilio, dans un format défendable devant le conseil d'administration. Les équipes pricing en ont besoin pour fixer leurs marges. La finance en a besoin pour le reporting du COGS. Les responsables produit en ont besoin pour identifier les fonctionnalités qui tirent la marge vers le bas.
La plupart des outils de coûts cloud excellent à répondre à la question pourquoi notre facture AWS a-t-elle augmenté ? Ils n'ont jamais été conçus pour répondre à ce produit est-il rentable ?
Le même problème arrive désormais plus vite avec les dépenses IA. Les coûts d'inférence LLM ne se comportent pas comme EC2. Ils sont pilotés par les requêtes, propres à chaque client, et ils s'accumulent rapidement. Un export de facturation vous dit ce que Bedrock ou OpenAI vous a facturé le mois dernier. Il ne vous dit pas quelle fonctionnalité produit en est à l'origine, quel segment de clients l'a consommée, ni si les unit economics tiennent à l'échelle. Volume de tokens, choix du modèle, longueur des prompts : rien de tout cela ne correspond à une ligne de facturation. La finance commence à poser des questions sur le COGS de l'IA comme elle en pose sur le COGS du cloud. Le manque de données est identique. Les enjeux sont plus élevés parce que les coûts évoluent plus vite.
Your cloud bill shouldn't be a mystery
Optimization, automation, expertise. In one platform.
Le problème de la reconstitution de la réalité
Tous les outils basés sur les exports de facturation présentent la même limite structurelle. Le fichier de facturation vous dit ce qui vous a été facturé. Il ne vous dit ni pourquoi, ni quels clients en sont à l'origine, ni comment les ressources partagées se répartissent réellement entre les consommateurs.
Attribute lit le système en production plutôt que le fichier de facturation. Un capteur eBPF ultraléger, déployé sur votre infrastructure de calcul, observe quels workloads communiquent avec quelles bases de données et quels services, à partir de données runtime, au niveau de la couche réseau. L'attribution des coûts suit le comportement réel, pas des règles décrivant un comportement attendu.
La différence prend tout son sens lorsqu'une partie prenante vous demande d'où vient un chiffre. Avec une attribution basée sur la facturation, vous remontez une chaîne de règles et d'hypothèses. Avec l'attribution au runtime, vous remontez à une activité réseau observée.
Ce que cela donne en pratique
Prenez la visibilité des coûts par équipe, l'une des demandes FinOps les plus courantes. Avec un outil basé sur le tagging, votre visibilité sur les coûts d'une équipe dépend entièrement de votre couverture de tags et de la qualité de vos labels. Les namespaces partagés posent problème. Les services déployés la semaine dernière par l'engineering et pas encore tagués sont invisibles.
Le capteur d'Attribute détecte automatiquement les nouveaux workloads, parce qu'il les observe communiquer dans l'infrastructure au lieu d'attendre que quelqu'un leur attribue un tag. Quand votre équipe doit présenter les coûts refacturables par équipe, l'approche runtime produit un chiffre que vous pouvez défendre, parce qu'il reflète ce qui tourne réellement.
Le même principe s'applique au niveau du client. Si vous devez savoir combien coûte réellement le service d'un client donné, infrastructure fixe, calcul variable et outillage SaaS compris, un export de facturation ne suffira pas sans un travail de mapping manuel conséquent. Attribute construit ce mapping à partir de ce qu'il observe : quels workloads clients sollicitent quels services, dans quel volume, à quel coût. Quand les clients demandent le coût produit par région ou la rentabilité d'un produit selon les types de services, la question obtient une vraie réponse plutôt qu'une estimation.
Il en va de même pour les coûts IA. Le capteur d'Attribute lit les appels au niveau de la couche réseau : quel service a émis l'appel, quel workload client l'a déclenché, et ce qu'il a coûté. C'est le chiffre dont une équipe pricing a besoin pour décider d'absorber le coût d'inférence ou de le répercuter.
Attribute aide les équipes FinOps et finance à comprendre ce que financent réellement leurs dépenses cloud et SaaS, grâce à l'attribution au runtime plutôt qu'aux tags manuels et aux exports de facturation.
Pourquoi les rapports de coûts cloud échouent-ils face à la finance ?
La plupart des outils FinOps construisent leurs rapports à partir d'exports de facturation, de règles d'allocation et de tags. Les règles vieillissent. La couverture des tags est rarement complète. Quand la finance demande comment un chiffre a été obtenu, la réponse honnête remonte à une chaîne d'hypothèses, pas à des données observées. C'est précisément là que se situe l'écart.
Qu'est-ce que l'attribution des coûts au runtime ?
L'attribution au runtime signifie que les coûts suivent le comportement réel du système plutôt que des règles décrivant un comportement attendu. Attribute déploie un capteur eBPF qui observe quels workloads communiquent avec quels services au niveau du runtime. Chaque coût remonte à une activité réseau observée, et non à une décision de tagging prise il y a 18 mois.
Comment les dépenses non taguées sont-elles gérées ?
Avec les outils basés sur le tagging, les ressources non taguées sont soit ignorées, soit réparties via un découpage artificiel. Le capteur d'Attribute détecte les workloads, qu'ils soient tagués ou non, parce qu'il les observe communiquer dans l'infrastructure. Les nouveaux services déployés la semaine dernière sont visibles immédiatement.
Attribute peut-il montrer le cost-to-serve par client ?
Oui. Attribute rattache les dépenses cloud et SaaS à chaque client final en observant quels workloads clients sollicitent quels services, dans quel volume, à quel coût. Le résultat : un véritable cost-to-serve, incluant l'infrastructure fixe, le calcul variable et les outils tiers comme Snowflake ou Twilio.
Et les coûts d'inférence IA et LLM ?
Les coûts d'inférence n'apparaissent pas dans les exports de facturation avec un niveau de détail exploitable. Le capteur d'Attribute lit les appels de modèles au niveau de la couche réseau et attribue chaque requête au service, au client et à la fonctionnalité qui l'ont déclenchée. C'est le chiffre dont les équipes pricing ont besoin pour fixer les marges des fonctionnalités IA.
En quoi est-ce différent de CloudZero ou d'Apptio ?
Ces outils travaillent à partir d'exports de facturation et exigent du tagging avant d'afficher des données pertinentes. Attribute, lui, lit le système en production. Aucun tagging requis, aucune maintenance de règles, et la méthodologie tient la route quand une partie prenante demande d'où vient un chiffre.
