MVP (prototype)

Comment ça marche

Le réflexe classique devant un besoin d’outil : lister tout ce qu’il devrait faire, chiffrer, attendre. Le MVP inverse : trouver la plus petite version qui rend déjà service à quelqu’un, la construire vite, la mettre en usage, et apprendre. Qu’est-ce qui manque vraiment ? Qu’est-ce qui n’est jamais utilisé ? Qu’est-ce que personne n’avait prévu ?

Avec un agent de code, la plus petite version se construit en jours. Ce qui ne doit pas être minimal : la sécurité des données, la sauvegarde, la clarté de ce que l’outil fait et ne fait pas. Ce qui peut l’être : le nombre de fonctions, l’esthétique, les cas rares. Le MVP vit en production, sur un périmètre réduit (une équipe, un type de dossier), avec quelqu’un qui recueille ce qui se passe. Puis on décide, sur des faits, de la suite.

Un exemple concret

1. L’idée initiale : un outil complet avec saisie, suivi, statistiques, alertes, lien avec la facturation, portail client. Devis prestataire : quatre mois.
2. Le MVP, quatre jours avec un agent : un formulaire de saisie, une liste des réclamations avec leur statut, et un export. Utilisé par une seule agence, 15 personnes, pendant un mois. Données sauvegardées, accès par identifiants, rien d’autre.
3. Ce que le mois a appris : les statistiques prévues n’intéressent personne ; en revanche, tout le monde veut joindre des photos, et le délai de réponse est la seule mesure qui compte. Le portail client ne manque à personne.
4. La version 2, une semaine : photos, délai de réponse affiché, alerte à 48 h. Déployée sur les cinq agences. La version 3 attend d’autres retours.

Le projet de quatre mois aurait livré des statistiques et un portail dont personne ne voulait, sans les photos que tout le monde réclamait.

Ce que ça change pour une équipe

• On apprend sur l’usage, pas sur des hypothèses. Un mois de MVP en dit plus qu’un cahier des charges de trente pages.
• Le risque est petit. Quatre jours et un périmètre réduit : si ça ne marche pas, on a perdu peu.
• Les utilisateurs deviennent co-concepteurs. Ce qu’ils demandent après avoir utilisé l’outil est la vraie spécification.
• Les projets s’enchaînent. Un MVP par mois, chacun mesuré, vaut mieux qu’un grand projet par an.

Les limites et les erreurs fréquentes

• Le MVP qui reste en l’état. Il marche, on l’oublie, et trois ans après il gère toute l’entreprise sans tests ni sauvegarde. Le MVP est une étape ; il faut décider de la suivante.
• Minimal sur la sécurité. Un accès sans mot de passe « pour le test » qui dure. Les données réelles exigent le minimum de sécurité dès le premier jour.
• Trop de fonctions dans le minimum. Dix fonctions « indispensables », et le MVP met deux mois. Une fonction, un utilisateur, un mois.
• Pas de recueil des retours. Un MVP sans personne qui observe l’usage n’apprend rien. Quelqu’un suit, note, et mesure.