Fiche concept

Principe Clean Core

À jour au 2026-07-24T14:00:00Z

Édité par Cédric-Olivier Mâry, éditeur et directeur de la publication — 27 ans d'écosystème SAP. Comment ces pages sont produites, et où intervient l'automatisation.

Qu'est-ce que Principe Clean Core ?

Clean Core remplace 5 000 à 50 000 lignes d'ABAP custom in-core par trois modèles d'extension (70 % key-user, 25 % développeur, 5 % side-by-side) vivant hors du core.

Qu'est-ce que le clean core SAP ?

Réponse courte ci-dessus

Le Clean Core est la discipline architecturale qui permet à un environnement S/4HANA — et par extension à un Business Data Cloud — de rester montable en version sans devenir, à chaque nouvelle release de SAP, un projet de régression de plusieurs mois. Le principe est simple à énoncer et difficile à faire respecter : rien de ce que le client construit ne doit modifier les objets livrés par SAP, et tout ce qui est spécifique doit vivre dans une couche d'extension clairement séparée, que le processus de release de SAP ne peut pas toucher. Pour un consultant, le Clean Core est moins une technologie qu'une posture de gouvernance — la différence entre un environnement qui traite les montées de version trimestrielles comme une maintenance de routine et un environnement qui les redoute comme un événement coûteux.

Ce que c'est et pourquoi cela compte

Pourquoi c'est important

Zéro modification du code ou des tables SAP-delivered est le premier des cinq invariants — la règle qui transforme les upgrades trimestrielles de projets de régression multi-mois en événements cloud de routine.
70 % des extensions typiques relèvent de la key-user extensibility sans code ni transport — la plupart des tickets « besoin custom » n'ont pas besoin d'un développeur.
Le principe « side-by-side d'abord » signifie : en cas de doute, pousser l'extension vers BTP plutôt que dans le core — la décision de repli que tout architecte doit avoir actée en amont.

Points clés

Trois modèles d'extension : key-user (70 %) · développeur RAP (25 %) · side-by-side BTP (5 %).
Cinq invariants : pas de modifications dans le namespace SAP · namespaces client uniquement · API released uniquement · side-by-side en priorité · discipline d'upgrade trimestrielle.
Répartition du refactoring du code custom legacy : 60-80 % retiré · 15-25 % migré · 5-10 % redesigné.
Coût d'upgrade avant Clean Core : €5-15M / 6-18 mois. Après : ~€0 / cycle de régression de 2 semaines.
Seuil de rentabilité après un investissement de refactoring de €2-10M : 18-30 mois.
Les vues CDS Datasphere (C032) sont conformes Clean Core — l'analytics dépend de Clean Core en amont.
La migration brownfield (C034) hérite de la dette legacy ; la greenfield (C035 hybride) démarre propre.
Réduction de 30-50× de la charge d'upgrade sur 5 ans pour les clients Tier-1 conformes Clean Core.
Clean Core Principle n'est maîtrisé que lorsqu'il change une décision d'achat identifiée.
Commencer par le contrat sémantique et le modèle de contrôle avant de démontrer l'outil.

Termes employés sur cette page

Clean Core: Principe architectural SAP selon lequel les montées de version S/4HANA doivent rester sans friction — extensions HORS du cœur, configuration plutôt que modification.
Key user extensibility: Extension no-code via les outils d'interface Fiori — champs personnalisés, formulaires, applications simples. 70 % des cas d'extension.
Developer extensibility (RAP): ABAP RESTful Application Programming dans des espaces de noms client avec des contrats d'API released stricts. 25 % des cas.
Side-by-side extension: Application complète sur BTP (Cloud Foundry, Kyma) consommant SAP via OData/événements. Découplage maximal. 5 % des cas.
Customer namespace: Espaces de noms Z*, Y* ou enregistrés par le client où réside le code personnalisé. Les modifications de l'espace de noms SAP sont interdites.
Released API: API stable et versionnée que SAP s'engage à maintenir d'une version à l'autre. Le code personnalisé ne consomme que des released APIs.
Brownfield drag: Coût de l'héritage d'ABAP legacy dans le cœur lors d'une migration S/4 — généralement 2 à 10 M€ de refactoring.
Quarterly upgrade discipline: Pratique Clean Core consistant à absorber chaque release cloud S/4 dans les 2 semaines de tests de régression, sans jamais en sauter une.

Sources

Fiche complète réservée aux abonnés. Ce que la fiche complète ajoute : le cadre de décision complet · la comparaison SAP · Snowflake · Databricks · Fabric · les pièges courants et leur correctif · l'aide-mémoire · les schémas d'architecture · les blocs de code · les chiffres à citer.

Ouvrir dans l'application →