« On a toujours fait comme ça. »
Dans un projet, cette phrase peut sembler clore une discussion. Mais… elle peut aussi ouvrir une investigation.
Une validation supplémentaire, une fonctionnalité peu utilisée, un traitement technique compliqué : derrière chaque choix, il y a peut-être une raison solide. Mais cette raison est-elle encore connue ? Et surtout, est-elle toujours valable ?
Pour un Business Analyst, ces questions sont essentielles. Elles permettent de comprendre les besoins, les contraintes et les hypothèses qui ne sont plus spontanément exprimés, parce qu’ils font partie du paysage.
C’est une dimension de l’élicitation qu’on peut facilement négliger : recueillir ce qui semble tellement évident aux interlocuteurs qu’ils ne pensent plus à l’expliquer. Et c’est tellement important que j’ai décidé d’en faire un article.
Bonne lecture !
Élicitation : retrouver la raison derrière les pratiques existantes
Lorsqu’une pratique paraît compliquée, la tentation est de vouloir la simplifier immédiatement.
Pourquoi autant de validations ? Pourquoi cette donnée doit-elle être saisie deux fois ? Pourquoi conserver une fonctionnalité que presque personne n’utilise ?
Il est évidemment utile de poser ces questions. Mais attention à une réponse trop rapide, qui peut conduire à supprimer un élément dont on n’a pas compris la fonction.
Par exemple :
Une validation peut protéger contre une erreur coûteuse. Une double saisie peut compenser une intégration défaillante. Une fonctionnalité rarement utilisée peut répondre à une situation exceptionnelle, mais critique.
Je préfère donc commencer par comprendre ce qui avait conduit au choix.
Quel problème rencontrait-on ? Dans quelles circonstances ? Quelles contraintes existaient alors ? Qui avait besoin de cette solution ?
Cette première investigation permet de reconstituer une logique. On peut ensuite examiner ce qui a changé.
La contrainte existe-t-elle toujours ? Le risque est-il encore présent ? Les utilisateurs travaillent-ils de la même manière ? Une autre solution prend-elle désormais en charge le problème ?
Une pratique héritée peut rester pertinente. Sa justification mérite simplement d’être rendue explicite avant de décider de la conserver, de la modifier ou de la supprimer.
Le rôle des experts métier dans l'élicitation des besoins
Les experts métier et techniques sont indispensables à cette investigation. En tant que BA, nous ne sommes pas les « sachants », même si avec les années, nous pouvons très bien connaître des processus spécifiques.
Les experts – aussi appelés « SME » pour Subject Matter Experts, dans le BABOK de l’International Institute of Business Analysis (IIBA) : eux, ils connaissent les usages, les exceptions, les dépendances et les conséquences qu’un nouvel arrivant ne peut pas deviner. Mais connaître précisément le fonctionnement actuel ne signifie pas disposer de toute l’histoire des décisions.
Une personne peut savoir comment exécuter un contrôle sans connaître le risque qui avait motivé sa création. Un développeur peut maîtriser une fonctionnalité sans avoir participé à l’analyse du besoin initial.
Et même lorsque cette histoire est connue, elle n’est pas nécessairement réexaminée à chaque évolution.
C’est là que le regard du Business Analyst peut être utile.
Il fait préciser les termes, relie les informations et vérifie la compréhension partagée. Il cherche notamment à distinguer :
ce qui relève d’un besoin actuel ;
ce qui constitue une contrainte à respecter ;
ce qui correspond à une hypothèse encore à vérifier ;
ce qui vient d’une décision historique.
Ce travail concerne aussi les professionnels qui pratiquent la Business Analyse sans en porter l’intitulé : un consultant, un Product Owner ou un chef de projet MOA peut rencontrer exactement cette difficulté.
La contribution se construit dans l’analyse conduite avec les experts.
Cas concret d'élicitation : pourquoi cette validation existe-t-elle encore ?
Prenons un cas fictif.
Dans une entreprise, chaque demande de remboursement doit être validée par un manager, puis par le service financier. L’équipe souhaite automatiser davantage le circuit.
Une première approche consisterait à reproduire les deux validations dans le nouvel outil, avec des notifications et des relances.
Mais avant de concevoir ce fonctionnement, le Business Analyst demande pourquoi la seconde validation existe.
Le service financier explique qu’elle a été ajoutée plusieurs années auparavant, après des remboursements en double. À l’époque, les demandes étaient transmises par plusieurs canaux et les justificatifs étaient difficiles à rapprocher.
Depuis, les demandes sont centralisées dans un outil unique. Un contrôle automatique signale certains doublons.
La question initiale change alors d’enjeu : la seconde validation est-elle toujours nécessaire pour toutes les demandes ?
La réponse ne peut pas être déduite de la seule présence du contrôle automatique. Il faut examiner ce qu’il détecte réellement, les erreurs restantes et les autres vérifications effectuées par le service financier.
Peut-être que la validation reste indispensable. Peut-être qu’elle pourrait être réservée à certains cas. Peut-être qu’un contrôle différent serait plus adapté.
L’investigation a néanmoins permis un progrès : l’équipe peut désormais évaluer la validation en fonction du problème qu’elle doit traiter, plutôt que la reconduire uniquement parce qu’elle existe.
Les questions pour identifier les besoins métier implicites
Une question simple peut ouvrir cette investigation. Sa valeur dépend ensuite de la manière dont on utilise la réponse.
« Pourquoi faites-vous cela ? » est un point de départ possible. Mais formulée sans contexte, elle peut être entendue comme une contestation par certains contributeurs.
Je vous recommande donc de préciser l’intention derrière votre question : « Pour comprendre ce qu’il faut préserver dans la future solution, pouvez-vous m’expliquer ce qui avait conduit à cette validation ? »
Ce qui est génial, c’est que cette simple question ouvre alors plusieurs directions exploratoires :
Revenir au problème initial.
Quelle difficulté cette pratique devait-elle résoudre ? À qui arrivait-elle ? Quels effets produisait-elle ?
Comprendre sa valeur actuelle.
Qui bénéficie de ce fonctionnement aujourd’hui ? Quelle décision permet-il de prendre ? Quel risque réduit-il ?
Explorer les exceptions.
Dans quels cas cette étape est-elle particulièrement utile ? Existe-t-il des situations où elle ne l’est pas ?
Examiner les conséquences d’une suppression.
Que se passerait-il si nous arrêtions ce traitement ? Qui serait affecté ? Qu’est-ce qui deviendrait plus difficile ou plus risqué ?
Identifier les changements de contexte.
Les usages, les volumes, les outils ou les responsabilités ont-ils évolué depuis sa mise en place ?
Petite apartée pour celles et ceux qui cherchent à automatiser les questionnements (l’usage de l’IA y est pour quelque chose) : ces questions ne constituent pas un questionnaire à dérouler mécaniquement. Les réponses orientent la suite.
Si l’interlocuteur évoque une obligation, il faut en préciser l’origine. S’il parle d’un risque, il faut comprendre les situations dans lesquelles ce risque se manifeste.
J’appelle cette posture l’« ego-less questioning », ou questionnement sans égo : accepter de demander une explication simple, sans laisser la crainte de paraître peu compétent empêcher l’investigation.
Cela implique aussi de reformuler : « Si je comprends bien, cette étape sert principalement à vérifier ceci. Est-ce exact ? »
Cette démarche rejoint les techniques de facilitation utilisées pour faire émerger les besoins et clarifier les échanges en atelier.
L’objectif est de construire une compréhension suffisamment précise pour analyser la situation.
Élicitation et périmètre métier : que considère-t-on comme inchangé ?
J’ai rencontré cette question dans une mission où j’intervenais comme Business Analyst freelance.
Je venais d’arriver. Face à moi, un architecte, un tech lead, des développeurs et un chef de projet connaissaient très bien l’environnement logiciel du client.
Pendant un atelier technique, mes simples (et non pas « bêtes » !) questions ont fait émerger des habitudes reconduites depuis plusieurs années, dont la justification métier n’était plus clairement identifiée.
Le projet devait juste améliorer techniquement le logiciel « à iso-périmètre métier » : en d’autres termes, comme on était censé partir d’une demande technique, les besoins étaient considérés comme inchangés et la DSI ne voulait pas que les utilisateurs en profitent pour émettre de nouvelle demande métier.
Ce cadrage pouvait bien sûr être compréhensible. Mais la réalité, c’était que le métier avait évolué depuis la mise en place de la solution il y a des années en arrière.
Il devenait donc nécessaire de réexaminer la pertinence de certaines fonctionnalités et de certains choix avant de consacrer des efforts à leur optimisation.
Geler les nouvelles demandes pour maîtriser un projet ne démontre pas que tous les besoins historiques restent actuels.
Cette distinction mérite d’être clarifiée avec les responsables du périmètre. L’investigation peut révéler un sujet à arbitrer, sans donner au BA l’autorisation de modifier seul le cadrage.
Une amélioration technique peut également rester justifiée sans nouvelle fonctionnalité visible : sécurité, fiabilité, maintenance ou capacité d’évolution. Là encore, il faut comprendre la valeur recherchée et les conditions dans lesquelles elle sera obtenue.
Du questionnement à l'analyse des besoins métier
Faire émerger une incertitude est une première étape. Pour éclairer une décision, il faut ensuite vérifier et organiser les informations.
Reprenons notre circuit de remboursement. Si un interlocuteur ne sait pas expliquer la seconde validation, nous avons identifié une information manquante. Nous n’avons pas démontré que cette validation est inutile.
Le Business Analyst doit alors rechercher les éléments pertinents : règles documentées, exemples de demandes, incidents, contrôles existants et explications des acteurs concernés.
Il distingue ce qui est établi de ce qui reste hypothétique.
Cette analyse suppose également de définir le problème ou l’opportunité avant de privilégier une solution.
« Cette étape prend du temps » demande à être précisé. Combien de temps ? Pour quels dossiers ? Avec quelles conséquences ?
« Le contrôle automatique suffit » constitue une hypothèse à examiner. Que couvre-t-il ? Quelles situations lui échappent ?
L’analyse peut ensuite présenter les options : conserver le fonctionnement, l’adapter à certains cas ou envisager une autre réponse au besoin. Chaque option doit être accompagnée de ses impacts, risques et points restant à vérifier.
Voilà ce qui rend le questionnement utile au projet : il permet de passer d’une évidence supposée à une décision mieux étayée.
Vous n’avez pas besoin de connaître toutes les réponses avant d’ouvrir cette investigation. Vous devez, en revanche, travailler avec les réponses obtenues, reconnaître les limites de votre analyse et solliciter les expertises nécessaires.
Renforcer cette capacité dans votre pratique
Si vous exercez déjà la Business Analyse, parfois de manière autodidacte, vous avez peut-être l’intuition des bonnes questions sans toujours savoir comment structurer l’investigation ou défendre vos conclusions.
BA Elevate™ vous accompagne pour professionnaliser cette expérience : renforcer votre démarche d’analyse, mieux argumenter vos choix et développer votre posture auprès des experts et des décideurs.
La prochaine cohorte démarre la semaine du 16 novembre 2026. Les candidatures sont ouvertes jusqu’au 31 octobre.
Faire le point avec l’équipe BoBA permet d’examiner votre situation et de voir si ce parcours correspond à vos objectifs.
