On conseille souvent aux fondateurs et aux équipes produit de « construire un MVP » alors qu'ils ont en réalité besoin d'un prototype ou d'une preuve de concept. Chacun répond à une question différente, demande un effort différent et produit un résultat différent. Choisir le bon permet de gagner du temps et de réserver le budget à l'étape qui en a réellement besoin. Ce guide explique les différences et propose une manière simple de décider.
Définition
Une preuve de concept (PoC) répond à une question technique : est-ce faisable ? Elle peut vérifier si une API renvoie les données dont vous avez besoin, si un modèle peut classer des documents avec une précision suffisante, ou si deux systèmes peuvent s'intégrer dans des limites acceptables. Une PoC est généralement restreinte, jetable et n'est pas montrée aux clients. Un prototype répond à une question de conception et d'ergonomie : cela a-t-il du sens pour les utilisateurs ? Il peut s'agir d'écrans cliquables ou d'une interface légère sans données réelles, utilisés pour tester des parcours, recueillir des retours et aligner les parties prenantes. Un produit minimum viable (MVP) répond à une question de marché : de vrais utilisateurs vont-ils l'utiliser, revenir ou payer ? Un MVP est un logiciel fonctionnel avec des données réelles, déployé auprès de vrais utilisateurs, et délibérément limité au plus petit ensemble de fonctionnalités qui apporte la valeur centrale. Comme de vraies personnes l'utilisent, un MVP exige une attention appropriée à l'authentification, au traitement des données et à la maintenabilité, même si son périmètre fonctionnel est réduit.
Public concerné
Cette comparaison est utile pour :
- Les fondateurs qui s'apprêtent à commander leur premier développement
- Les équipes produit d'entreprises établies qui explorent un nouveau service numérique
- Les investisseurs ou conseils d'administration qui se demandent ce que le prochain jalon doit produire
- Les équipes qui ont construit un prototype et ne savent pas s'il peut devenir le produit
Ce qu'il aide à clarifier
Choisir entre eux aide à clarifier :
- Quel risque est le plus important à ce stade : faisabilité technique, ergonomie ou demande du marché
- De quels éléments la prochaine décision a besoin, et qui la prendra
- Quelle part du travail est censée être conservée ou jetée
- Si les exigences de sécurité, de protection des données et des app stores s'appliquent déjà
Ce qui est inclus
- Choisissez une PoC si la technologie centrale, l'intégration ou la source de données n'a pas fait ses preuves
- Choisissez un prototype si le parcours ou l'expérience utilisateur n'est pas clair, ou si les parties prenantes ne s'accordent pas sur l'apparence du produit
- Choisissez un MVP si la faisabilité et les parcours principaux sont compris et que vous avez besoin de données d'usage réelles
- Pour toute option : notez la question à laquelle elle doit répondre et la façon dont vous jugerez le résultat
- Définissez la suite pour chaque résultat : poursuivre, ajuster ou arrêter
- Décidez tôt si le code de la PoC ou du prototype sera réutilisé ; en général, il ne devrait pas l'être
- Pour un MVP : confirmez les choix d'authentification, de stockage des données, de confidentialité et d'hébergement avant le développement
Ce qui n'est pas inclus
- L'affirmation que l'une de ces approches assure l'adéquation produit-marché ou l'adoption
- La transformation d'un prototype jetable en logiciel de production sans revue
- Le marketing ou l'acquisition d'utilisateurs
- Des montants budgétaires fixes ; l'effort dépend du périmètre, confirmé par écrit
Quand le choisir
Si vous pouvez formuler votre principale inconnue en une phrase, vous pouvez généralement choisir. « Nous ne savons pas si l'intégration fonctionne » oriente vers une PoC. « Nous ne savons pas si les utilisateurs comprennent le parcours » oriente vers un prototype. « Nous ne savons pas si les utilisateurs vont l'adopter » oriente vers un MVP. Si vous ne pouvez pas encore formuler l'inconnue, commencez par un travail de cadrage (discovery) pour la définir.
Notre approche
Procédez dans l'ordre qui élimine le plus de risques pour le moins d'effort. De nombreux produits gagnent à passer par une courte phase de cadrage ou de blueprint, une PoC ciblée sur la question technique la plus difficile, puis un MVP construit sur les enseignements tirés. Notre service Technical Feasibility & PoC produit un registre de décision de faisabilité et une synthèse de validation pour une question technique définie. Notre service App MVP Sprint livre une première version fonctionnelle et délimitée, avec des éléments de passation, construite avec une attention portée dès le départ à l'authentification et au traitement des données. Lorsque les utilisateurs, les parcours ou le périmètre restent flous, une mission Discovery Sprint ou Product Blueprint & Scope peut intervenir en premier. Quel que soit le chemin choisi, convenez par écrit de la question, des limites et de la passation avant le début des travaux, afin que le résultat puisse être évalué au regard de ce qui était prévu.
Foire aux questions
Articles connexes
Services d'applications et de produits
Qu'est-ce qu'un App MVP Sprint ?
Services d'applications et de produits
Discovery Sprint : planifier avant de développer
Services d'applications et de produits
Coût d'un MVP : les facteurs qui déterminent périmètre et effort
Démarrer
Vous hésitez entre une PoC, un prototype et un MVP ?
Décrivez votre idée, la principale inconnue et la décision que la prochaine étape doit éclairer. Nous vous suggérerons un périmètre de départ proportionné.
Demander un périmètre écrit