← Parcours PMP
🌍

Domaine Business Environment (26 %)

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 :

  • 01Relier un projet à la stratégie et aux bénéfices attendus
  • 02Intégrer les exigences de conformité dans le pilotage
  • 03Piloter la réalisation des bénéfices après livraison

Prérequis

Module Process

📖 Lectures de référence

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

The Standard for Business Analysis

Payant

PMI

Inclus dans l'adhésion PMI. Couvre le domaine Business Environment (26 % de l'examen), souvent le plus négligé.

Conformité, gouvernance & environnement organisationnel

⏱ 30 min

Le domaine Business Environment relie le projet à son contexte organisationnel et externe.

Conformité (compliance)

→ Identifier les exigences légales, réglementaires, contractuelles et de sécurité applicables.

→ Les intégrer au projet et surveiller leur respect en continu. La non-conformité est un risque majeur (juridique, financier, réputationnel).

Gouvernance : cadre de décision et de contrôle. Définit qui décide quoi (comités, CCB, sponsor), comment l'information remonte, et comment le projet s'aligne sur les règles de l'organisation.

EEF & OPA (à bien distinguer)

→ EEF (Enterprise Environmental Factors) : facteurs externes ou imposés au projet (culture d'entreprise, marché, réglementation, conditions économiques, outils existants). On les subit.

→ OPA (Organizational Process Assets) : actifs internes réutilisables (modèles, procédures, leçons apprises, archives de projets passés). On s'en sert.

À l'examen : reconnaître si un élément est un EEF (contrainte du contexte) ou un OPA (ressource interne) revient souvent.

Ressource : Andrew Ramdayal — Business Environment 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 — EEF ou OPA ?

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

Classe chacun de ces dix éléments en EEF (facteur environnemental de l'entreprise) ou OPA (actif organisationnel), et dis si tu peux le modifier ou seulement le subir.

  1. 1.Le modèle de charte de projet utilisé dans ton organisation
  2. 2.La réglementation RGPD
  3. 3.La culture hiérarchique de l'entreprise
  4. 4.La base de données des leçons apprises des projets passés
  5. 5.Le logiciel de gestion de projet imposé par la DSI
  6. 6.La procédure interne de validation des achats
  7. 7.Les conditions du marché du travail dans ton secteur
  8. 8.Le référentiel de risques types de ton organisation
  9. 9.La tolérance au risque du comité de direction
  10. 10.Le format de rapport d'avancement en vigueur

Puis : pourquoi cette distinction est-elle testée à l'examen ? Que change-t-elle en pratique ?

🧩

Exercice B — L'exigence réglementaire découverte au mois 7

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

Cas situationnel.

Ton projet de plateforme de données est au mois 7 sur 11. Le service conformité, qui n'avait pas été impliqué, découvre que la solution ne respecte pas une obligation de localisation des données personnelles : elles doivent rester sur le territoire national, or ton hébergeur les réplique à l'étranger.

Les conséquences :
- l'architecture retenue est incompatible en l'état
- corriger représente environ 6 semaines et 90 k€
- la date de mise en service est engagée auprès du client
- le sponsor te demande si « on peut passer outre en attendant »

  1. 1.réponds à la question du sponsor
  2. 2.quelle est ta première action, avant même de chiffrer ?
  3. 3.quel processus a échoué en amont, et comment tu le répares
  4. 4.construis les options que tu présentes en comité, avec leurs conséquences
  5. 5.dans quelle catégorie classes-tu cette obligation, et qu'est-ce que ça implique ?

Le point 1 n'admet qu'une réponse. Formule-la de façon utilisable en réunion.

🤖

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