Le guide du fondateur sur les modèles de tarification SaaS

Les fondateurs passent des semaines à débattre de la liste de fonctionnalités de leur MVP, puis fixent le prix en un après-midi, juste avant le lancement. C'est l'inverse qu'il faudrait faire. Les modèles de tarification SaaS déterminent combien de revenus chaque segment de clientèle génère, et si votre unit economics tient la route après les dix premiers clients payants. Nous avons couvert la partie technique dans notre guide MVP SaaS pour startups et son coût dans notre répartition des coûts de développement SaaS. Ce guide couvre le chiffre qui finance les deux: combien facturer, et comment éviter les erreurs qui vous enferment dans un mauvais prix pendant un an.

Beaucoup considèrent la tarification comme un problème de croissance, à régler une fois le product-market fit trouvé. Cet instinct coûte cher aux fondateurs. Le prix de lancement détermine quels clients s'auto-sélectionnent, et la marge de manœuvre qu'il vous reste pour baisser le prix plus tard sans habituer les acheteurs à attendre une promotion. Un MVP SaaS avec le mauvais modèle de tarification peut ressembler à un problème produit alors qu'il s'agit en réalité d'un problème de prix. Une tarification à l'usage sur un produit que personne ne comprend encore génère des factures imprévisibles, et des factures imprévisibles font fuir les premiers utilisateurs rapidement. La plupart des fondateurs SaaS B2B avec qui nous travaillons traitent la tarification comme une décision de la semaine du lancement, au même titre que le nom de domaine ou le logo. Traitez-la plutôt comme une partie du périmètre du MVP: votre métrique de valeur influence votre modèle de données, et même les fonctionnalités que vous construisez en premier.

Demandez à cinq fondateurs SaaS comment tarifer un produit SaaS et vous obtiendrez cinq approches différentes, la plupart empruntées à l'outil qu'ils utilisaient juste avant. En pratique, presque tous les modèles de tarification SaaS en production aujourd'hui sont une variation de cinq schémas: le forfait, les paliers, l'usage, le par utilisateur et le freemium. Aucun n'est universellement le bon choix. Chacun tarife une chose différente, et chacun convient à un type d'acheteur différent. Voici comment les cinq se comparent avant de vous engager sur l'un d'eux pour votre MVP:

Le tableau ci-dessus montre la logique de chaque modèle. La question la plus difficile est de savoir lequel convient à un produit vieux de huit semaines avec une douzaine de clients payants. Le forfait l'emporte sur la simplicité: un seul prix, facile à expliquer en appel commercial, facile à facturer sans toucher à un système de mesure. C'est le bon point de départ si votre produit fait bien une seule chose. La tarification par paliers laisse de la place pour grandir sans ajouter trop de complexité. Deux ou trois paliers, chacun limitant un ensemble de fonctionnalités ou un plafond d'usage, permettent de capter davantage de valeur auprès des clients qui en ont besoin. Le piège, c'est la prolifération des paliers: cinq paliers aux fonctionnalités qui se chevauchent déroutent les acheteurs plus qu'ils ne les convertissent. La tarification à l'usage aligne le prix sur la valeur mieux qu'aucun autre modèle, quand elle fonctionne, même si présenter une facturation à la consommation à un acheteur novice demande davantage de pédagogie. La tarification par utilisateur est le modèle le plus facile à prévoir en matière de revenus, car les effectifs varient rarement d'un mois à l'autre. Elle convient mal quand la valeur de votre produit n'a rien à voir avec le nombre de personnes connectées, et les acheteurs le remarquent vite.

Les fondateurs emploient freemium et essai gratuit comme des synonymes, à tort. Un essai gratuit donne un accès limité dans le temps au produit complet, généralement 14 à 30 jours, pour prouver sa valeur avant qu'une carte ne soit débitée. Le freemium est un palier gratuit permanent qui coexiste avec les offres payantes, pensé pour convertir lentement une partie d'une base d'utilisateurs plus large. Les essais gratuits conviennent aux produits avec un time-to-value court. Le freemium convient aux produits à effets viraux ou de réseau, où les utilisateurs gratuits créent aussi de la valeur pour les utilisateurs payants, comme un outil de planification dont les invités n'ont jamais besoin de leur propre compte. Voici l'arbitrage honnête: le freemium au stade MVP coûte cher avant de rapporter. Vous payez l'infrastructure et le support d'utilisateurs qui ne paieront peut-être jamais, sans assez de volume pour prouver que le calcul de conversion fonctionne. Un essai gratuit limité dans le temps bat généralement le freemium pour une première version. Ajoutez le freemium plus tard, une fois que vous pouvez modéliser la conversion du gratuit vers le payant au lieu de deviner.

Une métrique de valeur est l'unité sur laquelle vous basez votre prix: utilisateurs, appels API, enregistrements stockés, projets actifs. Choisissez la mauvaise et vous passerez un an à vous battre contre votre propre tarification au lieu de construire votre produit. Voici le test que nous faisons passer aux fondateurs: la métrique croît-elle naturellement à mesure que le client obtient plus de valeur? Facturer par utilisateur fonctionne bien pour un outil de gestion de projet, car plus de collaborateurs signifie plus de valeur de coordination. Facturer par utilisateur fonctionne mal pour un outil d'analyste solo, où la valeur vient du résultat produit plutôt que du nombre de personnes. Une bonne métrique de valeur est aussi lisible: un client doit pouvoir prédire la facture du mois prochain sans écrire au support. Un mélange de stockage, d'appels API et d'utilisateurs pondérés par palier d'usage capture la valeur plus précisément sur le papier, et déroute tous les acheteurs qui essaient de le lire. Une métrique principale, et éventuellement un plafond d'usage, suffit pour la plupart des produits en phase de démarrage. En empiler trois ou quatre ajoute une complexité de facturation que votre temps d'ingénierie serait mieux employé ailleurs.

Les décisions de tarification se transforment vite en décisions d'ingénierie. Un modèle par utilisateur nécessite un moyen de compter les utilisateurs actifs par compte. Un modèle à l'usage nécessite une infrastructure de mesure qui suit la consommation par tenant, avec précision et en temps réel. La plupart des MVP SaaS B2B sont multi-tenant dès le premier jour, votre modèle de tarification doit donc tenir compte de la façon dont les tenants partagent l'infrastructure. Un plafond d'usage par tenant exige que votre modèle de données suive l'usage au niveau du tenant, car un même compte d'entreprise héberge souvent plusieurs équipes. Nous détaillons les modèles d'isolation dont cela dépend dans notre guide d'architecture multi-tenant. Stripe Billing, Paddle et Chargebee prennent désormais tous en charge la facturation à l'usage et par utilisateur, ce qui supprime la plupart des raisons de construire votre propre système de mesure. Ce qu'ils ne suppriment pas, c'est le problème des données: votre produit doit quand même émettre des événements d'usage précis par tenant, sinon vos factures sortent fausses.

Quelques erreurs reviennent dans presque toutes les discussions sur la tarification que nous avons avec des fondateurs en phase de démarrage. Sous-tarifer par peur arrive en tête de liste. Les fondateurs craignent qu'un prix plus élevé ne fasse fuir leurs premiers clients, alors ils fixent un niveau qui couvre à peine les coûts de support, puis se sentent coincés une fois que ces clients se sont habitués à l'ancien chiffre. Tarifez en fonction de la valeur livrée à votre client idéal. Le confort n'est pas une stratégie de tarification. Trop de paliers arrive juste après. Trois paliers suffisent largement pour un MVP; cinq ou six transforment une décision de deux minutes sur la page tarifs en une décision de dix minutes, et les acheteurs déroutés partent au lieu de convertir. Copier la page tarifs d'un concurrent est un autre raccourci. Sa tarification reflète sa structure de coûts et son stade de développement, construite pour une entreprise différente de la vôtre. Un concurrent qui a trois ans d'avance sur vous peut se permettre un palier gratuit qui coulerait votre économie dès le troisième mois. Ne pas préserver les tarifs de vos clients existants coûte aussi la confiance: augmenter les prix sans prévenir, et même une hausse juste passe alors pour une manœuvre déloyale.

Le prix n'est pas une décision du jour de lancement que vous devez défendre pour toujours. Traitez votre premier chiffre comme une hypothèse, fondée sur de la recherche plutôt que copiée sur la page d'un concurrent, et restez prêt à vous tromper. Avant de finaliser un prix, demandez à 10 à 15 personnes de votre segment cible ce qu'elles s'attendraient à payer, et à partir de quel niveau ce serait trop cher. Vous n'obtiendrez pas un chiffre précis de cette façon, les gens tarifient mal les choses dans l'abstrait, mais vous saurez si vous êtes dans la bonne fourchette. Une fois en ligne, surveillez ensemble la conversion essai-vers-payant et le time-to-value. Un essai qui convertit bien mais met une éternité à s'activer révèle généralement un problème d'onboarding, traité dans notre guide d'onboarding SaaS. Un essai qui s'active vite mais convertit mal pointe généralement vers un problème de prix. Lorsque vous augmentez vos prix, conservez le tarif de vos clients existants et augmentez d'abord celui des nouveaux clients. Faire évoluer son prix est normal. Le faire évoluer sans raison visible pour les clients érode la confiance.