La question qui plombe le plus de projets SaaS n'est pas « comment le construire », mais « par quoi commencer ». Tout paraît indispensable, alors on veut tout livrer, et le projet s'étire jusqu'à ne jamais sortir. Le MVP n'est pas une version au rabais : c'est une décision de tri, et ce tri suit une règle simple qu'on applique sur chaque projet.
- Un MVP SaaS tient en trois blocs : la fonction centrale, l'authentification et le paiement.
- Le test de tri : sans cette fonctionnalité, un premier client peut-il quand même payer et obtenir la valeur ?
- Le back-office complet, les exports et les réglages avancés attendent presque toujours.
- Les fonctions reportées ne sont pas abandonnées : elles sont priorisées sur les usages réels.
Le seul test qui tranche#
Face à une liste de fonctionnalités, on ne discute pas chacune pendant des heures. On la passe par une seule question : sans elle, un premier utilisateur peut-il payer et obtenir ce qu'on lui a promis ?
Si la réponse est oui, la fonctionnalité attend. Si c'est non, elle entre dans le MVP. Ce test paraît brutal, mais il tranche la grande majorité des arbitrages en quelques secondes, et il sort les débats du registre de l'opinion (« moi je trouve ça important ») pour les ramener sur un critère objectif.
Les trois blocs qui entrent toujours#
Quel que soit le SaaS, trois briques passent ce test à chaque fois, parce que sans elles le produit ne peut littéralement pas fonctionner :
- La fonction centrale. Celle qui justifie l'existence du produit. Pour un outil de facturation, c'est créer et envoyer une facture, pas le tableau de statistiques.
- L'authentification. Créer un compte, se connecter, accéder à ses propres données. Sans elle, pas d'utilisateur.
- Le paiement. Encaisser un abonnement. C'est ce qui sépare un produit d'une démo, et c'est le bloc qu'on sous-estime le plus, comme on le détaille dans ce qu'on livre dans chaque SaaS.
Au-delà de ces trois, chaque ajout doit gagner sa place au test.
Ce qu'on reporte presque toujours#
Certaines fonctionnalités semblent indispensables et ne le sont jamais au lancement. Les candidates au report les plus fréquentes :
- Le back-office d'administration complet. Les premières semaines, gérer les comptes à la main ou directement en base coûte moins cher que de construire une interface d'admin que vous serez seul à utiliser.
- Les statistiques et exports. Utiles plus tard, inutiles tant que vous n'avez pas assez de données pour qu'elles veuillent dire quelque chose.
- Les réglages avancés et la personnalisation. Un utilisateur qui découvre votre produit n'a pas besoin de trente options. Il a besoin que la fonction centrale marche.
- Les intégrations secondaires. Chaque connexion à un service tiers ajoute du travail et des cas limites. On n'intègre que ce qui est indispensable au premier client.
Reporter n'est pas abandonner. Ces fonctions sont documentées et ressortent après le lancement, quand les usages réels disent lesquelles comptent vraiment. C'est souvent à ce moment qu'on découvre que la moitié de la liste de départ n'intéressait personne.
Pourquoi ce tri protège votre budget#
Un périmètre qui gonfle est la première cause de dérapage d'un projet SaaS, bien avant la difficulté technique. Plus le MVP est large, plus il est long à sortir, et plus le budget part avant le premier euro encaissé. C'est l'une des raisons les plus fréquentes d'échec d'un SaaS.
Trancher tôt, c'est sortir vite, encaisser un premier client, et financer la suite sur du réel plutôt que sur des suppositions. C'est la discipline même qui permet de lancer un SaaS en 6 à 8 semaines.
Comment on procède#
Sur nos projets, le tri se fait au cadrage, avant la moindre ligne de code : on liste les fonctionnalités voulues, on les passe au test, et on sépare le MVP du « plus tard » noir sur blanc. Le périmètre retenu est chiffré à prix fixe, ce qui aligne tout le monde sur le même produit de départ.
C'est le point de départ de notre offre de création de SaaS : un premier produit resserré, solide et livré sur votre dépôt, pensé pour grandir sur ses propres usages.
Questions fréquentes
Quelles fonctionnalités inclure dans un MVP SaaS ?
Trois blocs, et rien de plus : la fonction centrale qui crée la valeur, l'authentification pour gérer les comptes, et le paiement pour encaisser. Tout ce qui n'empêche pas un premier utilisateur de payer est reporté après le lancement.
Comment décider si une fonctionnalité entre dans le MVP ?
Posez une seule question : sans elle, un premier client peut-il quand même payer et obtenir la valeur promise ? Si oui, elle attend. Si non, elle entre. Ce test tranche la grande majorité des arbitrages sans débat.
Faut-il un tableau de bord d'administration dans un MVP SaaS ?
Au lancement, non. Les statistiques, exports et réglages avancés peuvent souvent être gérés à la main ou directement en base les premières semaines. Construire un back-office complet avant d'avoir des utilisateurs est une dépense prématurée.
Que se passe-t-il pour les fonctionnalités reportées ?
Elles ne sont pas abandonnées, elles sont documentées et priorisées après le lancement, à la lumière des usages réels. Beaucoup de fonctions jugées indispensables au départ se révèlent secondaires une fois les vrais utilisateurs arrivés.