Modèles de mise en œuvre SAP : guide phase par phase, du cadrage au go-live

Les modèles SAP Activate sont les modèles de mise en œuvre et les accélérateurs que SAP publie pour chaque phase d'un programme S/4HANA, du document de cadrage en Prepare jusqu'au plan de cutover en Deploy. Vous les trouverez dans le SAP Activate Roadmap Viewer et, sur les programmes cloud, dans SAP Cloud ALM.

Réponse courte : vous n'avez pas besoin de tous. Il vous en faut une douzaine, chacun avec un responsable nommé et un point de validation, et vous devriez conserver environ 80 % de la structure standard de SAP. Le tableau ci-dessous présente l'ensemble que j'exige sur les 21 programmes SAP que j'ai dirigés ou redressés.

Trouver les modèles est facile. Savoir lesquels prendre au sérieux, voilà la difficulté.

Voici l'ensemble des modèles de mise en œuvre SAP que je m'attends à voir validés, avec le responsable et l'étape que chacun doit franchir.

Phase	Modèle	Responsable	Validé avant
Prepare	Document de cadrage du projet	Responsable de programme (approuvé par le sponsor)	Le début d'Explore
Prepare	Business case	DAF ou responsable métier	Le déblocage du financement
Prepare	Matrice des parties prenantes	Responsable de programme	La planification des ateliers Explore
Explore	Feuille des exigences et du fit-gap	Autorité de conception (métier et IT)	Le début de Realize
Realize	Journal de paramétrage	Responsables fonctionnels	Le passage de chaque transport en QA
Realize	Registre des développements spécifiques	Responsable des développements	Le début du développement de tout objet
Realize	Stratégie de test	Responsable des tests	Le début des tests d'intégration système
Realize	Plan de migration des données	Responsable de la migration des données	Le premier chargement à blanc
Deploy	Plan de cutover	Responsable du cutover	La répétition générale finale
Deploy	Checklist de préparation au go-live	Directeur de programme (signée par le sponsor)	La réunion go/no-go
Deploy	Modèle de support d'hypercare	Responsable de la prestation de services	Le go-live
Run	Fiche de suivi des performances	Responsable Basis	Le go-live

SAP Activate compte six phases : Discover, Prepare, Explore, Realize, Deploy et Run. Il associe le contenu SAP Best Practices, une méthodologie et un paramétrage guidé. Discover est la phase d'exploration sans engagement : pour la plupart des clients, elle se termine avant la signature du contrat, et les modèles ci-dessous commencent donc en Prepare.

1. 01DiscoverEn général avant la signature du contrat
2. 02PrepareDocument de cadrage, business case, matrice des parties prenantes
3. 03ExploreFeuille des exigences et du fit-gap
4. 04RealizeJournal de paramétrage, registre des développements, stratégie de test, plan de migration
5. 05DeployPlan de cutover, préparation au go-live, hypercare
6. 06RunSuivi des performances

Chaque modèle validé avant sa quality gate

Dans le Roadmap Viewer, chaque feuille de route est découpée en phases, livrables et tâches. Les modèles y sont classés comme accélérateurs : guides pratiques, documents types et checklists rattachés à la tâche qui en a besoin. Vous pouvez filtrer par phase, par flux de travail ou par accélérateur, ce qui est le moyen le plus rapide de récupérer les livrables SAP Activate d'une phase.

Quand vous les adaptez, conservez environ 80 % de la structure standard. Ne modifiez que ce qui reflète votre contexte : exigences sectorielles, contrôles réglementaires, spécificités régionales. Tout réécrire, c'est perdre la raison même de les utiliser.

Ce qui a changé dans l'outillage

La structure des phases est la même. L'outillage autour a évolué.

1. SAP Cloud ALM est l'endroit où se trouvent les modèles sur les programmes cloud. Il est fourni aux clients disposant de SAP Enterprise Support et inclus dans les abonnements cloud SAP comme RISE with SAP. Solution Manager 7.2 bénéficie de la maintenance standard jusqu'à fin 2027 et d'une maintenance étendue jusqu'en 2030 pour certaines fonctions.
2. Joule est intégré à l'outillage de la méthodologie. SAP a ajouté Joule au Roadmap Viewer en 2025 ainsi qu'à SAP Cloud ALM, pour qu'une équipe puisse demander des conseils sur une tâche ou un premier jet. Il ne remplace pas la personne qui signe le fit-gap.
3. Le Clean Core a désormais des niveaux. En août 2025, SAP a introduit quatre niveaux de Clean Core, de A à D : le niveau A n'utilise que des API publiées et le niveau D n'est pas clean. Votre feuille de fit-gap a besoin d'une colonne indiquant où chaque écart se situera.

Les projets qui sautent ce travail préparatoire le paient en Explore et en Realize. Ces trois documents sont ceux que les équipes sautent pour arriver plus vite au paramétrage.

Document de cadrage du projet

Il définit ce que le programme inclut et ce qu'il n'inclut pas. Quand quelqu'un essaie d'ajouter du périmètre au bout de trois mois (et cela arrivera), c'est la référence.

Les sections que j'attends :

1. Titre, sponsor et responsable de programme.
2. Contexte : situation actuelle et raison du changement.
3. Objectifs chiffrés, par exemple « faire passer le cycle de clôture de 14 jours à 5 ».
4. Périmètre inclus, par module et par processus (FI/CO, intégration MM/SD, migration des données, UAT, go-live).
5. Hors périmètre, rédigé aussi explicitement que le périmètre (RH, migration des anciens états, intégrations hors ERP).
6. Hypothèses et contraintes, comme la disponibilité du sponsor pour un comité de pilotage mensuel et une date de go-live fixe.
7. Calendrier par phase, avec validation par le sponsor et le PMO avant le début d'Explore.

Calez le calendrier sur ce qui est réaliste. D'après mon expérience, les programmes GROW prennent 6 à 9 mois, RISE 9 à 18 mois, les conversions brownfield 12 à 18 mois et le greenfield 18 à 24 mois ; mon guide du calendrier de mise en œuvre SAP le détaille phase par phase.

Modèle de business case

Il présente l'analyse coûts-bénéfices dans un format que l'équipe financière sait lire. Des clients ont obtenu l'approbation de leur programme dès la première soumission avec cette structure, parce que les chiffres sont clairs et que les hypothèses sont écrites.

La structure :

1. Responsable et synthèse : pourquoi maintenant, ce qui change, ce qui reste identique.
2. Énoncé du problème : durée du cycle de clôture, contournements manuels, ancienneté du système.
3. Approche proposée : greenfield, brownfield ou sélective, avec un résumé du périmètre.
4. Bénéfices chiffrés : jours gagnés sur la clôture, temps des ETP, taux d'erreur, risque d'audit.
5. Coûts et financement : mise en œuvre, licence ou abonnement, temps interne, provision pour imprévus.
6. Les trois principaux risques, avec probabilité et impact.
7. Recommandation : lancer, lancer sous conditions ou reporter.

Une règle que je tiens : l'intégrateur qui réalisera le travail ne doit pas rédiger ce document. Son intérêt est de démarrer. Le vôtre est d'aboutir, et mon modèle de business case SAP approfondit le modèle de bénéfices.

Matrice des parties prenantes

Elle recense toutes les personnes concernées par la mise en œuvre, leur influence et la façon dont vous allez les impliquer. Elle vous dit qui a besoin d'un point hebdomadaire et qui doit simplement être prévenu avant le go-live.

Pour chaque groupe, notez le rôle, l'intérêt, l'influence et le mode d'implication. Un ensemble typique : le DAF comme sponsor (comité de pilotage mensuel), le directeur informatique comme responsable technique, le directeur financier comme propriétaire du processus clé, les directeurs d'usine et les utilisateurs comptabilité fournisseurs et clients comme utilisateurs impactés, et l'audit interne aux quality gates.

Utilisez la même matrice pour planifier les ateliers de Prepare qui recueillent les exigences de haut niveau. Numérotez-les dès maintenant dans le format que vous utiliserez en Explore (REQ-001 et ainsi de suite), afin que la traçabilité jusqu'à la demande d'origine survive.

C'est en Explore que la conception est figée, lors des ateliers Fit-to-Standard menés sur la base des SAP Best Practices. C'est aussi là que les budgets SAP dérapent, parce que le nombre de WRICEF (workflows, états, interfaces, conversions, améliorations et formulaires) y augmente.

Ne laissez pas l'enchaînement des phases glisser. Sur une mission dans la distribution en Europe en 2023, le client a tenté de sauter Explore et a passé trois mois à développer sur des exigences incomplètes. Ma ventilation des coûts de mise en œuvre SAP montre comment ce type de reprise se transforme en budget.

Feuille des exigences et du fit-gap

La cartographie des exigences relie chaque besoin métier à un composant du système et à un cas de test. L'analyse fit-gap montre ensuite où SAP standard répond au besoin et où il n'y répond pas.

Je garde les deux dans une seule feuille, avec une colonne pour la voie de résolution. Sur S/4HANA, chaque écart exige une réponse explicite : paramétrage standard, extension par un utilisateur clé, extension développeur dans le système ou extension side-by-side sur SAP BTP.

ID exigence	Exigence	Composant SAP	Fit / gap	Voie de résolution	Réf. test
REQ-001	Écritures automatisées de clôture mensuelle	FI-GL, clôture de période	Fit	Paramétrage des pièces récurrentes	TC-001
REQ-002	Approbation des commandes d'achat sur mobile	Achats MM, application d'approbation Fiori	Fit dans S/4HANA	Application standard et paramétrage du workflow	TC-003
REQ-003	Automatisation de la facturation intragroupe	Facturation SD, intégration FI	Fit	Paramétrage de la facturation intragroupe	TC-010
REQ-004	Archivage des données pour les règles de confidentialité	Information Lifecycle Management	Gap	Paramétrage des règles ILM	TC-025
REQ-005	Reporting en temps réel par centre de coûts	CO, analytique embarquée ou SAC	Gap	Analytique embarquée ou connexion live SAC	TC-030
REQ-006	Portail libre-service fournisseurs	SAP Ariba ou portail fournisseurs	Gap	Intégration Ariba	TC-020

C'est ici que l'on économise de l'argent. Sur une migration ECC vers S/4HANA dans l'industrie en Europe en 2023, les ateliers fit-gap ont réduit de 35 % les améliorations prévues, et l'économie s'est chiffrée à six chiffres.

Deux règles font fonctionner la feuille. L'intégrateur ne doit pas contrôler le périmètre, car chaque écart qu'il classe en développement est du travail facturable pour lui. Une autorité de conception réunissant le métier et l'IT est responsable des décisions de Clean Core, et toute modification du code SAP exige un approbateur nommé ; ma stratégie Clean Core SAP explique les niveaux.

C'est la phase de construction. Ces modèles constituent la piste d'audit de chaque décision de paramétrage, de chaque développement et de chaque résultat de test.

Journal de paramétrage

Il enregistre chaque modification du système : qui l'a faite, pourquoi et dans quel transport. Quand quelque chose casse plus tard, vous retrouvez l'origine en quelques minutes plutôt qu'en plusieurs jours.

Chaque entrée doit comporter :

1. L'identifiant de paramétrage et le module (par exemple MM-CONF-001).
2. Le chemin de paramétrage et l'objet modifié.
3. Le processus métier concerné et la raison.
4. Qui l'a paramétré, et quand.
5. Le numéro d'ordre de transport.
6. Les valeurs clés avant et après.
7. Les cas de test liés et le statut d'approbation.

Registre des développements spécifiques

Chaque objet spécifique reçoit une ligne avant que quiconque n'écrive du code : identifiant, description, rôle du développeur, effort, statut et type d'extension. C'est dans la colonne du type d'extension que le Clean Core est imposé.

Sur une mise en œuvre S/4HANA dans la distribution en Europe en 2024, le registre a réduit de 30 % le code spécifique prévu. Il a montré où SAP standard suffisait tout à fait.

Stratégie de test

Elle rassemble tous les tests en un seul endroit : qui teste quoi, quand, dans quel environnement et selon quel niveau d'exigence.

1. Périmètre : tests fonctionnels, d'intégration, de non-régression, de performance et UAT sur les modules inclus.
2. Environnements : développement, QA, UAT et préproduction.
3. Outils : gestion des tests dans SAP Cloud ALM ou dans votre outil existant, avec les outils d'automatisation et de performance nommés.
4. Cycle de vie des anomalies, avec la gravité et la priorité fixées lors du tri.
5. Critères de sortie : toutes les anomalies critiques closes, l'UAT validée, un taux de réussite des tests de non-régression convenu à l'avance.

SAP Activate termine Realize par les tests d'intégration et les tests d'acceptation utilisateur. Rédigez les critères de sortie avant le début des tests, pas au moment où les résultats arrivent.

Plan de migration des données

La migration des données est le flux de travail le plus susceptible de vous faire mal. Le plan couvre le périmètre (partenaires commerciaux, articles, postes ouverts, soldes), les systèmes sources, les règles de mapping, les outils (le SAP S/4HANA Migration Cockpit), les chargements à blanc, la validation et le retour arrière.

La validation est la partie que les équipes sous-estiment : convenez des comptages d'enregistrements, de l'échantillonnage et du rapprochement des soldes avant le premier chargement à blanc.

Dans SAP Activate, Deploy couvre la mise en place de la production, le cutover, le go-live et l'hypercare. Ces modèles transforment un week-end chaotique en événement maîtrisé.

Modèle de plan de cutover SAP

Le plan de cutover découpe la fenêtre d'arrêt heure par heure. Chaque tâche a un responsable, une heure de début et une dépendance. Personne ne devrait se demander à 2 heures du matin ce qu'il doit faire ensuite.

Mettez-vous d'accord sur quatre points avant d'écrire la liste des tâches : la fenêtre (par exemple du vendredi 22:00 au samedi 06:00), le déclencheur du retour arrière, la rapidité avec laquelle l'ancien système peut être réactivé et les tests de fumée qui prouvent que le nouveau système fonctionne. Ensuite, la séquence :

Étape	Tâche	Responsable	Début	Statut
1	Geler l'ancien système (aucune comptabilisation)	Basis	22:00	En attente
2	Extraction finale des données et rapprochement	Responsable de la migration des données	22:30	En attente
3	Chargement de migration en production	Responsable de la migration des données	23:00	En attente
4	Importer les transports restants	Basis	00:30	En attente
5	Basculer les interfaces et le routage réseau	Responsable de l'intégration	01:30	En attente
6	Test de fumée : comptabilisation FI, entrée de marchandises, commande client	Responsable QA	02:00	En attente
7	Confirmation du métier et go/no-go	Directeur de programme	03:00	En attente
8	Ouvrir le système aux utilisateurs métier	Basis	06:00	En attente

Checklist de préparation au go-live

Elle décide si vous êtes réellement prêt à basculer. Chaque point reçoit une réponse oui ou non, avec preuve à l'appui.

1. Fonctionnel : processus clés et scénarios inter-modules testés, anomalies P1 et P2 ouvertes listées, utilisateurs clés confirmant leur préparation.
2. Données : données de base et données de transaction chargées et rapprochées, états de rapprochement approuvés, gel de l'ancien système confirmé.
3. Finance : paramétrage de la clôture de période testé pour chaque société et chaque entité.
4. Technique : plan de cutover approuvé, transports en production, jobs batch planifiés, surveillance configurée.
5. Personnes : couverture de la formation, rôles d'accès validés, équipe d'hypercare en place.
6. Décision : risques critiques et mesures d'atténuation, go / no-go / sous conditions, approuvée avec nom, fonction et date.

La ligne finance est là pour une raison. Sur un programme dans la distribution dans le GCC en 2024, la revue de go-live a détecté un problème de paramétrage de la clôture financière sur les 25 entités, deux jours avant le go-live ; il aurait déclenché une opération de rattrapage à six chiffres.

J'ai utilisé cette évaluation pour recommander un report de deux semaines sur deux programmes. C'est précisément son rôle.

Modèle de support d'hypercare

Il organise le traitement des incidents après le lancement. Sans lui, chaque problème devient un P1.

1. Fenêtre et couverture de l'hypercare, par exemple quatre semaines avec horaires étendus.
2. Canaux de support : la file des incidents, un canal de discussion et une conférence téléphonique pour les P1.
3. Niveaux de support : centre de services, consultants fonctionnels, puis Basis et développement.
4. Délais de réponse et de résolution par gravité.
5. Critères de sortie : aucun incident P1 ou P2 ouvert et une passation signée à l'organisation de support.

Run correspond au support et à la gestion du système en production. Le modèle que la plupart des équipes abandonnent trop tôt est celui qui surveille les performances.

Fiche de suivi des performances

Elle suit la santé du système jour après jour pour repérer les ralentissements avant que les utilisateurs ne se plaignent. Sur un programme dans les services financiers en Europe en 2024, elle a détecté en semaine 3 de l'hypercare un problème de base de données qui aurait fait tomber le système pendant la clôture mensuelle.

Les indicateurs que je suis, chacun avec une cible, un seuil d'alerte et un responsable :

1. Temps de réponse en dialogue (95e centile) : cible inférieure à 1 seconde, alerte à 2 secondes, Basis.
2. Jobs en arrière-plan : 100 % terminés dans les délais, alerte à la moindre erreur, responsable de l'exploitation.
3. Temps des requêtes en base de données : cible inférieure à 200 ms, alerte à 500 ms, administrateur de base de données.
4. Taux d'erreur des interfaces : inférieur à 1 %, alerte à 2 %, responsable de l'intégration.
5. Durée d'exécution des jobs de clôture mensuelle : dans la fenêtre convenue, alerte à 30 % au-dessus de la référence, opérations financières.

SAP Activate intègre des quality gates dans les feuilles de route de chaque phase, avec des points de contrôle pour chacune. Mon guide des quality gates SAP explique comment les mettre en place ; voici pourquoi elles doivent avoir du mordant.

Fixez des critères de réussite et d'échec à chaque quality gate. « 95 % des tests de non-régression réussissent. » « Tous les scénarios d'intégration FI sont au vert. » Des critères de ce type vous permettent de tenir bon quand le métier veut démarrer à une date donnée quelle que soit la qualité.

Une quality gate sur un programme dans l'industrie en Europe en 2024 nous a arrêtés alors que le taux de réussite des tests d'intégration était de 74 %. Nous avons tenu, corrigé les problèmes et démarré deux semaines plus tard. Le premier mois, les tickets de support après le go-live ont été deux fois moins nombreux que sur des programmes comparables.

La validation par la direction ne doit pas non plus être une formalité ; le problème de clôture financière dans la distribution dans le GCC mentionné plus haut a été détecté précisément lors de cette revue. Une quality gate que le sponsor peut lever d'un simple coup de téléphone n'est pas une quality gate. Écrivez qui peut y déroger avant d'en avoir besoin.

Pour l'ensemble du processus autour de ces modèles, consultez mon guide pas à pas de la mise en œuvre SAP.

Ce guide fait partie de mon dossier sur la mise en œuvre de SAP, qui relie tous les sujets, du business case au démarrage.

Où télécharger les modèles SAP Activate ?

Dans le SAP Activate Roadmap Viewer, à l'adresse me.sap.com/roadmapviewer. Ouvrez la feuille de route correspondant à votre déploiement, puis filtrez par phase ou par accélérateur pour voir les modèles, guides et checklists de chaque tâche.

Sur les programmes cloud, le même contenu est disponible dans SAP Cloud ALM, où les tâches et les livrables peuvent être suivis par rapport au projet.

Quels sont les livrables SAP Activate de chaque phase ?

Prepare livre le périmètre, le plan, la gouvernance et le business case. Explore livre les résultats Fit-to-Standard, le backlog des exigences et du fit-gap et la conception de la solution. Realize livre le système paramétré et testé, y compris les tests d'intégration et les tests d'acceptation utilisateur.

Deploy livre le cutover, le go-live et l'hypercare. Run couvre le support et l'amélioration du système en production.

Quelle phase SAP Activate contient les modèles les plus importants ?

Prepare. Le document de cadrage, le business case et la matrice des parties prenantes conditionnent toutes les décisions qui suivent, et ce sont ceux que les équipes sautent pour arriver plus vite au paramétrage.

Explore suit de près, parce que la feuille de fit-gap décide du nombre de WRICEF et que c'est là que les budgets dérapent.

Peut-on personnaliser les modèles SAP Activate ?

Oui. Conservez environ 80 % de la structure standard et ne modifiez que ce qui vous est propre : règles de validation dans l'industrie pharmaceutique, achats du secteur public, contrôles SOX. Faites ces modifications au début de Prepare, pas en Deploy.

Ne supprimez pas par personnalisation l'enchaînement des phases, les quality gates ni l'évaluation de préparation au go-live.

Que doit contenir un modèle de plan de cutover SAP ?

Une liste de tâches minutée pour la fenêtre d'arrêt, avec un responsable, une heure de début et une dépendance pour chaque tâche. Avant la liste des tâches, mettez-vous d'accord sur la fenêtre, le déclencheur du retour arrière, le temps nécessaire pour réactiver l'ancien système et les tests de fumée.

Décidez qui prend la décision de retour arrière, et avant quelle heure, avant le début du cutover. Les décisions de retour arrière prises à 4 heures du matin sans critères convenus sont le point de départ des problèmes après le go-live.

Que contient une checklist de préparation au go-live SAP ?

La préparation fonctionnelle, données, finance, technique et humaine, chaque point recevant une réponse oui ou non avec preuve, plus une décision go / no-go consignée avec noms et dates.

Testez le paramétrage de la clôture de période pour chaque entité avant le go-live. C'est le contrôle le plus susceptible de vous éviter une opération de rattrapage à six chiffres.

Les modèles SAP Activate fonctionnent-ils en greenfield comme en brownfield ?

Oui. La différence se situe surtout en Explore. Une conversion brownfield reprend le paramétrage existant : le fit-gap se concentre donc sur ce qui doit changer et sur le code spécifique que S/4HANA standard peut désormais remplacer ; un programme greenfield part des SAP Best Practices.

Le plan de cutover diffère aussi, car une conversion de système suit une séquence technique différente d'un chargement de données greenfield.