REX #4 · Méthodo & Bonnes pratiques
Les règles d'or de la gestion de projet IT
Après 25 ans de programmes IT sur des périmètres internationaux, quatre piliers font systématiquement la différence entre un projet livré et un projet qui dérape. Gouvernance, Budget, Qualité, Planning — voici les règles d'or issues de la méthodologie PMP et de mon expérience terrain.
Par Philippe Damas
· PMP® · ITIL v3
· ~12 min de lecture
L'essentiel
Un projet IT ne dérape pas à cause de la technique. Il dérape à cause d'une gouvernance floue, d'un budget mal piloté, d'une qualité non mesurée, d'un planning non tenu et de risques mal gérés. Ces cinq piliers sont interdépendants — négliger l'un fragilise les quatre autres.
⚠️
Pilier 05
Gestion des Risques
La gouvernance, c'est la colonne vertébrale du projet. Sans structure de pilotage claire, les décisions traînent, les escalades n'arrivent pas au bon niveau et les parties prenantes s'alignent sur des informations contradictoires. La communication n'est pas un livrable optionnel — c'est un workstream à part entière.
En pratique, cela signifie définir dès le kick-off qui décide quoi, à quel niveau et avec quel délai. Une RACI claire, un rythme de Copil régulier et des escalades formalisées sont les trois fondements d'une gouvernance qui fonctionne.
Règles d'or de la gouvernance
RACI documentée et validée dès le kick-off — Chaque livrable a un Responsible, un Accountable, des Consultés et des Informés. Sans RACI, tout le monde est responsable, donc personne ne l'est.
Copil régulier avec ordre du jour structuré — Avancement, risques, décisions à prendre, actions ouvertes. Pas de Copil informatif : chaque réunion doit se terminer avec des décisions actées.
Reporting adapté au niveau d'audience — Dashboard synthétique pour le Sponsor, rapport détaillé pour le Copil technique, communication terrain pour les utilisateurs.
Registre de décisions tenu à jour — Chaque décision prise en Copil est documentée avec la date, le décideur et les impacts. C'est votre protection en cas de contestation ultérieure.
Processus d'escalade formalisé — Définir à l'avance les seuils qui déclenchent une escalade Sponsor (retard critique, dépassement budgétaire, blocage décisionnel).
« Un Sponsor mal informé est un Sponsor qui découvre les problèmes trop tard pour les résoudre. La transparence inconfortable vaut mieux que la surprise catastrophique. »
Retour terrain — Programmes IT grands comptes
Le budget d'un programme IT n'est pas une donnée figée — c'est un indicateur vivant qui doit être suivi en temps réel. La question n'est pas de savoir si le budget va évoluer, mais quand et comment le gérer de façon professionnelle.
Le Change Order (CO) est l'outil contractuel qui permet de faire valider formellement un nouveau périmètre ou un dépassement budgétaire par le Sponsor. Un CO bien préparé, avec une justification claire et un chiffrage rigoureux, est toujours mieux reçu qu'une surprise en fin de projet.
Règles d'or du suivi budgétaire
Budget baseline documenté et signé — Le budget initial (baseline) doit être formalisé et approuvé avant tout démarrage. C'est la référence de tout écart futur.
Suivi mensuel Dépensé / Engagé / Reste à faire — Le consommé seul ne suffit pas : il faut suivre ce qui est engagé (commandes en cours) et le reste à faire prévisionnel.
Provision de réserve (contingency) — Prévoir systématiquement 10 à 15% de réserve sur le budget initial pour absorber les aléas sans déclencher un Change Order à chaque surprise.
Seuils d'alerte définis à l'avance — Définir avec le Sponsor les seuils qui déclenchent une alerte formelle : en général à 80% du budget consommé, et dès qu'un écart >10% est anticipé. Un écart de +5% en fin de projet est souvent toléré selon les clients et les contrats — mais cela doit être acté explicitement dès le départ, pas découvert à la clôture.
Comment alerter et à quel moment ?
≤ 80%
Zone verte — suivi normal Reporting mensuel standard au Copil. Pas d'action spécifique requise.
80–95%
Zone orange — alerte préventive Informer le Sponsor par écrit. Présenter une projection de fin de projet et les leviers d'optimisation disponibles.
> 95%
Zone rouge — Alerte Sponsor + évaluation Change Order Évaluer en priorité le RAF (Reste À Faire) : si du RAF significatif subsiste, préparer un CO formel avec justification détaillée, impact périmètre/planning, et soumettre à validation Sponsor avant tout nouvel engagement. Si le projet est quasi terminé, le CO n'est plus pertinent — on documente la variance budgétaire finale et on l'explique en Copil de clôture.
📋
Comment faire valider un Change Order ?
Un CO doit contenir : (1) l'origine du changement — c'est le point le plus important car il détermine la responsabilité : s'agit-il d'un oubli ou d'une mauvaise maîtrise des dépenses côté IT (responsabilité du chef de projet), ou d'un nouveau besoin/cas d'usage apparu en cours de route (responsabilité du Sponsor) ? Cette distinction conditionne toute la négociation. (2) la description précise du changement de périmètre ou de la cause du dépassement, (3) le chiffrage détaillé du surcoût avec les hypothèses, (4) l'impact sur le planning, (5) les alternatives étudiées et rejetées, (6) la recommandation du chef de projet. Présentez le CO en Copil avec un temps dédié — et surtout ne le glissez jamais en AOB (Any Other Business — le fourre-tout en fin de réunion où personne n'écoute vraiment et où les décisions importantes ne sont jamais bien prises).
La qualité d'un projet IT ne se décrète pas — elle se mesure. Et pour mesurer, il faut définir des indicateurs avant le début du projet, pas après. C'est la seule façon de démontrer objectivement la valeur apportée et de détecter les dérives avant qu'elles ne deviennent des incidents.
La méthodologie PMP distingue deux types de qualité : la qualité du produit (la solution livrée est-elle conforme aux exigences ?) et la qualité du processus (le projet est-il piloté de façon rigoureuse ?). Les deux doivent être mesurées.
Exemple concret d'un projet de refonte VPN : la qualité du produit se mesure par le temps de connexion moyen, le taux d'incidents post-déploiement et la conformité aux exigences Cyber/RSSI. La qualité du processus se mesure par le respect du planning par vague, le taux de tickets traités dans les SLA et le taux de satisfaction des utilisateurs après chaque vague. Sans ces mesures définies en amont, impossible de prouver que le projet a réussi.
Avant le projet — Baseline
Temps de connexion VPN moyen
Mesurer le temps moyen de connexion sur l'ancienne solution. C'est la référence qui permettra de prouver l'amélioration.
Après le projet — Résultat
Temps de connexion VPN cible
Mesurer sur la nouvelle solution après stabilisation. L'écart prouve (ou non) la valeur du projet.
Pendant le projet — Process
Taux de tickets incidents / vague
Nombre d'incidents remontés par vague de déploiement. Un pic anormal déclenche un arrêt de la vague suivante.
Après le projet — Adoption
Taux d'adoption par site
% d'utilisateurs actifs sur la nouvelle solution 30 jours après déploiement. En dessous de 85%, investiguer.
Règles d'or de la qualité projet
Définir les KPIs avant de commencer — Sans baseline mesurée avant le projet, impossible de démontrer la valeur créée après.
Critères d'acceptance formalisés — Chaque livrable a des critères de recette clairs et objectifs, validés par le client avant la livraison.
Revue qualité à chaque jalon — Ne pas attendre la fin du projet pour mesurer : une revue qualité à chaque jalon permet de corriger en cours de route.
Leçons apprises documentées — À chaque fin de phase, documenter ce qui a bien fonctionné et ce qui doit être amélioré. C'est la matière première de la progression.
✅
Porter la performance au projet — pas seulement la livraison
Un projet livré dans les délais et le budget mais qui n'apporte pas de valeur mesurable est un échec. La qualité, c'est aussi savoir présenter au Sponsor les gains obtenus : temps économisé, incidents réduits, satisfaction utilisateur améliorée. Ces données transforment un livrable technique en succès business.
Un planning n'est pas un tableau Excel qu'on remplit pour le kick-off et qu'on oublie. C'est un outil de pilotage vivant, mis à jour en continu, qui reflète la réalité du projet à chaque instant. La méthodo PMP insiste sur la distinction entre le planning de référence (baseline) et le planning courant — les deux doivent exister et être comparés régulièrement.
Sur les projets de migration IT en particulier, le plan de migration est le document le plus critique. Il doit être co-construit avec toutes les équipes techniques, validé par le client, et inclure impérativement un plan de rollback testé pour chaque étape.
Bonnes pratiques de planification
WBS (Work Breakdown Structure) complet — Décomposer le projet en lots de travaux jusqu'au niveau des tâches estimables. Sans WBS, les estimations sont des intuitions.
Chemin critique identifié — Identifier les tâches sans marge qui, si elles glissent, font glisser toute la date de fin. Ce sont les tâches à surveiller en priorité absolue.
Jalons de validation formalisés — Chaque jalon doit avoir un critère de sortie binaire (oui/non), pas une appréciation subjective. Un jalon non validé ne passe pas.
Dépendances inter-équipes cartographiées — Les retards les plus fréquents viennent des interfaces entre équipes. Identifier et monitorer ces dépendances est essentiel.
Fenêtres de maintenance définies avec les métiers — Convenir à l'avance des créneaux d'intervention (nuits, week-ends) en évitant les périodes critiques (clôtures, audits, congés).
Plan de rollback testé pour chaque étape critique — Pas de migration sans procédure de retour arrière documentée et testée. Une migration sans rollback est un pari, pas un projet. Le rollback doit être mesuré en termes de temps. Sur une migration DC à DC réalisée sur un week-end par exemple, le rollback doit être exécutable dans la même fenêtre de maintenance — redéménager le matériel, réinstaller, recâbler, retester les services — tout doit tenir dans le week-end. Sinon il faut revoir la fenêtre et le plan avant de commencer, pas pendant.
⚠️
Le planning est un outil de communication, pas seulement de suivi
Un planning que seul le chef de projet comprend ne sert à rien. Il doit être lisible par le Sponsor (vue macro, jalons clés), par les équipes techniques (tâches détaillées, dépendances) et par les métiers (impacts et fenêtres de maintenance). Trois niveaux de lecture, un seul document de référence.
« Planifier, c'est décider à l'avance de ce qu'on fera si les choses ne se passent pas comme prévu. Un bon plan inclut toujours ses propres alternatives. »
Méthodologie PMP — De mon expérience terrain, 25 ans
La gestion des risques est le pilier le plus souvent négligé — et pourtant le plus déterminant. En méthodologie PMP, un risque est un événement incertain qui, s'il se produit, a un impact positif ou négatif sur les objectifs du projet. La gestion des risques ne consiste pas à dresser une liste exhaustive de tout ce qui pourrait mal tourner : c'est un processus continu d'identification, d'évaluation et de décision.
Sur un programme IT complexe, les risques les plus dangereux sont rarement ceux qu'on n'a pas identifiés. Ce sont ceux qu'on a identifiés, mal évalués, et dont on a différé le traitement. Un Risk Register tenu à jour et discuté à chaque Copil est l'outil de base — mais c'est la culture de l'anticipation qui fait vraiment la différence.
Règles d'or de la gestion des risques
Risk Register tenu à jour dès le kick-off — Chaque risque identifié est documenté avec sa probabilité (faible/moyenne/forte), son impact (faible/moyen/fort), son score (probabilité × impact) et son propriétaire.
4 stratégies de réponse selon le PMP — Éviter (changer le plan pour éliminer le risque), Transférer (assurance, sous-traitance), Mitiger (réduire la probabilité ou l'impact), Accepter (provisionner une réserve et surveiller).
Risk Review à chaque Copil — Passer en revue les risques ouverts, mettre à jour les scores, clôturer les risques résolus, identifier les nouveaux. Un risque non discuté en Copil est un risque ignoré.
Distinguer risque et problème — Un risque est incertain (il peut arriver). Un problème est avéré (il est arrivé). La gestion est différente : le risque se mitigue en amont, le problème se résout en urgence. Confondre les deux, c'est toujours réagir trop tard.
Provision de réserve pour risques résiduels — Les risques acceptés doivent être couverts par une réserve budgétaire et calendaire. Sans provision, un risque "accepté" est en réalité un risque ignoré.
⚠️
Le risque le plus dangereux est celui qu'on connaît mais qu'on ne traite pas
Sur tous les projets en difficulté que j'ai rencontrés, le problème n'était presque jamais un risque imprévu. C'était un risque identifié dès le début, mal évalué, dont le traitement avait été différé faute de temps ou de budget — et qui a fini par se matérialiser au pire moment. Identifier un risque sans lui affecter un propriétaire et un plan d'action, c'est se donner bonne conscience sans se protéger.
« Gérer les risques, ce n'est pas prévoir l'imprévisible. C'est décider à l'avance comment réagir à ce qu'on sait possible. »
Méthodologie PMP — De mon expérience terrain, 25 ans
PMP®
Gouvernance
Budget
Qualité
Planning
Change Order
RACI
KPI
Copil
WBS
Chemin critique
Gestion des Risques
Risk Register
Rollback
REX
Vous cherchez un chef de programme IT rigoureux ?
PMP® certifié, 25 ans de programmes IT complexes sur 5 pays. Je peux renforcer votre équipe projet ou prendre en charge la direction de programme de bout en bout.
Me contacter →