Minimum Viable Product (MVP) : définition, exemples et méthode
Mis à jour le
Le MVP (Minimum Viable Product), ou produit minimum viable en français, est la première version d’un produit mise entre les mains de vrais utilisateurs, réduite aux fonctionnalités qui résolvent leur problème principal. Il sert à vérifier, avec le moins de développement possible, que des clients utilisent le produit avant d’investir dans la suite.
Pour un SaaS ou une application web, un MVP se construit le plus souvent en quatre semaines à trois mois. Cet article donne sa définition, des exemples connus et un cas réalisé par Lonestone, les étapes pour le construire et la liste des fonctionnalités que Lonestone retire d’un MVP pour tenir ce délai.
Qu’est-ce qu’un MVP ?
Frank Robinson, fondateur du cabinet de conseil SyncDev, a inventé le terme en 2001. Eric Ries, entrepreneur américain, l’a popularisé en 2011 dans The Lean Startup. Il y définit le MVP comme la version d’un nouveau produit qui permet à une équipe d’apprendre le plus de choses possible sur ses clients avec le moins d’effort.
Dans un projet logiciel, un MVP se reconnaît à trois critères :
- de vrais clients l’utilisent seuls, en conditions réelles
- il couvre de bout en bout un seul parcours, celui qui répond au problème principal
- il mesure un comportement précis, comme une inscription, un usage répété ou un premier paiement
Le « minimum » limite le nombre de fonctionnalités. Le parcours qui reste doit quand même être « viable » : s’il est lent ou confus, les utilisateurs partent avant que l’équipe ait appris quoi que ce soit.
MVP, prototype et POC
Le prototype, le POC et le MVP répondent chacun à une question différente.
| Prototype | POC | MVP | |
|---|---|---|---|
| Question testée | Les utilisateurs comprennent-ils le produit ? | L’idée est-elle techniquement faisable ? | Les utilisateurs adoptent-ils le produit ? |
| Forme | Maquettes cliquables, sans code de production | Code isolé, souvent sans interface | Logiciel en production |
| Qui s’en sert | Un panel de test | L’équipe technique | Les premiers clients |
| Durée courante | Quelques semaines | Une à trois semaines | Quatre semaines à trois mois |
Pour une maison, le prototype correspond aux plans, le POC à l’étude de sol et le MVP à un premier logement habitable avec une cuisine, une chambre et une salle de bains.
Une preuve de concept (POC) passe avant le MVP quand la faisabilité technique reste à prouver, par exemple la précision d’un modèle d’IA. Lonestone développe ces POC en une à trois semaines.
Exemples de MVP
Zappos a vendu des chaussures sans stock
En 1999, Nick Swinmurn, fondateur de Zappos, photographie les chaussures de magasins de sa région et les met en ligne. Quand une commande arrive, il achète la paire au prix boutique et l’expédie lui-même. Il vérifie ainsi que des gens achètent des chaussures sur Internet avant de constituer le moindre stock.
Airbnb a commencé avec trois matelas gonflables
En 2007, Brian Chesky et Joe Gebbia, futurs cofondateurs d’Airbnb, louent des matelas gonflables dans leur appartement de San Francisco pendant une conférence de design où les hôtels affichent complet. Un site d’une page leur suffit pour trouver leurs trois premiers clients.
Dropbox a testé la demande avec une vidéo
En 2008, Drew Houston, cofondateur de Dropbox, publie une vidéo qui montre la synchronisation de fichiers alors que le produit n’est pas encore prêt. La liste d’attente de la bêta passe de 5 000 à 75 000 inscrits en une nuit.
Une inscription sur une liste d’attente montre de la curiosité. Pour un logiciel B2B, Lonestone préfère un MVP que les clients utilisent vraiment, parce qu’un usage répété montre qu’ils y trouvent de la valeur.
Salto.run est parti de deux briques
Salto, la plateforme de streaming lancée par TF1, M6 et France Télévisions, voulait un outil interne pour centraliser toute la connaissance métier sur ses contenus audiovisuels. Lonestone a construit le MVP de Salto.run sur deux briques seulement : le suivi de l’acquisition des contenus et le pilotage financier du catalogue.
Lonestone a fixé ce périmètre avec un représentant de chaque métier, pendant des ateliers de priorisation. Tous les autres besoins sont allés dans la roadmap. Chaque sprint de deux semaines se terminait par une démo aux équipes métier, qui testaient la nouvelle version dans la foulée.
Les étapes pour créer un MVP
1. Formuler l’hypothèse et l’indicateur de réussite
Écrivez en une phrase ce que le MVP doit prouver, avec un chiffre. Par exemple : « La moitié des commerciaux inscrits relancent un prospect depuis l’outil au moins une fois par semaine pendant un mois. » Sans indicateur fixé à l’avance, chaque résultat finit par passer pour un succès.
Avant d’écrire une ligne de code, parlez à une dizaine d’utilisateurs potentiels de leur problème et de la façon dont ils le règlent aujourd’hui. Ces entretiens servent ensuite à écrire la proposition de valeur et à cadrer le projet.
2. Prototyper et tester le parcours principal
Dessinez le parcours principal en maquettes cliquables et faites-le tester à quelques utilisateurs. Une incompréhension se corrige en une heure de design à ce stade, contre un sprint de développement une fois le code écrit. Lonestone conçoit et teste ces maquettes avec l’offre Shape.
3. Prioriser les fonctionnalités avec la méthode MoSCoW
Lonestone fixe le périmètre du MVP pendant un atelier produit avec la méthode MoSCoW. Chaque fonctionnalité y reçoit l’un des quatre niveaux de priorité : Must have, Should have, Could have ou Won’t have.
Seules les fonctionnalités Must have entrent dans le MVP. Les Should have attendent la version suivante. L’atelier sert surtout à faire accepter ce tri à tout le monde.
4. Développer en sprints de deux semaines
Une fois les user stories écrites et les maquettes validées, le développement avance par sprints de deux semaines. Chaque sprint suit le même cycle :
- définition et priorisation des user stories, avec leurs critères d’acceptation
- planification du sprint
- développement
- démo de l’avancement au client
- rétrospective
Avec le no code et le low code, on teste une demande en quelques jours. Quand le MVP doit devenir le produit, le code sur mesure évite de tout reconstruire au moment où les premiers clients arrivent. Lonestone développe ces MVP en TypeScript avec l’offre Build.
5. Lancer, mesurer et itérer
Le cycle de la méthode Lean Startup tient en trois verbes : construire, mesurer, apprendre. Mettez le MVP en ligne, suivez l’indicateur fixé à l’étape 1, puis décidez de continuer, de corriger le cap ou d’arrêter.
« Si vous n’êtes pas gêné par la première version de votre produit, alors vous l’avez lancé trop tard. »
Reid Hoffman, cofondateur de LinkedIn
Répondez aux premiers utilisateurs un par un. Croisez ensuite leurs retours avec les données d’usage pour décider des sprints suivants et de la stratégie produit.
graph TD
A["1. Formuler l’hypothèse et l’indicateur de réussite"] --> B["2. Prototyper et tester le parcours principal"]
B --> C["3. Prioriser les fonctionnalités avec MoSCoW"]
C --> D["4. Développer en sprints de deux semaines"]
D --> E["5. Lancer et mesurer l’indicateur"]
E --> F{"L’indicateur est-il atteint ?"}
F -->|Oui| G["Continuer vers la V1"]
F -->|En partie| H["Corriger le cap"]
H --> D
F -->|Non| I["Arrêter ou repartir de l’hypothèse"]
I --> A
Les fonctionnalités que Lonestone retire d’un MVP
Sur un MVP, Lonestone retire tout ce qui ne sert pas le parcours principal, puis soigne ce parcours comme dans un produit fini. Les fonctionnalités retirées en premier sont presque toujours les mêmes :
- le back-office d’administration, puisque l’équipe fondatrice traite à la main les quelques opérations des premières semaines
- les rôles et permissions détaillés, alors qu’un rôle utilisateur et un rôle administrateur suffisent au départ
- la facturation automatisée, remplacée par une facture ou un lien de paiement pour les premiers clients
- les exports, les tableaux de bord avancés et les écrans de paramétrage
- les autres langues, et l’application mobile quand un site web responsive couvre l’usage
- les intégrations secondaires, pour ne garder que celle dont le parcours principal a besoin
Lonestone garde en revanche quatre éléments dès la première version :
- l’authentification et la sécurité des données, parce qu’une fuite chez les premiers clients coûte leur confiance
- l’UX du parcours principal, parce qu’un utilisateur qui se perd n’apprend rien à l’équipe sur la valeur du produit
- le suivi des usages, sans lequel l’équipe n’a rien à mesurer
- un code propre, testé et déployable, parce qu’un MVP qui marche devient la base de la V1
Pour ce socle, Lonestone part de son boilerplate open source, qui fournit déjà l’authentification, la gestion des utilisateurs et le déploiement. L’équipe consacre ainsi les premières semaines au parcours principal, avec des ingénieurs qui ont pour la plupart entre 10 et 25 ans d’expérience.
Vous envisagez de développer un SaaS sur mesure, un site web ou une application mobile ? L’équipe de Lonestone conçoit et développe votre MVP, puis les versions suivantes. On en discute ? Contactez-nous.
Questions fréquentes
Que veut dire MVP ?
MVP signifie « produit minimum viable » en français : c’est l’abréviation de l’anglais Minimum Viable Product. Frank Robinson, fondateur du cabinet SyncDev, a inventé le terme en 2001. L’entrepreneur Eric Ries l’a popularisé en 2011 avec la méthode Lean Startup. Un MVP est la première version d’un produit, réduite aux fonctionnalités qui résolvent le problème principal et mise entre les mains de vrais utilisateurs pour vérifier qu’ils l’adoptent.
Que signifie MVP en informatique ?
En informatique, MVP (Minimum Viable Product) désigne la première version d’un logiciel, web ou mobile, limitée aux fonctionnalités indispensables à son usage principal. Elle est mise en production auprès de vrais utilisateurs pour mesurer s’ils l’adoptent, puis enrichie sprint après sprint. En développement, le même sigle désigne aussi le modèle d’architecture Model-View-Presenter, qui sépare l’affichage d’une interface de sa logique. Dans un projet produit, MVP renvoie presque toujours au Minimum Viable Product. Lonestone conçoit et développe des SaaS sur mesure en commençant par un MVP.
Qu’est-ce qu’une phase MVP dans un projet ?
La phase MVP est le moment du projet où l’équipe livre une première version fonctionnelle sur un périmètre volontairement restreint, puis mesure comment les utilisateurs s’en servent. Elle intervient après le cadrage et la priorisation des fonctionnalités, et avant les itérations qui font grandir le produit. Sa durée courante va de quatre semaines à trois mois selon la complexité du produit.
Quelle est l’utilité d’un MVP ?
Le MVP réduit le risque de lancer un produit dont personne ne veut. Il valide un concept à moindre coût grâce aux retours des premiers utilisateurs, ce qui permet d’arrêter ou de réorienter un projet avant d’y engager un budget complet. Il donne aussi des données d’usage réelles pour arbitrer la stratégie produit et la roadmap des versions suivantes.
Quelle est la différence entre un MVP et un POC ?
Un POC vérifie la faisabilité technique d’une idée, souvent hors production et sans utilisateur final. Un MVP vérifie la valeur commerciale : il est livré à de vrais utilisateurs, dans des conditions réelles, et mesure s’ils adoptent le produit. Un projet peut enchaîner les deux, le POC levant le risque technique et le MVP le risque marché.
Comment faire un MVP ?
Il n’existe pas de modèle de MVP applicable à tous les produits. La démarche courante consiste à identifier les fonctionnalités qui répondent au problème principal des utilisateurs, à concevoir une interface simple, à fixer des indicateurs de succès mesurables, puis à lancer vite pour récolter des données d’usage. La méthode MoSCoW aide à trancher entre ce qui doit être livré et ce qui peut attendre. Lonestone livre ce type de première version avec l’offre Build, ou avec l’offre Shape quand le produit doit d’abord être conçu et testé.
Combien coûte le développement d’un MVP ?
Un MVP logiciel livré par une agence française senior se situe le plus souvent entre 40 000 et 80 000 €, pour deux à trois mois de développement. Le prix dépend du nombre de parcours à couvrir, des intégrations tierces et du niveau d’exigence sur la mise en production. Le prix d’un développement SaaS se détaille poste par poste. Lonestone livre un MVP en un mois sur des périmètres cadrés, avec une équipe d’ingénieurs seniors.
