Le MVP en 4 semaines : ce qu'il faut couper, ce qu'il faut garder

Un MVP qui sort en quatre semaines a surtout coupé les bonnes choses au bon moment. Voici comment on s’y prend.

Semaine 1 : cadrer, pas concevoir

Les trois premiers jours sont entièrement non-techniques. On ne touche ni Figma ni le code. On répond à trois questions, par écrit, validées par le client :

• Quelle est l’hypothèse principale qu’on cherche à valider ?
• Quel est le parcours utilisateur unique qui prouve cette hypothèse ?
• Quels indicateurs signaleront que le MVP a réussi ou échoué ?

Le reste de la semaine 1 sert à dessiner le parcours en wireframes basse fidélité et à figer la stack technique.

Semaine 2 : construire le squelette

Cette semaine est la plus dense techniquement. On livre :

• L’authentification (la moins exotique possible : un provider managed, jamais un système maison)
• Le modèle de données complet
• Les écrans clés en version fonctionnelle non finalisée
• Les intégrations critiques (paiement, API tierce)

Le mot d’ordre : ça doit fonctionner de bout en bout, même moche. Si à la fin de la semaine 2 le parcours principal ne tourne pas, on a un problème de scope.

Semaine 3 : donner du sens

C’est la semaine où on transforme un prototype en produit utilisable. Design propre, copy travaillée, états vides, messages d’erreur clairs, micro-animations uniquement là où elles servent.

À éviter cette semaine :
- ajouter une fonctionnalité "vite fait"
- refondre l'UX parce qu'on a une meilleure idée
- intégrer un nouvel outil parce qu'on a vu un tweet

Toute idée nouvelle est notée, datée, et programmée pour la v2. Aucune exception.

Semaine 4 : stabiliser et livrer

La dernière semaine, on ne code plus de fonctionnalités. On corrige et on documente. La règle :

• Lundi-mardi : tests utilisateurs avec 3 à 5 personnes représentatives
• Mercredi : ajustements basés sur les retours
• Jeudi : préparation du déploiement (environnement de prod, monitoring, backups)
• Vendredi : mise en ligne et formation client

Ce qu’on ne fait jamais en MVP

Même si le client insiste, on refuse :

• Système de rôles et permissions complexe (un MVP a un type d’utilisateur, point)
• Internationalisation (une langue, à choisir au kick-off)
• Tableaux de bord analytics maison (on intègre Plausible ou PostHog)
• Système de notifications multi-canal (email transactionnel uniquement)
• Mode hors-ligne (jamais en MVP)

Chacun de ces sujets représente une à deux semaines de travail. Multiplié par cinq, le MVP devient un projet de six mois.

Les trois pièges classiques

Trois raisons font dérailler la majorité des MVP :

1. Le périmètre n’est pas figé : le client ajoute des demandes en cours de route, on accepte par politesse, la deadline glisse
2. La stack est neuve pour l’équipe : on découvre les pièges en production, on perd 30% du temps sur des problèmes résolus
3. Le design passe avant la fonction : on polit des écrans qui changeront après le premier test utilisateur

Quatre semaines, c’est avant tout un cadre : il force tout le monde, client compris, à se concentrer sur ce qui prouve l’hypothèse.