Quand j’échange avec des Business Analysts, une phrase revient très souvent.
Parfois formulée avec un sourire un peu gêné, parfois avec une vraie inquiétude :
« Je ne comprends pas comment l’entreprise est organisée… et je ne sais pas vraiment à qui m’adresser. »
Cette difficulté est rarement liée à un manque de compétences techniques ou méthodologiques. Elle provient presque toujours d’un décalage entre la représentation théorique de l’organisation et sa réalité opérationnelle.
Beaucoup de Business Analysts arrivent en mission avec une vision rationnelle des entreprises : des départements bien définis, des rôles clairs, des circuits de décision identifiables. Puis, très vite, ils découvrent une réalité beaucoup plus floue, mouvante, parfois déroutante.
Avec le recul de mes années comme Business Analyst senior, et à travers les nombreux retours reçus en formation et en accompagnement, j’ai compris que ne pas savoir lire une organisation est l’une des premières causes de maladresse — et parfois d’échec — chez les BA.
Cet article ne cherche pas à décrire des modèles idéaux, mais à proposer une grille de lecture pragmatique pour se repérer dans ce que j’appelle souvent la jungle organisationnelle.
L’organigramme : une carte officielle, rarement le territoire
L’organigramme est souvent le premier document transmis au Business Analyst. Il rassure. Il donne l’impression que l’entreprise est lisible, structurée, presque logique.
Mais très vite, ses limites apparaissent.
L’organigramme indique les liens hiérarchiques formels, mais il ne montre presque jamais qui décide réellement, qui influence, qui peut bloquer un sujet, ni où se situent les expertises clés. Il ne dit rien non plus des relations informelles, des alliances, des tensions historiques ou des zones de pouvoir implicites.
Pour un Business Analyst, prendre l’organigramme pour une vérité opérationnelle est une erreur fréquente. Compréhensible, mais risquée, notamment lorsqu’il s’agit d’identifier les bons contributeurs métiers ou de sécuriser des arbitrages.
Pourquoi « le métier » n’est jamais un bloc homogène
Parler du métier comme d’un ensemble cohérent est un raccourci très répandu. En réalité, un département métier est presque toujours traversé par des logiques différentes, parfois contradictoires.
Il réunit des managers, des opérationnels, des experts, des relais projets, chacun avec ses contraintes, ses priorités et sa propre lecture du projet. Plus un Business Analyst s’adresse au métier de manière globale, moins il comprend ce qui s’y joue réellement.
À l’inverse, plus il affine sa compréhension des rôles, des responsabilités et des tensions internes, plus il peut ajuster sa posture. Cette lecture fine permet d’éviter des situations bien connues :
« Je pensais que c’était validé », « Je croyais que tout le monde était aligné », ou encore « Je ne comprends pas pourquoi ça bloque maintenant ».
Les organisations pyramidales : claires sur le papier, complexes dans la pratique
Les organisations pyramidales restent très répandues, notamment dans les grandes entreprises, les banques, les assurances, l’industrie ou le secteur public. Les responsabilités y sont formellement définies, les circuits hiérarchiques visibles, les rôles relativement stables.
Mais cette clarté apparente masque souvent une réalité plus complexe : des silos forts, des objectifs locaux parfois contradictoires, et une dépendance élevée aux arbitrages hiérarchiques.
Pour un Business Analyst, le piège consiste à croire que la validation d’un manager suffit à sécuriser une décision. En pratique, un même sujet traverse souvent plusieurs départements, chacun avec son propre angle de lecture. Comprendre cette dynamique est indispensable pour éviter de renforcer les silos… dans des organisations qui en souffrent déjà.
Les organisations orientées produit ou valeur : plus agiles, mais pas toujours plus simples
À l’opposé apparent des structures pyramidales, on trouve les organisations orientées produit, service ou chaîne de valeur. Elles sont fréquentes dans la tech, les scale-ups et les entreprises en transformation agile.
Ces modèles favorisent la rapidité, la responsabilité collective et la proximité avec les utilisateurs. Mais ils peuvent aussi diluer certaines responsabilités transverses, notamment sur la donnée, la conformité ou l’architecture.
Le Business Analyst doit alors comprendre rapidement si le produit constitue un véritable centre de décision ou s’il s’agit avant tout d’une façade organisationnelle. Cette distinction conditionne profondément la manière d’impliquer les parties prenantes et de sécuriser les arbitrages.
Les organisations matricielles : quand le pouvoir devient contextuel
Dans les grands groupes, la structure matricielle est fréquente. Un collaborateur peut dépendre à la fois d’un manager fonctionnel, d’un manager projet ou produit, et parfois d’une entité pays.
Cette organisation permet de mutualiser les compétences, mais elle crée aussi une ambiguïté décisionnelle forte. Le pouvoir n’y est jamais absolu : il dépend du sujet, du contexte et du moment.
Pour le Business Analyst, cela signifie qu’il n’existe pas une seule personne légitime à solliciter, mais plusieurs autorités relatives, à identifier avec précision selon le périmètre traité.
Gouvernance top-down, bottom-up… et la réalité entre les deux
Peu d’organisations fonctionnent de manière strictement top-down ou bottom-up. Dans les faits, certaines décisions sont imposées, d’autres émergent du terrain, et beaucoup se construisent dans un entre-deux implicite, comme le montrent de nombreux travaux sur la gouvernance et la décision publique menés par des institutions comme Organisation for Economic Co-operation and Development
Chaque logique impose une posture différente au Business Analyst : sécuriser la compréhension et l’appropriation dans un contexte top-down, ou structurer et rendre arbitrables des remontées parfois foisonnantes dans un contexte bottom-up.
Organisations process-driven et data-driven : attention aux illusions
Certaines entreprises sont fortement structurées par leurs processus, notamment dans l’industrie, la logistique, la santé ou le secteur public. D’autres se revendiquent data-driven, avec une place centrale accordée aux indicateurs et aux tableaux de bord.
Dans les deux cas, le Business Analyst doit faire preuve de discernement. Une organisation process-driven attend que l’on parle en priorité de flux, de responsabilités et de conformité. Une organisation data-driven, quant à elle, n’utilise pas toujours réellement la donnée pour décider, malgré un discours souvent très affirmé, comme le soulignent de nombreux travaux académiques sur le design organisationnel, notamment à la MIT Sloan School of Management.
La question centrale reste toujours la même : où se situe la vérité opérationnelle, et qui a la légitimité pour l’interpréter ?
Les organisations politiques : une réalité omniprésente
Toute organisation est politique, au sens où elle est traversée par des intérêts, des stratégies et des rapports de force. Ignorer cette dimension, c’est s’exposer à des incompréhensions majeures.
Comprendre les enjeux, les territoires et les équilibres internes ne signifie pas manipuler, mais agir avec lucidité. Un Business Analyst qui fait comme si les décisions étaient uniquement rationnelles prend un risque important.
Cas souvent sous-estimés : croissance externe et secteur public
Les organisations issues de fusions et acquisitions cumulent souvent des systèmes, des cultures et des processus hétérogènes. L’histoire de l’entreprise devient alors une clé essentielle pour comprendre les résistances actuelles.
Le secteur public obéit, quant à lui, à des logiques très spécifiques : séparation forte entre décideur et exécutant, temporalité longue, primauté du cadre réglementaire. Les Business Analysts issus du privé y font souvent les mêmes erreurs, en cherchant à aller trop vite ou à optimiser ce qui relève avant tout de la conformité.
Le Business Analyst comme explorateur organisationnel
Le Business Analyst est un acteur transversal dans un monde encore largement structuré verticalement. Les problèmes qu’il traite traversent les départements, les systèmes et les rôles, alors que les organisations restent majoritairement organisées en silos.
Avant même de modéliser un besoin, un processus ou une donnée, il doit apprendre à lire l’organisation dans laquelle il évolue. Cette compétence n’est ni accessoire ni optionnelle. C’est un pré-requis métier.
Conclusion
Avec le temps, j’ai compris que beaucoup de difficultés rencontrées par les Business Analysts ne viennent pas de la complexité des projets, mais de celle des organisations. Les départements ne sont pas des blocs figés, mais des systèmes vivants, historiques, parfois contradictoires.
Avant de chercher à clarifier un besoin ou à structurer une solution, il est souvent nécessaire de se poser une question plus fondamentale :
dans quelle jungle suis-je en train d’entrer, et quelles en sont les règles implicites ?
C’est à partir de cette compréhension que le Business Analyst peut réellement retrouver son chemin — et aider les autres à en faire autant.
Pour ceux qui souhaitent consolider ces bases et poser un cadre clair sur le rôle et les fondamentaux du métier, une introduction structurée à la Business Analyse constitue souvent un point d’ancrage utile :
