Business Analyst, Chef de projet, PO, PM : pourquoi on confond tout
Il existe une confusion que je rencontre de manière récurrente lorsque j’échange avec des professionnels du projet, du produit ou de l’IT.
Elle apparaît en formation, lors d’entretiens, dans des échanges informels, et même dans des fiches de poste pourtant rédigées par des organisations structurées.
On confond tout.
Business Analyst, Chef de projet, Product Owner, Product Manager.
Comme si ces rôles étaient interchangeables.
Comme si seule l’appellation variait selon les entreprises, sans conséquence réelle sur les responsabilités.
Cette confusion n’est pas uniquement sémantique.
Elle a des impacts très concrets sur la réussite des projets, sur la charge des équipes, et sur la perception même de certains métiers, en particulier celui de Business Analyst.
Une confusion construite historiquement
Pendant longtemps, l’analyse des besoins n’a pas été identifiée comme une discipline autonome.
Dans de nombreuses organisations, elle était répartie entre le métier, l’IT et le Chef de projet.
Le métier exprimait ce qu’il pensait vouloir.
L’IT traduisait comme il pouvait.
Le Chef de projet tentait d’orchestrer l’ensemble, souvent sous contrainte de délais et de budget.
Dans ce schéma, personne n’était réellement responsable de la compréhension globale du besoin.
Cette réalité est documentée de manière très claire dans un article de BA Times consacré aux impacts négatifs d’exigences mal définies. L’article montre que les exigences incomplètes ou ambiguës constituent l’une des premières causes de dérive projet, bien avant les problèmes techniques.
Lorsque les besoins sont mal cadrés, les équipes construisent des solutions techniquement correctes, mais fonctionnellement inadaptées. Le coût apparaît plus tard, sous forme de rework, de retards et de tensions entre parties prenantes.
Le coût réel d’un besoin mal compris
Les conséquences de cette confusion sont mesurables.
Une analyse publiée par ProjectManager.com sur les causes d’échec projet montre que les projets échouent rarement à cause de la technologie elle-même. Les causes principales sont liées à des objectifs flous, des exigences mal définies et une absence de vision partagée du problème à résoudre.
Sur le terrain, ces causes se traduisent par des symptômes bien connus :
- des ateliers où chacun parle d’un sujet différent sans s’en rendre compte,
- des user stories qui décrivent une solution en omettant de mettre le besoin utilisateur au centre de la réflexion
- des décisions prises pour « avancer », puis remises en cause quelques semaines plus tard,
- une perte progressive de confiance entre le métier et les équipes de réalisation.
Dans ces contextes, la confusion entre Business Analyst, Product Owner et Chef de projet devient un facteur aggravant. Les responsabilités sont mal positionnées, et les équipes compensent en aval ce qui n’a pas été clarifié en amont.
L’agilité n’a pas supprimé la confusion, elle l’a déplacée
L’agilité a profondément transformé les modes de fonctionnement, mais elle n’a pas supprimé le besoin d’analyse. Elle a surtout déplacé les malentendus.
Le cas le plus fréquent concerne la confusion entre Product Owner et Business Analyst.
Dans les cadres agiles de référence, le Product Owner est responsable de la valeur produit, des arbitrages et de la priorisation. Il décide de ce qui doit être construit et dans quel ordre. En revanche, il n’est pas défini comme un analyste métier chargé de l’analyse détaillée de besoins complexes.
Cette distinction est explicitement rappelée par Mike Cohn dans sa description du rôle de Product Owner.
Dans la pratique, pourtant, le Product Owner se retrouve souvent à porter seul l’analyse, faute de rôle clairement identifié pour le faire. Cela conduit à une surcharge du rôle et à une analyse parfois implicite, dissoute dans des tickets, des échanges rapides et des décisions prises sans cadre clair.
Ce que l’on demande à tort au Chef de projet
Le Chef de projet joue un rôle essentiel dans la réussite des projets.
Il sécurise le cadre, les délais, les ressources et la coordination.
Mais lorsqu’on lui confie la responsabilité d’analyse, un conflit de logique apparaît.
L’exécution pousse naturellement à faire entrer le besoin dans un planning et un budget.
L’analyse, au contraire, nécessite de questionner le besoin, d’explorer les zones d’incertitude et d’accepter un inconfort temporaire pour éviter des erreurs coûteuses plus tard.
Lorsque le Chef de projet est amené à cadrer à la place d’un Business Analyst, les arbitrages sont souvent biaisés, même de bonne foi, en faveur de l’exécution plutôt que de la compréhension.
Ce que l’on demande à tort au Product Owner
Le Product Owner est un rôle de décision.
Il priorise, arbitre et porte la valeur produit.
Sans analyse structurée en amont, il se retrouve à arbitrer sur des bases fragiles. Il priorise des demandes mal qualifiées, parfois contradictoires, avec une visibilité partielle sur les impacts métiers et organisationnels.
Ce n’est pas un problème de compétence individuelle.
C’est un problème de clarté sur la responsabilité d’analyse.
Le rôle réel du Business Analyst
Le Business Analyst est responsable de la compréhension.
Il travaille sur :
- les enjeux métiers,
- les besoins réels, au-delà de ce qui est exprimé,
- les impacts organisationnels,
- les règles de gestion,
- les zones d’ambiguïté et d’incertitude.
Son rôle n’est pas de produire des documents pour produire des documents.
Son rôle est de réduire l’incertitude avant la décision.
Cette approche est détaillée dans le livre blanc Introduction à la Business Analyse, qui clarifie la mission du Business Analyst et ses interactions avec les autres rôles projet.
Des rôles complémentaires, pas interchangeables
Un projet équilibré repose sur une répartition claire des responsabilités.
Le Business Analyst sécurise la compréhension.
Le Product Owner maximise la valeur et arbitre.
Le Chef de projet sécurise l’exécution.
Le Product Manager porte la vision produit à moyen et long terme.
Ces rôles se complètent, mais ne se remplacent pas.
Lorsqu’ils sont clairement définis, les projets gagnent en fluidité, en cohérence et en efficacité.
Le vrai problème derrière la confusion des rôles
La question n’est pas de savoir quel intitulé est le plus pertinent.
La vraie question est la suivante :
qui est responsable de comprendre le besoin avant de construire la solution ?
Tant que cette responsabilité restera floue, les mêmes erreurs se répéteront, quels que soient les outils, les méthodes ou les frameworks utilisés.
Pourquoi cette confusion alimente les doutes en reconversion BA
De nombreux professionnels doutent de leur légitimité lorsqu’ils envisagent une reconversion vers la Business Analyse.
Ce doute provient rarement d’un manque de compétence réelle. Il est le plus souvent lié à une mauvaise compréhension du rôle. La Business Analyse valorise avant tout la compréhension du terrain, des usages et des contraintes, bien plus que la maîtrise de frameworks.
Pour aider à y voir plus clair, j’ai conçu un quiz rapide qui permet d’évaluer, en première analyse, dans quelle mesure votre parcours et vos compétences sont compatibles avec le rôle de Business Analyst.
Accéder au quiz : Avez-vous le profil pour devenir Business Analyst ?
Pour aller plus loin
Clarifier les rôles n’est pas un luxe organisationnel.
C’est un levier de performance.
Pour poser des bases solides sur le rôle du Business Analyst, le livre blanc Introduction à la Business Analyse constitue un point de départ structurant.
Note de fin
Des organismes institutionnels comme l’IIBA publient également des cadres de référence sur la Business Analyse. Ils peuvent constituer des sources complémentaires, mais n’ont volontairement pas été développés ici afin de rester centrée sur une approche terrain, pragmatique et orientée pratique.
