MVP (produit minimum viable)

Un MVP est un produit réel, utilisé par de vraies personnes sur de vraies données. Ce qui le distingue d'une version complète, c'est la sélection rigoureuse de ce qui y figure. Seules les fonctionnalités indispensables au cas d'usage central sont incluses : les fonctions secondaires, les optimisations et les interfaces annexes attendent les versions suivantes.

Il se distingue d'un prototype : un prototype est souvent interne, non fonctionnel, et sert à tester une interface ou une idée. Un MVP fonctionne et produit des données réelles sur ce que les utilisateurs font, ce qu'ils ne font pas, et ce qu'ils cherchent sans le trouver. C'est cette boucle de retour qui justifie le concept.

Le terme vient de la méthode Lean Startup, formalisée par Eric Ries dans un ouvrage publié en 2011. L'idée centrale : avant de construire un produit complet, valider que le problème existe réellement et que la solution proposée est acceptable pour ceux qui l'ont.

MVP dans un projet

L'erreur la plus fréquente est d'interpréter « minimum » comme « rapide » plutôt que « suffisant ». Un MVP qui ne couvre pas le cas d'usage central n'apprend rien, parce que les utilisateurs ne l'utiliseront pas. La question n'est pas « que peut-on enlever pour aller plus vite ? » mais « quel est le problème précis que cette version doit résoudre ? ».

L'intérêt du MVP n'est pas de réduire le budget (les fonctionnalités fondamentales coûtent autant dans un MVP que dans une version complète), mais de réduire le risque de construire ce que personne n'utilise. Il permet de décider, après une vraie utilisation, si l'investissement dans les versions suivantes est justifié.

La structure du code d'un MVP détermine le coût de ses évolutions. Un MVP construit rapidement avec des raccourcis techniques sera difficile et coûteux à étendre. Prévoir dès le départ une architecture claire et une couverture de tests de base n'alourdit pas beaucoup le premier livrable, et évite un refactoring complet à la deuxième version.

Définir le périmètre d'un MVP est un exercice de concession : chaque fonctionnalité ajoutée allonge le délai avant de recueillir de vrais retours. Un outil simple pour trancher : demander pour chaque fonctionnalité si le MVP est inutilisable sans elle. Seules celles qui répondent oui restent dans le périmètre.

Questions pratiques avant de démarrer : quel est le problème que ce produit doit résoudre ? Qui sont les premiers utilisateurs et comment les joindre ? Quelle décision voulons-nous pouvoir prendre après cette version ? Répondre à ces trois questions avant de commencer évite de construire un périmètre que personne ne valide.