Il y a une phrase que j'entends dans presque chaque premier appel avec un fondateur : « Et si on ajoutait aussi… ». C'est la phrase la plus dangereuse du développement d'apps mobiles. Pas parce que les idées sont mauvaises — souvent elles sont bonnes — mais parce qu'elle traduit une incompréhension fondamentale de ce qu'est un MVP.
Un MVP, ce n'est pas une version allégée de votre produit final. C'est la version la plus petite possible qui permet de tester si votre hypothèse centrale est vraie. Rien de plus. Rien de moins.
Le syndrome de la liste infinie
Voici comment ça se passe en général. Vous arrivez avec 5 fonctionnalités essentielles. Pendant le cadrage, vous en ajoutez 3 « qui ne prendront pas longtemps ». Pendant le design, vous en ajoutez 2 autres « puisqu'on y est ». Pendant le dev, vous en demandez encore 1 ou 2 « pour rester compétitifs ».
Résultat : vous partez pour 60 jours de dev, vous finissez à 5 mois, le budget a explosé, et votre app sort quand votre énergie et votre argent sont déjà à plat.
La bonne question à se poser
Pour chaque feature que vous envisagez d'intégrer, posez cette question simple :
« Si on enlève cette fonctionnalité, l'utilisateur peut-il quand même accomplir son objectif principal ? »
Si la réponse est oui — même avec un peu de friction — elle n'est pas dans le MVP. Elle sera dans la V2, une fois que vous aurez des vrais utilisateurs pour vous dire si elle manque vraiment.
Les trois catégories de fonctionnalités
- Essentielles : sans elles, le produit ne fonctionne pas. Elles vont dans le MVP.
- Importantes : elles améliorent l'expérience, mais ne bloquent pas l'usage. Elles attendent la V2.
- Nice-to-have : elles seraient sympa mais personne ne les a demandées. Elles n'existent pas.
Pourquoi c'est si difficile de couper
La résistance à couper des fonctionnalités n'est pas irrationnelle. Elle vient d'une peur légitime : et si la concurrence propose ça ? Et si les utilisateurs désinstallent parce qu'il manque quelque chose ?
Mais voici la réalité : les utilisateurs désinstallent une app parce qu'elle est complexe, lente, ou qu'elle ne résout pas leur problème. Pas parce qu'il lui manque une feature secondaire. Une app simple qui fait une chose parfaitement bat toujours une app complète qui fait dix choses moyennement.
Ce que ça change en pratique
Chez ZUHD Studio, on travaille avec une règle simple : le MVP ne dépasse pas 5 à 6 fonctionnalités métier. Ce n'est pas un chiffre magique — c'est la limite au-delà de laquelle la qualité commence à se dégrader dans un dev de 60 jours.
Chaque fonctionnalité en plus, c'est du temps de design supplémentaire, du code supplémentaire, des tests supplémentaires, des bugs potentiels supplémentaires. Le coût n'est pas linéaire — il est exponentiel.
Les projets les plus réussis qu'on a livrés sont ceux où le fondateur a eu le courage de trancher, de dire « non » à la moitié de sa liste initiale. Et invariablement, quelques semaines après le lancement, ils reviennent en disant que les utilisateurs n'ont jamais demandé ce qu'ils avaient coupé — mais qu'ils adorent la fluidité du produit livré.
Si vous voulez aller plus loin sur le sujet, mon article sur comment cadrer votre projet avant de coder complète celui-ci. Et pour comprendre pourquoi le focus produit conditionne directement le fait que vos utilisateurs reviennent ou non, voir l'article sur la rétention des applications mobiles.
Vous voulez un MVP qui fonctionne vraiment ?
On commence par cadrer ensemble ce qui mérite d'être développé, et ce qui peut attendre. 30 minutes, gratuit, sans engagement.
Réserver mon appel