MVP SaaS : ce qu'il faut vraiment inclure au départ
Un MVP doit valider une hypothèse business avec le moins de code possible. Ce n'est pas une version incomplète du produit final — c'est un outil délibérément limité pour répondre à une question précise. Voici ce qui doit absolument y être, ce qui peut attendre, et les erreurs qui font perdre 3 mois.
Ce qu'est vraiment un MVP
MVP signifie Minimum Viable Product. Le mot important n'est pas "minimum", c'est "viable". Un MVP est viable s'il permet à un utilisateur réel d'accomplir la tâche centrale du produit et d'en tirer de la valeur.
Ce n'est pas un prototype cliquable sans backend, ni un produit à moitié fini qui ne fonctionne pas vraiment. C'est un produit qui fonctionne, livré à de vrais utilisateurs, dont on mesure le comportement pour décider quoi construire ensuite.
Les 5 composants non négociables
1. L'authentification fonctionnelle. Inscription avec email + vérification, login/logout, récupération de mot de passe, session persistante. Pas de fausse auth — les utilisateurs doivent avoir un vrai compte pour que les mesures d'engagement aient du sens.
2. La fonctionnalité core — une seule. Un MVP n'a qu'un seul job. La question à poser pour chaque fonctionnalité : "si on enlève ça, est-ce que le problème core n'est plus résolu ?" Si la réponse est non, ça sort du MVP.
3. Un onboarding qui ne requiert pas votre intervention. Si chaque nouvel utilisateur nécessite que vous le configuriez manuellement, le produit n'est pas un SaaS — c'est un service manuel avec une interface. L'onboarding minimum : email de bienvenue, état vide avec une action claire, un tutoriel d'une étape.
4. Le paiement. Pour les SaaS B2B, ne pas attendre la V2. Stripe prend 2 à 3 jours à intégrer. Si l'hypothèse est "les gens paient pour ça", la validation ne peut pas se faire sans paiement réel. Schéma minimum : un plan, un prix, Stripe Checkout.
5. Une interface de mesure basique. Pas d'analytics sophistiqués — mais savoir combien d'utilisateurs se sont inscrits, combien ont accompli la tâche core au moins une fois, et combien reviennent après J+7.
Ce qui peut attendre la V2
Fonctionnalités administratives. Gestion des utilisateurs, rôles avancés, audit logs — ça peut être géré manuellement en base de données si vous avez 20 utilisateurs.
Les intégrations "pendant qu'on y est". Slack, Zapier, API publique, webhooks. Si l'utilisateur a besoin de l'intégration pour utiliser le produit, c'est une fonctionnalité core. Sinon, c'est une V2.
Les emails automatisés avancés. Résumé hebdomadaire, rappels, notifications d'inactivité — utiles mais non vitaux. L'email de confirmation et le mot de passe oublié sont obligatoires. Le reste peut attendre.
La personnalisation. Thèmes, white-labeling, branding personnalisé — un utilisateur qui valide la fonctionnalité core n'a pas besoin de personnaliser l'interface.
Les erreurs qui tuent les MVP
Valider avec des gens qui vous connaissent. Vos amis et anciens collègues vont dire que c'est bien. Ils n'ont aucune raison de vous dire que c'est inutile. La seule validation qui compte : des inconnus qui cherchent activement à résoudre le problème paient réellement pour votre solution.
Construire pour des cas limites imaginaires. "Mais qu'est-ce qui se passe si un utilisateur a 10 000 items ?" Au MVP, si ça n'est pas encore arrivé, ne le gérez pas.
Le MVP sans date de fin. Un MVP sans deadline se transforme en produit à moitié fini qui traîne 18 mois. Fixer une date de livraison — 6 à 12 semaines — et ne pas en déroger. Ce qui n'est pas fait à la deadline est reporté à la V2.
La question à se poser avant de commencer
Pour chaque fonctionnalité sur votre liste : "si un utilisateur paye et qu'il n'a pas cette fonctionnalité, est-ce qu'il demande un remboursement ?"
Si la réponse est non, c'est une V2.
Vous avez un projet SaaS et voulez un avis externe sur ce qui doit entrer dans votre MVP ? On peut en discuter — l'appel de cadrage prend 45 minutes et n'engage à rien.