Comment lancer un MVP qui fonctionne : faire une seule chose, et la faire bien avant de vouloir en faire dix

L’acronyme MVP a été tellement utilisé qu’on l’a vidé de son sens. Aujourd’hui, on appelle MVP un simple prototype inachevé, une landing page avec un bouton "liste d’attente", voire un produit complet… mais laid. Il est temps de remettre les choses à plat.

Qu’est-ce qu’un vrai MVP ?

Minimum Viable Product. Ces trois mots sont cruciaux. Minimum : le plus petit possible. Viable : qui fonctionne vraiment pour quelqu’un. Product : pas une maquette, pas une idée, un produit.

La question n’est pas "Quelles fonctionnalités dois-je inclure ?", mais plutôt "Quelle est la seule chose que mon produit doit faire pour qu’un utilisateur paie (ou l’utilise, si vous ne monétisez pas encore) ?" Le reste viendra dans la version 2.

Le cas de Mi Seguro de Auto

Lors du développement de Mi Seguro de Auto, la tentation était grande de s’attaquer à l’ensemble du marché des assurances : voitures, motos, habitation, vie, ART. Pourtant, nous avons fait exactement l’inverse. Nous avons démarré avec un seul segment (les motos) et un seul flux (devis en 5 étapes sans appel téléphonique).

Cette décision a tout changé. Aucune calculatrice de devis pour l’assurance vie dans le menu. Aucune option pour assurer la voiture du beau-frère. Un seul bouton : "Devis moto". Cela mène l’utilisateur à travers cinq écrans jusqu’à ce qu’il obtienne un chiffre. Point.

Résultat : les gens comprennent en 3 secondes à quoi sert le produit. L’assureur, de son côté, peut mesurer la conversion. Et l’équipe de développement peut itérer sur quelque chose de concret, et non sur une plateforme théorique.

Les 3 erreurs classiques qui tuent un MVP

Erreur n°1 : Confondre MVP et "version low-cost". Un MVP n’est pas la même chose avec moins de budget. C’est autre chose : plus petit, mieux ciblé, mieux fini sur ce qu’il fait. Si votre MVP vous fait honte, ce n’est pas parce qu’il manque de fonctionnalités. C’est parce que celles qu’il a sont mal exécutées.

Erreur n°2 : Le syndrome du tableau Trello. L’équipe établit une liste de 80 fonctionnalités, les priorise, et finit par un MVP de 40. Ce n’est toujours pas assez. La bonne question n’est pas "Qu’est-ce qu’on enlève ?", mais "Si je devais livrer quelque chose demain, quelle est la seule fonctionnalité que je garde ?". Commencez par celle-là.

Erreur n°3 : Lancer en catimini. Un MVP qui n’est pas mesuré est une démo. Avant de coder, définissez : quelle est la métrique qui indique si ça fonctionne ou non ? Si c’est une plateforme de devis, la métrique est les devis finalisés, pas les visites. Si c’est un CRM, ce sont les leads qui passent d’une étape à l’autre, pas les utilisateurs enregistrés.

La checklist concrète

Avant de commencer à programmer votre MVP, notez sur une feuille :

1. Une phrase : quel problème vous résolvez et pour qui.
2. Une métrique : comment vous saurez que ça a fonctionné (un nombre concret, pas du "engagement").
3. Un flux : de A à Z, étape par étape, sans options alternatives.
4. Une date : quand vous le lancerez auprès d’utilisateurs réels (pas votre mère, des utilisateurs réels).
5. Un plan B : que faire si la métrique n’est pas atteinte sous 60 jours.

Si vous ne pouvez pas répondre à ces cinq questions, vous n’avez pas encore un MVP. Vous avez une idée. Et l’idée, c’est la partie facile. C’est l’exécution qui compte.

Combien de temps prend un vrai MVP ?

Tout dépend du secteur. Voici quelques repères : un service de devis comme Mi Seguro de Auto, développé à partir de zéro, prend entre 4 et 8 semaines si le périmètre est bien défini. Un CRM comme La Carolina, avec ses pipelines et ses propositions, prend entre 8 et 12 semaines. Une plateforme avec IA comme Tontin, où la rétention et la mémoire entre sessions sont cruciales, prend entre 12 et 20 semaines.

Si on vous propose un MVP "complet" en 2 semaines, ce que vous allez recevoir, c’est un template acheté sur ThemeForest avec votre logo dessus. Ce n’est pas un MVP.

Conclusion

Un MVP est un pari. Vous misez sur une hypothèse précise (ces gens paieront pour ça) et vous la testez avec le produit le plus petit possible capable de la valider. Plus vous le lancez rapidement auprès d’utilisateurs réels, plus vite vous saurez si l’hypothèse est bonne. Et si elle ne l’est pas, vous aurez perdu 8 semaines au lieu de 8 mois.

Si vous avez une idée en tête mais que vous ne savez pas par où commencer pour définir le périmètre, contactez-nous. En 30 minutes, nous définissons ensemble le périmètre minimal viable réel de votre produit.

---

Par Esteban Aleart, Fondateur & Lead Engineer chez Pair Programming.