Modèles de mise en œuvre SAP : guide phase par phase

SAP Activate fournit un modèle pour presque chaque livrable d'un programme S/4HANA. Vous les trouverez dans le SAP Activate Roadmap Viewer et, sur les programmes cloud, dans SAP Cloud ALM. Les trouver est facile. Savoir lesquels prendre au sérieux, voilà la difficulté.

Ce guide s'adresse aux responsables de programme, aux responsables de PMO et aux sponsors qui lancent une mise en œuvre. Il présente les modèles que j'exige à chaque phase, montre une trame de travail pour chacun et signale où les équipes rognent. Si vous avez une semaine avant le lancement, faites d'abord le document de cadrage et la matrice des parties prenantes. Tout le reste s'appuie sur ces deux-là.

Le constat est constant sur les programmes ECC et S/4HANA que j'ai menés dans l'industrie, la distribution et les services financiers. Les équipes qui suivent les modèles repèrent les problèmes plus tôt. Celles qui les traitent comme de la paperasse facultative découvrent en cours de projet que chaque décision qu'elles n'ont pas écrite s'est transformée en litige de périmètre.

Voici l'ensemble que je m'attends à voir validé, avec la personne qui détient chaque modèle et le point qu'il doit franchir.

Phase	Modèle	Responsable	Validé avant
Prepare	Document de cadrage du projet	Responsable de programme (le sponsor approuve)	Le démarrage d'Explore
Prepare	Business case	Directeur financier ou responsable métier	Le déblocage du financement
Prepare	Matrice des parties prenantes	Responsable de programme	La planification des ateliers Explore
Explore	Fiche des exigences et du fit-gap	Architecte de solution avec les propriétaires de processus	Le démarrage de Realize
Realize	Journal de paramétrage	Responsables fonctionnels	Chaque passage d'un transport en QA
Realize	Registre des développements spécifiques	Responsable développement	Le début de la réalisation de tout objet
Realize	Stratégie de test	Responsable des tests	Le démarrage des tests d'intégration système
Realize	Plan de migration des données	Responsable migration des données	Le premier chargement à blanc
Deploy	Plan de cutover	Responsable du cutover	La dernière répétition générale
Deploy	Évaluation de préparation au go-live	Directeur de programme (le sponsor signe)	La réunion go/no-go
Run	Modèle de support hypercare	Responsable de la prestation de service	Le go-live
Run	Fiche de suivi des performances	Responsable Basis	Le go-live

Activate comprend six phases : Discover, Prepare, Explore, Realize, Deploy et Run. Il associe le contenu SAP Best Practices, un paramétrage guidé et une approche de livraison agile. Pour la plupart des clients, Discover a lieu avant la signature du contrat ; les modèles ci-dessous commencent donc à Prepare.

1. 01DiscoverGénéralement avant la signature du contrat
2. 02PrepareDocument de cadrage, business case, matrice des parties prenantes
3. 03ExploreFiche 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
6. 06RunModèle hypercare, suivi des performances

Chaque modèle est signé avant son jalon

L'ordre des phases n'est pas facultatif. J'ai travaillé avec un distributeur qui a voulu en sauter une partie et a fini par refaire trois mois de travail. Chaque quality gate a sa raison d'être.

Quand vous adaptez les modèles, conservez environ 80 % de la structure standard. Ne changez que ce qui reflète votre contexte : exigences sectorielles, contrôles réglementaires, spécificités régionales. Tout réécrire fait perdre l'intérêt de l'exercice.

Ce qui a changé dans l'outillage pour 2026

La structure d'Activate est restée la même. L'outillage qui l'entoure a bougé.

1. SAP Cloud ALM héberge les modèles sur les programmes cloud. C'est le successeur de Solution Manager chez SAP, inclus avec SAP Enterprise Support et avec les abonnements cloud comme RISE with SAP. Cadrage, exigences, plans de test et tâches de cutover peuvent y vivre, avec une traçabilité entre eux. Solution Manager 7.2 sort de la maintenance standard fin 2027, avec une maintenance étendue jusqu'en 2030 pour certaines fonctions : les systèmes sur site existants ont donc quelques années devant eux, pas une décennie.
2. Joule est désormais intégré à l'outillage de la méthodologie. SAP a rendu Joule disponible dans l'Activate Roadmap Viewer en 2025 et dans SAP Cloud ALM, de sorte qu'une équipe peut demander des conseils sur une tâche ou faire rédiger du contenu à partir de la roadmap. Cela accélère le premier jet. Cela ne remplace pas la personne qui signe le fit-gap.
3. Le clean core est désormais une règle de conception, avec des niveaux. En août 2025, SAP a remplacé son modèle d'extensibilité à trois niveaux par quatre niveaux de clean core, de A à D. Le niveau A n'utilise que des API publiées, soit sur SAP BTP, soit dans le système avec ABAP Cloud. Le niveau D n'est pas clean du tout. Le modèle de fit-gap a besoin d'une colonne indiquant où chaque écart atterrira.
4. La Public Edition resserre le fit-gap. SAP commercialise désormais S/4HANA Cloud Public Edition sous le nom SAP Cloud ERP, vendu aux entreprises de taille intermédiaire sous le nom SAP GROW. Les mêmes six phases s'appliquent avec des livrables plus légers, et seules les extensions via des API publiées sont autorisées : la colonne « gap » a donc moins de réponses possibles.

Les projets qui sautent ce travail de fondation le paient en Explore et en Realize.

Modèle de cadrage du projet

Définit ce que le projet inclut et ce qu'il exclut. Quand quelqu'un essaie d'ajouter du périmètre trois mois plus tard (et quelqu'un essaiera), ce document sert de référence. La charte de projet SAP se place au-dessus et porte le détail de la gouvernance.

Section	Détails
Titre, sponsor, chef de projet	Mise en œuvre de SAP S/4HANA Finance ; directeur financier ; chef de projet senior nommé
Contexte	Situation actuelle et moteur du changement
Objectifs	Ramener le cycle de clôture de 14 jours à 5 ; supprimer les rapprochements manuels
Dans le périmètre	FI/CO, intégration MM/SD, migration des données, UAT, go-live
Hors périmètre	Modules RH, migration des états historiques, intégrations tierces au-delà de l'ERP
Hypothèses	Sponsor exécutif disponible pour un comité de pilotage mensuel ; données de test convenues d'ici la semaine 6
Contraintes	Date de go-live fixe ; ressources internes uniquement pour le paramétrage
Livrables	Système paramétré, plans de test, plan de cutover, supports de formation
Calendrier	Prepare : semaines 1 à 4 ; Explore : semaines 5 à 10 ; Realize : semaines 11 à 26
Approbation	Validation du sponsor du projet et du PMO requise avant le début d'Explore

Modèle de business case

Déroule l'analyse coûts-bénéfices dans un format que l'équipe finance sait lire. J'ai vu des clients obtenir l'approbation du programme dès la première soumission avec cette structure, parce que les chiffres sont clairs et les hypothèses écrites.

Une règle à laquelle 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 de finir. Mon modèle de business case SAP détaille davantage le modèle de bénéfices.

Section	Détails
Responsable et synthèse	Directeur financier ou directeur de programme ; pourquoi maintenant, ce qui change, ce qui reste identique
Énoncé du problème	Problèmes opérationnels précis (durée du cycle de clôture, contournements manuels, âge du système)
Approche proposée	Greenfield / brownfield / sélective, avec résumé du périmètre
Bénéfices	Chiffrés : jours gagnés sur le cycle de clôture, économies d'ETP, baisse du taux d'erreur, réduction du risque d'audit
Coût et financement	Mise en œuvre, licence ou abonnement, temps des ressources internes, provision pour imprévus ; source du budget
Risques	Les trois principaux, avec probabilité et impact
Recommandation	Poursuivre / poursuivre sous conditions / reporter, avec justification

Matrice d'identification des parties prenantes

Cartographie toutes les personnes touchées par la mise en œuvre et leur niveau d'influence. Elle indique d'un coup d'œil qui a besoin d'un point hebdomadaire et qui a seulement besoin d'être prévenu avant le go-live.

Partie prenante	Rôle	Intérêt	Influence	Engagement
Directeur financier du groupe	Sponsor exécutif	ROI du programme, amélioration de la clôture financière	Élevée	Comité de pilotage mensuel, point écrit hebdomadaire
Directeur informatique	Responsable technique	Stabilité du système, intégration, sécurité	Élevée	Comité de programme hebdomadaire, quotidien pendant Realize
Directeur de la comptabilité	Propriétaire de processus clé	Conception FI/CO, processus de clôture	Élevée	Ateliers en Explore, validation de l'UAT
Responsables d'usine	Utilisateurs concernés	Changements des processus MM/PP	Moyenne	Communication mensuelle sur le changement, participation à l'UAT
Utilisateurs finaux (AP/AR)	Opérateurs	Changements au niveau des transactions	Faible	Formation, support hypercare
Audit interne	Gouvernance	Traçabilité, contrôles, conformité	Moyenne	Revues des livrables aux quality gates

Utilisez la même matrice pour planifier les ateliers de Prepare qui recueillent les exigences de haut niveau par département. Numérotez ces exigences dans le format que vous utiliserez en Explore (REQ-001 et ainsi de suite), pour que rien ne soit renuméroté plus tard et que le lien avec la demande d'origine survive.

Explore, c'est là que la mise en œuvre prend forme. Ces modèles révèlent l'écart entre ce que SAP fait en standard et ce dont le métier a besoin.

Modèle de cartographie des exigences et de fit-gap

La cartographie des exigences recense les besoins métier par département et rattache chacun à un composant du système et à un cas de test. J'ai vu des entreprises la sauter et se retrouver avec des systèmes que personne n'utilise, parce que la réalisation reposait sur ce que les consultants supposaient plutôt que sur ce que le métier avait dit.

L'analyse de fit-gap montre ensuite où SAP standard répond à chaque besoin et où il ne le fait pas. C'est une vraie révélation pour la plupart de mes clients. J'aime observer le moment où une équipe comprend qu'elle peut utiliser une fonction standard au lieu d'un code spécifique coûteux.

Je garde les deux dans une seule feuille, avec une colonne pour la voie de résolution. Sur S/4HANA, chaque écart appelle une réponse explicite : paramétrage standard, extension key user, extension développeur dans le système, ou extension side-by-side sur SAP BTP. Les modifications classiques du code SAP sont la réponse la plus coûteuse et devraient exiger un approbateur nommé.

ID exigence	Exigence	Composant SAP	Fit / Gap	Voie de résolution	Réf. test
REQ-001	Écritures de clôture mensuelle automatisées	FI-GL, clôture de période	Fit	Paramétrer des modèles de pièces récurrentes	TC-001
REQ-002	Approbation des commandes d'achat via Fiori	Achats MM, application d'approbation Fiori	Gap (absent d'ECC)	Application S/4HANA standard et paramétrage du workflow	TC-003
REQ-003	Automatisation de la facturation intersociétés	Facturation SD, intégration FI	Gap	Paramétrage de la facturation intersociétés	TC-010
REQ-004	Suivi des jobs batch	Application Jobs	Fit	Application standard	TC-015
REQ-005	Portail libre-service fournisseurs	SAP Ariba ou portail fournisseurs	Gap	Intégration Ariba	TC-020
REQ-006	Archivage des données conforme au RGPD	ILM, archivage des données	Gap	Paramétrage de la politique ILM	TC-025
REQ-007	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-008	Prise en charge de 500 utilisateurs simultanés	Dimensionnement HANA	Gap (300 testés)	Revue du dimensionnement et renfort d'infrastructure	TC-035

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

Modèle de suivi du paramétrage

Enregistre chaque modification du système : qui l'a faite, pourquoi, et dans quel transport elle est partie. Quand quelque chose casse plus tard, vous retrouvez le problème en quelques minutes plutôt qu'en quelques jours.

1. ID de paramétrage et module : [p. ex. MM-CONF-001, MM]
2. Chemin IMG et objet de paramétrage : [p. ex. table T161, types de documents de commande]
3. Objectif et processus métier concerné
4. Paramétré par, et date
5. Numéro de l'ordre de transport : [p. ex. DEVK900123]
6. Valeurs clés : avant et après
7. Cas de test liés
8. Statut de validation et d'approbation

Registre des développements spécifiques

Chaque objet spécifique reçoit une ligne avant que quiconque écrive du code. Un de mes clients a réduit son code spécifique de 30 % parce que le registre montrait où SAP standard suffisait très bien.

ID dév.	Objet	Description	Développeur	Effort (h)	Statut	Type d'extension
CD-001	Tuile Fiori : vue d'ensemble des centres de coûts	Tuile de reporting CO en temps réel pour la finance	Développeur Fiori	12	Terminé	Extension développeur
CD-002	Rapport de facturation intersociétés	Rapport de rapprochement intersociétés	Développeur ABAP	20	En cours	Extension développeur
CD-004	Application de statut des paiements fournisseurs	Application Fiori pour les demandes sur les paiements fournisseurs	Développeur BTP	10	En attente de QA	Side-by-side sur BTP
CD-005	Notification de réception de marchandises	Envoi d'un e-mail à la comptabilisation d'une réception de marchandises	Développeur d'intégration	24	Planifié	Basé sur les événements, sur BTP

Modèle de stratégie de test

Réunit tous les plans de test en un seul endroit : qui teste quoi, quand, dans quel environnement et selon quel niveau d'exigence.

Section	Détails
Périmètre	Tests fonctionnels, d'intégration, de non-régression, de performance et UAT sur les modules du périmètre (les tests d'intrusion relèvent de la sécurité informatique)
Environnements	DEV, QA, UAT (préproduction), staging pour la validation finale
Outils	Gestion des tests dans SAP Cloud ALM ou Jira/Xray ; automatisation avec Tricentis Tosca ou équivalent ; performance avec JMeter ou LoadRunner
Cycle de vie des anomalies	Nouvelle, En cours, Résolue, Vérifiée, Clôturée ; sévérité et priorité fixées au tri
Critères de sortie	Toutes les anomalies critiques clôturées ; validation de l'UAT reçue ; taux de réussite de la non-régression d'au moins 95 % ; objectifs de performance atteints

Modèle de planification de la migration des données

La migration des données est le chantier le plus susceptible de vous faire mal. Ce modèle la découpe en étapes qui exposent les problèmes de qualité des données avant le cutover plutôt que pendant. L'article sur les schémas d'échec de la migration des données explique ce qui se passe quand on l'omet.

Section	Détails
Périmètre	Données de base clients, données de base fournisseurs, postes ouverts, données de base articles, stocks, hiérarchies de centres de coûts
Systèmes sources	ECC 6.0 EHP 7 (principal) ; ancien système RH (affectations des salariés aux centres de coûts)
Système cible	S/4HANA (version courante)
Mapping et règles	Clients et fournisseurs vers Business Partner ; centres de coûts vers la nouvelle hiérarchie ; suppression des coordonnées bancaires invalides ; fusion des doublons
Outils de migration	SAP S/4HANA Migration Cockpit (principal) ; Migration Object Modeler pour les objets spécifiques ; scripts de prétraitement
Stratégie de chargement	Chargement à blanc sur QA ; migration delta et rapprochement ; cutover en production
Approche de validation	Comptage des enregistrements de la source vers la cible ; échantillonnage aléatoire de 10 % ; états de rapprochement des soldes
Plan de retour arrière	Sauvegarde avant cutover ; ancien système en veille pendant 48 heures

La phase Deploy, c'est le moment du go-live. Ces modèles transforment un week-end chaotique en événement maîtrisé.

Modèle de planification du cutover

Cartographie la fenêtre d'arrêt heure par heure. Chaque tâche, chaque responsable, chaque heure de début. Votre équipe ne doit jamais rester à attendre à 2 h du matin sans savoir quoi 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. Puis la séquence des tâches :

Étape	Description	Responsable	Heure de début	Statut
1	Gel du système ECC (aucune comptabilisation)	Basis	22:00	En attente
2	Extraction finale des données et rapprochement	Responsable migration des données	22:30	En attente
3	Exécution du chargement de migration en production	DBA	23:00	En attente
4	Import des transports restants en production	Basis	00:30	En attente
5	Bascule du DNS et du répartiteur de charge vers S/4HANA	Réseau	01:30	En attente
6	Test de fumée : comptabilisation FI, réception de marchandises, commande client	Responsable QA	02:00	En attente
7	Confirmation du métier et décision go/no-go	Directeur de programme	03:00	En attente
8	Ouverture du système aux utilisateurs métier	Basis	06:00	En attente

Évaluation de préparation au go-live

Décide si vous êtes réellement prêt à basculer. Des clients ont repoussé leur go-live sur la foi de cette évaluation, et ils m'en ont remercié plus tard.

Domaine	Vérifications (chacune répondue par oui ou non, preuve à l'appui)
Fonctionnel	Processus clés testés ; scénarios inter-modules terminés ; anomalies P1/P2 ouvertes listées ; utilisateurs clés confirmant leur préparation
Données	Chargements des données de base terminés ; données de mouvement validées ; états de rapprochement approuvés ; gel de l'ancien système confirmé
Technique	Plan de cutover approuvé ; transports en production ; jobs batch planifiés ; supervision configurée
Personnes	Taux de couverture de la formation en % ; rôles d'accès validés ; équipe hypercare constituée ; plan de support communiqué
Décision	Risques critiques et mesures d'atténuation listés ; Go / No-go / Conditionnel ; approuvé avec nom, rôle et date

Après le go-live, le travail change de forme. Ces modèles accompagnent le système et l'équipe à travers l'hypercare, puis jusqu'au régime établi.

Modèle de support post-mise en œuvre

Organise la façon de traiter les problèmes après le lancement. Sans lui, chaque problème devient un P1.

Section	Détails
Fenêtre d'hypercare	Semaines 1 à 4 après le go-live : couverture 24 h/24 et 7 j/7
Canaux de support	File d'incidents ServiceNow (principal) ; canal de discussion dédié ; pont téléphonique pour les incidents P1
Niveaux de support	1 : service desk (mots de passe, navigation, problèmes connus) ; 2 : consultants fonctionnels (questions de processus, paramétrage mineur) ; 3 : Basis et développement (erreurs système, performance, interfaces)
SLA (réponse / résolution)	Critique 15 min / 2 h ; Élevée 30 min / 4 h ; Moyenne 4 h / 1 jour ; Faible 1 jour / 3 jours
Supervision	SAP Cloud ALM ou Solution Manager ; revue quotidienne du journal d'erreurs
Critères de sortie	Aucun incident P1/P2 ouvert ; tous les incidents documentés ; signature de la passation finale

Modèle de suivi des performances

Il vous permet de surveiller la santé du système jour après jour et de repérer les ralentissements avant que les utilisateurs ne se plaignent. J'ai récemment aidé une entreprise à détecter ainsi un problème de base de données qui aurait fait tomber son système pendant la clôture mensuelle.

Indicateur	Cible	Outil	Seuil d'alerte	Responsable
Temps de réponse en dialogue (95e centile)	Moins de 1 seconde	ST03 / SAP Cloud ALM	2 secondes	Équipe Basis
Fin des jobs en arrière-plan	100 % selon le planning	SM37 / Application Jobs	Tout job en échec	Responsable exploitation
Temps des requêtes en base	Moins de 200 ms	SAP HANA cockpit	500 ms	DBA
Disponibilité du système	Plus de 99,5 %	SAP Cloud ALM	Moins de 99 %	Infrastructure
Taux d'erreur des interfaces	Moins de 1 %	Supervision de SAP Integration Suite	2 %	Responsable middleware
Taux de réussite des connexions	Plus de 98 %	Journal d'audit de sécurité	Moins de 95 %	Responsable sécurité
Durée du job de clôture mensuelle	Dans la fenêtre convenue	Ordonnanceur de jobs	Plus de 30 % au-dessus de la référence	Finance (exploitation)

Les quality gates empêchent qu'un problème d'une phase ne se transforme en reprise coûteuse dans la suivante. Mon guide des quality gates SAP explique comment les mettre en place. Voici pourquoi ils comptent.

La validation de la direction avant le go-live ne doit pas être un tampon. Sur un projet auquel j'ai participé, le PDG a repéré lors de la revue de go-live un gros problème qui aurait perturbé le travail de l'équipe finance.

Fixez des critères de réussite ou d'échec à chaque gate. « 95 % des tests de non-régression doivent passer. » « Tous les scénarios d'intégration FI sont au vert. » Des critères comme ceux-là vous donnent une base défendable pour tenir bon quand le métier veut lancer à une date donnée, quelle que soit la qualité.

Sur l'un de mes projets, le quality gate nous a arrêtés alors que 75 % seulement des tests d'intégration étaient passés. Nous avons d'abord corrigé les problèmes au lieu de foncer. Cela a épargné au client environ 100 000 € de correctifs d'urgence après le lancement.

Un gate que le sponsor peut annuler d'un coup de téléphone n'est pas un gate. Notez par écrit, avant d'en avoir besoin, qui peut y déroger.

Qu'est-ce que la méthodologie SAP Activate ?

SAP Activate est la méthodologie de mise en œuvre de SAP pour S/4HANA et ses autres produits cloud. Elle se déroule en six phases (Discover, Prepare, Explore, Realize, Deploy, Run) et associe le contenu SAP Best Practices, un paramétrage guidé et une livraison agile.

Les listes de tâches et les modèles de livrables pour chaque scénario de déploiement sont publiés dans le SAP Activate Roadmap Viewer.

Quelle phase de SAP Activate a les modèles les plus importants ?

Prepare. Le document de cadrage, le business case et la matrice des parties prenantes posent les fondations de chaque décision qui suit, et ce sont ceux que les équipes sautent pour arriver plus vite au paramétrage. Ce raccourci est la cause la plus fréquente des litiges de périmètre en Realize.

Explore vient en second. Les lacunes dans les documents de fit-gap et de cartographie des exigences ressortent des mois plus tard sous forme d'anomalies d'UAT, quand les corriger coûte bien plus cher qu'à la semaine 3 d'Explore.

Peut-on personnaliser les modèles SAP Activate ?

Oui. Conservez environ 80 % de la structure standard et ne changez que ce qui est propre à votre contexte : validation pharmaceutique, règles de la commande publique, contrôles SOX. Ajoutez-les au début de Prepare, pas en Deploy.

Ne personnalisez pas la structure des quality gates, l'ordre des phases ni les livrables obligatoires (document de cadrage, business case, évaluation de préparation au go-live).

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

Oui. La principale différence se situe en Explore. Une conversion brownfield reprend le paramétrage existant : le fit-gap porte donc sur ce qui doit changer, sur le code spécifique que S/4HANA standard peut désormais remplacer, et sur le nettoyage de données nécessaire avant la conversion. Un programme greenfield part de SAP Best Practices et confirme quels processus standard conviennent.

Le plan de cutover diffère aussi. Une conversion de système brownfield suit une séquence différente de celle d'un go-live greenfield avec migration complète des données.

Quel niveau de détail pour un plan de cutover ?

Heure par heure au minimum, et plus fin encore pour la fenêtre d'arrêt. Chaque tâche a besoin d'une heure de début, d'un responsable et d'une dépendance.

Convenez des critères de retour arrière avant le début du cutover : quelles conditions déclenchent le retour à l'ancien système, qui prend cette décision, et avant quelle heure. Les décisions de retour arrière prises à 4 h du matin sans critères préalables sont le point de départ des désastres après le go-live.