Le cahier des charges en une page
Pourquoi le pavé de quarante pages échoue
Le cahier des charges de quarante pages échoue parce que personne ne le relit en cours de projet. Il rassure au moment de la signature, puis il dort dans un dossier partagé. Quand une décision se pose trois semaines plus tard, ni le client ni moi ne rouvrons un document aussi long pour y chercher la réponse. Le cadrage devient un objet mort, et le projet dérive faute de référence vivante.
Le pavé crée aussi une fausse sécurité. Détailler chaque écran et chaque cas limite avant d'avoir codé la moindre ligne, c'est figer des décisions qu'on prendrait mieux plus tard, une fois le terrain mieux connu. On passe des jours à écrire ce qu'on jettera, et on confond exhaustivité avec clarté. Or un projet a besoin de clarté, pas de volume.
Ce que tient une page de cadrage
Une page de cadrage tient l'essentiel : l'objectif, les utilisateurs, le périmètre, ce qui est exclu, et la définition du succès. Je commence par une phrase qui dit pourquoi le projet existe. Puis je nomme les personnes qui vont s'en servir et ce qu'elles viennent y faire. Ensuite seulement viennent les fonctionnalités, listées sans entrer dans le détail des écrans.
Le bloc le plus utile est souvent celui des exclusions. Écrire noir sur blanc ce qu'on ne fait pas dans cette version évite la moitié des malentendus. « Pas de paiement en ligne », « pas d'espace client », « pas d'application mobile » : ces lignes valent de l'or quand une demande surgit en cours de route. Elles transforment une dérive de périmètre en simple décision à prendre, plutôt qu'en conflit.
Je termine par la définition du succès. Pas une promesse marketing, mais un critère vérifiable : le site charge vite, le formulaire envoie un lead par mail, le client met à jour ses horaires seul. Quand le succès est écrit, on sait quand s'arrêter.
Comment cette page se construit avec le client
Cette page se construit avec le client, pas pour lui, en un seul échange dédié. Je préfère un appel ou un rendez-vous où l'on rédige ensemble, à l'écran, plutôt qu'un document que j'envoie pour validation passive. Quand le client voit la phrase d'objectif se former et qu'on bute sur un mot, on touche tout de suite un désaccord qui aurait coûté cher plus tard.
Je pose des questions de débit, pas de spécification. À qui ça sert. Qu'est-ce qui change pour eux le jour de la mise en ligne. Qu'est-ce qui se passe aujourd'hui sans le site. Ces questions ramènent au besoin réel, là où la liste de fonctionnalités cache souvent des envies mal triées. La page se remplit d'elle-même quand le besoin est clair.
La page comme contrat vivant
La page devient un contrat vivant parce qu'on la relit à chaque décision et qu'on la met à jour. Elle est courte, donc on l'ouvre sans appréhension. Quand une nouvelle idée arrive, on la confronte à l'objectif et au périmètre écrits. Si elle entre, on l'ajoute et on en retire éventuellement une autre. Si elle sort du cadre, on la note pour une version suivante. La décision est tracée, datée, partagée.
Ce fonctionnement protège les deux parties. Le client garde la main sur ses priorités sans avoir à comprendre un jargon technique. Moi, je travaille contre une cible stable, et je peux dire non à une demande hors périmètre sans que ce soit un bras de fer : il suffit de pointer la page qu'on a écrite ensemble. Le document n'arbitre pas par autorité, il arbitre par accord.
Quand une page ne suffit pas
Une page ne suffit pas quand le projet porte une logique métier complexe ou des contraintes réglementaires. Un ERP de marchés publics, une application de santé, une intégration avec un système existant : là, certaines règles doivent être spécifiées finement, parce qu'une erreur d'interprétation a des conséquences lourdes. Je ne prétends pas le contraire.
Mais même dans ces cas, la page de cadrage reste le sommet de la pyramide. Elle donne le cap, et les documents détaillés viennent en dessous, attachés à des fonctionnalités précises, écrits au moment où on les implémente. On ne remplace pas la page par le pavé : on garde la page comme boussole, et on descend dans le détail seulement là où le risque l'exige. La règle tient en une phrase : cadrer large et court, spécifier fin et tard.
Freelance ou studio : ce que change Krealabs