Périmètre du MVP : ce qu'il ne faut PAS construire est plus important

Le terme MVP — produit minimum viable — a été introduit par Frank Robinson et popularisé par le livre d'Eric Ries « The Lean Startup » (2011). Le mot clé est minimum. C'est aussi le mot que les débutants comprennent le moins bien : après « personne n'en a besoin », le plus grand tueur de lancements est « il n'a jamais été livré » — le produit s'est gonflé de fonctionnalités et n'a jamais vu le jour. Cette leçon porte sur l'outil pour réduire le périmètre.

La boucle utilisateur clé

Décrivez le SEUL chemin pour lequel les gens paient : arrive → fait l'action principale → obtient la valeur → revient. Exemple (un service de résumé d'appels) : téléchargez un enregistrement → obtenez des notes avec des actions à entreprendre → envoyez-les à l'équipe. Tout ce qui ne fait pas partie de cette boucle n'est pas un MVP.

Le cas classique : la première version d'Instagram s'appelait Burbn et permettait les enregistrements de lieux, la planification de rencontres, les points et les photos. Les utilisateurs n'ont jamais utilisé que les photos. Kevin Systrom a supprimé tout le reste et a conservé une seule boucle : prendre une photo → appliquer un filtre → publier. Deux ans plus tard, Facebook l'a racheté pour un milliard de dollars. La boucle porte le produit ; les extras le coulent.

L'outil de réduction du périmètre : trois listes

1. Maintenant (la boucle + connexion + paiement) : sans cela, il n'y a pas de produit.
2. Plus tard (une fois que vous avez de vrais utilisateurs) : thèmes, intégrations, équipes, paramètres.
3. Pas pour l'instant (les tentations) : une application mobile, une API, une marketplace. Notez-le, puis oubliez-le jusqu'à ce que vous ayez une centaine de clients.

Le test pour chaque fonctionnalité : « Un utilisateur partirait-il au cours du premier mois si cela manquait ? » Non — cela va sur la deuxième liste. Cette seule question vous fait gagner des semaines.

Une pause socratique

Vous êtes sur le point d'ajouter des « paramètres de notification » au MVP. Arrêtez-vous et demandez : une seule personne partirait-elle au cours du premier mois si les notifications fonctionnaient simplement avec des réglages par défaut sensés, sans aucun paramètre ? La réponse est presque toujours non. Ce qui signifie : liste « plus tard ».

Mythes de débutants

• « Un MVP est un mauvais produit. » Non. C'est un produit ciblé mais bon : une chose bien faite, pas dix mal faites.
• « Ça ne marchera pas sans connexion sociale / mode sombre / une application mobile. » Les choses fonctionnent avec la boucle essentielle. Les améliorations sont ajoutées une fois que vous avez de vrais utilisateurs.
• « Je vais l'ajouter juste au cas où. » « Juste au cas où » est l'expression la plus coûteuse en développement logiciel. Chaque fonctionnalité est du code, des bugs et de la maintenance — pour toujours.

Le brief produit pour l'IA

Nous prenons le brief du cours de vibe coding et le développons en un brief produit :

Produit : [nom] — [pour qui] — [valeur principale].
Boucle : [les étapes de l'utilisateur].
Pages : page d'accueil, connexion, l'application (un écran fonctionnel !), paramètres minimaux.
Données : [entités et champs — comme enseigné dans la leçon sur les bases de données].
Pas dans le MVP : [la liste « pour plus tard » — incluez-la directement dans le brief pour que l'IA ne construise pas d'extras].
Style : [référence + palette].

Cette ligne « Pas dans le MVP » est l'ingrédient secret. Un assistant IA (un modèle qui écrit du code à partir de votre description) aime être utile et combler les lacunes : demandez un formulaire de connexion et vous obtiendrez la récupération de mot de passe, l'authentification à deux facteurs et une page de paramètres de profil en prime. Une interdiction explicite maintient le périmètre sous contrôle.

Rythme et diagnostic

Un MVP construit à partir de ce brief dans Lovable/Replit prend 2 à 4 semaines de soirées. Si votre estimation est plus longue, le périmètre est encore trop large : réduisez la boucle à un seul scénario. La règle est simple — la question n'est pas « que pourrais-je ajouter d'autre », mais « que puis-je supprimer tout en gardant la boucle intacte ». Chaque élément écarté est un jour que vous n'avez pas perdu.

Où cela tourne mal : « Je ne peux rien supprimer, tout est important »

L'objection la plus courante dans cette leçon est : « mais tout dans mon produit est lié, rien ne peut être supprimé. » C'est presque toujours l'illusion de se tenir trop près de sa propre idée. Testez-le honnêtement : prenez la fonctionnalité que vous « ne pouvez pas supprimer » et imaginez un utilisateur qui ne l'ouvre jamais au cours du premier mois. Obtient-il toujours de la valeur ? Si oui, cette fonctionnalité ne fait pas partie de la boucle — elle peut et doit attendre.

Vous réduisez le périmètre non pas parce que les fonctionnalités sont mauvaises, mais parce que pour l'instant elles empêchent le produit d'être livré. Ce qui est reporté n'est pas écarté ; cela attend son tour sur la liste « pour plus tard ».

Comment cela se connecte à d'autres cours

Les données et entités pour le brief (quoi stocker et comment) feront l'objet d'une leçon dédiée sur les comptes et les données plus tard dans ce cours, et la technique de base de construction à partir d'un brief se trouve dans le cours de vibe coding. Ici, le brief passe d'un format technique à un format orienté produit — avec cette ligne explicite « Pas dans le MVP ».

Faites ceci maintenant (5 minutes)

Prenez votre idée de la leçon précédente et écrivez la boucle sous forme d'une ligne de flèches. Ensuite, listez tout ce que vous souhaitez inclure dans le produit et triez-le honnêtement dans les trois listes. Si la liste « Maintenant » contient plus de 5 éléments, continuez à réduire.