MVP : ce que ça veut dire, et surtout ce que ça ne veut pas dire

« On va faire un MVP » est probablement la phrase la plus souvent prononcée et la plus rarement comprise dans les projets sur lesquels j’interviens.

Elle recouvre trois idées différentes selon la personne qui la prononce, et le malentendu se paie toujours au même moment : à la mise en production.

Les trois contresens

« Un MVP, c’est la même chose en moins bien. » On garde toutes les fonctionnalités, mais mal faites : pas de gestion d’erreur, pas de cas limites, une interface bâclée. Le résultat n’est utilisable par personne, et l’on en conclut que « le besoin n’était pas là » — alors qu’on n’a rien testé du tout.

« Un MVP, c’est une maquette. » On montre des écrans cliquables. C’est utile, mais cela ne répond pas à la question qui compte : les gens l’utiliseront-ils quand ce sera réel, avec leurs propres données et leur charge de travail ?

« Un MVP, c’est un prototype qu’on jettera. » Parfois vrai, souvent faux. En pratique, le prototype part en production, parce qu’il fonctionne et que la pression est là. Autant le construire proprement dès le départ, ou décider explicitement et collectivement qu’il sera jeté.

Ce que c’est, réellement

La plus petite version qui résout un problème réel, de bout en bout, pour quelqu’un.

Les mots importants sont « de bout en bout ». Un utilisateur doit pouvoir entrer dans l’application, faire ce pour quoi il est venu, et en sortir avec son problème résolu — sans qu’on l’aide, sans reprise manuelle derrière lui.

Le périmètre se réduit donc en largeur, pas en qualité. Moins de cas traités, mais chaque cas traité correctement.

Photo : Solo Shutter — licence CC0.

Le bon critère de découpage

La question n’est pas « quelles fonctionnalités peut-on enlever ? » — elle mène toujours à raboter partout et à ne rien terminer.

La question est : quel utilisateur, sur quel cas d’usage, peut aller jusqu’au bout ?

Prenons un outil de gestion de dossiers. La version complète imaginée couvre quatre types de dossiers, trois profils d’utilisateurs, un back-office, des exports et des statistiques.

Un mauvais MVP : les quatre types de dossiers, mais sans gestion des pièces jointes, sans droits et sans notifications. Personne ne peut s’en servir en vrai.

Un bon MVP : un seul type de dossier — le plus fréquent —, un seul profil utilisateur, mais complet : création, pièces jointes, validation, consultation. Une population restreinte peut travailler réellement avec, dès le premier jour.

Ce qu’on apprend, et qui justifie tout

Le « V » de viable existe pour une raison : il faut pouvoir apprendre quelque chose.

Une mise en production restreinte donne des réponses qu’aucun atelier ne donne. Les gens utilisent-ils la fonctionnalité qu’ils réclamaient ? Dans quel ordre font-ils les choses ? Qu’est-ce qui les bloque et qu’on n’avait pas anticipé ? Quels cas particuliers arrivent en réalité, et à quelle fréquence ?

Sur l’un de nos projets, la première version a montré que la fonctionnalité classée numéro deux au backlog n’était utilisée par personne, tandis qu’une demande jugée mineure revenait chaque jour. Nous avons inversé la suite du plan. Cette information valait plusieurs semaines de développement.

C’est cela qu’on achète avec un MVP : pas une économie, une information.

Photo : domaine public (CC0).

Les objections que j’entends

« Nos utilisateurs vont mal le prendre. » Risque réel, qui se traite par le choix de la population. On commence avec une équipe volontaire, prévenue qu’elle essuie les plâtres et que ses retours comptent. C’est souvent valorisant, à condition d’être honnête.

« On ne peut pas lancer sans la fonctionnalité X. » Parfois vrai. Dans ce cas X fait partie du MVP, et l’on réduit ailleurs. Ce qui ne marche pas, c’est de considérer que tout est indispensable — cela signifie simplement que l’arbitrage n’a pas été fait.

« Ça va coûter plus cher au total. » Oui, un peu : on repasse sur certaines parties. L’expérience montre que ce surcoût est très inférieur au coût des fonctionnalités construites puis inutilisées.

Photo : rawpixel — licence CC0.

Ce qu’il ne faut jamais sacrifier

Réduire en largeur, oui. Il reste pourtant quatre choses qui ne se coupent pas, même dans une première version.

La sécurité. Un MVP mis en production traite de vraies données. L’authentification et le contrôle d’accès ne sont pas des fonctionnalités qu’on ajoute ensuite.

La sauvegarde. Perdre les données d’un pilote est le meilleur moyen de tuer un projet, et définitivement — la confiance ne revient pas.

La gestion des erreurs sur le parcours retenu. Si le parcours est réduit à un seul cas, ce cas doit tenir. Un utilisateur bloqué sans message clair abandonne et n’y revient pas.

La possibilité de revenir en arrière. Si la version pose problème, il faut pouvoir repasser au fonctionnement précédent sans drame. Cela suppose que l’ancien processus reste disponible pendant la période de pilote.

Ces quatre points représentent peu de charge s’ils sont prévus au départ, et un chantier douloureux s’ils sont ajoutés après.

Après le MVP : le moment délicat

Il y a un piège juste après la première mise en production, et je l’ai vu se refermer plusieurs fois.

La version restreinte fonctionne, les utilisateurs pilotes sont contents, et la tentation est d’élargir immédiatement à tout le monde. C’est prématuré : les autres populations ont des cas que le pilote n’a pas rencontrés.

Ce que je fais à la place : élargir une population à la fois, en traitant à chaque étape les cas nouveaux qu’elle apporte. C’est plus lent en apparence, et beaucoup plus rapide en pratique — parce qu’un déploiement massif qui se passe mal coûte des semaines à réparer, et abîme la réputation du projet en interne.

Comment je le présente en interne

La difficulté du MVP est rarement technique : elle est de faire accepter qu’on livre quelque chose d’incomplet.

Ce qui fonctionne, c’est de ne jamais le présenter comme une version réduite du produit final. Je le présente comme une question posée aux utilisateurs, avec une date de réponse.

Concrètement : « nous pensons que les techniciens saisiront leur compte rendu sur mobile s’ils peuvent le faire en moins de deux minutes. Nous allons le vérifier en six semaines, sur trois agences. » La conversation cesse de porter sur ce qui manque et se déplace sur ce qu’on va apprendre.

Cette formulation a un autre mérite : elle engage aussi ceux qui décident. Une hypothèse écrite, datée, avec un critère de réussite, ne se réinterprète pas au moment des résultats.

Le test que j’applique

Avant de figer un périmètre de première version, je vérifie une chose : puis-je nommer une personne, dans l’entreprise, qui utilisera ça tous les jours dès la mise en ligne ?

Si je peux la nommer, le périmètre est bon.

Si la réponse est « tout le monde, un peu », ce n’est pas un MVP — c’est une version incomplète du produit final. Et une version incomplète ne s’utilise pas : elle se subit.