Différence entre POC, prototype et MVP

POC, prototype, MVP : trois mots qu'on emploie souvent comme des synonymes, et c'est une erreur qui coûte cher. Ce ne sont pas trois noms pour la même chose, ni trois étapes obligatoires d'une même séquence. Ce sont trois outils distincts, chacun conçu pour répondre à une question précise. Confondre les trois, c'est répondre à une question qu'on ne se posait pas, et croire qu'on a avancé.

Un POC teste la faisabilité (« est-ce techniquement possible ? »), un prototype teste la désirabilité (« est-ce que les gens en veulent et le comprennent ? »), un MVP teste la viabilité (« est-ce que ça peut devenir une activité réelle ? »). On choisit l'outil selon la question la plus risquée du moment, et on ne fait pas les trois par principe.

Si vous cadrez votre premier produit, le cadre d'ensemble est dans le guide du MVP au PMF. Ici, on clarifie les trois outils pour que vous n'investissiez pas dans le mauvais.

Trois questions, trois outils

La distinction n'est pas une affaire de taille ou de qualité de code. Elle est une affaire d'intention. Avant de lancer quoi que ce soit, identifiez quelle est votre incertitude dominante. Si vous ne savez pas si c'est techniquement faisable, vous n'avez pas besoin d'une belle interface. Si vous doutez que les gens en veuillent, vous n'avez pas besoin d'un backend robuste.

La règle qui évite 90 % des erreurs

Ne demandez jamais « lequel dois-je construire ? ». Demandez « quelle est l'hypothèse qui, si elle est fausse, tue mon projet en premier ? ». Si c'est une hypothèse technique (cette techno tient-elle la charge, cette intégration existe-t-elle, ce modèle d'IA est-il assez précis), c'est un POC. Si c'est une hypothèse d'usage (les gens comprennent-ils, en veulent-ils, sont-ils prêts à changer d'habitude), c'est un prototype. Si la faisabilité et le désir sont acquis et qu'il reste à prouver qu'on peut en vivre, c'est un MVP. L'outil découle de la peur, pas de l'envie.

Voici les trois outils côte à côte, avec ce qu'ils prouvent et ce qu'ils ne prouvent pas.

Outil	Question testée	Ce qu'il prouve	Ce qu'il ne prouve pas	Public
POC	Faisabilité technique	Que c'est possible de construire	Que quelqu'un en veut ou paiera	Interne, équipe technique
Prototype	Désirabilité, usage	Que les gens comprennent et adhèrent	Que ça tient techniquement ou se vend	Quelques utilisateurs cibles
MVP	Viabilité, marché	Que ça peut devenir une activité	Que ça scalera sans réécriture	Vrais utilisateurs, marché

Le POC : « est-ce possible ? »

Le POC, ou preuve de concept, ne s'adresse à personne d'autre qu'à votre équipe. Il est souvent moche, jetable, codé à la va-vite, et c'est très bien ainsi. Son seul but est de lever un doute technique : une intégration tient-elle, un algorithme donne-t-il un résultat acceptable, une performance est-elle atteignable. On le garde le plus court possible, et surtout on le jette une fois la réponse obtenue. Le danger du POC, c'est de tomber amoureux de son code de brouillon et de vouloir le transformer en produit.

Le prototype : « les gens en veulent-ils ? »

Le prototype ne contient parfois aucune ligne de code fonctionnel. Une maquette cliquable, un faux écran, une vidéo de démonstration peuvent suffire. Sa question n'est pas technique mais humaine : l'utilisateur comprend-il à quoi ça sert, en a-t-il envie, change-t-il une habitude pour ça ? On le met entre les mains de quelques personnes cibles, on observe, on écoute. Le prototype est l'outil le moins cher pour éviter de construire un produit dont personne ne veut, l'erreur la plus coûteuse du lot, que je range parmi les erreurs à éviter au lancement d'un MVP.

Le MVP : « peut-on en faire une activité ? »

Le MVP, lui, est un vrai produit, mis entre les mains de vrais utilisateurs, dans des conditions réelles. Faisabilité et désir étant supposés acquis, il teste la viabilité : les gens l'utilisent-ils dans la durée, sont-ils prêts à payer, le coût d'acquisition est-il soutenable ? C'est le seul des trois qui se mesure en rétention, en conversion, en revenu. Et c'est le seul qui justifie d'investir dans un parcours complet plutôt qu'un écran isolé, un point que je développe dans combien de fonctionnalités dans un MVP.

Lequel, et quand : ne pas faire les trois par défaut

L'erreur classique consiste à dérouler les trois comme une séquence obligatoire : POC, puis prototype, puis MVP. Dans beaucoup de projets, c'est du temps et de l'argent gaspillés. Si votre faisabilité technique ne fait aucun doute, sautez le POC. Si votre désirabilité est évidente parce que des concurrents existent et que la demande est prouvée, allez plus vite vers le MVP. La séquence n'est pas un rituel, c'est une réponse à vos incertitudes réelles, et certaines cases sont déjà cochées avant de commencer.

C'est exactement le type d'arbitrage que je tranche en cadrage : quelle est l'incertitude qui mérite un test, et quel est l'outil le plus léger pour y répondre. Choisir le bon outil au bon moment, c'est souvent diviser par deux le coût d'apprentissage, ce que je relie au budget global dans combien coûte un MVP.

On choisit le bon outil ensemble ?

J'interviens comme CTO fractional armé d'IA pour identifier votre vraie incertitude et tester la bonne hypothèse au moindre coût. Découvrez le Sprint Fondateur, ou réservons 30 minutes pour décider POC, prototype ou MVP.