MVP vs MMP

MVP et MMP : quatre lettres qui se ressemblent, un glissement de sens qui coûte cher. La plupart des équipes utilisent "MVP" pour désigner la première version de leur produit qu'elles comptent lancer sur le marché. C'est une erreur de définition — et cette erreur a des conséquences concrètes sur ce qu'on construit, pour qui, et dans quel ordre.

La confusion courante

Dans les discussions produit, "MVP" est devenu un mot valise. On l'entend pour parler d'une V1 allégée, d'un produit beta, d'une version "sans toutes les features", ou d'un lancement limité à quelques utilisateurs. Ces usages partagent une idée — faire moins — mais ils n'ont pas le même objectif, ni la même cible, ni la même définition du succès.

La confusion entre MVP et MMP n'est pas anodine. Elle pousse des équipes à lancer au grand public une version trop rudimentaire pour être utilisée sérieusement, ou à l'inverse, à attendre d'avoir un produit trop abouti avant d'aller valider leurs hypothèses. Dans les deux cas, on perd du temps et de l'argent — mais pas pour les mêmes raisons.

Qu'est-ce qu'un MVP ?

Le Minimum Viable Product est un concept introduit par Frank Robinson en 2001 et popularisé par Eric Ries dans The Lean Startup. Sa définition originale est précise : un MVP est la version d'un produit qui permet de collecter le maximum d'apprentissages validés sur les clients avec le minimum d'effort.

Le mot clé n'est pas "produit" — c'est apprentissage. Un MVP est un outil d'expérimentation, pas une version allégée d'un produit fini. Son objectif n'est pas de satisfaire des utilisateurs, mais de tester une hypothèse.

Quelques exemples de ce qu'un MVP peut être — et qui surprennent souvent :

Une landing page qui décrit un service qui n'existe pas encore, pour mesurer si des gens cliquent sur "s'inscrire"
Une vidéo de démonstration d'un produit fictif pour valider l'intérêt avant d'écrire une ligne de code (c'est ce que Dropbox a fait en 2007)
Un service manuel où l'équipe fait "à la main" ce que le logiciel fera plus tard, pour valider que la promesse intéresse des vrais clients (c'est ce qu'a fait Zappos au début : acheter les chaussures en magasin après chaque commande reçue)
Un prototype non fonctionnel testé en entretien utilisateur pour valider l'ergonomie d'une idée

Un MVP peut donc ne pas être un logiciel du tout. Ce qui le définit, c'est qu'il permet de répondre à une question précise — "Est-ce que des gens ont ce problème ?" ou "Paieraient-ils pour cette solution ?" — avec le moins de travail possible.

La cible d'un MVP n'est pas le grand public. C'est un groupe restreint de testeurs, d'early adopters, ou simplement quelques dizaines de personnes à qui vous posez une question déguisée en produit.

Qu'est-ce qu'un MMP ?

Le Minimum Marketable Product est la première version d'un produit suffisamment aboutie pour être mise sur le marché auprès d'un vrai public. Elle n'a pas toutes les fonctionnalités souhaitées — elle en a le minimum — mais celles qu'elle a fonctionnent correctement, sont polies, et créent une valeur réelle pour l'utilisateur.

L'objectif du MMP n'est plus d'apprendre : c'est de vendre (ou d'acquérir, de fidéliser, selon votre modèle). Le succès ne se mesure plus en insights validés, mais en métriques business : taux de conversion, rétention, revenu, NPS.

Un MMP, c'est un produit dont on n'a pas honte. Pas un produit parfait — mais un produit qui tient sa promesse sur le périmètre qu'il couvre. Si votre application de gestion de tâches ne permet que de créer et cocher des tâches, c'est acceptable pour un MMP — à condition que ces deux fonctionnalités soient irréprochables.

	MVP	MMP
Objectif	Tester une hypothèse	Aller sur le marché
Cible	Testeurs, early adopters internes	Grand public, premiers clients
Mesure de succès	Apprentissage validé	Métriques business
Qualité attendue	Suffisante pour l'expérimentation	Suffisante pour être utilisée sérieusement
Exemples	Landing page, prototype, Wizard of Oz	V1 publique, beta ouverte

L'analogie du skateboard et du vélo

L'image classique pour illustrer la différence vient du monde du développement itératif. Imaginez que vous devez livrer un moyen de transport :

Construire pour apprendre (MVP) : vous livrez d'abord une planche à roulettes bancale. Elle roule, à peine. Elle ne tient pas sous la pluie, elle est inconfortable, et elle n'ira nulle part à grande vitesse. Mais elle permet de valider l'essentiel : est-ce que la personne veut se déplacer de façon autonome ? Est-ce que ce besoin est réel ? Avec ce skateboard, vous apprenez.

Construire pour vendre (MMP) : vous livrez un vélo. Pas un vélo de course, pas un vélo électrique avec GPS intégré — mais un vélo fonctionnel, stable, avec des freins qui marchent et une selle réglable. Il est utilisable au quotidien. Il crée de la valeur immédiate. Il peut être vendu.

La différence n'est pas dans la quantité de fonctionnalités, mais dans l'intention et dans la cible. Le skateboard bancal est parfait pour un MVP — personne ne s'attend à l'utiliser tous les jours. Le vélo basique est le minimum pour un MMP — si les freins ne fonctionnent pas, le produit ne devrait pas exister.

Lancer un skateboard bancal auprès du grand public sous prétexte que "c'est un MVP" est l'erreur la plus courante — et la plus coûteuse.

Quand utiliser l'un ou l'autre

Utilisez un MVP quand vous avez une hypothèse à valider avant d'investir dans le développement. Vous ne savez pas encore si le problème existe vraiment, si votre solution est la bonne, ou si des gens paieraient pour elle. Le MVP est votre outil de réduction d'incertitude. Plus tôt dans la vie d'un produit, plus c'est pertinent.

Questions typiques auxquelles un MVP répond :

"Est-ce que des gens cherchent activement une solution à ce problème ?"
"Notre positionnement est-il compris en moins de 10 secondes ?"
"Est-ce que quelqu'un sortirait sa carte bancaire pour cette promesse ?"

Utilisez un MMP quand les hypothèses fondamentales sont validées et que vous êtes prêt à acquérir des utilisateurs réels. Vous savez que le problème existe, vous avez une idée claire de la solution, et vous voulez commencer à construire une base d'utilisateurs ou de clients. Le MMP est votre premier pas commercial.

Questions typiques auxquelles un MMP répond :

"Est-ce que les utilisateurs reviennent après la première utilisation ?"
"Quel est notre coût d'acquisition ?"
"Quelle fonctionnalité manquante bloque le plus la conversion ?"

En pratique, la séquence naturelle est : hypothèse → MVP → apprentissage → MMP → croissance. Le MVP précède le MMP ; ils ne sont pas interchangeables.

Les erreurs courantes à éviter

Lancer un MVP au grand public. C'est l'erreur la plus fréquente. Un MVP n'est pas fait pour des utilisateurs qui ne savent pas qu'ils sont des cobayes. Si vous lancez une version expérimentale à des milliers de personnes sans les prévenir, vous ne faites pas un MVP — vous faites un mauvais MMP. Et vous abîmez votre réputation avant même d'avoir une base solide.

Appeler "MVP" ce qui est en réalité un MMP raté. Dire "c'est un MVP, c'est normal que ça bugue" pour excuser une mauvaise qualité sur un produit public, c'est utiliser le vocabulaire lean comme bouclier. La vraie question est : pour qui est ce produit, et quelle promesse lui fait-on ?

Sauter le MVP pour aller directement au MMP. C'est l'erreur inverse : construire directement une V1 "commercialisable" sans avoir validé que le problème existe ou que la solution est la bonne. Des mois de développement pour découvrir que personne ne voulait du produit — c'est le récit de la majorité des startups qui échouent.

Confondre "minimal" avec "médiocre". Un MMP est minimal en termes de périmètre, pas en termes de qualité. Ce que le produit fait, il doit le faire bien. Réduire le périmètre est une décision stratégique ; livrer quelque chose de cassé est une erreur d'exécution.

MVP et MMP répondent à deux questions différentes. Le MVP répond à "Est-ce qu'on construit la bonne chose ?" Le MMP répond à "Est-ce qu'on est prêt à la vendre ?" Les confondre, c'est risquer de livrer trop tôt ce qui devait rester interne, ou trop tard ce qui aurait pu générer de la valeur depuis longtemps. Garder les deux définitions claires, c'est se donner les moyens de prendre les bonnes décisions — au bon moment.