Les 3 rôles Scrum : Qui décide VRAIMENT ?

En Scrum, il n’y a pas de chef de projet.
Et c’est précisément pour ça que la majorité des équipes se trompent… et que beaucoup échouent au PSM.

Le Product Owner (PO) est la personne qui décide ce qui a le plus de valeur pour le produit et dans quel ordre le faire. Il porte la vision long terme à travers le Product Goal et gère le Product Backlog : il crée les items, les ordonne, les clarifie et s’assure que tout le monde comprend pourquoi on travaille sur tel sujet plutôt que sur un autre.

En pratique, cela signifie qu’il parle en continu avec les parties prenantes (clients, métier, RH, direction…), arbitre les priorités et assume le “non” quand une demande n’apporte pas assez de valeur. Il peut déléguer la rédaction de certaines user stories, mais il reste toujours accountable du contenu et de l’ordre du Product Backlog.

À l’examen PSM, méfie‑toi des réponses où le PO “valide” l’Incrément ou “approuve” le Sprint Backlog : dans Scrum, c’est la Definition of Done qui valide la qualité, et les Developers construisent eux‑mêmes le plan de Sprint.​

👉 Erreur fréquente : penser que le Product Owner “décide tout”. En réalité, il décide de la valeur — mais il ne contrôle ni le travail, ni la manière de le faire

2. Scrum Master : garant du cadre et de la dynamique

Le Scrum Master n’est pas un chef de projet rebaptisé : c’est un leader‑serviteur qui aide la Scrum Team à être efficace en appliquant vraiment Scrum. Il enseigne le cadre, facilite les événements, aide à lever les obstacles, accompagne le Product Owner et l’organisation dans l’adoption de l’empirisme (transparence, inspection, adaptation).​

Concrètement, il ne décide ni du contenu du Sprint, ni des priorités du Product Backlog, ni de la répartition des tâches : son rôle est de créer les conditions pour que l’équipe s’auto‑organise, pas de décider à sa place.

Dans PSM I/II, de nombreuses questions testent ce point : toute réponse qui transforme le Scrum Master en “project manager” (assignation des tâches, contrôle hiérarchique, validation des plans) est presque toujours incorrecte.

👉 Erreur critique : évaluer un Scrum Master sur sa capacité à “piloter”. Plus il contrôle, moins il fait du Scrum.

3. Developers : responsables de l’Incrément et du “comment”

Les Developers sont toutes les personnes qui travaillent directement à la création d’un Incrément utilisable à chaque Sprint : développeurs, testeurs, UX, data, profils métier… selon le produit. Ensemble, ils construisent et ajustent le Sprint Backlog, choisissent comment atteindre le Sprint Goal, se répartissent le travail et s’engagent à respecter la Definition of Done.

Ils ne re‑priorisent pas le Product Backlog (cela reste la responsabilité du PO), mais ils peuvent challenger la faisabilité, clarifier les items et proposer des solutions techniques.

À l’examen, un piège récurrent consiste à laisser le Product Owner ou le Scrum Master décider “qui fait quoi” dans l’équipe : en Scrum, ce sont les Developers qui détiennent cette responsabilité, au nom de l’auto‑gestion.​

4. Qui décide quoi, sans de chef de projet ?

On peut résumer la répartition ainsi :

• Le Product Owner décide quoi développer en priorité. Il détermine l'ordre du Product Backlog en fonction de la valeur métier, des retours stakeholders et des contraintes business. Cette décision garantit que l'équipe travaille toujours sur les éléments les plus importants pour le succès du produit.

• La Scrum Team, portée par le Product Owner, décide pourquoi ce Sprint est utile. Le Sprint Goal exprime l'objectif concret du sprint, choisi collectivement mais guidé par le PO. Il donne du sens au travail et aligne l'équipe sur une valeur tangible à livrer.

• Les Developers décident comment atteindre le Sprint Goal. Ils créent le plan détaillé dans le Sprint Backlog et s'auto-organisent pour le réaliser. Personne ne leur assigne de tâches : c'est leur responsabilité collective.

• Le Scrum Master décide comment appliquer Scrum et lever les obstacles. Il sert la Scrum Team et l'organisation en maintenant le cadre Scrum, en facilitant les événements et en résolvant les blocages systémiques. Il n'intervient pas sur le contenu produit.

• La Scrum Team décide quand un travail est “Done”. Elle définit et applique une Definition of Done partagée, qui assure que chaque Incrément est potentiellement livrable, testé et conforme aux standards de qualité.

Si vous devez retenir une seule chose, c’est celle-ci :

• Product Owner → valeur

• Developers → exécution

• Scrum Master → cadre

• Scrum Team → qualité

C’est cette distribution d’accountabilities que Scrum.org cherche à vérifier en détail dans PSM I/II : dès qu’une réponse concentre trop de pouvoir sur une seule personne – Product Owner “tout‑puissant”, Scrum Master chef de projet, “Project Manager” officiel – tu peux la regarder d’un œil critique.​

👉 Scrum ne répartit pas les tâches. Il répartit les responsabilités.

5. Pièges fréquents à l’examen PSM

Quelques formulations typiques que tu rencontreras :

• “Le Scrum Master assigne les tâches aux Developers.” → Faux : les Developers s’auto‑organisent.

• “Le Product Owner valide l’Incrément à la fin du Sprint.” → Faux : c’est la Definition of Done qui fait foi ; le PO juge la valeur, pas la complétude technique.

• “Le Project Manager met à jour le Sprint Backlog.” → Faux : il n’y a pas de rôle Project Manager dans Scrum, et le Sprint Backlog appartient aux Developers.

• “Les stakeholders peuvent modifier directement le Product Backlog.” → Faux : ils peuvent proposer, mais seul le Product Owner en est responsable.

👉 À l’examen PSM, ces questions ne testent pas votre mémoire. Elles testent votre capacité à détecter une dérive vers le management classique.

En t’entraînant à repérer ces pièges, tu renforces à la fois ta compréhension du cadre et tes réflexes pour PSM1/PSM2.

Comprendre les rôles ne suffit pas. Ce qui fait la différence à l’examen PSM, c’est votre capacité à repérer immédiatement les erreurs de responsabilité.

👉 Si tu veux éviter ces pièges le jour du PSM, tu dois t’entraîner à les reconnaître rapidement.

Mes guides PSM I et PSM II sont conçus exactement pour ça :

• questions corrigées

• pièges détaillés

• logique d’examen expliquée

Objectif : viser +90% dès le premier passage.

Pour approfondir, tes e‑books de préparation PSM I et PSM II détaillent ces trois rôles avec des scénarios d’examen, des questions piégées et des explications pas à pas : un complément idéal pour transformer cette compréhension en score > 90% le jour J.

• PSM I (125 questions corrigées, pièges analysés, plans de révision sur 2 et 4 semaines),

• PSM II (scénarios avancés, examens blancs

• et L'Agilité pour tous (pour ancrer les fondamentaux dans tous vos contextes professionnels).

👉 Disponibles sur le site et sur Amazon.