← Parcours PMP
⚙️

Domaine Process — piloter le projet (41 %)

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 :

  • 01Calculer et interpréter les indicateurs EVM (CPI, SPI, EAC)
  • 02Identifier le chemin critique et l'impact d'un retard
  • 03Conduire une analyse de risques qualitative et quantitative

Prérequis

Module Fondamentaux

📖 Lectures de référence

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

PMBOK Guide, 7e édition

Payant

PMI

Référentiel officiel — les processus du domaine Process (41 % de l'examen) en découlent directement.

Practice Standard for Earned Value Management

Payant

PMI

Inclus dans l'adhésion PMI. L'EVM tombe systématiquement à l'examen et se calcule, donc les points sont sûrs.

Intégration, charte projet & valeur

⏱ 30 min

Le domaine Process couvre les aspects techniques de la conduite de projet. L'intégration est le fil rouge qui relie tout.

La charte de projet (project charter)

→ Document qui autorise officiellement le projet et nomme le chef de projet.

→ Émise par le sponsor. Contient les objectifs de haut niveau, le business case, les grandes contraintes et les parties prenantes clés.

→ Sans charte, le projet n'existe pas formellement : c'est le premier livrable.

Le plan de management de projet (PMP plan) : document intégrateur regroupant tous les plans subsidiaires (périmètre, échéancier, coûts, qualité, risques…) et les baselines de référence.

Maîtrise intégrée des changements (Integrated Change Control)

→ Tout changement passe par une demande de changement formelle, évaluée (impact coût/délai/périmètre/risque) puis approuvée ou rejetée, souvent par un CCB (Change Control Board).

→ On ne modifie jamais une baseline « en douce » : c'est une faute classique sanctionnée à l'examen.

Orientation valeur (PMBOK 8) : on pilote vers les bénéfices attendus, pas seulement le respect du triangle coût/délai/périmètre.

Ressource : Andrew Ramdayal — Process domain 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 — Ce qui passe par le contrôle des changements

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

Pour chacune de ces huit demandes, dis si elle nécessite une demande de changement formelle ou non, et justifie.

  1. 1.Le client veut ajouter un écran de rapport non prévu.
  2. 2.Un développeur veut renommer une variable dans le code.
  3. 3.L'équipe veut remplacer une bibliothèque par une autre, à fonctionnalité identique et sans impact sur les délais.
  4. 4.Le sponsor veut avancer la date de livraison de trois semaines.
  5. 5.Une réglementation nouvelle impose un champ supplémentaire dans un formulaire.
  6. 6.Un membre de l'équipe est remplacé par un autre, à compétence équivalente.
  7. 7.Le client accepte de retirer une fonctionnalité pour tenir les délais.
  8. 8.Le fournisseur annonce que son composant coûtera 15 % de plus.

Puis réponds : qu'est-ce qu'on ne fait jamais, quelle que soit l'approbation ?

🧩

Exercice B — Le changement déjà commencé

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

Cas situationnel.

Tu découvres en réunion d'avancement que ton équipe travaille depuis deux semaines sur une fonctionnalité qui n'est pas au périmètre. En creusant : le client l'a demandée directement à ton développeur senior lors d'un point technique, celui-ci a trouvé « que c'était logique » et s'y est mis.

Le travail est fait à 70 %. Il a consommé environ 15 jours-personnes non budgétés, et deux tâches du chemin critique ont pris du retard.

  1. 1.quelle est ta première action ?
  2. 2.que fais-tu du travail déjà réalisé — on le jette, on le garde ?
  3. 3.comment traites-tu le développeur, et le client ?
  4. 4.quel processus a échoué, et comment tu le répares
  5. 5.que dis-tu au sponsor, et quand ?

Le point 2 est un piège. La réponse instinctive — « on jette, ce n'était pas au périmètre » — n'est pas la bonne.

🤖

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