MVP, prototype ou preuve de concept : que construire en premier

Chacun teste un risque différent. Ce tableau les compare côte à côte.

Une preuve de concept, ou PoC, vérifie qu’une chose est techniquement possible. C’est généralement un petit morceau de code qui résout un problème difficile et ignore tout le reste : pas de design, pas de comptes, pas de finitions.

Par exemple, une startup qui veut extraire les montants totaux de photos de tickets manuscrits doit d’abord vérifier qu’un modèle d’IA sait les lire avec assez de précision. Sinon, aucun design ne sauvera le produit.

La plupart des produits n’ont pas besoin de PoC. Si votre idée repose sur des briques éprouvées comme les comptes, les paiements, les formulaires et les tableaux de bord, le risque technique est faible et une PoC ne fait que retarder la vraie question.

Le code d’une PoC est généralement jeté. Il a été écrit pour répondre vite à une question, pas pour porter un produit.

Un prototype montre comment le produit fonctionnera avant que quiconque n’écrive du code de production. Ce peut être une série de croquis ou une interface cliquable et réaliste qui se comporte presque comme le vrai produit.

Le guide de Nielsen Norman Group sur les prototypes basse et haute fidélité explique bien ce compromis. Les croquis simples vont plus vite et suscitent des critiques honnêtes ; les prototypes haute fidélité montrent un comportement réaliste, ce qui compte quand on teste des parcours précis.

Un prototype est aussi le meilleur outil pour mettre tout le monde d’accord. AutoIntel, un outil B2B pour le marché allemand des voitures d’occasion, a commencé comme un prototype interactif sur des annonces d’exemple. Le client l’a parcouru avec son équipe, et tous se sont accordés sur les champs et les filtres importants avant de chiffrer le traitement des données.

Un MVP, ou produit minimum viable, est la plus petite version de votre produit que de vrais utilisateurs peuvent utiliser pour de vrai. Il a des comptes qui fonctionnent, de vraies données et, là où c’est important, de vrais paiements.

L’objectif est d’apprendre, pas de lancer pour lancer. Selon les mots du Lean Startup, on construit un MVP pour « commencer le processus d’apprentissage le plus vite possible ».

Un MVP mesure ce qu’un prototype ne peut pas mesurer : si les gens reviennent, et s’ils paient. Sur CarPixly, un studio photo à base d’IA pour les annonces automobiles, chacun peut s’inscrire et explorer le studio gratuitement, et le paiement intervient au moment où la valeur apparaît, au rendu. Un tel modèle montre clairement combien de visiteurs deviennent des utilisateurs payants.

La plupart des MVP se développent en 6 à 14 semaines selon leur complexité. Nos guides sur le temps nécessaire pour développer un MVP et le coût d’un MVP SaaS donnent les fourchettes par niveau.

Commencez par l’inconnue la plus risquée. Posez-vous ces questions dans l’ordre :

• Existe-t-il un vrai risque que ce soit impossible à construire ? Par exemple, tout repose sur un modèle d’IA, un capteur matériel ou une API que vous n’avez pas testés. Construisez une preuve de concept.
• Ne sait-on pas si les gens comprennent la solution ou la veulent ? Construisez un prototype et testez-le avec des utilisateurs.
• Les gens comprennent et veulent la solution, et la question ouverte est de savoir s’ils vont l’utiliser ou payer ? Construisez un MVP.

La plupart des startups s’arrêtent à la deuxième question. La technologie est en général éprouvée ; ce qui ne l’est pas, c’est le sens du produit pour les personnes à qui il s’adresse.

Vous ne savez pas quel est le plus grand risque de votre idée ? Envoyez-nous un court brief et nous vous dirons par quelle étape nous commencerions, et pourquoi.

Un prototype n’est utile que si de vraies personnes l’essaient. Bonne nouvelle : il faut moins de testeurs que ne le pensent la plupart des fondateurs.

Les recherches de Jakob Nielsen ont montré que tester avec 5 utilisateurs révèle la plupart des problèmes d’utilisabilité d’une interface. Il conseille plusieurs petites sessions plutôt qu’une seule grande étude.

Une session de test simple se déroule ainsi :

• Donnez à chaque personne une tâche réaliste, comme « réservez une prestation pour mardi prochain ».
• Observez ce qu’elle fait sans l’aider ni lui expliquer.
• Notez où elle hésite, comprend mal ou abandonne.
• Corrigez les pires problèmes, puis testez la version suivante avec de nouvelles personnes.

Interrogez aussi les gens sur leurs habitudes actuelles : comment ils résolvent le problème aujourd’hui et ce que cela leur coûte. Cela en dit plus sur la demande que de leur demander s’ils « utiliseraient » votre produit.

Un prototype fait de croquis est un outil d’apprentissage et sera redessiné plus tard. Un prototype haute fidélité conçu avec de vrais composants est différent : ses parcours, ses écrans et son design system deviennent le point de départ du MVP.

C’est pourquoi nous concevons avec des composants réutilisables dès le premier écran. Une fois le prototype testé et validé, le développement démarre sur ces mêmes composants au lieu de réinterpréter une image.

Pour une preuve de concept, c’est l’inverse. Son code répond à une question et il est généralement réécrit proprement dans le MVP, car il n’a jamais été prévu pour de vrais utilisateurs.

Chaque étape doit se conclure par une réponse claire, pas par une impression. Écrivez ce que signifie « réussite » avant de commencer, pour que le résultat ne puisse pas être réinterprété ensuite selon vos espoirs.

• Une preuve de concept réussit quand la partie difficile fonctionne sur des données réalistes, avec la précision ou la vitesse dont le produit a besoin. « Ça marche sur trois fichiers de test » ne suffit pas si les utilisateurs en enverront des milliers.
• Un prototype réussit quand la plupart des testeurs accomplissent la tâche principale sans aide et décrivent avec leurs propres mots le problème qu’il résout.
• Un MVP réussit quand de vrais utilisateurs reviennent sans relance, ou paient, à un rythme qui justifie l’investissement suivant.

Si une étape échoue, c’est utile aussi. Une preuve de concept ratée vous évite un développement coûteux. Un prototype déroutant vous dit de changer le parcours tant que les changements coûtent encore peu.

Fixez aussi une limite de temps à chaque étape. Un prototype que l’on peaufine encore après des mois n’est plus un test : c’est devenu un produit que personne ne peut encore utiliser.

Parfois, oui. Si vous avez déjà testé l’idée, par exemple avec une version manuelle du service, vous en savez peut-être assez pour passer directement au MVP.

Par exemple, une personne qui met en relation depuis des mois, à la main, des clients et des professeurs particuliers, avec des tableurs et des messages, connaît déjà les parcours et les questions que posent les gens. Un prototype confirmerait surtout ce qu’elle sait déjà.

Sauter cette étape a du sens quand trois conditions sont réunies : la technologie est éprouvée, vous avez vu de vraies personnes suivre le processus, et vous savez quelle partie du processus le logiciel doit prendre en charge en premier. S’il en manque une, le prototype reste le moyen le moins cher de le découvrir.

Les mêmes erreurs reviennent sans cesse :

• Appeler MVP un prototype. Les clics sur un prototype montrent la compréhension, pas l’usage ni le paiement. Ne confondez pas les deux.
• Polir une preuve de concept jusqu’à en faire un produit. Du code écrit pour répondre à une seule question devient une base fragile pour tout ce qu’on construit dessus.
• Sauter le prototype. Construire un MVP avant d’avoir testé les parcours, c’est payer des développeurs pour découvrir des problèmes de design.
• Mettre trop de choses dans le MVP. Chaque fonctionnalité en plus repousse le moment où vous saurez si le cœur fonctionne.
• Tester avec des amis. Les gens qui vous apprécient loueront l’idée. Testez avec des personnes qui ont le problème et aucune raison d’être gentilles.

Prêt à choisir votre première étape ? Parlez-nous de votre idée et nous vous aiderons à choisir entre preuve de concept, prototype et MVP.