Migration de SAP ECC vers SAP S/4HANA : guide pratique du Clean Core pour les entreprises françaises

Les métiers s’appuient parfois sur des développements spécifiques ECC que la DSI souhaite remplacer. Ce guide explique comment évaluer les besoins auxquels ils répondent, décider des fonctionnalités à conserver et choisir une approche Clean Core adaptée à votre migration vers SAP S/4HANA.Les métiers s’appuient parfois sur des développements spécifiques ECC que la DSI souhaite remplacer. Ce guide explique comment évaluer les besoins auxquels ils répondent, décider des fonctionnalités à conserver et choisir une approche Clean Core adaptée à votre migration vers SAP S/4HANA.

Une entreprise peut avoir terminé sa migration de SAP ECC vers SAP S/4HANA et devoir encore adapter ses anciens développements spécifiques avant la prochaine montée de version. Un état financier sur mesure peut, par exemple, continuer à lire directement les données d’une table interne SAP dont la structure évolue d’une version à l’autre. La direction financière a toujours besoin de ces chiffres : l’entreprise doit donc financer une nouvelle adaptation de cet état.

Le Clean Core vise à réduire ce travail récurrent en revoyant la manière dont l’entreprise utilise et étend SAP. Lors de la migration, l’équipe peut remplacer cet état par une fonctionnalité déjà disponible dans SAP S/4HANA ou le redévelopper à l’aide des interfaces que SAP prévoit pour les développements clients.

Pour les entreprises françaises, l’enjeu consiste donc à déterminer ce que le nouvel ERP doit reprendre de l’existant.

Pourquoi les entreprises françaises vont au-delà de la conversion technique de SAP ECC

La politique de SAP prévoit une maintenance standard des applications centrales SAP Business Suite 7 éligibles jusqu’à fin 2027, puis une maintenance étendue en option jusqu’à fin 2030. Les conditions dépendent du produit et du niveau d’Enhancement Package (EHP). La planification du projet doit donc tenir compte des versions effectivement installées dans l’environnement SAP. support.sap.com

Une conversion réussie sur le plan technique peut néanmoins laisser en place des états redondants, des interfaces non documentées et des variantes de processus dont la raison d’être a disparu. Autant de dépendances qu’il faudra comprendre avant toute nouvelle évolution.

La réforme française de la facturation électronique illustre cet enjeu. Pour les entreprises entrant dans son champ d’application, le calendrier est le suivant :

• Depuis le 1er septembre 2026, toutes les entreprises concernées, quelle que soit leur taille, doivent pouvoir recevoir des factures électroniques. Les grandes entreprises et les entreprises de taille intermédiaire (ETI) sont également soumises aux obligations d’émission et de transmission des données à l’administration fiscale, ou e-reporting, pour les opérations concernées.
• À compter du 1er septembre 2027, les obligations d’émission et d’e-reporting s’étendront aux PME et aux microentreprises, selon le périmètre applicable à leurs opérations.

Le dispositif concerne des catégories d’opérations définies par la réglementation et repose sur le recours à des plateformes agréées. Les interfaces de facturation, les règles de correspondance des données et le traitement des exceptions doivent donc être examinés dans le cadre du projet de migration ERP.

Une intégration dédiée, reposant sur des interfaces prises en charge, est plus facile à maintenir lorsque son rôle est clairement défini. Ajouter un traitement sur mesure au code de facturation crée de nouvelles dépendances que le projet suivant devra analyser.

Pour un groupe français présent dans plusieurs pays, le même principe s’applique aux états réglementaires locaux et aux processus des filiales : définir un socle commun, puis identifier les particularités locales qui doivent être conservées. La démarche Clean Core intègre ces arbitrages dès le début de la transformation.

Que recouvre l’approche SAP Clean Core ?

L’approche SAP Clean Core consiste à limiter les modifications du code standard de l’ERP et à répondre aux besoins spécifiques par des extensions prises en charge par SAP. Ces extensions utilisent les interfaces prévues pour les développements clients, ce qui réduit leurs dépendances au code interne du logiciel. Lors d’une mise à jour, les développeurs ont ainsi moins de modifications à examiner et à reprendre.

Les fonctionnalités spécifiques peuvent être mises en œuvre à deux endroits :

• Au sein de SAP S/4HANA, avec les outils d’extensibilité destinés aux utilisateurs clés ou aux développeurs. Cette option convient aux fonctionnalités qui doivent s’exécuter directement dans une application ou une transaction de l’ERP.
• Sur SAP Business Technology Platform (SAP BTP), dans une application distincte connectée à SAP S/4HANA. Un portail fournisseurs peut, par exemple, récupérer les informations des commandes d’achat au moyen d’API mises à disposition par SAP à cet effet.

Ces deux options font partie du modèle d’extensibilité de SAP. Le choix dépend des fonctions attendues et des interfaces disponibles dans la version SAP retenue.

Source: SAP

Ce qu’indiquent les niveaux A à D

En août 2025, SAP a présenté une évolution de son modèle Clean Core, qui classe les extensions selon les technologies utilisées et les risques associés aux montées de version. Ces niveaux qualifient les extensions ; ils ne constituent pas quatre étapes obligatoires à franchir par l’entreprise.

Cette distinction est utile dans un environnement SAP ECC enrichi de développements ABAP au fil des années. Le préfixe Z signale un objet développé par le client, mais ne suffit pas à déterminer son risque. SAP évalue une extension selon la technologie ou la dépendance la moins bien classée qu’elle utilise. Il faut donc examiner ce dont dépend le code avant de décider de le remplacer.

Quels développements spécifiques de SAP ECC faut-il conserver ?

Avant de migrer le code spécifique ECC, vérifiez si les métiers en ont toujours besoin et si SAP S/4HANA propose déjà une fonction équivalente. Commencez par quatre questions :

1. Quels développements sont exécutés, et à quels moments ? Examinez les programmes spécifiques, les extensions, les traitements planifiés, les formulaires et les états. Tenez compte des activités saisonnières et des traitements de clôture.
2. Quels éléments en dépendent ? Recensez les applications qui les appellent, les interfaces, les systèmes externes et les composants partagés. Plusieurs transactions peuvent utiliser le même code.
3. À quel besoin répondent-ils ? Identifiez le responsable métier, le besoin couvert et les conséquences d’une suppression. Distinguez les obligations réglementaires, les fonctions qui apportent un avantage concurrentiel et les habitudes héritées de l’existant.
4. Par quoi peuvent-ils être remplacés ? Confrontez le besoin aux fonctionnalités de la version SAP S/4HANA retenue, à ses processus standard et aux points d’extension disponibles.

Les options d’extension pour moderniser le code spécifique ECC

Les exemples suivants illustrent différents choix de conception. La solution à retenir dépend de la version cible, des API disponibles, des contraintes transactionnelles et des coûts d’exploitation.

Les processus standard SAP complétés par des extensions pour utilisateurs clés

Prenons le cas d’un programme d’achat dans ECC qui soumet les commandes supérieures à 10 000 € à la validation d’un responsable. Ce programme comprend également un champ dans lequel les collaborateurs justifient leur achat.

Pour le remplacer lors de la migration vers SAP S/4HANA, l’équipe doit déterminer comment couvrir ces deux besoins. Si le paramétrage standard permet déjà de gérer la règle de validation, le code correspondant peut être supprimé. Le champ de justification peut toutefois rester nécessaire.

Lorsque l’application autorise l’ajout de champs personnalisés, les outils d’extensibilité pour utilisateurs clés permettent de créer ce champ sans modifier le code standard SAP. L’entreprise peut ainsi utiliser le circuit de validation standard tout en conservant l’information complémentaire dont ses équipes ont besoin.

Les règles métier spécifiques au sein de SAP S/4HANA

L’extensibilité on-stack permet aux développeurs d’ajouter des règles métier dans SAP S/4HANA sans modifier le code standard. Cette approche convient aux contrôles qui doivent intervenir pendant une opération dans l’ERP, par exemple pour valider une commande avant son enregistrement. Le contrôle peut utiliser les données de l’ERP et déterminer immédiatement si l’opération peut se poursuivre.

Pour ajouter ce contrôle, les développeurs doivent disposer d’un point d’extension prévu par SAP à l’étape concernée. Lorsque le programme standard atteint ce point, il exécute la logique supplémentaire de l’entreprise. Les développeurs maintiennent cette logique séparément du programme SAP d’origine, même si les deux s’exécutent dans SAP S/4HANA.

Cette option convient lorsque le paramétrage standard ne couvre pas le besoin et qu’un point d’extension adapté est disponible.

Un fabricant peut, par exemple, devoir appliquer une contrainte de production que le paramétrage standard ne permet pas d’exprimer. Une extension on-stack vérifie le matériau et les dimensions au moment où un commercial enregistre une commande. Si cette combinaison ne peut pas être fabriquée, le système indique les corrections nécessaires et bloque l’enregistrement. Le commercial corrige ainsi la commande avant sa transmission à la production.

Les applications distinctes sur SAP BTP

Avec l’extensibilité side-by-side, les entreprises développent des applications en dehors de SAP S/4HANA, notamment sur SAP BTP. Ces applications exécutent leur propre logique métier et peuvent disposer de leur propre interface utilisateur. Elles consultent ou mettent à jour les données de l’ERP par des interfaces prises en charge, sans modifier le code standard SAP.

Cette approche convient aux applications qui réunissent des informations issues de plusieurs systèmes ou qui s’adressent à des utilisateurs ne travaillant pas directement dans SAP S/4HANA. Les équipes peuvent y déployer de nouvelles fonctionnalités selon un calendrier distinct de celui des mises à jour de l’ERP.

L’entreprise doit toutefois assurer la maintenance de cette application et gérer ses connexions. Des interfaces SAP adaptées doivent être disponibles. L’équipe doit également déterminer quel système fait référence pour les données partagées et comment les modifications seront répercutées dans les autres systèmes.

Un portail fournisseurs peut ainsi recueillir les confirmations de livraison de partenaires externes et les transmettre à SAP S/4HANA, où les équipes achats continuent de gérer les commandes.

Les bénéfices du Clean Core

Les choix faits pendant la migration influencent l’utilisation et l’évolution de SAP S/4HANA après sa mise en production. Leurs effets deviennent particulièrement visibles lors d’une montée de version, de l’intégration d’une filiale ou d’une évolution des exigences de reporting.

Des montées de version SAP plus simples

Les modifications du code standard SAP doivent être examinées lors des montées de version. En les réduisant, l’entreprise limite le volume de code à adapter à chaque nouvelle version.

Les équipes peuvent estimer plus précisément le travail restant et planifier la montée de version avec moins de dépendances non résolues. Les processus métiers critiques doivent néanmoins toujours être testés.

Un déploiement plus rapide des nouvelles fonctionnalités

Les extensions prises en charge par SAP permettent d’ajouter des fonctionnalités sans réécrire les programmes standard. Les applications distinctes exécutées sur SAP BTP peuvent également suivre leur propre calendrier de mise en production.

L’entreprise peut donc y introduire de nouvelles fonctionnalités sans attendre une montée de version de l’ERP, à condition de préserver la compatibilité des interfaces.

Des déploiements facilités dans les filiales

Les filiales qui suivent un même processus peuvent partager une extension. Les développeurs réalisent alors la modification une seule fois, puis la déploient dans les entités concernées.

Les exigences propres à chaque pays peuvent être traitées par un paramétrage local ou par des extensions distinctes.

Des données plus cohérentes pour l’intelligence artificielle

La démarche Clean Core comprend aussi un travail sur la cohérence des données : harmonisation des définitions métier, traitement des doublons et correction des divergences entre les systèmes connectés. Ce travail réduit les incohérences dans les informations utilisées par les applications d’IA.

Des identifiants fournisseurs communs aident, par exemple, un assistant achats à rattacher les commandes au bon fournisseur. Les synthèses de l’historique des commandes comportent ainsi moins d’erreurs d’attribution.

Des mises à jour de sécurité et des revues des accès facilitées

La réduction des modifications du code standard SAP peut diminuer les travaux de compatibilité nécessaires avant l’application des correctifs de sécurité.

La documentation des connexions aide également les équipes à identifier les applications qui accèdent aux données métier et les responsables de ces accès. Ces améliorations facilitent les opérations courantes de sécurité ; les contrôles d’accès et la supervision restent nécessaires.

Une réduction des coûts de maintenance

Le Clean Core peut réduire les coûts de maintenance en supprimant le code inutilisé et en limitant les adaptations des développements spécifiques lors des montées de version SAP.

Lorsque certains développements sont remplacés par une application sur SAP BTP, les économies attendues doivent être comparées aux coûts de la plateforme et de la maintenance de cette nouvelle application pour évaluer le gain global.

Quelles trajectoires de migration permettent d’adopter le Clean Core ?

Le choix dépend de la part du système ECC que l’entreprise souhaite conserver et des processus qu’elle prévoit de faire évoluer. SAP distingue trois approches pour passer à SAP S/4HANA : la conversion du système, une nouvelle implémentation et la transition sélective des données.

Pour une migration SAP S/4HANA en France, ces options doivent être évaluées au regard des exigences locales, des déploiements internationaux prévus, de la durée d’indisponibilité acceptable et de la capacité des équipes à adopter de nouveaux processus. Le Clean Core peut guider chacune de ces trajectoires ; le choix de la méthode dépend du contexte de l’entreprise.

Les difficultés courantes et les moyens d’y répondre

Des processus critiques reposent sur du code non documenté

Un programme spécifique ECC peut contenir des règles métier qui n’ont jamais été documentées. Modifier ce code sans comprendre son rôle risque de perturber les achats ou la facturation, notamment lorsque certains cas particuliers ne se présentent qu’occasionnellement.

Mesures à prendre :

• Analysez des transactions réelles avec les équipes concernées pour reconstituer les règles appliquées. Si la solution de remplacement reste incertaine, un prototype ciblé permet de vérifier qu’elle traite les scénarios requis.
• Donnez la priorité au code susceptible de bloquer la migration ou d’interrompre des opérations critiques.

Les équipes perçoivent la standardisation comme une perte de fonctionnalités

Les collaborateurs peuvent s’appuyer sur des raccourcis propres aux écrans spécifiques pour effectuer des tâches répétitives. Le remplacement de ces écrans risque d’ajouter des étapes à leur travail. Les réticences peuvent donc tenir à un risque réel de perte de productivité.

Mesures à prendre :

• Demandez aux utilisateurs d’effectuer leurs tâches habituelles dans la solution envisagée. Repérez les étapes qui nécessitent davantage de temps ou de travail manuel.
• Documentez chaque écart en précisant la tâche concernée et sa fréquence. Ces éléments permettent de décider si le paramétrage ou une extension prise en charge peut répondre au besoin.

Aucune API SAP publiée pour les extensions ne répond à un besoin essentiel

La réalisation d’une fonctionnalité peut nécessiter un accès que SAP ne prévoit pas pour les développements clients. Cette situation restreint les solutions compatibles avec les principes du Clean Core. Certaines techniques utilisables dans ECC peuvent également être incompatibles avec l’édition cible de SAP S/4HANA.

Mesures à prendre :

• Confirmez la limitation pour l’édition et la version retenues, puis étudiez les solutions prises en charge et les adaptations possibles du processus. Si une exception est nécessaire et autorisée dans cette édition, désignez un responsable et documentez les vérifications de compatibilité à réaliser lors des montées de version.
• Fixez une date de réexamen et intégrez tout remplacement prévu au planning du projet. Les restrictions d’extensibilité propres à SAP S/4HANA Cloud Public Edition doivent guider les choix possibles.

De nouveaux développements spécifiques s’accumulent après la mise en production

Des demandes métier urgentes peuvent conduire les équipes à ajouter du code sans vérifier si le standard répond déjà au besoin. À mesure que ces développements s’accumulent, des responsabilités mal définies et des dépendances non documentées alourdissent le support et compliquent les futures montées de version.

Mesures à prendre :

• Examinez chaque extension proposée avant de lancer son développement.
• Confirmez son objectif métier, évaluez les alternatives standard et désignez les responsables des tests et du support dans la durée.
• Mettez à disposition des exemples de développement validés que les équipes peuvent réutiliser.
• Après la mise en production, suivez les exceptions non réexaminées à la date prévue et les incidents liés au code spécifique. Les prochaines actions de rationalisation pourront ainsi cibler les développements qui perturbent le plus l’activité.

Comment LeverX accompagne les entreprises françaises vers un environnement SAP S/4HANA Clean Core

Les services Clean Core de LeverX couvrent l’évaluation de l’environnement SAP, l’analyse des processus métiers, la réduction de la dette technique, la conception des extensions et la gouvernance des évolutions. La démarche comprend des ateliers et des prototypes de validation, ou PoC, pour évaluer les extensions envisagées avant une mise en œuvre plus large.

Pour les entreprises françaises, cet accompagnement peut se structurer autour des étapes du programme SAP S/4HANA et des décisions associées.

Ces services relient la migration vers SAP S/4HANA à la modernisation des applications et à la transformation des processus métiers. L’offre de migration de LeverX couvre également la mise en place du socle SAP BTP, la connectivité, la sécurité, les tests et l’accompagnement après la mise en production.

Pour une entreprise française, le cadrage gagne à réunir la DSI, les responsables de processus et la direction financière autour d’une analyse commune : inventaire du code spécifique, dépendances critiques pour l’activité, exigences locales et version SAP cible. Sur cette base, l’équipe peut planifier les changements en fonction des risques pour l’entreprise et des ressources disponibles.

Échangez avec LeverX pour définir une feuille de route Clean Core adaptée à votre migration de SAP ECC vers SAP S/4HANA.