Il y a une erreur que j’ai souvent vue — et que j’ai moi-même appris à éviter avec l’expérience : commencer une mission de Business Analyst par ce qu’on attend de nous, au lieu de commencer par comprendre dans quoi nous venons d’atterrir.
On vous parle d’ateliers à animer, d’un backlog à reprendre, de spécifications fonctionnelles à rédiger, d’un processus métier à modéliser ou d’un besoin à clarifier. Très vite, la question devient : quel est mon premier livrable ?
Mais avant cela, il y a une autre question, beaucoup plus structurante : ai-je suffisamment cadré mon mandat pour produire quelque chose de pertinent ?
Parce qu’un besoin exprimé par les pôles métier, le management ou la DSI n’émerge jamais de nulle part. Il s’inscrit dans un contexte métier, un système d’information, une organisation, une gouvernance, des jeux d’acteurs… et dans une mission dont votre propre rôle n’est pas toujours aussi clair qu’il en a l’air.
Dans cet article, je vous propose donc une checklist de cadrage en 5 dimensions, issue de la réalité des missions terrain : ce que vous devez chercher à comprendre avant votre premier atelier ou votre premier livrable, les questions à poser, et surtout les signaux qui doivent vous alerter.
Comprendre le contexte avant de démarrer une mission de Business Analyst
Lorsque j’arrive sur une nouvelle mission, l’une de mes premières questions est simple : pourquoi ce projet existe-t-il ?
Car le Business Analyst arrive souvent alors qu’une solution est déjà évoquée, voire décidée :
« Nous devons remplacer notre CRM. »
« Il faut digitaliser ce processus. »
« Nous allons changer d’ERP. »
Mais cela nous dit ce que l’organisation veut faire, pas nécessairement le problème qu’elle cherche à résoudre.
Prenons le remplacement d’un CRM, exemple que nous garderons dans cet article. Derrière cette même décision peuvent se cacher des réalités très différentes : des commerciaux qui ressaisissent les informations, des données clients peu fiables, un outil qui ne sera bientôt plus maintenu ou encore une entreprise qui doit accompagner sa croissance internationale.
La solution affichée est la même. Les enjeux, eux, ne le sont pas. Et cela changera nécessairement votre analyse.
Avant d’entrer dans les besoins détaillés, je cherche donc à comprendre :
- Quel problème ou quelle opportunité a déclenché le projet ?
- Pourquoi maintenant ?
- Quels résultats métier ou économiques sont attendus ?
- Comment saura-t-on que la situation s’est améliorée ?
- Quelles décisions structurantes ont déjà été prises ?
Une question est particulièrement efficace pour remonter à l’enjeu réel :
« Que se passe-t-il si nous ne faisons rien ? »
L’objectif n’est pas de refaire l’étude d’opportunité. Si vous rejoignez un projet déjà lancé, votre travail consiste plutôt à comprendre son historique, les hypothèses retenues et les arbitrages déjà réalisés.
À vérifier
Avant votre premier livrable, vous devriez pouvoir expliquer avec vos propres mots :
- pourquoi le projet existe ;
- quelle valeur ou quel résultat il recherche ;
- pourquoi il est lancé maintenant ;
- quelles décisions importantes sont déjà actées.
Si vous ne pouvez expliquer le projet qu’en citant sa solution — « on change de CRM » — vous n’avez probablement pas encore remonté assez loin dans son contexte.
Cadrer le périmètre, le SI et les dépendances du projet
Une fois que j’ai compris pourquoi le projet existe, je cherche à savoir dans quoi il vient s’insérer.
C’est particulièrement important sur les projets SI : une application ne vit presque jamais seule.
Reprenons notre CRM. Il peut échanger avec l’ERP, le site web, un outil marketing, la facturation, le référentiel clients ou encore le reporting commercial. Une demande fonctionnelle apparemment anodine peut donc avoir des conséquences bien au-delà du CRM.
Le Business Analyst n’a pas besoin de devenir architecte ou développeur pour comprendre cet environnement. En revanche, il doit en avoir une vision suffisante pour se demander :
« Si nous modifions quelque chose ici, qu’est-ce qui risque de bouger ailleurs ? »
À ce stade, je cherche notamment à identifier :
- ce qui est dans le périmètre du projet — et ce qui ne l’est pas ;
- les principaux systèmes, processus et données concernés ;
- les interfaces et dépendances importantes ;
- les contraintes SI déjà connues ;
- les autres projets ou évolutions susceptibles d’avoir un impact.
Il faut aussi distinguer ce qui est réellement imposé de ce qui est simplement présenté comme tel. Sur un projet déjà bien avancé, certaines contraintes sont parfaitement légitimes ; d’autres sont parfois des hypothèses anciennes que plus personne n’a pensé à questionner.
À vérifier
Avant votre premier livrable, vous devriez pouvoir :
- décrire le périmètre sur lequel vous intervenez ;
- identifier les principaux systèmes et processus concernés ;
- repérer les dépendances importantes ;
- distinguer les contraintes connues des zones encore à explorer.
Vous n’avez pas besoin d’une cartographie SI parfaite.
Mais si vous analysez un besoin sans savoir ce qu’il peut impacter autour de lui, vous risquez de raisonner juste… sur un périmètre trop petit.
Identifier les parties prenantes… sans s’arrêter à l’organigramme
Une fois le terrain de jeu compris, je cherche à savoir avec qui je vais réellement devoir travailler.
Identifier les parties prenantes paraît assez évident : sponsor, métiers, utilisateurs, chef de projet, Product Owner, IT, experts, fonctions transverses…
Mais une liste de noms ou un organigramme ne suffit pas.
Sur le terrain, j’ai appris à distinguer plusieurs choses : le rôle officiel, le pouvoir de décision, le niveau d’influence et la détention de l’information. Et les quatre ne sont pas toujours réunis chez la même personne.
Sur notre projet CRM, le directeur commercial peut être le sponsor officiel, tandis qu’une responsable des ventes connaît réellement les difficultés quotidiennes des utilisateurs. Un autre collaborateur, absent des comités projet, peut détenir une connaissance historique indispensable pour comprendre certaines règles métier.
Le BA doit donc chercher à savoir :
- qui décide et qui influence ;
- qui possède l’expertise métier nécessaire ;
- qui utilisera réellement la solution ;
- qui sera impacté, directement ou indirectement ;
- qui soutient le projet — et qui pourrait avoir de bonnes raisons d’y être réticent.
C’est là toute la différence entre identifier une partie prenante et la comprendre.
Pour approfondir la gestion et l’analyse des parties prenantes, les ressources du Project Management Institute (PMI) constituent également une référence utile.
À vérifier
Avant votre premier livrable, assurez-vous d’avoir identifié :
- les décideurs et principaux influenceurs ;
- les détenteurs de l’expertise métier ;
- les utilisateurs et populations impactées ;
- les éventuelles zones de tension ou intérêts divergents.
Une stakeholder map peut être utile. Mais elle ne doit jamais vous faire oublier une chose : le projet réel ne tient pas toujours dans l’organigramme.
Comprendre comment les décisions sont réellement prises
Vous pouvez avoir identifié toutes les bonnes parties prenantes et pourtant découvrir, au premier désaccord, que personne ne sait vraiment qui décide de quoi.
C’est pourquoi je cherche très tôt à comprendre la gouvernance réelle du projet : qui valide, qui arbitre, quelles sont les instances de décision, quel est le niveau d’autonomie de l’équipe et comment sont gérés les changements.
Une question toute simple permet souvent d’en apprendre beaucoup :
« Si demain deux parties prenantes importantes ne sont pas d’accord, qui tranche ? »
La réponse est parfois très différente de ce que laisse penser l’organisation officielle.
Un projet peut par exemple se dire Agile tout en ayant besoin d’un comité mensuel pour valider certaines décisions. Un Product Owner peut théoriquement prioriser le backlog mais disposer, dans les faits, d’une marge de manœuvre limitée. Le BA doit comprendre le fonctionnement réel du projet, pas seulement sa méthodologie affichée.
Je cherche donc à clarifier :
- qui décide, valide et arbitre ;
- quelles instances rythment le projet ;
- comment sont gérés les désaccords et demandes de changement ;
- quelles contraintes de délai, budget ou méthodologie s’imposent à l’équipe.
À vérifier
Avant votre premier livrable, vous devriez savoir :
- qui valide votre travail et les décisions métier ;
- qui arbitre en cas de désaccord ;
- quelles instances et règles de gouvernance vous concernent ;
- quelle autonomie possède réellement l’équipe.
Connaître l’organigramme vous indique qui est responsable. Comprendre la gouvernance vous apprend comment le projet décide réellement.
Cadrer votre propre mission de Business Analyst
C’est une dimension que l’on oublie facilement : avoir compris le projet ne signifie pas encore avoir cadré votre propre mission.
J’ai connu des contextes où le rôle du BA était parfaitement défini, avec des responsabilités, des livrables et des circuits de validation clairs. Et d’autres où il fallait justement commencer par comprendre ce que l’organisation mettait derrière le mot « Business Analyst ».
Car selon les entreprises et les projets, on peut attendre de vous de l’élicitation, des exigences, de la conception fonctionnelle, de la modélisation, de la recette, du support au Product Owner… parfois tout cela à la fois.
Les référentiels de l’International Institute of Business Analysis (IIBA) permettent également d’approfondir les différentes dimensions de la pratique de la Business Analyse.
Il faut donc clarifier rapidement :
- pourquoi vous avez été intégré au projet et à quel stade vous arrivez ;
- ce qui a déjà été produit et ce qui reste à faire ;
- vos responsabilités et leurs frontières avec celles des autres rôles ;
- les livrables attendus et leur niveau de formalisme ;
- votre autonomie, vos interlocuteurs et vos accès ;
- qui validera votre travail et selon quels critères.
Cette clarification est particulièrement importante lorsque plusieurs rôles se chevauchent : BA, PO, chef de projet, QA, consultant fonctionnel, architecte…
À vérifier
Avant votre premier livrable, vous devriez pouvoir répondre à ces questions :
- Qu’attend-on concrètement de moi sur ce projet ?
- Où commence et où s’arrête ma responsabilité ?
- Avec qui dois-je travailler et à quelles informations ai-je accès ?
- Qui valide mon travail et selon quelles règles ?
Le cadrage du projet et le cadrage de la mission du BA sont deux choses différentes.
Et lorsque la seconde reste floue, mieux vaut le découvrir au début de la mission qu’au moment de livrer.
Pour aller plus loin
J’ai également consacré une vidéo à ce sujet sur ma chaîne YouTube, sous une forme un peu différente : le test des 30 minutes.
Le principe est simple : vous arrivez sur une nouvelle mission de Business Analyst et le chef de projet vous accorde 30 minutes. Qu’allez-vous chercher à comprendre avant de commencer ?
C’est un bon complément à cette checklist, notamment si vous voulez tester vos propres réflexes plutôt que simplement parcourir une liste de questions.
Vous souhaitez aller plus loin dans la structuration de votre pratique ? Découvrez également les parcours BA Ready™ et BA Elevate™ et leurs différences.
Et si vous souhaitez continuer à structurer votre pratique de la Business Analyse, vous pouvez également vous inscrire à la newsletter Best Of Business Analyst.
J’y partage régulièrement mes retours d’expérience, mes analyses du métier, des ressources pratiques et mes prochains contenus et événements autour de la Business Analyse.
