← Parcours PMP
👥

Domaine People — diriger l'équipe (33 %)

Cœur de l'examen
🧠Comprendre en lisant n'est pas savoir écrire.🧠Un module est fini quand tu peux le reproduire fenêtre fermée.🧠Écris le problème en français avant d'écrire du code.🧠Une question impossible cache trois questions faciles.🧠Retape le code à la main. Puis referme et réécris-le.🧠Essaie d'abord, cherche ensuite.🧠Cherche « comment on écrit ça », jamais « qu'est-ce que je dois faire ».🧠Pour comprendre du code, casse-le.⌨️Une fonction qui plante sur un cas limite n'est pas finie.⌨️Si un bloc a un nom clair, il mérite d'être une fonction.⌨️Savoir lire une erreur vaut plus que connaître dix méthodes.⌨️Diagnostiquer, c'est éliminer dans l'ordre — pas essayer au hasard.⌨️Une optimisation sans mesure avant/après est une croyance.🔍Regarde le fichier avant de le charger.🔍Une performance anormalement bonne est une hypothèse à réfuter.🔍Cette valeur existe-t-elle à l'instant où je dois prédire ?🔍fit sur le train, transform partout.🔍Un chiffre qu'on ne sait pas raconter est un chiffre qu'on n'a pas compris.🔍Un graphique sans question n'a rien à dire.🤖Un score d'entraînement parfait n'est jamais une bonne nouvelle.🤖Le jeu de test ne se regarde qu'une fois.🤖Plus tu essaies de configurations, plus ton meilleur score est optimiste.🤖Un seuil de décision est un arbitrage économique, pas un réglage technique.🤖Commence toujours par une baseline. Note son score.🤖Le meilleur modèle n'est pas le plus précis, c'est celui qu'on peut maintenir.🚀Un modèle en production n'est pas un livrable, c'est un système vivant.🚀Un secret publié est un secret compromis.🚀Pour chaque permission : que se passe-t-il si cette machine est compromise ?🚀Un post-mortem qui cherche un coupable ne produit aucune amélioration.🚀« Nous n'utilisons pas cette variable » n'est pas une garantie d'équité.🚀Rends l'arbitrage explicite et chiffré. Ne le tranche pas en silence.🚀Un résultat qu'on ne sait pas reproduire est une anecdote.

🎯 Objectifs d'apprentissage

À l'issue de ce module, tu seras capable de :

  • 01Diagnostiquer et résoudre un conflit d'équipe selon le modèle du PMI
  • 02Adapter son style de leadership au niveau de maturité de l'équipe
  • 03Construire un plan d'engagement des parties prenantes

Prérequis

Module Mindset PMI

📖 Lectures de référence

Sélection d'expert — les ressources gratuites sont signalées.

The Five Dysfunctions of a Team

Payant

Patrick Lencioni

~25 €. Court, sous forme de récit. Le modèle de référence sur les dynamiques d'équipe, directement applicable aux questions People (33 % de l'examen).

Constituer et lancer une équipe performante

⏱ 35 min

Le domaine People concerne les compétences humaines pour diriger une équipe. Première étape : la constituer et lui donner un cadre.

Les 5 étapes de Tuckman (dynamique d'équipe)

→ Forming : l'équipe se forme, polie et prudente.

→ Storming : tensions, désaccords — phase normale et nécessaire.

→ Norming : des règles communes émergent, la collaboration s'installe.

→ Performing : l'équipe est autonome et très productive.

→ Adjourning : dissolution en fin de projet.

Outils de lancement

→ Team charter (charte d'équipe) : document co-construit définissant valeurs, règles de fonctionnement (« ground rules »), modes de communication et de décision. Crée l'adhésion.

→ Ground rules : règles de comportement convenues ensemble (ponctualité aux réunions, respect, gestion des désaccords).

→ En agile : équipes réduites, pluridisciplinaires et auto-organisées, idéalement co-localisées ou bien outillées si distantes.

Idée clé : la performance d'équipe se construit. Le PM crée un environnement de sécurité psychologique où chacun peut s'exprimer.

Ressource : Andrew Ramdayal — People domain (YouTube) https://www.youtube.com/AndrewRamdayal

✍️ Exercices de la leçon

2 exercices

Fais-les dans l'ordre, dans un vrai fichier .py — pas dans ta tête. Ne déplie la correction qu'après avoir écrit quelque chose, même faux.

🔧

Exercice A — Reconnaître la phase de Tuckman

Application directe · Tu appliques ce que tu viens de lire.

Pour chacune de ces cinq descriptions, identifie la phase de Tuckman et dis ce que le chef de projet doit faire à ce moment-là.

  1. 1.L'équipe est polie, chacun se présente, personne ne conteste rien, et les réunions sont plates.
  2. 2.Deux développeurs s'opposent ouvertement sur l'architecture. L'ambiance est tendue.
  3. 3.L'équipe a trouvé son rythme, les revues de code se passent bien, chacun sait à qui s'adresser.
  4. 4.L'équipe livre sans supervision, résout ses problèmes seule, et te sollicite rarement.
  5. 5.Le projet se termine dans trois semaines et la productivité baisse ; les gens parlent de leur prochaine affectation.

Puis réponds : quelle phase les chefs de projet cherchent-ils à éviter, et pourquoi est-ce une erreur ?

🧩

Exercice B — Lancer une équipe distribuée sur trois pays

Cas situationnel · Aucune grille fournie : à toi de raisonner et de justifier.

Cas situationnel.

On te confie un projet de 8 mois avec une équipe de 9 personnes réparties sur trois sites : Montréal, Casablanca, Bangalore. Personne ne s'est jamais rencontré. Trois des neuf sont des prestataires externes. Le projet démarre lundi.

Le sponsor te dit : « Tu as une semaine pour lancer l'équipe. Après, on veut voir des livrables. »

  1. 1.quelles sont les trois premières choses que tu mets en place, et dans quel ordre ?
  2. 2.que contient concrètement ta charte d'équipe, sur ce contexte précis ?
  3. 3.quel est le risque n° 1 de cette configuration, et comment tu le traites ?
  4. 4.le sponsor veut des livrables dès la semaine 2 — que lui réponds-tu ?
  5. 5.qu'est-ce qui change parce que trois membres sont des prestataires ?

Le point 3 concerne les fuseaux horaires, mais pas de la façon qu'on croit.

🤖

Question sur cette leçon ? Clique sur 💬 Demander au tuteur en bas à droite.