/cadrage — définir le besoin
L'interview qui transforme une idée en quelque chose de constructible. Le moment où ton avis vaut le plus cher.
/cadrage F-014Quand l'utiliser
Quand une fonctionnalité doit passer d'une idée à quelque chose de constructible. C'est le premier des trois moments où tu décides — et de loin le plus important : si le cadrage est flou, ce qui sort est flou.
Prévois d'y être disponible. C'est une conversation, pas un formulaire.
Comment ça se passe
On te pose des questions, la plupart à choix multiples, et on relance seulement là où c'est vague. Elles tournent autour de six sujets :
| Sujet | La question derrière |
|---|---|
| Hors-scope | Qu'est-ce que cette fonctionnalité ne fait pas ? |
| Critères d'acceptation | À quoi on saura que c'est réussi ? Donne un exemple concret. |
| Cas limites | Et si l'utilisateur fait la mauvaise chose ? Et si c'est vide ? |
| Choix à conséquence | Deux façons de faire, deux résultats différents pour l'utilisateur. |
| Pour qui | Quel profil, quelle règle du produit c'est censé servir. |
| Dépendances | Est-ce que ça a besoin d'autre chose pour fonctionner ? |
Tu réponds en français. Tu n'as jamais à trancher une question technique.
« Pas maintenant » n'est pas la même chose que « hors-scope ».
Hors-scope dit ce que la fonctionnalité ne fera pas — c'est une frontière. Un sujet que tu écartes en disant « on verra plus tard », « pas pour la première version », c'est autre chose : une question ouverte.
Quand ça arrive, on te demande ce qui te ferait revenir dessus, et le sujet est mis de côté avec cette condition. Sans elle, il ne reviendrait jamais — c'est comme ça que les meilleures idées disparaissent.
Le point de validation
À la fin, on te présente un récapitulatif en français :
- Ce que je vais construire — l'objectif et les critères de réussite.
- Ce que je ne fais pas — le hors-scope, explicitement.
- Mis de côté, et ce qui le fera revenir — chaque sujet écarté avec sa condition. S'il n'y en a aucun, on te le dit aussi : ne rien avoir en attente et ne pas avoir regardé sont deux choses différentes.
- Ce que je change dans les règles du produit — chaque changement en clair (« à partir de maintenant, la règle R-001 dira : … »). C'est une modification du comportement de référence : tu l'approuves ici, pas au détour d'un document.
- Signalé à ton attention — les points restés flous.
Tu te prononces item par item avant que l'approbation globale s'ouvre. C'est volontaire : une approbation en bloc ne dit rien de ce que tu as réellement regardé.
Ce que ça produit
La fonctionnalité passe de Cadrage à Prête — mais seulement si une vérification automatique du document est verte. Un cadrage incomplet ne passe pas, quelle que soit ton approbation.
Les essais qui serviront à la recette sont figés à ce moment-là.
Modifier quelque chose qui existe déjà
Si une demande client vise une fonctionnalité déjà construite, elle arrive par
/tickets et se cadre avec son numéro de ticket :
/cadrage T-031L'interview est alors ciblée : on ne te redemande pas ce que le ticket dit déjà, et on ne redéroule pas tout le questionnaire. On décide seulement ce qui bouge. La fonctionnalité ne change pas d'étape — elle reste ce qu'elle est pendant qu'on la modifie.
Ce que ça ne fait pas
- Aucun code. C'est
/dev. - Aucune remise en cause du tri. Si en lisant un ticket il apparaît que la fonctionnalité visée
est la mauvaise, on te le dit et on repasse par
/tickets— jamais de redirection en silence.
Ensuite
/dev F-XXX pour la construire.