Business Analyst vs Product Owner : qui fait quoi

En bref. Le Product Owner est redevable de la valeur du produit : il ordonne le backlog — ce qui reste à construire — et il tranche. Le business analyst est garant de l'intégrité des exigences : il fait émerger le besoin réel, le traduit, et il recommande. L'un décide, l'autre recommande — deux redevabilités distinctes, souvent portées par la même personne.

Chez Edelw'ice, le glacier artisanal lausannois fondé par Heidi en 1983, Elisabeth, la cheffe de produit, prend le rôle de Product Owner (PO) — le rôle, issu des méthodes agiles : redevable de la valeur du produit, elle ordonne les travaux. Sur la refonte de la vente en ligne, un flottement s'installe : qui décide des priorités, elle ou Abby, la méthodique du duo d'analystes ? Lexie résume la tension d'une phrase : « on ne sait pas qui tient le volant et qui lit la carte. » La confusion des rôles coûte plus cher que leur chevauchement.

Si tu travailles sur un produit — ou avec la personne qui en répond —, tu as déjà vu ce flottement : deux personnes compétentes parlent du même besoin, et personne ne sait laquelle tranche. Voici où passe la frontière.

Pourquoi confond-on si souvent les deux rôles ?

Parce qu'ils touchent tous deux au besoin et au backlog produit — la liste ordonnée de tout ce qui reste à construire pour le produit. Ce backlog n'appartient pas à un projet : il vit au-delà, il est porté par le Product Owner, et il est ordonné par la valeur. Vu de loin, le Product Owner et le business analyst (BA) semblent faire la même chose : parler aux gens, écrire des exigences, discuter priorités. De près, leur responsabilité diffère.

Le Product Owner est redevable de la valeur du produit : il ordonne le backlog par la valeur, il tranche, et il en répond. Le business analyst est garant de l'intégrité des exigences — qu'elles restent complètes, cohérentes et à jour du premier jour à la livraison : il fait émerger le besoin réel et le traduit en exigences — des phrases précises sur ce que la solution devra faire (et ne devra pas faire), qu'on pourra contrôler une fois livrée. Abby instruit et recommande ; Elisabeth s'appuie sur cette recommandation et tranche : c'est son mandat, pas celui d'Abby. Deux redevabilités distinctes, et il en faut deux.

Qui fait quoi, exactement ?

Le réflexe d'Abby. « Elisabeth tient le volant, moi je lis la carte — et une carte ne conduit pas. » 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 — affiner le backlog, écrire les user stories, décider de l'ordre — ne changent pas de main : elles gagnent une deuxième question.

L'affinage du backlog. Mené pour préparer la suite, il demande « est-ce assez clair pour être construit ? ». Mené côté exigences, il demande d'abord si la ligne répond à un besoin qu'on a vérifié, ou à une demande qu'on a reçue. Ce n'est pas la même chose.

Les user stories. Écrites pour l'équipe, elles disent ce qu'on va construire. Écrites côté exigences, elles disent aussi comment on saura que c'est juste : les critères d'acceptation ne sont pas un formalisme, c'est là que le besoin devient vérifiable. Une user story n'est pas un autre objet que l'exigence : c'est la forme qu'elle prend dans une équipe agile — le besoin dit du point de vue de celui qui s'en sert, et les critères qui permettront d'affirmer qu'il est satisfait. Écrire des user stories claires déroule la forme.

L'ordre du backlog. Le business analyst instruit — ce que la ligne apporte, ce qu'elle suppose, ce qu'elle casse ailleurs. Le Product Owner tranche avec ça en main. L'ordre reste le sien : c'est sa redevabilité, et elle ne se délègue pas.

Si tu n'as pas de BA, ces questions restent à poser — c'est toi qui les poses, à un autre moment que l'affinage.

Là où ils travaillent ensemble

Le meilleur duo n'est pas celui qui trace une frontière, mais celui qui se passe le relais : le BA fait émerger et clarifie le besoin, le PO s'en sert pour ordonner le backlog produit en connaissance de cause. Chez Edelw'ice, une fois les rôles nommés, Abby clarifie le besoin « livraison réfrigérée fiable » et Elisabeth décide de le mettre en tête du backlog. 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.

Un mot sur la priorisation, parce que c'est là que les tables se mélangent : les axes dépendent de qui arbitre. Elisabeth arbitre côté métier, et elle compare des fonctionnalités en impact × urgence — ce que ça rapporte, et ce que coûte l'attente. L'équipe qui réalise arbitre ses tâches, et elle les compare en impact × effort : la charge lui appartient. Nommer l'arbitre avant de tracer les axes, et le flottement disparaît.

La même logique, hors du produit

Sur un chantier, le maître d'ouvrage décide ce qu'on construit et dans quel ordre : c'est son budget, et c'est lui qui en répond. L'architecte l'aide à formuler ce qu'il veut vraiment, puis le met en plans : il fait apparaître ce que le programme implique — ce qui est constructible, à quelles conditions, à quel prix — et le lui dit avant qu'on coule les fondations. Les deux métiers sont entiers, et aucun ne se déduit de l'autre : sans le premier on bâtit sans décision, sans le second on décide sans plan. Que tu sois en start-up, en PME ou en association, la distinction recommander / trancher vaut partout.

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

1. Sépare les deux redevabilités : la valeur du produit, qui se tranche (PO), et l'intégrité des exigences, qui se recommande (BA).
2. Nomme, pour chaque décision produit, qui tranche et qui recommande — même si c'est la même personne portant deux casquettes.
3. Chasse les responsabilités orphelines : un besoin que personne n'a le mandat de clarifier, ou un backlog produit sans arbitre nommé. C'est là que les projets dérapent.

Ces trois gestes ne créent pas de bureaucratie — ils évitent le flou qui paralyse une équipe.

Pour aller plus loin (le référentiel). L'IIBA consacre un guide entier à cette zone : le Guide to Product Ownership Analysis (version 1.0, 2021). Il ne trace pas la frontière nette qu'on aimerait — il décrit trois zones (§3.1, p. 12), dont voici l'essentiel. Côté Business Analyse : traduire le pourquoi en comment, tenir les exigences, les modéliser et les communiquer. Côté Product Ownership : déterminer le pourquoi et le quoi, porter la vision et la feuille de route, la valeur livrable, la voix du client. Et entre les deux, la Product Ownership Analysis elle-même — parties prenantes, compréhension du problème et des processus, prise de décision. Le guide note par ailleurs que le contexte de l'organisation pèse lourd sur la répartition des responsabilités entre rôles voisins (§2.4.1, p. 7, à propos cette fois du Product Owner et du product manager). La redevabilité se nomme : elle ne se déduit pas d'un référentiel.

Articles liés : La Business Analyse, et ce qu'elle apporte vraiment aux entreprises · Business Analyst vs chef de projet : qui fait quoi · Prioriser ses tâches quand tout est « prioritaire »