Minimum Viable Product (MVP)

Objectif

La technique retient le plus petit ensemble de fonctions qui délivre de la valeur aux adopteurs précoces, le met en service au plus vite, puis lit la réponse dans leur comportement. Le MVP répond à une question de direction: le produit envisagé intéresse-t-il assez de clients pour qu'on le construise en entier? L'Agile Extension lui donne pour intention d'éviter le coût et le risque liés au développement du mauvais produit. Le guide la place à l'horizon stratégique, où elle sert à arbitrer l'allocation des ressources et à accélérer l'apprentissage de l'organisation.

Le problème traité est le pari en une seule fois: une organisation choisit un produit, le finance en entier, le livre au bout de dix-huit mois et découvre que l'usage n'est pas celui qu'elle supposait. Une analyse de marché déplace une partie de ce risque sans le lever, parce qu'elle enregistre ce que des personnes déclarent. Le MVP substitue à la déclaration un comportement observé: adoption, paiement, usage répété.

La technique produit deux livrables. Le premier est la version mise en service. Le second est l'apprentissage validé: la mesure obtenue, confrontée au seuil, puis la décision qui en découle. Une version réduite livrée sans mesure a payé une réduction de périmètre pour rien.

Usage

Quand l'utiliser

• Nouveau produit dont la demande reste supposée: livrer le noyau à des adopteurs précoces et lire leur usage réel.
• Service dont le prix n'a jamais été présenté à un client: vérifier le consentement à payer avant de construire l'offre complète.
• Fonction que l'équipe et le commanditaire évaluent différemment: trancher par une mesure d'usage plutôt que par un avis.
• Entrée sur un marché déjà occupé: éprouver la différenciation sur un segment restreint avant l'ouverture générale.
• Enveloppe et délai serrés: obtenir un retour client avant d'engager le reste du budget.

Quand ne pas l'utiliser

• Solution simple, sans incertitude sur l'usage: le produit complet est déjà le plus petit produit viable, écrire directement les user stories de la solution.
• Aucun accès à de vrais clients: sans usage observé la technique perd son objet, éprouver la demande par un sondage ou questionnaire ou une analyse de marché.
• Version partielle impossible à exposer pour raison de sécurité ou de conformité: éprouver l'intention par un prototypage jetable ou une simulation.

Description

D'où vient la technique

Frank Robinson forge le terme en 2001, dans sa méthode de développement synchrone: le produit à construire est celui dont le rapport entre le rendement attendu et le risque est le plus élevé, assez grand pour provoquer l'adoption, la satisfaction et la vente, assez petit pour ne pas devenir pléthorique et risqué. Eric Ries lui donne en 2011 sa formulation courante et sa diffusion: la version d'un produit qui permet de collecter le maximum d'apprentissage validé sur les clients pour le moindre effort. C'est cette seconde définition que l'Agile Extension reprend, sans la nommer.

Le guide intitule son entrée « Minimal Viable Product ». La littérature d'origine, le glossaire de l'Agile Alliance et l'usage des praticiens disent « Minimum », forme retenue ici; un lecteur qui remonte au §7.6 y trouvera l'autre orthographe pour la même technique.

Les quatre éléments

Le guide énonce que la quantité d'exigences est subjective et dépend du contexte, avec deux bornes: il faut en produire assez pour valider l'hypothèse et le minimum pour mettre la solution en service rapidement. Une équipe qui commence par tailler dans son backlog n'arrive donc jamais à un MVP. Là où l'instrumentation manque, les métriques et indicateurs se posent avant le mécanisme de mesure.

Les trois étapes

1. Déterminer le problème à résoudre et poser l'hypothèse
   Le problème s'établit à partir de ce que vivent les adopteurs précoces. L'hypothèse dit ce que l'on croit vrai de leur comportement si la solution existait.
2. Identifier le plus petit ensemble de fonctions qui met cette hypothèse à l'épreuve
   Le guide demande de chercher des options créatives et peu coûteuses de test auprès du marché cible. Une page décrivant l'offre avec son prix et un formulaire d'inscription mesure un consentement à payer sans qu'une ligne de code du produit soit écrite.
3. Analyser l'apprentissage validé pour décider de la suite
   La mesure est confrontée au seuil. Le retour porte aussi sur la faisabilité de la solution et sur les fonctions supplémentaires nécessaires pour élargir l'adoption.

La numérotation se lit comme une ligne droite; le guide décrit pourtant des cycles successifs, le retour étant collecté et analysé avant que d'autres fonctions soient livrées. L'étape 3 ramène donc à l'étape 1 quand la mesure invalide l'hypothèse, à l'étape 2 quand elle la confirme et qu'un périmètre plus large se justifie.

Écrire une hypothèse qui peut échouer

Une hypothèse utilisable tient quatre choses: le public concerné, un comportement observable, un seuil chiffré et un horizon. « Les fiduciaires apprécieront la préparation automatique du décompte » n'en tient aucune. « Au moins 30% des fiduciaires pilotes souscrivent l'option payante au terme des six mois d'essai » les tient toutes et peut être démentie par un chiffre.

Le seuil se fixe avant la mise en service, avec le commanditaire, parce qu'il répond à une question de financement: à partir de quel taux la suite est-elle financée? Trois décisions se rattachent au même chiffre: la poursuite, la reprise de l'hypothèse et l'arrêt, chacune avec sa bande de valeurs. Un taux d'adoption de 12% se défend devant un comité comme un encouragement autant que comme un échec.

Comment choisir le plus petit ensemble de fonctions?

Le guide est explicite: il n'existe pas de formule, et les fonctions souhaitées relèvent d'une estimation au jugé. Deux questions suffisent à trier les fonctions candidates. Sans cette fonction, l'hypothèse peut-elle encore être mise à l'épreuve? Sans elle, la mesure serait-elle faussée? Une exigence de sécurité, une obligation légale, l'exactitude d'un calcul ou un temps de réponse acceptable entrent par cette seconde porte. L'analyse de Kano classe les mêmes fonctions candidates par la satisfaction qu'elles procurent et départage celles que les deux questions laissent à égalité.

Le niveau de qualité se fixe donc par ce qu'exige un test honnête. Une version bâclée confond deux causes d'abandon, le défaut et l'absence d'intérêt, et rend la mesure inexploitable au prix d'une économie de quelques jours. Ce qui reste hors du périmètre s'écrit, avec les fonctions nommées une à une: sans cette liste, la discussion sur le périmètre recommence à chaque affinage du backlog.

Le guide relève comme limite que la technique demande une analyse de marché poussée pour identifier l'ensemble de fonctions nécessaire aux adopteurs précoces. C'est le coût caché du MVP: le travail de segmentation, souvent appuyé sur des personas et sur des entretiens, se fait avant la première ligne de code.

MVP, prototype et produit minimum commercialisable

Trois objets voisins se distinguent par leur public et par le critère qui les juge. Un prototype montre une faisabilité ou une intention; il circule à l'intérieur de l'organisation ou devant un panel réuni pour l'occasion, et il se juge sur des avis. Un MVP est une version en service, offerte à de vrais clients dans leurs conditions habituelles, et il se juge sur un comportement mesuré. Le produit minimum commercialisable (minimum marketable product) est le plus petit ensemble qui se vend; le glossaire de l'Agile Alliance en fixe la différence par la finalité, l'apprentissage pour l'un et le revenu pour l'autre.

Un MVP dont l'hypothèse est démentie a rempli son office, puisqu'il a évité une construction entière; un produit minimum commercialisable qui ne se vend pas a échoué.

Ce qui fait échouer la technique

La version réduite sans hypothèse

Le guide le dit dans ses limites: la technique porte sur la mise à l'épreuve d'une hypothèse de départ. Une équipe sous contrainte de délai coupe des fonctions, livre le reste et l'appelle un MVP. Aucun seuil n'a été écrit et aucune mesure n'a été instrumentée.

L'étape 3 sautée

La version part en production, l'équipe enchaîne sur l'itération suivante et personne ne dépouille la mesure. Le coût du MVP se paie d'avance, en périmètre abandonné et en instrumentation; il ne rapporte qu'à l'étape 3. Le remède tient à un rendez-vous fixé au moment de la mise en service, à la date de fin de la période d'observation, avec le commanditaire.

Le public trop large

Ouvrir la version à tous les utilisateurs noie le signal des adopteurs précoces et expose une version volontairement réduite à des clients qui attendaient autre chose. Une cohorte nommée, un drapeau de fonctionnalité (feature flag) et une communication qui présente la version pour ce qu'elle est: ces trois éléments tiennent l'exposition sous contrôle.

Le MVP promu produit définitif

La mesure est bonne, la version reste en l'état et les raccourcis deviennent les fondations du produit. Le dépouillement de l'étape 3 tranche deux choses: ce qui se construit ensuite et ce qui se refait parce qu'il n'avait été bâti que pour tenir huit semaines.

Considérations IA

Un modèle de langage sert aux deux extrémités de la technique. Au cadrage, il produit des hypothèses candidates à partir d'un énoncé de problème et d'une description du public visé; ce qui intéresse l'analyste, ce sont celles que la salle n'avait pas formulées. Il propose des options de test peu coûteuses, ce que le guide réclame à l'étape 2, et il liste les événements à instrumenter pour que la mesure existe le jour de la mise en service. Interrogé fonction par fonction, « quelle hypothèse cette fonction met-elle à l'épreuve? », il fait apparaître celles qui n'en testent aucune. Au dépouillement, il regroupe par motif les commentaires libres des adopteurs précoces et signale ceux qui contredisent la mesure quantitative.

Le seuil ne se demande pas à un modèle. Sommé d'en produire un, il rendra un pourcentage plausible qui ne sort d'aucune décision de l'entreprise, alors que ce nombre engage un budget. Le même écueil vaut pour le verdict: un modèle à qui l'on demande si le MVP a réussi construira un récit favorable à partir des mêmes données, ce que le seuil écrit à l'avance rend sans effet. Les données d'usage recueillies pendant l'observation identifient des clients et parfois des montants, donc des données personnelles au sens de la loi fédérale sur la protection des données (LPD); elles sont anonymisées avant tout envoi vers un service d'IA hébergé chez un tiers, et l'hébergement se vérifie lorsque le traitement sort de Suisse.

La génération de code change l'économie de la technique. Construire une version réduite coûte moins qu'avant, ce qui affaiblit l'argument de coût du guide et laisse la valeur du côté de la mesure: l'hypothèse, le seuil et le dépouillement restent le travail du business analyst.

Exemples

Un éditeur romand de logiciels de comptabilité veut savoir si les fiduciaires paieront pour la préparation automatique du décompte TVA de leurs mandats. La fiche de définition ci-dessous est le livrable de cadrage de la technique.

Visualisations

Le premier dessin est la boucle: problème et hypothèse, plus petit ensemble de fonctions, mise en service auprès des adopteurs précoces, mesure de l'apprentissage, puis décision. Le trait qui doit se voir est celui qui repart de la décision vers l'hypothèse plutôt que vers la liste de fonctions.

Un second dessin sert le tri du périmètre. Les fonctions candidates s'y répartissent en trois zones: celles qui mettent l'hypothèse à l'épreuve, celles qui rendent la mesure honnête (sécurité, conformité, exactitude d'un calcul) et celles qui attendent hors du périmètre. Ce qui doit se voir est le second critère d'admission, celui par lequel une exigence sans rapport avec l'hypothèse entre malgré tout dans la version livrée.

Coût

Outils

Le drapeau de fonctionnalité (LaunchDarkly, Unleash ou le mécanisme intégré à la plateforme de développement) est l'outil propre à la technique: il ouvre la version à une cohorte nommée, la referme en une opération si le défaut apparaît et sépare la mise en production de l'exposition. Sans lui, l'exposition se règle par des déploiements successifs, ce qui coûte cher et retire la maîtrise du public observé.

Les outils de mesure d'usage (Matomo, Piwik PRO, Amplitude et leurs équivalents) produisent le taux qui sera confronté au seuil, à condition que les événements soient instrumentés avant la mise en service.

Les outils de test A/B (Optimizely, VWO, GrowthBook) servent la variante où deux propositions sont exposées en parallèle, traitée sous test A/B. Ils apportent le découpage aléatoire de la population et le suivi de la significativité, que les outils de mesure d'usage n'offrent pas seuls.

Les outils de création de pages et de formulaires (Webflow, Typeform, Jotform) tiennent les options de test peu coûteuses de l'étape 2: une page d'offre, un prix affiché et un formulaire.

Les outils de gestion de backlog (Jira, Azure DevOps, GitLab et leurs équivalents) accueillent la fiche de définition et le hors-périmètre, à condition qu'un champ porte l'hypothèse visée par chaque élément retenu. Ce rattachement permet, à l'étape 3, de dire quelles fonctions la mesure a servi à décider. Un tableur suffit pour la fiche elle-même, qui se relit en séance de décision.

Sources

• IIBA, Agile Extension to the BABOK Guide, §7.6 Minimal Viable Product: la finalité de la technique, la définition du plus petit ensemble de fonctions, les quatre domaines d'application, les trois étapes, les quatre éléments, les forces énoncées et les limites, dont l'absence de formule, l'analyse de marché préalable et le cas de la solution simple.
• Eric Ries, The Lean Startup, Crown Business, 2011, chapitre 6: la définition en usage, la version d'un produit qui permet de collecter le maximum d'apprentissage validé pour le moindre effort, et la boucle construire, mesurer, apprendre.
• SKMurphy, Frank Robinson's Minimum Viable Product Definition: compte rendu documenté de la définition de Frank Robinson, à qui le terme est attribué depuis 2001, et de son dimensionnement par le rapport entre rendement attendu et risque.
• Agile Alliance, glossaire, Minimum Viable Product (MVP): la forme du terme retenue par la profession et la distinction entre le MVP, orienté vers l'apprentissage, et le produit minimum commercialisable, orienté vers le revenu.