Un atelier peut être parfaitement organisé, réunir les bonnes personnes et générer beaucoup d’échanges… sans pour autant produire grand-chose.
Pour le Business Analyst, la difficulté n’est pas seulement de faire parler les participants. Il faut faire émerger les informations utiles, révéler les divergences, éviter que certaines voix prennent toute la place et aider le groupe à progresser vers un résultat exploitable.
Tout cela sans orienter artificiellement les réponses ni décider à sa place.
C’est précisément le rôle de la facilitation.
1. Faciliter un atelier ne signifie pas simplement animer une réunion
Il est 11 heures. L’atelier se termine. Pendant une heure, les participants ont échangé, argumenté, posé des questions. Le tableau est couvert de Post-it et plusieurs sujets intéressants ont émergé. Tout le monde a beaucoup parlé. Pourtant, au moment de conclure, une question toute simple suffit parfois à révéler le problème : qu’avons-nous réellement produit pendant cette heure ?
C’est là que se situe une différence importante entre animer une réunion et faciliter un atelier. L’objectif du Business Analyst n’est pas simplement de distribuer la parole, de respecter un ordre du jour ou de maintenir une bonne dynamique. Il doit créer les conditions qui permettent au groupe de progresser vers l’objectif fixé : comprendre une situation, faire émerger des besoins, confronter plusieurs points de vue, clarifier une règle, explorer des options ou préparer une décision.
Cela ne signifie pas pour autant conduire les participants vers la réponse que le BA considère comme la meilleure. C’est même l’un des pièges de la facilitation : à force de vouloir faire avancer le groupe, on peut finir par orienter les échanges, privilégier certaines réponses ou fermer trop rapidement une discussion.
Faciliter, c’est donc intervenir sur la manière dont le groupe travaille, sans prendre possession du résultat qu’il doit produire.
Et cette frontière est parfois beaucoup plus fine qu’elle n’en a l’air.
2. Pourquoi la facilitation est une compétence clé du Business Analyst
Le Business Analyst intervient rarement dans un environnement où tout le monde possède les mêmes informations, poursuit exactement les mêmes objectifs et partage la même compréhension du problème. C’est même souvent l’inverse.
Autour d’une table, un opérationnel peut connaître parfaitement les exceptions d’un processus que son manager ne voit jamais. Un responsable peut avoir une vision plus globale, mais moins précise du travail réel. Une équipe IT peut raisonner en termes de contraintes techniques quand le métier parle d’expérience utilisateur. Deux personnes peuvent même utiliser le même mot en lui donnant des significations différentes.
À cela s’ajoutent les dynamiques humaines. Celui qui possède le plus d’expertise n’est pas nécessairement celui qui parle le plus. La présence d’un manager peut modifier la façon dont certains collaborateurs s’expriment. Un participant peut défendre une solution parce qu’il y travaille depuis plusieurs mois, tandis qu’un autre peut éviter de soulever un problème qui remettrait en cause une décision déjà prise.
Le rôle du BA n’est pas de faire disparaître artificiellement ces différences. Elles constituent au contraire une partie de la matière qu’il doit faire émerger et clarifier.
C’est pourquoi être neutre ne signifie pas être passif. Le Business Analyst peut intervenir fortement sur le processus : distribuer la parole, questionner, reformuler, rendre une contradiction visible, recentrer le groupe ou interrompre une discussion qui l’éloigne de son objectif.
La difficulté consiste à le faire sans transformer progressivement sa propre lecture de la situation en celle du groupe.
La facilitation fait d’ailleurs partie des techniques mobilisées dans les pratiques d’élicitation et de collaboration décrites par l’IIBA.
3. 8 techniques de facilitation pour un atelier de Business Analysis
Technique 1 : utiliser le silence intentionnel
Le silence peut être un véritable outil d’élicitation. Après une question, quelques secondes laissées à l’interlocuteur peuvent lui permettre de réfléchir, de préciser sa pensée ou d’ajouter spontanément une information que le BA n’aurait pas pensé à demander. À l’inverse, vouloir combler immédiatement le vide conduit parfois à reformuler trop vite, à suggérer une réponse ou à interrompre une réflexion qui était simplement en train de se construire.
Mais le silence n’est pas une recette. Dans un entretien individuel, il peut laisser à une personne peu à l’aise à l’oral le temps de formuler sa réponse. Dans un atelier collectif, sa signification dépend aussi de la dynamique du groupe : hésitation, manque d’expertise, crainte de contredire un responsable ou simple absence d’idée.
L’erreur fréquente : provoquer artificiellement de longs silences parce qu’on a appris que « le silence fait parler ». Utilisé sans lecture du contexte, l’outil peut devenir inconfortable sans produire davantage d’informations.
Technique 2 : reformuler sans interpréter
Reformuler permet au Business Analyst de vérifier qu’il a correctement compris une information, mais aussi de rendre cette compréhension accessible au reste du groupe. La nuance est importante : une bonne reformulation restitue ce qui vient d’être exprimé sans y glisser la propre lecture du BA.
Si un participant explique par exemple qu’il vérifie systématiquement certaines demandes avant de les transmettre, reformuler par « Vous effectuez donc un contrôle avant chaque transmission » ne produit pas le même effet que « Vous faites cela parce que vous ne faites pas confiance aux informations reçues ». Dans le second cas, le BA a déjà introduit une interprétation.
La reformulation peut également permettre de ralentir une discussion lorsque plusieurs notions commencent à se mélanger et de vérifier que les participants parlent bien de la même chose.
L’erreur fréquente : transformer subtilement une hypothèse en constat. Plus une reformulation semble évidente, plus le groupe risque de la valider sans remarquer ce que le BA y a ajouté.
Technique 3 : poser des questions qui explorent plutôt que des questions qui confirment
Plus le Business Analyst connaît son sujet, plus un risque apparaît : entrer dans l’atelier avec une explication déjà construite et utiliser, sans s’en rendre compte, ses questions pour la confirmer.
« Le problème vient donc du délai de validation ? » appelle beaucoup plus facilement un oui ou un non que : « Qu’est-ce qui explique ce délai ? ». Dans le premier cas, une hypothèse est déjà contenue dans la question. Dans le second, le champ reste ouvert à une explication que le BA n’avait peut-être pas envisagée.
Les questions exploratoires sont particulièrement utiles lorsque le groupe semble parvenir très rapidement à une explication commune. Ce consensus apparent mérite parfois d’être interrogé : sur quels faits repose-t-il ? Existe-t-il des exceptions ? Tous les participants observent-ils réellement la même chose ?
L’erreur fréquente : confondre précision et orientation. Une question très précise peut sembler efficace tout en enfermant progressivement l’interlocuteur dans le cadre de réflexion du Business Analyst.
Technique 4 : rendre les divergences visibles plutôt que rechercher trop vite le consensus
Lorsqu’un désaccord apparaît en atelier, le réflexe peut être de chercher rapidement un compromis pour permettre au groupe d’avancer. Pourtant, une divergence est souvent une information précieuse. Deux participants qui ne décrivent pas la même règle, la même priorité ou le même fonctionnement peuvent révéler une exception, une ambiguïté ou simplement deux réalités différentes.
Le rôle du Business Analyst peut alors consister à matérialiser cette divergence : « Nous avons actuellement deux interprétations de cette règle. » Le désaccord cesse d’être une opposition entre deux personnes pour devenir un élément que le groupe peut examiner.
Il n’est d’ailleurs pas toujours nécessaire de le résoudre pendant l’atelier. Identifier ce qui doit être vérifié, qui peut arbitrer ou quelle information manque constitue déjà un résultat.
L’erreur fréquente : chercher le consensus pour préserver une bonne dynamique. Un accord obtenu trop rapidement peut simplement masquer un problème qui réapparaîtra plus tard dans le projet.
Technique 5 : revenir du « comment » au besoin derrière la solution proposée
Les participants arrivent parfois en atelier avec une solution déjà formulée : ajouter un champ, automatiser une étape, créer une alerte, modifier un écran… Cette proposition est utile, mais elle ne dit pas nécessairement tout du besoin auquel elle cherche à répondre.
Le Business Analyst peut donc revenir sur l’objectif recherché. Pourquoi ce champ est-il nécessaire ? Que doit permettre cette alerte ? Que se passe-t-il aujourd’hui lorsqu’elle n’existe pas ? Une demande d’ajout de champ peut, par exemple, révéler un besoin de traçabilité lié à un contrôle plutôt qu’un simple besoin d’information supplémentaire.
L’objectif n’est pas de contester la solution proposée. Elle peut d’ailleurs être parfaitement pertinente. Il s’agit de comprendre ce qui la motive afin que le groupe puisse raisonner à partir du besoin et pas uniquement de la première réponse envisagée.
L’erreur fréquente : challenger systématiquement les solutions des participants, au risque de transformer l’élicitation en confrontation inutile.
Technique 6 : matérialiser la réflexion du groupe
Une discussion exclusivement orale oblige chacun à conserver mentalement ce qui a été dit, tout en intégrant les nouvelles informations qui arrivent. Matérialiser progressivement la réflexion permet au groupe de travailler sur quelque chose de visible et de commun : un processus, une liste de règles, une carte, un tableau de critères ou un simple schéma.
L’intérêt ne réside pas dans l’outil utilisé. Un tableau blanc peut être aussi efficace qu’un outil collaboratif sophistiqué. Ce qui compte, c’est que les participants puissent regarder la même représentation, la compléter, la contredire ou signaler ce qui manque.
Cette matérialisation peut aussi faire apparaître des incohérences qui seraient restées invisibles dans une conversation : une étape manquante, deux règles incompatibles ou une exception jamais évoquée.
L’erreur fréquente : se concentrer sur la qualité du support au point d’oublier sa fonction. L’objectif n’est pas de produire un joli tableau pendant l’atelier, mais de soutenir la réflexion du groupe.
Technique 7 : utiliser le timeboxing sans sacrifier l’élicitation
Un atelier a une durée limitée, alors que les sujets qui émergent ne respectent pas toujours le planning prévu. Une discussion importante peut apparaître là où le Business Analyst avait prévu de passer cinq minutes. À l’inverse, un sujet complexe peut monopoliser le groupe sans être indispensable à l’objectif de la séance.
Le timeboxing aide à garder cette maîtrise du temps. Mais respecter mécaniquement le minutage peut être aussi contre-productif que de laisser toutes les discussions se prolonger. Faciliter implique donc d’arbitrer : poursuivre parce qu’une information essentielle est en train d’émerger, reporter un sujet, l’inscrire dans un « parking lot » ou identifier les personnes qui devront le traiter séparément.
Le principe de timeboxing est notamment utilisé dans les pratiques agiles pour maintenir le focus d’un échange dans une durée définie.
Un sujet peut ainsi être parfaitement légitime sans devoir être résolu dans cet atelier.
L’erreur fréquente : confondre respect du planning et réussite de l’atelier. Terminer exactement à l’heure n’a que peu d’intérêt si le groupe n’a pas atteint l’objectif pour lequel il était réuni.
Technique 8 : terminer par ce qui est décidé… et ce qui reste ouvert
La fin d’un atelier est souvent consacrée aux décisions prises. Mais ce qui n’a pas été résolu mérite tout autant d’être explicité. Une hypothèse reste-t-elle à vérifier ? Une règle doit-elle être confirmée ? Un arbitrage est-il nécessaire ? Une information manque-t-elle encore ? Qui doit la rechercher et quelle sera la prochaine étape ?
Cette clarification évite un phénomène fréquent : plusieurs participants quittent la même réunion avec des perceptions différentes de ce qui vient d’être conclu.
Le Business Analyst peut donc aider le groupe à distinguer clairement les décisions, les points encore ouverts, les actions à mener et, lorsque c’est pertinent, leurs responsables. Un désaccord identifié mais correctement tracé peut ainsi constituer un résultat plus utile qu’un consensus artificiel obtenu dans les dernières minutes.
L’erreur fréquente : considérer que l’atelier est terminé lorsque le temps prévu est écoulé. Il l’est réellement lorsque chacun sait ce qui a été produit et ce qui doit se passer ensuite.
Mais connaître la banque ne fait pas de vous un Business Analyst
C’est ici qu’il faut éviter un raccourci un peu trop séduisant (qui, entre parenthèse, était une réalité du marché quand j’ai débuté. Mais les temps ont changé).
Parce qu’un conseiller bancaire sait analyser un besoin client, manipuler des règles complexes et comprendre un processus de crédit, il possède effectivement un capital très utile pour une reconversion. Mais cela ne signifie pas qu’il sait déjà exercer le métier de Business Analyst en systèmes d’information.
Prenons un irritant qu’il connaît bien : les dossiers de crédit arrivent régulièrement incomplets et génèrent des allers-retours avec les clients.
Un professionnel expérimenté de la banque saura probablement expliquer pourquoi cela se produit, quelles pièces posent problème et quelles conséquences cela entraîne pour le conseiller et le client. Le Business Analyst doit aller un cran plus loin : analyser le processus existant, confronter le point de vue du conseiller à celui du crédit, du risque ou de la conformité, identifier les règles et les exceptions, puis traduire cette analyse en exigences logicielles suffisamment précises pour qu’une équipe puisse concevoir une évolution du système.
Et surtout, il doit pouvoir vérifier que la solution finalement développée répond bien au besoin initial.
C’est cette chaîne complète qui apparaît dans les postes de Business Analyst proposés par les banques : recueil et analyse du besoin, spécifications fonctionnelles, collaboration avec les équipes techniques, participation aux méthodes Agile, définition des tests, recette et accompagnement jusqu’au déploiement. La Société Générale décrit par exemple un cycle allant de la compréhension du besoin jusqu’aux tests et à la mise en production ; chez BPCE, les offres font également apparaître Jira, Confluence, SQL sur certains postes et la maîtrise des méthodes Agile.
C’est généralement là que se situe le véritable écart de compétences pour un professionnel de la banque qui n’a jamais travaillé sur un projet IT.
Il peut connaître parfaitement le crédit sans savoir cartographier un processus AS-IS et concevoir son TO-BE. Il peut avoir recueilli les besoins de centaines de clients sans avoir jamais conduit un atelier de recueil des exigences. Il peut connaître une règle métier sans savoir la formaliser pour qu’elle soit comprise sans ambiguïté par une équipe de développement. Il peut enfin avoir testé quotidiennement, au sens courant du terme, les limites d’un outil bancaire sans avoir jamais construit une stratégie de recette ou des critères d’acceptation.
Et ce sont précisément ces compétences qu’il devra acquérir.
Il ne s’agit donc ni de repartir de zéro, ni de rebaptiser artificiellement quinze années d’expérience bancaire en « expérience de Business Analyst ».
L’expérience bancaire constitue le capital de départ. La Business Analyse est le nouveau métier à apprendre.
Cette distinction est importante pour construire une reconversion réaliste. Elle permet aussi d’éviter une erreur fréquente : vouloir devenir d’abord un BA parfaitement généraliste, comme si toute l’expérience accumulée auparavant devait être mise entre parenthèses.
Car pour décrocher une première opportunité, le chemin le plus court se trouve parfois précisément dans le domaine que l’on connaît déjà.
4. Une technique de facilitation n’est jamais une recette
Ces huit techniques ont un point commun : aucune ne fonctionne indépendamment du contexte.
Un silence qui aide une personne à approfondir sa réponse en entretien individuel peut produire un tout autre effet face à un groupe. Une reformulation utile dans une situation peut devenir orientée dans une autre. Une divergence mérite parfois d’être explorée immédiatement ; parfois, le meilleur choix consiste à la tracer et à poursuivre l’atelier.
La facilitation demande donc au Business Analyst de lire ce qui se passe dans le groupe : qui parle, qui ne parle pas, quelles réactions apparaissent, où se situent les incompréhensions, mais aussi ce que ses propres comportements peuvent provoquer.
C’est ce qui fait toute la différence entre connaître une technique et savoir l’utiliser.
Le BA ne dispose pas d’une boîte à outils dans laquelle il suffirait de choisir mécaniquement la bonne méthode. Il adapte son intervention à l’objectif du recueil, aux personnes présentes et à ce qui émerge pendant l’échange.
Le rôle du Business Analyst : faire avancer sans décider à la place du groupe
La réussite d’un atelier ne se mesure donc ni au nombre de Post-it produits, ni au nombre de personnes qui ont pris la parole.
Elle se mesure d’abord à ce que le groupe est désormais capable de comprendre, de décider ou de faire grâce au travail réalisé ensemble.
Avant votre prochain atelier, une question peut être utile à garder en tête :
« Suis-je en train d’aider le groupe à réfléchir… ou de l’amener vers la réponse que j’ai déjà en tête ? »
La frontière est parfois ténue. Et apprendre à la maîtriser fait partie intégrante du travail d’élicitation du Business Analyst.
Vous souhaitez maîtriser l’élicitation et apprendre à mobiliser ces techniques dans des situations réelles ?
L’élicitation fait partie des compétences travaillées dans les parcours BA Ready™, pour les personnes qui préparent leur reconversion vers le métier de Business Analyst, et BA Elevate™, pour les BA qui souhaitent structurer et faire évoluer leur pratique.
Les candidatures pour les cohortes de novembre sont actuellement ouvertes.
Et si vous souhaitez vous former en autonomie, l’élicitation est également abordée dans BA Fast Track™, notre parcours e-learning consacré à la pratique de la Business Analyse.
Vous voulez nous poser des questions et y voir plus clair sur votre projet professionnel ?
