Équipe projet SAP : rôles et responsabilités essentiels

Une mise en œuvre SAP exige huit rôles, chacun avec un responsable nommé et dédié : sponsor exécutif, chef de projet, responsables fonctionnels, responsable informatique, responsable de la migration des données, responsable de la conduite du changement, partenaire de mise en œuvre et conseiller de programme indépendant. RISE with SAP ajoute les interlocuteurs de livraison de SAP et rend explicite la responsabilité du Clean Core. Ce guide s'adresse aux sponsors et aux directeurs de programme qui constituent une équipe ou en redressent une. Il couvre ce que chaque rôle possède, ce qui casse sans lui, les effectifs selon la taille de l'entreprise et la façon de constituer le centre d'excellence (CoE) avant le go-live. Commencez par vérifier lequel des huit rôles est tenu par quelqu'un qui a par ailleurs son poste habituel. C'est votre plus gros risque.

J'ai travaillé avec des dizaines d'équipes SAP au fil des ans. J'ai vu des projets bien financés, avec des prestataires expérimentés, échouer parce que des rôles clés manquaient ou étaient répartis entre des personnes qui avaient d'autres missions. J'ai aussi vu des projets sous-financés réussir parce que les bonnes personnes étaient dans la pièce, pleinement engagées, avec des responsabilités claires.

Un distributeur mondial avec lequel j'ai travaillé avait du budget, le soutien de sa direction et SAP comme ERP choisi. Mais son équipe de mise en œuvre était un désastre. Des rôles clés manquaient. Personne n'était responsable des décisions critiques. La communication partait dans tous les sens sans jamais aboutir. Les échéances ont glissé, les coûts ont grimpé et la confiance s'est effondrée.

Toute mise en œuvre SAP a besoin que ces rôles soient pourvus. L'intitulé compte moins que la responsabilité.

1. Sponsor exécutifDécisions, financement, escalade
   Conseiller programme ERPSupervision indépendante, risques, alignement de la direction
2. Chef de projetCalendrier, budget, coordination

• Responsables fonctionnels et experts métierConception des processus, paramétrage des modules
• Responsable informatique et son équipeIntégration, développement, sécurité
• Responsable migration des donnéesQualité des données, séquencement des chargements, cutover
• Responsable conduite du changementFormation, adoption, communication
• Partenaire de mise en œuvreArchitecture, conception des intégrations, livraison

Rôle	Responsabilité principale	Ce qui casse sans lui
Sponsor exécutif	Décisions stratégiques, financement, pouvoir d'escalade	Dérive, conflits de périmètre, personne pour trancher
Chef de projet	Calendrier, budget, coordination entre équipes	Retards, blocages non résolus, dépassements de coûts
Responsables fonctionnels et experts métier	Conception des processus métier, paramétrage des modules	Mauvais paramétrage, contournements après le go-live
Responsable informatique et son équipe	Intégration, développement, sécurité, performance	Dette technique, interfaces cassées, instabilité
Responsable migration des données	Qualité des données, séquencement des chargements, exactitude du cutover	Données inutilisables, go-live raté, des mois de nettoyage
Responsable conduite du changement	Formation, adoption, communication	Résistance des utilisateurs, tableurs parallèles
Partenaire de mise en œuvre	Architecture, conception des intégrations, livraison	Surconstruction, échecs d'intégration
Conseiller programme ERP	Supervision indépendante, risques, alignement de la direction	Décisions prises en vase clos, erreurs évitables

Sponsor exécutif

Le sponsor n'est pas un nom sur une présentation de comité de pilotage. Il prend les décisions que personne d'autre ne peut prendre : budget, changements de périmètre, engagements de ressources entre départements. Quand le rôle est cérémoniel, les projets dérivent.

J'ai travaillé avec une entreprise qui avait fait l'impasse sur ce rôle. Le projet a dérivé. Aucune décision, aucun progrès, de l'argent jeté par les fenêtres.

Les sponsors efficaces restent jusqu'à la fin de l'hypercare. Ils assistent aux comités de pilotage mensuels après le go-live et prennent les petites décisions qui débloquent des sujets coincés depuis des semaines. Mon guide pour mettre en place un comité de pilotage SAP explique comment structurer cette instance.

Chef de projet

Le chef de projet gère le quotidien : calendrier, registre des risques, coordination, points d'avancement. Sur un grand programme SAP, c'est un poste à plein temps pour quelqu'un qui l'a déjà fait.

J'ai vu un client perdre son développeur principal en pleine mise en œuvre. Tout le projet s'est arrêté pendant des semaines, le temps de lui trouver un remplaçant.

Le problème inverse est tout aussi destructeur. J'ai travaillé avec une entreprise qui comptait plus de 30 personnes dans son équipe. Personne ne savait qui décidait. Un changement simple demandait cinq réunions. Le calendrier est passé de 12 à 18 mois à cause de la seule charge de communication.

Responsables fonctionnels et experts métier

Ces personnes traduisent le fonctionnement de l'entreprise en paramétrage SAP. Elles doivent connaître le métier assez bien pour remettre en cause les mauvais processus, et SAP assez bien pour savoir ce qui est possible.

J'ai travaillé avec un client industriel dont l'équipe a excellé parce que ses responsables fonctionnels avaient passé du temps en atelier avant de concevoir les processus.

Des experts métier à moitié engagés laissent toujours des trous. Soit le projet a leur attention, soit il a leur nom sur une feuille de validation. Ce n'est pas la même chose.

Responsable informatique et son équipe

L'équipe informatique est responsable du socle technique : développement, Basis, sécurité, intégration et performance. Sur S/4HANA, elle porte aussi la discipline Clean Core, qui consiste à garder le code spécifique hors du cœur.

L'intégration est ce que la plupart des équipes sous-estiment. Chaque connexion à un système externe doit être conçue, construite, testée et avoir un responsable. Les interfaces cassent en UAT quand personne n'a cartographié les flux de données. Mettez l'informatique dans les ateliers de blueprint, pas après les décisions.

Responsable migration des données

Ce rôle est attribué tard et doté de trop peu de moyens. Quand les problèmes de données apparaissent, le programme est déjà sous pression de calendrier.

Un client pensait pouvoir se passer du nettoyage des données. Grosse erreur. Son système est resté inutilisable pendant des mois. Nettoyer les données sur un système en production coûte plus cher qu'un vrai nettoyage en amont.

Un responsable de migration dédié effectue des réconciliations à chaque chargement, ce qui permet de faire apparaître les problèmes structurels avant le go-live. Cela n'arrive pas quand le rôle est tenu par quelqu'un qui a trois autres chantiers. Mon article sur les raisons de l'échec des migrations de données SAP en détaille la méthode.

Responsable conduite du changement

C'est le rôle le plus constamment sous-doté. J'ai vu des systèmes à plusieurs millions de dollars rester inutilisés parce que personne ne voulait changer sa façon de travailler.

J'ai vu une mise en œuvre techniquement parfaite échouer parce que les utilisateurs la détestaient. Le paramétrage était correct et la conception des processus solide. Mais les personnes qui s'en servaient tous les jours n'avaient pas été associées à la conception. Elles ne comprenaient pas pourquoi les choses avaient changé et continuaient d'utiliser leurs anciens fichiers Excel.

Un client de la distribution a réussi parce qu'il a écouté les inquiétudes de ses caissiers face au nouveau système et a ajusté son approche.

Le minimum pour un programme d'entreprise est de deux personnes dédiées à la conduite du changement. Une seule personne ne peut pas couvrir en même temps la conception de la formation, la communication, la gestion des résistances et le suivi de l'adoption.

Conseiller programme ERP

Un conseiller indépendant n'est pas le partenaire de mise en œuvre. Sa mission est la supervision et la correction de trajectoire : vérifier que la direction a encore du sens, repérer les risques que l'équipe de livraison est trop proche pour voir, et combler l'écart entre ce que les dirigeants croient qu'il se passe et ce qui se passe vraiment.

J'ai tenu ce rôle pour des clients dotés de bonnes équipes de livraison mais sans voix indépendante. J'ai travaillé avec un client industriel qui a failli déployer les mauvais modules parce que personne n'avait relié sa stratégie de croissance à sa feuille de route SAP.

Repérer les problèmes tôt en est l'autre moitié. J'ai un jour identifié un manque de compétences critique dans l'équipe données d'un client trois mois avant qu'il ne retarde le go-live. Nous l'avons corrigé avant qu'il ne devienne une crise.

Le modèle à huit rôles tient toujours. Trois éléments sont à y intégrer en 2026.

Les interlocuteurs de livraison de SAP sur RISE

Sur RISE with SAP en cloud privé, SAP exploite l'infrastructure et les opérations techniques. Son document sur les rôles et responsabilités prévoit que les clients conviennent des services avec un SAP Cloud Architect Advisor, un Client Delivery Manager ou l'équipe du centre client cloud privé de SAP. Inscrivez les personnes que SAP désigne au tableau de l'équipe, à côté de l'équipe du partenaire, et nommez de votre côté la personne qui porte cette relation. Sur site, SAP est un éditeur de logiciels et cela ne s'applique pas.

Responsabilité du Clean Core et des extensions

Sur S/4HANA Cloud Public Edition, le Clean Core est imposé par conception : les extensions passent par des API publiées, des outils pour key users ou SAP BTP. En cloud privé et sur site, les modifications restent possibles, mais chacune complique les mises à niveau. Quelqu'un doit être responsable de cette frontière.

Sur les grands programmes, c'est un architecte Clean Core ou un responsable des extensions BTP dédié, rattaché à l'architecte de solution. Sur les programmes de taille intermédiaire, l'architecte de solution l'absorbe en général, mais la responsabilité doit être écrite noir sur blanc. Quand vous évaluez des partenaires, demandez combien d'extensions BTP ils ont livrées et demandez à voir des exemples.

L'IA change la productivité, pas la responsabilité

SAP Joule for Consultants (en disponibilité générale depuis 2025) répond aux questions de paramétrage à partir de la base de connaissances de SAP et explique le code ABAP. SAP Build Code génère du code d'extension Java et JavaScript sur SAP BTP. Microsoft Copilot rédige les notes de comité de pilotage et les rapports d'avancement.

Les gains se voient sur les rôles très orientés flux de travail, comme l'analyse des exigences, le reporting d'avancement et le développement spécifique, et seulement quand les gens utilisent les outils de façon régulière. Considérez tout chiffre de productivité qu'on vous cite comme une affirmation à vérifier sur votre propre programme.

L'équipe est un peu plus petite que ce que le même périmètre exigeait avant ces outils, mais pas de façon spectaculaire. Écrivez les outils dans les définitions de rôle plutôt que de les traiter comme une activité annexe. L'IA rédige plus vite. Les humains restent responsables de ce que dit le brouillon.

Le tableau montre le dimensionnement type de chaque rôle selon l'échelle de l'entreprise. Prenez-le comme point de départ et ajustez selon le périmètre et la géographie. Pour la même question hors SAP, consultez mon guide de l'équipe de mise en œuvre ERP.

Rôle	Petite entreprise	Taille intermédiaire	Grande entreprise
Sponsor exécutif	Directeur senior	DSI ou directeur financier	Direction générale avec comité de pilotage
Chef de projet	1 à plein temps	1 à 2 à plein temps	Directeur de programme plus chefs de projet par chantier
Responsables fonctionnels	1 à 2 par module	Un dédié par module	Plusieurs par module
Équipe informatique	2 à 3 (partagés)	4 à 6 (dédiés)	8 spécialistes ou plus
Migration des données	1 responsable	1 responsable plus des analystes	Chantier dédié
Conduite du changement	1 au minimum	2 au minimum	3 à 5 dédiés
Responsable Clean Core ou extensions BTP	Architecte de solution	Architecte de solution	Rôle dédié
Contacts SAP (RISE)	Un contact nommé	Un contact nommé	Contacts nommés avec revues trimestrielles
Partenaire de mise en œuvre	5 à 10 consultants	15 à 25 consultants	30 ou plus avec un directeur de programme

Les compétences techniques permettent de construire le système. L'intelligence émotionnelle décide si les gens s'en servent.

J'ai travaillé avec une entreprise industrielle dont le responsable d'entrepôt souriait en réunion mais sapait le projet en coulisses. Un responsable de la conduite du changement perspicace a repéré les signes tôt et en a fait un défenseur du projet. Le découvrir au go-live aurait été bien plus difficile à rattraper.

Le chef de projet d'un client était brillant sur le plan technique, mais incapable d'adapter son message. Un directeur financier n'a pas besoin de la même communication que le personnel d'entrepôt. Résultat : une faible adhésion dans toute l'organisation et un go-live pénible.

La réponse à la question « collaborateurs ou consultants ? » est presque toujours : les deux.

Les collaborateurs connaissent l'entreprise : les processus, la politique interne et les contournements que personne ne documente. J'ai travaillé avec une entreprise industrielle dont les collaborateurs ont repéré des problèmes de mise en œuvre que les consultants extérieurs avaient complètement manqués. Ces observations lui ont évité un paramétrage d'entrepôt désastreux.

Les collaborateurs manquent souvent d'expérience de mise en œuvre. Un client de la distribution avait insisté pour une équipe entièrement interne. Six mois plus tard, il avait pris un retard irrattrapable parce qu'il apprenait SAP en le déployant.

Les consultants reconnaissent les schémas déjà vus ailleurs. J'ai fait venir un consultant chez un client : il a immédiatement identifié une approche de migration de données qui aurait fait échouer son go-live.

Le risque avec les consultants, c'est le transfert de connaissances. Si personne en interne n'apprend le système, les honoraires de conseil continuent bien après le lancement.

Le modèle qui fonctionne : les binômes de doublure. Un client de l'industrie pharmaceutique a donné à chaque consultant un homologue interne qui sera responsable de ce domaine après le go-live. Le consultant livre, l'homologue apprend, et le savoir reste. Autour de ce modèle, six pratiques font la différence :

1. Constituez l'équipe avant de choisir le logiciel. Un client a acheté des modules que son équipe ne savait pas maintenir, et six mois de chaos ont suivi.
2. Dédiez les gens à plein temps. À temps partiel, le travail habituel gagne quand la pression arrive. J'ai vu un paramétrage critique attendre des semaines parce que quelqu'un était trop occupé.
3. Regroupez les équipes au même endroit quand c'est possible. Un client industriel a gagné des semaines d'allers-retours en installant son équipe dans la même salle trois jours par semaine.
4. Définissez tôt les circuits d'escalade. Un client de la distribution avait un document d'une page montrant exactement comment les décisions remontaient la chaîne. Il lui a évité d'innombrables retards.
5. Consignez les décisions avec leur justification. J'ai travaillé avec une entreprise qui notait ce qu'elle décidait et pourquoi. Cela a évité des discussions sans fin à l'arrivée de nouveaux dirigeants en cours de projet.
6. Marquez les jalons en chemin. Un client industriel organisait des événements mensuels de reconnaissance. Une petite chose, mais elle a maintenu le moral pendant une mise en œuvre éprouvante de 18 mois.

L'erreur que font les entreprises après le go-live est de dissoudre l'équipe de mise en œuvre. C'est précisément le moment où le CoE doit reprendre les évolutions, les mises à niveau, la gouvernance, la formation des nouveaux utilisateurs et l'alignement du paramétrage sur le fonctionnement réel de l'entreprise.

Prévoyez-le pendant la mise en œuvre. J'ai eu un client industriel qui a ignoré ce conseil. Trois mois après le go-live, ses principaux experts en paramétrage sont partis. Personne ne savait maintenir ce qui avait été construit, et le système s'est mis à se dégrader aussitôt.

Voici les rôles du CoE à prévoir dès les premiers mois de la mise en œuvre.

Rôle du CoE	Responsabilité principale
Directeur du CoE	Stratégie SAP, alignement sur les objectifs métier, fonctionnement du CoE
Architecte de solution	Architecture, conception des intégrations, gouvernance Clean Core
Responsable Clean Core ou extensions BTP	Catalogue des extensions, analyse d'impact des mises à niveau
Consultants fonctionnels	Optimisation des modules, amélioration des processus
Consultants techniques	Développement, Basis, performance, sécurité
Responsable changement et formation	Adoption, formation, montée en compétences
Responsable gouvernance des données	Qualité et standards des données de base
Responsable intégration	Middleware, API, flux de données entre systèmes
Responsable support	Résolution des incidents, amélioration continue
Responsable de la relation SAP (RISE)	Escalades vers SAP, revues de service, alignement sur la feuille de route

Une entreprise pharmaceutique a désigné des propriétaires de module, qui devaient approuver tout changement susceptible d'affecter leur domaine. Cette gouvernance a évité les changements non coordonnés qui rendent généralement les systèmes pénibles à utiliser au bout de deux ou trois ans.

Un client a investi 10 % de son budget de CoE dans la formation continue. Trois ans plus tard, il déployait des nouveautés que ses concurrents ne pouvaient pas approcher. Voilà à quoi ressemble un CoE qui fonctionne.

Pourquoi les équipes de mise en œuvre SAP échouent-elles alors que le plan semble solide ?

Le plus souvent parce que le plan couvre la technologie et ignore les personnes. Les schémas courants : des rôles clés tenus par des gens qui ont d'autres missions, des experts métier rappelés à l'exploitation en cours de projet, et une conduite du changement réduite à une fonction de formation. Quand personne n'est responsable d'une décision et qu'il n'y a pas de circuit d'escalade, les blocages durent des semaines et le projet échoue sur la coordination, pas sur la technologie.

Quels rôles sont incontournables dans toute mise en œuvre SAP ?

Six rôles exigent des personnes dédiées et responsables : sponsor exécutif, chef de projet, au moins un responsable fonctionnel par module majeur, un responsable informatique, un responsable de la migration des données et un responsable de la conduite du changement. Retirez-en un seul et le manque apparaît dans les dernières semaines avant le go-live. La conduite du changement est le rôle le plus sous-doté. Sur RISE, ajoutez un responsable clair pour les extensions et pour la relation avec les interlocuteurs de livraison de SAP.

Qu'est-ce qui change dans la conception de l'équipe avec RISE with SAP ?

SAP exploite l'infrastructure et les opérations techniques : vous travaillez donc avec des interlocuteurs désignés par SAP, comme un Client Delivery Manager ou un Cloud Architect Advisor. Inscrivez-les au tableau de l'équipe et nommez votre propre responsable de la relation. La responsabilité du Clean Core doit aussi être explicite : un architecte dédié sur les grands programmes, ou l'architecte de solution sur ceux de taille intermédiaire.

Une équipe projet SAP doit-elle s'appuyer sur des collaborateurs ou des consultants ?

Les deux. Les collaborateurs apportent un contexte métier que les consultants ne peuvent pas reproduire rapidement. Les consultants apportent la reconnaissance des schémas de mise en œuvre qui manque en général aux collaborateurs. Associez chaque consultant à un homologue interne qui sera responsable de ce domaine après le go-live, pour que le savoir reste quand les consultants partent. Les entreprises qui s'en dispensent paient souvent pendant des années un support qu'elles auraient dû assurer en interne.

Quand faut-il commencer à constituer le CoE SAP ?

Pendant la mise en œuvre, idéalement dès les premiers mois. Vos meilleurs membres du CoE sont en général vos contributeurs les plus solides de la mise en œuvre, et si vous attendez le go-live, ils sont partis avant que vous les ayez identifiés. Un client industriel qui a attendu a perdu ses principaux experts en paramétrage trois mois après le go-live, et personne ne savait maintenir ce qui avait été construit.

Comment l'IA change-t-elle la conception d'une équipe SAP en 2026 ?

Des outils comme SAP Joule for Consultants, SAP Build Code et Microsoft Copilot augmentent la productivité des rôles très orientés flux de travail quand les gens les utilisent de façon régulière. L'équipe est un peu plus petite que ce que le même périmètre exigeait avant ces outils, mais pas de façon spectaculaire. Intégrez les outils aux définitions de rôle et gardez la responsabilité du côté des personnes : l'IA rédige plus vite, les humains restent responsables de ce que dit le brouillon.