Dans les organisations qui adoptent Scrum, la question se pose rapidement: qui endosse le rôle de Product Owner? Le réflexe le plus courant consiste à désigner le chef de projet existant, en partant du principe que les compétences sont transférables. C’est à la fois compréhensible et risqué, car les deux rôles reposent sur des logiques de responsabilité fondamentalement différentes.
Deux responsabilités qui ne visent pas le même objet
Le chef de projet classique est responsable de la livraison d’un projet dans le respect d’un triangle de contraintes: délais, coûts et périmètre. Son succès se mesure à sa capacité à tenir ces engagements. Le Product Owner, tel que défini par le Guide Scrum, est responsable de maximiser la valeur du produit résultant du travail de l’équipe Scrum. Son succès se mesure à la satisfaction des utilisateurs et à la pertinence de ce qui a été livré.
Cette distinction a des conséquences concrètes sur chaque décision quotidienne. Quand un chef de projet apprend qu’une fonctionnalité prendra deux semaines de plus que prévu, il cherche à ajuster le planning ou le périmètre pour respecter la date de livraison. Quand un Product Owner fait face à la même situation, il se demande si cette fonctionnalité apporte suffisamment de valeur pour justifier le délai, ou si le temps de l’équipe serait mieux investi sur un autre élément du Product Backlog (la liste ordonnée de tout ce que l’équipe doit réaliser).
Le chef de projet exécute un plan défini en amont, avec des marges d’ajustement. Le PO définit en permanence ce qui mérite d’être construit, en s’appuyant sur les retours du terrain et l’évolution du contexte. Scrum.org résume la différence en une formule éclairante: le chef de projet se voit dire quoi ajouter ou retirer de la liste de souhaits, tandis que le Product Owner effectue lui-même les choix stratégiques.
Des compétences partagées, une posture différente
Les deux rôles mobilisent des compétences qui se recoupent en partie. La gestion des parties prenantes (stakeholders) occupe une place centrale dans les deux cas: il faut comprendre les attentes, arbitrer entre des intérêts divergents et communiquer les décisions. La capacité à prioriser est tout aussi essentielle, de même que l’aptitude à négocier et à maintenir une vision d’ensemble.
Là où les chemins divergent, c’est dans la posture adoptée. Le chef de projet coordonne des ressources et des activités, souvent depuis une position extérieure à l’équipe d’exécution. Le Product Owner est membre à part entière de l’équipe Scrum. Il participe aux événements Scrum (Sprint Planning, Sprint Review, rétrospective), répond aux questions des Developers sur le Backlog et reste disponible pour clarifier les priorités au fil du Sprint.
Cette appartenance à l’équipe change la nature des interactions. Le PO ne délègue pas un cahier des charges puis attend le résultat: il collabore au quotidien avec les Developers pour affiner les éléments du Backlog, valider les hypothèses et ajuster le cap en fonction de ce que l’équipe découvre au fil du développement.
Les pièges du cumul des deux rôles
Dans les PME et les organisations en transition vers l’agilité, la même personne cumule fréquemment les fonctions de chef de projet et de Product Owner. Cette situation s’explique souvent par des contraintes de ressources dans les petites structures, mais elle génère des tensions structurelles qu’il vaut mieux anticiper.
Le premier piège est le conflit de priorités. Le réflexe du chef de projet face à un retard est de protéger le planning, quitte à réduire le périmètre de manière mécanique. Le réflexe du PO devrait être de réexaminer la valeur de chaque élément et de réordonner le Backlog en conséquence. Quand une seule personne porte les deux rôles, le mode “chef de projet” tend à prévaloir, car les délais sont visibles et mesurables tandis que la valeur produit est plus difficile à défendre.
Le deuxième piège concerne la disponibilité. Un chef de projet passe une partie importante de son temps en réunions de pilotage, en reporting et en coordination avec d’autres projets. Or le Product Owner doit rester accessible pour l’équipe Scrum, y compris pour des clarifications ponctuelles sur un élément du Backlog. Un PO absent crée des blocages qui ralentissent l’équipe et dégradent la qualité des livraisons.
Le troisième piège est le Backlog Refinement négligé. Cette activité, au cours de laquelle le PO et les Developers décomposent et précisent les éléments à venir, est la première à être sacrifiée quand le temps manque. Sans Refinement régulier, les éléments du Backlog arrivent en Sprint Planning insuffisamment détaillés, ce qui génère des incompréhensions et des reprises.
Comment réussir la transition
Pour un chef de projet qui assume un rôle de Product Owner, le changement le plus important est la métrique de succès. Le PO doit accepter que respecter un planning n’est pas une fin en soi si le produit livré ne répond pas aux besoins des utilisateurs. Cela implique de renoncer à une certaine prévisibilité au profit d’une capacité d’adaptation continue, ce qui peut être déstabilisant pour quelqu’un formé à la planification rigoureuse.
Il est également essentiel de clarifier les moments où l’on agit en tant que chef de projet (coordination, reporting, gestion des contraintes) et ceux où l’on agit en tant que PO (priorisation par la valeur, décisions produit, collaboration avec l’équipe). Scrum.org identifie six postures que le PO endosse selon les situations: visionnaire, collaborateur, représentant client, décideur, expérimentateur et influenceur. Reconnaître dans quelle posture on se trouve à un moment donné aide à prendre des décisions cohérentes.
Enfin, l’organisation elle-même doit soutenir la transition. Le Guide Scrum précise que les décisions du Product Owner doivent être respectées par l’ensemble de l’organisation. Si la hiérarchie remet systématiquement en cause les arbitrages du PO, le Backlog perd sa cohérence et l’équipe Scrum ne sait plus quelles priorités suivre. Pour le chef de projet qui devient PO, cela signifie négocier un mandat clair avec sa direction. La certification PSPO (Professional Scrum Product Owner) aide à structurer cette démarche en formalisant les compétences attendues sur trois niveaux de maîtrise.