Image : startupphotos — Openverse (by)
Ton MVP n'est pas assez minimal : repenser le « minimum viable »
Tu bosses depuis trois mois sur ta « première version ». Tu as un système d'auth complet, un dashboard avec des graphes animés, un onboarding en cinq étapes et un mode sombre. Tu appelles ça un MVP. Ce n'en est pas un.
Le terme MVP — minimum viable product — est devenu un alibi pour construire un vrai produit en se donnant bonne conscience. On se dit « c'est juste un MVP » tout en empilant des features qu'aucun utilisateur n'a encore demandées. Le résultat : des semaines perdues, de l'énergie brûlée, et zéro feedback du marché.
Il est temps de revenir à ce que « minimum » veut vraiment dire.
Le piège du MVP qui n'a rien de minimal
Le problème n'est pas l'ambition. C'est la confusion entre construire un produit et valider une hypothèse.
Quand tu ajoutes une feature à ton MVP, pose-toi la question : est-ce que cette feature m'aide à prouver que quelqu'un veut payer pour résoudre ce problème ? Dans 90 % des cas, la réponse est non. Tu ajoutes la feature parce qu'elle te semble nécessaire pour que le produit soit « complet ». Mais personne ne t'a demandé un produit complet. Personne ne sait encore que tu existes.
Les symptômes classiques du faux MVP :
- Tu travailles dessus depuis plus de quatre semaines sans qu'un seul utilisateur l'ait touché.
- Tu as plus de trois écrans ou sections distinctes.
- Tu passes du temps sur le design « pour faire pro ».
- Tu gères des edge cases que tu n'as jamais observés.
- Tu construis une infra « scalable » pour zéro utilisateur.
Chacun de ces points est un signal que tu optimises pour toi, pas pour l'apprentissage.
Le vrai but d'un MVP : apprendre
Un MVP n'est pas une version dégradée de ton produit final. C'est un outil d'apprentissage. Sa seule raison d'exister est de répondre à une question précise : est-ce que le problème que je cible est suffisamment douloureux pour que quelqu'un change son comportement ?
Reformule ton MVP comme une expérience scientifique :
- Hypothèse : « Les freelances perdent du temps à relancer leurs factures impayées. »
- Test : une landing page avec un bouton « Envoyer mes relances automatiquement » + un formulaire email.
- Métrique : nombre d'inscriptions en une semaine.
Tu n'as pas besoin de construire le système de relance pour valider l'hypothèse. Tu as besoin de prouver que des gens lèvent la main. Le produit vient après.
Ce n'est pas de la triche. C'est du respect pour ton propre temps. Chaque heure passée à coder une feature non validée est une heure volée à la découverte de ce que tes utilisateurs veulent vraiment.
Couper les features par la racine
Voici un exercice brutal mais efficace. Prends ta liste de features prévues pour le MVP. Maintenant, supprime tout sauf une seule action utilisateur. Une. Pas trois. Une.
Quelle est l'action unique qui prouve ta proposition de valeur ?
- Si tu fais un outil de gestion de tâches : créer une tâche et la cocher. Pas de projets, pas de tags, pas de collaboration.
- Si tu fais un SaaS de facturation : générer une facture PDF à partir d'un formulaire. Pas de dashboard, pas de récurrence, pas de multi-devises.
- Si tu fais une marketplace : mettre en relation un vendeur et un acheteur. Même manuellement par email.
Le critère n'est pas « est-ce que c'est beau ». C'est « est-ce que ça démontre la valeur en moins de 30 secondes ».
Quelques règles pour couper sans pitié :
- Pas d'auth au début. Un lien unique ou un mot de passe partagé suffit pour 10 beta-testeurs.
- Pas de paiement intégré. Un virement ou un lien Stripe manuel marche très bien pour les premiers euros.
- Pas de notifications. Envoie un email toi-même.
- Pas de settings. Choisis les valeurs par défaut et impose-les.
Chaque feature que tu retires te rapproche du lancement. Et un MVP lancé avec une feature bat un MVP parfait resté sur localhost.
Quand le MVP devient le produit
Il y a un moment où le MVP a rempli son rôle. Tu as appris. Tu sais que le problème est réel, que des gens veulent une solution, et que ta direction est la bonne. C'est là — et seulement là — que tu commences à construire un produit.
La transition se fait naturellement :
- Tes utilisateurs te demandent des choses précises → tu ajoutes ces features.
- Tu vois des patterns dans l'usage → tu structures l'expérience.
- Tu as des clients payants → tu investis dans la fiabilité.
Le piège inverse existe aussi : rester en mode MVP trop longtemps. Si tu as 50 utilisateurs actifs qui paient et que ton produit tient avec du scotch, il est temps de consolider. Mais ce problème-là est un bon problème. Il signifie que tu as validé quelque chose.
La majorité des makers n'atteignent jamais ce stade. Pas parce que leur idée est mauvaise. Parce qu'ils ont passé six mois à construire un château avant de vérifier que quelqu'un voulait y habiter.
Ton MVP devrait te mettre mal à l'aise. Si tu n'as pas un peu honte de ce que tu lances, c'est que tu as trop attendu. Le minimum dans MVP n'est pas un défaut. C'est une discipline. C'est la compétence qui sépare ceux qui livrent de ceux qui peaufinent indéfiniment.
Écris ton hypothèse. Coupe tout ce qui ne la teste pas. Lance cette semaine. Le reste viendra — mais seulement si tu apprends d'abord.
Envie de passer du « je devrais » au « c'est en ligne » ? Commence par valider ton idée, puis distribue-la. graine de startup est édité par le studio de Sébastien Debollivier.