Expression de besoin - Cadrer un projet sans le figer

Dans un projet, le vrai risque n’est presque jamais la technique : c’est un cadrage flou. L’expression de besoin sert précisément à transformer une attente encore vague en exigences compréhensibles, testables et partagées. Quand ce travail est bien mené, on réduit les malentendus, on évite les fonctionnalités inutiles et on gagne du temps à chaque étape suivante.

Je vais aller droit au point : ce qu’il faut formaliser, comment recueillir l’information sans noyer le fond, quel support choisir selon le contexte et quelles erreurs je vois revenir dans les projets digitaux comme dans les projets plus classiques.

Ce que l’on formalise vraiment quand on parle du besoin

Je sépare toujours le besoin en quatre niveaux : le problème à résoudre, l’utilisateur concerné, la valeur attendue et les contraintes qui encadrent la solution. Tant que ces quatre éléments ne sont pas posés, on discute souvent d’options techniques avant même d’être d’accord sur la cible.

• Le besoin décrit le changement recherché.
• La solution décrit le moyen choisi pour y parvenir.
• Le livrable décrit ce que l’équipe va remettre.
• Le critère de réussite décrit la preuve que l’objectif est atteint.

Dans les cadres les plus structurés, la logique du besoin fonctionnel pousse justement à décrire le service attendu avant d’écrire la réponse technique. C’est une discipline utile dès qu’un projet touche à la qualité, aux usages ou à la conformité, parce qu’elle réduit la tentation de surspécifier trop tôt.

Quand cette base est solide, le recueil devient beaucoup plus simple à piloter. C’est précisément ce que je mets en place dans la phase suivante.

Comment conduire le recueil sans perdre la finesse du terrain

Le meilleur recueil n’est pas le plus long, mais celui qui fait émerger les vrais arbitrages. Sur un projet simple, je compte souvent 1 à 3 ateliers de 60 à 90 minutes, complétés par des entretiens ciblés ; dès qu’on dépasse ce cadre sans avancer, le problème est souvent le périmètre, pas le format.

1. Préparer le cadrage initial : je reformule le problème en une phrase, je liste les hypothèses et j’écris ce qui est déjà certain.
2. Cartographier les parties prenantes : je ne me contente jamais du sponsor ou du décideur, parce que les utilisateurs, les opérations, le support, la sécurité ou le juridique peuvent changer le projet de manière très concrète.
3. Choisir le bon mode de collecte : entretien individuel pour creuser, atelier pour aligner, observation pour voir les usages réels, prototype pour tester vite.
4. Traduire les attentes en exigences : je transforme chaque demande en formulation vérifiable, avec un verbe clair, un périmètre défini et une manière de tester.
5. Valider avant d’engager l’équipe : une validation orale peut suffire au démarrage, mais je préfère une trace écrite dès que le projet a un coût ou un risque significatif.

Dans les projets numériques, je trouve l’observation et le prototype particulièrement efficaces, parce qu’un utilisateur explique parfois une chose et en fait une autre. Sur un outil interne, cette différence peut paraître mineure ; en production, elle devient souvent la source d’un aller-retour supplémentaire, parfois de plusieurs semaines.

Pour les projets industriels ou les produits plus complexes, des outils comme la bête à cornes ou le diagramme pieuvre aident à structurer l’analyse fonctionnelle et à relier le besoin aux fonctions attendues. Une fois ce recueil posé, la vraie question devient celle du support : document lourd, backlog vivant, ou combinaison des deux.

Quel format choisir selon votre contexte

Je ne choisis pas le même support pour une startup, une refonte de site e-commerce ou un projet réglementé. Le bon format dépend du niveau d’incertitude, du nombre d’acteurs et du coût d’une erreur.

Quand je parle de backlog, je parle d’une liste ordonnée de besoins à traiter, pas d’un inventaire figé. Quand je parle d’une user story, je parle d’un besoin exprimé du point de vue de l’utilisateur, bref et orienté résultat. Ces formats sont utiles, mais ils ne remplacent pas le cadrage initial : ils le prolongent.

Le bon format dépend donc de l’incertitude du projet et du coût d’une erreur. C’est aussi pour cette raison que certains cadrages dérapent alors que les équipes ont pourtant bien documenté le sujet.

Les erreurs qui font dérailler le cadrage

Les dérapages que je vois le plus souvent tiennent rarement à un manque de bonne volonté. Ils viennent plutôt d’un cadrage trop rapide, d’un vocabulaire flou ou d’un refus de trancher ce qui relève du besoin et ce qui relève de la solution.

• Confondre besoin et solution : on impose une idée avant de valider le problème, ce qui ferme des options utiles. Je corrige en reformulant le besoin sans mentionner l’outil.
• Écouter seulement le sponsor : on obtient une vision partielle, parfois très éloignée des usages réels. Je croise toujours la parole des décideurs avec celle des utilisateurs.
• Oublier les contraintes non fonctionnelles : sécurité, performance, accessibilité, maintenance ou RGPD arrivent trop tard. Je les fais apparaître dès le cadrage.
• Rester vague sur le succès : “améliorer”, “fluidifier”, “moderniser” ne suffisent pas. Je demande un indicateur, un seuil ou un comportement observable.
• Ne pas organiser les changements : chaque nouvelle idée devient une dette de décision. Je fixe un circuit clair pour les demandes de modification.

Le point le plus simple à vérifier est souvent le plus révélateur : si je ne peux pas tester l’exigence ou en observer le résultat, c’est qu’elle n’est pas encore assez précise. Ces erreurs deviennent encore plus visibles quand on compare un projet en cycle en V, une démarche agile et une approche hybride.

Cycle en V, agile ou hybride ce qui change vraiment

Je ne traite pas la formalisation du besoin de la même façon selon la méthode de pilotage. Le niveau de stabilité attendu n’est pas le même, et c’est là que beaucoup d’équipes se trompent.

Dans un cadre agile, je considère le besoin comme vivant : on le précise, on le découpe et on l’enrichit au fil des retours. Le refinement, c’est simplement ce travail régulier d’ajustement qui permet au backlog de rester exploitable sans devenir un document théorique.

Dans un cadre plus classique, je sécurise davantage la formulation initiale, parce que les impacts de changement sont plus lourds à absorber. L’approche hybride, elle, marche bien quand le projet a besoin d’un cap clair mais que l’on ne peut pas figer tous les détails dès le départ.

Le bon réflexe n’est donc pas de choisir une méthode par effet de mode, mais de choisir le niveau de formalisation qui correspond au risque réel du projet.

Ce que je sécurise avant de lancer le projet

Avant d’autoriser le démarrage, je vérifie toujours un noyau de points. S’ils sont flous, je sais que le projet me réclamera des clarifications plus tard, souvent au pire moment.

• Le problème est formulé en une phrase simple et comprise par tous.
• L’utilisateur ou le groupe d’utilisateurs principal est identifié.
• Le périmètre inclus et le périmètre exclu sont écrits noir sur blanc.
• Les contraintes non négociables sont visibles dès le départ.
• Les critères d’acceptation ou de succès sont suffisamment concrets pour être vérifiés.
• Le propriétaire du besoin et le circuit de décision sont clairs.
• La règle de gestion des changements est connue avant le premier développement ou la première exécution.

Quand j’ajoute une maquette ou un prototype, je gagne souvent en qualité de décision, surtout pour un parcours digital, un site ou un produit en ligne. C’est souvent plus efficace qu’un long document, parce que tout le monde regarde la même chose au lieu d’imaginer une version différente du projet.

Si je devais retenir une seule règle, ce serait celle-ci : un bon cadrage ne cherche pas à tout figer, il cherche à rendre les arbitrages visibles avant qu’ils ne coûtent cher. C’est cette discipline, plus que la quantité de documents, qui fait la différence entre un projet qui avance et un projet qui recommence sans cesse.