Le seul indicateur SaaS qui résiste quand le marché se durcit
Il existe un moment dans le cycle de vie de toute entreprise de logiciels par abonnement où le tableau de bord des métriques commence à ressembler à un symptôme plutôt qu'à un outil. Utilisateurs actifs quotidiens, taux d'ouverture des fonctionnalités, temps de session, adoption des modules, NPS trimestriel. Tout est mesuré. Tout s'affiche en vert. Et pourtant, les contrats ne se renouvellent pas.
Ce décalage entre activité et valeur n'est pas nouveau, mais il n'est pas non plus corrigé à la vitesse que la pression du marché exige. À un moment où les acheteurs en entreprise appliquent un vrai scrutin à chaque ligne de leur budget technologique, la question que beaucoup de fournisseurs de logiciels évitent de se poser honnêtement est celle-ci : leurs clients gagnent-ils de l'argent grâce à leur plateforme, ou se contentent-ils simplement d'utiliser un outil que personne n'a encore eu le temps d'annuler ?
David Pickard, directeur mondial de Phonexa, a publié récemment dans le Forbes Technology Council une thèse qui résume ce décalage avec une question d'auto-évaluation : si vous étiez votre propre client, utiliseriez-vous votre logiciel ? La provocation est efficace parce que le diagnostic qui la sous-tend est précis. Le secteur SaaS a construit une culture de métriques d'activité qui fonctionne bien pour les roadmaps internes et les présentations aux investisseurs, mais qui présente une corrélation de plus en plus faible avec l'expérience économique du client.
Quand la métrique de succès est interne
Le problème n'est pas de mesurer. C'est ce qu'on choisit de mesurer, et pourquoi.
Les métriques de vanité — utilisateurs actifs quotidiens, volume de connexions, nombre de fonctionnalités adoptées — ont une fonction légitime dans les premières phases d'un produit : elles indiquent si le logiciel est utilisé, si l'onboarding fonctionne, s'il y a suffisamment d'engagement pour justifier un cycle de feedback. L'erreur se produit lorsque ces métriques migrent au centre du tableau de bord exécutif sans avoir effectué la transition vers des métriques de résultat économique.
Un client peut générer un schéma d'utilisation élevé et, dans le même temps, générer moins d'argent qu'avant la mise en œuvre de la plateforme. Le logiciel lui consomme du temps de configuration, nécessite des intégrations que son équipe ne maîtrise pas, produit des rapports que personne ne sait interpréter correctement. Le taux de rétention semble sain pendant des mois parce que les processus d'annulation sont lents et que l'inertie organisationnelle est puissante. Mais le contrat ne se renouvelle pas, et lorsqu'il faut expliquer pourquoi, la réponse ne figure pas dans le tableau de bord des métriques internes.
Cela a une conséquence moins évidente : les équipes produit commencent à optimiser ce qui est mesuré. Si l'indicateur de succès est l'adoption des fonctionnalités, on ajoute des fonctionnalités. Si c'est le temps de session, on conçoit des parcours qui retiennent l'utilisateur à l'intérieur de la plateforme même si ce n'est pas nécessaire. Si c'est le NPS, on gère la perception au moment de l'enquête. L'optimisation vers des métriques d'activité produit des produits plus complexes et des clients avec un retour réel moindre. Non pas par mauvaise intention, mais parce que l'architecture des incitations pointe dans une direction différente de celle dont le client a besoin.
L'argument de Pickard sur ce qu'il appelle le « vanity development » — construire des fonctionnalités qui ne sont pas motivées par les besoins des clients, mais par les tendances du marché, la pression concurrentielle ou l'affinité technologique interne — décrit exactement ce mécanisme. Le résultat est une plateforme qui accumule des couches de complexité sans qu'aucune d'entre elles ne fasse bouger de manière démontrable les revenus, l'efficacité ou la réduction des coûts du client.
La structure d'incitations que personne n'audite
Derrière la prolifération des métriques de vanité, il n'y a pas d'ingénuité. Il y a une structure d'incitations qui les produit de manière systématique et qui opère sur au moins trois niveaux simultanés.
Le premier est le cycle de financement. Les tours de table en phase précoce et intermédiaire d'une entreprise SaaS ont historiquement été liés à des métriques de croissance des utilisateurs, au taux de croissance des revenus récurrents mensuels et aux projections d'expansion de marché. Ces métriques sont capturables avec des données d'activité. Le retour économique du client, en revanche, est plus lent à mesurer, nécessite l'accès à des données que le client ne partage pas toujours, et n'apparaît pas proprement dans une pitch deck de Série B. La conséquence est prévisible : les équipes optimisent pour les indicateurs qui font bouger le prix du prochain tour, pas nécessairement pour ceux qui reflètent la valeur réellement délivrée.
Le deuxième niveau est la structure des équipes de Customer Success. Pendant des années, cette fonction a été conçue comme un support technico-relationnel : résoudre les problèmes d'implémentation, répondre aux tickets, gérer l'onboarding. Dans ce modèle, l'indicateur de performance de l'équipe était la satisfaction du client et le taux de rétention, et non l'expansion des revenus du client. Cela crée une équipe bien positionnée pour détecter les frictions, mais sans les outils ni le mandat nécessaires pour quantifier l'impact financier de la plateforme sur le business du client.
Le troisième niveau — et le plus résistant au changement — est la distance entre l'équipe produit et le client qui opère au quotidien. Les décisions de roadmap s'alimentent d'entretiens utilisateurs, d'analyses comportementales au sein du produit et de benchmarking concurrentiel. Elles s'alimentent rarement des états financiers du client, de ses métriques d'efficacité opérationnelle, ou d'une évaluation honnête de la question de savoir si la plateforme a réduit son coût par transaction ou augmenté son taux de conversion. Cette distance produit des fonctionnalités qui résolvent des problèmes perçus, mais pas des problèmes économiques.
Pickard propose comme solution à cela ce qu'il décrit comme « vanillifier » les exigences : lorsqu'un client demande une fonctionnalité spécifique, l'équipe produit doit généraliser cette demande pour qu'elle s'adapte à d'autres segments et soit suffisamment flexible pour des cas d'usage futurs. Le principe est correct, mais il existe une condition préalable que l'argument ne résout pas directement : pour savoir si une fonctionnalité généralisée crée de la valeur, il est nécessaire de disposer d'une définition opérationnelle de ce que signifie la valeur pour le client. Sans cette définition, la généralisation peut produire de la complexité de la même manière que la copie des concurrents.
Le retour du client comme indicateur financier de la santé du fournisseur
Il existe une raison structurelle pour laquelle le retour du client finit par être le meilleur indicateur avancé de la santé financière du fournisseur SaaS, et il vaut la peine de la rendre explicite.
Les modèles d'affaires par abonnement dépendent de deux variables : la rétention des revenus existants et l'expansion au sein de la base de clients actuelle. La Rétention Nette des Revenus (NRR), l'un des indicateurs les plus surveillés dans le secteur, mesure précisément cela : si les revenus provenant des clients actifs croissent, se maintiennent ou se contractent après intégration des annulations, des déclassements et des expansions. Un NRR supérieur à 100 % indique que la base de clients existante est en train d'étendre son utilisation, ce qui constitue généralement l'indicateur de croissance le plus efficace, car il évite le coût d'acquisition de nouveaux clients.
Ce chiffre ne se maintient pas sans retour économique démontrable pour le client. Un client qui ne génère pas de revenus incrémentaux, qui n'économise pas de coûts ou qui ne gagne pas en efficacité opérationnelle grâce à la plateforme n'a pas de raison économique d'élargir son contrat. Il peut renouveler par inertie pendant un ou deux cycles, mais la logique d'expansion — qui est ce qui permet à un NRR de dépasser le seuil des 100 % — exige que le client ait associé le logiciel à un résultat positif pour son activité.
La chaîne causale est alors précise : retour du client → rétention des contrats → expansion des dépenses → NRR sain → valorisation du fournisseur. Mesurer uniquement les maillons intermédiaires de cette chaîne — rétention et expansion — sans auditer le maillon initial produit une illusion de solidité que le marché corrige lors du cycle de renouvellement suivant.
Pickard pointe dans la même direction lorsqu'il souligne que dans les modèles de revenus basés sur l'usage, la croissance des dépenses du client sur la plateforme devrait être le symptôme que ce client génère davantage de revenus grâce au système. Si le client double ses dépenses sur la plateforme, son bénéfice devrait croître dans un multiple plus grand. Si cela ne se produit pas, le modèle ne délivre pas de valeur : il capture une portion croissante d'un revenu qui ne croît pas.
Les services gérés que mentionne l'article fonctionnent comme un accélérateur de ce cycle lorsqu'ils sont bien conçus : ils réduisent le temps entre la mise en œuvre et le retour démontrable, ce qui à son tour accélère la décision du client d'étendre son usage. Le risque — que l'article ne thématise pas explicitement mais qui est bien réel — est que les services gérés deviennent un palliatif pour des plateformes qui ne sont pas suffisamment intuitives ou qui nécessitent trop d'intervention pour produire des résultats. Dans ce cas, la couche de services subventionne indéfiniment une complexité que le produit aurait dû éliminer.
Ce qui précède le chiffre visible
L'argument consistant à tout centrer sur le retour du client est correct dans son diagnostic, mais sa mise en œuvre se heurte à une condition préalable que peu d'entreprises SaaS ont résolue : comment mesurer ce retour de manière systématique et non anecdotique.
Les cas de succès clients existent dans toutes les entreprises de logiciels. Ils constituent le carburant des présentations commerciales et des pages de témoignages. Le problème est qu'un cas de succès narré après coup a une valeur commerciale, mais une utilité opérationnelle limitée. Il ne dit pas ce qui a produit le retour, dans quelles conditions il se reproduirait, ni quelles variables l'ont rendu possible chez ce client et pas chez d'autres ayant des profils similaires.
Construire une méthodologie de mesure du retour client qui soit comparable entre segments, qui se mette à jour en temps réel et qui alimente les décisions produit et de Customer Success nécessite un accès à des données que le client ne partage souvent pas par défaut. Cela nécessite que la plateforme soit instrumentée pour capturer non seulement le comportement au sein du système, mais aussi ses effets en aval sur les indicateurs d'activité du client. Et cela requiert que les équipes produit et Customer Success parlent le même langage économique que les acheteurs exécutifs qui évaluent le renouvellement.
La friction que personne ne comptabilise dans le débat sur les métriques de vanité est précisément celle-là : le problème n'est pas que les entreprises SaaS ne souhaitent pas mesurer le retour client. C'est que l'infrastructure de données, les accords d'échange d'informations avec les clients et la capacité analytique pour convertir ces données en signaux de roadmap ne sont pas construits chez la majorité des fournisseurs de taille intermédiaire. Changer le tableau de bord exécutif est simple. Changer l'architecture d'information qui alimente ce tableau de bord est le travail qui prend des années.
Cela n'invalide pas la thèse de Pickard. Cela la renforce. Mais cela place le vrai problème là où il doit être : non pas dans le choix de ce que l'on mesure, mais dans la capacité à mesurer ce qui compte de manière systématique. Les entreprises SaaS qui parviendront à construire cette capacité en premier — y compris les accords avec les clients qui permettent la visibilité sur leurs résultats — disposeront d'un avantage qui ne se réplique pas simplement en changeant le nom d'un indicateur dans le rapport trimestriel.
Le tableau de bord des métriques ne change pas si la plateforme ne génère pas de retour démontrable. Mais l'architecture qui produit ce tableau de bord — et les équipes capables de l'interpréter avec honnêteté — constitue l'investissement qui sépare les fournisseurs qui survivent aux renégociations budgétaires de ceux qui n'arrivent pas au prochain cycle de renouvellement.
