La difficulté dans la définition d'un MVP n'est pas de trouver des idées de fonctionnalités — c'est d'en retirer. Chaque fonctionnalité ajoutée allonge le délai, augmente le budget et complique la recette. Le périmètre minimum n'est pas une contrainte : c'est une discipline de décision.
Ce document propose une méthode concrète pour arbitrer et définir ce qui entre dans la v1.
La question centrale : quelle hypothèse teste-t-on ?
Chaque fonctionnalité en v1 doit se justifier par rapport à l'hypothèse principale à valider. Si une fonctionnalité ne contribue pas directement à cette validation, elle attend la v2. C'est le seul critère d'arbitrage qui tient face aux pressions d'équipe ou de parties prenantes.
Exemple : si l'hypothèse est « des freelances acceptent de payer pour accéder à des briefs clients qualifiés », les fonctionnalités nécessaires sont : création de compte freelance, accès à une liste de briefs, contact avec le client. Tout le reste (profil public, portfolio, messagerie intégrée) est de la v2.
La méthode MoSCoW appliquée au MVP
La méthode MoSCoW classe les fonctionnalités en quatre catégories : Must have (sans ça, le produit ne fonctionne pas), Should have (important mais contournable), Could have (nice-to-have), Won't have for now (explicitement exclu).
Pour un MVP, le périmètre v1 se limite aux Must have. Les Should have sont des candidats v2. Cette clarté évite les glissements de périmètre en cours de développement.
Les fonctionnalités presque toujours en v1
Authentification (inscription, connexion, mot de passe oublié), la fonctionnalité centrale de valeur (ce pour quoi l'utilisateur vient), et un moyen de nous contacter ou de signaler un problème. Ces trois éléments sont non-négociables.
Si votre produit génère des transactions, Stripe est aussi un Must have. Si votre produit implique plusieurs rôles (admin + utilisateur), la gestion des accès est un Must have.
Les fonctionnalités presque toujours en v2
Dashboard analytics, export de données, notifications email avancées, gestion multi-équipes, API publique, intégrations tierces non critiques, mode sombre, internationalisation. Ces fonctionnalités sont réelles et importantes — mais elles n'empêchent pas de valider l'hypothèse principale.
Mettre ces fonctionnalités en v2 n'est pas les abandonner. C'est les traiter au bon moment, avec les bonnes priorités, sur la base de retours utilisateurs réels.