Unit economics cloud : calculer le coût par client, feature et environnement

Comment définir la bonne unité de coût cloud ?

La première erreur, et de loin la plus fréquente, c’est de vouloir calculer « le coût par client » avant même de savoir ce que recouvre le mot client dans votre contexte. Un client B2B avec dix utilisateurs et un client B2B avec cinq mille utilisateurs ne sont pas la même unité et pourtant, beaucoup d’entreprises les traitent comme un seul et même axe d’analyse parce que c’est la colonne qui existe déjà dans le CRM.

On distingue en général trois familles d’unités, et il vaut mieux les traiter séparément dès le départ plutôt que d’essayer de les fusionner artificiellement.

Le coût par client (ou par tenant, si vous êtes en architecture multi-tenant) répond à une question commerciale : ce compte est-il rentable au tarif actuel ? C’est l’unité la plus naturelle à vendre en interne, celle qui parle immédiatement au CFO et au sales. Mais elle cache énormément de disparités internes un client « moyen » n’existe pas vraiment, c’est une fiction statistique utile pour les board decks, dangereuse pour les décisions opérationnelles.

Le coût par feature (ou par service, si votre produit est découpé en modules) répond à une question produit : cette fonctionnalité justifie-t-elle son coût d’infrastructure au regard de son usage ou de sa valeur perçue ? On a vu des équipes découvrir qu’une feature d’export PDF, utilisée par 3 % des utilisateurs, représentait 22 % de la charge de calcul totale — parce que personne n’avait mis de limite raisonnable sur la taille des documents générés. Ce genre de découverte ne sort jamais d’un dashboard de facturation cloud classique. Il sort d’un travail d’allocation par feature.

Le coût par environnement répond à une question d’hygiène technique : combien coûte le staging qui tourne 24h/24 pour trois développeurs ? Combien coûte cet environnement de démo qu’on a créé pour un prospect il y a huit mois et que personne n’a jamais éteint ? On sous-estime systématiquement ce que les environnements non-productifs pèsent dans la facture sur les audits qu’on mène chez Leonys, c’est fréquemment entre 15 et 30 % du total, pour une valeur business proche de zéro une fois la démo ou le test terminé.

Le vrai travail, à cette étape, ce n’est pas technique c’est de décision. Il faut choisir l’unité qui répond à la question que vous vous posez vraiment. Un CFO qui veut challenger la rentabilité par segment de clientèle n’a pas besoin d’un détail par feature. Un VP Product qui doit arbitrer une roadmap n’a pas besoin d’un détail par client. Vouloir tout mesurer en même temps, dès le départ, c’est le meilleur moyen de ne jamais rien livrer.

Quelles données utiliser pour calculer les coûts unitaires cloud ?

Une fois l’unité choisie, on pourrait croire que la suite est un exercice de reporting. Ce n’est pas le cas. La donnée brute de facturation cloud (AWS Cost and Usage Report, Azure Cost Management, GCP Billing Export) vous donne un coût par service, par ressource, parfois par tag mais jamais nativement un coût par client ou par feature. Il faut construire ce lien, et c’est là que la plupart des projets d’unit economics s’enlisent.

Le tagging est la brique de base, et on ne le répétera jamais assez : sans une stratégie de tagging rigoureuse (client_id, feature_id, environment, cost_center appliqués de façon systématique dès la création de la ressource), toute tentative d’allocation fine part avec un handicap sérieux. Le problème, c’est que le tagging seul ne suffit pas dès qu’on sort des ressources dédiées. Une instance EC2 provisionnée pour un client précis, facile. Une base de données partagée par douze clients sur un modèle multi-tenant, une queue de traitement asynchrone commune à toutes les features, un cluster Kubernetes qui héberge trente microservices sur les mêmes nœuds là, le tag ne répond plus à la question.

Il faut alors croiser plusieurs sources : les métriques applicatives (nombre de requêtes, volume de données traité, temps de calcul consommé par tenant souvent disponibles via vos logs ou votre APM), les métriques d’infrastructure (utilisation CPU/mémoire par pod ou par namespace si vous êtes en Kubernetes), et les données de facturation elles-mêmes. Aucune de ces sources, prise isolément, ne donne le coût par client. C’est leur combinaison, via des clés de répartition qu’on définit soi-même, qui produit un chiffre exploitable.

On voit souvent des équipes techniques hésiter avant de se lancer, en se disant qu’il faut d’abord un outil de FinOps sophistiqué pour faire ça bien. C’est une erreur de séquencement. On a vu des premières estimations solides sortir d’un croisement manuel entre l’export de billing et les logs applicatifs dans un tableur pas élégant, mais suffisant pour prendre une première décision. L’outillage vient ensuite, pour industrialiser ce qui a déjà prouvé sa valeur, pas pour le remplacer.

Comment allouer les coûts d’une infrastructure cloud mutualisée ?

C’est le cœur technique du sujet, et honnêtement, c’est là que le débat devient presque philosophique : il n’existe pas de méthode d’allocation parfaite, seulement des méthodes plus ou moins défendables selon votre contexte.

Trois approches reviennent le plus souvent.

L’allocation directe s’applique quand une ressource est dédiée à une unité précise un client premium avec son propre cluster, une feature isolée dans son propre service. C’est simple, c’est exact, et c’est malheureusement rare dès que l’architecture cherche à optimiser les coûts par la mutualisation (ce qui est, ironiquement, une excellente pratique FinOps qui complique ensuite l’unit economics on y reviendra en FAQ).

L’allocation proportionnelle répartit un coût partagé au prorata d’un indicateur d’usage mesurable : le nombre de requêtes API par client, le volume de stockage occupé, le temps CPU consommé. C’est la méthode la plus utilisée, et la plus honnête, à condition de choisir un indicateur qui reflète réellement la consommation de ressources pas un proxy commode mais trompeur. Répartir le coût d’un cluster de calcul au prorata du nombre d’utilisateurs actifs, par exemple, ignore complètement le fait que certains utilisateurs déclenchent des traitements bien plus lourds que d’autres. Le choix du dénominateur est presque toujours le point de friction principal dans ces projets, et c’est normal d’y passer du temps c’est une décision de modélisation, pas un détail technique.

L’allocation forfaitaire, enfin, répartit un coût fixe de manière égale ou selon une clé arbitraire assumée (par exemple, moitié aux plans premium, moitié aux plans standard). Elle a mauvaise réputation parce qu’elle est moins « scientifique », mais elle est parfaitement légitime pour les coûts qui ne sont pas raisonnablement rattachables à un usage le coût d’une équipe SRE, par exemple, ou d’un outil de monitoring transverse. Vouloir à tout prix rendre proportionnel ce qui ne l’est pas produit des chiffres faussement précis, ce qui est pire qu’un chiffre honnêtement approximatif.

Un point qu’on insiste beaucoup à souligner en atelier : documentez vos clés d’allocation. Pas pour la forme, mais parce que dans six mois, quelqu’un va contester un chiffre un chef de produit va trouver que sa feature « coûte trop cher » selon le modèle et si vous ne pouvez pas expliquer pourquoi vous avez choisi telle clé plutôt qu’une autre, la crédibilité de tout l’exercice s’effondre. Un unit economics qu’on ne peut pas défendre en réunion ne sert à rien.

Comment analyser le coût cloud par client, fonctionnalité et environnement ?

Voilà, vous avez un tableau : coût par client, coût par feature, coût par environnement. Et là, en général, deux réactions se bousculent. La première, c’est le soulagement d’avoir enfin un chiffre. La seconde, plus tardive et plus utile, c’est la méfiance qu’il faut absolument garder face à ce chiffre.

Parce qu’un coût unitaire seul ne dit rien. Ce qui compte, c’est de le rapporter à quelque chose : à la marge brute par client une fois le coût d’infra soustrait du revenu, à l’évolution du coût dans le temps pour une même feature (une hausse de 40 % en trois mois sur une feature qui n’a pas changé de périmètre fonctionnel, c’est un signal d’alerte, pas une fatalité), ou à la distribution pas seulement la moyenne. Un coût moyen par client de 12 € masque très bien le fait que 5 % de vos clients coûtent 80 € et que le reste coûte 3 €. Cette distribution-là, c’est elle qui doit guider vos décisions, pas la moyenne qui lisse tout et rassure à tort.

On recommande systématiquement de croiser trois lectures. D’abord, les outliers : quels sont les 10 clients les plus coûteux, et pourquoi ? Souvent, la réponse tient en une ou deux causes concentrées un usage intensif d’une feature lourde, une intégration mal optimisée, un environnement de test client oublié en production. Ensuite, la tendance : le coût par unité augmente-t-il plus vite que le revenu associé ? C’est le signal le plus dangereux de tous, parce qu’il est silencieux l’entreprise peut croître en chiffre d’affaires tout en dégradant sa marge unitaire, et personne ne s’en aperçoit avant le rapprochement trimestriel. Enfin, la comparabilité : un coût par feature n’a de sens que comparé à sa valeur perçue ou à son usage une feature chère mais différenciante et massivement utilisée n’est pas un problème, une feature chère et marginale, si.

Et il faut accepter une chose, aussi inconfortable soit-elle : la première mesure sera imparfaite. Les clés d’allocation seront approximatives, certains coûts resteront difficiles à rattacher précisément, et c’est normal. L’objectif n’est pas la précision comptable au centime près c’est d’obtenir une direction fiable, suffisante pour trancher. On préfère toujours une estimation à 80 % de précision livrée cette semaine à une modélisation parfaite qui ne sortira jamais du chantier.

Comment l’unit economics cloud améliore le pricing et la roadmap produit ?

C’est la partie qu’on ne devrait jamais séparer du calcul lui-même, et pourtant c’est systématiquement celle qui manque. Un unit economics qui reste un exercice FinOps isolé, sans connexion avec les décisions de pricing et de produit, perd l’essentiel de sa valeur.

Sur le pricing, d’abord. Connaître le coût réel par client permet de sortir du tarif unique appliqué à des profils de consommation radicalement différents. Ça ne veut pas dire qu’il faut facturer chaque client à son coût marginal exact la valeur perçue compte aussi, et un client à faible coût d’infra mais à fort besoin d’accompagnement peut légitimement payer plus cher qu’un tarif purement indexé sur la consommation cloud. Mais ça veut dire qu’un plan tarifaire construit sans connaître les coûts sous-jacents est, au mieux, un pari. On a accompagné des entreprises SaaS qui ont découvert, une fois l’unit economics posé, que leur plan d’entrée de gamme était structurellement déficitaire dès qu’un client dépassait un seuil d’usage pourtant courant. Pas catastrophique en soi sauf que ce plan représentait 60 % de la base client.

Sur la roadmap produit, ensuite, l’effet est parfois encore plus net. Une feature dont le coût d’infrastructure explose sans que l’usage ou la valeur suive la même courbe devient un candidat naturel à l’optimisation technique, voire à la remise en question pure et simple de son existence dans sa forme actuelle. Ce n’est pas un jugement sur l’intérêt produit de la feature c’est un signal qu’il faut investiguer : est-ce un problème d’implémentation (une requête non optimisée, un stockage mal dimensionné) ou un problème structurel (la feature est intrinsèquement coûteuse à l’échelle et nécessite un modèle de tarification différencié) ? Ces deux diagnostics appellent des réponses complètement différentes, et sans l’unit economics, on ne sait même pas qu’il faut se poser la question.

Il y a aussi un usage moins évident mais tout aussi puissant : celui de prioriser les efforts d’ingénierie sur la base du ROI réel plutôt que sur l’intuition. Une équipe qui sait que telle feature coûte 40 % du budget infra pour 8 % de l’usage a un argument imparable pour justifier un sprint d’optimisation technique auprès d’une direction qui, sinon, aurait préféré voir cette équipe livrer de nouvelles fonctionnalités. C’est un des rares cas où le FinOps devient un argument produit à part entière, et pas seulement une ligne de reporting financier.

Comment calculer les coûts unitaires dans une architecture cloud partagée ?

C’est la question qu’on nous pose le plus souvent, et elle mérite une réponse directe : une architecture partagée ne rend pas l’unit economics impossible, elle le rend simplement moins précis à obtenir et c’est acceptable.

Face à une base de données mutualisée, un cluster Kubernetes commun ou une architecture multi-tenant serrée, la bonne stratégie n’est pas de viser une allocation exacte à la ressource près (ce qui, techniquement, peut demander un effort d’instrumentation disproportionné par rapport au bénéfice), mais de construire des proxys de mesure raisonnables et transparents. Un indicateur applicatif nombre de requêtes, volume de données traité, temps de traitement appliqué de façon cohérente à l’ensemble des clients donne une allocation défendable, même imparfaite. L’essentiel est la cohérence de la méthode dans le temps, pas son exactitude absolue à un instant donné : un chiffre qui bouge de façon cohérente d’un mois à l’autre est plus utile pour piloter qu’un chiffre ponctuellement exact mais incomparable d’une période à l’autre.

Et il faut aussi accepter qu’un certain pourcentage des coûts, souvent entre 10 et 20 % selon les architectures qu’on a auditées, restera raisonnablement classé en coûts communs non-allouables l’équivalent des frais généraux dans une comptabilité classique. Ce n’est pas un échec de la méthode, c’est une limite honnête à assumer plutôt qu’à masquer par une clé de répartition artificielle qui donnerait une fausse impression de précision.

Combien de temps faut-il pour obtenir les premiers chiffres exploitables ?

Sur les projets qu’on a menés, une première estimation défendable pas parfaite, mais suffisante pour orienter une décision de pricing ou de priorisation produit sort généralement en deux à trois semaines, à condition que le tagging de base existe déjà. Sans tagging du tout, il faut compter ce délai en plus pour la mise en place, ce qui est une raison supplémentaire de ne jamais repousser ce chantier « à plus tard ».

Comment transformer l’unit economics en outil de pilotage de la rentabilité ?

On a passé cet article à parler méthode, allocation, clés de répartition c’est nécessaire, mais ce n’est pas le plus dur. Le plus dur, c’est de faire de l’unit economics un réflexe organisationnel : que le CFO le consulte avant de valider un plan tarifaire, que le VP Product s’y réfère avant d’arbitrer un sprint, que personne ne signe un gros contrat sans avoir une idée de sa marge unitaire prévisionnelle. Le calcul, une fois la méthode posée, se refait en quelques heures chaque mois. C’est l’habitude de s’en servir qui prend du temps à s’installer et qui fait, au bout du compte, toute la différence entre une entreprise qui pilote sa rentabilité et une entreprise qui la découvre a posteriori.