Créer un comité de pilotage efficace pour un projet SAP

Un comité de pilotage de projet SAP est le petit groupe de dirigeants qui prennent les décisions que l'équipe projet ne peut pas prendre : budget, changements de périmètre, conflits entre départements et go/no-go final. Il fonctionne quand ses membres ont une réelle autorité, se réunissent assez souvent pour décider en séance et jugent la préparation sur des preuves plutôt que sur le calendrier. Ce guide s'adresse aux sponsors et aux directeurs de programme qui mettent en place un comité, ou qui veulent redresser un comité devenu le simple public de rapports d'avancement. Il couvre ce que le comité doit trancher, sa composition selon la taille du projet, la façon dont les décisions doivent se prendre, une checklist go/no-go, et ce que RISE with SAP et les outils d'IA changent.

Je n'ai jamais vu un projet SAP réussir avec un comité de pilotage faible. C'est au comité que se prennent les décisions difficiles. Soit elles se prennent en temps réel, soit elles s'accumulent jusqu'à exploser à la bascule.

Sur un déploiement SAP, le comité se réunissait une fois par mois. L'équipe projet signalait des workflows d'approbation défaillants, des tests incomplets et une formation absente. La direction disait qu'elle allait « y réfléchir ». Elle ne l'a jamais fait. Le projet est passé en production, et la finance a passé les six mois suivants à nettoyer.

Dans une autre entreprise, le comité se réunissait chaque semaine et prenait de vraies décisions. Quand les tests ont révélé des lacunes, il a réaffecté des ressources. Quand un processus ne fonctionnait pas, il l'a corrigé. Ce projet s'est mis en production sans accroc.

L'un des comités dirigeait. L'autre se contentait d'assister à des réunions.

Si le comité ne fait que recevoir des rapports d'avancement, il est déjà en échec. Le tableau montre la différence en pratique.

Fonction	À quoi ressemble un bon comité	À quoi ressemble un comité faible
Décisions majeures	Examine le dossier et tranche sur-le-champ	« Voyons cela en dehors de la réunion » ; le sujet revient le mois suivant
Blocages	Les RH retardent les tests ? Le président appelle directement le responsable du département	Prend acte du problème et le consigne
Périmètre	Pèse chaque demande de changement par rapport au plan	Entérine ce qui est remonté avec le plus de bruit
Risque	Voit un fournisseur en difficulté et prépare une solution de repli avant que les retards ne frappent	Attend de voir si le problème se règle tout seul
Budget	Approuve 2 M$ supplémentaires pour prolonger de trois mois, parce que la perturbation coûterait plus cher	Repousse la décision au mois suivant
Go/no-go	Repousse le go-live de six semaines parce que les tests ne sont pas terminés, et tient bon	Approuve le go-live parce que la date est au calendrier

La dernière ligne est la plus importante. J'ai vu des comités repousser des go-lives alors que les équipes voulaient foncer. Le comité d'un client pharmaceutique a repoussé le go-live de six semaines parce que les tests n'étaient pas terminés. Décision difficile, mais elle lui a évité un désastre.

Trop de membres, et le comité ne peut plus décider. Trop peu, et des voix essentielles manquent.

Taille du projet	Budget et périmètre	Membres	Qui doit être dans la salle
Petit	Moins de 0,5 M$, un seul département, moins de 6 mois	3 à 5	Responsable du département, responsable informatique, représentant de la finance
Entreprise intermédiaire	De 0,5 à 5 M$, plusieurs départements, 6 à 18 mois	5 à 8	Responsables métier des départements concernés, direction informatique, finance
Grande entreprise	Plus de 5 M$, à l'échelle de l'entreprise, 18 mois ou plus	8 à 12	Dirigeants (C-level) de la finance, des RH, des opérations et de l'informatique ; chef de programme ; responsable du changement

La règle que j'applique : inclure des personnes qui ont un vrai pouvoir de décision. J'ai vu des comités échouer parce que des titres prestigieux ne pouvaient rien approuver sans en référer à quelqu'un d'autre. Si le directeur financier ne peut pas venir, envoyez quelqu'un qui a un véritable mandat pour décider, et non pour faire remonter l'information.

Le président du comité doit être le sponsor du projet, généralement un dirigeant de niveau C capable d'exiger des comptes des autres dirigeants. Un cadre intermédiaire à la présidence ne peut pas passer outre un directeur financier, et cette autorité compte quand des conflits de périmètre ou de budget surgissent.

Sur des preuves. J'ai travaillé avec un client industriel dont l'équipe informatique affirmait qu'un changement de processus ajouterait trois mois. Les métiers soutenaient que c'était « simple ». Le comité a refusé de décider avant d'avoir vu les estimations d'effort, l'analyse des dépendances et le plan de capacité. L'informatique avait raison. Le comité a eu raison parce qu'il a exigé des preuves au lieu de se ranger du côté de la voix la plus forte.

Vite. J'ai connu un client dont le comité se réunissait toutes les deux semaines mais concluait toujours par « nous en rediscuterons en dehors de la réunion ». Les sujets se sont accumulés jusqu'à six mois de retard sur le projet. Chez un autre client, le comité prenait ses décisions en séance, et son projet s'est terminé en avance et sous le budget. Les comités lents produisent des projets en retard.

Avec une autorité explicite. Les comités efficaces peuvent passer outre les responsables de département, approuver un budget non prévu et rejeter des ajouts de périmètre en cours de route. Si ces pouvoirs ne sont pas écrits et compris, le comité devient consultatif, et les comités consultatifs ne mènent pas à terme les projets SAP.

Sur le périmètre, de façon sélective. Chez l'un de mes clients, un département a soudain exigé 20 rapports supplémentaires. Le comité a demandé si chacun était nécessaire maintenant et s'il casserait le calendrier. Il en a approuvé cinq critiques et reporté le reste après le go-live. Cette décision a probablement sauvé la date de go-live.

Limitez les réunions à 60 à 90 minutes. Les principaux risques, les décisions précises à prendre, et des actions avec responsables et échéances. Pas de points techniques qui pourraient être lus avant la séance. Si le même sujet revient trois réunions de suite sans être résolu, vous avez un problème de gouvernance, pas un problème de complexité.

Des données, pas des présentations. J'ai travaillé avec un client du secteur de l'énergie qui avait construit un tableau de bord de l'exécution des tests, de la résolution des anomalies, de l'avancement de la formation et de la consommation du budget. Les réunions ont cessé de servir à comprendre où l'on en était pour servir à résoudre des problèmes.

Montrez le système au comité. Le comité d'un client pharmaceutique a déroulé un scénario de « journée type ». Il s'est rendu compte que la conception approuvée obligerait le personnel à utiliser cinq écrans différents pour un processus courant. Il a ordonné une refonte immédiate.

Prévoyez la politique. L'échec le plus courant n'est pas l'incompétence. Ce sont des départements qui protègent leur territoire et des équipes qui retardent les tests à cause des travaux de fin d'année. Sur un projet, les RH repoussaient sans cesse les tests de paie parce qu'elles étaient occupées par les tâches de fin d'année. Le comité a revu les priorités et affecté des testeurs de secours, et le projet est resté dans les temps au lieu de glisser pendant des mois.

Recourez à des contrôles indépendants aux jalons majeurs. Un client industriel a fait évaluer sa préparation par des relecteurs externes avant d'approuver le go-live. La revue a mis au jour plusieurs problèmes graves que l'équipe projet avait manqués ou minimisés. Mon guide des jalons qualité SAP montre comment structurer ces points de contrôle.

La pression du calendrier est une mauvaise base pour approuver un go-live. Avant le vote, le comité doit voir des preuves sur chacun de ces points :

1. Tests d'intégration et recette utilisateur terminés, sans anomalie critique ouverte
2. Dernière migration d'essai des données rapprochée et signée par la finance
3. Répétition de la bascule terminée dans la fenêtre prévue
4. Utilisateurs clés formés, avec support de proximité et fiches pratiques prêts
5. Préparation métier confirmée par écrit par chaque propriétaire de processus
6. Plan de retour arrière testé et validé
7. Équipe d'hypercare, circuit d'escalade et support de la première clôture en place

Si un seul point est au rouge, un comité solide dit non. Un retard de six semaines se rattrape. Un go-live raté qui perturbe l'exploitation ou la clôture financière peut mettre des mois à se stabiliser. J'ai nettoyé trop de go-lives approuvés parce que la date semblait immuable. Alimentez l'ordre du jour du comité à partir d'un registre des risques vivant pour que ces points apparaissent tôt.

RISE intègre SAP dans le modèle de gouvernance. Avec RISE with SAP, SAP gère l'infrastructure et les opérations techniques. Le document de SAP sur les rôles et responsabilités de RISE prévoit que les clients travaillent avec un SAP Cloud Architect Advisor, un Client Delivery Manager ou le centre client du cloud privé de SAP. Pour les problèmes de plateforme comme la performance, la disponibilité ou les niveaux de service, le comité a besoin d'un accès à ces interlocuteurs qui ne passe pas par le partenaire d'implémentation. Invitez-les pour les points d'ordre du jour concernés plutôt que comme membres permanents.

Une instance Clean Core se place sous le comité. Sur les programmes RISE, mettez en place une design authority qui approuve ou rejette les demandes de personnalisation au regard des principes Clean Core. Elle ne remonte au comité que lorsqu'une demande critique pour le métier est bloquée. Sans cette couche, chaque personnalisation devient un combat en comité. En on-premise, le modèle traditionnel s'applique toujours et SAP est un fournisseur, pas un participant.

1. Comité de pilotagePrésidé par le sponsor. Budget, périmètre, conflits, go/no-go
   Interlocuteurs de livraison SAPInvités pour les sujets de plateforme, sans passer par le partenaire

• Bureau de gestion de programme (PMO)Exécution au quotidien, registre des risques, coordination
• Design authority Clean CoreTranche sur les personnalisations, ne remonte que les demandes critiques bloquées

L'IA fait gagner du temps sur la paperasse. Microsoft 365 Copilot rédige les comptes rendus à partir de la réunion enregistrée. Le travail consiste alors à relire un brouillon plutôt qu'à écrire de zéro, et les décisions viennent de la transcription. Rovo d'Atlassian peut transformer des notes de réunion en entrées structurées du journal des décisions une fois le modèle construit. Les assistants basés sur Joule dans SAP Cloud ALM peuvent rédiger une première analyse d'impact pour une demande de changement de périmètre, ce qui permet au comité de décider en séance au lieu de reporter.

Laissez de côté l'analyse de sentiment pour l'instant. Certains éditeurs proposent l'analyse de sentiment des communications du programme comme donnée d'entrée du comité. Sur la plupart des programmes, c'est du théâtre : le signal est faible, les faux positifs sont fréquents et être vu en train de surveiller le sentiment a un coût politique. Ce n'est que sur de très grands programmes qu'elle permet de repérer tôt des groupes qui se désengagent. Pour la plupart des comités, ce n'est pas là qu'il faut dépenser le budget d'IA.

Quel est le rôle d'un comité de pilotage dans un projet SAP ?

Il prend les décisions que l'équipe projet ne peut pas prendre : validation du budget, changements de périmètre, escalade des ressources et go/no-go final. Il résout les conflits entre départements et tient les responsables de département à leurs engagements en matière de tests et de formation. S'il se contente de recevoir des points d'avancement, il ne fait pas son travail. La valeur tient aux décisions prises, pas aux réunions auxquelles on assiste.

Combien de personnes un comité de pilotage SAP doit-il compter ?

De trois à cinq pour un petit projet limité à un département, de cinq à huit pour une entreprise intermédiaire, de huit à douze pour un programme de grande entreprise. L'échec habituel est d'être trop nombreux : un comité de 20 personnes devient un public de présentations. Chaque membre doit avoir un réel pouvoir de décision sur quelque chose. Avec RISE, faites venir les interlocuteurs de livraison de SAP pour les sujets de plateforme plutôt que comme membres permanents.

Comment RISE with SAP change-t-il le comité de pilotage ?

SAP devient un acteur de la livraison pour l'infrastructure et les opérations techniques, si bien que le comité a besoin d'un accès direct aux interlocuteurs désignés par SAP, sans passer par le partenaire d'implémentation. Il lui faut aussi, en dessous de lui, une design authority Clean Core chargée des demandes de personnalisation, et seules les demandes critiques pour le métier qui sont bloquées lui sont remontées. En on-premise, SAP reste un fournisseur.

Quelle est la différence entre un comité de pilotage et un PMO ?

Le bureau de gestion de projet (PMO) conduit l'exécution au quotidien : tâches, registres des risques et coordination entre les chantiers. Le comité de pilotage prend les décisions que le PMO ne peut pas prendre : arbitrages budgétaires, changements de périmètre et go/no-go. Dans les grandes organisations, un comité de portefeuille se place au-dessus de plusieurs projets et répartit les ressources entre eux.

Que doit contenir l'ordre du jour d'un comité de pilotage ?

Des décisions, pas des points d'avancement. Commencez par les trois à cinq principaux risques, puis les décisions précises à valider, puis les sujets transverses à résoudre, puis les actions de la réunion précédente avec responsables et échéances. Si un point apparaît trois fois sans être résolu, escaladez la façon dont il est traité plutôt que d'en rediscuter.

Quand le comité de pilotage doit-il repousser le go-live ?

Quand les tests ne sont pas terminés, que les utilisateurs clés ne sont pas formés, que la migration des données n'est pas rapprochée, qu'une intégration critique est instable ou que le plan de retour arrière n'a pas été testé. Un retard coûte presque toujours moins cher que le nettoyage après le go-live. Un retard de six semaines se rattrape ; un go-live raté qui perturbe la chaîne logistique ou la clôture financière peut mettre des mois à se stabiliser.