MVP : ce qu'on met dedans, ce qu'on laisse dehors

Pourquoi « minimum » est le mot qui trompe

Minimum se comprend comme « le moins de fonctions ». C'est une lecture qui produit des produits inutilisables : cinq fonctions à moitié faites valent moins qu'une seule qui marche.

La bonne lecture est : le moins de périmètre, pas le moins de qualité. Une seule chose, faite complètement, jusqu'au bout du parcours, y compris les cas moches. Un utilisateur pardonne l'absence d'une fonction, pas une fonction qui plante à mi-chemin.

Le test est simple : quelqu'un peut-il faire son travail avec, de bout en bout, sans qu'on lui explique un contournement ? Si la réponse demande un « oui mais », le périmètre n'est pas minimum, il est incomplet.

Cette différence entre minimum et incomplet est ce qui sépare un MVP qui apprend quelque chose d'un MVP dont personne ne sait quoi conclure. Un produit incomplet reçoit des retours sur son incomplétude, pas sur son intérêt.

Un exemple parlant : un outil de devis qui calcule le prix mais ne sait pas imprimer le document n'apprend rien, parce que personne ne s'en servira en vrai. Le même outil qui calcule et imprime, pour une seule famille de produits, apprend tout ce qu'on voulait savoir.

Il y a une raison mécanique à ça. Une fonction à moitié faite n'économise pas la moitié du travail : elle en déplace une partie sur l'utilisateur, qui doit inventer un contournement. Et un contournement inventé une fois devient une habitude que le produit final devra défaire.

Le réflexe qui protège : pour chaque fonction candidate, se demander ce qui se passe si on ne la fait pas du tout, plutôt que ce qui se passe si on la fait à moitié. La première question donne un périmètre net, la seconde donne un produit bancal.

Il existe un test de terrain pour vérifier qu'on a bien compris le mot. Prenez la liste des fonctions prévues et demandez, pour chacune, ce qui se passe si un utilisateur la rencontre à moitié faite. Si la réponse est qu'il appellera quelqu'un, la fonction est soit complète, soit absente. Il n'y a pas de milieu qui tienne dans un vrai poste de travail.

Les quatre erreurs qui le font rater

La première est le périmètre négocié. Chacun défend sa fonction, personne n'arbitre, et la liste double. Le projet reste appelé MVP par politesse alors qu'il est devenu le produit complet, avec le budget d'un MVP.

La deuxième est l'absence de question. On construit pour construire, sans avoir écrit ce qu'on cherche à savoir. À la livraison, personne ne peut dire si c'est un succès, donc tout le monde a raison et la décision suivante se prend au ressenti.

La troisième est le mauvais utilisateur. On teste avec les personnes les plus enthousiastes, souvent celles qui ont porté le projet. Elles adorent, et on en conclut que ça marche. Le vrai test se fait avec quelqu'un qui n'a rien demandé.

La quatrième est la dette silencieuse. Pour aller vite, on coupe. Couper est légitime, ne pas noter ce qu'on a coupé ne l'est pas. Six mois plus tard, personne ne sait plus ce qui était provisoire et ce qui était voulu, et le produit devient difficile à faire évoluer.

Ces quatre erreurs ont un point commun : elles se décident avant la première ligne de code, pendant les conversations où l'on croit ne rien décider.

Il existe un signe avant-coureur commun à ces quatre erreurs : le moment où quelqu'un dit « tant qu'on y est ». Cette phrase précède presque toujours l'ajout d'une fonction dont personne n'avait parlé et dont personne ne mesurera l'usage.

La parade tient en une habitude de réunion. Chaque ajout demandé s'accompagne d'une question : qu'est-ce qu'on retire en échange ? Un périmètre qui ne peut que grossir n'est plus un périmètre, c'est une liste d'envies.

Une cinquième erreur mérite d'être nommée, même si elle est moins fréquente : construire pour une population qu'on n'a pas consultée. Un outil pensé par la direction pour les équipes terrain, sans que les équipes terrain aient vu une ligne, arrive avec un handicap qui n'a rien de technique.

Ces situations se rattrapent, mais elles coûtent un temps que personne n'avait budgété : celui qu'il faut pour regagner la confiance de gens à qui on a imposé un changement.

Ce qu'on met dedans, ce qu'on laisse dehors

Dedans : le parcours principal, complet. Celui qui représente la majorité des usages, du premier écran jusqu'au résultat que la personne attendait.

Dedans aussi : ce qui rend le produit utilisable par quelqu'un qui n'était pas dans la salle quand on l'a conçu. Une connexion, des libellés compréhensibles, un message d'erreur qui dit quoi faire.

Dehors : les cas particuliers. Ils représentent souvent la moitié du travail pour un dixième des usages. On les note, on les traite à la main pendant le test, on les code après si le produit vit.

Dehors aussi : les écrans d'administration. Tant que le produit n'a pas prouvé son intérêt, la configuration se fait en base ou dans un fichier. C'est le poste qu'on sous-estime le plus, et il ne sert à personne d'autre qu'à l'équipe.

Dehors encore : les statistiques, les exports, les notifications, les préférences. Chacune paraît petite, et ensemble elles pèsent des semaines. Elles arrivent quand quelqu'un les réclame vraiment.

Une règle de tri qui fonctionne bien : si l'absence d'une fonction empêche quelqu'un de finir son travail, elle est dedans. Si elle l'oblige juste à faire un geste de plus, elle attend son tour.

Les cas particuliers méritent un mot de plus, parce qu'ils sont la première cause de dérapage. Dans une PME, ils ne sont jamais documentés : ils vivent dans la tête de la personne qui les traite depuis dix ans. On ne les découvre qu'en suivant de vrais dossiers, jamais en réunion.

Une méthode qui marche pour les tenir à distance : les traiter à la main pendant toute la durée du test, en les comptant. À la fin, vous savez lesquels arrivent trois fois par semaine et lesquels sont arrivés une fois en deux mois. Les premiers entrent dans le produit, les seconds restent à la main, et personne ne s'en plaint.

Il reste une catégorie difficile à trancher : les fonctions qui ne servent qu'à une personne, mais dont cette personne a besoin tous les jours. La règle du parcours principal les exclut, le bon sens les inclut parfois. La question à poser est simple : si elle manque, cette personne utilisera-t-elle quand même l'outil ?

Comment on choisit le périmètre, concrètement

On part de la question à laquelle on veut répondre, écrite en une phrase, et validée par la personne qui décidera de la suite. Tout le reste en découle.

On suit ensuite un dossier réel de bout en bout, avec la personne qui le traite aujourd'hui. Pas une description, un vrai dossier. On note chaque étape, chaque outil, chaque endroit où l'information change de main.

Ce parcours donne la liste des étapes indispensables. Tout ce qui n'y figure pas est un candidat au report, et il faut une raison explicite pour le repêcher.

On chiffre alors chaque étape en jours. L'exercice révèle presque toujours deux ou trois étapes qui coûtent la moitié du budget pour peu de valeur : ce sont les premières à sortir ou à simplifier.

On écrit enfin ce qu'on saura à la fin, et comment on le saura. « Trois commerciaux auront fait dix devis chacun sans revenir vers nous » est un critère. « Les utilisateurs seront satisfaits » n'en est pas un.

Ce travail tient en deux à quatre ateliers. Il coûte quelques jours et il évite la dérive la plus chère, celle du périmètre qui gonfle en cours de route parce que rien n'avait été posé au départ.

Une difficulté revient à chaque fois : les gens décrivent le travail tel qu'il devrait se passer, pas tel qu'il se passe. Ce n'est pas de la mauvaise foi, c'est que les contournements sont devenus invisibles à force d'être quotidiens.

D'où l'importance de regarder faire plutôt que de demander. Une heure passée derrière quelqu'un qui traite un dossier apprend plus que trois réunions de cadrage, et coûte moins cher.

Un détail pratique qui change beaucoup de choses : filmer ou enregistrer les ateliers, avec l'accord des participants. Les phrases exactes des utilisateurs valent mieux que les notes qu'on en prend, parce qu'on note ce qu'on a compris, pas ce qui a été dit.

Ces enregistrements servent une seconde fois, plus tard, quand une décision est contestée. Retrouver la phrase d'origine règle en deux minutes des débats qui durent une réunion.

Combien coûte un MVP

Entre 15 000 et 50 000 euros pour un produit qui tourne sur vos données, avec de vrais utilisateurs, dans votre environnement.

Ce qui fait monter le prix : le nombre de systèmes auxquels il faut se connecter, la qualité des données de départ, les obligations de votre secteur, et le nombre de personnes à consulter avant de trancher.

Ce qui le fait baisser : un parcours unique, un seul type d'utilisateur, des données déjà propres, et un interlocuteur qui décide sans passer par un comité.

En dessous de 15 000, vous obtenez une maquette cliquable. C'est utile pour montrer une intention, ça ne répond pas à la question de l'usage réel, parce qu'une maquette ne tombe jamais en panne et ne rencontre jamais une donnée bizarre.

Au-dessus de 50 000, posez-vous une question simple : est-ce encore un MVP ? Souvent le périmètre a glissé vers le produit complet sans que personne l'ait dit à voix haute. Ce n'est pas forcément une erreur, mais ça se décide.

Le coût du MVP se compare rarement au coût du produit complet. Il se compare au coût de construire le mauvais produit pendant un an, qui se chiffre en centaines de milliers d'euros et en équipes découragées.

Un poste est systématiquement sous-estimé : la reprise des données existantes. Si le MVP doit partir de vos données réelles, et il le doit sinon il ne prouve rien, quelqu'un va passer des jours à les nettoyer. Ce travail ne se voit pas à l'écran et il représente souvent le quart du budget.

Un autre poste passe inaperçu : votre temps. Un MVP demande une demi-journée par semaine côté entreprise, pour arbitrer et tester. Ce n'est pas facturé, ça se paie quand même, et un projet où personne n'a ce temps s'enlise quel que soit le prestataire.

Une comparaison utile pour situer l'ordre de grandeur : un MVP à 30 000 euros représente à peu près le coût annuel d'un poste à mi-temps. Posé comme ça, l'arbitrage devient concret pour un dirigeant, alors que la somme brute paraît abstraite.

Combien de temps ça prend

Six à douze semaines entre le premier atelier et le premier utilisateur réel. Cette fourchette suppose que les décisions se prennent en jours et pas en semaines, ce qui est le vrai facteur de vitesse.

Au-delà de douze semaines, deux choses arrivent. Le contexte bouge, et vous testez une question qui n'est plus la vôtre. Et l'équipe qui attend perd la mémoire de ce qu'elle voulait vérifier.

En dessous de six semaines, c'est possible, mais le périmètre doit être vraiment étroit et les données déjà accessibles. Sinon le temps gagné se paie en travail bâclé qu'on refait.

Le calendrier se découpe en général ainsi : une à deux semaines de cadrage, quatre à huit semaines de construction par tranches livrées, une à deux semaines d'usage réel avant de conclure.

Cette dernière période est la plus souvent sacrifiée, et c'est la seule qui produit la réponse. Livrer sans laisser le temps d'utiliser revient à faire le travail sans en lire le résultat.

La vitesse dépend moins de l'équipe technique que du délai de décision. Une question posée le lundi et tranchée le lundi suivant coûte une semaine de projet. Trois questions comme celle-là transforment un MVP de huit semaines en projet de trois mois.

C'est pour cette raison qu'on demande, avant de commencer, qui tranche et sous quel délai. Ce n'est pas une formalité administrative, c'est le premier facteur de coût.

Une remarque sur les périodes de l'année. Un MVP lancé fin juin traverse août, et août ne compte pas : les utilisateurs sont absents, les décisions attendent. Le même projet lancé mi-septembre livre en novembre, avec des gens présents pour l'utiliser.

Ce qu'on mesure pour savoir si ça a marché

L'usage, d'abord. Combien de personnes s'en servent sans qu'on le leur rappelle, combien de fois par semaine, sur combien de dossiers réels.

Le retour en arrière, ensuite. Combien de fois quelqu'un a repris l'ancienne méthode parce que l'outil ne suivait pas. C'est la mesure la plus honnête et celle qu'on regarde le moins.

Le temps, quand c'était le sujet. Il faut l'avoir mesuré avant, sinon la comparaison se fait au souvenir, et le souvenir arrange toujours celui qui a porté le projet.

Les demandes spontanées, enfin. Quand les utilisateurs réclament d'eux-mêmes une fonction en plus, c'est le signe que le produit est entré dans leur travail. Le silence est un résultat aussi, et il faut savoir l'entendre.

Ces mesures se décident avant la construction. Décidées après, elles se choisissent inconsciemment parmi celles qui donnent raison au projet.

Une mesure supplémentaire vaut le détour : le nombre de fois où quelqu'un a demandé de l'aide pour s'en servir. Un produit qui génère des questions les deux premiers jours est normal. Un produit qui en génère encore au bout d'un mois raconte quelque chose sur sa conception.

Attention à ne pas confondre l'enthousiasme et l'usage. Une démonstration en comité de direction déclenche des félicitations qui ne prédisent rien. Seul le compteur d'utilisation d'un mardi ordinaire dit la vérité.

Ces mesures ne demandent pas d'outillage compliqué. Un compteur simple, une conversation de dix minutes avec trois utilisateurs à la fin du premier mois, et la comparaison avec le temps mesuré avant suffisent. Ce qui manque le plus souvent n'est pas l'outil de mesure, c'est d'avoir mesuré la situation de départ.

Ce qu'on fait du MVP après

Trois suites possibles, et il vaut mieux les avoir nommées avant : on étend, on réécrit, on arrête.

On étend quand l'usage est là et que le code tient. Le MVP devient la première version du produit, on ajoute les cas particuliers et les fonctions reportées, dans l'ordre où les utilisateurs les réclament.

On réécrit quand l'usage est là mais que le code a été écrit pour aller vite. Ce n'est pas un échec, c'est une décision prise en connaissance de cause, et elle se chiffre. Notre page sur la dette technique décrit comment l'évaluer sans être technique.

On arrête quand l'usage n'est pas là. C'est le résultat le plus utile et le plus rare, parce qu'il demande d'accepter que la question posée avait une réponse décevante. Il a pourtant économisé le budget du produit complet.

Dans les trois cas, le MVP a fait son travail. Le seul scénario perdant est celui où l'on continue par inertie, sans avoir regardé les chiffres, parce que le projet a déjà coûté de l'argent.

Le moment de la décision compte autant que la décision elle-même. Fixez la date à l'avance, avant de commencer, et tenez-la. Sans date, le MVP entre dans une zone grise où il n'est ni validé ni arrêté, et où il continue de coûter en petites corrections.

Cette date protège aussi l'équipe qui l'a construit. Elle sait quand son travail sera jugé, sur quels critères, et par qui. C'est ce qui distingue un test d'une période d'incertitude.

Le cas le plus fréquent, en pratique, n'est aucun des trois purs. On garde le cœur qui fonctionne, on réécrit deux ou trois morceaux qui ont été bâclés, et on abandonne une fonction dont personne ne s'est servi. C'est un résultat sain, à condition d'avoir noté ce qui était provisoire pendant qu'on le construisait.

MVP, POC et prototype : ce qui les sépare

Le prototype montre à quoi ça ressemblera. Il ne fonctionne pas, il se clique. Il coûte quelques jours et sert à aligner des gens qui ne se comprenaient pas.

Le POC vérifie que c'est faisable. Il fonctionne, sur une difficulté précise, et il peut être laid. On le construit quand la question est technique : est-ce que le modèle retrouve la bonne information dans nos documents, est-ce que l'ancien logiciel accepte qu'on lui parle.

Le MVP vérifie que quelqu'un s'en sert. Il fonctionne, il est utilisable par une personne qui n'a pas participé, et il vit dans le vrai travail.

Les confondre coûte cher dans les deux sens. Payer un MVP pour une question technique, c'est dépenser quatre fois trop. Payer un POC en croyant obtenir un MVP, c'est se retrouver avec quelque chose que personne ne peut utiliser.

Le mot importe moins que la question posée. Avant de commander l'un des trois, écrivez ce que vous voulez savoir. Le bon format se déduit de la question, jamais l'inverse.

Une manière rapide de trancher : regardez qui doit être convaincu. Un comité qui n'arrive pas à se représenter le produit a besoin d'un prototype. Une équipe technique qui doute de la faisabilité demande un POC. Et quand c'est vous qui doutez de l'usage réel, c'est un MVP qu'il faut.

Il arrive qu'on enchaîne les trois, et c'est parfois justifié. Mais chaque étape se décide sur une question qui reste ouverte, jamais par habitude de méthode.

Le vocabulaire varie selon les interlocuteurs, et ça n'a aucune importance tant que la question posée est écrite. Un prestataire sérieux vous demandera d'ailleurs cette question avant de vous proposer un format. S'il propose un format sans avoir demandé ce que vous cherchez à savoir, c'est qu'il vend ce qu'il sait faire.

Quand il ne faut pas faire de MVP

Quand vous connaissez déjà la réponse. Certains besoins sont documentés depuis des années, mesurés, et personne ne doute de l'usage. Construire une version réduite pour s'en convaincre retarde d'un trimestre.

Quand le produit ne se découpe pas. Un système où la moitié des fonctions dépendent des autres donne un MVP qui coûte presque le prix du complet. Mieux vaut l'assumer et découper la livraison plutôt que le périmètre.

Quand vous n'avez pas les utilisateurs. Un MVP sans personne pour s'en servir pendant un mois ne produit aucune réponse. Si vos équipes sont en pleine saison haute, attendez.

Quand la contrainte est réglementaire. Dans certains secteurs, une version partielle ne peut pas être mise entre les mains des utilisateurs. Le test se fait alors en parallèle de l'existant, ce qui change le calendrier et le budget.

Dans tous ces cas, le guide du logiciel sur mesure aide à choisir le bon format avant d'engager quoi que ce soit.

Un cas de plus, moins évident : quand le sujet est politique dans l'entreprise. Si deux services s'opposent sur la marche à suivre, un MVP ne tranchera pas le désaccord, il donnera à chacun de quoi alimenter sa position. Le désaccord se règle avant, entre humains.

Dans le doute, le guide du logiciel sur mesure compare les trois chemins possibles, et notre offre premier outil décrit le format que nous utilisons pour ce genre de test, avec son prix et sa durée.

Enfin, il y a le cas où le budget total est trop petit pour supporter deux étapes. Si vous avez de quoi financer un seul chantier, mettez-le sur le produit et resserrez son périmètre, plutôt que de dépenser un tiers de l'enveloppe à vérifier une chose dont vous êtes déjà à peu près sûr.

Refuser un MVP n'est pas renoncer au projet. C'est reconnaître que la question qu'il aurait servi à trancher a déjà sa réponse, ou qu'elle se posera mieux dans six mois. Les deux arrivent souvent, et le dire à voix haute évite de dépenser pour se rassurer.