Créer un SaaS : ce qu’il faut trancher avant

Avant la première version, il faut décider qui paie, quel travail le logiciel fait vraiment, et ce qu’on laisse de côté. Ces trois décisions sont plus utiles qu’une longue liste de fonctions.

Qui paie

Une première version sert à vérifier un usage avec de vraies personnes. Ce n’est pas le produit complet.

Quand on cherche à créer un SaaS, on pense vite aux écrans, aux fonctionnalités, à la stack technique ou au nom. Ces sujets viendront, mais ils ne disent pas encore si quelqu’un voudra utiliser et payer le produit.

La première décision est plus directe : qui paie si le problème est résolu ?

Pas “les entreprises”. Pas “les équipes”. Pas “les utilisateurs”. Une personne précise, avec une responsabilité précise, un problème assez fréquent, et une raison de changer sa façon de faire.

Une phrase utile ressemble à ceci : “La responsable des opérations d’un réseau de cabinets paie parce qu’elle perd du temps à consolider les demandes entrantes.” Ou : “Le dirigeant d’une agence de quinze personnes paie parce que les validations client lui retombent dessus chaque semaine.”

Ce n’est pas encore du marketing. C’est une vérification de réalité. Si vous ne pouvez pas nommer cette personne, dire pourquoi ce sujet lui appartient et expliquer pourquoi elle aurait intérêt à essayer maintenant, la première version risque de répondre à une demande trop vague.

Un piège fréquent consiste à construire pour plusieurs profils sans qu’aucun ne soit vraiment responsable de l’achat. L’outil peut être utile à des utilisateurs quotidiens, mais si personne ne porte le problème au niveau budget, adoption ou arbitrage, le SaaS reste difficile à lancer.

Pour savoir comment créer un SaaS sans vous disperser, commencez donc par la personne qui pourrait décider d’un essai réel. Si la réponse implique tout un comité dès le premier jour, réduisez le périmètre.

Le travail que le logiciel fait

La deuxième décision consiste à écrire le travail que le logiciel fait en une seule phrase.

Une personne arrive avec une situation et repart avec un résultat. Cette phrase doit être concrète, courte et vérifiable.

“Améliorer la collaboration” ne suffit pas. “Aider les équipes à piloter leurs projets” non plus. Ces phrases donnent une direction, mais elles ne permettent pas de construire une première version.

Une phrase exploitable ressemble davantage à ceci : “Le responsable d’équipe reçoit une demande, la fait valider, puis retrouve son statut sans relancer tout le monde.” Ou : “Le gestionnaire centralise des documents entrants et sait lesquels sont complets sans vérification manuelle.”

Un seul travail. Si la phrase a besoin de “et aussi”, ce sont probablement deux produits, ou au moins deux versions différentes.

C’est souvent la partie la plus difficile. Beaucoup d’idées semblent proches. Beaucoup de cas d’usage paraissent légitimes. On veut ajouter un second profil, une vue de reporting, un module de configuration, une intégration “évidente”. Pourtant, développer un SaaS commence par refuser le second travail.

Le test est simple : une vraie personne peut-elle utiliser la première version ce mois-ci pour obtenir ce résultat, même si le reste se fait encore ailleurs ? Si oui, vous avez peut-être un bon point de départ. Si non, le travail est encore trop large.

Ce que la première version laisse de côté

Un MVP SaaS n’est pas une petite copie du produit complet. C’est la plus petite version qui permet aux bonnes personnes d’essayer l’usage principal.

La différence est importante. Une copie réduite cherche à représenter toutes les futures zones du produit, en plus petit. Un vrai MVP cherche à rendre un trajet possible de bout en bout : problème, action, résultat.

Cela implique d’écrire ce qui reste dehors.

Les rapports avancés restent dehors. Le deuxième type d’utilisateur reste dehors. Les réglages que personne n’a encore demandés restent dehors. Les cas rares restent dehors. Les automatisations qui rendront le produit plus confortable ensuite restent dehors, si l’usage principal peut déjà être essayé sans elles.

En pratique, un MVP d’application se définit autant par cette liste que par les fonctionnalités incluses.

Pour chaque idée, posez une question froide : est-ce qu’une vraie personne peut déjà essayer le travail principal sans cela ? Si oui, ce n’est pas pour maintenant. Si non, l’idée mérite peut-être de rester.

Cette discipline évite un problème courant : lancer une première version trop large, puis recevoir des retours trop dispersés pour apprendre quoi que ce soit. Plus le produit couvre de cas dès le début, plus les retours portent sur des préférences secondaires avant même que l’usage central soit validé.

Une première version solide ressemble rarement au produit rêvé. Elle ressemble plutôt à un passage étroit mais praticable. L’important est qu’une personne ciblée puisse l’emprunter jusqu’au bout.

Ce qu’il ne faut pas trancher maintenant

Certaines décisions donnent une impression d’avancement, mais arrivent trop tôt.

Le détail du nom, une grille de prix complète, une place de marché, une application mobile “parce que tout le monde en a une”, un programme partenaire, un système de rôles complexe : tout cela peut attendre que quelqu’un d’autre que vous ait utilisé la première version.

Cela ne veut pas dire qu’il faut improviser. Cela veut dire qu’il faut protéger l’énergie du projet. Avant usage réel, beaucoup de décisions restent théoriques. Elles seront meilleures avec quelques personnes en face, des objections concrètes, et des premiers retours sur le travail principal.

Le danger n’est pas seulement de mal construire. C’est aussi de trancher trop tôt des sujets qui dépendront de l’usage réel. Un prix, une promesse commerciale ou une segmentation peuvent changer quand vous découvrez qui ressent vraiment le problème et dans quel contexte.

À ce stade, le bon ordre n’est pas une feuille de route complète. C’est une séquence de décisions : payeur, travail, exclusions.

Une semaine de décisions

Avant de construire, prenez une semaine pour faire ce travail. Pas pour dessiner beaucoup d’écrans. Pas pour écrire un grand document produit. Pour vérifier que la première version a une base.

1. Écrivez qui paie, en une ligne.
2. Écrivez le travail, en une ligne.
3. Écrivez trois choses que la première version ne fera pas.
4. Trouvez cinq personnes qui correspondent au payeur.
5. Demandez-leur si elles utiliseraient la première version pour ce travail ce mois-ci.
6. Notez leurs mots exacts quand elles décrivent le problème.
7. Si elles décrivent un autre travail, changez la phrase avant de construire.

Le but n’est pas de récolter des compliments. Le but est de voir si ces personnes reconnaissent le problème comme étant le leur, si elles décrivent le même résultat que vous, et si elles voient une raison d’essayer vite.

Quand elles reformulent autrement, écoutez. Quand elles parlent d’un besoin voisin mais différent, resserrez. Quand elles ne sentent pas d’urgence, votre première version est peut-être encore trop large ou trop confortable.

Cette semaine donne une base plus utile qu’une longue liste de fonctionnalités. Elle aide ensuite à décider ce qui entre, ce qui sort, et ce qui attend.

La suite

Une fois les trois décisions écrites et vérifiées avec de vraies personnes, la construction peut commencer.

À partir de là, le travail devient plus simple à piloter. Vous savez pour qui vous construisez, quel résultat vous rendez possible, et ce que la première version laisse volontairement de côté.

Si vous en êtes à cette étape, Perfusion peut vous aider à transformer ces décisions en première version claire, testable et utile.