Quelles features dans ton MVP (et lesquelles virer)

Ton MVP a trop de features. C’est le cas de la quasi-totalité des fondateurs qui me contactent : une liste de 15 fonctionnalités “indispensables”, un budget qui explose, et pas un seul utilisateur.

3 features maximum. Pas 5, pas 8. Trois.

La règle des 3 features

Le réflexe naturel quand tu définis le périmètre fonctionnel de ton MVP, c’est de lister tout ce que ton produit “doit” faire. Profils, recherche, messagerie, notifications, paiement, analytics, avis, favoris, partage social, personnalisation…

Stop.

Ce que tu penses être le scope minimum de ton produit minimum viable, divise-le par deux. Puis refais-le deux fois. Tu tombes sur 3 features. C’est ton MVP.

Pourquoi 3 ? Parce que chaque feature supplémentaire allonge le délai, augmente le budget et retarde le moment où tu mets ton produit entre les mains de vrais utilisateurs. Et c’est le feedback de ces utilisateurs qui valide ton marché - pas ta liste de features.

Les MVPs célèbres avaient moins que tu crois

• Airbnb : poster une annonce, voir les annonces, réserver. Trois features. Pas de paiement intégré au début, pas d’avis, pas de messagerie.
• Buffer : programmer un tweet. Une seule feature. La landing page a validé la demande avant même que le produit existe.
• Dropbox : une vidéo de démo. Zéro feature codée. La vidéo a généré 75 000 inscriptions en une nuit.

Ces exemples ne sont pas des exceptions. Ils illustrent un principe que les fondateurs de la méthode lean startup répètent depuis 15 ans : le MVP ne teste pas ton produit. Il teste ton hypothèse de marché.

La contrainte de temps comme outil de tri

Une autre approche fonctionne : fixe la deadline d’abord, ajuste le scope ensuite.

Si ton MVP ne peut pas être construit en 4 à 6 semaines, tu as trop de features. La plupart des fondateurs qui réussissent à lancer convergent vers cette règle : ce qui tient dans un mois de développement, c’est la bonne quantité. Si ça déborde, coupe des features. Ne repousse pas la deadline.

C’est exactement le principe derrière un MVP en 4 semaines.

Comment prioriser tes features

Tu as ta liste de 12 features. Tu dois la réduire à 3. Voici deux méthodes concrètes.

MoSCoW en pratique

La méthode MoSCoW classe chaque feature en 4 catégories :

• Must have : le produit ne fonctionne pas sans. Si tu la retires, il n’y a plus de produit.
• Should have : important, mais le produit tient debout sans. Deuxième itération.
• Could have : bonus si le temps le permet. V2.
• Won’t have : pas dans cette version. Point final.

Exemple concret avec une app de réservation de restaurants :

Résultat : 3 Must Have. C’est ton MVP.

L’erreur classique : classer 6 features en Must Have parce que “le produit serait bizarre sans”. Si tu ne peux pas réduire à 3 Must Have, tu n’as pas encore trouvé ta proposition de valeur core. Reviens à la question : quel problème unique tu résous ?

La feature la plus risquée d’abord

La plupart des fondateurs construisent les features les plus faciles en premier. C’est l’inverse de ce qu’il faut faire.

Construis la feature la plus risquée d’abord. Celle dont tu n’es pas sûr qu’elle fonctionne, qu’elle plaise aux utilisateurs, ou qu’elle soit techniquement faisable. Teste-la de la manière la plus rapide qui te donne une confiance raisonnable dans le résultat.

Un développeur a passé 4 mois à construire un système de collaboration en temps réel avec gestion des conflits et mode offline pour un outil de gestion créative. Au lancement, les utilisateurs ont demandé un export CSV. Une feature faisable en quelques heures.

Il avait construit la feature la plus excitante techniquement au lieu de tester la plus risquée commercialement. L’hypothèse risquée n’était pas “peut-on collaborer en temps réel ?” mais “les créatifs ont-ils besoin d’un nouvel outil de gestion ?”

Avant de coder, définis ton hypothèse principale et construis le test le plus rapide pour la valider. Le reste, c’est de l’optimisation prématurée. Ton cahier des charges devrait commencer par cette hypothèse, pas par une liste de features.

Les features essentielles par type d’app

Tous les MVPs ne se ressemblent pas. Une marketplace, un SaaS B2B et une app mobile grand public n’ont pas les mêmes must have.

Marketplace

Le minimum pour qu’une marketplace fonctionne : des profils (vendeurs et acheteurs), une recherche avec filtres basiques, un moyen de communiquer entre les deux parties, et un paiement sécurisé.

Les avis ? Tu n’as pas de contenu au lancement. Les favoris ? Personne ne favoritise quand il n’y a que 20 annonces. Les notifications push ? Inutiles avec tes 30 premiers utilisateurs.

Le piège des marketplaces, c’est le problème de la poule et de l’œuf : tu as besoin de vendeurs pour attirer des acheteurs et vice versa. Ta priorité n’est pas les features. C’est l’acquisition d’un côté du marché.

SaaS B2B

Un SaaS B2B MVP a besoin de quatre choses : authentification (login + gestion de compte), un dashboard qui montre les données clés, une feature core (celle qui résout le problème principal de tes utilisateurs), et la facturation.

L’erreur fréquente en SaaS B2B : construire des intégrations trop tôt. “Il faut s’intégrer à Slack, à HubSpot, à Salesforce…” Non. Tes 10 premiers clients paieront pour ta feature core, pas pour une intégration Zapier.

App mobile grand public

Trois features suffisent : un onboarding fluide (2-3 écrans maximum), la feature core qui résout le problème utilisateur, et des notifications pour le rappeler que l’app existe.

La personnalisation, le social, la gamification - tout ça vient après. Les early adopters tolèrent un produit minimal s’il résout leur problème. Ils ne tolèrent pas un produit qui essaie de tout faire et qui le fait mal.

Pour estimer le budget selon ton type d’app, consulte la grille de prix d’une application mobile.

Les erreurs qui tuent les MVPs

Le piège du “juste une feature de plus”

Le feature creep tue plus de MVPs que les bugs techniques.

Des fondateurs dépensent des dizaines de milliers d’euros et des mois de travail à construire en isolation, certains que les plaintes des utilisateurs sur les produits existants indiquent un marché. Ils lancent. Zéro client.

Le problème n’est pas le produit. C’est l’absence de validation avant la construction. Chaque feature ajoutée “au cas où” est une hypothèse non testée déguisée en certitude.

Un fondateur a passé un an sans lancer. Il ajoutait sans cesse des features “nécessaires” - dont un système complet de suppression de compte automatisé. Personne ne s’est jamais inscrit grâce à une fonction “supprimer mon compte”.

Le test pour chaque feature : est-ce que quelqu’un va s’inscrire grâce à ça ? Si la réponse est non, elle attend la V2.

Pour valider ton idée avant de coder, il existe des méthodes plus rapides et moins chères qu’un MVP complet.

Le niveau de finition dépend du marché

“Minimum” ne veut pas dire “bâclé”. Mais le niveau de finition acceptable dépend de ton contexte concurrentiel.

Si tu crées un marché qui n’existe pas encore, ton MVP peut être rugueux. L’important c’est qu’il fonctionne. Personne ne va te comparer à un concurrent qui n’existe pas.

Si tu attaques un marché saturé avec des acteurs établis, tes 2-3 features core doivent être irréprochables. Tu ne peux pas être “un peu moins bien” sur un marché où les utilisateurs ont déjà des alternatives gratuites.

La règle : moche, c’est OK. Peu de features, c’est OK. Buggé, ça ne l’est pas.

Features techniques vs features produit

Quand un fondateur dit “mon MVP a 3 features”, il oublie souvent la moitié du travail.

L’authentification, l’hébergement, le monitoring, le tracking d’erreurs, les emails transactionnels, le RGPD - ce sont des features techniques. Invisibles pour l’utilisateur, mais elles consomment du budget et du temps de développement.

Ne les compte pas dans tes 3 features produit. Mais compte-les dans ton budget.

Un exemple : un fondateur liste “profils + recherche + paiement” comme ses 3 features. Mais le paiement seul implique l’intégration Stripe, la gestion des webhooks, les emails de confirmation, la facturation et la conformité PCI. C’est une feature produit qui cache 5 features techniques.

Si tu n’en es pas encore là, un prototype permet de tester l’expérience utilisateur sans payer le développement technique.

Si tu veux que je t’aide à construire le tien, c’est exactement ce que fait mon agence vibe coding à Paris.

Foire aux questions

Combien de features dans un MVP ?

3 maximum. Un MVP doit résoudre un seul problème avec le minimum de fonctionnalités. Les MVPs de Airbnb, Buffer et Dropbox ont tous lancé avec 1 à 3 features core. Si tu ne peux pas décrire ton MVP en une phrase, tu as trop de features.

C’est quoi la méthode MoSCoW pour un MVP ?

MoSCoW classe tes features en 4 catégories : Must have (indispensable pour que le produit fonctionne), Should have (important mais pas bloquant), Could have (bonus si le temps le permet), Won’t have (pas dans cette version). Pour un MVP, tu ne gardes que les Must have. L’exemple travaillé plus haut montre comment passer de 12 features à 3.

Quelles sont les features essentielles d’une marketplace MVP ?

Quatre features minimum : profils utilisateurs (vendeurs et acheteurs), recherche avec filtres, messagerie entre utilisateurs et paiement sécurisé. Les avis, favoris et notifications push sont du nice-to-have pour la V2.

Comment éviter le feature creep ?

Fixe la deadline avant le scope. Si ton MVP ne peut pas être construit en 4 à 6 semaines, tu as trop de features. Chaque nouvelle demande doit passer le test : est-ce que quelqu’un va s’inscrire grâce à cette feature ? Si la réponse est non, elle attend la V2.

Faut-il inclure l’authentification dans un MVP ?

Oui, si ton app gère des données personnelles ou du paiement. L’auth n’est pas une feature produit, c’est une feature technique. Elle consomme du budget mais elle est invisible pour l’utilisateur. Compte-la dans le budget technique, pas dans tes 3 features.

Quelle différence entre un MVP et un prototype ?

Le prototype teste la faisabilité et l’expérience utilisateur. Le MVP teste le marché avec de vrais utilisateurs et de vraies transactions. Un prototype peut être un Figma cliquable. Un MVP est un produit fonctionnel, même minimal.

Combien de temps pour développer un MVP avec 3 features ?

Entre 2 et 6 semaines selon la complexité. Un MVP marketplace avec profils, recherche et paiement prend environ 4 semaines. Un SaaS B2B avec auth, dashboard et une feature core peut être livré en 2 semaines avec le vibe coding.

Comment savoir si une feature est must have ou nice-to-have ?

Pose-toi deux questions. Est-ce que le produit fonctionne sans cette feature ? Si oui, c’est du nice-to-have. Est-ce que quelqu’un va s’inscrire grâce à cette feature ? Si non, elle peut attendre.

Peut-on ajouter des features après le lancement ?

Oui, et c’est exactement le principe du MVP. Lance avec 3 features, collecte le feedback des premiers utilisateurs, puis ajoute les features que tes utilisateurs demandent réellement. Les features ajoutées après le lancement sont mieux ciblées que celles imaginées avant.

Un MVP peut-il n’avoir qu’une seule feature ?

Oui. Buffer a lancé avec une seule feature : programmer des tweets. Dropbox a lancé avec une vidéo de démo, sans produit du tout. Le M de MVP signifie minimum. Si une seule feature suffit à tester ton hypothèse de marché, c’est assez.