Les questions sur les coûts cloud paraissent souvent simples.
- Combien nous coûte ce client ?
- Quel est le coût d'exploitation de cette fonctionnalité ?
- Quelles équipes ou quels produits tirent la dépense ?
À petite échelle, quelques estimations suffisent à y répondre. Mais à mesure que les systèmes grandissent, ces questions deviennent, sans bruit, parmi les plus difficiles de l'organisation.
Non pas par manque de données, mais parce que le fonctionnement même de l'infrastructure moderne a changé.
Les coûts ne collent plus au périmètre de responsabilité
Dans les environnements en phase initiale, les coûts épousent généralement le périmètre de responsabilité. Un service appartient à une équipe. Une base de données porte un produit. Un environnement correspond à une fonction.
À mesure que l'infrastructure grandit, ce modèle mental s'effondre.
Les systèmes actuels sont :
- Largement partagés entre équipes et produits
- Bâtis sur des couches de plateforme au service de nombreux consommateurs
- De plus en plus multi-tenants par conception
Le coût n'a plus un propriétaire unique. Il se répartit selon les usages. À ce stade, la question " à qui cela appartient-il ? " n'est plus la bonne.
L'infrastructure partagée masque la consommation réelle
L'essentiel des coûts cloud se concentre dans les couches partagées :
- Pipelines de données
- Plateformes de streaming
- Bases de données
- Réseau et trafic inter-services
- Services de plateforme qui portent de nombreux workloads
Ces composants correspondent rarement, un pour un, à une équipe, une fonctionnalité ou un client.
Ils absorbent au contraire l'usage de toute l'organisation, souvent de manière inégale. Certaines équipes consomment bien plus que d'autres, mais ce déséquilibre reste difficile à percevoir.
Résultat : une opacité sur les coûts, même quand la dépense globale est visible.
Pourquoi l'unit economics se brouille à grande échelle
Quand le coût ne peut plus être rattaché directement à l'usage, l'unit economics en pâtit.
Les équipes peinent à :
- Expliquer les marges par client ou par produit
- Identifier les fonctionnalités rentables
- Prévoir la dépense avec précision
- Trancher sereinement sur l'architecture ou la tarification
La finance voit des chiffres qui ne se réconcilient pas. L'engineering voit une complexité que les rapports ne restituent pas.
Tout le monde ressent l'écart.
Le vrai enjeu, c'est l'attribution, pas la visibilité
Le vrai enjeu n'est pas la visibilité. C'est le modèle.
Toutes les organisations voient leur facture cloud.
Ce qui se grippe, c'est le lien entre les ressources cloud et les questions métier qui vous sont posées.
Les tags cloud rendent service pour une responsabilité simple. Mais les questions à la maille unitaire sont rarement du un pour un :
- Un client utilise de nombreux services.
- Un service sert de nombreux clients.
- Une équipe plateforme porte de nombreux produits.
- L'infrastructure partagée et le trafic réseau n'ont pas de propriétaire unique.
Même avec une hygiène de tagging irréprochable, les tags ne peuvent restituer cette réalité plusieurs-à-plusieurs, ni la logique d'allocation nécessaire pour répondre à des questions comme le coût par client, le coût par fonctionnalité, ou savoir quelle équipe en subventionne une autre.
Voilà pourquoi l'unit economics se brouille à grande échelle : les données existent, mais le modèle de coûts ne reflète pas la façon dont le système est réellement consommé. C'est aussi pour cela que notre approche FinOps sans tagging se démarque autant.
Ce que font différemment les équipes les plus avancées
Les équipes qui opèrent à grande échelle repensent la façon de modéliser les coûts :
- En partant de l'usage réel (bottom-up), plutôt que d'une responsabilité descendante
- En partant des systèmes partagés, plutôt que de ressources isolées
- En partant de la consommation réelle, plutôt que d'hypothèses
Ce basculement rend le coût unitaire de nouveau explicable, même dans des environnements complexes.
Vous pouvez voir comment cela fonctionne concrètement dans cette étude de cas qui montre comment Akamai explique le coût unitaire sur une infrastructure partagée sans recourir au tagging :
Et pour voir ce que cela donne dans votre environnement, vous pouvez planifier une démo ici