Vos plans SaaS ne devraient pas être des plans tarifaires

Cette présentation rassure les équipes internes, parce qu’elle donne l’impression d’être exhaustive. Mais elle produit un effet secondaire immédiat : elle invite le client à comparer ligne par ligne. Si votre plan est présenté comme une somme de fonctionnalités, le client va comparer cette somme à celle du concurrent.

Il va aussi commencer à négocier :

“Je n’ai pas besoin de cette fonctionnalité, pourquoi payer plus cher ?”

La discussion descend alors au niveau de l’unité fonctionnelle, au lieu de rester au niveau du résultat attendu. Les features comptent. Elles sont nécessaires. Mais elles sont le véhicule de la valeur, pas la valeur elle-même. Elles montrent comment la promesse s’incarne dans le produit. Elles ne devraient pas remplacer le récit de valeur.

Le tableau de features devrait donc arriver à la fin. Il sert à prouver, détailler, objectiver. Il ne devrait pas être la structure principale du discours.

Prix, offre, plan : trois rôles différents

Une partie de la confusion vient du vocabulaire. On parle de “plans tarifaires”, comme si le prix était le sujet principal. Il ne l’est pas.

Le prix est le moyen d’accéder à la valeur. Si la valeur est bien comprise, le prix n’est pas une fin en soi : il devient un arbitrage économique.

L’offre, elle, est la promesse faite à une cible. Elle relève du positionnement produit. Elle dit à qui l’on parle, quel problème on prend au sérieux, quelle vision du travail ou de l’organisation le produit porte.

Le plan est autre chose : c’est un niveau d’accès à cette valeur. Il accompagne un client dans sa maturité d’usage, dans ses contraintes et dans sa capacité à tirer davantage du produit. Un bon plan ne devrait donc pas être défini par “ce qu’il contient” seulement, mais par “ce qu’il permet d’atteindre”.

Pourquoi trois plans reviennent partout

La majorité des SaaS finissent avec trois plans principaux. Ce n’est pas un hasard.

Avec deux offres, par exemple Basic à 20 euros et Pro à 50 euros, le client doit répondre directement à une question :

“Est-ce que Pro vaut vraiment 30 euros de plus ?”

Avec trois offres, la comparaison change. Basic, Pro, Enterprise : le client ne compare plus seulement deux prix, il compare une architecture de choix.

Le plan intermédiaire devient souvent le choix raisonnable. Il n’est ni trop limité, ni excessif. C’est l’effet de compromis. Le plan Enterprise, lui, peut servir d’ancre de prix : si l’offre la plus haute est à 500 euros par mois ou “sur devis”, le plan Pro paraît soudain plus accessible.

Mais Enterprise ne sert pas seulement d’ancre. Dans le B2B, il ouvre aussi la porte à une autre mécanique de vente : devis, contrat, DPA, SLA, négociation, achats, juridique, sécurité. Un directeur informatique ou un service achat ne sort pas toujours une carte bancaire sur une page web.

Dans beaucoup de grilles, les rôles implicites sont donc assez clairs :

Le risque serait de s’arrêter là et de croire que la psychologie du choix suffit. Elle aide à comprendre la forme des grilles. Elle ne suffit pas à construire une offre saine. Le plan cible doit réellement ouvrir une valeur supérieure.

Les plans ne sont pas des segments

Une erreur fréquente consiste à faire correspondre chaque plan à un segment différent : le plan A pour les indépendants, le plan B pour les PME, le plan C pour les grands groupes. Cette logique semble pratique. Elle est souvent dangereuse.

Le segment vient du positionnement produit, pas du plan. Le produit porte une vision : une manière d’organiser le travail, de faire circuler l’information, de distribuer les responsabilités, de contrôler ou non les accès. Cette vision ne peut pas changer radicalement d’une colonne tarifaire à l’autre.

Si chaque plan vise un segment différent, l’entreprise se retrouve avec plusieurs produits implicites sous une même marque. Le site web parle à plusieurs publics contradictoires. Les réseaux sociaux hésitent. Les sales racontent plusieurs histoires. Le produit accumule des arbitrages incompatibles. Le support et l’accompagnement doivent servir des attentes qui ne relèvent pas de la même promesse.

Si vous avez deux segments réellement différents, il faut peut-être deux produits. Ils peuvent reposer sur la même base technologique. Mais ils doivent avoir deux positionnements, deux communications, deux promesses explicites.

Attention toutefois : partager une base technologique ne résout pas tout. Deux produits peuvent coexister lorsqu’ils restent proches dans leur ADN : par exemple un produit simplifié et un produit plus complet. Le problème apparaît lorsque les deux produits portent des ADN trop éloignés.

Une équipe doit “matcher” avec l’ADN du produit qu’elle construit : ses convictions, ses arbitrages et sa manière de prioriser en dépendent. Si deux produits demandent deux visions trop différentes, l’équipe ne matche plus vraiment avec les deux.

Par exemple, un produit fondé sur l’ouverture de l’information et un produit fondé sur le contrôle strict, les workflows lourds et la compartimentation ne demandent pas seulement deux interfaces différentes ; ils demandent deux visions différentes du travail.

Les plans comme carte d’adoption

Plutôt que de voir les plans comme une échelle tarifaire, il faut les voir comme une carte d’adoption.

Le plan A n’est pas nécessairement “le petit client”. Il peut représenter l’entrée dans l’usage : découvrir, tester, apprendre, commettre les premières erreurs, comprendre la première valeur.

Le plan B n’est pas seulement “plus de features”. Il correspond souvent au moment où le client gagne en maîtrise. Il ne subit plus le produit. Il anticipe. Il structure ses pratiques. Il commence à créer une stratégie autour de l’usage.

Le plan C, Enterprise, n’est pas toujours la suite naturelle de B. Il peut apparaître très tôt, dès que la culture de l’entreprise acheteuse impose ses contraintes : sécurité, conformité, auditabilité, gouvernance, achats, IT, maîtrise de l’information.

Les chemins ne sont donc pas toujours linéaires. Un client peut passer de A à B. Il peut passer de A à C si les contraintes d’entreprise apparaissent vite. Il peut aussi passer de A à B puis C : adoption locale, généralisation, intervention de l’IT.

Un plan n’est pas une marche tarifaire. C’est une situation d’adoption.

Le plan A : créer assez de valeur, puis assez de tension

Si le plan B est la vraie cible commerciale, le plan A pose un problème délicat. Il doit être assez utile pour faire comprendre la valeur du produit. Mais il ne doit pas être tellement complet qu’il bloque toute progression vers B.

Il faut donc construire une frustration contrôlée. Cette frustration peut prendre plusieurs formes : une fonctionnalité absente, une fonctionnalité disponible seulement à l’essai, un quota d’utilisation, une limite de volume, une version restreinte qui permet de faire une partie du travail mais pas tout.

La limite est claire : la frustration ne doit pas casser l’usage. Si le plan A est trop pauvre, le client ne comprend jamais la valeur. S’il est trop frustrant, il perd confiance. S’il est trop généreux, il ne voit pas pourquoi il passerait au plan supérieur.

Le bon plan A ne bloque pas la valeur. Il rend visible la prochaine valeur.

Enterprise : le produit rendu acceptable par l’organisation

Le plan Enterprise est souvent mal compris. Il n’est pas simplement “le plan avec toutes les features”. Il peut contenir des éléments de valeur métier : support avancé, support téléphone, capacités réservées, accompagnement renforcé. Mais sa logique dominante est ailleurs.

Enterprise rend le produit acceptable, gouvernable, contrôlable, auditable et achetable par une grande organisation. Ces exigences ne viennent pas d’abord du SaaS. Elles viennent du client.

En Enterprise, l’entreprise acheteuse impose souvent des conditions : compliance, sécurité, ISO 27000, auditabilité, politiques internes, validation IT, achats, juridique. Il faut ici distinguer les utilisateurs métiers de l’entreprise acheteuse.

Les utilisateurs veulent obtenir la valeur du produit. L’entreprise veut réduire ses risques, contrôler, contractualiser, auditer, gouverner. C’est le rôle du whole product : tout ce qui permet au produit d’être adopté dans son environnement réel.

Le produit ne se limite plus à ses fonctionnalités. Il inclut les garanties, l’administration, la sécurité, le support, l’intégration, les processus de déploiement, les contrats. Mais ce whole product a une limite : il ne doit pas trahir l’ADN du produit.

Un produit ouvert, par exemple un wiki, peut fournir des rapports hebdomadaires à l’entreprise sans cesser d’être ouvert. Ce reporting se superpose au produit.

En revanche, si l’entreprise demande d’ajouter des workflows lourds, de la compartimentation et des permissions qui transforment un produit ouvert en produit de contrôle, l’éditeur doit choisir. Il peut accepter la compromission, avec l’impact que cela aura sur l’ADN produit. Ou refuser.

Enterprise ne vend pas seulement plus de produit. Il vend la possibilité pour une organisation complexe d’accepter le produit.

Freemium : un pari sur la culture d’adoption

Le freemium n’est pas bon ou mauvais en soi. Il dépend de la culture d’adoption du marché.

Il fonctionne quand des utilisateurs peuvent expérimenter seuls, comprendre la valeur, créer un usage et devenir champions internes. Notion est un bon exemple : l’usage personnel peut précéder l’usage professionnel. Un utilisateur commence seul, puis défend le produit dans son équipe, puis l’usage s’étend.

Mais tous les produits ne peuvent pas suivre ce chemin. Personne n’installe spontanément un logiciel de maintenance industrielle chez soi. Un CRM n’a pas toujours de sens hors contexte collectif.

Dans une organisation très bureaucratique, où l’on ne peut pas installer un outil sans validation IT ou sécurité, le freemium peut produire un engagement proche de zéro. Il y a aussi une question de temps. Des utilisateurs débordés peuvent ouvrir un compte gratuit et ne jamais vraiment tester.

Le freemium suppose de l’autonomie, du temps, le droit d’expérimenter et une culture de l’initiative. Le freemium n’est pas un prix. C’est un pari sur la capacité du marché à adopter seul.

Acheter n’est pas adopter

Le B2B ajoute une autre difficulté : un produit peut être acheté sans être adopté, et adopté officiellement sans être réellement utilisé.

Il peut exister des champions internes chargés de mettre en place un outil, mais déconnectés de la réalité des équipes. L’entreprise peut aussi refuser de payer l’accompagnement, puis s’étonner que le produit ne décolle pas.

Le SaaS lui-même peut se tromper en croyant qu’il suffit de vendre des abonnements. Surtout en B2B, vendre ne suffit pas toujours.

Il faut parfois accompagner : par des CSM, de l’onboarding, des vidéos, des contenus, des templates, des programmes de formation, des parcours d’adoption.

Cette distinction est essentielle pour construire les plans. Un plan ne doit pas seulement rendre le produit achetable. Il doit rendre la valeur atteignable.

Une méthode pour construire ses plans

Une grille de plans ne devrait pas commencer par la question :

“Quelles features met-on dans chaque colonne ?”

Elle devrait commencer par une méthode plus simple.

1. Définir le segment et la promesse produit

À qui parle-t-on ? Quelle vision du travail ou de l’organisation porte le produit ? Quelle promesse est faite à cette cible ?

2. Identifier la valeur recherchée

Il n’y a pas un seul chemin pour y arriver. On peut partir des jobs to be done, d’une connaissance fine du contexte client, d’une mesure d’usage, d’une feature qui fonctionne et dont il faut comprendre ce qu’elle révèle.

Les chemins varient, mais la destination est unique : la valeur.

3. Décrire les situations d’adoption

Qu’est-ce qu’un client en entrée d’usage ? Qu’est-ce qu’un client qui gagne en maîtrise ? Quelles contraintes font basculer vers Enterprise ?

4. Construire les plans comme des niveaux d’accès à la valeur

A doit permettre d’entrer. B doit rendre visible la maîtrise. C doit rendre le produit acceptable par l’organisation.

5. Vérifier le plan A

Est-il assez utile ? Est-il trop complet ? La frustration qu’il crée donne-t-elle envie d’aller vers B ou détruit-elle la confiance ?

6. Vérifier Enterprise

Ce qui est ajouté relève-t-il du whole product ou modifie-t-il le core product ? Est-ce imposé par l’entreprise acheteuse ? Est-ce superposé au produit ou est-ce que cela dénature son ADN ?

7. Tester avec les quatre risques de Marty Cagan

Le client va-t-il acheter ? L’utilisateur va-t-il utiliser ? L’équipe peut-elle construire ? L’entreprise peut-elle soutenir économiquement et stratégiquement cette offre ?

Enfin seulement : construire le tableau de features. Ce tableau est nécessaire. Il permet de vérifier, comparer, objectiver.

Mais il doit venir après le récit de valeur. Il doit être la dernière page, pas le point de départ.

Conclusion : arrêter de vendre des plans tarifaires

Un bon plan n’est pas un prix. Un bon plan n’est pas une liste de features.

Un bon plan aide le client à comprendre où il en est, quelle valeur il peut atteindre et quelles conditions rendent cette valeur accessible.

Dans le SaaS B2B, les plans devraient raconter une progression : entrer dans l’usage, gagner en maîtrise, rendre le produit acceptable par l’organisation.

Les plans tarifaires ne devraient pas vendre le prix du logiciel. Ils devraient vendre le prochain niveau de valeur auquel le client est prêt à accéder.