Cadrer un MVP en 6 semaines, ce n'est pas livrer du code en 6 semaines : c'est définir précisément quoi construire, pour qui, et comment valider que ça marche. Voici la méthode que je pratique pour transformer une idée floue en plan d'attaque exécutable.
Pourquoi cadrer avant de coder
Un projet d'application qui démarre directement par le dev sans cadrage sérieux a 80 % de chances de devoir être réécrit en partie ou en totalité dans les 18 mois. Pas parce que les développeurs sont mauvais, mais parce que le périmètre n'a jamais été défini avec assez de précision.
Cadrer un MVP en 6 semaines, c'est faire 70 % du travail d'architecture en amont. C'est l'investissement le plus rentable d'un projet applicatif sérieux.
Phase 1 (sem. 1-2) : problème, utilisateurs, cas d'usage
On commence par le pourquoi et le pour qui, jamais par le quoi.
Le problème métier réel
Décrit en une phrase concise. « Les commerciaux passent 5h/sem à recopier des devis dans Excel » plutôt que « On veut une app de gestion commerciale ».
Les utilisateurs cibles
Qui s'en sert, sur quel appareil, dans quelle situation, à quelle fréquence. Idéalement, interviewer 3-5 utilisateurs réels (pas juste le client commanditaire).
Les cas d'usage clés
5 à 10 scénarios concrets racontés en une phrase. « Quand Sophie reçoit un appel client, elle doit pouvoir créer un devis en moins de 2 minutes sans quitter le téléphone ».
Phase 2 (sem. 3-4) : architecture, entités, parcours
Une fois le besoin clair, on traduit en structure.
| Livrable | Pourquoi |
|---|---|
| Liste des entités métier | Client, Commande, Produit, Facture : comprendre les objets et leurs relations. |
| Schéma de la base de données | Tables, champs clés, contraintes. Évite les refontes structurelles plus tard. |
| Liste des rôles utilisateurs et permissions | Admin, manager, commercial, lecteur : qui voit/fait quoi. |
| Parcours utilisateurs clés | Le chemin précis du clic 1 à l'action complète, pour les 5-10 cas d'usage. |
| Liste des intégrations externes | Chaque service tiers à brancher (CRM, paiement, mail, signature). |
| Contraintes techniques et RGPD | Hébergement, type de données, audit éventuel, conformité. |
Phase 3 (sem. 5-6) : prototype + plan dev
Prototype des écrans clés
Wireframes ou maquettes basse fidélité des 5-10 écrans principaux. Pas pour faire joli, pour valider les parcours et les contenus avant de coder.
Plan de développement
Découpage en sprints (semaines de dev), ordre des features, dépendances. Permet de chiffrer précisément et de mesurer l'avancement pendant le dev.
Critères de validation
Comment on saura que le MVP a réussi : KPIs, retours utilisateurs, métriques d'adoption. Sans critères, on ne sait pas si l'app marche.
Le livrable final
À la fin des 6 semaines, vous repartez avec un dossier de cadrage vivant de 15-30 pages :
- Synthèse exécutive (1 page : le quoi, pour qui, pour quoi).
- Détail problème + utilisateurs + cas d'usage.
- Architecture technique cible (stack, hébergement).
- Schéma de données et liste des entités.
- Parcours utilisateurs détaillés + wireframes des écrans clés.
- Liste des intégrations externes et hypothèses techniques.
- Contraintes RGPD et sécurité.
- Plan de développement avec sprints et chiffrage précis.
- Critères de validation et KPIs du MVP.
Pour démarrer un cadrage de MVP, prévoyez un premier appel. Voir aussi Analyse et cadrage et Applications & SaaS.
Questions fréquentes
Pourquoi 6 semaines, pas 2 ou 12 ?
C'est un compromis. En dessous de 4-6 semaines, on cadre trop vite et on découvre les problèmes pendant le dev (coûteux à corriger). Au-dessus de 8 semaines, on optimise excessivement avant validation utilisateur (on planifie du superflu). 6 semaines couvre les 3 phases clés sans s'éterniser.
Peut-on cadrer plus vite si l'idée est claire ?
Oui, pour des MVP très simples (3-4 écrans, 1 rôle utilisateur, pas d'intégration complexe), un cadrage en 2-3 semaines peut suffire. Mais attention au biais : ce qui semble clair en tête est souvent flou sur le papier. Le cadrage révèle des angles morts qu'on n'avait pas vus.
Le cadrage est-il facturé séparément du dev ?
Souvent oui, surtout pour les projets ambitieux. Avantages : permet de chiffrer le dev avec un vrai recul, sans s'engager sur un budget total avant compréhension du périmètre. Pour les projets simples, cadrage + dev peuvent être dans un même contrat. Voir Analyse et cadrage.
Que se passe-t-il si le cadrage révèle que le projet n'est pas viable ?
Je vous le dis. C'est une des vraies valeurs du cadrage : éviter de lancer un projet qui ne devrait pas exister. Si le besoin est mal défini, si le marché est saturé, ou si une solution du marché ferait l'affaire pour 10× moins, on arrête là plutôt que d'enchaîner sur du dev qui ne servira pas.