Comment rédiger la charte d'un projet de mise en œuvre SAP

Une charte de projet de mise en œuvre SAP est le document court qui autorise formellement le programme. Elle fixe, par écrit, ce que le programme livrera, ce qu'il ne livrera pas, qui décide, comment le succès se mesure et pour quand. Rédigez-la avant la signature des contrats de prestation, faites-la porter par le sponsor côté client, et rendez-la assez précise pour trancher une dispute. Un plan section par section figure plus bas.

Les équipes arrivent aux réunions de lancement SAP avec assurance. Puis elles découvrent que les rôles étaient définis de façon floue, que les limites du périmètre n'ont jamais été convenues et que personne ne sait dire à quoi ressemble le succès. Une charte devrait l'éviter. La plupart n'y parviennent pas, parce qu'elles sont écrites pour satisfaire une exigence de gouvernance et non pour ancrer le travail.

J'ai vu des chartes de projet qui avaient l'air propres mais ne se rattachaient à aucun plan réel. La version qui fonctionne est celle dont les gens débattent pendant la rédaction. C'est comme cela qu'on sait qu'elle est honnête.

Trois documents sont confondus sur chaque grand programme SAP. Ils ont des rôles différents.

Document	Objectif	Créé par	Moment
Proposition de projet	Justifier pourquoi le projet doit avoir lieu	Sponsor métier	Avant l'approbation
Charte de projet	Autoriser le projet ; fixer le périmètre, les objectifs, les responsables nommés et la gouvernance	Le sponsor avec le directeur de programme	Au lancement
Plan de projet	Définir comment le travail est réalisé : tâches, ressources, dépendances	Directeur de programme	Après l'approbation de la charte

La charte est le document de gouvernance. Elle trace des lignes. Si votre programme S/4HANA couvre plusieurs modules, pays et prestataires, c'est dans la charte que vous décidez de ce qui est inclus, avant que chacun ne se mette à faire ses propres hypothèses.

Des objectifs liés à un résultat métier

Pas « modernisation du système ». Chaque objectif a besoin d'un chiffre. Le test : pouvez-vous expliquer la vision à un membre du conseil en 30 secondes, sans diapositives ?

J'ai travaillé sur des programmes SAP où tout le monde a fêté le go-live, et deux mois plus tard personne ne pouvait dire s'il avait apporté la valeur promise. Un client industriel a dépensé plus de 4 millions de dollars et n'a pu démontrer aucun retour. Le DAF a demandé des indicateurs. Personne n'en avait, et cela a retardé son prochain tour de financement.

À l'inverse, prenez un client du commerce de détail que j'ai accompagné. Sa charte avait défini des indicateurs dès le premier jour. Il a montré une baisse de 32 % des coûts de traitement des commandes, et la phase 2 a été approuvée immédiatement.

Un périmètre avec des exclusions explicites

C'est la section la plus négligée. Les équipes rédigent de longues listes de ce qui est dans le périmètre et omettent les exclusions, qui sont précisément là où naissent les disputes.

J'ai travaillé avec une entreprise de santé qui a gardé son déploiement SAP concentré de cette manière. Le responsable marketing voulait ajouter des analyses pour le suivi des campagnes pendant la recette utilisateur (UAT). La charte n'avait pas de place pour cela, et le comité de pilotage l'a signalé immédiatement. Cette seule décision a économisé 850 000 $ et évité un retard de six semaines.

Des personnes nommées, pas des services

« Équipe finance : apporte sa contribution sur le reporting » ne rend personne responsable. « Responsable finance, [nom] : définit les exigences de reporting, valide le paramétrage FI/CO, approuve la préparation de la migration des données » le fait.

Des jalons comme engagements

Un client du commerce de détail a retardé son go-live de quatre mois. Le retard initial était un glissement de trois semaines dans le recueil des exigences que personne n'avait reporté au calendrier. Il pensait pouvoir le rattraper en aval. Au lieu de cela, il a dépensé 1,8 million de dollars en dépassements.

Cela marche aussi dans l'autre sens. Lors d'une mission chez un industriel, l'équipe s'en est tenue au plan publié. Quand l'équipe de migration des données a signalé un retard, le comité de pilotage a autorisé immédiatement un renfort en personnel, parce que la charte rendait le jalon visible. Cette décision a économisé à la fois du temps et 600 000 $.

Budget, risques et dépendances

Un budget de haut niveau, les trois ou quatre risques qui pourraient faire dérailler le programme, et les autres programmes qui se disputent les mêmes personnes et le même argent. Un client du commerce de détail a dépensé 3,2 millions de dollars dans une mise en œuvre qui n'est jamais entrée en production. Sa refonte de la finance et son projet SAP se déroulaient en parallèle avec les mêmes ressources et la même fenêtre budgétaire, et aucune des deux chartes ne mentionnait l'autre. La direction l'a vu trop tard.

Voici la structure que je prendrais comme point de départ. Chaque section devrait tenir sur une page ou moins.

1. Objet et contexte : pourquoi maintenant, ce qui ne fonctionne pas, ce qui se passe si vous ne faites rien.
2. Objectifs et mesures de succès : chaque objectif avec une valeur de départ, une cible et une date.
3. Périmètre : modules, processus, entités juridiques, pays, sites, intégrations et données dans le périmètre.
4. Hors périmètre : rédigé avec autant de soin que le périmètre, avec la phase à laquelle chaque élément exclu est reporté.
5. Modèle de déploiement et règles d'extension : S/4HANA Cloud Public Edition, Private Edition sous RISE, ou on-premise, et comment les développements spécifiques seront approuvés.
6. Gouvernance : sponsor, comité de pilotage, autorité de conception, contrôle des changements, circuit d'escalade, avec des personnes nommées.
7. Rôles et responsabilités : des personnes nommées pour chaque domaine de processus, les données, les tests, le changement et la bascule.
8. Jalons : points de passage de phase avec leurs dates et les critères pour les franchir. Mon guide des jalons qualité en donne des exemples.
9. Budget et provision pour aléas : l'enveloppe, la provision, et qui peut la débloquer.
10. Risques, hypothèses et dépendances : y compris les programmes parallèles et les échéances réglementaires.
11. Exigences de conformité : par exemple HIPAA dans la santé aux États-Unis, GxP dans la pharma, SOX pour les sociétés cotées aux États-Unis.
12. Approbation : sponsor et responsables métier, avec un numéro de version et une date.

1. 01Interroger ceux qui connaissent le travailSponsors, responsables métier et utilisateurs finaux
2. 02Séparer l'indispensable du souhaitableGo-live, phase 2 ou hors de ce projet
3. 03Partir d'un modèlePuis ajouter intégration, données et conformité
4. 04Être assez précis pour trancher les disputesPouvez-vous prouver que chaque objectif est atteint ?
5. 05Obtenir une vraie validationLue, contestée et acceptée, section par section

Une charte à laquelle vous référer quand le périmètre est contesté au troisième mois

1. Interrogez ceux qui connaissent le travail

Avant d'écrire quoi que ce soit, asseyez-vous avec les sponsors, les responsables métier et les utilisateurs finaux. Demandez ce qui ne fonctionne pas et ce qui a déjà été essayé. J'ai travaillé avec un client industriel qui a gaspillé 1,8 million de dollars dans une mise en œuvre SAP parce qu'il croyait savoir ce dont l'atelier avait besoin. Six mois plus tard, il a découvert que les vrais problèmes de workflow n'étaient pas traités.

Sur une transformation de la finance à laquelle j'ai participé, la DSI prévoyait de déployer SAP pour résoudre des problèmes d'efficacité. Les échanges avec la finance ont montré que le vrai problème était la mauvaise qualité des données. Si nous n'avions pas posé la question, nous aurions dépensé des millions à résoudre le mauvais problème.

2. Séparez l'indispensable du souhaitable avant d'écrire le périmètre

Classez chaque demande comme nécessaire au go-live, relevant de la phase 2 ou hors de ce projet. Un de mes clients de services professionnels a dépassé son budget de 40 % parce que ses exigences se trouvaient à trois endroits différents et étaient « redécouvertes » des mois après le début du projet. Mon guide du modèle de périmètre aide pour cette étape.

3. Partez d'un modèle, puis ajoutez les spécificités SAP

Un modèle générique oublie ce qui rend les programmes SAP coûteux : les points d'intégration, la responsabilité de la migration et du nettoyage des données, les hypothèses sur les modules, les exigences de conformité et les règles pour le développement spécifique. J'ai entendu parler d'un projet SAP qui avait démarré avec une charte générique qui ne mentionnait jamais le nettoyage des données. Six mois plus tard, les données héritées se sont révélées être un désastre, ce qui a ajouté 750 000 $ et trois mois.

4. Soyez assez précis pour trancher les disputes

J'ai conduit la mise en œuvre pour un client du commerce de détail à Singapour dont la charte disait « moderniser la gestion des stocks ». La moitié de l'équipe pensait que cela signifiait un traitement plus rapide. L'autre moitié s'est concentrée sur les prévisions. Résultat : 1,8 million de dollars dépensés et aucun accord sur ce que serait le succès. Pour chaque objectif, demandez-vous : puis-je prouver qu'il a été atteint ?

5. Obtenez une vraie validation

La charte est terminée quand les personnes qui la signent l'ont lue, l'ont contestée et ont accepté ses engagements. Passez-la en revue avec le sponsor et les responsables métier, section par section. J'ai vu des clients du commerce de détail passer trois jours pleins à obtenir l'alignement sur la charte. Cela leur a épargné des mois de disputes et de changements de périmètre par la suite.

Erreur	Ce qu'elle provoque	Que faire à la place
Objectifs vagues (« améliorer l'efficacité »)	Les équipes tirent dans des directions différentes	Mettre un chiffre sur chaque objectif
Pas d'exclusions	Le périmètre grossit discrètement	Rédiger la liste du hors périmètre avec autant de soin que le périmètre
Responsables désignés uniquement par fonction ou par service	Les décisions sont repoussées	Nommer des personnes
Pas de mesures de succès	On fête le go-live, la valeur n'est jamais démontrée	Définir les indicateurs avant le lancement
Programmes parallèles non cartographiés	Collisions de ressources et de budget	Consigner les dépendances dans les deux chartes
Charte rédigée par le partenaire intégrateur	Le périmètre reflète ce que le partenaire veut livrer	Le client la porte ; le partenaire apporte le détail

Sur ce dernier point, je suis ferme. Votre partenaire intégrateur ne doit pas rédiger votre charte. Son intérêt est de lancer le projet. Le vôtre est de le cadrer.

Avec RISE with SAP (Private Edition), ajoutez deux éléments à la section gouvernance. D'abord, un forum d'approbation Clean Core. SAP classe désormais les extensions du niveau A, API publiées uniquement, au niveau D, modifications (SAP News, août 2025). La Private Edition permet toujours de modifier le noyau, c'est donc le forum qui empêche la dette technique de s'accumuler. Ensuite, un circuit d'escalade vers SAP. Sous RISE, SAP exploite l'infrastructure et les opérations techniques. Le DSI doit savoir qui appeler chez SAP quand quelque chose tombe en panne au niveau de la plateforme, et pas seulement chez le partenaire.

Avec GROW with SAP (Public Edition), la charte devient plus légère. Les extensions sont limitées aux interfaces publiées, la plateforme impose donc le Clean Core à votre place, et les options d'intégration sont plus étroites. La vision, les mesures de succès, les responsables nommés et les exclusions comptent tout autant.

Les outils d'IA peuvent transformer des notes d'entretien en première ébauche plus vite. Ils ne peuvent pas faire le travail politique de la charte, qui consiste à faire convenir les sponsors de ce dont ils sont responsables.

Qu'est-ce qu'une charte de projet dans une mise en œuvre SAP ?

Le document qui autorise formellement le programme SAP. Il fixe le périmètre et les exclusions, nomme le sponsor et les personnes responsables, définit les mesures de succès, fixe les jalons et la gouvernance, et recense les principaux risques. Une charte utile est assez précise pour trancher un désaccord sur le périmètre ou les responsabilités.

Que doit contenir une charte de projet SAP ?

L'objet, des objectifs avec des cibles mesurables, le périmètre, des exclusions explicites, le modèle de déploiement et les règles d'extension, une gouvernance avec des personnes nommées, les rôles, des jalons avec leurs critères de passage, le budget et la provision pour aléas, les risques et dépendances, les exigences de conformité et l'approbation. Le plan ci-dessus montre chaque section.

Quelle est la différence entre une charte de projet et un plan de projet ?

La charte autorise et définit : périmètre, sponsor, gouvernance et jalons de haut niveau. Le plan exécute : tâches, dépendances, ressources et séquence. Un plan sans charte dérive, parce que le périmètre n'a jamais été convenu. Chaque engagement du plan doit pouvoir être relié à la charte.

Qui doit rédiger la charte de projet SAP ?

Le sponsor côté client en est propriétaire et le directeur de programme la rédige, avec les responsables de la finance, de la DSI et des opérations qui apportent le détail. Je déconseille de laisser le partenaire intégrateur la rédiger. Son intérêt est de lancer le projet, pas de vous protéger d'un périmètre dont vous n'avez pas besoin.

Comment RISE with SAP change-t-il la charte de projet ?

Ajoutez un forum d'approbation Clean Core qui décide quelles extensions sont autorisées et à quel niveau. Ajoutez un circuit d'escalade vers SAP pour les problèmes de plateforme, puisque SAP exploite l'infrastructure sous RISE. Avec GROW with SAP, la charte est plus légère, parce que la Public Edition impose le Clean Core sur le plan technique.

La charte de projet peut-elle changer pendant la mise en œuvre ?

Oui, par le contrôle des changements. Traitez la charte comme une référence. Quand le périmètre, le sponsor, le budget ou un jalon majeur change, mettez-la à jour avec un numéro de version, une note sur ce qui a changé et pourquoi, et une nouvelle validation. Ne la laissez pas être révisée discrètement chaque fois que le projet dérive.