Combien de fonctionnalités dans un MVP ?

« Combien de fonctionnalités dans un MVP, cinq, dix, vingt ? » La question revient à chaque cadrage, et elle est mal posée. Un MVP ne se compte pas en nombre de fonctionnalités. Un produit avec vingt features superficielles peut être inutilisable, là où un produit avec six features qui couvrent un parcours complet rend un vrai service. Le bon repère n'est pas un chiffre, c'est la complétude d'un seul chemin.

Le bon nombre de fonctionnalités dans un MVP n'est pas un nombre fixe : c'est exactement ce qu'il faut pour qu'un utilisateur traverse de bout en bout le parcours qui teste votre hypothèse, sans trou ni détour. En pratique, cela donne souvent cinq à huit fonctionnalités, mais c'est le résultat d'un raisonnement, jamais une cible posée d'avance.

Si vous cadrez votre premier produit, le cadre d'ensemble est dans le guide du MVP au PMF. Ici, on règle la question du volume une bonne fois.

Le bon objet n'est pas la feature, c'est le parcours

Raisonner en liste de fonctionnalités mène toujours à l'inflation, parce qu'une liste invite à ajouter. Raisonnez plutôt en parcours : quel est l'enchaînement d'actions qu'un utilisateur doit pouvoir réaliser, de la première rencontre au moment où il retire la valeur que vous promettez ? Ce parcours a un début, une fin, et aucun trou autorisé entre les deux. Les fonctionnalités du MVP sont exactement celles qui rendent ce chemin possible, ni plus, ni moins.

La conséquence est contre-intuitive. Couper un parcours en deux pour « faire plus de fonctionnalités » est pire que de n'en livrer qu'un seul entier. Un utilisateur qui bute sur un trou au milieu de son chemin ne vous apprend rien, sauf que votre produit est cassé. C'est pourquoi la vraie discipline n'est pas de minimiser le nombre de features, mais de garantir qu'aucune étape du parcours retenu ne manque.

Le piège des features « au cas où »

L'inflation ne vient presque jamais du parcours critique. Elle vient des fonctions périphériques qu'on ajoute « au cas où » : un second type d'utilisateur, un tableau de bord administrateur riche, des paramètres avancés, trois intégrations « que les clients vont sûrement demander ». Chacune semble raisonnable isolément. Mises bout à bout, elles doublent le périmètre et retardent la seule chose qui compte : mettre le parcours central devant de vrais gens.

La règle est simple et radicale : si une fonctionnalité ne sert pas le parcours qui teste votre hypothèse, elle n'est pas dans le MVP. Pas reportée dans une zone grise, pas « si on a le temps » : hors périmètre, écrit noir sur blanc. C'est l'application directe de la méthode must / should / cut que je détaille dans comment réduire le périmètre de son MVP. Le « au cas où » est toujours un should déguisé en must.

Comment compter, concrètement

Voici la démarche que j'applique en cadrage pour aboutir au juste volume. Elle part toujours du parcours, jamais de la liste de souhaits.

Pourquoi le bon compte fait baisser le coût

Compter juste n'est pas qu'une affaire de méthode produit, c'est une affaire de budget. Chaque fonctionnalité hors parcours est du temps de build, de la surface de bug et de la maintenance que vous payez avant même d'avoir prouvé que votre cœur intéresse quelqu'un. Ramener le MVP au seul parcours critique est, de loin, le premier levier pour tenir un budget, ce que je détaille dans combien coûte un MVP et dans MVP qui coûte trop cher.

C'est aussi le cœur de mon travail de cadrage : transformer une liste de souhaits en un parcours net, et défendre ce parcours contre la tentation d'en faire « un peu plus ». Le bon nombre de fonctionnalités, c'est celui qui vous met le plus vite devant la vérité du marché, et pas une de plus.