Dans beaucoup d’organisations, les programmes restent pilotés comme de « gros projets » : plusieurs chefs de projet travaillent côte à côte, sans planification transverse des interdépendances et sans responsable unique pour porter l’ensemble. Une organisation peut pourtant être mature en gestion de projet et démunie face à un programme, car les deux disciplines ne mobilisent ni les mêmes outils ni les mêmes niveaux de décision.
Le scénario est classique : un programme de 30 ou 50 M€ est traité comme une collection de chantiers autonomes. Chaque chef de projet défend son périmètre, son planning et ses jalons. Les dépendances entre projets ne sont cartographiées nulle part et c’est en CODIR, six mois avant la mise en production, que les acteurs découvrent que les projets ne peuvent pas converger à la date prévue. Les dépassements budgétaires et les décalages de planning qui suivent n’ont rien d’accidentel. Ils étaient prévisibles dès le cadrage.
La gestion de programme répond à ce problème précis. Elle ne remplace pas la conduite de projet : elle la complète en coordonnant l’ensemble. Le directeur de programme (program manager ou program director en anglais) pilote les interdépendances, arbitre les conflits de ressources, maintient la lisibilité budgétaire consolidée et porte une responsabilité que les chefs de projet n’ont pas : livrer le bénéfice métier qui justifie l’investissement, pas seulement les livrables techniques.
Programme, projet, portefeuille : une distinction qui change la gouvernance
Définition d’un programme
Cette définition, alignée sur The Standard for Program Management du PMI (Project Management Institute, 5e édition, 2024), pointe un aspect souvent mal compris : un programme se juge moins à ses livrables techniques qu’aux bénéfices métier (croissance du CA, amélioration de l’expérience client, réduction des coûts opérationnels, mise en conformité réglementaire) qui nécessitent la convergence de plusieurs chantiers distincts, portés par des acteurs différents au sein de l’entreprise.
Par exemple, un programme de transformation e-commerce B2B/B2C dans un groupe de distribution pourra regrouper :
- Un projet de refonte du CMS et du front-end.
- Un projet d’intégration ERP / OMS (Order Management System).
- Un projet de mise en place d’une Customer Data Platform (CDP).
- Un chantier de conduite du changement auprès des équipes commerciales.
- Un volet cybersécurité et conformité RGPD.
Chacun de ces projets a son propre chef de projet. Mais c’est leur convergence coordonnée qui produit le bénéfice stratégique visé : une hausse des ventes en ligne et une expérience client unifiée, que la seule mise en service de la plateforme ne garantit pas.
Ce que la gestion de programme n’est pas
La confusion la plus courante est de traiter un programme comme un grand projet.
Un projet produit un livrable unique dans un périmètre, un budget et un délai définis. Le chef de projet arbitre entre coût, délai, qualité et périmètre, selon des modalités qui diffèrent entre approche prédictive et approche agile. Il est responsable de ce qui sort de son projet, pas des bénéfices obtenus côté métier après la mise en production.
Un programme regroupe plusieurs projets liés par un objectif stratégique commun. Le directeur de programme pilote les interdépendances, les bénéfices et les risques transverses. Sa responsabilité première est de démontrer que l’investissement produit le retour attendu, et pas seulement de franchir les jalons. Les cadres de référence sont le Standard for Program Management (PMI), MSP (PeopleCert, ex-Axelos) et, dans les contextes agiles, SAFe.
Un portefeuille est l’ensemble des programmes, projets et activités d’une organisation, arbitrés collectivement pour optimiser les investissements. La gestion de portefeuille projets est l’outil par lequel la direction générale ou la DSI traduit sa stratégie en feuille de route : quelles initiatives lancer, poursuivre, réorienter ou arrêter, au regard de la valeur attendue, des ressources disponibles et de l’équilibre entre BUILD et RUN.
En pratique : le projet livre un résultat, le programme démontre un bénéfice, le portefeuille arbitre l’allocation des ressources entre toutes les initiatives, au service de la stratégie et de la roadmap. Confondre ces trois niveaux, c’est piloter à la mauvaise altitude.

Le directeur de programme : chef d’orchestre de la complexité
Un rôle de leadership stratégique
Le directeur de programme est le pivot du dispositif. Son rôle dépasse largement la coordination de plannings : il porte la vision stratégique du programme et s’assure que chaque projet contribue aux bénéfices attendus. Ses responsabilités couvrent :
- Cadrage stratégique : formaliser le business case, définir les objectifs, le périmètre et les KPI.
- Gouvernance : concevoir et animer les comités, les rituels d’arbitrage et les circuits de décision.
- Pilotage des interdépendances : cartographier et gérer les dépendances techniques, fonctionnelles, organisationnelles et contractuelles.
- Gestion des parties prenantes : maintenir l’engagement des sponsors, faciliter les arbitrages entre directions métier.
- Pilotage budgétaire : suivre le consommé, l’engagé, le prévisionnel (forecast) et l’atterrissage (EAC, Estimate at Completion), identifier les dérives et proposer des plans d’action.
- Management des risques transverses : risques d’architecture, de dépendance fournisseur, réglementaires, de capacité.
- Pilotage par la valeur : s’assurer que le programme produit les bénéfices métier qui justifient l’investissement.
Directeur de programme, chef de projet, PMO : qui fait quoi ?
Le chef de projet est responsable de la livraison d’un projet spécifique : périmètre, coût, délai, qualité. En contexte agile, une partie de ces responsabilités est partagée avec le Product Owner (valeur et priorisation du backlog) et le Scrum Master (fonctionnement de l’équipe).
Le directeur de programme est responsable des bénéfices stratégiques du programme. Il coordonne les chefs de projet, arbitre les conflits de ressources et porte la responsabilité du budget et du planning consolidés.
Le PMO (Project Management Office) recouvre des réalités différentes selon son rattachement. Un PMO d’entreprise, souvent rattaché à la DSI ou à la direction générale, définit les standards et consolide la vision du portefeuille sans descendre dans l’opérationnel. Le PMO de programme, dont il est question ici, est une équipe au service du directeur de programme et des chefs de projet : planning et budget consolidés, suivi des risques et des décisions, reporting, assurance qualité. Il éclaire la décision plus qu’il ne la prend, même si certains PMO dits directifs disposent d’un pouvoir d’arbitrage. Dans SAFe 6.0, cette fonction devient le Value Management Office (VMO), centré sur la mesure du flux de valeur.
Dans les organisations matures, ces trois rôles coexistent. Dans les autres, le directeur de programme cumule souvent les casquettes, ce qui génère des risques de surcharge et de perte de hauteur stratégique. C’est un signal d’alerte en soi : quand le directeur de programme passe plus de temps à consolider des plannings qu’à piloter les bénéfices, le programme a déjà un problème de gouvernance.
Les piliers d’une gestion de programme efficace
Cadrage et gouvernance : les fondations
Sans business case solide et sans gouvernance claire, le programme démarre sans cap. La phase de cadrage est la plus critique : c’est elle qui définit la vision du programme, la cartographie des projets connexes et de leurs interdépendances, le budget prévisionnel, les jalons structurants, l’analyse des risques majeurs, la roadmap macro et la gouvernance cible. Négliger cette planification initiale, c’est accepter de piloter à vue un investissement majeur pour l’organisation.
La gouvernance s’articule généralement sur trois niveaux :
- COPIL (trimestriel) : sponsors exécutifs, orientations majeures, go/no-go.
- Comité programme (mensuel) : directeur de programme, chefs de projet et PMO, risques transverses, arbitrages opérationnels.
- Comités de projet : instances propres à chaque projet, qui remontent les sujets nécessitant un arbitrage transverse.
Le piège classique : multiplier les comités sans clarifier les délégations. Un bon programme réduit le nombre d’instances en augmentant la qualité de chacune.
Pilotage des interdépendances : le cœur du sujet
Les interdépendances entre projets sont l’une des principales causes de dérive des programmes. Elles se manifestent à tous les niveaux : techniques (une migration conditionne les tests d’intégration), fonctionnelles (les processus cibles impactent les spécifications ERP), organisationnelles (une équipe partagée entre trois projets) ou contractuelles (le livrable d’un intégrateur A est un prérequis pour l’intégrateur B).
Le directeur de programme doit cartographier ces dépendances (matrice des dépendances, tableau de bord programme, carte des dépendances) et les faire vivre en continu. Dans les environnements agiles à l’échelle (SAFe), le PI Planning est un rituel clé pour les rendre visibles. En méthode agile comme en cycle en V, le principe reste le même : rendre les dépendances explicites, les suivre avec discipline et anticiper les blocages. Les bonnes pratiques en la matière passent par une revue hebdomadaire des dépendances critiques avec les parties prenantes concernées.
Pilotage budgétaire : consommé, engagé, prévision et atterrissage
Le pilotage budgétaire d’un programme ne se résume pas à agréger les budgets des projets. Il requiert une lecture consolidée avec les indicateurs suivants :
- Budget initial (BAC, Budget at Completion),
- Consommé (AC, Actual Cost),
- Engagé (commitments),
- Reste à faire (ETC, Estimate to Complete),
- Atterrissage (EAC, Estimate at Completion)
- Ecart à terminaison (VAC, Variance at Completion).
Le cycle de pilotage fonctionne sur un rythme mensuel : actualisation de la prévision par chaque chef de projet, consolidation par le PMO, analyse des écarts par le PMO avec le directeur de programme, présentation en comité avec recommandations.
La capacité à transformer un tableau Excel en un récit budgétaire clair (« on est en dérive de X % sur tel lot, causée par Y, voici le plan d’action pour revenir à Z ») est ce qui distingue un directeur de programme expérimenté d’un coordinateur. Les directions métiers et SI veulent comprendre où elles en sont et ce qu’il faut décider.
Conduite du changement : le facteur humain
Un programme de transformation ne réussit que si les utilisateurs s’approprient les changements. La conduite du changement est un chantier structurant du programme, avec ses propres ressources et indicateurs : analyse d’impact par population, plan de communication cadencé auprès de toutes les parties prenantes, plan de formation par phase de déploiement, et dispositif de support post-déploiement (hyper-care). La communication doit couvrir l’ensemble des acteurs du programme, pas seulement les utilisateurs finaux.
Trop souvent, la conduite du changement est traitée comme un sous-projet périphérique, lancé six mois trop tard, avec un budget résiduel. Il faut au contraire l’intégrer dès la phase de cadrage, au même niveau que la planification technique ou le pilotage budgétaire.
Réalisation des bénéfices : mesurer ce que le programme apporte
Les bénéfices ne se constatent pas d’eux-mêmes en fin de programme. Ils se préparent dès le cadrage, avec une carte des bénéfices qui relie chaque projet aux résultats métier attendus, et un registre qui précise pour chaque bénéfice son indicateur, sa valeur de référence, sa cible et son propriétaire côté métier. Un point est souvent oublié : la plupart des bénéfices se matérialisent après la clôture des projets, une fois les nouveaux processus adoptés. La transition vers les opérations, puis la clôture formelle du programme avec un bilan des bénéfices obtenus, font donc partie intégrante du pilotage.
Méthodes, référentiels et outils de pilotage
Les principaux cadres de référence
Plusieurs référentiels structurent la gestion de programme. Le choix dépend du contexte, pas d’un effet de mode :
- Standard for Program Management (PMI) : dans sa 5e édition (2024), huit principes et six domaines de performance (alignement stratégique, gestion des bénéfices, engagement des parties prenantes, cadre de gouvernance, collaboration, gestion du cycle de vie). Adapté aux environnements structurés et réglementés. Certification associée : PgMP.
- MSP, Managing Successful Programmes (PeopleCert, ex-Axelos) : dans sa 5e édition (2020), sept principes, sept thèmes et sept processus. Accent fort sur la réalisation des bénéfices et la gestion du changement organisationnel. Le modèle opérationnel cible (Target Operating Model, anciennement Blueprint) est un outil d’alignement stratégique.
- SAFe (Scaled Agile Framework) : le pilotage de programme s’exerce à travers l’Agile Release Train (ART). Le rôle du directeur de programme s’y répartit entre le Release Train Engineer (RTE), qui facilite le train, le Product Management, qui porte la priorisation, et les Business Owners, garants de la valeur métier. Adapté aux organisations ayant déjà une maturité agile.
- Approche hybride : souvent la plus réaliste dans les grandes organisations, combinant cycle en V pour l’infrastructure et l’intégration avec l’agilité de Scrum ou SAFe pour les développements applicatifs.
Le critère de choix est l’adéquation au contexte (maturité des équipes, complexité, culture, exigences de conformité), pas la modernité du framework. Un SAFe mal implanté dans une organisation qui n’a pas la maturité agile suffisante fera plus de dégâts qu’un cycle en V bien piloté.
Quels outils PPM pour piloter un programme ?
Un programme de grande envergure nécessite un outillage structuré couvrant : consolidation des plannings, suivi budgétaire, gestion des risques, pilotage des dépendances et reporting. Le marché des outils PPM propose plusieurs catégories :
- Logiciels PPM intégrés : Planisware, Planview, Clarity, Triskell, ServiceNow SPM. Ces logiciels couvrent portefeuille, programme, projet, ressources et finances dans un seul environnement.
- Solutions agilité à l’échelle : Jira Align, Rally, Azure DevOps, Targetprocess. Conçues pour SAFe, Scrum@Scale ou LeSS. Le choix d’une méthode agile à l’échelle conditionne souvent le choix du logiciel.
- Solutions collaboratives : Monday.com, Smartsheet, Asana, Wrike, Microsoft Planner. Flexibles, adaptées aux programmes de taille intermédiaire où les équipes ont besoin de travailler ensemble sans courbe d’apprentissage longue.
- Solutions BI : Power BI, Tableau, Looker. En complément, pour des tableaux de bord sur-mesure orientés directions métier et SI.
Principes de bon sens : l’outil reflète les processus (qui doivent d’abord être clairs, partagés et appliqués), la simplicité d’adoption est un critère critique, l’intégration avec l’écosystème existant (SAP, Jira, Teams) évite les doubles saisies, et le coût total de possession (TCO) dépasse largement le prix de la licence. Un logiciel mal paramétré génère plus de travail qu’il n’en économise.
Facteurs clés de succès et signaux d’alerte
Bonnes pratiques et facteurs de réussite
- Un sponsorship exécutif engagé. Le sponsor (souvent un directeur de BU ou le DSI) doit être disponible pour arbitrer, porter les messages difficiles en comité de direction et débloquer les crises. Sans cela, le directeur de programme se retrouve seul face aux résistances organisationnelles.
- Une cellule PMO programme structurée. Plannings consolidés, tableaux de bord budgétaires, registre de risques, suivi des décisions : le PMO conditionne la capacité du directeur de programme à piloter avec hauteur.
- Une culture de la transparence. Les programmes qui réussissent sont ceux où les mauvaises nouvelles remontent vite, où les écarts sont traités dès qu’ils apparaissent, et où les équipes ne sont pas pénalisées pour avoir signalé un problème.
- Des équipes compétentes et stables. Un programme qui change de chefs de projet tous les six mois aura beaucoup moins de chance de réussir. La stabilité est un facteur sous-estimé, en particulier quand le recours à des prestataires rend la gestion de la connaissance critique.
- Un pilotage par la valeur. Intégrer des indicateurs de bénéfices métier (adoption, impact CA, réduction des coûts, NPS) dès le pilotage courant permet de détecter les dérives de valeur avant qu’elles ne deviennent irréversibles.
Reconnaître un programme en difficulté
Certains signaux ne trompent pas :
- Les jalons se décalent de manière répétée, avec des justifications changeantes. Quand les causes varient mais que le résultat est toujours le même, le problème est structurel.
- Le budget dérive sans explication claire. La prévision n’est pas fiable. L’atterrissage (EAC) est recalculé chaque mois.
- Les dépendances explosent : le planning consolidé n’est plus à jour.
- La gouvernance est devenue un rituel sans décision : comités de trois heures, « points d’attention » mais aucun arbitrage.
- Le directeur de programme est submergé par l’opérationnel au lieu de piloter la stratégie.
- Les sponsors se désengagent.
Face à un tel constat, les leviers les plus efficaces sont : un audit flash (2-4 semaines) pour répondre à « où en est-on réellement ? », la clarification de la gouvernance et des rôles entre les différents acteurs, la reprise du planning consolidé et des jalons structurants sur des bases réalistes, la limitation du WIP (Work in Progress) pour réduire la surcharge, et si nécessaire, une revue du périmètre pour préserver les objectifs essentiels sur le long terme.
En synthèse
La gestion de programme est une discipline de pilotage stratégique. Elle transforme des investissements IT importants en bénéfices métier mesurables, à condition d’être exercée comme telle.
Dans un contexte où les programmes sont de plus en plus complexes (multi-pays, multi-intégrateurs, hybrides agile/cycle en V), le directeur de programme n’est plus un coordinateur. C’est le garant de l’alignement entre la stratégie et l’exécution. La différence entre un programme qui dérive et un programme qui délivre tient rarement à l’outil ou au framework. Elle tient à la qualité de la gouvernance, à la discipline du pilotage budgétaire, et à la capacité du directeur de programme à dire non quand le périmètre dérape.
Si vos programmes souffrent de dérives récurrentes, de gouvernance floue ou d’un manque de visibilité sur les bénéfices livrés, il est peut-être temps de repenser votre approche. Découvrez notre offre d’accompagnement en direction de programme et en structuration de gouvernance, ou contactez-nous pour un diagnostic personnalisé.
FAQ – Gestion de programme : ce qu’il faut savoir
Comment mesurer la réussite d’un programme ?
Au-delà du respect du budget et du calendrier, un programme se mesure aux bénéfices métier obtenus : adoption des nouveaux outils et processus, impact sur le chiffre d’affaires ou les coûts, satisfaction client. Ces indicateurs doivent être définis dès le cadrage, avec une valeur de référence et un propriétaire métier, puis suivis au-delà de la mise en production.
Quelles certifications pour devenir directeur de programme ?
Les plus reconnues : PgMP (PMI), MSP Practitioner (PeopleCert), SAFe RTE ou SAFe SPC pour les contextes agiles à l’échelle. Le PMP n’est pas un prérequis formel du PgMP, mais il dispense de justifier l’expérience en gestion de projet exigée.
Quels sont les principaux risques d’un programme IT ?
Risques d’architecture et d’intégration, dépendance fournisseur, résistance au changement, dérive budgétaire et capacité (ressources clés indisponibles). Les bonnes pratiques imposent de les anticiper dès la phase de planification, de les qualifier (probabilité et impact) et de les traiter avant qu’ils ne se matérialisent. Chaque entreprise doit adapter cette démarche à son contexte et à sa maturité en gestion de projets.
Quand faut-il une gestion de programme plutôt qu’une gestion de projet ?
Dès que l’initiative dépasse un projet unique : plusieurs projets interdépendants, plusieurs intégrateurs ou fournisseurs à coordonner, enjeux transverses multi-directions, bénéfices stratégiques moyen/long terme.
Quel est le rôle du PMO dans un programme ?
Le PMO fournit les standards, les outils de reporting, le suivi budgétaire consolidé et l’assurance qualité. Il produit l’information nécessaire pour que le directeur de programme et les comités puissent décider en connaissance de cause.
Sources : PMI, The Standard for Program Management, 5e édition (2024). PeopleCert (ex-Axelos), Managing Successful Programmes (MSP), 5e édition. Scaled Agile, SAFe 6.0.





