Pourquoi l’Integration Management est-il si important ?
L’Integration Management consiste à coordonner l’ensemble des éléments du projet pour atteindre ses objectifs. Chaque décision que prend le chef de projet impacte simultanément plusieurs contraintes : périmètre, planning, coûts, qualité, risques et ressources. C’est précisément cette vision globale qui définit l’intégration.
L’Integration Management est le seul domaine qui a des processus dans les cinq groupes de processus : Initiating, Planning, Executing, Monitoring & Controlling et Closing. Sur l’examen, si une question demande “quel domaine intervient tout au long du projet ?”, la réponse est toujours Integration.
Les sept processus d’Integration Management couvrent l’intégralité du cycle de vie du projet :
- 4.1 Develop Project Charter — Initiating
- 4.2 Develop Project Management Plan — Planning
- 4.3 Direct and Manage Project Work — Executing
- 4.4 Manage Project Knowledge — Executing
- 4.5 Monitor and Control Project Work — Monitoring & Controlling
- 4.6 Perform Integrated Change Control — Monitoring & Controlling
- 4.7 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.
Les 7 processus en détail
Le Project Charter est le document qui autorise officiellement le projet. C’est le premier livrable de la gestion de projet — sans lui, le projet n’existe pas formellement. Il est rédigé par le chef de projet mais signé par le sponsor.
Ce que contient un Project Charter :
- Autorisation formelle du projet
- Objectifs mesurables et critères de succès
- Exigences de haut niveau et périmètre préliminaire
- Risques majeurs identifiés
- Budget préliminaire et jalons principaux
- Nom du chef de projet et niveau d’autorité accordé
- Lien avec les objectifs stratégiques de l’organisation
Le charter crée aussi l’Assumption Log — le registre des hypothèses identifiées lors de l’initiation, qui sera mis à jour tout au long du projet.
C’est le Project Charter qui donne au chef de projet l’autorité pour utiliser les ressources de l’organisation. Le charter est signé par le sponsor — pas par le chef de projet. Les changements au charter au-delà de l’initiation doivent remettre en question la poursuite du projet.
Le Project Management Plan (PMP) est le document central qui regroupe et intègre tous les plans subsidiaires du projet. C’est la référence principale pour piloter et contrôler le projet.
Il contient les plans de gestion pour :
- Scope, Schedule, Cost, Quality
- Resources, Communications, Risk, Procurement
- Stakeholder Engagement, Requirements Management
- Change Management, Configuration Management
Il inclut également les trois baselines :
- Scope baseline : scope statement + WBS + WBS dictionary
- Schedule baseline : planning approuvé avec dates de début et fin
- Cost baseline : budget approuvé réparti dans le temps
Ces trois baselines constituent ensemble la performance measurement baseline, utilisée pour mesurer et rapporter la performance du projet via l’Earned Value Management.
Pour l’examen, chaque management plan répond à trois questions fondamentales : Comment planifier ? Comment exécuter ? Comment mesurer et contrôler ? Supposez toujours que le chef de projet a créé tous les management plans. Si un problème survient en cours de projet, la première action est souvent de consulter le management plan correspondant.
Ce processus représente la phase d’exécution du projet — là où l’équipe produit concrètement les livrables. Le chef de projet coordonne et intègre tout le travail d’exécution en un effort cohérent.
Le chef de projet :
- Coordonne les ressources et l’équipe
- Collecte les Work Performance Data (WPD)
- Gère l’Issue Log pour suivre les problèmes identifiés
- Implémente les changements approuvés
- Utilise un work authorization system pour coordonner les activités
- Supprime les obstacles (impediments) pour l’équipe
Principaux outputs : Deliverables, Work Performance Data (WPD), Change Requests, Issue Log updates.
Ce processus capitalise et partage les connaissances du projet — à la fois pour bénéficier des leçons des projets passés et pour enrichir l’organisation avec les apprentissages du projet en cours.
Il existe deux types de connaissances à gérer :
- Explicit knowledge : connaissances factuelles documentables — processus, procédures, leçons apprises formelles. Facile à communiquer par écrit.
- Tacit knowledge : connaissances expérientielles difficiles à documenter — intuitions, savoir-faire, culture. S’acquiert par observation et compagnonnage (job shadowing).
Lessons Learned : elles ne sont pas réalisées uniquement à la fin du projet. Elles sont collectées tout au long du projet dans le Lessons Learned Register et décrivent “ce qui a fonctionné, ce qui n’a pas fonctionné, et ce qu’on ferait différemment.”
Beaucoup de candidats pensent que les Lessons Learned se font uniquement à la clôture du projet. Faux — elles sont collectées en continu tout au long du projet. Le Lessons Learned Register est à la fois un input et un output de nombreux processus.
Ce processus compare la performance réelle du projet avec le plan de management. Il couvre toutes les contraintes du projet simultanément — c’est la vision holistique de la performance.
Le chef de projet :
- Analyse les Work Performance Data pour produire des Work Performance Information (WPI)
- Identifie les écarts (variances) par rapport aux baselines
- Effectue des analyses : variance analysis, trend analysis, cost-benefit analysis, root cause analysis
- Suit les risques identifiés et détecte de nouveaux risques
- Génère des Change Requests si les écarts le justifient
- Produit des Work Performance Reports (WPR)
Les trois types de changements possibles : Corrective Action (corriger un écart existant), Preventive Action (éviter un écart anticipé), Defect Repair (corriger un livrable non conforme).
C’est le processus le plus testé à l’examen PMP sur le chapitre Integration. Il évalue, approuve, rejette ou diffère toutes les demandes de changement. L’objectif central est d’analyser l’impact de chaque changement sur toutes les contraintes du projet — pas seulement celle directement concernée.
Le processus de gestion d’un changement :
- Réception de la demande de changement (change request)
- Analyse de l’impact sur toutes les contraintes (scope, schedule, cost, quality, risk, resources, satisfaction client)
- Décision : approbation, rejet ou report (par le CCB ou le sponsor selon l’ampleur)
- Si approuvé : mise à jour du Project Management Plan et des baselines
- Implémentation dans Direct and Manage Project Work
Le Change Control Board (CCB) est l’instance décisionnelle pour les changements significatifs. Le chef de projet ne prend pas seul la décision — il analyse et présente les options.
Un changement de scope doit toujours être évalué pour son impact sur les coûts, le planning, la qualité, les risques ET la satisfaction client. Ne jamais évaluer un seul aspect. Si l’examen demande “quelle est la prochaine action après avoir estimé que le changement ajoute 2 semaines ?” — la réponse est : analyser l’impact sur toutes les autres contraintes.
Avant que le charter et le Project Management Plan soient approuvés, les modifications peuvent être faites directement sans change request formel. Après l’approbation, tout changement aux baselines ou au plan doit passer par l’Integrated Change Control. Les mises à jour de documents projet (issue log, lessons learned) ne nécessitent pas de change request si elles n’affectent pas la performance measurement baseline.
Ce processus finalise toutes les activités pour clôturer officiellement le projet ou une phase. Un projet se ferme toujours — qu’il soit terminé normalement, complété par anticipation ou annulé.
Activités de clôture :
- Confirmer que tout le travail est conforme aux exigences
- Obtenir l’acceptation formelle finale du client
- Clôturer les contrats (procurement closure)
- Effectuer la clôture financière et administrative
- Transférer le produit au client ou aux opérations
- Recueillir le feedback final du client
- Finaliser et archiver tous les documents du projet
- Documenter les lessons learned finales
- Rédiger le rapport final de performance
Validate Scope (processus 5.5) obtient l’acceptation formelle des livrables intermédiaires tout au long du projet. Close Project or Phase obtient l’acceptation finale globale du projet ou de la phase entière. Les deux processus sont nécessaires — l’un n’annule pas l’autre.
Les pièges les plus fréquents à l’examen
1. Agir sans analyser
Le réflexe de nombreux candidats est de choisir une action immédiate face à un problème. La logique PMP impose toujours d’analyser d’abord, d’identifier les options, d’évaluer les impacts sur toutes les contraintes — et ensuite seulement d’agir ou d’informer le management.
2. Modifier le projet sans passer par l’Integrated Change Control
Mettre à jour directement le planning, le scope ou le budget sans change request est une faute grave dans la logique PMP. Tout changement impactant une baseline ou un management plan doit suivre le processus formel.
3. Accepter immédiatement une demande de changement
Même si le client demande un changement, le chef de projet ne l’accepte pas directement. Il analyse l’impact sur toutes les contraintes, soumet une change request, et attend la décision du processus formel.
4. Oublier l’impact global
Un changement de scope affecte aussi le schedule, le cost, la quality, les risks et les resources. Un changement de schedule affecte le cost, le risk… La pensée intégratrice — penser toujours à l’impact global — est au cœur de l’Integration Management.
5. Confondre WPD, WPI et WPR
Work Performance Data (WPD) : données brutes collectées dans Direct and Manage Project Work (ex : % d’avancement réel, heures dépensées). Work Performance Information (WPI) : données analysées et contextualisées dans Monitor & Control (ex : écarts EVM). Work Performance Reports (WPR) : communication formatée des WPI vers les parties prenantes.
Flux des informations dans Integration Management
| Du processus | Vers le processus | Ce qui transite |
|---|---|---|
| 4.1 Develop Charter | 4.2 Develop PMP | Project Charter, Assumption Log |
| 4.2 Develop PMP | 4.3 Direct & Manage | Project Management Plan approuvé |
| 4.3 Direct & Manage | 4.5 Monitor & Control | Work Performance Data (WPD) |
| 4.3 Direct & Manage | 4.4 Manage Knowledge | Deliverables, Project Documents |
| 4.5 Monitor & Control | 4.6 Integrated Change Control | Change Requests, WPI |
| 4.6 Integrated Change Control | 4.3 Direct & Manage | Approved Change Requests |
| 4.6 Integrated Change Control | 4.2 Develop PMP | Updates aux baselines et plans |
| 4.4 Manage Knowledge | Organisation | Lessons Learned Register |
| 4.7 Close Project | Opérations / Client | Produit livré, Final Report, Lessons Learned finales |
Integration Management en approche agile et hybride
Les processus d’Integration Management s’appliquent à toutes les approches, mais leur mise en œuvre diffère :
- Project Charter : existe aussi en agile, mais avec davantage d’incertitude sur les livrables. Le Product Owner peut avoir l’autorité de gérer les changements plutôt qu’un CCB formel.
- Project Management Plan : en agile, les plans de scope, schedule et risques peuvent être intégrés dans le backlog produit et la roadmap de releases plutôt que dans des documents séparés.
- Integrated Change Control : en agile, les changements sont accueillis et gérés via la repriorisation du backlog par le Product Owner. La mécanique est différente mais l’analyse d’impact reste essentielle.
- Lessons Learned : en agile, elles sont collectées lors des iteration retrospectives à la fin de chaque sprint — intégrées naturellement dans le cycle de développement.
- Close Project : en agile, une clôture formelle a lieu à la fin de chaque release, puis à la fin du projet.
Points clés à retenir pour l’examen PMP
- Integration Management est le seul domaine présent dans les 5 groupes de processus.
- Le Project Charter autorise le projet et donne l’autorité au chef de projet — il est signé par le sponsor.
- Le Project Management Plan est plus qu’un planning — c’est l’ensemble de tous les plans subsidiaires et des trois baselines.
- Les Lessons Learned sont collectées tout au long du projet, pas seulement à la clôture.
- Tout changement à une baseline nécessite de passer par l’Integrated Change Control.
- Tout changement doit être évalué pour son impact sur TOUTES les contraintes du projet.
- WPD → WPI → WPR : données brutes → informations analysées → rapports communiqués.
- Un projet se clôture toujours, quelle que soit la façon dont il se termine.
- Validate Scope = acceptation des livrables intermédiaires. Close Project = acceptation finale globale.
- Face à une demande de changement : analyser d’abord, décider ensuite — jamais accepter immédiatement.
- En agile, la gestion des changements passe par la repriorisation du backlog par le Product Owner.
Basé sur Rita Mulcahy’s PMP® Exam Prep, 11e édition, aligné avec le PMBOK® Guide 7e édition et l’ECO en vigueur. Flowchart © Kaizen Skills Consulting.