MVP, prototype, POC : ces trois termes circulent dans toutes les conversations autour du lancement d'un produit digital. Ils sont souvent utilisés de façon interchangeable, y compris par des gens qui travaillent dans le secteur depuis longtemps. C'est une source de confusion qui a des conséquences concrètes : des budgets mal calibrés, des délais sous-estimés, et des livrables qui ne correspondent pas à ce que le client attendait.
Ce ne sont pas trois façons de dire la même chose. Ce sont trois objets différents, construits à des stades différents d'un projet, pour répondre à des questions différentes. Savoir lequel vous avez besoin selon votre situation, c'est gagner du temps et de l'argent avant même d'avoir écrit la première ligne de code.
Le POC : prouver que c'est faisable
POC signifie Proof of Concept, ou preuve de concept en français. C'est la première étape d'un projet qui soulève une question technique : est-ce que cette idée est réalisable avec les technologies disponibles ?
Un POC n'est pas destiné aux utilisateurs. Il n'est pas destiné à être montré à des clients ou à des investisseurs comme un produit fini. C'est un objet interne, souvent rudimentaire visuellement, qui sert à répondre à une question précise : est-ce que ce qu'on veut construire est techniquement possible, dans quelles conditions, et avec quelles contraintes ?
Quand faire un POC. Quand votre projet implique une brique technologique que vous n'avez jamais utilisée, une intégration avec un système tiers dont vous ne connaissez pas encore le comportement, ou une fonctionnalité dont la faisabilité technique est incertaine. Si vous n'êtes pas sûr que ce que vous voulez construire peut être construit, le POC répond à cette question avant d'engager un budget de développement complet.
Ce que ça produit. Un POC produit typiquement une démonstration technique fonctionnelle sur un périmètre très restreint. Pas d'interface utilisateur soignée, pas de gestion des cas d'erreur, pas de scalabilité. Juste la preuve que le mécanisme central fonctionne.
Ce que ça ne produit pas. Un POC n'est pas réutilisable tel quel dans le produit final. C'est du code exploratoire, souvent jeté ou profondément remanié ensuite. Son rôle est de valider une hypothèse technique, pas de poser les bases du produit.
En termes de budget et de délai. Un POC bien cadré se réalise en quelques jours à quelques semaines selon la complexité de la question à résoudre. C'est délibérément court et limité.
Le prototype : valider le design et le parcours
Un prototype est une représentation visuelle et interactive de votre produit ou de votre interface, sans les fonctionnalités réelles derrière. On clique sur des boutons, on navigue entre des écrans, on perçoit le flux de l'application, mais rien ne fonctionne vraiment en arrière-plan. C'est une simulation.
Le prototype répond à une question différente du POC : non pas "est-ce que c'est faisable ?" mais "est-ce que c'est compréhensible et utilisable ?". Il sert à valider le design de l'interface, la logique de navigation, et l'expérience utilisateur avant d'investir dans le développement.
Quand faire un prototype. Avant de commencer le développement d'une interface complexe. Avant de présenter un projet à des parties prenantes (investisseurs, direction, équipes métier) pour obtenir un arbitrage sur le design. Avant de faire des tests utilisateurs pour identifier les points de friction dans le parcours.
Ce que ça produit. Un prototype est généralement réalisé dans un outil de design comme Figma. Il peut aller du wireframe basse fidélité (des boîtes et du texte qui schématisent la structure) au prototype haute fidélité (un design pixel-perfect avec des interactions réalistes). Le niveau de fidélité dépend de l'objectif : un wireframe suffit pour valider une architecture d'information, un prototype haute fidélité est nécessaire pour des tests utilisateurs sérieux ou une présentation à des investisseurs.
Ce que ça ne produit pas. Un prototype ne contient pas de code fonctionnel. Il ne peut pas être "converti" en application réelle : le développement repart de zéro en s'appuyant sur le prototype comme référence visuelle.
En termes de budget et de délai. Un prototype basse fidélité se réalise en quelques jours. Un prototype haute fidélité couvrant un périmètre fonctionnel complet peut prendre deux à quatre semaines selon la complexité du produit.
Le MVP : lancer le minimum qui apporte de la valeur
MVP signifie Minimum Viable Product, ou produit minimum viable. C'est le terme le plus connu des trois, et aussi le plus mal compris. Il est souvent interprété comme "un produit avec le moins de fonctionnalités possible", ce qui est inexact et trompeur.
Un MVP est un produit réel, fonctionnel, déployé et utilisé par de vrais utilisateurs. Il contient le minimum de fonctionnalités nécessaires pour apporter une valeur réelle à ses premiers utilisateurs et pour permettre d'apprendre de leur usage. Ce n'est pas un produit dégradé : c'est un produit ciblé, qui fait peu de choses mais les fait bien.
La question à laquelle répond un MVP est différente des deux précédentes : non pas "est-ce que c'est faisable ?" ni "est-ce que c'est utilisable ?", mais "est-ce que des gens l'utilisent vraiment et en tirent de la valeur ?".
Quand faire un MVP. Quand vous voulez valider un marché avant d'investir dans un produit complet. Quand vous avez une hypothèse sur le besoin de vos utilisateurs et que vous voulez la confronter à la réalité. Quand vous êtes dans une phase de lancement où l'apprentissage rapide est plus important que la complétude fonctionnelle.
Ce que ça produit. Un MVP est un produit réel, avec une vraie base de code, un vrai hébergement, de vrais utilisateurs. Il peut être rudimentaire sur certains aspects (interface minimaliste, fonctionnalités secondaires absentes), mais il fonctionne et apporte une valeur concrète à ceux qui l'utilisent.
Ce que ça ne produit pas. Un MVP n'est pas un produit fini. Il manque des fonctionnalités, il peut avoir des imperfections, et il est conçu pour évoluer rapidement selon les retours des premiers utilisateurs. Ce n'est pas ce que vous présentez à un grand compte comme votre produit définitif.
En termes de budget et de délai. Un MVP représente un investissement réel en développement. Selon la complexité du produit, il peut prendre de quelques semaines à plusieurs mois et coûter de 15 000 à 60 000 euros ou plus. C'est moins qu'un produit complet, mais ce n'est pas anodin.
Le lien avec le Crédit d'Impôt Innovation
C'est un point de connexion important pour les PME françaises. Le Crédit d'Impôt Innovation (CII) finance précisément la phase de conception de prototypes de produits nouveaux. Dans la terminologie fiscale, le "prototype" du CII englobe ce que le secteur tech appelle POC et MVP quand il s'agit d'un produit logiciel inédit.
Ce qui est éligible au CII : la conception d'un POC qui lève un verrou technique (si le caractère innovant est démontré par rapport à l'état de l'art), et la conception d'un MVP qui constitue un produit logiciel nouveau sur le marché. Ce qui n'est généralement pas éligible : un prototype de maquette Figma seul (pas de développement), la maintenance ou les évolutions d'un produit existant, et la conception de produits qui reproduisent l'existant sans innovation.
Si votre projet implique un POC ou un MVP sur une brique technologique innovante, l'éligibilité au CII mérite d'être étudiée en amont avec votre expert-comptable ou un cabinet spécialisé.
Comment choisir selon votre situation
Voici une grille de lecture directe pour les situations les plus courantes.
Vous avez une idée mais vous n'êtes pas sûr que c'est techniquement réalisable. Commencez par un POC. Validez la faisabilité technique avant d'investir dans le design ou le développement complet.
Vous savez que c'est faisable mais vous voulez valider le design et le parcours avant de développer. Faites un prototype. C'est beaucoup moins coûteux que de développer une interface complète pour découvrir ensuite que les utilisateurs ne comprennent pas le flux.
Vous voulez lancer rapidement pour tester le marché et apprendre des vrais utilisateurs. Construisez un MVP. Définissez le périmètre minimal qui apporte une valeur réelle, développez-le correctement, et itérez selon les retours.
Vous avez un projet complexe qui implique une brique technique incertaine ET une interface à valider. Les trois étapes peuvent se succéder dans l'ordre : POC pour lever le verrou technique, prototype pour valider l'interface, MVP pour lancer et apprendre. Ce n'est pas toujours nécessaire de passer par les trois, mais sur des projets ambitieux, chaque étape réduit le risque de la suivante.
Les erreurs fréquentes
Confondre prototype et MVP. Un prototype Figma n'est pas un MVP. Un MVP est fonctionnel et utilisé par de vrais utilisateurs. Présenter un prototype à des clients comme "notre MVP" crée des attentes fausses sur ce qu'ils vont pouvoir utiliser.
Sur-spécifier le MVP. L'erreur classique : vouloir que le MVP contienne toutes les fonctionnalités "importantes". Un MVP avec 40 fonctionnalités n'est pas un MVP, c'est un produit complet. La discipline de la sélection est ce qui rend le MVP utile : qu'est-ce qui est absolument nécessaire pour apporter de la valeur à l'utilisateur et apprendre quelque chose d'utile ?
Sauter le prototype pour "aller plus vite". Développer directement sans avoir validé le design coûte souvent plus cher que de faire le prototype. Découvrir après trois mois de développement que le parcours utilisateur ne fonctionne pas, c'est recommencer. Un prototype de deux semaines peut éviter ce scénario.
Ne pas définir ce qu'on veut apprendre avec le MVP. Un MVP sans hypothèse à tester n'est pas un MVP, c'est un lancement prématuré. Avant de construire, définissez : qu'est-ce que ce MVP doit nous permettre de valider ou d'infirmer ? Quels indicateurs vont répondre à cette question ?
Ce qu'on retient
POC, prototype et MVP ne sont pas des synonymes. Le POC valide la faisabilité technique. Le prototype valide le design et le parcours utilisateur. Le MVP valide l'adéquation produit-marché avec de vrais utilisateurs.
Choisir le bon objet selon le stade de votre projet, c'est allouer votre budget au bon endroit. Un POC avant un développement incertain évite de construire sur des sables mouvants. Un prototype avant un développement lourd évite de retravailler une interface qui ne fonctionne pas. Un MVP avant un produit complet évite d'investir massivement dans quelque chose que le marché ne veut pas.
Ces trois étapes sont aussi celles que le Crédit d'Impôt Innovation peut financer quand elles impliquent de l'innovation : un argument supplémentaire pour structurer son projet en phases plutôt que de tout lancer d'un seul coup.
Voir aussi :
