La plupart des projets de produit que je vois arriver ne meurent pas d'un problème technique. Ils meurent d'un périmètre trop large. On veut tout construire d'un coup : le tableau de bord, les notifications, les abonnements, l'appli mobile. Six mois plus tard, rien n'est en ligne, le budget est consommé, et personne n'a encore vérifié que quelqu'un veut ce produit.
Le MVP existe pour éviter exactement ça. Mais le terme est devenu tellement galvaudé qu'il faut le redéfinir avant de s'en servir.
Un MVP n'est pas une version au rabais
MVP veut dire minimum viable product : le plus petit produit qui permet de tester votre hypothèse principale. Le mot important n'est pas « minimum ». C'est « tester ».
Un MVP n'est pas votre produit final avec moins de soin. C'est un instrument de mesure. Sa réussite ne se juge pas à sa beauté ni à son nombre de fonctionnalités, mais à une seule question : est-ce qu'il vous a appris quelque chose de décisif sur vos utilisateurs ?
Concrètement, ça change tout. Si votre hypothèse est « des artisans paieraient pour un outil de devis simplifié », le MVP n'a pas besoin de gestion d'équipe, ni d'export comptable, ni de mode sombre. Il a besoin d'un moyen de créer un devis, de l'envoyer, et de voir si des artisans reviennent le lendemain.
Réduire le périmètre : la partie difficile
Réduire le périmètre est la partie la plus inconfortable du travail, parce que chaque fonctionnalité écartée semble indispensable. Ma méthode tient en trois questions, posées pour chaque fonctionnalité envisagée :
Est-ce que l'hypothèse principale peut être testée sans elle ? Si oui, elle sort du MVP. Pas de négociation. Elle ira peut-être dans la V1, mais pas ici.
Est-ce qu'un humain peut la remplacer temporairement ? Beaucoup de choses qu'on veut automatiser peuvent être faites à la main au début. Envoyer les emails soi-même, valider les inscriptions manuellement, générer les documents une par une. C'est inconfortable, mais c'est des semaines de développement économisées pour un produit qui n'a pas encore prouvé son intérêt.
Est-ce que son absence fait fuir l'utilisateur au premier essai ? Là, attention : certaines choses ne sont pas négociables même dans un MVP. Un produit qui perd les données, qui plante, ou qui n'est pas utilisable sur mobile quand la cible est mobile, ne teste rien du tout — il teste juste la patience des gens.
Les pièges que je vois le plus souvent
Le premier piège, c'est le MVP fantôme : on dit « MVP » mais on construit la V1 complète, en se rassurant avec le vocabulaire. Le signe qui ne trompe pas : la liste de fonctionnalités ne diminue jamais, elle grandit.
Le deuxième, c'est l'inverse : le MVP tellement réduit qu'il ne teste plus rien. Une landing page avec un bouton « Bientôt disponible » mesure la curiosité, pas l'usage. C'est parfois suffisant pour tester l'intérêt, mais il ne faut pas confondre les deux niveaux de preuve.
Le troisième, c'est le MVP sans critère de succès défini à l'avance. Si vous ne savez pas, avant le lancement, ce qui vous fera dire « ça marche » ou « ça ne marche pas », vous trouverez toujours une raison de continuer. Fixez le seuil avant : combien d'utilisateurs actifs, combien de retours, combien reviennent la deuxième semaine.
Le passage à la V1
Si le MVP a validé l'hypothèse, la V1 n'est pas « le MVP en plus joli ». C'est le moment de payer les raccourcis pris volontairement : remplacer les processus manuels par de l'automatisation là où le volume le justifie, consolider la base technique, soigner l'interface sur les parcours que les utilisateurs empruntent vraiment — on les connaît maintenant, c'est tout l'intérêt.
C'est aussi le moment de trancher ce qu'on abandonne. Le MVP a souvent révélé que certaines fonctionnalités prévues n'intéressent personne. Les retirer du plan est un gain, pas un échec.
Techniquement, je défends une continuité : si le MVP est construit proprement — même petit — la V1 le prolonge au lieu de repartir de zéro. Un MVP jetable coûte deux fois : une fois à le construire, une fois à le remplacer. Petit périmètre ne veut pas dire code négligé.
Par où commencer
Si vous portez une idée de produit, l'exercice le plus rentable ne coûte rien : écrivez votre hypothèse principale en une phrase, puis listez le strict nécessaire pour la tester. Si la liste dépasse dix éléments, elle n'est pas encore assez courte.
C'est exactement le genre de cadrage que je fais en début de projet, avant d'écrire la moindre ligne de code. Vous portez une idée et vous ne savez pas par quel bout la prendre ? Parlons-en — le premier échange sert justement à ça.