Le piège classique du MVP est connu : on construit vite, on démontre, puis tout est à refaire dès que les vrais utilisateurs arrivent. Notre approche consiste à séparer ce qui doit être jetable de ce qui doit durer.
Semaines 1–2 : le périmètre, pas les écrans. Nous commençons par les scénarios critiques : ce que l’utilisateur doit pouvoir faire du début à la fin, sans alternative. Chaque scénario est relié à un risque commercial ou technique. Tout ce qui ne sert pas un scénario critique sort du périmètre — documenté, mais reporté.
Semaines 3–6 : le squelette. Modèle de données, API, authentification, déploiement. Ces éléments seront encore là dans trois ans : nous les construisons proprement dès le départ, avec tests et monitoring. Les interfaces, elles, restent volontairement simples.
Semaines 7–10 : la boucle de démonstration. Chaque semaine se termine par une version utilisable. Pas de maquettes commentées — un produit qui tourne, avec de vraies données. Les retours arrivent tôt, quand les changements coûtent encore peu.
Semaines 11–12 : le durcissement. Tests de charge, revue de sécurité, journalisation, plan de reprise. Le MVP sort quand il tient la charge prévue et que l’équipe peut l’exploiter sans nous.
Le résultat n’est pas un prototype : c’est la première itération d’un produit réel, avec une architecture qui absorbera la suite.
