La plupart des « documents de cadrage » sont une liste de fonctionnalités à puces et un chiffre. Ce n'est pas un document de cadrage. C'est une estimation avec une mise en forme.
Un vrai document est suffisamment précis pour que deux équipes d'ingénierie différentes, en ne lisant que le document, construisent un produit reconnaissablement identique. Voici ce que cela exige réellement.
La réponse courte
| Section | Ce qu'elle prévient |
|---|---|
| Énoncé du problème | Construire efficacement la mauvaise chose |
| Parcours utilisateurs | Des fonctionnalités qui ne s'assemblent pas en un produit fonctionnel |
| Liste de fonctionnalités priorisée | Une dérive de périmètre déguisée en « juste une chose de plus » |
| Architecture technique | Reconstruire au quatrième mois parce que la stack ne scalait pas |
| Liste d'écrans / prototype | Des surprises de design en pleine construction |
| Devis module par module | Un chiffre unique que personne ne peut vérifier ni ajuster |
| Risques et dépendances | Un dérapage de calendrier sur quelque chose que personne n'avait signalé |
| Exclusions explicites | La source la plus fréquente de litiges sur le périmètre |
Huit sections. En manquer deux ou trois, et vous avez une proposition, pas un plan.
Un énoncé du problème, pas une liste de fonctionnalités
Le document doit s'ouvrir sur le problème résolu et qui le rencontre, en langage clair, avant qu'une seule fonctionnalité ne soit nommée. Cela paraît évident et se voit constamment sauté.
Pourquoi c'est important : chaque décision de périmètre ultérieure est testée contre cela. Quand une demande de fonctionnalité apparaît en semaine six, « cela résout-il le problème énoncé » est un filtre plus rapide et plus honnête que « cela semble-t-il utile ».
Une version faible : « Une appli pour connecter les opérateurs de flottes aux mécaniciens. » Une version qui fonctionne nomme la douleur réelle - les opérateurs passent actuellement deux à six heures par panne à chercher un mécanicien disponible par téléphone, sans pouvoir vérifier ses compétences au préalable.
Les parcours utilisateurs avant les listes de fonctionnalités
Des fonctionnalités isolées ne disent pas si le produit fonctionne. Les parcours, si.
Le document doit cartographier les deux ou trois chemins essentiels qu'un utilisateur emprunte réellement de bout en bout - pas chaque écran, mais la séquence qui fait fonctionner le produit. C'est là que vous découvrez que « ajouter un système de notation » exige implicitement de « gérer les litiges quand la note est injuste », ce à quoi personne n'avait pensé à cadrer séparément.
Une liste de fonctionnalités réellement priorisée
Pas une liste à puces plate - une liste triée selon ce qui casse le produit en son absence par rapport à ce qui serait agréable à avoir. Nous avons déjà écrit sur la réduction d'une liste de 46 fonctionnalités à 11 en utilisant exactement ce test : si cela manque, la boucle centrale fonctionne-t-elle encore ?
Chaque fonctionnalité qui passe ce test entre dans « Indispensable ». Tout le reste va dans une section « Phase deux » clairement étiquetée - documentée, estimée à un niveau approximatif, et explicitement exclue de ce qui est construit maintenant. Cette seule pratique évite plus de litiges de périmètre que n'importe quelle clause contractuelle.
Une architecture technique, avec les raisons
Pas seulement une liste de technologies - le raisonnement derrière chaque choix, car c'est ce qui permet à quelqu'un d'évaluer si les décisions sont encore pertinentes six mois plus tard.
Un document de cadrage doit indiquer la stack, l'approche d'hébergement, et les deux ou trois décisions coûteuses à inverser - le choix de base de données pour un produit transactionnel, si les notifications passent par WhatsApp ou uniquement par e-mail, si l'architecture doit supporter plusieurs plateformes plus tard même en lançant sur une seule aujourd'hui.
Des écrans ou un prototype, pas une description
« Un tableau de bord épuré et moderne » n'est pas une spécification. Cinq à huit écrans clés, idéalement sous forme de prototype cliquable, éliminent la plus grande source de surprises en cours de construction : le fondateur et l'équipe ayant des images différentes de la même fonctionnalité en tête.
Cela n'a pas besoin d'être un design final au pixel près. Cela doit être suffisamment précis pour que « le panneau d'administration » cesse d'être une abstraction et devienne quelque chose de réel, discutable.
Un devis décomposé par module, pas un chiffre unique
Un prix unique cache chaque hypothèse qui l'a produit. Une décomposition module par module - comptes et permissions, flux transactionnel central, paiements, panneau d'administration, etc. - fait deux choses qu'un chiffre unique ne peut pas : elle montre ce qui coûte cher et pourquoi, et elle permet de couper un module précis si le budget ne suit pas, au lieu de renégocier l'ensemble.
Des risques et dépendances nommés précisément
Un langage de risque générique (« risque technique », « risque de calendrier ») ne sert à rien. Une vraie section de risques nomme la chose précise susceptible de ralentir le projet - le calendrier d'approbation d'un prestataire de paiement, une API tierce aux limites de débit floues, une décision du fondateur encore en suspens - et qui est responsable de sa résolution.
Cette section est aussi l'endroit où le chemin critique est identifié : les deux ou trois choses qui, si elles sont retardées, retardent la date de lancement quelle que soit la qualité du reste de l'ingénierie.
Ce qui est explicitement exclu
C'est la section que la plupart des documents de cadrage omettent entièrement, et c'est celle qui évite le plus de disputes plus tard.
Indiquez clairement ce qui n'est pas inclus : coûts de services tiers, rédaction de contenu, migration de données, support au-delà d'une fenêtre définie, une seconde plateforme. La meilleure version de cette section est longue et légèrement fastidieuse à lire. C'est une qualité, pas un défaut - le flou ici est la source des litiges du type « je pensais que c'était inclus ».
À quoi ressemble un vrai document
Nous publions un exemple de Blueprint anonymisé montrant les huit sections remplies pour un projet réel - pas un modèle avec du texte de remplissage, un véritable document de cadrage avec de vraies décisions et de vrais chiffres. Le lire va plus vite que d'en lire une description.
Le test pour savoir si le vôtre est réel
Remettez le document à un ingénieur qui ne vous a jamais parlé et demandez-lui d'estimer le calendrier. S'il peut le faire sans appel de clarification, c'est un document de cadrage. S'il revient avec dix questions, vous avez une liste de fonctionnalités avec un prix accroché - et ces dix questions sont exactement ce qui remontera sous forme de demandes de changement une fois le projet déjà lancé, quand y répondre coûte bien plus cher.
Envie de voir à quoi ressemble un document de cadrage complet sur un projet réel ? Notre exemple de Blueprint est le document complet, pas un extrait. Ou parlez-nous de votre projet et nous le cadrerons correctement avant d'annoncer un chiffre.
Questions fréquentes
Écrit par
Shakhbozbek Usmonov
Founder & CEO, Steppe Venture Builders
