MVP : ce qu’il faut garder pour une première version

Produit

Un MVP n'est pas un petit produit. C'est le plus court chemin pour savoir si vos utilisateurs en veulent.

Un parcours, un utilisateur, une promesse

Une première version répond à une seule question : est-ce que cette personne, avec ce problème, utilise ce produit ? Tout ce qui n'aide pas à répondre attend. Le découpage commence donc sur une page : qui l'utilise, ce qui lui coûte du temps, ce qui doit changer, et comment on saura que ça marche.

Ce qu’on garde

Le parcours principal, du début à la fin, qui fonctionne vraiment. Les comptes et les droits s'ils sont nécessaires. Ce qu'il faut pour mesurer l'usage. Et un prototype cliquable en amont : on valide les écrans clés avant d'écrire une ligne de code, parce que c'est le moment où changer d'avis ne coûte presque rien.

Ce qu’on retire

Tout ce qu'on écrit dans la colonne « hors V1 » : la signature électronique, le multi-devises, les réglages que personne n'a encore demandés, les cas rares qu'on peut traiter à la main au début. Ils reviendront si les utilisateurs les réclament, et seulement à ce moment-là.

Ce qu’on ne sacrifie pas

Le modèle de données : c'est lui qui décide si le produit tiendra dans deux ans. La sécurité des accès : chacun voit exactement ce qu'il doit voir, et c'est la base qui l'applique. Une vraie mise en production : un domaine, des environnements, un déploiement propre. Réduire le périmètre, oui. Bâcler les fondations, non.