Qu'est-ce qu'un MVP, et que construire en premier ?

Un MVP (« Minimum Viable Product », en français « produit minimum viable ») est la plus petite version de votre produit qui permet de vérifier votre idée auprès de vraies personnes. Ce n'est pas une version bâclée : c'est une version volontairement réduite à l'essentiel, pour apprendre vite avant d'investir davantage.

L'analogie : la première marche

Vous voulez construire un grand escalier vers un étage que vous n'avez jamais visité. Plutôt que de bâtir toutes les marches, vous commencez par la première, et vous vérifiez qu'elle vous mène bien dans la bonne direction. Si oui, vous continuez. Sinon, vous avez perdu bien moins que si vous aviez tout construit.

Le MVP, c'est cette première marche : solide, utilisable, mais petite.

Ce qu'un MVP n'est pas

• Pas un prototype jetable : il doit fonctionner pour de vrai, même sur un périmètre réduit.
• Pas une version médiocre : réduire les fonctionnalités n'autorise pas à négliger la fiabilité de ce qu'on livre.
• Pas la version finale en plus petit : c'est un outil pour apprendre, pas un produit complet en miniature.
• Pas un synonyme de « pas cher » : il coûte moins qu'un produit complet, mais il demande du soin.

Le principe : une seule question à valider

Un bon MVP répond à une question importante. Par exemple :

• Les gens ont-ils vraiment ce problème ?
• Sont-ils prêts à utiliser cette solution plutôt que leur méthode actuelle ?
• Ce parcours précis fonctionne-t-il pour eux ?

Si votre MVP essaie de répondre à dix questions en même temps, il ne répond bien à aucune.

Comment choisir quoi construire en premier

1. Décrivez le problème en une phrase, du point de vue de la personne qui l'a.
2. Identifiez l'utilisateur principal. Pour qui construisez-vous en premier ?
3. Listez tout ce que vous imaginez, puis rayez sans pitié. Gardez ce qui est indispensable pour que cette personne résolve son problème de bout en bout.
4. Choisissez un parcours complet plutôt que beaucoup de fonctions à moitié finies : l'utilisateur doit pouvoir aller du début à la fin d'une tâche.
5. Repoussez le reste : les options, les réglages, les cas rares, les écrans d'administration sophistiqués.

Un test pratique : « Si je retire cette fonctionnalité, mon utilisateur peut-il toujours résoudre son problème ? » Si oui, elle peut attendre.

Exemple illustratif

Imaginons une application pour une boutique de quartier qui veut gérer des commandes à retirer. Le MVP pourrait se limiter à : voir les produits, commander, être prévenu quand c'est prêt. Pas de programme de fidélité, pas de statistiques, pas de multi-boutiques. Ces éléments viendront si l'usage confirme l'intérêt.

Ce qu'il ne faut pas rogner

Même réduit, un MVP qui accueille de vrais utilisateurs doit tenir quelques promesses : leurs données sont protégées, l'application ne tombe pas au premier problème, et elle peut évoluer ensuite. C'est là que les outils d'IA qui produisent une application en quelques heures montrent leurs limites : voir Lovable, Bolt, Cursor : ce qui change et vibe coding : les limites.

Après le MVP

Le MVP n'est pas une fin. Une fois lancé, on observe : qui l'utilise, ce qui est utilisé, ce qui bloque. Ces observations décident de la suite. Pour bien cadrer avant de commencer, voir cadrer un produit.

À retenir

Un MVP, c'est la plus petite version qui répond à une vraie question auprès de vraies personnes : petite, mais solide. Choisissez un utilisateur, un problème, un parcours complet, et laissez le reste attendre.

Et pour votre produit ?

Si vous avez une idée et voulez définir ce qu'il faut construire en premier, notre accompagnement de création de produit permet de transformer l'idée en un premier périmètre réaliste, puis de le développer. Nous pouvons en discuter lors d'un échange de 30 minutes.