MVP : pourquoi commencer petit pour réussir grand

« On va tout mettre dès la première version. » C'est la meilleure façon de dépenser beaucoup, de sortir tard et de découvrir trop tard que le marché voulait autre chose. La solution : le MVP, ou produit minimum viable.

Qu'est-ce qu'un MVP ?

C'est la version la plus simple de votre produit qui apporte déjà de la valeur réelle. Pas une version bâclée : une version focalisée sur l'essentiel.

Pourquoi commencer petit

• Vous lancez plus vite sur le marché.
• Vous dépensez moins avant d'avoir validé l'intérêt.
• Vous apprenez de vrais utilisateurs, pas de suppositions.

Construire, mesurer, apprendre

On lance, on observe l'usage réel, on en tire des enseignements, et on améliore. Cette boucle évite d'investir des mois dans des fonctionnalités que personne n'utilisera.

L'erreur à éviter

Un MVP n'est pas un prétexte pour livrer un produit de mauvaise qualité. Le « V » de viable compte autant que le « M » de minimum.

Mieux vaut un produit simple que des utilisateurs adorent qu'un produit complexe que personne n'essaie.

Comment décider ce qui entre dans la première version

La difficulté n'est pas de comprendre le principe, elle est de couper. Une méthode simple donne des résultats fiables : écrivez le parcours complet de votre utilisateur principal, du problème rencontré jusqu'au résultat obtenu, puis demandez-vous, à chaque étape, si sa suppression empêche d'arriver au bout. Tout ce dont la suppression n'empêche pas d'aboutir sort de la première version, quelle que soit son élégance. Le tableau de bord d'analyse, la personnalisation du thème, le parrainage, les exports avancés : ces fonctions sont utiles, mais elles décrivent un produit mature, pas un produit qui cherche encore à prouver son intérêt.

Deux garde-fous évitent la dérive inverse. Le premier consiste à ne jamais rogner sur le socle invisible : authentification correcte, sauvegardes, journalisation des erreurs. Ce sont des fondations, pas des fonctionnalités, et leur reprise après coup coûte toujours plus cher. Le second consiste à ne pas confondre version réduite et version bâclée : un parcours court mais soigné convainc, un parcours complet mais approximatif détruit la confiance dès la première utilisation. Les critères d'interface qui font cette différence sont détaillés dans notre article sur les principes d'expérience utilisateur.

Les trois objections que l'on entend le plus souvent

La première est celle du secteur concurrentiel : sortir incomplet donnerait un avantage aux concurrents installés. En pratique, l'inverse se produit presque toujours. Un concurrent solide ne se laisse pas rattraper par une fonctionnalité de plus, il se laisse rattraper sur un usage précis mieux traité que chez lui. Autant découvrir vite lequel.

La deuxième est celle de l'image : une version réduite ferait mauvais effet auprès des clients. Elle est fondée si la réduction porte sur la finition, elle ne l'est pas si elle porte sur le périmètre. Personne ne reproche à un outil de ne pas tout faire ; on lui reproche de mal faire ce qu'il annonce. La distinction est la même que celle entre un menu court et un plat raté.

La troisième est celle du financement : un investisseur ou une banque attendrait un produit complet. C'est rarement vrai. Un produit livré, utilisé par de vraies personnes et accompagné de chiffres d'usage, même modestes, pèse davantage qu'un cahier des charges ambitieux resté sur le papier. Il montre en outre une capacité d'exécution, qui est précisément ce que l'on cherche à évaluer.

Ce qu'il faut mesurer pour que la démarche ait un sens

Une première version qui ne mesure rien n'est pas une première version, c'est un produit incomplet. Avant de livrer, décidez quelle observation vous fera dire que l'hypothèse est validée : une proportion d'utilisateurs qui reviennent la semaine suivante, un nombre de dossiers menés à terme, un taux de transformation sur une action précise. Fixez le seuil avant de voir les chiffres, sans quoi vous trouverez toujours une lecture rassurante. Prévoyez aussi le canal de retour qualitatif, souvent plus riche que les statistiques sur de petits volumes : un bouton de suggestion, un appel à dix utilisateurs, une observation directe.

Cette démarche vaut autant pour un produit vendu que pour un outil interne. Elle est particulièrement adaptée aux logiciels en abonnement, où la rétention des premières semaines détermine la viabilité du modèle, sujet développé dans notre article sur la construction d'un logiciel en abonnement rentable. Elle a aussi une conséquence sur le calendrier : livrer tôt raccourcit le délai avant les premiers enseignements, ce que détaille notre article sur les délais de développement. Enfin, elle suppose de savoir dans quel ordre les briques seront ajoutées ensuite, c'est-à-dire de raisonner sur le cycle de vie complet du projet plutôt que sur un lancement isolé, et de cadrer par écrit ce qui est reporté, comme le propose notre trame de cahier des charges.

En résumé

Commencer petit n'est pas manquer d'ambition : c'est la façon la plus sûre de réussir grand. Lisez aussi notre article sur le délai de développement. Parlons de votre MVP.