De l’idée au MVP livré en deux semaines

Deux semaines, ce n’est pas magique — c’est une contrainte. La contrainte vous force à répondre à une question avant de commencer : quelle est la seule chose que ce produit doit prouver ? Tout ce qui ne sert pas cette preuve est reporté. C’est inconfortable, et c’est exactement pourquoi ça marche.

Semaine 1 : cadrer et construire le cœur

Les deux premiers jours sont consacrés au cadrage : nous écrivons le parcours utilisateur principal en une seule phrase, puis nous coupons. Le reste de la semaine sert à construire ce parcours de bout en bout, avec de vraies données et une vraie persistance — pas une maquette. Mieux vaut un seul chemin qui fonctionne réellement que dix écrans qui ne mènent nulle part.

Semaine 2 : finir, durcir, livrer

La deuxième semaine ne consiste pas à ajouter des fonctionnalités, mais à rendre le cœur digne de confiance : gestion des erreurs, états vides, responsive mobile, et un déploiement réel sur une URL que les utilisateurs peuvent ouvrir. Un MVP qui vit sur le laptop du développeur n’a rien prouvé.

• Un seul parcours utilisateur, fonctionnel de bout en bout
• De vraies données et une vraie persistance, pas une maquette
• Déployé sur une URL publique dès le premier jour
• Des métriques pour mesurer ce que l’on cherche à prouver

Ce que vous obtenez à la fin

Au bout de deux semaines, vous ne tenez pas le produit final — vous tenez une réponse. Soit la preuve que l’idée mérite un vrai investissement, soit la certitude qu’il faut pivoter, obtenue pour une fraction du coût d’un développement complet. Dans les deux cas, vous avez gagné des mois.