Modèle de périmètre de projet SAP : ce qu'il faut définir et exclure

Un modèle de périmètre de projet SAP définit ce que le programme livrera, ce qu'il ne livrera délibérément pas, qui est responsable de chaque partie et comment le périmètre peut évoluer. Les neuf sections ci-dessous couvrent tout cela. Les deux qui comptent le plus sont celles que les équipes sautent : les exclusions explicites et le périmètre de migration des données. Renseignez le modèle avant le début du paramétrage et faites-le signer par le sponsor et les responsables de processus.

Il arrive que des équipes remplissent un modèle de périmètre et passent à autre chose. Cette partie paraît facile. Des semaines plus tard, pendant la conception ou la construction, quelqu'un signale un processus « supposé faire partie du périmètre ». La conversation devient inconfortable. Personne ne l'a écrit. Personne n'avait l'intention de l'omettre. Je l'ai vu arriver trop souvent. Quelques hypothèses non vérifiées au départ éloignent discrètement le projet de sa trajectoire de plusieurs semaines.

Le rôle du document de périmètre n'est pas de consigner ce que les gens ont dit en réunion. C'est d'imposer de la clarté avant que le paramétrage ne fige des hypothèses coûteuses à défaire.

Voici les neuf sections, avec ce à quoi chacune doit répondre.

1. Objectifs

Pourquoi ce travail est-il entrepris, et que verra le métier une fois qu'il sera terminé ? Rattachez chaque objectif à un résultat mesurable : réduire la clôture mensuelle de trois jours, supprimer les rapprochements manuels entre trois entités, une vue unique des stocks sur toutes les usines. Des objectifs vagues produisent des critères de réussite vagues, et le désaccord éclate pendant les tests d'acceptation utilisateur (UAT).

2. Définition du périmètre

Modules, entités juridiques, usines, pays, langues, intégrations et modèle de déploiement. Soyez précis. « Finance » n'est pas un périmètre. « Comptabilité financière et contrôle de gestion (FI/CO) couvrant la comptabilité fournisseurs, la comptabilité clients, le grand livre et la comptabilité par centre de coûts pour l'entité juridique des Émirats arabes unis sur S/4HANA Cloud Private Edition » est un périmètre.

3. Exclusions

C'est là que la plupart des modèles de périmètre échouent. Si quelque chose n'est pas écrit comme exclu, quelqu'un supposera que c'est inclus. Exclusions à consigner nommément :

1. Les pays ou entités reportés à une phase ultérieure.
2. Les intégrations existantes conservées telles quelles pour l'instant.
3. Les données historiques antérieures à une date de coupure définie.
4. Les rapports reportés vers une liste d'évolutions postérieure au go-live.
5. Les exigences réglementaires différées dans l'attente d'une confirmation juridique.

Indiquez pour chaque exclusion la phase vers laquelle elle est reportée, le cas échéant. Une exclusion signée transforme une dispute de deux semaines en une courte conversation.

4. Périmètre de migration des données

Un angle mort constant. Répondez par écrit à trois questions :

1. Qu'est-ce qui migre ? Les postes ouverts seulement, ou l'historique ? Tous les clients et fournisseurs, ou seulement les actifs ? Les articles de toutes les usines, ou seulement ceux des entités du go-live ?
2. Quelles sont les règles de coupure ? La date de référence pour les commandes d'achat, de vente et les ordres de travail ouverts, et ce qu'il advient des éléments en cours au moment de la bascule.
3. Qu'est-ce qui est archivé à la place ? Les règles légales de conservation de l'historique, et la durée pendant laquelle l'ancien système reste consultable.

Les hypothèses laissées sans documentation ici deviennent des litiges pendant la construction. Mon article sur les raisons de l'échec des migrations de données SAP traite de la planification en profondeur.

5. Périmètre non fonctionnel

Ces points sont oubliés à la planification et réapparaissent comme des blocages tard dans les tests. Mettez-les dans le périmètre :

1. La disponibilité et la fenêtre de maintenance. Avec RISE, référencez les conditions de disponibilité de votre contrat.
2. La performance en pointe de charge, comme la clôture mensuelle.
3. La journalisation d'audit : quelles transactions, et combien de temps les journaux sont conservés.
4. La sécurité et le contrôle d'accès par rôle.
5. La latence des rapports : temps réel, quasi temps réel ou quotidienne.

Ce ne sont pas des fonctionnalités. Ce sont des contraintes que le système doit respecter. Si elles ne figurent pas dans le périmètre, personne n'en tient compte à la conception.

6. Rôles et responsabilités

Chaque chantier a besoin d'un consultant responsable et d'un homologue métier disposant du pouvoir de décision, tous deux nommés. Le manque que je vois le plus souvent concerne la responsabilité de l'UAT : qui peut valider qu'un processus est testé et accepté ? Décidez-le avant le début de la construction, pas deux semaines avant le go-live.

7. Contrôle des changements

Pas un simple « les changements exigent une validation formelle ». Un processus précis : ce qui déclenche une demande de changement, qui évalue l'impact sur les délais et le budget, qui valide, et ce qui est consigné. Sans lui, « peut-on ajouter cela ? » devient « nous pensions que c'était inclus », puis une prolongation de trois semaines que personne n'avait prévue.

8. Règles d'extension

Comment les développements spécifiques seront approuvés. SAP classe désormais les extensions du niveau A, API publiées uniquement, au niveau D, modifications du noyau (SAP News, août 2025). Sur Public Edition avec GROW, le système n'autorise que les interfaces publiées. Sur Private Edition avec RISE et sur site, le noyau peut encore être modifié ; le périmètre doit donc indiquer le niveau cible et qui approuve les exceptions. Mon guide du Clean Core explique les niveaux.

9. Hypothèses et contraintes

Listez les hypothèses qui sous-tendent le périmètre afin que quelqu'un doive les vérifier. Puis les contraintes : échéances réglementaires qui fixent une date de go-live, plafonds budgétaires, personnes disponibles seulement à temps partiel, et dates de mise hors service des systèmes existants.

La personnalisation est la forme de dérive du périmètre qui met le plus de temps à se voir. Un rapport spécifique approuvé en devient cinq. Une exception de workflow devient le précédent de toutes les demandes qui suivent.

Classez chaque demande avant d'approuver quoi que ce soit :

Catégorie	Test	Action à mener
Essentielle	Le processus ne peut pas fonctionner légalement ou opérationnellement sans elle	Approuver, avec l'extension la moins coûteuse qui résiste aux mises à niveau
Importante, non critique	Améliore l'efficacité mais n'est pas bloquante	Approuver seulement avec une analyse coûts-bénéfices claire
Inutile	Une préférence, ou une copie du fonctionnement de l'ancien système	La contester, puis la refuser ou la reporter

La plupart des personnalisations inutiles existent parce que quelqu'un ne voulait pas changer sa façon de travailler, pas parce que SAP ne pouvait pas prendre en charge le processus. Et le coût de construction n'est que le début. Chaque objet spécifique ajoute du travail de test, de formation, de documentation et de mise à niveau tant qu'il existe.

Fixez un gel des changements. Choisissez une date, généralement quatre à six semaines avant le go-live, après laquelle plus aucune nouvelle demande n'est acceptée pour cette livraison. Tout ce qui vient après va dans le backlog postérieur au go-live. Le gel doit avoir la signature du comité de pilotage derrière lui. Une date annoncée par le seul chef de projet sera écartée la première fois qu'un directeur de service insistera.

1. 01Demande formuléeCe qui compte comme un changement est défini dès le départ
2. 02ClasséeEssentielle, importante ou inutile
3. 03Impact évaluéDélais et budget, par un évaluateur nommé
4. 04DécisionUn approbateur nommé approuve, refuse ou reporte
5. 05Périmètre versionnéNouveau numéro de version et liste de ce qui a changé

Après le gel des changements, les nouvelles demandes vont dans le backlog postérieur au go-live

L'analytique est le sujet où les discussions de périmètre s'enflamment. Tout le monde veut des rapports et personne ne dit combien.

Convenez d'une liste fermée de rapports pendant la conception. Demandez aux gens ce dont ils ont besoin, pas ce qu'ils pourraient souhaiter. Marquez chaque rapport comme sortie SAP standard ou développement spécifique, et faites signer la liste avec le reste du périmètre. Les rapports standard coûtent une fraction des rapports spécifiques. Identifiez en même temps les sources de données de chaque rapport ; un rapport qui puise dans trois systèmes est une exigence d'intégration. Si des tableaux de bord et de la planification sont dans le périmètre, mon guide SAP Analytics Cloud indique ce qu'il faut régler en premier.

Erreur	Ce qu'elle provoque	Comment l'éviter
Objectifs non mesurables	Litiges en UAT sur ce que « fonctionne » veut dire	Fixer des résultats mesurables dès le départ
Exclusions non écrites	Travail absorbé sans approbation	Lister nommément ce qui est hors périmètre
Périmètre de migration des données flou	Mauvais volumes, bascule décalée, reprises	Définir ce qui migre, les coupures et l'archivage
Exigences non fonctionnelles absentes	Problèmes d'audit et de performance au go-live	Mettre la disponibilité, la performance, la journalisation et la sécurité dans le périmètre
Pas de responsables UAT nommés	Les tests traînent, personne ne peut valider	Nommer des personnes ayant le pouvoir de décision
Pas de contrôle des changements	Ajouts informels, tests comprimés	Inscrire le processus de changement dans le périmètre
Pas de validation signée	Périmètre contesté plus tard sans responsabilité	Faire signer le sponsor et les responsables de processus
Analytique laissée pour plus tard	Demandes de rapports deux semaines avant le go-live	Convenir de la liste de rapports pendant la conception
Modèle de déploiement ou règles d'extension ouverts	Le débat déborde sur la phase de construction	Trancher les deux avant la signature du périmètre

Revoyez le périmètre à chaque point de contrôle de phase SAP Activate et après chaque changement approuvé, avec un numéro de version et la liste de ce qui a changé. Le périmètre doit figurer par référence dans la charte de projet, afin que les deux documents racontent la même histoire.

Que doit contenir un modèle de périmètre de projet SAP ?

Neuf sections : des objectifs assortis de résultats mesurables, la définition du périmètre (modules, entités, pays, intégrations, modèle de déploiement), des exclusions explicites, le périmètre de migration des données, les exigences non fonctionnelles, des rôles nommés, le contrôle des changements, les règles d'extension, et les hypothèses avec les contraintes. Les exclusions sont la section la plus souvent absente.

Comment éviter la dérive du périmètre dans les projets SAP ?

Écrivez les exclusions explicitement, faites passer chaque changement par une demande formelle avec évaluation d'impact et approbateur nommé, classez les personnalisations avant de les approuver, et fixez un gel des changements signé quatre à six semaines avant le go-live. L'objectif n'est pas de refuser tout changement. C'est de rendre le changement visible, évalué et autorisé.

Qu'est-ce que le périmètre de migration des données dans un projet SAP ?

C'est la définition des données qui migrent vers SAP et selon quelles règles : quels objets (clients, fournisseurs, articles, commandes ouvertes, historique), les dates de coupure, et ce qui est archivé au lieu d'être migré. Il détermine l'effort et le calendrier, et il décide combien de temps les systèmes existants doivent rester accessibles.

Qu'est-ce que le périmètre non fonctionnel dans les projets SAP ?

Ce sont les contraintes que le système doit respecter, par opposition aux processus qu'il prend en charge : disponibilité, performance en pointe de charge, journalisation d'audit, sécurité et contrôle d'accès, latence des rapports. Elles sont souvent laissées hors périmètre puis découvertes pendant les tests. Dans les secteurs réglementés, la journalisation d'audit est une obligation légale.

Comment traiter les personnalisations dans le périmètre ?

Classez chaque demande comme essentielle, importante ou inutile. Pour chacune de celles qui sont approuvées, consignez l'exigence, la raison pour laquelle le standard SAP n'y répond pas, l'effort, l'impact sur les tests, le coût de maintenance et l'approche d'extension. Sur Private Edition et sur site, indiquez le niveau cible de Clean Core et qui approuve les exceptions.

Quand faut-il revoir le périmètre d'un projet SAP ?

À chaque point de contrôle de phase SAP Activate, après chaque demande de changement approuvée, et chaque fois que le budget, les ressources ou le calendrier changent. Conservez chaque version avec une date, un numéro de version et un résumé de ce qui a changé. Cet historique protège l'équipe quand le périmètre est contesté plus tard.