Dans beaucoup d’organisations, le business analyst (analyste métier), le chef de projet et le product owner coexistent sans que personne ne sache exactement où commence et s’arrête la responsabilité de chacun. Le résultat est un mélange de doublons, de trous dans la couverture et de conflits larvés sur les décisions.
Le problème ne vient pas des personnes, il vient du fait que ces trois rôles partagent un territoire commun: la gestion des exigences et du périmètre.
Ce que fait réellement un business analyst
Selon le BABOK Guide, publié par l’IIBA (International Institute of Business Analysis), la business analysis est “la pratique qui permet le changement dans un contexte organisationnel, en définissant les besoins et en recommandant des solutions qui apportent de la valeur aux parties prenantes”.
Le BA identifie les besoins, analyse les options et traduit les attentes métier en spécifications exploitables. Son périmètre est le produit ou la solution, pas le projet lui-même. C’est une distinction fondamentale: le BA se demande “que faut-il construire et pourquoi?”, pas “comment livrer dans les délais et le budget?”.
En pratique, le BA mène les ateliers d’élicitation, documente les exigences, modélise les processus et valide que la solution répond au besoin initial. C’est un rôle d’interface entre le métier et l’équipe de réalisation.
Le chef de projet: le périmètre du projet, pas du produit
Le chef de projet est responsable de la livraison. Il gère les délais, le budget, les ressources et les risques. Son périmètre est le projet au sens opérationnel: il s’assure que le travail est planifié, exécuté et contrôlé.
La zone de chevauchement avec le BA se situe au niveau du scope (périmètre). Le PMI distingue le project scope et le product scope: le premier englobe l’ensemble du travail à réaliser pour livrer, le second décrit les caractéristiques de la solution. Le BA contribue à définir le product scope, le PM gère le project scope. En théorie, la frontière est nette. En pratique, quand un changement d’exigence modifie le périmètre du projet, les deux rôles doivent collaborer pour évaluer l’impact.
Un chef de projet qui recueille lui-même les exigences fait de la business analysis, qu’il le sache ou non. Le BABOK le reconnaît: la discipline n’est pas réservée à un intitulé de poste. Mais quand le PM cumule les deux fonctions sans en être conscient, il risque de négliger l’une au profit de l’autre, généralement au détriment de l’analyse.
Le product owner: une convergence naturelle avec le BA
En contexte Scrum, le product owner (PO) gère le backlog produit, priorise les fonctionnalités et représente la voix du client. Sur le papier, son rôle ressemble fortement à celui du BA. La différence se joue sur le niveau de détail et le pouvoir de décision.
Le PO a l’autorité finale sur les priorités. Le BA, quand il coexiste avec un PO, fournit l’analyse détaillée qui alimente les décisions du PO. Dans de nombreuses organisations, une seule personne cumule les deux rôles, ce qui est viable quand le produit est simple. Sur un produit complexe avec de multiples parties prenantes, séparer les rôles permet au PO de se concentrer sur la stratégie produit tandis que le BA gère la complexité des exigences détaillées.
L’IIBA a d’ailleurs créé une certification spécifique, le CPOA (Certificate in Product Ownership Analysis), qui reconnaît cette convergence entre analyse métier et ownership produit.
Les rôles que l’on sous-estime
Le BABOK identifie d’autres parties prenantes dont l’absence compromet la qualité de l’analyse. Le domain SME (subject matter expert, expert du domaine métier) est la personne qui connaît en profondeur les processus, les règles métier et les contraintes sectorielles. Sans sa contribution, les exigences restent superficielles et les hypothèses du BA ne sont validées par personne. C’est souvent un responsable opérationnel, un juriste ou un consultant spécialisé dont l’agenda est difficile à mobiliser, ce qui rend sa participation d’autant plus précieuse.
Le sponsor est celui qui autorise et finance le travail. Son rôle va au-delà de la signature budgétaire: il arbitre entre exigences contradictoires et maintient l’alignement stratégique du projet. Un sponsor absent ou désengagé est l’un des facteurs d’échec les plus documentés, car les décisions sur le périmètre stagnent faute d’autorité légitime.
Le testeur, enfin, gagne à être impliqué bien avant la phase de validation. Un testeur qui lit les exigences en cours de rédaction identifie les ambiguïtés, les cas limites et les critères d’acceptation manquants que le BA seul aurait pu manquer. Cette collaboration précoce entre BA et testeur améliore la qualité des spécifications de manière significative.
Comment clarifier les responsabilités
La solution n’est pas de dessiner des frontières rigides entre ces rôles, car elles varieront selon la taille du projet, la méthodologie utilisée et la culture de l’organisation. L’approche pragmatique consiste à répondre, dès le cadrage, à trois questions: qui recueille les besoins? Qui arbitre les priorités? Qui valide que la solution répond au besoin?
Si la réponse à ces trois questions est “la même personne”, le risque est réel, non pas parce que c’est impossible, mais parce que les biais d’un seul point de vue ne sont corrigés par personne. La valeur de la distinction entre BA, PM et PO n’est pas bureaucratique: c’est une séparation des perspectives qui réduit les angles morts dans l’analyse des besoins.