Qu'est-ce qu'un MVP ?
Un MVP est la plus petite version d'un produit qui permet de vérifier, auprès d'utilisateurs réels, l'hypothèse la plus risquée du projet.
Le sigle vient de l'anglais « minimum viable product ». Les trois mots ont chacun un sens précis :
- Minimum : on retire tout ce qui n'est pas nécessaire au parcours principal.
- Viable : ce qui reste fonctionne vraiment, sans bug bloquant, avec un niveau de finition qui ne fait pas fuir l'utilisateur.
- Produit : il est utilisé en conditions réelles, pas seulement montré en démonstration.
Un MVP n'est donc ni une maquette (qui ne fonctionne pas), ni un prototype technique (qui prouve qu'une technologie marche), ni une version 1 complète. C'est un outil d'apprentissage qui sert déjà.
MVP, prototype, POC, version 1 : ne pas confondre
Ces quatre livrables répondent à quatre questions différentes, et les confondre conduit à mal dépenser.
| Livrable | Question à laquelle il répond | Utilisé par de vrais clients ? |
|---|---|---|
| Maquette | Les écrans et le parcours sont-ils compris ? | Non, testé en entretien |
| POC (preuve de concept) | Est-ce techniquement faisable ? | Non, testé en interne |
| MVP | Les utilisateurs s'en servent-ils, et pour quoi ? | Oui |
| Version 1 complète | Peut-on servir tous les cas prévus ? | Oui |
Un projet d'intégration d'IA commence souvent par un POC (le modèle extrait-il correctement les données de nos factures ?) avant tout MVP.
Comment fixer le périmètre d'un MVP
On part de l'hypothèse à vérifier, on en déduit le parcours unique qui la teste, et on retire tout ce qui n'est pas sur ce parcours.
- Écrire l'hypothèse en une phrase : « Les techniciens rempliront leur rapport sur téléphone si cela leur prend moins de temps que le papier. »
- Identifier l'utilisateur principal : un seul profil au départ, les autres plus tard.
- Décrire le parcours critique de bout en bout : ouvrir l'intervention, saisir, photographier, faire signer, envoyer.
- Trier chaque fonction en trois colonnes : indispensable au parcours, utile plus tard, inutile.
- Remplacer ce qui peut l'être par une opération manuelle : un export envoyé à la main, une validation faite par mail, en attendant de savoir si la fonction mérite d'être construite.
- Écrire le hors périmètre pour que personne ne le rajoute en cours de route.
Ce travail est le cœur du cahier des charges et du cadrage.
Les deux erreurs classiques : le MVP trop gros et le MVP trop pauvre
Les MVP ratés se répartissent en deux familles opposées, et toutes deux coûtent cher.
Le MVP trop gros embarque le tableau de bord, les statistiques, trois rôles, la version anglaise et le paiement en plusieurs fois. Il sort tard, consomme le budget, et quand les premiers retours arrivent, il est déjà difficile de changer de cap.
Le MVP trop pauvre est si dépouillé, ou si instable, que les utilisateurs l'abandonnent pour de mauvaises raisons. On conclut alors à tort que l'idée ne marche pas, alors que c'est l'exécution qui a échoué. Une application qui plante à la signature ne teste rien.
Le bon MVP est étroit mais solide : peu de fonctions, chacune bien faite. Pour une application grand public, cela inclut l'inscription, la fiabilité et la publication sur les stores, qui ne s'improvisent pas.
Exemple : le MVP d'un outil de rapports d'intervention
Prenons une entreprise de maintenance dont les techniciens remplissent des bons papier, ressaisis le lendemain par l'assistante.
| Dans le MVP | Plus tard |
|---|---|
| Liste des interventions du jour sur téléphone | Planification par glisser-déposer |
| Saisie du rapport, photos, signature du client | Gestion du stock de pièces dans le véhicule |
| PDF envoyé automatiquement au client | Portail client avec historique |
| Fonctionnement sans réseau, synchronisation au retour | Tableau de bord de rentabilité par contrat |
Le fonctionnement hors ligne figure dans le MVP parce que, sans lui, le parcours casse dans le premier sous-sol venu. La planification avancée attend : l'assistante peut continuer à affecter les interventions depuis un écran simple pendant quelques semaines.
Quoi mesurer pendant et après le MVP
Avant la mise en ligne, choisissez trois à cinq indicateurs liés à l'hypothèse, et prévoyez de quoi les mesurer dès la première version.
- Activation : quelle part des personnes invitées accomplit le parcours principal au moins une fois ?
- Usage répété : reviennent-elles la semaine suivante, sans relance ?
- Temps de la tâche : combien de temps pour remplir un rapport, passer une commande, réserver ?
- Points d'abandon : à quelle étape les utilisateurs s'arrêtent-ils ?
- Retours qualitatifs : entretiens courts avec quelques utilisateurs, observation sur le terrain.
Pour un outil interne, l'indicateur le plus parlant est souvent la disparition du circuit parallèle : plus de bon papier, plus de fichier Excel en double.
Itérer après le MVP
Après le MVP, chaque cycle court ajoute ou corrige une chose précise, décidée à partir de ce qui a été mesuré, et non de la liste d'envies initiale.
Concrètement, on relit les indicateurs, on choisit le prochain frein à lever, on le construit, on le met entre les mains des utilisateurs, et on recommence. Certaines fonctions mises de côté reviennent ; d'autres disparaissent définitivement parce que personne ne les a réclamées. C'est aussi le moment de consolider ce qui avait été simplifié : tests automatisés, performance, sécurité. Pour une startup, la page MVP startup décrit cette trajectoire.
Check-list d'un MVP bien cadré
- L'hypothèse à vérifier tient en une phrase.
- Un utilisateur principal et un parcours principal sont désignés.
- Chaque fonction est classée indispensable, plus tard ou inutile.
- Le hors périmètre est écrit.
- Les indicateurs et leur mesure sont prévus dès la première version.
- La qualité du parcours principal est non négociable.
- La technologie choisie permet de faire évoluer le MVP sans tout réécrire.
Ce que fait YMHB Web
YMHB Web construit des MVP d'applications mobiles et web en cycles courts, avec une version testable accessible en permanence : vous voyez le produit avancer et pouvez le mettre entre les mains de quelques utilisateurs avant la fin. Les technologies sont choisies pour durer (Flutter pour une seule base de code iOS et Android, Next.js, Supabase, PostgreSQL), afin que le MVP devienne la base de la suite plutôt qu'un brouillon à jeter. Le guide créer une application mobile pour sa PME complète cette approche, et la méthode est publiée.
Questions fréquentes
- Que veut dire MVP pour une application ?
- MVP signifie minimum viable product, ou produit minimum viable. Pour une application, c'est la première version qui contient uniquement les fonctions nécessaires pour qu'un utilisateur réel accomplisse la tâche principale, avec une qualité suffisante pour qu'il l'utilise vraiment. Le MVP sert à vérifier l'hypothèse la plus risquée du projet avant d'investir dans des fonctions secondaires.
- Quelle différence entre un MVP et un prototype ?
- Un prototype sert à vérifier une idée ou une faisabilité technique, souvent en interne ou lors d'entretiens, sans être utilisé en conditions réelles. Un MVP est un produit qui fonctionne et qui est utilisé par de vrais clients ou de vrais collaborateurs. Le prototype répond à la question « est-ce possible ou compréhensible ? », le MVP à « est-ce utilisé ? ».
- Combien de fonctionnalités doit contenir un MVP ?
- Un MVP ne se définit pas par un nombre de fonctionnalités mais par un parcours. Il contient toutes les fonctions nécessaires pour que l'utilisateur principal accomplisse la tâche principale de bout en bout, et rien d'autre. Chaque fonction candidate se juge à une question : sans elle, le parcours principal est-il encore réalisable et testable ?
- Un MVP peut-il être développé en no-code ?
- Oui, un MVP peut être développé en no-code quand le but est de valider une demande rapidement et que les besoins de performance, de droits et de logique métier restent simples. Il faut alors accepter de reconstruire plus tard si le produit décolle, car beaucoup d'outils no-code atteignent vite leurs limites en volume, en coût par utilisateur et en dépendance à la plateforme.
- Que faire après un MVP ?
- Après un MVP, on analyse les indicateurs d'usage et les retours des utilisateurs, puis on choisit le prochain frein à lever. Chaque cycle court ajoute, modifie ou retire une fonction sur la base de ces données. On consolide aussi ce qui avait été simplifié : tests automatisés, sécurité, performance, avant d'élargir l'application à de nouveaux profils d'utilisateurs.