Une demande arrive : « il nous faut un export Excel des commandes ». L'équipe technique le livre. Trois semaines plus tard, personne ne s'en sert, parce que le vrai besoin était de savoir chaque matin quelles commandes partaient en retard. Le fichier était juste ce que la personne avait imaginé comme solution. Une expression de besoin sert à éviter ça : dire le problème avant l'outil, puis le traduire en quelque chose qu'une équipe technique peut construire et vérifier.
J'ai passé une bonne partie de mes vingt ans de projets des deux côtés de cette table, en maîtrise d'ouvrage puis en maîtrise d'œuvre, et aujourd'hui je travaille seul : je conçois et je construis moi-même. Je ne peux donc pas me cacher derrière « le métier n'a pas été clair » ou « la technique n'a pas compris ». Voici la méthode que j'applique, ce qu'elle m'a évité, et là où elle ne suffit pas.
01Pourquoi une expression de besoin se perd entre le métier et la technique
Le métier et la technique ne parlent pas de la même chose. Le métier parle de clients, de délais, de marges, d'erreurs qui coûtent. La technique parle de champs, de flux, d'API et de cas limites. Entre les deux, chacun traduit dans sa tête, et chaque traduction perd un peu de sens.
Trois pertes reviennent presque à chaque fois. La première : la demande est formulée comme une solution (un export, un bouton, une alerte par e-mail), et la raison disparaît. La deuxième : un mot n'a pas le même sens pour tout le monde. « Commande validée » veut dire payée pour la comptabilité, préparée pour l'entrepôt. La troisième : le document change sans que personne ne sache quelle version fait foi.
Sur une intégration entre un ERP et un site marchand, la spécification a bougé presque à chaque réunion. Je l'ai fait évoluer version après version, numérotée et datée, pour que tout le monde parle du même document. J'en ai tiré une méthode d'écriture de spécification d'intégration : ce n'était pas un problème de compétence, c'était un problème de référence commune.
02Écrire le besoin avant la solution
La règle que j'applique vient d'un endroit sérieux. Le manuel des services publics britanniques demande qu'un besoin décrive le problème de l'utilisateur plutôt qu'une solution possible, avec un exemple simple : avoir besoin d'un rappel, et non d'un e-mail ou d'un courrier. Le même texte traite toute opinion qui ne vient pas des utilisateurs comme une hypothèse à prouver.
Concrètement, quand on me tend une solution, je remonte d'un cran avec une seule question : « qu'est-ce qui se passe si on ne le fait pas ? ». La réponse donne presque toujours le vrai besoin. Pour l'export Excel, elle aurait été : « je découvre les retards quand le client appelle ».
Le format que j'utilise tient en trois lignes :
- quand… (la situation qui déclenche le besoin) ;
- j'ai besoin de… (ce que la personne doit pouvoir faire) ;
- pour… (le résultat attendu, celui qui compte).
C'est proche du format des user stories, et le guide britannique sur l'écriture des user stories dit quelque chose que je trouve juste : la partie la plus importante est le but, et si vous n'arrivez pas à l'écrire, il faut se demander pourquoi vous voulez cette fonctionnalité.
03Traduire un besoin métier en technique, en cinq étapes
Voici le déroulé que je suis, sur un projet de quelques semaines comme sur une demande isolée. Il s'insère bien dans un cadrage de projet d'une semaine.
1. Écouter ceux qui vivent le problème
Avant d'écrire, je parle aux personnes concernées, une par une. Le Nielsen Norman Group décrit bien ce que ces entretiens avec les parties prenantes apportent : l'historique, les contraintes, les solutions déjà essayées et ce que le succès veut dire concrètement. La relance qui m'aide le plus est la plus simple : « pouvez-vous me donner un exemple ? ». Un exemple réel vaut dix généralités.
2. Écrire le besoin avec leurs mots
Je rédige les besoins dans le vocabulaire du métier, puis je les relis avec eux. S'ils ne se reconnaissent pas dans la phrase, c'est que j'ai déjà traduit trop tôt.
3. Fixer le vocabulaire et les données de référence
Je fais une petite liste des mots qui comptent, avec leur définition et l'outil qui fait foi. C'est l'étape la plus ingrate et celle qui m'a le plus servi. Un mélange de centimètres et de millimètres entre deux outils suffit à déformer tout un rendu : depuis, l'unité et la source de chaque donnée sont écrites noir sur blanc.
4. Dériver les exigences techniques, et garder le lien
Pour chaque besoin, j'écris ce que le système doit faire, puis j'indique de quel besoin vient chaque exigence. Le manuel britannique appelle ça la traçabilité : les besoins sont larges et stables, les stories plus précises, et chaque story garde la trace du besoin qu'elle sert. Quand quelqu'un demande pourquoi un champ existe, la réponse est dans le document.
5. Écrire comment on saura que c'est fait
Chaque exigence reçoit un critère d'acceptation, rédigé en « c'est fait quand… ». C'est là que le métier et la technique se mettent d'accord pour de bon, parce qu'un critère se vérifie. Quand le sujet s'y prête, je montre aussi une maquette : présenter plusieurs directions au même niveau de finition débloque souvent une décision que des pages de texte n'obtiennent pas. J'en parle dans l'article sur le prototype cliquable.
04Rendre la règle métier vérifiable
Pour qu'une règle métier passe intacte du côté technique, je n'ai rien trouvé de plus sûr que d'en faire un test. Chez Moonworkers, mon entreprise de paie pour les petites entreprises britanniques, les règles de cotisation viennent des textes du HMRC, l'administration fiscale. Plutôt que de les résumer dans un document, j'ai écrit à partir de ces textes un « oracle » qui recalcule les résultats de façon indépendante. Il a rejoué 896 cas et trouvé quatre erreurs d'un penny, toutes dues à une règle d'arrondi. Je raconte le détail dans l'article sur l'oracle de test.
Ces écarts d'un penny, aucune relecture de spécification ne les aurait trouvés. La règle était juste sur le papier ; c'est sa traduction en code qui dérivait, au moment de l'arrondi.
Vous n'avez pas besoin d'aller aussi loin pour en tirer quelque chose. Une liste d'exemples concrets, entrée et résultat attendu, validée par le métier, fait déjà office de contrat. L'équipe technique peut la rejouer, et le métier peut la lire.
05Expression de besoin, cahier des charges, spécification : qui écrit quoi
Je vois souvent ces trois documents confondus. Voici comment je les sépare :
- L'expression de besoin dit le problème, le but, les contraintes et ce qui est hors périmètre. Le métier l'écrit en premier, avec quelqu'un qui pose les questions.
- Le cahier des charges dit ce qu'on attend du prestataire : périmètre, livrables, délais, recette. C'est le donneur d'ordre qui l'écrit.
- La spécification dit comment le système se comporte, donnée par donnée. L'équipe technique l'écrit, et le métier la relit.
Sur un petit projet, les trois tiennent dans un seul document. L'ordre, lui, ne change pas.
Reste à savoir qui arbitre. Le Scrum Guide le dit clairement : le Product Owner est une personne, pas un comité, il peut représenter les besoins de nombreuses parties prenantes, et c'est à lui de rendre les éléments du backlog clairs et compris. En revanche, ce sont les développeurs qui décident comment ils les réalisent. Cette séparation entre le quoi et le comment est exactement celle qu'une bonne expression de besoin respecte. La vidéo d'Henrik Kniberg, Agile Product Ownership in a Nutshell, résume ce rôle en un quart d'heure, entre les demandes des parties prenantes, le backlog et la priorisation par la valeur.
Dans mes machines de contenu, j'ai repris la même logique. Le brief bloque la rédaction tant que l'angle et la liste de ce que le texte ne dira pas ne sont pas écrits. Les retours d'un relecteur deviennent des règles écrites plutôt que des corrections faites à la main. C'est une expression de besoin appliquée à moi-même.
06Ce que ce rôle d'interface ne règle pas
Une méthode d'écriture ne remplace pas une décision. Si deux directions ne sont pas d'accord sur le but, même un document très soigné ne fera que rendre le désaccord plus visible. C'est utile, mais il faut alors quelqu'un qui tranche, et ce n'est pas la personne qui tient la plume.
Elle a aussi un coût. Fixer le vocabulaire, tracer chaque exigence, écrire les critères : sur une petite évolution, c'est disproportionné. Je réserve la version complète aux sujets où une erreur coûte cher, comme les calculs, les échanges entre outils ou ce que voit le client.
Enfin, je ne prétends pas que le rôle d'interface suffise à faire avancer un dialogue entre DSI et métier bloqué depuis des années. Il aide à remettre tout le monde sur le même document. Il ne répare pas une relation.
07Par où commencer lundi
Prenez la dernière demande arrivée sous forme de solution. Posez-lui la question « qu'est-ce qui se passe si on ne le fait pas ? », puis réécrivez-la en trois lignes : quand, j'ai besoin de, pour. Ajoutez deux critères en « c'est fait quand… » et montrez le tout à la personne qui a fait la demande. Vous verrez vite si vous parliez de la même chose.
Si vous voulez de l'aide pour cadrer un projet de ce type, mes services décrivent comment je travaille, et le portfolio des missions montre ce que j'ai construit. On peut en parler.