Un MVP n'est pas une version allégée de votre produit. Ce n'est pas non plus un prototype, ni une bêta, ni « la V1 avec moins de fonctionnalités ».

C'est le plus petit objet capable de trancher l'hypothèse la plus risquée de votre projet. Cette définition a une conséquence que la plupart des gens refusent : selon l'hypothèse à tester, un MVP peut ne contenir aucun code.

La confusion coûte cher. Elle produit des équipes qui passent six mois à construire une version réduite d'un produit dont personne n'a encore vérifié que quelqu'un le voulait — puis qui appellent ça un MVP parce qu'il manque des fonctionnalités.

Ce que « minimum » et « viable » veulent dire

Les deux mots tirent dans des directions opposées, et c'est volontaire.

Viable ne signifie pas « fonctionnel ». Il signifie capable de produire un apprentissage fiable. Une landing page qui recueille des précommandes est viable si elle vous dit quelque chose de vrai sur l'intention d'achat. Un logiciel complet qui ne trouve pas d'utilisateur n'est viable à rien.

Minimum ne signifie pas « bâclé ». Il signifie rien de plus que ce que l'apprentissage exige. Tout ce qui ne sert pas à trancher l'hypothèse est du temps dépensé sur une hypothèse que vous n'avez pas encore validée.

La question qui remplace toutes les autres : « Qu'est-ce que je saurai après, que je ne sais pas maintenant ? » Si vous ne pouvez pas y répondre en une phrase, vous n'êtes pas en train de construire un MVP, vous êtes en train de construire un produit.

Commencer par l'hypothèse, pas par le produit

Un MVP ne se conçoit pas à partir de ce que vous voulez construire. Il se conçoit à partir de ce qui peut faire tomber le projet.

Reprenez vos hypothèses — celles du Lean Canvas si vous l'avez rempli — et classez-les selon deux axes : si celle-ci est fausse, le projet s'arrête-t-il ? et combien coûte sa vérification ?

Vous obtenez quatre cas :

Vérification peu coûteuse Vérification coûteuse
Fatale si fausse 🎯 Testez maintenant Cherchez un test indirect
Non fatale Testez plus tard Ignorez pour l'instant

Le MVP sert la case en haut à gauche. Une seule à la fois.

L'erreur classique consiste à construire un objet qui teste cinq hypothèses en même temps : quand il échoue, vous ne savez pas laquelle a échoué, et vous avez dépensé cinq fois le budget nécessaire.

Les cinq formes de MVP, de la moins chère à la plus chère

1. La landing page avec engagement. Vous décrivez l'offre, vous demandez un acte qui coûte quelque chose : une précommande, un acompte, une inscription avec carte bancaire. Teste l'intention d'achat. Coût : quelques heures.

Attention au piège : une inscription gratuite à une liste d'attente ne coûte rien à celui qui la fait, et ne prouve donc rien. C'est le même travers que celui décrit dans les sept tests avant de se lancer.

2. Le concierge. Vous rendez le service à la main, sans automatisation, pour un petit nombre de clients qui paient le prix réel. Teste la valeur perçue et le prix. Coût : votre temps.

3. Le magicien d'Oz. L'utilisateur croit interagir avec un produit automatisé ; derrière l'interface, c'est vous. Teste l'usage et l'ergonomie sans construire le moteur. Coût : une interface.

4. Le produit à fonction unique. Une seule fonctionnalité, faite correctement. Teste si cette fonctionnalité suffit à déclencher l'usage. Coût : quelques semaines.

5. Le produit complet réduit. Ce que tout le monde appelle MVP. Teste beaucoup de choses en même temps, donc mal. Coût : des mois.

La règle : descendez aussi bas que possible dans cette liste. Le niveau 5 n'est justifié que lorsque les niveaux 1 à 4 ont déjà répondu à ce qu'ils pouvaient.

Sur les formes qui impliquent un premier client payant, vérifiez le cadre applicable avant de facturer : les fiches de BPI France Création détaillent les obligations qui s'appliquent dès la première vente, y compris en phase de test.

Un exemple déroulé

Reprenons le service de remplacement pour cabinets vétérinaires évoqué dans notre article sur le Lean Canvas.

L'hypothèse la plus risquée n'est pas la demande. Les vétérinaires seuls ont manifestement un problème avec les remplacements — il suffit de lire les groupes professionnels. L'hypothèse fatale est l'offre : existe-t-il assez de remplaçants disponibles et prêts à s'inscrire ? Sans eux, il n'y a pas de service, quelle que soit la demande.

Le MVP qui teste ça ne contient aucun code.

Semaine 1  Appeler 30 vétérinaires remplaçants (annuaire de l'Ordre régional)
           Question : « Si je vous proposais 3 missions par mois près de chez
           vous, contrat inclus, à ce tarif — vous inscririez-vous ? »

Semaine 2  Demander un engagement réel aux intéressés : disponibilités
           écrites sur les trois mois à venir.

Semaine 3  Placer manuellement deux remplacements entre ces vétérinaires
           et deux cliniques, contrat rédigé à la main.
           (MVP concierge, niveau 2)

Le seuil de décision, fixé à l'avance :
  15 remplaçants inscrits avec disponibilités → l'offre existe, on continue
  moins de 5                                 → l'offre n'existe pas, on arrête
  entre les deux                             → segment ou tarif à revoir

Trois semaines, aucun développement, et une réponse à la question qui décide de tout. Si l'hypothèse tombe, vous avez économisé six mois.

Le seuil de décision, fixé avant

C'est l'élément que presque tout le monde oublie, et sans lui l'exercice ne sert à rien.

Écrivez avant le test le chiffre qui vous fera arrêter. Pas après. Un MVP sans critère d'arrêt préétabli produit systématiquement le même résultat : quel que soit le chiffre obtenu, on trouve une raison de continuer. « Seulement trois inscrits, mais ils étaient très enthousiastes. »

Un bon critère est chiffré, daté, et rédigé par écrit avant le lancement du test. C'est inconfortable, et c'est précisément pour ça que c'est utile.

Ce qu'un MVP ne teste pas

Trois choses, quelle que soit sa qualité.

La rétention. Un MVP teste l'acquisition et l'intérêt initial, pas si les gens reviennent. La rétention demande du temps réel, et aucun raccourci ne l'imite.

Le passage à l'échelle. Un service rendu à la main pour dix clients ne dit rien de ce qui se passe à mille. C'est normal et ce n'est pas un défaut : ce sont deux questions différentes, à poser dans cet ordre.

Votre modèle économique complet. Un MVP peut valider que les gens paient sans rien dire de votre rentabilité. Vendre à perte est facile. C'est le seuil de rentabilité et la marge qui répondent à cette question, pas le MVP.

Les erreurs qui vident l'exercice

Construire d'abord, chercher l'hypothèse ensuite. Si vous avez décidé de ce que vous alliez construire avant d'avoir formulé l'hypothèse, ce n'est pas un MVP, c'est un produit avec un nom emprunté.

Confondre MVP et prototype. Un prototype teste la faisabilité technique, en interne. Un MVP teste le marché, avec de vrais utilisateurs et de vrais paiements. Les deux sont utiles, ils ne répondent pas à la même question.

Livrer un MVP honteux au mauvais public. Le minimum acceptable dépend du segment. Vos early adopters pardonnent l'inconfort ; le marché principal, non. Un MVP se montre aux premiers, jamais aux seconds.

Tester cinq choses à la fois. Quand ça échoue, vous ne savez pas pourquoi.

Ne pas fixer de seuil d'arrêt. Voir plus haut. C'est l'erreur qui transforme le MVP en rituel.

Appeler MVP un produit de six mois. Si votre MVP prend six mois, ce n'est pas un MVP — c'est que vous avez sauté les niveaux 1 à 4.

Ce que le MVP ne remplace pas

Un MVP vérifie une hypothèse à la fois, sur le terrain. Il ne vous dit pas quelles sont vos hypothèses, ni laquelle est la plus risquée, ni ce que fait la concurrence, ni si le marché est assez grand pour justifier l'effort.

C'est ce travail d'analyse qui vient avant — et c'est exactement ce que produit Stratify Hub : la liste des hypothèses de votre projet, hiérarchisées par risque, avec le marché chiffré et les concurrents réels en face. Le MVP vient après, pour trancher la première de la liste.

Questions fréquentes

Combien de temps doit prendre un MVP ? Le moins possible, et la question est mal posée : ce n'est pas une durée qui compte mais l'hypothèse testée. Une landing page prend deux jours, un MVP concierge deux à quatre semaines. Au-delà de six à huit semaines, il faut vérifier que vous ne construisez pas un produit en l'appelant MVP.

Faut-il faire payer dès le MVP ? Oui dès que l'hypothèse porte sur la valeur ou le prix — et c'est presque toujours le cas. Le gratuit mesure la curiosité, le payant mesure le besoin. L'écart entre les deux est le plus grand écart de l'entrepreneuriat.

Un MVP peut-il ne contenir aucune ligne de code ? Oui, et c'est souvent le meilleur. Landing page, concierge, magicien d'Oz : les trois formes les plus économiques ne demandent aucun développement. Le code n'arrive qu'une fois qu'on sait quoi coder.

Que faire si le MVP échoue ? Regarder quelle hypothèse précise est tombée. Si c'est le problème lui-même, le projet s'arrête sous cette forme. Si c'est le segment, le canal ou le prix, il se réoriente — c'est le sens du mot « pivot », qui décrit un changement d'hypothèse, pas un changement d'avis.

Quelle différence entre MVP et prototype ? Le prototype teste la faisabilité technique, en interne, sans client. Le MVP teste le marché, avec de vrais utilisateurs et, idéalement, de vrais paiements.

Cet article fait partie de notre série sur les frameworks stratégiques.