.avif)
.svg)
.svg){kind=small}
Sommaire
Publié le
24/7/26
-
5 min
Vous avez une idée de produit et vous ne savez pas par quel bout la prendre ? Découvrez notre accompagnement en product management, pensé pour transformer une intuition en périmètre chiffrable.
Tout le monde connaît le principe du MVP. Presque personne ne l'applique correctement. Dans les faits, l'immense majorité des projets qui nous arrivent sous l'étiquette « MVP » comportent déjà quinze fonctionnalités, trois profils utilisateurs et un back-office complet. Ce n'est plus un MVP, c'est un produit v1 avec un budget de MVP. Et c'est précisément ainsi qu'on perd de l'argent.
Un MVP, pour Minimum Viable Product, est la plus petite chose que vous puissiez construire pour apprendre quelque chose de décisif sur votre marché. Le mot important n'est ni « minimum » ni « product » : c'est « viable ». Votre MVP doit résoudre un vrai problème pour un vrai utilisateur, du début à la fin du parcours. Une fonctionnalité bâclée n'est pas un MVP, c'est un prototype raté.
La nuance vient de la méthode Lean Startup formalisée par Eric Ries, qui pose une boucle simple : construire, mesurer, apprendre. Le MVP n'est que la première brique de cette boucle. Sa valeur ne se mesure pas à ce qu'il contient, mais à ce qu'il vous apprend.
1. Un MVP n'est pas une maquette. Une maquette ne génère aucun comportement réel, seulement des déclarations d'intention.
2. Un MVP n'est pas une version bêta. Une bêta suppose que le produit est déjà défini et qu'on cherche des bugs. Un MVP suppose l'inverse : le produit n'est pas défini, on cherche à savoir s'il doit exister.
3. Un MVP n'est pas un produit gratuit. Si votre hypothèse est que les gens paieront, alors le MVP doit faire payer. Sinon vous testez l'attractivité, pas le modèle économique.
D'après les analyses de post-mortems menées par CB Insights, la raison numéro un d'échec des startups n'est ni le financement, ni la concurrence, ni l'équipe : c'est l'absence de besoin réel sur le marché, citée par environ quatre startups défaillantes sur dix. Le manque de trésorerie arrive derrière, et il n'en est souvent que la conséquence.
Autrement dit : la majorité des produits qui échouent ne meurent pas parce qu'ils étaient mal construits. Ils meurent parce qu'ils n'auraient pas dû être construits. C'est une information que le marché aurait pu vous donner avant, pour une fraction du coût.
Commencer petit n'est pas une stratégie d'économie, c'est une stratégie de risque. Vous n'essayez pas de dépenser moins, vous essayez de dépenser plus tard, une fois que l'incertitude principale est levée.
Prenez le raisonnement à l'envers. Si votre produit complet représente un budget de 80 000 euros et que vous avez 40 % de chances que le marché n'en veuille pas, votre espérance de perte est de 32 000 euros. Un MVP à 20 000 euros qui répond à cette question divise votre exposition par plus de deux, quelle que soit la réponse obtenue. Un « non » vaut alors très cher, dans le bon sens du terme.
La plupart des porteurs de projet arrivent avec une solution en tête et cherchent ensuite le problème qu'elle résout. C'est confortable et c'est la source d'à peu près toutes les erreurs de périmètre.
Trois questions suffisent à remettre les choses d'aplom. :
- Quel problème précis, et pour qui ?
- À quelle fréquence ce problème se pose-t-il ?
- Comment vos utilisateurs le résolvent-ils aujourd'hui, faute de votre produit ?
C'est la troisième qui compte le plus. Si la réponse est « ils ne font rien », le problème n'est probablement pas assez douloureux. Si la réponse est « ils s'en sortent avec un tableur et beaucoup de patience », vous tenez quelque chose.
Imaginons une application destinée aux freelances pour suivre leurs missions. Formulé côté solution, le projet devient un outil de gestion de projet, donc un marché saturé où vous n'avez aucun avantage. Formulé côté problème, il devient : « un freelance qui gère six clients en parallèle ne sait pas, à un instant donné, combien il a facturé et combien il lui reste à livrer ». C'est beaucoup plus étroit, beaucoup plus vérifiable, et cela désigne immédiatement les deux ou trois fonctionnalités qui comptent.
Cette étape se conclut par un travail de persona. Nous détaillons la méthode dans notre guide sur les buyer personas, mais retenez le principe : un persona utile décrit un contexte et une frustration, pas une tranche d'âge et un métier.
La priorisation MoSCoW, issue du cadre DSDM, classe chaque fonctionnalité en quatre catégories : Must have, Should have, Could have, Won't have this time. Son intérêt tient au dernier terme. La plupart des méthodes de priorisation permettent de dire « plus tard ». MoSCoW oblige à dire « pas cette fois », ce qui est un engagement bien plus ferme.
Point que presque tout le monde ignore : le cadre DSDM recommande que les fonctionnalités classées Must have ne dépassent pas 60 % de l'effort total du projet, et qu'une réserve d'environ 20 % soit conservée en Could have. Au-delà de ce seuil, la prévisibilité du projet s'effondre.
Appliquez ce ratio à votre MVP et l'exercice devient brutalement clair : si tout est indispensable, rien ne l'est, et votre périmètre n'a pas été arbitré.
Un second filtre, plus simple encore. Listez le parcours minimal qu'un utilisateur doit pouvoir accomplir de bout en bout pour que le produit ait du sens. Tout ce qui n'est pas sur ce chemin sort du périmètre, sans discussion. Un compte utilisateur, une page de réglages et un tableau de bord ne sont presque jamais sur ce chemin.
Cette discipline alimente ensuite votre roadmap produit : ce que vous écartez aujourd'hui n'est pas perdu, c'est daté.
La séquence est toujours la même. Un wireframe pose la structure sans se préoccuper du style. Un prototype cliquable rend le parcours testable. Figma couvre les deux étapes et reste l'outil de référence pour les faire circuler auprès de personnes non techniques.
Une incompréhension détectée sur une maquette coûte une heure de retouche. La même incompréhension détectée après développement coûte plusieurs jours, parfois une refonte de modèle de données. C'est le meilleur rapport entre effort investi et risque évité de tout le projet.
C'est aussi le moment où l'UX design prend le pas sur l'UI design. Sur un MVP, la qualité du parcours prime largement sur la sophistication visuelle. Notre équipe design UX/UI travaille systématiquement dans cet ordre.
Les plateformes no-code permettent de mettre un produit fonctionnel en ligne en quelques semaines. Webflow pour une interface publique et une landing page de conversion, Bubble pour une application avec logique métier et comptes utilisateurs, Airtable comme base de données pilotable par une équipe non technique.
Le compromis est réel et il faut l'énoncer : vous gagnez en vitesse, vous perdez en maîtrise des coûts à l'échelle et en liberté d'architecture. Notre comparatif des outils no-code et low-code détaille les seuils à partir desquels la bascule devient nécessaire.
Si votre différenciation repose sur un algorithme, un traitement de données lourd, une intégration complexe ou des exigences de conformité, le no-code devient un plafond dès le premier jour. C'est typiquement le cas d'un logiciel SaaS à destination de professionnels. Nous avons chiffré les postes de dépense dans notre article sur le développement SaaS sur mesure.
En pratique, la combinaison gagnante consiste souvent à traiter la partie visible en no-code et à développer sur mesure le seul composant qui porte votre valeur. Vous concentrez le budget technique là où il est réellement différenciant.
Une erreur classique consiste à lancer, puis à regarder les chiffres pour voir ce qu'ils racontent. Faites l'inverse. Avant la mise en ligne, écrivez noir sur blanc le seuil qui validera ou invalidera votre hypothèse. Par exemple : 30 % des inscrits complètent le parcours principal dans les sept jours. Sans ce seuil défini à l'avance, toute donnée devient interprétable dans le sens qui vous arrange.
Les métriques d'usage vous disent ce que les gens font. Elles ne vous disent jamais pourquoi. Un outil d'analyse comportementale comme Hotjar (https://www.hotjar.com/) montre où les utilisateurs décrochent, mais seuls des entretiens vous diront ce qu'ils cherchaient à ce moment-là.
Dix entretiens de vingt minutes avec des utilisateurs réels apportent plus qu'un sondage à deux cents réponses. Les premiers révèlent des raisons, le second confirme surtout vos propres questions.
C'est la question que la boucle Lean Startup pose à chaque cycle. Trois issues sont possibles : le marché confirme et vous investissez, le marché rejette et vous économisez le reste du budget, ou le marché révèle un besoin voisin et vous pivotez. Ces trois réponses sont des succès du MVP. Le seul échec, c'est de ne rien apprendre.
Une fois l'hypothèse validée, la vraie question devient budgétaire. Nous l'avons traitée dans notre guide sur le budget à prévoir pour faire évoluer un MVP après son lancement.
1. Élargir le périmètre en cours de route. Chaque ajout repousse le moment où vous apprenez quelque chose, et c'est exactement ce que le MVP cherchait à éviter.
2. ?Lancer sans hypothèse écrite. Si vous ne savez pas ce que vous testez, aucun résultat ne pourra vous contredire.
3. Confondre enthousiasme et validation. Les compliments de vos proches ne sont pas des données. Un utilisateur qui revient sans y être invité en est une.
4. Soigner le produit plutôt que le parcours. Un MVP peut être visuellement modeste. Il ne peut pas être incompréhensible.
5. Attendre d'être prêt. Le produit n'est jamais prêt. Le seul repère fiable est le parcours minimal complet défini à l'étape 2.
Commencer petit n'est pas une posture d'économie, c'est une méthode pour acheter de l'information au meilleur prix. Un MVP bien cadré coûte une fraction d'un produit complet et vous dit s'il faut le construire. Un MVP mal cadré coûte presque autant qu'un produit complet et ne vous dit rien.
La différence entre les deux se joue entièrement à l'étape 2, sur la capacité à écrire noir sur blanc ce que vous ne ferez pas. C'est la partie inconfortable du travail, et c'est celle où un regard extérieur a le plus de valeur.
Vous voulez savoir ce que représente votre MVP en périmètre, en budget et en délai ? Décrivez-nous votre projet, nous revenons vers vous sous 48 h avec un chiffrage argumenté : demander un devis.
