Comment on livre un MVP en deux semaines

Livrer un MVP en deux semaines demande moins de vitesse que de discipline. On réduit le projet jusqu’à ce qu’il soit vraiment livrable, puis on tient le rythme sans déraper.

Ce qu’on met en ligne au bout de ces deux semaines fonctionne vraiment : une application testée et déployée, pas une maquette cliquable. Cela suppose quelques conditions. Quand elles ne sont pas réunies, on le dit avant de commencer.

Ce qui rend le délai tenable

Le périmètre d’abord, mis par écrit avant la première ligne de code : quels écrans, pour quels utilisateurs, avec quel résultat attendu. Tant qu’il n’existe pas sur le papier, chacun a sa version du projet.

Vient ensuite la discipline de bout en bout : pour chaque écran, on traite le cas normal, et seulement lui. Les cas tordus, on les note pour la v2. C’est frustrant sur le moment, mais c’est ce qui empêche le projet de s’étaler.

Reste la technique. On part de briques éprouvées — authentification, base de données, e-mails, API — et on ne développe à la main que ce qui apporte vraiment quelque chose. Réinventer l’authentification ne fait gagner aucune journée.

Quand ça ne tient pas en deux semaines

Certains projets ne rentrent pas dans le format. On les repère assez vite, et on préfère le dire tôt. En général, il s’agit de :

• un produit bâti sur une intégration lourde (paiement multi-devises, ERP, données d’un partenaire) ;
• une brique centrale qui demande un algorithme qu’on ne sait pas encore estimer ;
• un back-office complet, avec des rôles et des validations à plusieurs étapes.

Dans ces cas-là, deux semaines ne suffiront pas. Ce n’est pas grave, mais autant le dire avant de signer que de déraper après.

Ce qu’on laisse de côté

Tout ce qui n’est pas dans le périmètre, et c’est volontaire. Quand une idée arrive en cours de route, on l’ajoute à une liste, on la chiffre, et on la développe seulement si vous la validez. Elle ne se glisse pas discrètement dans le forfait de départ.

On nous reproche parfois d’être rigides. C’est justement ce qui rend le délai tenable : on sait ce qui sera livré dans deux semaines. Un projet qu’on déplace en permanence n’arrive nulle part.

Le cadrage fait le reste

La semaine de cadrage, c’est là qu’on décide. On y écrit les écrans, le périmètre de la v1, les maquettes, les critères de réussite. Le reste suit tout seul : un projet cadré avance vite parce que les décisions sont prises, un projet flou relance une discussion à chaque écran.

En résumé

Deux semaines tiennent quand le périmètre est décidé d’avance et qu’on refuse les ajouts cachés. Le reste, c’est du rythme.

Si vous voulez savoir si votre projet rentre dans ce format, découvrez notre offre de développement MVP ou demandez un cadrage gratuit. En une heure, on vous répond franchement, chiffres en main.