Les 12 principes Agile : ceux que Scrum.org teste vraiment à l’examen PSM

Vous connaissez Scrum.
Vous avez lu le Scrum Guide.

Et pourtant, certaines questions à l’examen PSM restent ambiguës.

Pourquoi ?

Parce que Scrum.org ne teste pas uniquement le framework.
Il teste votre capacité à raisonner selon les principes du Manifeste Agile.

Et c’est précisément là que beaucoup de candidats se trompent.

Dans cet article, vous allez comprendre les 12 principes Agile — non pas comme une liste à apprendre, mais comme une grille de lecture pour éviter les pièges et répondre juste à l’examen.

1. Satisfaire le client par des livraisons précoces et continues

L’idée : la valeur ne doit pas rester bloquée jusqu’à la fin du projet. On livre tôt, on livre souvent, et on s’en sert pour ajuster la suite. En Scrum, cela se matérialise par un incrément potentiellement livrable à chaque Sprint, aligné sur le Sprint Goal et le Product Goal.​

Exemple : au lieu d’attendre un an pour livrer un SIRH complet, l’équipe met en production un premier périmètre paie dès le 3ᵉ Sprint, puis enrichit progressivement.

Vu de PSM : toute proposition qui privilégie un “big bang final” ou qui retarde systématiquement les mises en production s’éloigne de ce principe et est rarement la bonne réponse.​​

2. Accueillir les changements, même tard dans le projet

Le Manifeste assume que les besoins évoluent, et que c’est une opportunité plus qu’une menace. Scrum permet cette adaptation grâce au Product Backlog, que le Product Owner ré‑ordonne en continu, sans casser les timeboxes.

Exemple : une nouvelle obligation réglementaire apparaît en milieu de release. Le Product Owner ré‑priorise le backlog pour l’intégrer rapidement, au lieu de “geler le périmètre” jusqu’à la prochaine version.

Vu de PSM : les réponses qui rejettent tout changement après le Sprint Planning, ou qui proposent d’alléger la Definition of Done pour aller plus vite, sont en contradiction directe avec ce principe.​​

3. Livrer fréquemment un logiciel opérationnel

Ici, la fréquence est clé : on parle de quelques semaines, pas de quelques mois. D’où la recommandation de Sprints courts (1 à 4 semaines), chacun produisant au moins un incrément Done.

Exemple : à chaque Sprint, l’équipe délivre un ensemble de fonctionnalités réellement utilisables (écran, API, rapport), même modeste, plutôt qu’un gros bloc en fin de projet.

Vu de PSM : si une option suggère des Sprints très longs “pour tout finir”, ou considère comme acceptable qu’un Sprint se termine sans aucun incrément utilisable, la suspicion est de mise.​​

4. Travailler au quotidien avec les représentants du métier

On abandonne le modèle “MOA au début / MOE à la fin”. Le client – ou ses représentants – est impliqué tout au long du projet. En Scrum, cette collaboration s’incarne dans le rôle du Product Owner et dans la Sprint Review, où les parties prenantes voient et commentent l’incrément.​​

Exemple : sur un projet SIRH, le responsable paie participe régulièrement aux Reviews, donne du feedback, aide à arbitrer les priorités avec le Product Owner.

Vu de PSM : une réponse qui renvoie le Product Owner à un rôle de “rédacteur de cahier des charges” absent du quotidien s’oppose à ce principe.​​

5. Construire les projets autour de personnes motivées

Le Manifeste rappelle qu’une équipe engagée, autonome et soutenue fera de meilleurs choix qu’un projet dirigé à coups de Gantt et de micro‑management. Scrum mise sur une Scrum Team auto‑gérée, pluridisciplinaire, responsable de la manière d’atteindre le Sprint Goal.​​

Exemple : le Scrum Master ne distribue pas les tâches. Il crée les conditions pour que les Developers s’auto‑organisent et décident eux‑mêmes de la répartition du travail.

Vu de PSM : les propositions où le Scrum Master ou le Product Owner affecte les tâches et contrôle chaque détail de l’exécution sont presque toujours erronées.​​

6. Privilégier la communication en face‑à‑face

Un échange direct résout en quelques minutes ce qu’une chaîne d’e‑mails mettra des jours à clarifier. Scrum institutionnalise ces moments avec le Daily Scrum, la Sprint Planning, la Review et la Retrospective.​

Exemple : une équipe distribuée tient son Daily en visio caméra ouverte plutôt qu’en envoyant un rapport écrit au Scrum Master.

Vu de PSM : si la réponse propose de remplacer systématiquement ces échanges par du reporting, des slides ou des mails, elle s’éloigne de l’esprit du principe.​​

👉 À ce stade, vous devez commencer à voir un pattern : Scrum ne cherche pas à contrôler, mais à apprendre en continu. Et c’est exactement ce que Scrum.org teste : votre capacité à lâcher le contrôle pour raisonner en empirisme.

7. Mesurer l’avancement par le logiciel opérationnel

Les plannings, graphiques et indicateurs ont leur utilité, mais la vraie mesure de progression reste ce qui fonctionne réellement pour l’utilisateur. En Scrum, on mesure l’avancement par les incréments Done, pas par le nombre de tâches “en cours”.

Exemple : une équipe suit son progrès à partir des User Stories Done qui respectent la Definition of Done, plutôt qu’en comptant seulement les heures consommées.

Vu de PSM : les options centrées sur des métriques purement administratives (documents livrés, nombre de réunions tenues) sans lien avec l’incrément sont à traiter avec prudence.​​

8. Maintenir un rythme soutenable

Pas de “mode commando” permanent suivi de burn‑out collectif : l’agilité vise un rythme stable, tenable sur la durée. Scrum y contribue via des Sprints de durée constante, avec un engagement réaliste.​

Exemple : en Sprint Planning, l’équipe ajuste son engagement à sa capacité réelle plutôt que d’accepter toujours plus de travail, au détriment de la qualité ou de la santé des membres.

Vu de PSM : les réponses qui reposent sur des heures supplémentaires répétées ou sur la suppression d’événements Scrum pour “gagner du temps” sont contraires à ce principe.​​

9. Soigner l’excellence technique et la bonne conception

Aller vite ne veut pas dire “coder vite et mal”. Une base technique saine est un accélérateur, pas un frein. Scrum rend ce principe tangible avec la Definition of Done et l’idée de qualité non négociable.​

Exemple : l’équipe inclut tests automatisés, refactoring et revues de code comme partie intégrante du travail, même si cela ne se voit pas immédiatement côté utilisateur.

Vu de PSM : toute suggestion consistant à affaiblir la Definition of Done pour livrer plus ou à repousser indéfiniment la dette technique est à écarter.​​

👉 À l’examen PSM, ces principes se combinent souvent : qualité, simplicité et empirisme vont toujours ensemble.

10. Rechercher la simplicité : faire moins, mais mieux

La simplicité est “l’art de maximiser la quantité de travail non fait”. Cela signifie choisir consciemment de ne pas tout développer, mais de concentrer l’effort sur ce qui crée réellement de la valeur.

Exemple : le Product Owner nettoie régulièrement le Product Backlog, ferme les items obsolètes, et assume que certaines idées ne seront jamais mises en œuvre.

Vu de PSM : les réponses qui valorisent le fait de “tout livrer coûte que coûte” ou d’accumuler indéfiniment les demandes dans le backlog sont peu compatibles avec ce principe.​​

11. Laisser émerger les solutions des équipes auto‑organisées

Selon le Manifeste, les meilleures architectures et conceptions émergent d’équipes auto‑organisées. Scrum va dans ce sens en supprimant la hiérarchie interne à la Scrum Team : celle‑ci décide comment faire le travail.​​

Exemple : plutôt qu’imposer une architecture par un comité extérieur, l’organisation fait confiance à l’équipe pour expérimenter, apprendre et converger, sprint après sprint, avec inspection régulière en Review.

Vu de PSM : si une option introduit un chef de projet ou un architecte “au‑dessus” de l’équipe, décidant seul de la manière de travailler, elle s’écarte de ce principe.​​

12. Pratiquer l’amélioration continue

Enfin, le Manifeste invite l’équipe à prendre régulièrement du recul pour ajuster son fonctionnement. En Scrum, la Sprint Retrospective est la traduction directe de cette exigence.​

Exemple : à la fin de chaque Sprint, l’équipe choisit une ou deux actions d’amélioration concrètes (processus, communication, qualité) à tester dans le Sprint suivant, plutôt que de se contenter d’un tour de table “ça va / ça ne va pas”.

Vu de PSM : une réponse qui présente la Retrospective comme optionnelle, rare, ou centrée uniquement sur les individus plutôt que sur le système de travail, s’oppose à ce principe.​​

Comment transformer ces principes en réflexes pour l’examen

Pour Scrum.org, les 12 principes ne sont pas un supplément théorique : ils sont le filtre à travers lequel il faut lire chaque question. Quelques stratégies concrètes :​​

• Quand une question est ambiguë, demande‑toi : quel principe est mis à l’épreuve ? (changement, auto‑organisation, simplicité, qualité, rythme soutenable…).

• Élimine systématiquement les réponses “cycle en V” : plan exhaustif figé, changement rejeté, chef de projet qui contrôle tout, livraison unique en fin de projet.

• Relis régulièrement la page officielle des principes, en anglais, et reformule chacun avec un exemple tiré de ton propre contexte (projet SIRH, paie, RH, IT).

• Pendant tes simulations, identifie pour chaque question au moins un principe sous‑jacent ; cela t’entraîne à raisonner dans l’esprit du Manifeste, pas uniquement dans la lettre du Scrum Guide.​

• En travaillant de cette manière, tu ne prépares pas seulement un examen : tu te construis une grille de lecture robuste pour tous tes projets agiles, IT ou non.

Comprendre les 12 principes Agile est indispensable.
Mais ce qui fait la différence à l’examen PSM, c’est votre capacité à les reconnaître immédiatement dans une situation donnée.

Pour vous entraîner efficacement :

• PSM I : identifiez les pièges classiques et sécurisez vos réponses.

• PSM II : travaillez les scénarios complexes et la posture attendue.

• L’Agilité pour tous : consolidez vos fondamentaux pour éviter les erreurs de raisonnement.

  Disponibles en PDF sur ce site et en version Kindle et brochée sur Amazon.

  Ne mémorisez pas les principes.
  Entraînez-vous à les appliquer — c’est ce qui fait réussir l’examen