Si tu tapes « Business Analyst » sur Google, tu tombes rapidement sur des définitions pleines de jargon. Le BA serait le lien entre le métier et la technique, celui qui rédige les spécifications fonctionnelles ou qui fait le pont entre les équipes.
Tout ça est vrai, mais ça ne raconte qu’une partie de l’histoire.
Un Business Analyst, c’est avant tout une personne qui cherche à comprendre les problèmes rencontrés par une organisation et à contribuer à trouver les bonnes solutions.
Concrètement, il travaille avec les équipes métier, comme la comptabilité, les RH, les ventes ou les opérations, mais aussi avec les équipes techniques, comme les développeurs et les intégrateurs.
Il se situe souvent entre ces différents univers. Il doit comprendre les contraintes de chacun, poser les bonnes questions, analyser les besoins et aider les équipes à avancer dans la même direction.
Mais son rôle ne consiste pas simplement à traduire les demandes d’un côté vers l’autre. Il doit aussi questionner les hypothèses, explorer différentes pistes et contribuer à vérifier que la solution envisagée répond bien au problème de départ, en collaboration avec les autres parties prenantes.
Et c’est là que le métier devient intéressant.
Le vrai travail commence avant la solution
Un projet peut rencontrer de sérieuses difficultés lorsque le besoin n’a pas été suffisamment compris, questionné ou validé en amont.
Imagine qu’une équipe te demande de créer un tableau de bord, d’automatiser l’envoi d’un e-mail ou d’ajouter un champ dans un formulaire.
La première réaction pourrait être de réfléchir directement à la manière de réaliser la demande.
Mais est-ce vraiment la bonne approche ?
Ces demandes décrivent souvent une solution envisagée. Elles ne disent pas toujours quel problème doit être résolu.
C’est justement là que le Business Analyst intervient.
Pourquoi ce tableau de bord est-il nécessaire ? Quelle décision doit-il permettre de prendre ? Qui va l’utiliser ? À quelle fréquence ? Quel problème rencontre-t-on aujourd’hui ?
En creusant un peu, on peut découvrir que le tableau de bord ne répond pas au véritable besoin, qu’une information existe déjà ailleurs ou qu’un problème de processus explique la situation.
Le BA cherche à comprendre ce qui se cache derrière la demande initiale. Il peut alors contribuer à identifier une solution différente, parfois plus simple, plus adaptée ou moins coûteuse.
C’est un peu comme chez le médecin. On ne prescrit pas un traitement sans chercher à comprendre les symptômes et leur origine.
Dans un projet, cette phase d’analyse permet de prendre du recul avant de se lancer dans la réalisation.
Trouver la bonne solution, pas seulement celle qu’on demande
Le travail du BA ne s’arrête pas à la compréhension du besoin.
Il participe aussi à la réflexion sur les solutions possibles.
Cela peut passer par la cartographie d’un processus existant, l’exploration d’un outil déjà disponible sur le marché, la comparaison entre un développement spécifique et une solution existante, ou encore l’évaluation des bénéfices attendus par rapport aux coûts et aux contraintes.
Il faut parfois remettre en question certaines habitudes, confronter plusieurs hypothèses ou accepter que la première idée ne soit pas la meilleure.
Pour faire ce travail correctement, il faut comprendre le contexte métier, les contraintes techniques et les objectifs de l’organisation.
Le BA n’est pas là pour valider automatiquement chaque demande. Il contribue à s’assurer que l’on traite le bon problème, dans le bon contexte, avec une solution pertinente.
Cette combinaison de compétences métier, analytiques et relationnelles est, dans mon expérience, ce qui rend le profil intéressant et parfois difficile à trouver.
Les idées reçues sur le métier
« Le BA, c’est celui qui écrit les spécifications »
Les spécifications fonctionnelles font partie du travail, mais elles ne représentent qu’un moyen de formaliser ce qui a été compris et décidé.
Avant d’écrire, il faut échanger, observer, analyser, questionner et parfois explorer plusieurs possibilités.
Une spécification bien rédigée ne garantit pas que le besoin de départ soit pertinent. On peut très bien documenter parfaitement une mauvaise idée.
L’enjeu est donc de comprendre avant de formaliser.
« Le BA, c’est un chef de projet qui ne gère pas le planning »
Les deux rôles sont complémentaires, même si leurs responsabilités peuvent se chevaucher selon les organisations.
Le chef de projet se concentre généralement sur la coordination, le planning, le budget, les risques et les ressources. Le Business Analyst se concentre davantage sur la compréhension du besoin, l’analyse des processus et la définition de la solution attendue.
Dans la réalité, les frontières ne sont pas toujours aussi nettes. Certaines entreprises confient plusieurs responsabilités à une même personne, tandis que d’autres disposent d’équipes et de rôles bien distincts.
Le problème n’est donc pas qu’un rôle soit plus important que l’autre. C’est surtout qu’un projet peut avancer conformément au planning sans que personne ait réellement pris le temps de vérifier si l’on répond au bon besoin.
« Le BA passe ses journées sur Excel »
Personnellement, Excel représente environ 1 à 2 % de mon temps de travail, et je l’utilise surtout lorsque certaines contraintes m’y obligent.
C’est mon expérience, pas une règle valable pour tous les Business Analysts.
Excel peut d’ailleurs être très utile pour analyser des données, comparer des scénarios ou tester des hypothèses. Le problème n’est pas d’utiliser un tableur, mais de réduire le métier à cet outil.
Le cœur du travail se situe plutôt dans les échanges, la facilitation, l’analyse des processus et la compréhension des besoins.
Un BA peut passer du temps dans Excel sans que cela pose problème. En revanche, produire des tableaux sans comprendre le problème métier auquel ils doivent répondre risque de passer à côté de l’essentiel.
« Le BA est juste un tremplin vers le product management ou la gestion de projet »
Le métier peut effectivement ouvrir des portes vers d’autres fonctions. Mais il peut aussi constituer une spécialité à part entière.
Comprendre les besoins, analyser des situations complexes, faciliter les échanges entre des interlocuteurs différents et relier les enjeux métier aux contraintes techniques demande une véritable expertise.
Ce n’est pas simplement une étape à franchir avant de faire autre chose. Pour ceux qui aiment comprendre les problèmes, explorer les possibilités et contribuer à construire des solutions pertinentes, le métier peut être une voie professionnelle à part entière.
À quoi ressemble une journée de BA ?
Il n’existe pas vraiment de journée type.
On peut commencer par un atelier avec une équipe métier, poursuivre avec l’analyse d’un processus, explorer un outil susceptible de répondre à un besoin, puis terminer par la préparation de spécifications ou la clarification de certains points avec les développeurs.
Certaines journées sont très orientées vers les échanges. D’autres demandent davantage de recherche, de réflexion ou de documentation.
C’est cette dimension exploratoire que je trouve particulièrement intéressante dans le métier.
Il ne s’agit pas seulement d’exécuter une demande, mais de comprendre ce qui se passe, d’identifier les possibilités et de déterminer ce qui pourrait fonctionner dans un contexte donné.
Cela peut signifier découvrir un nouvel outil, tester plusieurs scénarios, consulter de la documentation, parcourir des forums ou lire des retours d’expérience pour comprendre les limites d’une solution.
Le BA doit parfois jouer les détectives.
Et le travail ne suit pas toujours une ligne droite. Une démonstration peut faire émerger de nouvelles questions. Un atelier peut révéler que le besoin est plus complexe que prévu. L’exploration d’un outil peut montrer qu’une fonctionnalité existe déjà et qu’un développement n’est finalement pas nécessaire.
Il faut alors revenir sur certaines hypothèses, ajuster l’analyse et parfois revoir les spécifications.
C’est stimulant, mais cela peut aussi être fatigant. On passe régulièrement d’un sujet à un autre, avec des interlocuteurs, des contraintes et des niveaux de détail très différents.
Une chose est sûre : quand on aime comprendre comment les choses fonctionnent, le métier est rarement ennuyeux.
Pourquoi le rôle du BA est-il stratégique ?
Un projet informatique peut aboutir techniquement tout en passant à côté de son objectif.
Les développeurs peuvent avoir construit exactement ce qui leur avait été demandé, dans les délais et conformément aux spécifications. Pourtant, si la demande initiale ne répondait pas au véritable besoin, le résultat risque de décevoir.
Ce n’est pas nécessairement un problème technique. Il peut s’agir d’un problème d’analyse, de compréhension ou de décision.
Le Business Analyst contribue à réduire ce risque en clarifiant les objectifs, en questionnant les hypothèses et en aidant les parties prenantes à prendre des décisions mieux informées.
Bien sûr, il ne peut pas garantir à lui seul la réussite d’un projet. Celle-ci dépend aussi des décisions prises, de la collaboration entre les équipes, des moyens disponibles et de nombreux autres facteurs.
Mais une analyse solide peut éviter de consacrer du temps et des ressources à une solution mal adaptée.
À mesure que les organisations adoptent de nouveaux outils numériques et automatisent leurs activités, cette capacité à comprendre les problèmes et à relier les besoins aux solutions reste essentielle.
Et avec l’IA, que devient le métier ?
L’intelligence artificielle peut déjà accélérer certaines tâches du Business Analyst : synthétiser des documents, structurer des informations, préparer une première version de spécifications ou explorer des pistes de solution.
Mais produire rapidement un document convaincant ne signifie pas que le besoin a été correctement compris.
Imaginons qu’une équipe demande à une IA de rédiger les spécifications d’un nouvel outil. Le résultat peut être clair, structuré et parfaitement présentable. Pourtant, si personne n’a questionné la demande initiale, l’IA risque simplement de formaliser plus rapidement une solution inadaptée.
Le rôle du BA ne consiste donc pas uniquement à produire des livrables. Il s’agit aussi de comprendre le contexte, de challenger les hypothèses, de faciliter les décisions et de vérifier que les propositions ont du sens dans la réalité de l’organisation.
L’IA peut devenir un véritable levier pour gagner du temps et explorer davantage de possibilités. Encore faut-il savoir quand l’utiliser, pourquoi et comment évaluer ce qu’elle produit.
C’est précisément l’un des sujets que je souhaite explorer davantage : comment intégrer concrètement ces outils dans le quotidien du Business Analyst, sans perdre de vue la qualité de l’analyse et la pertinence des solutions.
Pour aller plus loin
Le métier de Business Analyst est bien plus large que la rédaction de spécifications. Il demande de la curiosité, de la rigueur, une bonne capacité d’analyse et une vraie compréhension des enjeux métier et techniques.
Dans les prochains articles, je reviendrai notamment sur les différences entre le métier de BA en startup et en grande entreprise, sur l’impact de l’IA et sur les outils qui peuvent faciliter notre quotidien.
Abonne toi à la newsletter pour recevoir régulièrement des analyses, des outils concrets et des prompts directement utilisables dans ton quotidien.