La plupart des débats sur le pricing SaaS partent du mauvais pied.
Les équipes s'écharpent sur les paliers. Elles hésitent entre nombre de sièges et limites d'usage. Elles étudient la concurrence. Elles interrogent leurs clients sur ce qu'ils seraient prêts à payer. Puis elles lancent, voient leurs marges fondre et se demandent ce qui a bien pu se passer.
Voici ce qui s'est passé : le modèle de pricing a été bâti sur des estimations de coûts, pas sur la réalité. Et les estimations vieillissent mal. Le secret honteux de l'unit economics SaaS
Quand un VP Product ou un consultant en pricing construit un modèle pour une nouvelle offre, il raisonne à rebours à partir d'hypothèses. Les coûts d'infrastructure sont approximés. La consommation des ressources partagées est moyennée. L'usage de l'IA est estimé au doigt mouillé. La variance entre clients est lissée sur une seule ligne.
Le modèle indique qu'un client sur le plan Growth devrait coûter 80 $/mois à servir. Le coût réel, une fois retracé à travers l'infrastructure, avoisine plutôt 190 $ pour vos comptes les plus lourds et 12 $ pour les plus légers. La moyenne paraît saine. La queue de distribution, elle, vous saigne en silence.
Ce n'est pas un problème de stratégie de pricing. C'est un problème de données. Plus précisément, un problème de dataset manquant.
D'où vient cet écart
Les outils traditionnels de gestion des coûts cloud ont été conçus pour les équipes FinOps qui pilotent des budgets d'infrastructure. Ils lisent les exports de facturation, parsent les logs CloudTrail et organisent la dépense par compte, région ou tag. Utile pour l'équipe engineering qui cherche à faire du right-sizing sur ses instances EC2.
Inutile pour le pricing.
Les équipes pricing ont besoin d'une lecture des coûts organisée autrement : par client, par ligne de produit, par fonctionnalité, par l'unité d'usage qu'elles facturent réellement. Un export de facturation ne sait pas quel client a déclenché quel workload. Il ignore qu'un compte enterprise fait tourner des scan jobs qui consomment 40 fois plus de compute que n'importe quel autre client du même plan. Il ignore que votre fonctionnalité IA coûte trois fois plus cher pour vos power users que pour les utilisateurs occasionnels.
La couche de facturation n'a pas ce contexte. Elle ne l'a jamais eu. Elle a été conçue pour indiquer aux fournisseurs cloud combien vous facturer, pas pour vous dire combien coûte le workload de chacun de vos clients.
Pour répondre à cette question, il faut une source de données radicalement différente.
Ce que changent les données runtime
Quand vous instrumentez votre infrastructure à partir de données runtime — trafic réel, appels de services réels, consommation de ressources en temps réel — le portrait des coûts change du tout au tout.
Vous voyez quels clients déclenchent quels workloads. Vous pouvez remonter d'une requête base de données à la fonctionnalité qui l'a déclenchée, puis au client qui l'a utilisée. Vous pouvez observer des ressources partagées comme Kafka ou Elasticsearch et savoir précisément quels tenants consomment quoi, sans demander aux ingénieurs de taguer quoi que ce soit.
Ce n'est pas une capacité théorique. Elle existe aujourd'hui, déployée en production dans des entreprises qui mènent exactement ce type d'analyse.
Que découvrent-elles ?
La plupart constatent que leur représentation mentale de la distribution des coûts est fausse. L'écart entre consommateurs légers et lourds est plus large qu'anticipé. Un petit pourcentage de comptes — souvent enterprise, souvent au milieu de la gamme d'offres — consomment à un rythme qui fait passer leur ARR pour une remise déguisée.
Une entreprise a identifié 360 comptes dont le coût de service dépassait le revenu. Exposition totale : 1,3 M$ de pertes annuelles, invisibles jusqu'à ce que l'attribution runtime relie les coûts aux clients. Ces pertes ne se cachaient pas dans les comptes que l'on savait déjà déficitaires. Elles se dissimulaient dans des plans qui affichaient un ARR en apparente bonne santé.
Le pricing IA : un avant-goût de ce qui vient
Ce type de compression de marge ne va pas s'atténuer, il va s'aggraver.
Les fonctionnalités IA modifient la structure de coûts d'un produit SaaS d'une façon que le pricing par sièges — voire par usage — ne capture presque jamais. Un agent IA qui exécute un workflow multi-étapes ne consomme pas une quantité fixe de compute. Il consomme en fonction de la complexité, de la taille des inputs, du nombre d'outils qu'il appelle, du nombre de tokens qu'il brûle en chemin. Deux clients utilisant la même fonctionnalité IA peuvent afficher des profils de coûts qui varient d'un facteur 10.
Si votre modèle de pricing les traite à l'identique, l'un subventionne l'autre.
Les entreprises qui réussiront le pricing de l'IA seront celles capables de voir la consommation de tokens, les actions d'agent et le volume d'appels d'outils au niveau du client, puis de construire un pricing aligné sur cette réalité. Pas par siège. Pas par tranche de mille requêtes. Des structures de pricing qui reflètent les véritables leviers de coûts du produit.
Cela exige des données runtime. Il n'existe aucun autre moyen d'atteindre ce niveau de granularité.
Ce que cela débloque pour les équipes pricing
Vous pouvez repérer quels segments sont à marge négative avant qu'ils ne surgissent dans une présentation au board. Vous pouvez identifier quels paliers présentent la plus forte variance de coûts et concevoir des limites d'usage ou des add-ons calés sur la consommation réelle. Vous pouvez mesurer l'impact sur la marge d'une nouvelle capacité avant de la pricer et de la livrer, en vous appuyant sur des données de référence réelles plutôt que sur des hypothèses modélisées.
Vous pouvez aussi bâtir des modèles de pricing jusque-là hors de portée. Le pricing à la consommation cesse d'être un pari lorsque vous savez précisément combien coûte à livrer chaque unité consommée. Le pricing à la valeur devient défendable dès lors que vous pouvez démontrer ce que vous dépensez réellement pour produire le résultat que vous facturez.
L'ère des agents rend tout cela plus urgent. Si vous facturez 250 $ par tâche accomplie, vous devez savoir si cette tâche vous a coûté 80 $ ou 380 $. La réponse change tout : quels workflows pricer plus haut, lesquels repenser, quels clients sont rentables au tarif actuel. Sans données runtime, vous naviguez à l'aveugle sur vos décisions de pricing les plus stratégiques.
Vous pouvez enfin répondre à la question que les équipes pricing ont toujours dû trancher sans jamais vraiment le pouvoir : combien coûte réellement la livraison de cette valeur à ce client ?
Une fois cette réponse en main, la stratégie de pricing cesse d'être un exercice de devinette. Elle devient un avantage compétitif.
La question à poser lors de votre prochaine revue pricing
Avant de débattre des paliers de packaging ou du gating des fonctionnalités, posez une question préalable : savons-nous vraiment ce que coûte le fait de servir chaque client, chaque plan, chaque fonctionnalité ?
Si la réponse passe par des tableurs et des estimations, le modèle de pricing repose sur des fondations qui ne tiendront pas à mesure que le produit passera à l'échelle.
Partez de la réalité des coûts. Tout le reste en découle.
Attribute™ relie les coûts d'infrastructure cloud et IA aux clients, aux produits et aux fonctionnalités à partir de données runtime, sans tagging. Découvrez son fonctionnement pour les équipes pricing.