Le MVP est l'un des concepts les plus mal compris de l'entrepreneuriat logiciel. On commence avec un périmètre minimal, puis les demandes s'accumulent, les fonctionnalités s'ajoutent, et six mois plus tard on n'a toujours rien livré. Rester focus est une discipline à part entière.
Le Minimum Viable Product est une idée simple : livrer le plus tôt possible la version la plus réduite du produit qui apporte une valeur réelle à ses premiers utilisateurs. En théorie, tout le monde est d'accord. En pratique, le MVP est systématiquement contaminé par la peur de paraître incomplet, les demandes des parties prenantes, et la tentation de préparer « l'après ».
Les ennemis du MVP
Le premier ennemi est interne : le perfectionnisme. Un MVP laid, lent ou limité reste un MVP — à condition qu'il serve son objectif d'apprentissage. Le deuxième ennemi est externe : les demandes clients précoces. Avant même d'avoir validé l'hypothèse centrale du produit, des prospects formulent des besoins spécifiques. Chaque demande semble raisonnable. L'ensemble transforme le MVP en usine à gaz. Le troisième ennemi est organisationnel : la pression des investisseurs ou du management, qui confond richesse fonctionnelle et valeur.
Ce que « viable » signifie vraiment
Viable ne signifie pas complet. Cela signifie que le produit permet de répondre à une question précise : est-ce que quelqu'un est prêt à payer pour résoudre ce problème de cette façon ? Airbnb a commencé avec un site statique et des photos prises avec un appareil photo ordinaire. Dropbox a commencé avec une vidéo de démonstration, sans produit fonctionnel. Ces MVP n'étaient pas incomplets — ils étaient exactement dimensionnés pour valider leur hypothèse.
Techniques pour rester focus
- Écrire le problème, pas la solution : l'énoncé du problème à résoudre doit tenir en une phrase. Toute fonctionnalité qui ne sert pas directement cet énoncé est hors scope MVP.
- Le MoSCoW appliqué au MVP : Must have (indispensable à la valeur core), Should have (important mais pas bloquant), Could have (nice to have), Won't have (explicitement exclu). Si votre liste de Must-have dépasse cinq items, vous ne faites pas un MVP.
- Timebox immuable : fixer une date de livraison non négociable. Quand le temps est limité, les priorités deviennent réelles.
- Dire non avec un backlog : chaque demande écartée du MVP est notée dans un backlog daté. Ça permet de dire non sans rejeter l'idée — elle a juste sa place après la validation.
Un backlog court et priorisé est la marque d'un MVP discipliné.
Un MVP qui n'est jamais livré n'apprend rien. Un MVP livré avec trois fonctionnalités et dix utilisateurs réels vous apprend plus que six mois de spécification.