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 la charge dérape de 30 à 50 % sans surprise.
Le dossier de cadrage est l'outil qui aligne client et prestataire avant d'engager la phase de 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, périmètre, durée estimé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 d'investir dans le dev |
| Plan de dev par sprints | Sprints, ordre, dépendances, charge estimée par sprint | Permet de mesurer l'avancement et d'estimer 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 gratuit, sans engagement. Voir aussi 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 d'estimer le dev avec un vrai recul, une fois le périmètre compris plutôt qu'à l'aveugle. C'est plus sain pour les deux parties.
Qui valide le dossier de cadrage côté client ?
Le décideur métier (qui valide le périmètre fonctionnel) + 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.