Et si on arrêtait de commencer les projets par la mauvaise question ?

Repenser le recueil des besoins :

Ne plus partir des besoins, mais des problèmes

Dans la majorité des projets, les ateliers de recueil des besoins commencent de la même manière : on réunit les utilisateurs, on projette une matrice ou un canevas, et on pose la fameuse question :

« De quoi avez-vous besoin ? »

C’est une question logique, directe, orientée action. Pourtant, elle enferme d’emblée l’analyse dans une logique de réponse. On passe alors à côté de la véritable nature du travail d’analyse : comprendre la situation, identifier les enjeux, et éclairer les décisions. Cet article propose une approche alternative, pour repositionner le rôle du Business Analyst : non pas comme collecteur de besoins, mais comme analyste de problèmes.

1. Clarifier les concepts : besoin vs problème

Avant toute chose, il faut définir précisément les termes. Un besoin est une réponse attendue à une insatisfaction, un manque ou un objectif à atteindre. Un problème, lui, est une situation observée qui empêche l’atteinte d’un objectif ou crée une perte de valeur. Autrement dit, le besoin est souvent une manière de répondre à un problème, mais il ne suffit pas à comprendre l’enjeu réel.

Prenons un exemple. Lorsqu’un utilisateur dit « J’ai besoin d’un tableau de bord », cela semble clair. Mais quel est le problème sous-jacent ? Est-ce un manque de visibilité ? Un excès de données mal hiérarchisées ? Une incapacité à réagir à temps ? Le tableau de bord est une solution supposée, pas une analyse de la cause. En posant la question du problème, le Business Analyste ouvre l’exploration à d’autres alternatives, peut-être plus simples, plus efficaces ou moins coûteuses.

2. Les risques d’un recueil centré sur les besoins

Lorsqu’on se limite aux besoins exprimés, plusieurs dérives apparaissent. La première, c’est la dérive solutionniste. Les utilisateurs, animés de bonne foi, formulent des réponses prémâchées à des questions mal posées. Cela conduit à des cahiers des charges qui empilent des fonctionnalités, sans logique globale. Le projet devient une succession d’attentes individuelles, souvent contradictoires.

Le deuxième risque, c’est l’oubli du contexte. Un besoin exprimé hors de son environnement perd son sens. Le rôle du BA est de replacer chaque demande dans un cadre opérationnel, organisationnel, technique et humain. Sans cela, on peut livrer une solution conforme à la demande, mais inopérante sur le terrain.

Enfin, un recueil centré sur les besoins favorise la rigidité. On cherche à satisfaire des demandes formalisées, au lieu de comprendre une situation évolutive. Cela rend les projets plus difficiles à adapter, et moins ouverts à l’innovation.

3. Une approche centrée sur les problèmes : méthode et posture

Adopter une approche centrée sur les problèmes ne signifie pas ignorer les besoins, mais les recontextualiser. Concrètement, le BA commence par l’observation : quelles sont les difficultés actuelles ? Qui est impacté ? Quels sont les indicateurs de performance dégradés ? Quels irritants sont récurrents ?

Il utilise des techniques d’analyse comme le QQOQCCP, les 5 pourquoi, ou les arbres de causes pour remonter à la source du problème. Il structure les entretiens non pour recueillir des attentes, mais pour investiguer les obstacles, les doublons, les gaspillages ou les incohérences. Il peut également cartographier les processus existants, identifier les points de friction, ou représenter visuellement les écarts entre la situation actuelle et la cible souhaitée.

La posture est également essentielle. Le BA n’est pas là pour satisfaire des demandes, mais pour éclairer des choix. Il doit parfois remettre en question des évidences, ou proposer des angles de lecture différents. Cela demande de la diplomatie, de la neutralité, mais aussi de la rigueur.

4. Les bénéfices d’une analyse orientée problème

Travailler sur les problèmes avant de formuler des besoins change profondément la dynamique du projet. D’abord, cela permet de hiérarchiser les actions en fonction de la valeur réelle à créer. Plutôt que de livrer une solution par demande, on construit une trajectoire cohérente et priorisée.

Ensuite, cette approche favorise l’agilité. En partant des problèmes, on accepte qu’il existe plusieurs façons d’y répondre. On peut tester des hypothèses, prototyper des solutions, mesurer les effets. Cela ouvre la porte à l’amélioration continue et à l’ajustement itératif.

Enfin, c’est un formidable levier de conduite du changement. Lorsque les parties prenantes comprennent qu’on traite leurs vrais irritants, qu’on s’intéresse à leurs obstacles quotidiens, l’adhésion au projet est bien plus forte que lorsqu’on leur livre un outil correspondant à une demande formelle.

Conclusion

Repenser le recueil des besoins comme une analyse des problèmes est bien plus qu’un changement de méthode. C’est un changement de posture. C’est considérer que les utilisateurs sont d’abord porteurs d’expertise, de vécu, de signaux faibles, et pas uniquement des prescripteurs de solutions. C’est faire du Business Analyst un professionnel de l’interprétation, de la structuration et de la facilitation, capable de transformer la complexité en trajectoire claire.

Ce n’est qu’à cette condition que les projets répondront à de vrais enjeux, et non à des listes de courses techniques. Car entre un besoin exprimé et un problème résolu, il y a toute la valeur ajoutée de la Business Analyse.

Prenons contact maintenant

Transformez vos besoins en solutions concrètes