Vous êtes Business Analyst prestataire et vous avez l’impression que chacune de vos

missions débute systématiquement par une interminable période de montée en

compétence ? Vous allez prendre vos fonctions de Business Analyst comme collaborateur
interne chez votre nouvel employeur, et vous souhaitez vous préparer au mieux face aux
difficultés qui vous attendent ? Dans cet article, je vous décris les 17 défis du Business
Analyst en début de mandat.

La Business Analyse: une discipline en soi

Plus qu’un métier, la Business Analyse est une discipline, que de nombreux professionnels
peuvent être amenés à pratiquer en partie et ponctuellement tout au long de leur carrière, parmi
leurs autres activités.

En revanche, quand on parle du métier de Business Analyst, on évoque un(e) professionnel(le)

qui intervient lorsqu’une Organisation doit implémenter une solution en réponse à un problème
ou à un désir de changement.

C’est en effet à lui ou elle que revient la responsabilité de recommander, décrire et mettre en
œuvre la meilleure solution possible en fonction de la vision stratégique, des besoins métiers
et des nombreuses contraintes internes ou externes.

Business Analyst IT et non-IT

Cette « meilleure solution possible » peut tout aussi bien être liée au système d’information de
l’organisation, que non-IT – par exemple, lors de la mise en œuvre d’une conduite du
changement, de l’amélioration de la chaîne de processus ou de la gouvernance d’entreprise.

Il arrive fréquemment que ce soit une combinaison de tout cela, conduisant à l’intervention de
plusieurs professionnels de la business analyse, chacun spécialisé dans un domaine spécifique.

Par exemple : le « consultant en réorganisation » côtoiera l’AMOA (assistant à la maîtrise

d’ouvrage) intégré au pôle métier, et côté maîtrise d’œuvre, réalisatrice de la solution
informatique, on trouvera le Business Analyst en SI en support du Product Owner au sein d’une
équipe agile, voire d’un expert en Business Intelligence, en ERP ou autres CRM.

Un métier qui demande une grande adaptabilité

Un Business Analyst n’a donc pas forcément ce « titre » sur sa fiche de poste ou sur son
bulletin de salaire, mais dans cet article, je vais me focaliser sur celles et ceux qui sont
clairement identifiés comme BA par leur employeur ou leur client final.

Pouvant intervenir comme prestataire externe porté par une ESN ou un cabinet de conseil, ou
comme collaborateur interne de l’Organisation cliente, salarié ou freelance, le Business Analyst
doit faire preuve d’une très grande adaptabilité et ouverture d’esprit, et ce, tout au long de sa
carrière.

Surfant sans arrêt de changement en changement, pour lesquels on lui demande de trouver des
solutions, il doit avoir le goût de la nouveauté, être curieux, et ne pas craindre de sortir
fréquemment de sa zone de confort.
Des défis à relever à chaque stade d’une mission

Malgré toutes ces appétences pour une vie professionnelle rythmée et pleine de surprises, les
Business Analysts peuvent se sentir submergés par le volume d’informations hétérogènes à
recueillir et à analyser, alors qu’ils ne possèdent initialement pas ou peu d’expertise métier sur
le domaine économique de l’Organisation demandeuse.

Comprendre les défis des débuts de missions ou de prise de poste est indispensable pour
optimiser une montée en compétence rapide du Business Analyst.

A mon sens, celle-ci peut se découper en plusieurs phases : les premiers jours, les premières
semaines, une période allant environ du deuxième au sixième mois, et au-delà de 6 mois.

Les défis des tous premiers jours

Un Business Analyst qui débute dans un secteur et une entreprise qu’il ne connaissait pas
auparavant fait face à de nombreux défis lors des tous premiers jours de sa prise de fonction.

Les principaux sont les suivants :

 [1] Comprendre le « métier » de l’organisation: affrêtement maritime, aéronautique,

exploitation autoroutière, bateaux de croisières de luxe, ou encore banques, télécoms,
nucléaire, publicité, … Recommander et concevoir une solution qui tient compte des
spécificités sectorielles nécessite de les appréhender finement. Au tout début,
évidemment, on ne se focalise que sur les grandes lignes. Tels des acteurs qui
apprennent leurs nouveaux rôles, il est indispensable de comprendre le contexte sectoriel
dans lequel nous allons travailler. Et ça n’est pas facile !

 [2] Savoir qui fait quoi dans l’équipe / chez le client : recueillir les besoins de manière
exhaustive, puis les vérifier, les valider (ce qu’on appelle l’élicitation) avant de pouvoir
effectuer nos analyses, recommander et concevoir la solution nécessite de très
nombreuses interactions avec les parties prenantes et les contributeurs. Comment
identifier auprès de qui nous adresser tout en nous assurant que c’est réellement la
BONNE personne .

 [3] Savoir par où commencer

Contrairement à certains rôles (comme celui de développeur informatique), un Business
Analyst ne sait pas forcément quelles sont les activités, tâches, et livrables qui lui
incombent, ni à quelle échéance ceux-ci sont attendus par les autres membres de
l’équipe ou par le client final.
Etablir sa feuille de route personnelle est donc l’un des défis majeurs à surmonter
lorsqu’on débute. Dans le meilleur des cas, un chef de projet donne les grandes
lignes. Mais beaucoup de tâches de Business Analyse sont invisibles à ses yeux, alors
qu’elles sont chronophages et indispensables à la réalisation des livrables projet. Et dans
 de nombreuses situations, notamment sur les petits projets où le BA est polyvalent et a la
charge de sa propre gouvernance, c’est à lui d’établir sa road map.
Quand on est débutant, on ne sait en général pas du tout par quoi commencer, et je peux
vous assurer que c’est un réel challenge dans les tous premiers jours (et au-delà).

 [4] Obtenir de l’information utile et compréhensible pour notre niveau de

connaissance actuel (donc, de débutant…).
En effet, aller interroger des experts qui éprouveront de la difficulté à se mettre à notre
humble niveau, et à prendre du recul avec le jargon et les acronymes qu’ils manipulent
sans même s’en rendre compte, n’est pas pertinent dans les premiers jours de prise de
poste.
Notre contributeur idéal ? Celui ou celle qui vulgarise et synthétise son métier, et qui
visualise ce qui peut nous être utile (à notre place, parce qu’à ce stade, toutes les
informations se ressemblent !) sans se perdre dans les détails.

 [5] Aller vers les autres qu’on ne connaît pas encore

Pour un Business Analyst, il est fondamental d’être connu et reconnu pour recueillir de
l’information pertinente. Si personne ne sait ce que vous faites, ni à quoi vous pouvez
(leur) servir, vous risquez de passer à côté d’informations et de réunions importantes.
Prenez donc garde à ne pas rester dans votre coin à lire de la documentation 8 heures
d’affilée pendant ces premiers jours, en attendant d’être sollicité(e). Il est normal de se
sentir intimidé(e) en début de mission, mais un bon BA doit savoir passer outre pour se
présenter aux autres collaborateurs (et peut-être futurs utilisateurs de la solution cible).

Les 5 enjeux principaux des 2 premiers mois

Passés les premiers jours de brouillard londonien, le ou la Business Analyt en sait un petit peu
plus, et il ou elle commence à être invité(e) à diverses réunions. S’il /elle est rattaché(e) à une
équipe projet (en mode « build » ou « run »), il est probable que le chef de projet ou un manager
hiérarchique lui ait transmis des éléments de planification. Il ou elle a également en ligne de
mire ses premiers livrables ou tâches à réaliser.

A ce stade où le brouillard laisse peu à peu la place à de la brume, voici les défis que
rencontrent la majorité des business analysts :

 [6] Réussir à s’organiser

Un écueil fréquent est de naviguer à vue, d’être réactif et non proactif, de percevoir
une vue d’ensemble partielle et non complète, et de-ci de-là, quelques détails saillants
(pas forcément les plus importants). Attention également à la réunionite aigue qui
commence à s’installer. Je veux dire par là que dans les premières semaines, si votre rôle
de BA est bien compris, vous pouvez être invité(e) à pleiiiin de réunions, sans savoir en
quoi celles-ci peuvent vous être utiles.

 [7] Réussir à trouver sa place dans l’équipe projet.

Cette difficulté est particulièrement vraie pour les BA qui travaillent dans un contexte
agile, et cela a un impact considérable sur le point précédent. Pour ne pas avoir la
sensation d’être le bouche-trou de l’équipe ou du Product Owner (PO), commencez par
 bien identifier les rôles et responsabilités de chacun, ainsi que la plus-value que vous
pouvez apporter au produit, au projet, et à vos collègues.
Si vous pensez que ce n’est pas à vous, Business Analyst, de mener cette réflexion, vous
n’avez pas tort… Mais si personne ne le fait (manager, CP, PO…), mieux vaut prendre
les devants le plus tôt possible.

 [8] Obtenir les noms des « bons » contributeurs, c’est-à-dire ne pas se satisfaire des
noms que votre chef de projet ou manager vous aura donnés.
A ce stade, vous avez impérativement besoin d’identifier les contributeurs qui apportent
une information pertinente à la granularité voulue, c’est-à-dire :
o Soit suffisamment synthétique qui met en lumière la photo globale,
o Soit très détaillée, par exemple pour la phase de conception fonctionnelle,
o Soit permettant de comprendre la vision stratégique,
o Soit permettant de comprendre les interactions avec d’autres systèmes (projets ou
thématiques connectées, contraintes à prendre en compte etc).

Obtenir les noms des « bons » contributeurs est un travail d’élicitation à part entière, c’est ce qui
sécurisera le recueil exhaustif, fiable, vérifié et consensuel de la matière première dont sera
issue la solution cible : l’information.

 [9] Mettre en œuvre la stratégie d’engagement des contributeurs.

En tant que Business Analyst, le prérequis est d’avoir réussi la première phase
d’appropriation du projet, de comprendre les objectifs, le périmètre, et la feuille de route.
C’est ce qui nous permet d’identifier par la suite les profils de « bons » contributeurs, et
de préparer la stratégie d’engagement de ces derniers.
En effet, même si un contributeur est sur le papier « l’expert qu’il vous faut », il ou elle
n’est pas forcément aussi mobilisé(e) que vous l’êtes sur la réussite du projet. Sans doute
a-t-il déjà un poste très accaparant, des managers opérationnels auxquels rendre des
comptes en priorité, et parfois peu de motivation personnelle pour vous livrer son
expertise métier.

Quelques semaines après votre arrivée, il s’agit donc d’un défi important, souvent négligé et
quasi-invisible alors que c’est un point fondamental pour réussir la suite de votre mission de
Business Analyst.

 [10] Commencer à produire de la valeur

Passés les premiers jours où on vous laisse en général prendre vos marques, il est important de
commencer à apporter une plus-value assez rapidement. J’ai pu constater que cette attente, pas
forcément exprimée par vos managers ou par l’équipe projet, a comme un plafond de verre
aux alentours de la fin du deuxième mois anniversaire de votre arrivée.

Selon le contexte projet, et la nature de votre intégration (collaborateur interne ou prestataire

externe), sachez qu’à cette échéance, vous devrez avoir démontré votre valeur ajoutée d’une
manière ou d’une autre. Il ne s’agit pas forcément de livrables projets officiels (analyses,
spécifications etc), mais au moins de rapport d’étonnement, d’une feuille de route interne, de
recommandations méthodologiques, d’ateliers de travail, de comptes-rendus de réunions ou
autres analyses et conseils.

En effet, c’est à peu près à cette échéance (entre 1 et 2 mois) que le client ou le manager estime
que le BA doit vraiment être capable de produire quelque chose de concret.

Une période critique : entre 2 et 6 mois

Ça y est, vous avez enfin commencé à prendre vos marques, et votre agenda s’est rempli
d’activités productives. Pour autant, bien des Business Analysts débutants et même
expérimentés font face aux défis suivants :

 [11] Le syndrome de l’imposteur

Vous êtes entouré(e) d’experts. Experts métiers, experts IT, chefs de projets etc. Avoir
l’impression que tout le monde a une expertise, sauf vous, conduit beaucoup de BA à se
sentir illégitimes pour produire recommandations et autres descriptions d’une solution
qui devra apporter de la satisfaction aux utilisateurs finaux. Au début de votre projet /
mission, ne pas vous sentir expert était acceptable, mais cela ne doit plus être le cas par
la suite, pensez-vous (à tort, voir le point suivant).

 [12] Se faire prendre pour un expert métier par l’équipe

technique et devoir leur faire comprendre qu’on ne peut pas
répondre tout de suite à toutes leurs questions.
Même après être monté(e) en compétence sur les thématiques
métiers, un BA doit a minima vérifier sa bonne compréhension, la
pertinence de sa réponse, ou encore qu’il / elle n’a pas oublié des cas
aux limites ou des exceptions. Cela passe donc souvent par de
l’élicitation (lecture de documentation, analyse d’interfaces, ateliers
collaboratifs etc).

 [13] Eviter de se faire déposséder de ses

responsabilités fonctionnelles par l’équipe technique ou le
chef de projet.

Certains CP ou développeurs préfèrent faire vite, quitte à (faire) refaire

derrière, pour des raisons de planning, de contrat ou autres. Si un BA ne
rend pas assez rapidement ses analyses ou éléments de conception
fonctionnelle – quand bien même on lui aurait fixé des objectifs
inatteignables car mal évalués – il ou elle peut se faire « by-passer ».
Il arrive que dans une équipe où le rôle et les responsabilités du Business
Analyst ne sont pas assez identifiés et reconnus, ou en raison du manque
d’expérience du chef de projet, que celui-ci ou l’équipe de développement,
trop pressés de finaliser un développement prévu ou de ne pas mettre en
retard un planning mal ficelé, prennent des décisions sans les valider
fonctionnellement avec le BA.
Si vous vous reconnaissez dans ce cas de figure, vous savez comme cela
peut être impactant pour la qualité de la solution cible, et donc pour la
satisfaction utilisateur. Et en général, le BA se retrouve dans une situation
délicate où il/elle est pris dans un conflit de loyauté entre son employeur
(s’il s’agit d’une ESN en charge de la maîtrise d’œuvre, par exemple), et le
client envers lequel il s’est engagé à concevoir une solution fonctionnelle de
qualité.
Cette difficulté est majoritairement ressentie par des Business Analysts déjà
bien « installés » dans le projet, soit au-delà de 4 à 6 mois en moyenne.

Les enjeux principaux au-delà des 6 mois

Si vous croyez que votre vie de Business Analyst va enfin être un long
fleuve tranquille une fois que vous vous sentirez à l’aise avec votre projet et
vos collègues, j’ai le regret de vous dire que d’autres défis vous attendent.

Ne vous méprenez pas : j’adore mon métier, et si vous lisez mes

publications, vous savez que je suis plutôt du type « bisounours », à
présenter des facettes passionnantes de notre belle discipline! Mais il est
vrai que parfois, on peut se décourager, ou être fatigué(e) de devoir sans
cesse nous adapter.

Voici les difficultés que beaucoup de BA m’ont rapporté vivre après environ
6 mois de projet / mission :

 [14] La gestion du temps

En tant que chaînon reliant les pôles métiers, les équipes de dév et la
gestion de projet, un BA est sollicité de toutes parts, tout le temps et par
tout le monde, dès lors qu’il y a un questionnement métier. Vous devrez
apprendre à gérer votre temps, pour faire face aux nombreuses réunions,
urgences et demandes de dernière minute, tout en gardant votre capacité à
livrer vos analyses, spécifications fonctionnelles, user stories, documents
de formation utilisateurs et autres plans de tests dans les temps impartis.

 [15] Etre proactif(ve) et pas seulement réactif face aux

urgences
Découlant directement du point précédent, la proactivité est en effet
une attitude importante quand on est Business Analyst, pour garder
de la hauteur sur la vision d’ensemble et conserver l’alignement de la
solution cible sur les objectifs stratégiques et métiers initiaux.

 [16] Réussir à se positionner comme un conseiller et non

comme un simple exécutant.
Les schémas de certification internationaux à la Business Analyse ne
sont pas tous d’accord sur la place du BA.
 Pour IIBA, schéma historique de la Business Analyse fondée à Toronto
en 2004, le BA est le conseillé avisé du chef de projet, du client et de
l’équipe [Link] revanche, le PMI, influencé par sa culture « chef
de projet », voit davantage le Business Analyst avec un lien de
subordination entre lui et le chef de projet.

Personnellement, j’adopte la vision IIBA, qui me permet de travailler

en accord avec la philosophie de l’analyse métier et de viser la
satisfaction utilisateur et client avant toutes choses.

 [17] Le syndrome de l’imposteur peut s’intensifier à ce stade.

Car même après 6 mois sur un même projet, sachez-le, un BA n’est
toujours pas expert métier parlant à la place des utilisateurs finaux. Et
il ne devrait pas l’être – quand bien même sa connaissance métier
serait conséquente -, sous peine de passer à côté de nombreux
besoins non exprimés.
En Business Analyse, la technique de l’egoless programming est en
effet une posture très utile pour recueillir les besoins latents, cachés,
et inconscients. Or beaucoup de chefs de projets, managers ou
développeurs travaillant avec des BA pensent à tort qu’au-delà d’un
certain temps de “séniorité”, ceux-ci sont censés en savoir autant que
les utilisateurs finaux. Les BA se sentent donc en décalage entre
la manière dont ils sont perçus, et le fait qu’ils ne possèdent
évidemment pas la science infuse.

Enfin, il faut savoir que l’immense majorité des Business Analysts s’est
formée sur le tas à son métier, et ne dispose donc pas des bonnes
pratiques, techniques et méthodes de la profession.
Beaucoup d’employeurs de BA pensent qu’être Business Analyst revient à
avoir des connaissances ou un diplôme en économie de gestion et en
management, ainsi que des bonnes capacités de communication, d’analyse
et de synthèse. Les Business Analysts se sentent donc parfois (souvent)
durant de longues années perçus à tort comme plus compétents qu’ils ne
pensent eux-mêmes l’être.

Et pourtant, je vous l’assure, vous qui m’avez lu(e) jusqu’au bout:

si vous êtes Business Analyst, soyez fier/fière de vous et de votre
parcours!

Fier/ère de votre capacité à comprendre et à résoudre des problèmes, à

faire le lien entre un nombre infini d’informations hétérogènes, à vous
adapter au changement, à apprendre constamment de nouvelles choses et
à concevoir dans le détail des solutions dont la plus-value n’existe encore
que sur le papier.

Soyez fier/ère d’être si autonome et créatif/ve, résilient(e) et à l’écoute

constante des besoins tant des utilisateurs et que des managers,
soucieux(se) de fournir la meilleure solution possible en dépit des nombreux
défis et contraintes qui jalonnent votre chemin.