Un MVP, c'est-à-dire un minimum viable product (produit minimum viable), est la plus petite version d'un produit qui permet de tester l'hypothèse la plus importante auprès de vrais utilisateurs. Il ne s'agit pas d'une « version bon marché de l'application », mais du chemin le plus court vers la réponse à une question : quelqu'un en a-t-il vraiment besoin, et fera-t-il ce que vous attendez ?
Si vous arrivez ici depuis le monde du jeu vidéo ou du sport : là-bas, MVP signifie « most valuable player », le meilleur joueur. Dans cet article, il est question du produit.
D'où vient le terme
L'expression est apparue au début des années 2000 et a été popularisée par Steve Blank et Eric Ries. Dans « The Lean Startup », Ries décrit le MVP comme la version d'un produit qui permet de recueillir un maximum de connaissances validées sur les clients avec un minimum d'effort. Deux mots comptent ici : connaissance et effort. Le MVP doit apprendre quelque chose, pas seulement exister.
Ce que signifient les trois lettres
- Minimum — uniquement ce qui est nécessaire pour tester une hypothèse. Chaque fonctionnalité supplémentaire allonge le délai avant la première réponse.
- Viable — le produit doit vraiment fonctionner et apporter de la valeur. Une maquette bancale ne vous dira pas si les gens veulent la solution, seulement qu'ils ne veulent pas quelque chose de cassé.
- Product — quelque chose que les gens utilisent ou pour lequel ils paient. Un sondage « achèteriez-vous ? » est une étude, pas un produit.
L'erreur la plus fréquente est de ne retenir que la première lettre. Un « minimum » sans « viable » donne un produit qui ne prouve rien.
Les types de MVP
Un MVP n'est pas toujours une application. On commence par le moyen le moins cher qui donne une réponse fiable.
La page d'inscription (smoke test). Vous décrivez le produit comme s'il existait déjà et vous mesurez combien de personnes laissent leur e-mail ou cliquent sur « acheter ». Cela teste la demande avant même qu'une ligne de code du produit n'existe.
Le MVP concierge. Vous réalisez le service à la main pour les premiers clients. Vous savez tout de suite pour quoi ils paient et ce qui compte pour eux, et vous n'automatisez qu'ensuite.
Le MVP « magicien d'Oz ». Le client voit un produit abouti, mais en coulisses, une partie du travail est faite par une personne. Vous vérifiez si les gens utilisent la solution avant de construire une automatisation coûteuse.
Le produit à une seule fonction. Une application qui fonctionne et fait une seule chose bien : par exemple uniquement la réservation, sans programme de fidélité, sans chat ni rapports. C'est la forme la plus courante quand l'hypothèse porte sur un usage régulier.
Le MVP fait de briques existantes. Un formulaire, un tableur, un outil de paiement et une automatisation à la place d'un système sur mesure. Rapide et peu coûteux, mais avec des limites quand le trafic augmente.
Des exemples connus
- Dropbox, avant de construire le produit complet, a montré une courte vidéo expliquant comment la synchronisation des fichiers allait fonctionner. La liste d'attente est passée de quelques personnes à plusieurs dizaines de milliers en une nuit. C'était un test de la demande, pas une application.
- Zappos n'avait pas d'entrepôt au départ. Le fondateur photographiait des chaussures dans des magasins locaux et, à la commande, les achetait puis les expédiait. Il vérifiait si les gens achèteraient des chaussures en ligne.
- Airbnb a débuté en louant des matelas dans l'appartement des fondateurs pendant une conférence à San Francisco, alors que les hôtels étaient complets. Un site simple, quelques hôtes, de l'argent réel.
Dans les trois cas, la première version testait une seule hypothèse, celle dont dépendait toute l'idée.
Ce qu'un MVP n'est pas
Ce n'est pas un prototype à montrer aux investisseurs. Un prototype vérifie qu'une solution peut être comprise et utilisée. Un MVP vérifie que les gens l'utilisent ou paient pour elle. Les deux sont utiles, mais ils répondent à des questions différentes.
Ce n'est pas une première version avec la moitié des fonctionnalités. Si la liste de fonctionnalités du MVP ressemble à un plan d'un an coupé en deux, ce n'est pas un MVP. C'est un produit complet qui se construit plus lentement.
Ce n'est pas du travail bâclé. Un périmètre étroit n'excuse ni les bugs, ni la lenteur, ni un stockage de données peu sûr. Peu de fonctionnalités, mais bien faites.
Ce n'est pas la fin du travail. Le MVP est le début d'un cycle d'apprentissage. Viennent ensuite les données, les décisions et les versions suivantes.
Comment choisir le périmètre du MVP
- Notez vos hypothèses. Qui a le problème, comment le résout-il aujourd'hui, combien cela lui coûte, pourquoi vous choisirait-il.
- Choisissez les plus risquées. Celles qui, si elles sont fausses, ruinent le reste. Elles portent généralement sur la gravité du problème, plus que sur la faisabilité technique.
- Définissez ce que sera un succès. De façon concrète et avant le lancement : par exemple « 10 personnes sur 50 de la liste paient le premier mois ». Sans cela, n'importe quel résultat peut être interprété en votre faveur.
- Supprimez tout le reste. Connexion via cinq services, tableau de bord avec rapports, application pour deux systèmes : si cela n'aide pas à tester cette hypothèse, cela attendra.
J'explique plus en détail comment mener ce cycle pas à pas dans le sujet sur la méthode lean startup, et comment ordonner les hypothèses sur une seule feuille avec le lean canvas.
Combien coûte un MVP et combien de temps il prend
Cela dépend du type. Une page d'inscription ou un MVP concierge peut être prêt en quelques jours pour un coût modeste. Une application web qui fonctionne, avec une fonction principale, une connexion et des paiements, représente en général quelques semaines de travail.
Chez moi, un MVP d'application web au périmètre étroit coûte 1 900–9 300 € à prix fixe et prend 2 à 6 semaines. J'explique en détail d'où vient cette fourchette et quels sont les coûts cachés dans l'article Coût d'un MVP en 2026. Si vous voulez commencer, découvrez comment je construis un MVP.
Questions fréquentes
Un MVP doit-il forcément être une application ? Non. Si la question principale est « quelqu'un en veut-il ? », une page, des conversations et un service réalisé à la main suffisent souvent. Cela vaut la peine de construire une application quand vous voulez vérifier que les gens l'utiliseront régulièrement.
Peut-on montrer aux clients un MVP « inachevé » ? Oui, à condition que ce qu'il fait, il le fasse bien. Les premiers utilisateurs pardonnent l'absence de fonctionnalités, mais pas qu'une fonction de base ne marche pas.
Que faire après le MVP ? Vous mesurez ce que les gens ont fait et vous décidez : développer, changer de cap ou arrêter. Pour savoir si le produit répond à un vrai besoin, lisez le sujet sur le product-market fit.