Proof of concept, MVP, prototype : quelles différences ?

Un proof of concept, un prototype et un MVP ne prouvent pas la même chose et ne s’adressent pas aux mêmes personnes. Les confondre coûte cher : un POC promu en production devient une dette technique immédiate. Voici les quatre objets et l’ordre dans lequel les enchaîner.

POC, prototype, MVP et pilote : que veut dire chaque terme ?

Un POC, un prototype, un MVP et un pilote sont quatre objets distincts. Ils se séparent par deux critères : ce qu’ils prouvent et ce qu’il en reste une fois la question tranchée.

• Un proof of concept (POC) est une expérimentation technique courte, qui vérifie qu’une solution est réalisable avant tout engagement de développement.
• Un prototype est une simulation d’interface, cliquable et non fonctionnelle, qui sert à tester un parcours auprès d’utilisateurs avant d’écrire du code.
• Un MVP (minimum viable product) est la plus petite version utilisable d’un produit, mise entre les mains de vrais utilisateurs pour valider sa valeur.
• Un pilote est le déploiement d’une solution déjà construite sur un périmètre restreint, en conditions réelles, avec de vraies données.

Le critère qui tranche le plus vite un arbitrage est le dernier : ce qu’il en reste. Un POC se jette entièrement, code compris. Un prototype ne laisse que des décisions de parcours. Un MVP devient le socle du produit. Un pilote ne se jette pas non plus, il s’étend.

Qu’est-ce qu’un proof of concept (POC) et que prouve-t-il exactement ?

Un proof of concept prouve qu’une chose est techniquement possible, rien de plus. Il répond à une question fermée, posée avant le projet : cette brique fonctionne-t-elle dans notre contexte, avec nos données et nos contraintes ? En français, la traduction usuelle est preuve de concept, parfois validation de principe ou démonstration de faisabilité.

Un POC se regarde en interne : le directeur technique, l’équipe de développement, le comité qui engage le budget. Sa durée se compte en jours ou en semaines. Son livrable n’est pas un produit : du code d’expérimentation et une conclusion écrite, go ou no-go.

Le POC est redevenu central avec l’intelligence artificielle, où la faisabilité dépend d’abord de vos données. Un POC qui conclut « non » n’est pas un échec : c’est exactement sa fonction, et il coûte une fraction d’un développement engagé à l’aveugle. Le raisonnement vaut avant de déployer un agent IA.

Le risque technique devient réel dès qu’une brique n’est pas standard. Une application de reconnaissance d’espèces par IA, comme LuCEE-TP livrée pour la FNTP, repose sur un modèle dont la fiabilité se mesure d’abord.

Ce qu’un POC ne prouve jamais

Un POC ne prouve ni qu’un utilisateur veut le produit, ni que le modèle économique tient, ni que le code supportera la charge. Confondre « cela fonctionne chez un développeur » et « cela peut être exploité » est l’erreur la plus fréquente.

Qu’est-ce qu’un prototype et pourquoi ne se développe-t-il pas ?

Un prototype est une maquette cliquable qui simule le produit sans en exécuter la logique. Il prouve la désirabilité et la clarté d’un parcours, jamais la faisabilité technique. Il se fabrique dans un outil de design, se teste en quelques jours, et se jette une fois écrites les décisions qu’il a servi à prendre.

Son public est extérieur à l’équipe technique : utilisateurs cibles, comité de direction, financeurs. C’est l’objet le moins cher à modifier de toute la chaîne. Déplacer un bouton dans une maquette prend cinq minutes, dans une application livrée une itération complète.

Sans recherche utilisateur, un prototype devient un exercice de style, validé par les seuls avis internes.

Qu’est-ce qu’un MVP (minimum viable product) et où se cache le mot viable ?

Un MVP est la plus petite version d’un produit qui apporte déjà une valeur réelle à un utilisateur réel. Le mot qui compte n’est pas minimum, c’est viable : sans parcours complet, sans conformité et sans mesure, il n’y a rien à apprendre. Un MVP se met en production et devient la première brique du produit.

La définition de référence vient d’Eric Ries, qui décrit en août 2009 le minimum viable product comme la version d’un produit permettant de recueillir le maximum d’apprentissage validé sur les clients, avec le moindre effort. Le terme est plus ancien : forgé en 2001 par Frank Robinson, de SyncDev, dont SKMurphy reprend la définition en 2017.

Un MVP se juge depuis l’extérieur, par des utilisateurs qui l’adoptent ou l’abandonnent. Ma Vie d’Allergik est une application native iOS et Android que nous avons livrée pour ALK. Elle a atteint 10 000 utilisateurs 3 mois avant l’objectif fixé, avec 20 % de taux de conversion moyen.

Ce qui rend un MVP réellement viable

• Un parcours complet de bout en bout, sans étape simulée par un tableur.
• La conformité applicable dès le premier jour : RGPD, accessibilité, données de santé selon le secteur.
• Un paiement ou un engagement réel quand le produit se vend.
• Un indicateur et un seuil décidés avant le lancement.

Qu’est-ce qu’un projet pilote et en quoi diffère-t-il d’un POC ?

Un pilote est le déploiement d’une solution déjà construite sur un périmètre restreint, en conditions réelles. Il prouve qu’elle tient face aux vraies données, aux vrais utilisateurs et aux vrais processus. Contrairement au POC, un pilote ne se jette pas : soit il s’étend, soit il s’arrête sur un critère écrit avant son lancement.

La confusion avec le POC vient de leur seul point commun, le périmètre réduit. Un POC tourne sur un jeu de données de test, sans utilisateur final. Un pilote tourne sur une business unit réelle, avec des utilisateurs qui travaillent avec.

Tableau comparatif : POC, prototype, MVP et pilote

Quatre objets, cinq critères : ce qu’il prouve, qui le regarde, combien de temps il prend, ce qu’il en reste et l’erreur classique.

Critère	POC	Prototype	MVP	Pilote
Ce qu’il prouve	La faisabilité technique	La désirabilité du parcours	La valeur d’usage et la viabilité	La tenue en conditions réelles
Qui le regarde	Le directeur technique, en interne	Les utilisateurs cibles et la direction	De vrais utilisateurs, qui paient ou s’engagent	Une business unit ou un site réel
Combien de temps	Quelques jours à quelques semaines	2 à 6 semaines avec le cadrage	3 à 6 mois jusqu’en production	Un cycle métier complet
Ce qu’il en reste	Rien, sauf la conclusion écrite	Les décisions de parcours, pas les écrans	Tout : c’est le socle du produit	Le déploiement, qui s’étend
Erreur classique	Le pousser en production	Le faire développer	Retirer le viable	Le lancer sans critère d’arrêt

• POC : il prouve la faisabilité devant l’équipe technique et ne laisse qu’une conclusion écrite.
• Prototype : il prouve la désirabilité devant des utilisateurs cibles et ne laisse que des décisions de parcours.
• MVP : il prouve la valeur d’usage devant de vrais utilisateurs et devient le socle du produit.
• Pilote : il prouve la tenue en conditions réelles et s’étend au lieu d’être jeté.

Dans quel ordre enchaîner POC, prototype et MVP ?

L’ordre par défaut est POC, puis prototype, puis MVP, puis pilote. Il suit l’ordre des risques : le risque technique d’abord parce qu’il est éliminatoire, le risque d’usage ensuite, le risque de marché en dernier. Cet ordre se raccourcit dès qu’un de ces risques n’existe pas.

1. POC : lever le doute technique, sans lequel tout le reste est prématuré.
2. Prototype : faire valider le parcours et trancher les arbitrages de périmètre.
3. MVP : mettre en production la fonctionnalité cœur et mesurer l’usage réel.
4. Pilote : déployer sur une entité ou une équipe avant la généralisation.

Quand sauter une étape

• Pas de POC si la brique est standard : un formulaire, un paiement en ligne, un CMS du marché ne se prouvent plus.
• Pas de prototype si le parcours est un standard connu, déjà mesuré ailleurs sur votre site.
• Pas de MVP si le périmètre est déjà fixé par un contrat ou une obligation réglementaire.
• Pas de pilote si le périmètre cible se limite à une seule équipe.

Quelles sont les 4 erreurs classiques à éviter ?

Quatre erreurs reviennent sur la majorité des projets, et toutes consistent à faire jouer à un objet le rôle d’un autre.

1. Le POC qui part en production. Son code est écrit pour aller vite, sans tests ni gestion d’erreur. Le promouvoir crée une dette technique immédiate.
2. Le MVP qui n’est pas viable. Amputé du paiement, du support ou de la conformité, il ne se mesure pas : les utilisateurs abandonnent pour des raisons sans rapport avec l’idée testée.
3. Le prototype confié à des développeurs. Faire coder une maquette coûte bien plus cher et rend chaque modification négociable. Un prototype se dessine.
4. Le pilote sans critère d’arrêt. Sans seuil ni échéance écrits à l’avance, il devient un doublon permanent du système existant.

Combien de temps et combien coûte chaque étape ?

Un cadrage suivi d’un prototype tient en 2 à 6 semaines. La première version d’un produit digital ou d’une application en production demande 3 à 6 mois. Ce sont nos ordres de grandeur, recette comprise.

Côté budget, un projet de développement démarre à partir de 20 000 € et va jusqu’à plus de 80 000 € selon le périmètre. Le facteur qui pèse le plus n’est pas la technologie : c’est le nombre d’hypothèses encore ouvertes au lancement du développement. Chaque doute non levé se paie en itérations.

Notre méthodologie en cinq étapes place ces objets dans une même trajectoire : comprendre, définir, concevoir, développer, optimiser. Le prototype vit dans la conception, le MVP dans le développement.

Questions fréquentes

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

Un POC prouve la faisabilité technique, un MVP prouve la valeur d’usage. Le POC se regarde en interne et se jette entièrement, code compris. Le MVP se met entre les mains de vrais utilisateurs et devient la première version du produit.

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

Un prototype simule le produit, un MVP le fait fonctionner. Le prototype est une maquette cliquable sans logique derrière. Le MVP est un produit livré, avec sa conformité et sa mesure. Le premier se jette, le second devient le socle du produit à construire.

Combien de temps dure un POC ?

Un POC se compte en jours ou en semaines, jamais en mois. Sa durée dépend d’une seule variable : le temps de répondre par oui ou par non à la question posée. Un POC qui dépasse quelques semaines couvre plusieurs hypothèses au lieu d’une.

Un POC peut-il devenir un produit en production ?

Non, pas en l’état. Son code est écrit pour trancher vite, sans tests automatisés ni traitement des cas limites. Les enseignements se conservent, le code se réécrit. Le promouvoir revient à démarrer le produit avec une dette technique déjà constituée.

Faut-il toujours faire un POC avant un MVP ?

Non. Un POC ne se justifie que si une brique technique est incertaine : modèle d’IA, intégration à un système propriétaire, volumétrie inhabituelle. Sur un socle éprouvé, il fait perdre des semaines. Le raisonnement vaut pour le lancement d’un SaaS, où le risque dominant est commercial.