POC vs. MVP : nous ne serons pas d'accord
De manière surprenante, le sujet est passionnel, voire polémique. Mais, avant de rentrer dans le vif du sujet, actons si vous le voulez bien notre accord sur une chose : le caractère minimal du MVP. L’idée est d’aller en production rapidement pour itérer — l’essence-même de l’agilité.
D’où mon heuristique personnelle : si vous pensez que votre MVP est trop petit, c’est qu’il est encore trop gros. Reid Hoffman, cofondateur de LinkedIn, formulait la même idée en ces termes : « If you’re not embarrassed by the first version of your product, you’ve launched too late ». Difficile de lui donner tort.
Cela dit, je constate une confusion quasi systématique entre POC et MVP. Clarifions les choses, et pour ce faire, comme souvent, il suffit d’écouter les mots.
POC : Proof of Concept
Un POC est, en bon français, un démonstrateur. Son but est donc de démontrer l’existence d’un marché (la traction) ou la faisabilité technique d’une approche, autrement dit de valider une idée. Votre but est de savoir si ça vaut le coup de passer plus de temps sur le sujet, et une fois que vous en serez convaincus, de convaincre des investisseurs de vous suivre. Il est fréquent de faire plusieurs POCs au cours de la vie d’un produit.
Un POC, c’est rapide, c’est sale et c’est assumé. Quelques semaines de travail au maximum ; plus, c’est déjà autre chose. C’est du quick & dirty, parce qu’on veut en faire le moins possible pour obtenir le maximum de réponses. Si des maquettes suffisent pour obtenir du feedback, go for it!. Du vibe coding, pourquoi pas ou encore mieux. Mais attention : à ce stade, le but est d’obtenir des réponses, pas de constituer un actif pour votre entreprise. On ne construit pas sur un POC, on le jette.
MVP : Minimum Viable Product
L’objectif du MVP est tout autre : il vise à acquérir des utilisateurs. Pour cela, votre produit doit permettre à ces derniers de réaliser un Job To Be Done minimal. Le MVP doit rendre un service qui, à lui seul, justifie l’adoption du produit, voire surpasse le coût du changement si l’utilisateur utilisait préalablement un service concurrent (un MVP est donc par essence contextuel : il dépend de la concurrence). Mais attention : une fois que des utilisateurs vous font confiance, vous ne voudrez pas les décevoir, vous devrez fournir un vrai service, même s’il n’est pas parfait. Vous êtes engagés auprès de vos utilisateurs, car vous êtes en production.
La philosophie du MVP est donc d’en faire peu, mais de le faire bien, et même très bien. Votre produit doit être production ready : une bonne gestion de la sécurité, des erreurs, des logs, de la redondance, des sauvegardes, du monitoring, etc. L’idée est de fidéliser vos utilisateurs par un service non seulement utile, mais si possible agréable. Certains parlent d’ailleurs de Minimum Lovable Product. Par conséquent, construire un MVP requiert des mois de travail avec une vraie équipe et le financement adéquat.
Une bonne pratique consiste à concevoir le plus tôt possible un Walking Skeleton, qu’il faut comprendre comme les fondations techniques en matière de modularité, d’architecture, de test, de sécurité, d’opérations (CI/CD) etc. Cette étape est cruciale pour limiter la dette technique et maintenir la capacité à produire vite sur le long terme. Car, malgré tout ce qui vient d’être dit, le MVP reste un point de départ, une base sur laquelle vous allez itérer.
Conclusion
Vous ne mettrez peut-être pas les mêmes mots sur ces étapes qui jalonnent la vie d’un produit : 1. Valider une idée et 2. Acquérir des utilisateurs. Il n’empêche que ce sont des objectifs bien distincts et que les confondre vous coûterait cher. Posez-vous la bonne question : qu’êtes-vous en train de construire ?