Décision produit
POC, prototype ou MVP : que faut-il réellement construire ?
Un POC prouve un point de faisabilité, un prototype rend une solution testable et un MVP confronte une première offre utilisable au réel. Le vocabulaire compte moins que la question, le public du test et le critère de décision.
Trois livrables, trois décisions différentes
Ces définitions sont des repères, pas des normes universelles. Deux équipes peuvent employer le même mot pour des livrables très différents. Avant de signer un devis, il faut donc écrire ce qui sera testé, par qui, dans quel environnement et ce qui arrivera au livrable après le test.
- POC : est-ce faisable dans les conditions qui comptent ?
- Prototype : cette solution fonctionne-t-elle suffisamment pour être comprise et testée ?
- MVP : une première offre utilisable produit-elle un apprentissage réel auprès de son marché ?
Choisir un POC lorsqu’un verrou de faisabilité bloque la suite
Le POC isole une hypothèse critique : portée radio, précision d’un capteur, performance d’un algorithme, compatibilité d’une API, autonomie ou capacité d’un procédé. Il peut être volontairement incomplet et jetable.
Un bon POC possède un protocole, des conditions réalistes et un seuil de réussite. Une démonstration qui fonctionne une fois sur un bureau ne prouve pas qu’elle fonctionnera dans l’environnement du produit.
Choisir un prototype pour rendre la solution testable
Le prototype peut être visuel, mécanique, électronique ou fonctionnel. Il sert à apprendre sur la forme, l’usage, l’intégration ou l’assemblage. Il ne doit pas être présenté comme productionnable s’il ne respecte pas encore les contraintes de sécurité, de coût, de qualité ou de maintenance.
Dans un produit physique, plusieurs prototypes sont souvent nécessaires : preuve de principe, architecture représentative, prototype d’intégration puis présérie. Les appeler tous simplement “le prototype” masque des objectifs très différents.
Choisir un MVP pour apprendre auprès d’utilisateurs réels
Le MVP est une première offre suffisamment cohérente pour être utilisée dans un contexte réel. Il réduit le périmètre, pas l’exigence sur ce qui pourrait nuire à l’utilisateur, aux données ou à la réputation de l’entreprise.
Un écran cliquable peut valider la compréhension d’un parcours ; il ne valide pas l’usage récurrent ni le paiement. À l’inverse, développer toute l’infrastructure avant d’avoir testé la proposition de valeur transforme le MVP en produit complet construit trop tôt.
La grille de choix en cinq questions
- Quelle hypothèse pourrait encore rendre le projet inutile ou impossible ?
- Qui doit observer ou utiliser le livrable pour que le test ait du sens ?
- Quel comportement ou quelle mesure permettra de décider ?
- Le livrable doit-il être jeté, repris ou exploité après le test ?
- Quelles exigences de sécurité, de données, de conformité ou de fabrication sont déjà non négociables ?
Trois pièges fréquents
- Transformer un POC en production sans revoir son architecture, ses tests et sa sécurité.
- Construire un prototype très fidèle alors que le problème utilisateur n’est pas encore confirmé.
- Appeler MVP une version réduite qui ne permet aucun apprentissage mesurable sur le marché.
Sources et méthode
Cette ressource combine le retour d’expérience de Brice Cavelier et des sources primaires consultées le 20 août 2026. Elle décrit une méthode de décision, pas une règle universelle applicable sans tenir compte du projet.
La suite logique