Qu'est-ce que la mise en œuvre de SAP ? Étapes, phases et processus

La mise en œuvre de SAP est le programme qui fait passer la finance, les achats, la supply chain, les ventes et les RH d'une entreprise sur un seul système SAP, aujourd'hui le plus souvent SAP S/4HANA. Elle suit les six phases de SAP Activate (Discover, Prepare, Explore, Realize, Deploy et Run), et elle réussit ou échoue sur le travail mené sur les processus, les données et les personnes avant que quiconque ne paramètre quoi que ce soit.

En bref : un projet de mise en œuvre SAP remplace des systèmes historiques distincts par un seul système et un seul modèle de données. Le processus compte six étapes : confirmer le business case, mobiliser l'équipe, concevoir à partir du standard SAP, construire et tester, passer en production, puis stabiliser et transférer. D'après mon expérience, il faut 6 à 9 mois avec GROW with SAP et 9 à 18 mois avec RISE with SAP, et mon guide du calendrier de mise en œuvre SAP détaille ces durées phase par phase.

Sur les 21 programmes SAP que j'ai dirigés, redressés ou vus déraper, le schéma est toujours le même. Les entreprises qui traitent SAP comme une installation de logiciel peinent. Celles qui refondent d'abord leurs processus et paramètrent ensuite livrent ce qu'elles ont promis au conseil d'administration.

Ce guide s'adresse aux dirigeants et aux responsables de programme sur le point d'en lancer un. Si vous ne lisez qu'une section, lisez « Planifier avant de commencer le paramétrage ».

S/4HANA est l'ERP actuel de SAP et fonctionne sur la base de données en mémoire SAP HANA. Beaucoup d'entreprises utilisent encore l'ancien SAP ECC, mais la maintenance standard d'ECC prend fin le 31 décembre 2027, avec une maintenance étendue optionnelle jusqu'à fin 2030, plus chère.

Voici les modules cœur que la plupart des mises en œuvre abordent en premier :

Module	Ce qu'il gère
FI (comptabilité financière)	Grand livre, comptabilité fournisseurs, comptabilité clients, comptabilité des immobilisations
CO (contrôle de gestion)	Centres de coûts, centres de profit, ordres internes, reporting de gestion
MM (gestion des articles)	Achats, stocks, mouvements de marchandises, gestion des fournisseurs
SD (administration des ventes)	Order-to-cash, tarification, expédition, facturation
PP (planification de la production)	Ordres de fabrication, planification des capacités, MRP
HCM (gestion du capital humain)	Données de base RH, paie, gestion des temps

La plupart des entreprises commencent par FI/CO et un ou deux modules opérationnels. Le reste se construit dans les versions suivantes.

Une mise en œuvre n'est pas une migration. Si vous utilisez déjà SAP ECC, vous convertissez ou reconstruisez un système SAP, et mon guide de migration d'ECC vers S/4HANA couvre les approches greenfield, brownfield et sélective.

SAP Activate est la méthodologie de mise en œuvre de SAP. Elle a remplacé l'ancienne méthode ASAP et compte six phases, chacune fermée par un jalon de validation à franchir avant d'avancer.

Les six phases de SAP Activate

1. 01

   Discover

   Confirmer le business case et tester les processus prioritaires sur un système d'essai ou de démonstration.

2. 02

   Prepare

   Mobiliser : équipe, gouvernance, document de périmètre, planning et accès aux systèmes.

3. 03

   Explore

   Ateliers Fit-to-Standard avec les responsables de processus. Constituer le backlog de paramétrage, d'interfaces et d'extensions.

4. 04

   Realize

   Paramétrer, étendre, migrer les données et tester. La phase la plus longue. La sortie exige une campagne de non-régression propre.

5. 05

   Deploy

   Former les utilisateurs sur des processus réels, répéter la bascule, passer en production avec une war room en place.

6. 06

   Run

   Hypercare, optimisation et transfert au centre d'excellence.

Ce tableau est la version que j'épingle au mur du bureau de programme. Il montre ce que chaque phase doit produire, qui en est responsable et ce qui doit être acquis avant que la phase suivante commence.

Phase	Livrables attendus	Responsable	Condition de passage
Discover	Business case, périmètre cible, choix de déploiement	Sponsor et CFO	Financement approuvé
Prepare	Document de périmètre, planning, gouvernance, équipe en place	Directeur de programme	Le sponsor signe le périmètre
Explore	Résultats Fit-to-Standard, backlog, décisions d'extension	Architecte solution avec les responsables de processus	Aucun écart non résolu
Realize	Système paramétré et testé, données de test migrées	Responsables fonctionnels et techniques	Campagne de non-régression propre ; les données se rapprochent
Deploy	Utilisateurs formés, bascule répétée, dossier go/no-go	Responsable de la bascule	Répétition de clôture sur trois jours réussie
Run	Journal d'hypercare, transfert au CoE, backlog de phase 2	Responsable de la prestation de services	Aucun P1/P2 ouvert ; le CoE accepte

Les modèles associés à chaque phase se trouvent dans mon guide des modèles SAP Activate.

Cinq étapes ou six ?

On cherche les « 5 étapes de la mise en œuvre SAP » parce que l'ancienne méthode ASAP de SAP comptait cinq phases. C'étaient la préparation du projet, le Business Blueprint, la réalisation, la préparation finale, et le démarrage et support.

SAP Activate garde la même logique et ajoute Discover au début et Run à la fin. Les phases Prepare à Deploy sont généralement considérées comme le cœur de la réalisation. Les équipes qui parlent encore de « blueprint » désignent en général Explore.

Le jalon de la répétition de clôture sur trois jours

Le jalon entre Realize et Deploy est celui que les équipes sautent le plus souvent sous la pression du planning. J'utilise une répétition de clôture sur trois jours comme jalon de préparation sur chaque programme. Si la finance ne peut pas clôturer les comptes sur le nouveau système, votre migration des données n'est pas prête, quoi qu'en dise la DSI.

Sauter ce jalon coûte plus cher que le retard qu'il aurait causé.

L'ordre compte. Quatre choses doivent être faites avant la moindre décision de paramétrage.

1. 01Cartographier les processus actuelsTels qu'ils fonctionnent vraiment, contournements compris
2. 02Choisir standard ou extensionLe standard est presque toujours plus rapide
3. 03Auditer la qualité des donnéesAvant le début de la migration des données
4. 04Constituer l'équipe, puis figer le périmètreLes personnes disponibles déterminent ce que vous pouvez livrer

Le paramétrage ne commence qu'à ce moment-là

La plus grosse erreur que je vois, c'est de ne pas planifier correctement au départ. Les budgets dérapent en Explore, quand la liste des workflows, états, interfaces, conversions, améliorations et formulaires (WRICEF) s'allonge et que c'est le prestataire, et non le client, qui contrôle le périmètre. Ma ventilation des coûts de mise en œuvre SAP montre ce que cela fait au budget.

Cartographier les processus tels qu'ils fonctionnent vraiment

Pas ce que le processus est censé être. Ce qu'il est réellement, contournements compris.

Sur un programme dans les services financiers en Europe en 2023, j'ai assisté à une session de blueprint où la finance rapprochait les transactions intragroupe dans des tableurs. C'est dans les contournements que se cachent les exigences que personne n'a écrites.

Choisir entre standard et extension pour chaque processus

Identifiez les processus couverts par les fonctionnalités standard de SAP et ceux qui demandent une extension. Le standard est presque toujours plus rapide, car chaque extension ajoute des cycles de test, un risque lors des mises à niveau et de la maintenance.

Avec les recommandations clean core de SAP, chaque extension doit aussi être placée à un endroit choisi délibérément. La décision pèse donc plus lourd, pas moins.

Auditer la qualité des données avant la migration

Les données sont le chantier le plus sous-estimé. D'après mon expérience, la migration des données représente 30 à 40 % de l'effort de mise en œuvre.

Un client avait plus de 18 000 doublons dans ses fiches clients. Les corriger après le go-live a perturbé la facturation pendant des semaines. Profilez les données tôt et nettoyez-les dans le système source ; mon guide sur les raisons de l'échec des migrations de données SAP explique comment.

Constituer l'équipe d'abord, figer le périmètre ensuite

Le périmètre que vous pouvez livrer dépend des personnes disponibles pour paramétrer, tester et porter chaque chantier. Les équipes qui fixent le périmètre d'abord et staffent ensuite passent des mois à reconstruire ce sur quoi elles se sont trop engagées.

Un projet de mise en œuvre SAP a besoin de personnes nommées dans ces rôles, la plupart de votre côté, pas de celui de l'intégrateur :

1. Sponsor exécutif. Porte le business case et tranche les désaccords. En général le CFO ou le COO.
2. Directeur de programme. Pilote le planning, le budget et le comité de pilotage. Salarié de votre entreprise ou indépendant de l'intégrateur.
3. Responsables de processus. Un par domaine (finance, achats, ventes, production). Ils valident la conception et sont responsables du résultat après le go-live.
4. Architecte solution. Garde la cohérence de la conception d'ensemble et décide où vit chaque extension.
5. Responsables fonctionnels et techniques. Paramètrent, développent et testent. En général l'équipe de l'intégrateur.
6. Responsable de la migration des données. Nommé en Prepare, pas en Realize.
7. Responsable de la conduite du changement et de la formation. Commence à parler aux utilisateurs finaux dès Explore.
8. Responsable de la bascule. Porte le runbook du go-live et le dossier go/no-go.

Une règle compte plus que la liste. L'intégrateur qui réalisera le travail ne doit pas rédiger votre business case.

Son intérêt est de démarrer. Le vôtre est de terminer.

Voici les difficultés que je vois sur presque chaque programme, avec la parade pour chacune :

Difficulté	À quoi elle ressemble	Que faire
Dérive du périmètre	Les demandes « tant qu'on y est, ajoutez juste... » s'accumulent	Contrôle formel des changements dès le premier jour ; chaque demande fait l'objet d'une analyse d'impact
Qualité des données	La migration révèle des incohérences dont personne ne soupçonnait l'existence	Profiler les données tôt ; nettoyer dans le système source
Résistance des utilisateurs	Les utilisateurs reviennent à Excel dans les deux semaines suivant le go-live	Associer les utilisateurs finaux à la conception dès Explore
Échecs d'intégration	Les connexions avec les systèmes tiers cassent en recette (UAT)	Cartographier les interfaces en Explore ; tester tôt avec des volumes réalistes
Cycles de test raccourcis	La non-régression est écourtée pour tenir une date	Protéger les phases de test ; un retard en construction ne doit pas comprimer les tests
Fatigue de l'équipe	Le moral baisse, les taux d'anomalies montent dans la dernière ligne droite	La suivre avec un simple indice de ressenti hebdomadaire

Sur la fatigue de l'équipe, je suis un indice de ressenti hebdomadaire très simple. Quand plus de 25 % de l'équipe se disent débordés, les taux d'anomalies en test s'envolent.

Sur un programme industriel dans le Golfe (CCG) en 2024, l'équipe a sauté les tests de non-régression pour rattraper trois semaines de planning. La finance n'a ensuite pas pu rapprocher des états clés, et des mois de remise en ordre ont suivi. Ce n'était pas un défaut du système, juste une décision évitable.

Avant, pendant et après le go-live

Avant le go-live, faites la répétition de clôture, validez les données migrées avec des états de rapprochement et formez sur des processus réels plutôt que sur des scénarios de démonstration. Testez le plan de retour arrière. Passez en revue les critères go/no-go avec le comité de pilotage et obtenez une validation explicite, pas des hochements de tête implicites.

Pendant le go-live, renforcez la surveillance et gardez l'équipe de bascule disponible 24 heures sur 24 pendant les 72 premières heures. Les décisions prises pendant ces heures déterminent si l'hypercare s'ouvre dans la confiance ou avec une file d'attente.

Après le go-live, menez l'hypercare pendant au moins quatre semaines et suivez les tickets de support par catégorie. Ils vous montrent où la formation a échoué et où le paramétrage doit être ajusté.

Sur un programme industriel européen en 2024, le client tombait sans cesse en rupture de matières premières. Les achats accusaient les planificateurs, et les planificateurs accusaient des tableurs auxquels personne ne se fiait. Nous avons remplacé ce dispositif par S/4HANA en nous appuyant fortement sur SAP PP avec un paramétrage MRP rigoureux.

Les niveaux de stock sont passés de l'estimation à la donnée en temps réel, et les commandes d'achat se déclenchaient selon le besoin. Au cours des six premiers mois, les ruptures de matières premières ont baissé de plus de 50 %. Le résultat est venu de la refonte des processus qui a précédé le paramétrage, car PP sans ce travail sur les processus aurait seulement produit plus vite de mauvaises réponses.

Sur un programme dans les services professionnels au Royaume-Uni en 2024, le problème était la finance. La clôture mensuelle prenait plus de deux semaines et les états étaient refaits à la main. Nous avons déployé SAP Finance par étapes sous un comité de pilotage très impliqué.

La clôture mensuelle est descendue à un peu plus d'une semaine. Le CFO m'a dit que les chiffres « semblaient crédibles ».

Un guide écrit pour 2022 ne résiste pas au contact d'un acheteur de 2026. Trois changements doivent être intégrés dès le lancement.

Les éditions cloud sont la norme

SAP vend désormais deux éditions d'ERP cloud : SAP Cloud ERP (l'édition publique, anciennement S/4HANA Cloud Public Edition) et SAP Cloud ERP Private (l'édition privée). RISE with SAP associe l'édition privée à une exploitation assurée par SAP et à une chaîne d'outils qui comprend SAP Signavio, SAP LeanIX et SAP Cloud ALM. GROW with SAP est l'offre destinée aux entreprises de taille intermédiaire sur l'édition publique.

Le choix de l'édition se place désormais au-dessus des anciens débats sur le déploiement. Big bang ou par phases, greenfield, brownfield ou sélectif : ce sont des choix que vous faites à l'intérieur de l'édition, pas à sa place.

Le clean core est gradué, pas binaire

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 stables, soit en side-by-side sur SAP BTP, soit dans le système avec ABAP Cloud. Le niveau B autorise des API classiques encore considérées comme propres, le niveau C exige des mesures particulières et le niveau D n'est pas propre.

L'édition publique n'autorise que des extensions de niveau A. L'édition privée et l'on-premise autorisent les extensions classiques : la discipline y vient donc de la gouvernance, pas d'une plateforme qui vous bloque. Décidez du niveau et de l'emplacement de chaque extension en Explore, et désignez une personne capable de dire non.

L'IA dans l'équipe de réalisation

Joule est désormais intégré au SAP Activate Roadmap Viewer et à SAP Cloud ALM, où il répond aux questions sur les tâches et rédige du contenu à partir de la méthodologie. SAP Build Code, disponible depuis 2024, utilise Joule pour générer la logique applicative, les modèles de données et les tests des extensions Java et JavaScript sur SAP BTP. SAP a ajouté une aide comparable par IA générative pour les développeurs ABAP.

Mon avis : l'IA dans les programmes SAP est bien réelle, mais c'est la qualité des données qui en fait la valeur. Une documentation de processus propre et des données de base propres produisent un résultat utile, alors que des données sales produisent du bruit très sûr de lui. Rien de tout cela ne supprime le besoin d'une personne responsable de chaque décision.

Les phases s'appliquent toujours et l'ordre du travail compte toujours. Un programme qui intègre dès le lancement le choix de l'édition, la discipline sur les extensions et les nouveaux outils les traite comme des contraintes de conception. Celui qui les ignore passe ses trois premiers mois à découvrir ce qui a changé, généralement à travers les demandes de changement de l'intégrateur.

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.

Qu'est-ce que la mise en œuvre de SAP, en termes simples ?

C'est le projet qui consiste à mettre en place le logiciel SAP pour faire tourner les processus cœur d'une entreprise, comme la finance, les achats, les ventes et les RH, dans un seul système avec un seul modèle de données. Il couvre la conception des processus, le paramétrage, la migration des données, les tests, la formation et le go-live, en suivant généralement la méthodologie SAP Activate.

Quelles sont les 5 étapes de la mise en œuvre SAP ?

Les cinq étapes viennent de l'ancienne méthode ASAP de SAP : préparation du projet, Business Blueprint, réalisation, préparation finale, et démarrage et support. SAP Activate a remplacé ASAP et utilise six phases, en ajoutant Discover au début et Run à la fin.

Quelles sont les six phases de SAP Activate ?

Discover (business case et adéquation), Prepare (équipe, gouvernance, planning), Explore (ateliers Fit-to-Standard et backlog), Realize (paramétrer, étendre, migrer, tester), Deploy (former, répéter la bascule, passer en production) et Run (hypercare et transfert au centre d'excellence).

Quelle est la différence entre une mise en œuvre SAP et une migration SAP ?

Une mise en œuvre met SAP en place, en remplaçant généralement des systèmes non SAP ou historiques. Une migration fait passer un système SAP ECC existant vers S/4HANA, par conversion (brownfield), par une nouvelle construction (greenfield) ou par une transition sélective des données. Les deux suivent les phases de SAP Activate.

Qui doit faire partie d'une équipe de mise en œuvre SAP ?

Un sponsor exécutif, un directeur de programme, des responsables de processus pour chaque domaine, un architecte solution, des responsables fonctionnels et techniques, un responsable de la migration des données, un responsable de la conduite du changement et de la formation et un responsable de la bascule. Le sponsor, les responsables de processus et le responsable des données doivent venir de votre côté, pas de celui de l'intégrateur.

Pourquoi les mises en œuvre SAP échouent-elles le plus souvent ?

Trois causes profondes apparaissent sur presque chaque programme en difficulté. Le travail sur les processus est sauté, la qualité des données est ignorée jusqu'à la bascule et la conduite du changement est réduite à de la formation.

Une cause plus récente : un intégrateur qui développe des extensions sans plan clean core. Cela laisse une dette qui ressort à la première mise à niveau majeure.

Comment choisir le bon intégrateur pour une mise en œuvre SAP ?

Cherchez une expérience dans votre secteur à votre échelle, avec des références que vous pouvez réellement appeler. La personne présente à la soutenance doit diriger le programme. Demandez combien d'extensions SAP BTP et ABAP Cloud ils ont développées, et demandez à les voir.

Qu'est-ce que RISE with SAP et est-ce adapté à mon organisation ?

RISE with SAP est l'offre d'abonnement de SAP pour SAP Cloud ERP Private : le logiciel, l'infrastructure et l'exploitation gérées par SAP, et une chaîne d'outils pour l'analyse des processus, l'architecture et la gestion du cycle de vie. C'est toujours votre intégrateur qui réalise la mise en œuvre.

Elle convient aux grandes organisations qui quittent ECC et veulent un seul contrat SAP pour la plateforme et l'exploitation. Les entreprises de taille intermédiaire capables de rester proches du standard devraient regarder GROW with SAP sur l'édition publique.