Business Analyst vs chef de projet : qui fait quoi

En bref. Le chef de projet est redevable de la livraison — il en rend compte : délais, budget, ressources, risques. Le business analyst est garant de l'intégrité des exigences : il fait émerger le besoin réel, le traduit, et veille à ce qu'il reste juste jusqu'à la livraison. Il recommande, il ne tranche pas. Deux redevabilités distinctes, souvent cumulées, jamais identiques.

Si tu pilotes un projet — ou si tu travailles avec la personne qui le pilote —, tu as déjà vu les deux questions se mélanger, et parfois tomber sur la même tête. Voici où passe la frontière.

Chez Edelw'ice, le glacier artisanal lausannois fondé par Heidi en 1983, la refonte de la vente en ligne avance bien : Nora, la cheffe de projet, tient le planning et le budget, et la question qu'elle pose chaque semaine — « serons-nous prêts à la date promise ? » — trouve sa réponse. Abby, la méthodique du duo d'analystes, en pose une autre : « à quel besoin cette refonte répond-elle, et comment saura-t-on qu'elle y répond ? » Ce n'est pas une question que Nora aurait ratée : c'est une question que personne n'avait le mandat de poser. Les deux sont différentes, et il en faut deux.

Pourquoi confond-on chef de projet et business analyst ?

Parce que les deux gravitent autour du même projet et parlent aux mêmes personnes. Mais le chef de projet répond d'une chose : que le projet soit livré, dans les délais, le budget et la qualité convenus. Le business analyst répond d'une autre : que ce qui est livré réponde au besoin réel.

Un projet peut tenir ses délais et son budget et livrer autre chose que ce dont l'organisation avait besoin. Quand cela arrive, ce n'est pas qu'on a mal piloté : c'est que la question du besoin n'était inscrite dans le mandat de personne. Abby la pose, et elle écrit la réponse sous forme d'exigences — des phrases précises sur ce que la solution devra faire (et ne devra pas faire), qu'on pourra contrôler une fois la livraison faite. Nora s'en sert pour planifier sur du solide plutôt que sur des intentions. Chacune gagne à ce que l'autre fasse son travail.

Qui fait quoi, exactement ?

Le réflexe d'Abby. « Nora répond de ce qu'on arrive à l'heure. Moi, de ce qu'on ait vérifié l'adresse avant de partir — et c'est tout : je la vérifie, je ne choisis pas où on va. » Deux rôles, une même direction — pas une hiérarchie.

Qu'est-ce qui change dans mon équipe, concrètement ?

Rien ne déménage en bloc. Les trois tâches qui inquiètent le plus — animer les ateliers, rédiger les spécifications, négocier les demandes de changement — restent les tiennes. Ce qui change, c'est qu'une deuxième question s'y ajoute, et que quelqu'un a le mandat de la poser.

L'atelier. Tu continues de l'animer. Mené pour tenir le planning, il demande « de quoi avez-vous besoin, qu'on puisse chiffrer ? ». Mené aussi côté besoin, il demande d'abord quel problème on règle, et pour qui. Même réunion, deux récoltes — un binôme dans la salle, pas une chaise de plus.

Les spécifications. Le document reste le même. Ce qu'on y ajoute, c'est comment on vérifiera chaque ligne une fois la solution livrée. C'est cette colonne-là qui manque le plus souvent, et c'est elle qui sert le jour où le périmètre bouge en cours de route.

La demande de changement. Elle reste sur ton bureau, et c'est toi qui la négocies. Ce qui change, c'est ce que tu as en main pour le faire : tu dis ce qu'elle coûte en délai et en budget, le business analyst dit si elle sert le besoin réel ou si elle le contourne. Quand la décision remonte plus haut — un sponsor, un Product Owner —, elle remonte avec deux réponses au lieu d'une.

Si tu n'as pas de business analyst (BA), ces trois questions restent à poser — c'est toi qui les poses, à un moment séparé du pilotage.

Là où ils travaillent ensemble

Le bon tandem se relaie : le business analyst clarifie le besoin en amont, le chef de projet le transforme en plan tenable et pilote son exécution. Chez Edelw'ice, Abby cadre le besoin « livraison réfrigérée fiable » et ses exigences ; Nora en fait un lot livrable, avec un planning, un budget et un registre de risques. Ni l'une ni l'autre ne fait le travail de son binôme — et le projet avance droit. Et quand la recommandation et la décision divergent ? C'est justement que l'analyse a servi. Le désaccord se dit avant, il se note, et celui qui tranche l'assume — c'est à ça que sert une redevabilité nommée.

La même logique, hors du projet

Sur un déménagement, quelqu'un répond du camion, des dates et du budget ; quelqu'un d'autre répond d'avoir vérifié, avant de charger, que le nouveau logement peut vraiment accueillir ce qu'on emporte. Ni l'un ni l'autre ne choisit où l'on s'installe : c'est une autre décision, et elle appartient à celui qui déménage. Un déménagement peut se passer à l'heure et finir avec un canapé qui ne passe pas la porte, ou être parfaitement anticipé et ne jamais démarrer. Que tu montes un événement, un déménagement ou un lancement, il faut les deux — et deux personnes pour les tenir, même si c'est parfois la même qui porte les deux casquettes.

Clarifier les rôles dans ton équipe en trois gestes

1. Sépare les deux questions : « tenons-nous les délais et le budget ? » (chef de projet) et « répondons-nous au besoin réel ? » (BA).

2. Avant de lancer, fais poser la question du besoin — par quelqu'un dont c'est le mandat, ou par toi à un moment séparé du pilotage. Si les deux casquettes sont les tiennes, ne les porte pas dans la même réunion.

3. Ne laisse aucune des deux questions orpheline : écris, en face de chacune, le nom de la personne qui en répond.

Ces trois gestes n'alourdissent pas le projet — ils garantissent que les deux questions ont un titulaire.

Articles liés : La Business Analyse, et ce qu'elle apporte vraiment aux entreprises · Business Analyst vs Product Owner : qui fait quoi · Quelle technique de BA pour quel problème