Un cadrage de projet d'application sur mesure ne peut pas se livrer en une slide PowerPoint. Voici ce qu'un dossier de cadrage sérieux doit contenir, livrable par livrable, pour que la phase de dev démarre sans flou et sans surprise.
Pourquoi un dossier de cadrage
Cadrer un projet d'application sur mesure, c'est transformer une idée floue en plan d'attaque exécutable. Sans cadrage rigoureux, le dev démarre avec des hypothèses non partagées, les hors-périmètre explosent en cours de projet, et le budget dérape de 30 à 50 % sans surprise.
Le dossier de cadrage est l'outil qui aligne client et prestataire avant d'engager le budget dev. Il est vivant : il guide sans enfermer, ajustable en cours de projet.
Les 6 livrables du cadrage
| Livrable | Contenu type | Pourquoi essentiel |
|---|---|---|
| Synthèse exécutive | 1 page : quoi, pour qui, pour quoi, budget global, durée | Donne le contexte à tout intervenant en 5 min |
| Cartographie utilisateurs + cas d'usage | Profils, situations, fréquence, 5-10 scénarios concrets | Évite de construire pour soi au lieu des vrais users |
| Architecture fonctionnelle | Liste des modules, périmètre détaillé, exclusions claires | Limite les hors-périmètre futurs |
| Schéma de données | Entités, relations, contraintes, volumes attendus | Évite les refontes structurelles plus tard |
| Wireframes des écrans clés | 5-10 écrans en basse fidélité validant les parcours | Valide l'UX avant le dev coûteux |
| Plan de dev + chiffrage | Sprints, ordre, dépendances, chiffrage précis par sprint | Permet de mesurer l'avancement et de chiffrer juste |
La méthode de cadrage
Atelier de démarrage
Demi-journée ou journée avec décideurs et utilisateurs clés. Comprendre le problème, les contraintes, les attentes. Base pour la suite.
Entretiens utilisateurs
3-5 entretiens individuels avec les vrais futurs utilisateurs. Découvrir les vrais problèmes du terrain, pas la vision idéalisée depuis la direction.
Synthèse + itérations
Production des livrables, validation par le client en plusieurs passes. Ajustements selon les retours. Le dossier final est partagé et signé.
Les pièges du cadrage
- Cadrage trop court : on saute des étapes, on découvre les problèmes en dev (coûteux).
- Cadrage trop long : on optimise excessivement avant validation utilisateur (on planifie du superflu).
- Cadrage sans utilisateurs : on cadre depuis la direction, l'app ne correspond pas au terrain.
- Cadrage figé : on enferme le dev dans des décisions prises sans recul.
- Cadrage non signé : pas de référence commune, les hors-périmètre se discutent au cas par cas.
Pour démarrer un cadrage, prévoyez un premier appel. Voir aussi Analyse et cadrage et cadrer un MVP en 6 semaines.
Questions fréquentes
Combien de temps prend un cadrage sérieux ?
Pour un MVP standard : 2 à 6 semaines selon l'ambition. Pour un SaaS ou app multi-rôles complexe : 4 à 8 semaines. Compter 15-25 % du temps total du projet en cadrage. Cet investissement amont évite 30-50 % de dépassement en aval.
Le cadrage est-il toujours facturé séparément ?
Pour les MVP simples : peut être inclus dans le contrat de dev. Pour les projets ambitieux ou flous, séparer le cadrage permet de chiffrer le dev avec un vrai recul, sans s'engager sur un budget total avant compréhension du périmètre. C'est plus sain pour les deux parties. Voir Analyse et cadrage.
Qui valide le dossier de cadrage côté client ?
Le décideur métier (qui valide le périmètre fonctionnel et le budget) + les utilisateurs clés (qui valident que les parcours collent à la réalité du terrain). Ne pas valider seul depuis la direction sans consulter les utilisateurs : risque d'adoption faible en fin de projet.