SAP Clean Core : définition, niveaux A à D et gouvernance

SAP Clean Core consiste à garder votre système S/4HANA aussi proche du standard SAP que votre activité le permet. Tout ce que vous ajoutez passe par des interfaces que SAP a publiées et s'est engagé à maintenir stables, pour que les montées de version ne le cassent pas.

La réponse courte : le Clean Core est une discipline qui encadre la façon dont vous étendez et gouvernez SAP. La logique spécifique s'exécute on-stack avec ABAP Cloud ou side-by-side sur SAP BTP, et SAP note chaque extension du niveau A (le plus propre) au niveau D (modifications à supprimer). Le bénéfice, ce sont des montées de version plus rapides : j'ai vu des entreprises réduire ainsi de 40 % la durée de leurs montées de version.

Si votre système est rempli de modifications d'objets standard SAP, chaque release devient un projet de non-régression. Si votre logique spécifique se trouve derrière des interfaces publiées, les montées de version deviennent de la maintenance courante.

J'ai vu des entreprises réduire de 40 % la durée de leurs montées de version en appliquant les principes du Clean Core. Elles y sont parvenues en limitant les personnalisations au strict minimum et en gouvernant celles qu'elles ont gardées.

En 2024, une entreprise européenne de biens de consommation a remplacé sa logique de prix historique par une application Fiori modulaire construite hors du cœur, sur SAP BTP. Cela a supprimé entièrement les tests de non-régression pour cette logique.

Vous pouvez toujours personnaliser un ERP Clean Core. La personnalisation doit utiliser des interfaces que SAP a publiées et s'est engagé à maintenir stables. SAP propose deux façons de le faire :

• On-stack, avec ABAP Cloud. Les extensions s'exécutent dans S/4HANA mais n'utilisent que des API et des points d'extension publiés.
• Side-by-side, sur SAP BTP. Les extensions s'exécutent comme des applications distinctes et dialoguent avec S/4HANA via des API ou des événements.

SAP décrit son approche comme BTP-first, avec un choix au cas par cas. D'après mon expérience, l'endroit où le code s'exécute compte moins que la question de savoir si le besoin exige du code.

Un cœur « sale » paraîtra familier à quiconque a exploité ECC : programmes standard modifiés, tables Z écrites directement, interfaces qui lisent les éléments internes de SAP, améliorations implicites que personne n'a documentées. Rien de tout cela n'était faux au moment où on l'a construit. Ce n'était simplement pas conçu pour un système qui monte de version tous les un ou deux ans.

J’aborde aussi ce sujet dans une vidéo sur ma chaîne YouTube (en anglais).

SAP organise le Clean Core autour de cinq principes directeurs. Voici comment SAP présente chacun d'eux, et ce que je regarde en premier :

Principe	Ce que SAP entend par là	Ce que je vérifie en premier
Processus	Rester aussi proche que possible du processus standard SAP	Quelles variantes de processus n'existent que parce que « nous avons toujours fait comme ça »
Extensibilité	Des extensions découplées du cœur via des API publiées, avec une gouvernance sur l'option utilisée	Combien de code spécifique existe, combien est utilisé, et à quel niveau il se situe
Données	Des données propres et conformes, avec un modèle de gouvernance établi	Données de base en double et incomplètes, champs spécifiques que personne ne sait expliquer
Intégrations	Des connexions standardisées et sécurisées, fondées sur des technologies prises en charge	Interfaces point à point qui lisent directement les tables
Exploitation	La gouvernance, les personnes, les processus et les outils qui maintiennent les quatre autres en place	Qui approuve une extension, et ce qui empêche la prochaine modification

La plupart des équipes commencent et finissent par l'extensibilité, parce que c'est le plus facile à mesurer. D'après mon expérience, les processus et les données causent davantage de retard. Le code spécifique est généralement le symptôme, et le processus qui se cache derrière en est la cause.

En août 2025, SAP a remplacé son ancien modèle d'extensibilité à trois niveaux par le concept de niveaux Clean Core. Chaque extension est notée selon sa façon d'être construite, son degré de découplage par rapport au cœur et sa capacité à survivre sans risque à une montée de version. Si vous lisez d'anciens documents SAP qui parlent de tiers, c'est ce concept qui les a remplacés.

Niveau ANiveau BNiveau CNiveau D

Ce qu'il utiliseNiveau AUniquement des interfaces publiques publiées et stablesNiveau BAussi les API classiques de SAPNiveau CDes objets internes SAPNiveau DModifications, écritures dans les tables SAP, améliorations implicites

Risque à la montée de versionNiveau ALe plus faible, couvert par des contrats de stabilitéNiveau BGénéralement stable aux montées de versionNiveau CÀ vérifier à chaque montée de versionNiveau DLe plus élevé

Ce qu'il faut déciderNiveau ALe choix par défaut pour tout nouveau développementNiveau BAccepter, en consignant la raisonNiveau CAccepter avec une raison, revérifier à chaque montée de versionNiveau DSupprimer en premier, ou le faire passer en B ou C

Source: Concept de niveaux Clean Core de SAP, SAP News, août 2025

Le niveau A n'utilise que des interfaces publiques publiées avec contrats de stabilité, construites avec SAP Build, ABAP Cloud ou BTP. Le niveau B y ajoute les API classiques de SAP. Le niveau C touche des objets internes SAP, et SAP prévoit pour ceux-ci un journal des modifications afin d'aider à planifier les montées de version.

Le niveau D regroupe les modifications, les écritures dans les tables SAP, les améliorations implicites et d'autres techniques que SAP ne recommande pas. C'est plus utile que l'ancien débat « propre ou pas propre », parce que cela vous permet de fixer une cible par objet. Faire passer vos objets de niveau D en B ou C avant une montée de version, c'est déjà une vraie réduction du risque.

ABAP Cloud est le modèle de développement ABAP de SAP conçu pour le cloud. Les développeurs utilisent la version de langage « ABAP for Cloud Development » et ne peuvent construire que sur des objets publiés, des API publiques et des points d'extension. Il est né dans l'environnement ABAP de SAP BTP et il est désormais disponible dans toutes les éditions de S/4HANA (SAP ABAP Cloud FAQ).

S/4HANA Cloud vous offre trois voies d'extension. L'extensibilité pour utilisateurs clés couvre les modifications simples de champs, de logique et d'interface sans toucher au code SAP. L'extensibilité développeur avec ABAP Cloud prend en charge la logique fortement couplée, et les extensions side-by-side sur SAP BTP prennent en charge tout ce qui doit rester découplé.

L'édition détermine votre marge de choix :

	S/4HANA Cloud Public Edition	S/4HANA Cloud Private Edition et on-premise
Développement ABAP	ABAP Cloud uniquement, obligatoire pour les nouveaux clients depuis la release 2208	ABAP Cloud recommandé depuis 2022 ; ABAP classique toujours autorisé
Modifications du code SAP	Impossibles	Possibles, mais elles sont de niveau D
Extensions utilisateurs clés et side-by-side sur BTP	Disponibles	Disponibles
Qui impose le Clean Core	Le système	Votre gouvernance

Ma règle pour les clients en Private Edition : traitez-la comme s'il s'agissait de la Public Edition pour tout nouveau développement. L'ABAP classique est autorisé, mais chaque objet classique que vous ajoutez aujourd'hui est une décision que quelqu'un devra défendre à la prochaine montée de version.

Les décisions Clean Core doivent être portées par une design authority réunissant le métier et l'IT. L'IT seule approuvera tout ce qui est techniquement possible. Le métier seul redemandera son ancien processus.

Voici comment je la mettrais en place :

1. Nommez les membres. Les responsables de processus métier de chaque grand domaine, plus l'architecte de la solution et le développeur principal. Les responsables métier décident si un besoin est réel, et l'IT décide comment il est construit.
2. Fixez l'ordre de préférence avant le début de la réalisation. D'abord le processus standard, puis l'extensibilité pour utilisateurs clés, puis le niveau A sur ABAP Cloud ou BTP. Le niveau B ou C exige une justification écrite, et le niveau D un plan de sortie.
3. Exigez que chaque demande d'extension ait un responsable et une raison métier. Pas de responsable, pas de développement. La décision et le niveau accepté vont dans un registre unique.
4. Placez un contrôle technique en amont des transports. Exécutez de façon planifiée les contrôles Clean Core de l'ABAP test cockpit, et bloquez le nouveau code de niveau D avant qu'il n'atteigne la production.
5. Revoyez le registre avant chaque montée de version. Retirez ce que plus personne n'utilise et faites monter tout ce qui peut désormais atteindre un niveau supérieur.

Autour de cette table, la question était autrefois « pourquoi cela ne peut-il pas vivre sur BTP ? ». Aujourd'hui, je demanderais « pourquoi cela ne peut-il pas être de niveau A ? ». Si ce n'est pas possible, la question suivante est de savoir quel niveau vous acceptez, et pourquoi.

La plus grosse erreur Clean Core que je vois, c'est de vouloir faire fonctionner SAP comme Oracle. Adoptez les processus standard de SAP plutôt que de reconstruire en code spécifique la logique d'un autre système. Si vous hésitez encore entre les deux, je les compare dans SAP vs Oracle.

Le Clean Core est un problème de conduite du changement avant d'être un problème technique. Chaque objet spécifique existe parce que quelqu'un l'a demandé. Le supprimer, c'est convaincre cette personne que le processus standard suffit.

Cette conversation se passe mieux quand le métier voit le nouveau processus fonctionner, pas une diapositive qui le décrit. Elle se passe mieux aussi quand vous mettez à l'épreuve l'affirmation selon laquelle un processus est unique, car souvent il ne l'est pas (voir les étapes 4 et 5 ci-dessous).

Les compétences comptent autant que les outils. Une équipe ABAP qui n'a jamais travaillé avec ABAP Cloud ou BTP ralentira le programme le temps d'apprendre. Un industriel avec qui j'ai travaillé a mené un programme interne BTP de trois mois avant le démarrage de son projet S/4HANA, et cela a payé : moins de surprises pendant la réalisation.

La conformité Clean Core, c'est la part de votre système qui respecte les critères de SAP sur les cinq principes. Vous ne pouvez pas la piloter sans chiffres, et SAP vous donne trois endroits où les obtenir.

1. L'ABAP test cockpit. L'outil SAP pour les contrôles au niveau du code. Il montre quels objets spécifiques utilisent des objets non publiés, des modifications ou un accès direct aux tables.
2. Le SAP Readiness Check. Il est inclus dans votre contrat de maintenance et montre ce qu'un passage à S/4HANA va toucher avant que vous ne vous engagiez.
3. Le RISE with SAP Methodology dashboard, aussi appelé clean core dashboard. Il s'exécute dans SAP Cloud ALM. Sa vue système vérifie votre version de S/4HANA, confirme que les outils de collecte de données sont actifs et passe en revue les extensions avant une montée de version, et sa vue exploitation suit les KPI opérationnels.

Les chiffres que je présenterais chaque mois à la design authority sont simples. Combien d'objets spécifiques se trouvent à chaque niveau, et le niveau D diminue-t-il ? Combien d'exceptions sont ouvertes, et chacune a-t-elle un responsable ?

Si vous me demandiez d'évaluer votre système le mois prochain, voici l'ordre que je suivrais.

1. Identifiez ce qui est utilisé. Lancez le SAP Readiness Check et collectez des données d'utilisation sur votre code spécifique. Sur un programme, l'analyse avec smartShift nous a fait passer de 18 000 objets spécifiques à 3 200, parce que l'essentiel du reste n'était tout simplement pas utilisé.
2. Classez ce qui reste dans les niveaux A à D. Utilisez l'ABAP test cockpit pour le code. Si vous êtes sur RISE, le clean core dashboard prend le suivi à partir de là.
3. Décidez objet par objet. Le retirer, le faire passer sur une interface publiée, le reconstruire sur BTP ou le conserver avec une raison documentée. Commencez par le code qui s'exécute tous les jours, car un rapport utilisé deux fois par an par une équipe régionale peut attendre.
4. Faites entrer le métier dans la pièce. Un responsable financier avec qui j'ai travaillé n'a compris sa nouvelle application Fiori qu'après une démonstration de 45 minutes. Cette séance a évité deux semaines d'allers-retours en recette utilisateur (UAT).
5. Remettez en question le « notre processus est différent ». Lors d'un atelier avec l'équipe commerciale d'un industriel européen en 2023, le processus « unique » s'est révélé être à 80 % de l'administration héritée redondante. Le standard SAP a amélioré leur expérience client une fois les contournements supprimés.
6. Commencez tôt le travail sur les données. Un client de la distribution dans le CCG avec qui j'ai travaillé en 2024 avait plus de 15 000 champs spécifiques à trier. D'après mon expérience, la migration des données représente 30 à 40 % de l'effort de mise en œuvre, et mon guide des coûts de mise en œuvre SAP montre où cela se situe dans le budget.
7. Mettez en place la gouvernance avant le go-live. Installez la design authority décrite plus haut et faites-en la seule voie possible pour une nouvelle extension.

Trois questions reviennent dans presque toutes les conversations que j'ai sur ce sujet.

Le Clean Core est-il obligatoire avec RISE with SAP ?

Pas comme règle générale. En Public Edition, le système l'impose, tandis qu'en Private Edition et on-premise vous pouvez toujours modifier le cœur.

Là, le Clean Core est un choix de gouvernance que SAP suit via le RISE methodology dashboard. Si un intégrateur vous dit que c'est contractuel, demandez-lui de vous montrer la clause.

Combien de temps me reste-t-il sur ECC ?

Pour SAP ERP 6.0 avec les enhancement packages 6 à 8, la maintenance standard prend fin le 31 décembre 2027. La maintenance étendue optionnelle court jusqu'au 31 décembre 2030, moyennant un surcoût.

Ensuite, l'option de transition SAP ERP, private edition couvre 2031 à 2033. Elle ne s'applique qu'aux grands systèmes déjà passés sur SAP ERP, private edition sur SAP HANA avant la fin de 2030.

Considérez 2033 comme une voie d'exception, pas comme une date de planification. Mon guide de migration d'ECC vers S/4HANA couvre les choix de trajectoire.

Le Clean Core compte-t-il pour l'AI ?

Oui. Rester sur le standard SAP aide l'AI et Joule à mieux fonctionner, et c'est sur les processus fortement modifiés qu'ils sont le plus difficiles à adopter.

SAP construit ses fonctionnalités d'AI, dont Joule, sur ses processus standard et son modèle de données. Joule for developers génère du code ABAP Cloud qui s'appuie sur des API publiées. J'explique comment le cloud, l'AI et le Clean Core s'articulent dans modernisation de l'ERP.

Les équipes qui font l'impasse sur le Clean Core n'évitent pas le travail. Elles le repoussent, et il revient sous forme de montées de version bloquées, de marathons de tests de non-régression et de code spécifique que personne ne comprend.

Avant de signer un contrat S/4HANA ou RISE, demandez à votre intégrateur de classer votre code spécifique actuel dans les niveaux A à D. S'il n'est pas capable de le produire, cela vous dit quelque chose sur son estimation. Réservez un appel et nous examinerons votre situation.

Qu'est-ce que le Clean Core dans SAP ?

Le Clean Core consiste à garder S/4HANA proche du standard SAP et à ne construire des extensions que via des interfaces que SAP a publiées et s'est engagé à maintenir stables. Les extensions s'exécutent soit on-stack avec ABAP Cloud, soit side-by-side sur SAP BTP. L'objectif est que les montées de version ne cassent pas votre logique spécifique.

Quels sont les cinq principes de SAP Clean Core ?

Les cinq principes directeurs du Clean Core selon SAP sont les processus, l'extensibilité, les données, les intégrations et l'exploitation. Les processus restent proches du standard, les extensions utilisent des API publiées et les données restent propres dans le cadre d'un modèle de gouvernance. Les intégrations reposent sur des technologies prises en charge, et l'exploitation couvre la gouvernance, les personnes et les outils qui maintiennent les quatre autres en place.

Que sont les niveaux A, B, C et D de SAP Clean Core ?

Depuis août 2025, SAP classe les extensions en quatre niveaux. Le niveau A n'utilise que des interfaces publiques publiées et stables, le niveau B utilise en plus les API SAP classiques, et le niveau C accède à des objets internes SAP. Le niveau D couvre les modifications, les écritures dans les tables SAP et les améliorations implicites, et présente le risque le plus élevé lors des montées de version.

Le Clean Core est-il obligatoire pour RISE with SAP ?

Pas comme règle générale. S/4HANA Cloud Public Edition n'autorise qu'ABAP Cloud et les interfaces publiées, elle impose donc techniquement le Clean Core. En Private Edition, vous pouvez toujours modifier le cœur, si bien que le Clean Core y est une décision de gouvernance que SAP suit via le RISE with SAP Methodology dashboard.

Qu'est-ce qu'ABAP Cloud ?

ABAP Cloud est le modèle de développement ABAP de SAP conçu pour le cloud. Il n'autorise que les objets publiés, les API publiques et les points d'extension, ce qui rend le code spécifique stable lors des montées de version. Il est obligatoire dans S/4HANA Cloud Public Edition pour les nouveaux clients depuis la release 2208, et recommandé en Private Edition et on-premise depuis 2022.

Comment mesurer le Clean Core ?

Utilisez l'ABAP test cockpit pour les contrôles au niveau du code et classez les objets spécifiques dans les niveaux A à D. Les clients RISE peuvent suivre l'adoption dans le RISE with SAP Methodology dashboard, aussi appelé clean core dashboard, dans SAP Cloud ALM. Je suis le nombre d'objets à chaque niveau, la tendance du niveau D et le nombre d'exceptions ouvertes ayant un responsable.

Qui doit porter la gouvernance SAP Clean Core ?

Une design authority réunissant le métier et l'IT doit porter chaque décision Clean Core. Les responsables de processus métier décident si un besoin est réel, et l'IT décide comment il est construit et à quel niveau. Chaque exception est consignée avec un responsable et revue avant chaque montée de version.

Quand le support de SAP ECC prend-il fin ?

Pour SAP ERP 6.0 avec les enhancement packages 6 à 8, la maintenance standard prend fin le 31 décembre 2027, avec une maintenance étendue optionnelle jusqu'au 31 décembre 2030 moyennant un surcoût. L'option de transition SAP ERP, private edition court jusqu'en 2033, uniquement pour les grands systèmes éligibles passés sur SAP ERP, private edition sur SAP HANA avant la fin de 2030.