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 d'estimer l'effort avec précision 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 estimation de l'effort.
- Critères de validation et KPIs du MVP.
Pour démarrer un cadrage de MVP, prévoyez un premier appel. Voir aussi mes services applications & digitalisation.
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 (pénibles à corriger à ce stade). 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 une étape distincte du dev ?
Souvent oui, surtout pour les projets ambitieux. L'avantage : aborder le dev avec un vrai recul, sans s'engager sur un périmètre avant de l'avoir compris. Pour les projets simples, cadrage et dev peuvent s'enchaîner directement. On en discute au premier appel pour décider du découpage le plus adapté.
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 déjà l'affaire, on arrête là plutôt que d'enchaîner sur du dev qui ne servira pas.