Les projets ne dérapent pas à cause de la technique. Ils dérapent parce que personne n'a écrit ce qui n'était pas dans la v1. Comment cadrer en quatre semaines.
Les projets de développement échouent rarement pour des raisons techniques. Ils échouent parce que personne n'a écrit ce qui n'était pas dans la v1.
Le mécanisme est toujours le même. Le périmètre est décidé oralement au démarrage. Chaque semaine ajoute une idée raisonnable — une seule, jamais deux. Personne ne dit non, parce que chaque idée prise isolément coûte deux jours. Au sprint 8, la date a glissé de deux mois et personne ne peut dire quelle décision en est responsable. Aucune ne l'est. Leur accumulation, oui.
Le coût de la correction selon le moment.
Une erreur trouvée sur une maquette coûte 1. Sur un prototype testé, 3. Dans du code livré, 15. Après le lancement, avec des données réelles, de 50 à 100. Le facteur exact se discute selon les études ; l'ordre de grandeur, lui, ne se discute pas — et il justifie à lui seul de passer un mois à cadrer un projet de six mois.
Ce qu'un cadrage produit réellement.
Pas des maquettes. Des décisions écrites. Le problème, formulé comme une phrase testable : « les organisateurs perdent deux heures par événement à réconcilier les listes d'invités » se vérifie. « Améliorer l'expérience événementielle » ne se vérifie pas, donc ne se conteste pas, donc ne cadre rien.
Un utilisateur, pas trois. Un produit qui sert les organisateurs, les participants et les partenaires dès la v1 n'en sert aucun correctement. Choisis celui dont la douleur est la plus vive et accepte de décevoir les deux autres pendant six mois.
La liste du hors-périmètre est le document le plus important, et celui que presque personne ne rédige.●
C'est ce qui te permet de répondre « oui, en v2 » au lieu de « on va voir ». Sans elle, chaque bonne idée devient une négociation.
La contrainte réglementaire, identifiée maintenant, avec le problème et le marché : elle façonne le modèle de données. Découverte au sprint 10, elle impose une migration. Et un prototype que cinq personnes ont réellement manipulé — pas montré : manipulé, en silence, pendant que tu les regardes chercher un bouton qui te paraissait évident.
Pourquoi cinq utilisateurs.
Parce que le rendement s'effondre après. Cinq personnes révèlent la grande majorité des problèmes d'usage d'un parcours donné ; la sixième confirme surtout ce que les cinq premières ont déjà montré. Cinq entretiens tiennent en trois jours et ne demandent aucun budget d'étude — ce qui retire le dernier prétexte pour ne pas les faire.
Ce sont ces cinq personnes qui te diront que la fonction dont tu es le plus fier n'intéresse personne. Il vaut mieux l'apprendre en semaine 4 qu'en mois 7.
La règle des quatre semaines.
Semaine 1, le problème et la contrainte. Semaine 2, les parcours et les arbitrages. Semaine 3, les maquettes et le système de design. Semaine 4, les tests, les corrections et un backlog estimé. Quatre semaines, parce qu'au-delà le cadrage devient une manière de retarder la construction. En deçà, on saute les tests utilisateurs — et le cadrage perd ce qui fait sa valeur.
Le signe qu'un cadrage a réussi.
Un développeur qui n'a jamais parlé à ton client peut prendre le dossier et commencer lundi, sans te poser trois questions bloquantes. C'est le seul critère qui compte. Si le dossier ne tient debout qu'avec toi dans la pièce, il n'est pas terminé.
Ce qu'on ne fait pas.
On ne démarre pas un cadrage sans accès à cinq utilisateurs cibles. C'est une condition, pas une préférence — sans eux, on produit un document d'opinion, et tu n'as pas besoin de nous pour ça.