Lorsque l’on lit certaines offres d’emploi de Business Analyst aujourd’hui, on pourrait croire que ce métier consiste avant tout à maîtriser une longue liste d’outils : SQL, Power BI, Jira, Python, Tableau, SAP ou encore divers outils de modélisation. Les annonces empilent les technologies, comme si la valeur d’un analyste reposait essentiellement sur sa capacité à manipuler des logiciels.
Cette vision est pourtant profondément réductrice — et surtout, elle passe à côté de l’essence même du métier.
Dans les grands cabinets de conseil stratégique comme McKinsey & Company, Boston Consulting Group ou Bain & Company, la logique est exactement inverse. Avant de parler de solutions, d’outils ou même de technologies, les consultants commencent toujours par structurer le problème.
Comprendre la situation. Clarifier les objectifs. Décomposer les causes possibles. Formuler des hypothèses.
Autrement dit : transformer un problème imprécis en question structurée.
C’est précisément cette approche qui devrait guider le travail d’un Business Analyst.
Introduction
Dans de nombreux projets de transformation, un constat revient systématiquement : le problème n’est pas technique.
Les organisations pensent manquer d’outils. Elles imaginent qu’une nouvelle solution, un nouvel ERP ou un nouveau dashboard suffira à résoudre leurs difficultés.
Mais lorsqu’on analyse réellement ces situations, on découvre autre chose :
- des objectifs mal défini
- des processus mal compris
- des besoins mal formulés
- des responsabilités mal définies
Autrement dit, le problème n’est pas l’outil.
Le problème est la manière dont le problème a été posé.
C’est précisément pour cette raison que les cabinets de conseil stratégique ont développé des méthodes rigoureuses pour structurer l’analyse : issue trees, principe MECE, raisonnement par hypothèses.
Ces méthodes ne servent pas à produire des livrables, elles servent à comprendre.
Et c’est exactement ce que doit faire un Business Analyst.
1. Comment travaillent réellement les cabinets de conseil stratégique
Le travail des consultants ne repose pas d’abord sur des outils.
Il repose sur une discipline intellectuelle : structurer un problème.
Le point de départ n’est jamais une solution. C’est une question.
1.1 Structurer avant de résoudre
Dans le conseil stratégique, une règle implicite guide tout le travail :
On ne cherche pas une solution tant que le problème n’est pas correctement structuré.
Une entreprise dit : “la rentabilité baisse”.
Le consultant ne propose pas une solution. Il découpe.
Rentabilité = Revenus – Coûts
Revenus = Volume × Prix
Coûts = Production + Logistique + Structure
Le problème devient analysable.
1.2 Le principe MECE
Le principe MECE (Mutually Exclusive, Collectively Exhaustive) impose une structuration rigoureuse.
Chaque catégorie :
- ne se chevauche pas
- couvre l’ensemble du problème
C’est une discipline de pensée.
1.3 Une logique de raisonnement, pas d’outils
Les cabinets ne recrutent pas des experts logiciels.
Ils recrutent des profils capables de :
- structurer
- analyser
- poser des hypothèses
Les outils viennent ensuite.
2. Les méthodes d’analyse popularisées par McKinsey
Les méthodes utilisées dans les cabinets de conseil stratégique ne sont pas des outils techniques. Elles constituent avant tout des cadres de raisonnement permettant d’analyser une situation complexe de manière structurée.
Contrairement à une idée répandue, ces approches ne visent pas à produire rapidement des livrables, mais à orienter l’analyse dès les premières étapes du raisonnement. Elles permettent d’éviter une erreur fréquente dans les projets : se précipiter vers des solutions sans avoir correctement compris le problème.
2.1 L’Issue Tree
L’issue tree, ou arbre de problèmes, est une méthode qui consiste à décomposer une question complexe en sous-questions plus simples et analysables.
Concrètement, cela permet de transformer une problématique générale — souvent imprécise — en une structure logique qui guide l’analyse.
Par exemple, lorsqu’une entreprise constate une baisse de rentabilité, il est inutile de chercher immédiatement des solutions. Il est nécessaire de comprendre ce qui se passe réellement.
Le problème peut alors être structuré en deux grandes dimensions : les revenus et les coûts. Chacune de ces dimensions peut ensuite être analysée plus finement.
Cette structuration permet de :
- clarifier le raisonnement
- éviter les analyses dispersées
- organiser le travail d’investigation
Sans cette étape, l’analyse reste désorganisée et peu exploitable.
2.2 L’approche hypothesis-driven
Une fois le problème structuré, les consultants ne cherchent pas à explorer toutes les pistes possibles de manière exhaustive. Ils adoptent une approche guidée par des hypothèses.
Cela signifie qu’ils formulent, dès le départ, des hypothèses plausibles sur l’origine du problème, puis cherchent à les valider ou les invalider à partir de données.
Cette approche présente plusieurs avantages :
Elle permet d’abord de gagner du temps, en évitant d’analyser des pistes peu pertinentes. Elle permet également de donner une direction claire à l’analyse et d’éviter de collecter des informations sans objectif précis.
Enfin, elle impose une discipline intellectuelle importante : chaque hypothèse doit être testée, et aucune conclusion ne doit être tirée sans confrontation avec des faits.
2.3 Le principe 80/20
Le principe de Pareto repose sur une idée simple : dans de nombreux systèmes, une minorité de causes explique la majorité des effets.
Dans le cadre d’une analyse, cela signifie qu’il n’est pas nécessaire d’examiner tous les éléments avec le même niveau de détail. L’enjeu consiste plutôt à identifier les facteurs réellement déterminants.
Dans la pratique, cette approche permet de :
- prioriser les analyses
- concentrer les efforts sur les leviers à fort impact
- éviter les analyses trop lourdes et peu utiles
2.4 Une logique simple mais exigeante
Ces méthodes montrent une chose essentielle : la valeur du travail analytique ne repose pas sur les outils utilisés, mais sur la manière dont le raisonnement est structuré.
Les outils interviennent ensuite, pour exploiter les données ou formaliser les résultats. Mais ils ne remplacent jamais la capacité à organiser une analyse.
Marre de produire des analyses approximatives ?
Découvrez la formation Business Analyst en SI pour structurer vos analyses et monter en compétence sur des méthodes utilisées en contexte réel.
3. Pourquoi cette logique est aussi celle du Business Analyst
Les méthodes utilisées dans les cabinets de conseil stratégique peuvent, à première vue, sembler éloignées du quotidien des projets informatiques. Pourtant, lorsqu’on les examine attentivement, elles reposent sur une logique très proche de celle qui devrait structurer le travail d’un Business Analyst.
Dans les deux cas, il ne s’agit pas simplement de produire des livrables ou d’utiliser des outils, mais de comprendre une situation complexe, d’en organiser l’analyse et d’identifier les leviers d’action pertinents.
Autrement dit, avant même de parler de solutions, le Business Analyst doit lui aussi passer par une étape essentielle : structurer le problème métier.
3.1 Le BA intervient sur des problèmes mal formulés
Dans la réalité des projets, le point de départ est rarement un besoin clairement formulé.
Les demandes exprimées par les équipes métier prennent souvent la forme de solutions : mise en place d’un outil, automatisation d’un processus, création d’un tableau de bord. Ces demandes traduisent une intention, mais elles ne décrivent pas nécessairement le problème sous-jacent.
Derrière une demande d’automatisation, on trouve parfois un processus mal conçu. Derrière une demande de reporting, un manque de clarté sur les indicateurs réellement utiles. Derrière la volonté de déployer un nouvel outil, une difficulté organisationnelle plus profonde.
Le rôle du Business Analyst consiste précisément à prendre du recul par rapport à ces formulations initiales. Il doit analyser la situation dans son ensemble, comprendre le fonctionnement actuel, identifier les points de friction et clarifier les objectifs poursuivis.
Ce travail conduit souvent à reformuler la demande initiale. Et c’est une étape déterminante.
Un besoin exprimé ne correspond pas toujours au besoin réel. Il en est souvent une traduction partielle, influencée par des habitudes ou par des solutions déjà connues.
Découvrez le rôle réel du BA et cette capacité à prendre du recul.
3.2 Le recueil du besoin est une analyse, pas une collecte
Dans de nombreuses méthodologies, le recueil des besoins est présenté comme une étape relativement linéaire : il s’agirait d’interroger les utilisateurs, de collecter leurs attentes et de les formaliser.
En pratique, cette vision est largement simplifiée.
Les besoins exprimés par les parties prenantes sont souvent incomplets, parfois contradictoires et parfois formulés à partir de solutions existantes plutôt que de problèmes réels. Le Business Analyst ne peut donc pas se contenter de collecter ces informations.
Il doit les analyser.
Cela implique de comprendre le contexte dans lequel s’inscrit le projet, d’identifier les différentes parties prenantes, d’examiner les processus existants et d’analyser les contraintes organisationnelles ou réglementaires.
Cette démarche peut mobiliser différents leviers : entretiens, ateliers, observation des pratiques opérationnelles, analyse documentaire ou encore étude de données.
L’objectif n’est pas d’accumuler de l’information, mais de construire une compréhension structurée du problème.
C’est précisément cette structuration qui permettra ensuite de définir des exigences pertinentes et exploitables.
3.3 Le BA comme consultant interne
Le parallèle avec le conseil stratégique prend ici tout son sens.
Dans de nombreux projets, le Business Analyst joue un rôle très proche de celui d’un consultant. Il intervient dans des situations où une organisation cherche à comprendre un problème, à clarifier ses enjeux et à orienter ses décisions.
Comme un consultant stratégique, il doit être capable de prendre du recul, de reformuler une situation et de structurer une analyse cohérente. Il ne s’agit pas simplement de traduire un besoin, mais de contribuer activement à sa définition.
La différence principale réside dans son positionnement.
Le consultant intervient généralement de manière externe, pour une durée limitée, avec un regard indépendant sur la situation.
Le Business Analyst, lui, est intégré au projet et à l’organisation. Il travaille au plus près des équipes métier et techniques, ce qui lui permet d’accéder à une compréhension fine des pratiques opérationnelles.
Cette proximité constitue un atout important, mais elle nécessite également une vigilance particulière. Le Business Analyst doit être capable de conserver une posture analytique, sans se limiter aux perceptions immédiates des acteurs du projet.
C’est cette capacité à conjuguer proximité opérationnelle et recul analytique qui fait la spécificité du rôle.
3.4 Les outils ne remplacent pas la réflexion
Une fois le problème compris et structuré, le Business Analyst peut mobiliser différents outils pour formaliser son analyse.
Ces outils peuvent prendre des formes variées : diagrammes de processus, modèles de données, scénarios d’usage, maquettes fonctionnelles ou encore supports de restitution.
Ils jouent un rôle essentiel dans la communication entre les parties prenantes. Ils permettent de rendre l’analyse plus lisible, de partager une compréhension commune et de faciliter les échanges entre équipes métier et techniques.
Cependant, il est important de rappeler que ces outils n’ont de valeur que s’ils reposent sur une analyse solide.
Un diagramme de processus peut être parfaitement construit d’un point de vue formel, tout en représentant un fonctionnement mal compris. De la même manière, un tableau de bord peut être techniquement abouti, sans pour autant répondre aux enjeux réels du pilotage de l’activité.
Les outils permettent de représenter une analyse. Ils ne la produisent pas.
3.5 La compétence clé : structurer un problème
Si l’on prend du recul sur l’ensemble de ces éléments, une compétence apparaît comme centrale dans le métier de Business Analyst : la capacité à structurer un problème.
Cette compétence consiste à transformer une situation complexe, parfois ambiguë, en un cadre d’analyse clair. Elle permet d’identifier les causes d’un dysfonctionnement, de clarifier les objectifs d’un projet et d’orienter les décisions.
Elle constitue également un facteur déterminant dans la réussite des projets.
Lorsque le problème est correctement structuré, les solutions peuvent être définies de manière pertinente et cohérente. À l’inverse, lorsqu’il est mal compris, même les meilleures solutions techniques peinent à produire de la valeur.
C’est pourquoi cette capacité d’analyse et de structuration constitue le véritable cœur du métier de Business Analyst.
4. Pourquoi certaines offres d’emploi passent à côté de l’essentiel
Si l’on met en regard les méthodes utilisées dans les cabinets de conseil stratégique et la manière dont certaines offres d’emploi décrivent le rôle de Business Analyst, un décalage apparaît très clairement.
Dans le conseil, la valeur d’un analyste repose avant tout sur sa capacité à structurer un problème, à organiser une analyse et à éclairer la prise de décision. Les outils ne sont mobilisés qu’en support, une fois que le raisonnement est posé.
À l’inverse, un grand nombre d’offres d’emploi semblent définir le rôle de Business Analyst principalement à travers une liste de compétences techniques : SQL, Power BI, Python, Jira, SAP ou encore divers outils de reporting et de modélisation.
Ces compétences peuvent bien sûr être utiles dans certains contextes. Mais lorsqu’elles deviennent le cœur de la description du poste, cela traduit souvent une incompréhension plus profonde de ce que recouvre réellement le métier.
4.1 Une confusion des rôles
Dans de nombreuses organisations, le terme “Business Analyst” est utilisé pour désigner des rôles qui relèvent en réalité d’autres métiers.
Certaines offres décrivent des missions proches de celles d’un Data Analyst, dont l’objectif principal est d’exploiter des données pour produire des indicateurs. D’autres correspondent davantage à des fonctions de BI Analyst, centrées sur la conception de tableaux de bord, ou encore à des rôles d’expert fonctionnel spécialisés sur un outil particulier comme un ERP.
Ces rôles sont indispensables dans les projets, mais ils n’ont pas le même objectif.
Le Business Analyst intervient généralement en amont, lorsque le problème métier n’est pas encore clarifié. Il ne s’agit pas encore de produire des indicateurs ou de configurer un outil, mais de comprendre ce qui doit être résolu.
Cette confusion des rôles conduit souvent à des attentes incohérentes : on attend du Business Analyst qu’il soit à la fois analyste métier, expert data, spécialiste outil et parfois même chef de projet. Dans ces conditions, la dimension analytique du rôle tend à être diluée.
4.2 La dérive “outils d’abord”
Cette confusion se traduit également dans la manière dont certains projets sont abordés.
Lorsqu’un besoin apparaît, la réponse est souvent formulée immédiatement en termes de solution : mise en place d’un outil, automatisation d’un processus, création d’un tableau de bord. Le raisonnement part de la solution plutôt que du problème.
Or cette logique inverse la démarche analytique.
Un outil d’analyse de données, par exemple, permet de manipuler des informations et de produire des visualisations. Mais il ne permet pas de définir les bonnes questions. De la même manière, un outil de modélisation peut représenter un processus, mais il ne permet pas de comprendre les enjeux organisationnels qui sous-tendent ce processus.
Dans la pratique, cette approche conduit fréquemment à des situations où les équipes investissent dans des solutions techniques sans avoir clarifié le besoin initial. Les projets avancent, les livrables sont produits, mais la valeur créée reste limitée, voire inexistante.
Ce phénomène n’est pas lié à un manque de compétences techniques. Il est lié à une insuffisance dans la phase d’analyse.
4.3 Une sous-estimation des compétences analytiques
En mettant l’accent sur les outils, certaines offres d’emploi tendent à sous-estimer les compétences qui sont pourtant les plus déterminantes dans le métier de Business Analyst.
Analyser un contexte organisationnel, comprendre des processus, identifier les parties prenantes, clarifier des besoins parfois contradictoires, structurer un problème en axes d’analyse cohérents : ces activités constituent le cœur du rôle.
Elles demandent du recul, de la méthode et une capacité à organiser l’information. Elles ne peuvent pas être remplacées par un outil.
À l’inverse, la maîtrise d’un logiciel ou d’un langage technique peut s’acquérir relativement rapidement lorsque le besoin se présente. Elle ne constitue pas, en soi, un facteur différenciant durable.
C’est pourquoi les organisations qui souhaitent réellement améliorer la qualité de leurs projets gagneraient à valoriser davantage ces compétences analytiques, plutôt que de se concentrer exclusivement sur des critères techniques.
4.4 Le risque pour les projets
Lorsque la dimension analytique est insuffisamment prise en compte, les conséquences se manifestent rapidement dans les projets.
Les besoins sont mal définis, ce qui entraîne des incompréhensions entre les équipes métier et les équipes techniques. Les solutions mises en place ne répondent que partiellement aux enjeux initiaux. Des ajustements sont nécessaires en cours de projet, générant des retards et des coûts supplémentaires.
Dans certains cas, les équipes peuvent avoir le sentiment que “tout a été fait correctement” du point de vue technique, tout en constatant que le résultat ne correspond pas aux attentes. Ce décalage est souvent le symptôme d’un problème initial mal structuré.
Autrement dit, les difficultés ne proviennent pas de l’exécution, mais de la manière dont le problème a été formulé.
4.5 Revenir à l’essence du métier
Revenir à l’essence du métier ne signifie pas ignorer les outils. Ceux-ci restent indispensables dans de nombreux projets et font partie du quotidien des équipes.
Mais il est essentiel de remettre ces outils à leur juste place.
Ils interviennent après la phase d’analyse, pour formaliser, représenter et partager les résultats. Ils ne constituent pas le point de départ du raisonnement.
Le rôle du Business Analyst consiste avant tout à comprendre une situation, à structurer un problème et à organiser une analyse permettant d’orienter les décisions.
C’est cette capacité qui rapproche le Business Analyst du consultant stratégique, bien plus que la maîtrise d’un outil particulier.
Et c’est également cette capacité qui conditionne la valeur qu’il est en mesure d’apporter dans un projet.
Conclusion
Les cabinets de conseil stratégique nous rappellent une chose essentielle : la valeur d’un analyste ne réside pas dans les outils qu’il utilise.
Elle réside dans sa capacité à structurer un problème.
Le Business Analyst fonctionne exactement de la même manière.
Dans un monde où les outils évoluent en permanence, cette compétence reste la seule constante.
Et c’est elle qui fait toute la différence.
