Integration : le ciment qui relie tous les processus du projet
Si on vous pose la question “quel est le rôle principal du chef de projet ?”, la réponse selon PMI est : faire de l’integration management. Assembler toutes les pièces du projet en un tout cohérent — les processus, les personnes, les contraintes, et les objectifs pour lesquels le projet a été lancé. C’est tellement fondamental que c’est, selon Rita Mulcahy, la raison d’être même du chef de projet dans une organisation.
Ce chapitre est dense. Il couvre les 7 processus d’intégration et plusieurs concepts qui reviennent dans pratiquement toutes les questions situationnelles de l’examen. Prenez le temps de bien le comprendre.
1. Vue d’ensemble : l’intégration est présente dans tous les groupes de processus
C’est la caractéristique unique de l’integration management : c’est le seul domaine qui a des processus dans les 5 groupes (Initiating, Planning, Executing, Monitoring & Controlling, Closing). Tous les autres domaines ont des “trous” dans certains groupes. Le chef de projet est toujours en train d’intégrer.
Les 7 processus d’intégration dans l’ordre :
- Develop Project Charter — Initiating
- Develop Project Management Plan — Planning
- Direct and Manage Project Work — Executing
- Manage Project Knowledge — Executing
- Monitor and Control Project Work — Monitoring & Controlling
- Perform Integrated Change Control — Monitoring & Controlling
- Close Project or Phase — Closing
Visualiser le flux des processus
Ce diagramme illustre comment les processus d’Integration Management s’enchaînent et s’influencent mutuellement. Le Project Charter autorise le projet, le Project Management Plan définit comment il sera exécuté, Direct & Manage produit les livrables, Monitor & Control mesure la performance, Integrated Change Control gère les changements, et Close Project finalise tout.
2. Develop Project Charter
La charte de projet est le document qui autorise formellement l’existence du projet et donne au chef de projet l’autorité d’utiliser les ressources de l’organisation. Elle est signée par le sponsor et constitue le point de départ officiel du projet.
Pour l’examen, retenez ce que la charte fait au minimum :
- Autorise le projet à exister
- Donne au chef de projet l’autorité d’utiliser les ressources
- Définit les objectifs, exigences de haut niveau, et critères de succès
- Clarifie les livrables et jalons majeurs
- Identifie les risques et hypothèses initiaux
- Lie le projet aux objectifs stratégiques de l’organisation
La charte est assez large pour ne pas avoir besoin de changer pendant le projet. Si la charte doit changer après l’initiation, cela remet en question la pertinence même du projet.
Le processus de création de la charte génère aussi le journal des hypothèses (Assumption Log) — premier registre des hypothèses et contraintes identifiées à haut niveau.
3. Develop Project Management Plan
Le plan de management du projet n’est pas un simple calendrier. C’est un ensemble de plans et de baselines qui décrit comment le projet sera exécuté, contrôlé, et clôturé. Il intègre tous les plans individuels de chaque domaine.
Les plans individuels inclus
Scope, Schedule, Cost, Quality, Resources, Communications, Risk, Procurement, Stakeholder Engagement. Plus trois plans spécifiques que beaucoup de candidats oublient : le change management plan, le configuration management plan, et le requirements management plan.
La performance measurement baseline
C’est l’ensemble des trois baselines contre lesquelles la performance du projet sera mesurée :
- Scope baseline : le scope statement + WBS + WBS dictionary
- Schedule baseline : le calendrier approuvé avec dates de début/fin de chaque activité
- Cost baseline : le budget approuvé réparti dans le temps (time-phased)
Pour l’examen : un plan de management du projet doit être BARéF — Bought into, Approved, Realistic, et Formal. L’équipe doit y croire, le sponsor doit l’approuver formellement, il doit être réaliste, et c’est un document officiel qui évolue via des changements approuvés.
Le tailoring
Le chef de projet adapte les processus aux besoins spécifiques du projet — il ne les applique pas tous systématiquement. C’est le tailoring. C’est aussi une responsabilité formelle dans le plan de management du projet : définir quels processus seront utilisés et dans quelle mesure.
La réunion de lancement (Kickoff Meeting)
Avant de commencer l’exécution, le chef de projet tient une réunion de lancement pour s’assurer que toutes les parties clés connaissent les détails du projet — objectifs, rôles, responsabilités, jalons. C’est la fin officielle de la planification et le début de l’exécution.
4. Direct and Manage Project Work
C’est le processus d’exécution de l’intégration. Le chef de projet coordonne tout le travail en cours — l’équipe, les fournisseurs, les parties prenantes — pour produire les livrables selon le plan approuvé. Ce processus produit notamment :
- Les livrables
- Les work performance data (données brutes sur l’avancement)
- Les change requests
Le work authorization system est un outil utilisé sur les grands projets pour autoriser formellement le début de chaque lot de travaux. Sans cette autorisation, le travail ne commence pas — cela évite que deux équipes se retrouvent à travailler sur la même zone en même temps.
5. Manage Project Knowledge
Ce processus s’assure que les connaissances générées pendant le projet sont partagées et archivées pour bénéficier à l’organisation. Il distingue deux types de connaissances :
- Explicit knowledge (connaissance explicite) : factuelle, documentable, communicable par mots et symboles. Exemples : leçons apprises, processus, rapports, historiques.
- Tacit knowledge (connaissance tacite) : subjective, basée sur l’expérience, difficile à documenter. Elle s’acquiert par observation, mentorat, job shadowing. Exemples : les “trucs du métier”, l’intuition professionnelle.
L’osmotic communication est le concept agile de connaissance qui s’absorbe naturellement par la proximité physique — entendre les conversations de collègues voisins sans le chercher.
Les leçons apprises (Lessons Learned)
Les leçons apprises documentent ce qui s’est bien passé, ce qui a mal tourné, et ce qu’on ferait différemment. Elles sont collectées tout au long du projet — pas seulement à la clôture. En agile, elles sont collectées après chaque itération lors des rétrospectives. C’est une responsabilité professionnelle du chef de projet.
6. Monitor and Control Project Work
Ce processus s’étend de l’initiation jusqu’à la clôture. Il compare l’avancement réel et les prévisions au plan, identifie les écarts, et déclenche les actions correctives nécessaires. Il est transversal — le chef de projet surveille toutes les contraintes simultanément.
Ce processus produit notamment des work performance reports et des change requests. Si des écarts sont découverts, le chef de projet doit analyser leurs causes et prendre des mesures correctives, préventives, ou de réparation de défauts.
Règle importante pour l’examen : beaucoup d’écarts significatifs par rapport aux baselines indiquent une gestion des risques insuffisante. Si l’examen vous demande quoi faire face à un écart majeur, considérez que la bonne réponse peut être de revoir le processus de gestion des risques.
7. Perform Integrated Change Control
C’est l’un des concepts les plus testés de tout l’examen PMP. Tous les changements sur un projet prédictif passent par ce processus. Son rôle : évaluer l’impact de chaque changement sur toutes les contraintes du projet avant de l’approuver.
Les 3 types de changements
- Corrective action : ramener la performance future en ligne avec le plan. On corrige un écart déjà constaté.
- Preventive action : éviter un écart anticipé. On agit avant que le problème ne survienne, en analysant les tendances.
- Defect repair : corriger un composant qui ne répond pas aux exigences (retravail).
Le processus de gestion des changements en 4 étapes
- Évaluer l’impact sur toutes les contraintes (pas seulement le temps ou le coût)
- Identifier les options : crash, fast track, réduction de périmètre, etc.
- Faire approuver par le CCB ou le sponsor
- Communiquer aux parties prenantes concernées et mettre à jour tous les documents
Pour l’examen : quand quelqu’un veut un changement, la première action est toujours d’évaluer son impact sur toutes les contraintes — pas de l’accepter, pas de le refuser, pas de chercher des solutions tout de suite. Évaluer d’abord.
Le Change Control Board (CCB)
Groupe formel responsable de l’approbation, du report, ou du rejet des changements. Il peut inclure le chef de projet, le client, le sponsor, des experts, et des managers fonctionnels. Pour l’examen : supposez que les projets prédictifs ont un CCB.
En agile, c’est le product owner qui joue ce rôle pour les changements quotidiens. Les changements qui dépassent les seuils de tolérance (budget, bénéfices) sont escaladés au sponsor ou steering committee.
8. Close Project or Phase
La clôture est souvent négligée dans la réalité, mais PMI suppose qu’elle est toujours faite — même si le projet est annulé. La règle absolue : tout projet doit être formellement clôturé, quelles que soient les circonstances.
Les activités de clôture incluent :
- Confirmer que tout le travail est fait selon les exigences
- Clôturer tous les contrats et achats
- Obtenir l’acceptation formelle finale du produit
- Compléter la clôture financière
- Transférer le produit au client ou aux opérations
- Solliciter le feedback du client sur le projet
- Compléter le reporting final de performance
- Indexer et archiver tous les enregistrements du projet
- Finaliser et partager les leçons apprises
Distinguez bien Close Project or Phase (clôture du projet entier — acceptation finale) de Validate Scope (acceptation des livrables intermédiaires au fil du projet). Les deux sont nécessaires.
Les points à retenir pour l’examen
- Le rôle principal du chef de projet = integration management — assembler toutes les pièces en un tout cohérent
- L’intégration est le seul domaine présent dans les 5 groupes de processus
- La charte : autorisation formelle du projet, signée par le sponsor, donne l’autorité au chef de projet
- Le plan de management du projet = BARF : Bought into, Approved, Realistic, Formal
- La performance measurement baseline = Scope + Schedule + Cost baselines
- Les plans à ne pas oublier : Change management plan, Configuration management plan, Requirements management plan
- Explicit knowledge = documentable / Tacit knowledge = expérientielle, difficile à documenter
- Leçons apprises = collectées tout au long du projet, pas seulement à la clôture
- Face à un changement : 1- Évaluer l’impact sur toutes les contraintes / 2- Identifier les options / 3- Faire approuver / 4- Communiquer et mettre à jour
- Corrective = corriger un écart constaté / Preventive = éviter un écart anticipé / Defect repair = retravail
- Tout projet doit être formellement clôturé, même s’il est annulé
- En agile : le product owner joue le rôle du CCB pour les changements courants
- Déviations significatives des baselines → souvent signe d’une gestion des risques insuffisante
