Prototype, MVP ou produit ? Comment valider une idée avant d'investir

Beaucoup de projets produit commencent par la fin : ils construisent la solution avant de savoir si le problème existe, qui l'a et combien il est prêt à payer pour le résoudre. Quand la réponse arrive, le budget est déjà dépensé.

Un prototype, un MVP et un produit répondent à des questions différentes. Les confondre, c'est payer pour répondre à la mauvaise question. Ce guide montre quoi construire à chaque étape, un calendrier de quatre semaines pour valider une idée et les signaux qui indiquent s'il faut avancer ou s'arrêter.

D'abord le problème, ensuite la solution

Avant de décider quoi construire, validez le problème et le processus qui l'entoure. Qui a ce problème ? Comment le résout-il aujourd'hui : avec quels outils, quelles étapes, combien de temps perdu ? Que lui coûte le fait de ne pas le résoudre ?

Ces réponses vous disent s'il existe un problème qui vaut la peine d'être résolu et montrent par où la solution doit passer. Une solution conçue sans comprendre le processus du client résout un problème que personne n'a, ou résout le bon problème de la mauvaise façon.

Écrivez l'hypothèse

Avant d'écrire une seule ligne de code, complétez cette phrase :

« Je pense que [type de client] paiera [montant] pour [solution] parce que [problème]. »

Si vous ne pouvez pas remplir tous les blancs, vous n'êtes pas encore prêt à construire. Et définissez dès maintenant ce qui compte comme un succès et comme un échec : quelle réponse, de combien de personnes, vous ferait avancer ou vous arrêter.

Prototype, MVP ou produit : quoi construire à chaque étape

Prototype

• La question à laquelle il répond : « les gens comprennent-ils cela et le veulent-ils ? »
• Ce qu'il comporte : des écrans cliquables, une page de présentation, une courte vidéo qui montre l'idée.
• Ce qu'il ne comporte pas : un vrai backend, l'authentification, les paiements.

MVP

• La question à laquelle il répond : « quelqu'un l'utilise-t-il et paie-t-il pour cela ? »
• Ce qu'il comporte : le parcours principal qui fonctionne réellement, avec uniquement les fonctionnalités qui prouvent la valeur. En coulisses, une partie du travail peut être faite à la main.
• Ce qu'il ne comporte pas : tout ce qui n'est pas nécessaire pour répondre à la question.

Produit

• La question à laquelle il répond : « comment le proposer à de nombreux clients de façon fiable ? »
• Ce qu'il comporte : robustesse, sécurité, performance, tests, supervision et support.
• Quand : seulement après que le MVP a montré un signal clair de demande.

Ce qu'est (et ce que n'est pas) un MVP

MVP signifie Minimum Viable Product (produit minimum viable), et les trois mots comptent :

• Minimum : le moins possible pour répondre à une question.
• Viable : il fonctionne vraiment, ce n'est pas une maquette.
• Product : quelqu'un peut l'utiliser et payer pour.

Ce n'est pas un MVP :

• un Figma « interactif » sans backend ;
• une page « bientôt disponible » avec liste d'attente ;
• une version « bêta » qui met des mois à sortir.

Ces éléments ont de la valeur, mais ils valident un intérêt, pas un produit. Ils relèvent de l'étape du prototype.

Un calendrier de 4 semaines pour valider

Quatre semaines, c'est un rythme de travail, pas une promesse : l'objectif est d'obtenir une réponse, pas un produit fini.

Semaine 1 : entretiens. Parlez à des clients potentiels du problème et de la façon dont ils le résolvent aujourd'hui. Pas de démonstration, seulement des questions. Continuez jusqu'à entendre les mêmes réponses. Cherchez des tendances, pas des compliments.

Semaine 2 : prototype. Des écrans, une page de présentation et une courte vidéo. Toujours pas de vrai code.

Semaine 3 : prévente ou équivalent. Montrez le prototype à des personnes qui correspondent au profil et demandez un engagement concret : un paiement anticipé, un pilote payant, une lettre d'intention ou un rendez-vous avec le décideur. Un oui assorti d'un engagement vaut mieux que beaucoup de compliments.

Semaine 4 : construction minimale. Uniquement le parcours dont ont besoin les personnes qui se sont engagées. Faire une partie du travail à la main en coulisses est acceptable à ce stade. L'objectif est de livrer le premier client.

Les signaux pour avancer et les signaux pour s'arrêter

Vous êtes sur la bonne voie quand :

• des clients sont prêts à payer avant que le produit existe ;
• ils demandent des fonctionnalités précises, pas génériques ;
• ils se plaignent quand quelque chose ne marche pas, parce qu'ils en dépendent déjà.

Il est temps de s'arrêter ou de changer de cap quand :

• la réponse de presque tout le monde est « intéressant, mais… » ;
• on vous demande une remise avant d'avoir vu la valeur ;
• personne ne recommande la solution à d'autres.

S'arrêter est aussi un résultat. Découvrir en quatre semaines que l'idée ne prend pas coûte beaucoup moins cher que de le découvrir après avoir construit le produit.

Les MVP qui échouent (et pourquoi)

• Trop complets. L'envie de « bien faire » retarde le lancement jusqu'à ce que le marché ait déjà changé.
• Construits avant de comprendre le processus. La solution ne s'intègre pas à la façon de travailler du client, et personne ne l'adopte.
• Sans plan de distribution. On l'a construit, on l'a lancé, et personne n'en a entendu parler. Faire parvenir le MVP aux bonnes personnes fait partie du MVP.
• Sans critères de succès et d'échec. « Si ça marche, on continue » n'est pas un critère. Définissez avant de construire ce qui compte comme un signal pour avancer.

Conclusion

Construire dans le bon ordre n'est pas lent. C'est le moyen le plus rapide d'arriver à quelque chose qui fonctionne : d'abord le problème et le processus, ensuite le prototype, puis le MVP et seulement à la fin le produit. À chaque étape, ne construisez que ce qu'il faut pour répondre à la question de cette étape.

Questions fréquentes

Quelle est la différence entre un prototype et un MVP ?

Le prototype teste si les gens comprennent et veulent l'idée, sans vrai backend. Le MVP teste si quelqu'un l'utilise et paie pour elle, avec le parcours principal qui fonctionne réellement.

Combien de temps faut-il pour valider une idée ?

Cela dépend du problème et de l'accès aux clients. Le calendrier de quatre semaines de cet article est une référence de rythme : entretiens, prototype, prévente et construction minimale.

Un MVP peut-il reposer sur des processus manuels ?

Oui. À ce stade, faire une partie du travail à la main en coulisses est un moyen peu coûteux de tester la valeur avant d'automatiser.

Quand passer du MVP au produit ?

Quand le MVP montre un signal clair de demande : des clients qui paient, qui continuent à l'utiliser et qui recommandent la solution.