SAP a formalisé sa stratégie Clean Core progressivement depuis 2023, puis l’a renforcée lors de SAP Sapphire 2026 avec l’annonce d’un programme de certification officielle des extensions BTP. Pour les DSI en cours de migration vers S/4HANA, ou en phase de cadrage, la question n’est plus de savoir si le Clean Core s’applique, mais comment l’integrer dans le programme de transformation sans sous-estimer le travail de remise en ordre du code existant.
Ce guide decrit la doctrine SAP telle qu’elle s’applique en 2026 : les 5 dimensions du Clean Core, le modele de niveaux d’extensibilite, la methodologie d’audit du code Z, et les arbitrages strategiques entre Greenfield, Brownfield et BTP.
Qu’est-ce que le SAP Clean Core ? La doctrine officielle SAP expliquee
Definition : noyau standard non modifie, extensible uniquement via des APIs publiees
Le Clean Core SAP designe un systeme S/4HANA dont le noyau applicatif n’a pas ete modifie directement. Aucune table SAP n’est alteree manuellement, aucun programme standard n’est surecrits, aucun objet interne non publie n’est appele depuis le code client. Toutes les extensions passent exclusivement par des APIs officiellement publiees par SAP, documentees dans le SAP Business Accelerator Hub.
Ce principe peut sembler simple. Dans la pratique, des annees de developpements specifiques (objets Z, modifications BADI, surcharges de programmes standard) ont laisse des empreintes profondes dans la quasi-totalite des systemes SAP ECC existants. Le passage au Clean Core implique donc un programme de remediation, pas simplement une decision architecturale.
Les 5 dimensions du Clean Core
SAP structure sa doctrine autour de cinq dimensions interdependantes, publiees dans son whitepaper officiel “5 guiding principles of clean core” de decembre 2025 :
-
Processus : les processus metier suivent le standard SAP autant que possible. Chaque ecart par rapport au standard doit etre justifie et documente. L’objectif est de reduire la complexite et d’accelerer les mises a jour du core.
-
Extensions : toutes les extensions s’appuient exclusivement sur des APIs publiees. Le code client ne doit pas appeler d’objets internes SAP. Les extensions utilisent soit ABAP Cloud (on-stack), soit SAP BTP (side-by-side).
-
Data : la gouvernance des donnees doit etre formalisee. Un modele de qualite continue est requis pour garantir coherence, conformite et fiabilite des donnees metier.
-
Integrations : toutes les nouvelles interfaces utilisent des APIs publiees (OData, SOAP) via SAP Integration Suite, plutot que des BAPI ou des appels RFC directs vers des objets internes.
-
Operations : le maintien du Clean Core dans la duree necessite des controles de transport automatises, des tests de regression structures, et un pilotage continu via des KPIs de conformite.
Pourquoi SAP impose cette strategie : le business model du cloud public
La strategie Clean Core repond a un imperatif economique de SAP : rendre possible la mise a jour automatique du core S/4HANA Cloud Public Edition. Dans un modele SaaS mutualise, SAP ne peut pas livrer des mises a jour regulieres si chaque client dispose d’un core personnalise. SAP CEO Christian Klein a confirme lors de SAP Sapphire 2026 que la transformation vers le cloud de ses clients alimente la croissance jusqu’en 2030.
Pour les clients cloud public (SAP S/4HANA Cloud Public Edition, RISE with SAP), le Clean Core est une contrainte de fait : le systeme ne permet techniquement pas les modifications directes du standard. Pour les clients cloud prive ou on-premise, il reste recommande mais non impose techniquement, meme si SAP en fait un prerequis de sa roadmap de support.
Clean Core ne signifie pas zero developpement
Un ecueil frequent dans les projets de migration est de confondre Clean Core avec l’absence totale de developpement specifique. Cette interpretation erronee amene des refus de developpements legitimes, puis des contournements manuels qui generent de la dette non documentee.
Le Clean Core autorise les developpements specifiques, a condition qu’ils passent par les voies officielles : ABAP Cloud pour les extensions on-stack, SAP BTP CAP ou Kyma pour les extensions side-by-side. La surface d’extension est large. C’est la voie qui change, pas la capacite a developper.
L’ecosysteme d’extensions SAP : ce qui est autorise en 2026
SAP BTP : les briques fondamentales
SAP Business Technology Platform (BTP) est la plateforme d’extensions officielle. Elle regroupe plusieurs environnements de developpement :
- SAP Cloud Application Programming model (CAP) : framework Node.js et Java pour developper des applications metier orientees donnees. C’est la voie recommandee pour réécrire des extensions ABAP complexes qui ne peuvent pas rester on-stack.
- Kyma : environnement Kubernetes open source heberge sur BTP. Prefere pour les microservices stateless et les integrations asynchrones avec des systemes tiers.
- SAP Integration Suite : successeur officiel de SAP Process Orchestration (PO/PI). Toutes les nouvelles interfaces doivent passer par Integration Suite, via des APIs publiees.
- SAP Build : environnement low-code pour creer des applications Fiori ou des workflows sans code ABAP, accessible a des equipes moins techniques.
ABAP Cloud vs ABAP Legacy : les APIs released vs les objets non relases
ABAP Cloud est le successeur de l’ABAP classique dans un contexte Clean Core. La difference fondamentale : ABAP Cloud n’autorise syntaxiquement que les APIs officiellement publiees par SAP (source : SAP Community, Clean Core Extensibility). Toute tentative d’appeler un objet non relase genere une erreur a la compilation.
Les APIs publiees sont documentees dans le SAP Business Accelerator Hub (api.sap.com). Elles constituent la surface d’extension officielle, verifiable et maintenue par SAP entre les releases.
L’ABAP classique (dit “Legacy”) continue de fonctionner dans les systemes existants, mais toute nouvelle extension devrait utiliser ABAP Cloud pour rester dans le perimetre Clean Core.
Le modele de niveaux A, B, C, D (publie en aout 2025)
En aout 2025, SAP a formalise un modele a quatre niveaux pour qualifier le degre de conformite Clean Core d’une extension ou d’un systeme :
- Niveau A : conformite totale. Le core reste standard, toutes les innovations fonctionnent en dehors du noyau via ABAP Cloud ou BTP. C’est le niveau cible pour les projets cloud public.
- Niveau B : conformite partielle, cote BTP. Les extensions ont ete deplacees vers SAP BTP, mais certains appels legacy subsistent. Acceptable en cloud prive, a rationaliser progressivement.
- Niveau C : rationalisation en cours. Une partie du code a ete nettoyee, mais du code legacy subsiste avec des risques d’incompatibilite lors des upgrades.
- Niveau D : non conforme. Le systeme cumule des annees de customisation non geree, modifications directes du standard incluses. Les upgrades sont bloques ou tres couteux.
Ce modele remplace les anciens reperes plus binaires “clean / not clean” et permet un pilotage progressif. Pour les equipes projet, il constitue un outil de communication avec les directions metier et financieres : le niveau D est un risque programme, le niveau A est un objectif de gouvernance.
Extensions side-by-side vs extensions in-app : quand utiliser quoi
Extensions in-app (on-stack) via ABAP Cloud : recommandees quand l’extension doit fonctionner dans la transaction S/4HANA, acceder directement aux donnees SAP, ou etre deployee sans latence reseau. Exemples typiques : validations de donnees metier, logiques de declenchement en sortie de transaction, extensions Fiori legeres.
Extensions side-by-side via BTP : recommandees quand l’extension est un vrai sous-systeme fonctionnel, implique des services cloud tiers (IA, IoT, OCR, signature electronique), ou doit evoluer independamment du cycle de release SAP. Exemples : portail fournisseur, moteur de configuration avancee, outil de reporting analytique specifique.
Le choix entre les deux n’est pas dichotomique. Un projet de migration moyen mobilise les deux types d’extensions, avec un arbitrage au cas par cas sur la base de la criticite, de la latence, et de la dependance aux donnees SAP temps reel.
L’impact sur les migrations SAP ECC vers S/4HANA Cloud Public
L’inventaire des objets Z existants : comment les classer
Avant toute migration, un audit complet du code specifique est indispensable. SAP fournit deux outils integres pour ce travail :
- SAP Readiness Check : disponible depuis la transaction READINESS_CHECK ou via le cloud. Analyse le systeme ECC existant, identifie les simplifications S/4HANA impactantes, et liste les objets Z qui appellent des structures ou fonctions supprimees ou modifiees dans S/4HANA.
- SAP Custom Code Migration App : application Fiori standard disponible dans le catalogue BTP. Scanne les objets ABAP non relases, les classe par niveau de risque, et recommande des chemins de remediation (retirer, migrer vers ABAP Cloud, réécrire sur BTP).
La taxonomie de classification standard comporte quatre categories :
- Objets a retirer : code obsolete, jamais execute en production, ou remplace par le standard S/4HANA.
- Objets a réécrire sur BTP : fonctionnalites complexes qui doivent evoluer independamment du core.
- Objets a migrer vers ABAP Cloud : extensions legitimes qui restent on-stack, mais doivent passer aux APIs publiees.
- Objets a conserver temporairement : code encore necessaire, en attente d’un equivalent standard ou BTP.
Dans la pratique, une part significative des objets Z identifies lors de l’audit correspond a du code jamais appele en production ou a des fonctions depuis couvertes par le standard S/4HANA. Les retraiter systematiquement reduit le perimetre de migration avant meme d’entamer les developpements.
Quels modules sont les plus touches
Les modules les plus susceptibles d’accumuler du code specifique sont ceux qui ont fait l’objet de personnalisations historiques importantes :
- FI/CO : etats de reporting specifiques, logiques de cloture comptable, integrations avec des outils de consolidation externes.
- MM/SD : workflows d’approbation achat, gestion des conditions tarifaires complexes, interfaces EDI historiques.
- PP : logiques de planification specifiques, interfaces MES/SCADA, gestion d’ordres de fabrication atypiques.
Les modules de gestion de paie (PY) et les developpements sur la base HR presentent souvent les dettes techniques les plus importantes, en raison de la complexite reglementaire et de la frequence des adaptations locales.
Le cout reel de la remise en ordre du code specifique
Le cout d’un programme Clean Core est difficile a generaliser. Il depend directement du volume d’objets Z identifies, de leur complexite, et des ressources disponibles en ABAP Cloud et BTP.
Ce qu’on observe sur le terrain : les projets qui sous-estiment le travail de clean-up en phase de cadrage le payent sous forme d’allongement de projet ou de dettes techniques reportees. Un audit serieux avec la Custom Code Migration App, realise avant la contractualisation du perimetre de migration, est le meilleur investissement de prevention.
Les integrateurs specialises BTP (Capgemini, Accenture, Sopra Steria, Viseo, Apside) publient des retours d’experience qui donnent des ordres de grandeur selon la taille du systeme et le secteur. Ces fourchettes restent des estimations a affiner par l’audit propre a chaque systeme.
Greenfield vs Brownfield vs Bluefield : Clean Core change-t-il la recommandation ?
Le Clean Core influence le conseil sur la strategie de migration :
- Greenfield (reimplemantation depuis zero) : naturellement aligne avec le Clean Core, puisqu’on repart du standard sans dette technique heritee. Il suppose de redefinir tous les processus metier, ce qui est un projet de transformation complet.
- Brownfield (conversion technique du systeme existant) : le Clean Core ajoute une etape prealable obligatoire de remediation du code. Sans cette etape, le systeme converti reste non conforme et les benefices cloud public sont inaccessibles.
- Bluefield (selectif, migration partielle de donnees et processus) : adapte quand on veut combiner la rapidite du Brownfield et la proprete du Greenfield. Le Clean Core s’integre naturellement dans la selection des processus a migrer.
Pour les ETI et grandes entreprises en cloud public, le Greenfield ou le Bluefield restent les approches les plus coherentes avec les contraintes Clean Core. Le Brownfield seul, sans programme de remediation serieux, cree souvent une conformite de facade qui se paie lors du premier upgrade majeur.
Methodologie pour adopter le Clean Core pas a pas
Etape 1 : Audit du code existant
Lancer la SAP Readiness Check et la Custom Code Migration App sur le systeme de production (ou une copie recente). Ces outils fournissent une cartographie exhaustive des objets Z, classes par risque d’incompatibilite S/4HANA et par type d’acces aux APIs non relasees.
Ne pas confier cet audit uniquement a l’integrateur : l’equipe interne doit valider la liste des objets identifies avec les responsables metier, pour distinguer le code critique du code mort.
Etape 2 : Classification fonctionnelle et decision de remediation
Pour chaque objet identifie, decider : retrait, migration ABAP Cloud, réécriture BTP, ou maintien temporaire. Cette decision est fonctionnelle autant que technique. Elle doit impliquer les process owners, pas seulement les developpeurs.
Constituer un registre de decision avec le responsable de chaque objet, la justification du choix, et la date de traitement prevue. Ce registre devient l’outil de pilotage du programme Clean Core.
Etape 3 : Build sur BTP ou migration vers ABAP Cloud
Pour les extensions a developper sur BTP :
- BTP CAP (Node.js ou Java) pour les applications metier a interface Fiori ou API REST.
- Kyma pour les microservices, les traitements asynchrones, et les integrations avec des services cloud tiers.
- SAP Integration Suite pour remplacer toutes les interfaces RFC/BAPI existantes par des APIs publiees.
Pour les extensions a maintenir on-stack : migration vers ABAP Cloud Developer Tools, remplacement des appels non relases par les APIs documentees dans le Business Accelerator Hub.
Etape 4 : Tests de regression
Le passage au Clean Core modifie les comportements techniques meme si la logique fonctionnelle est preservee. Un plan de tests de regression doit couvrir l’ensemble des extensions migrees, avec validation par les equipes metier, pas seulement par les equipes IT.
L’automatisation des tests de regression (ABAP Unit Tests, outils d’automatisation Fiori) est un investissement rentable : elle reduit le cout des cycles de release futurs et constitue le filet de securite indispensable lors des upgrades automatiques du core.
Etape 5 : Gouvernance long terme via Custom Code Management
Le Clean Core n’est pas un etat ponctuel atteint une fois pour toutes. SAP propose le Custom Code Management comme discipline continue : surveillance reguliere des nouveaux developpements, integration des controles de conformite dans les pipelines CI/CD, et reporting vers un dashboard centralise.
A SAP Sapphire 2026, SAP a annonce le Clean Core Certification Programme, qui certifie formellement les extensions BTP comme compatibles avec les mises a jour S/4HANA Cloud sur au minimum trois cycles de release consecutifs. Cette certification devient un critere de selection pour les solutions partenaires et un argument de gouvernance IT.
Avantages concrets d’un systeme Clean Core
Les benefices observes dans les retours de projets ayant atteint le niveau A ou B du modele de conformite :
Mises a jour du core automatiques : SAP peut livrer les nouvelles fonctionnalites, y compris les 50+ assistants Joule annonces a Sapphire 2026, sans bloquer sur des modifications du standard. C’est le benefice le plus direct du cloud public.
Reduction du cout de maintenance des specifiques : un code Z bien encapsule dans BTP CAP est plus simple a tester, a documenter et a faire evoluer qu’un code Z imbrique dans le core. Le budget de maintenance des specifiques baisse a mesure que le registre BTP se structure.
Adoption plus rapide de l’IA embarquee : a SAP Sapphire 2026, Joule Studio 2.0 a ete annonce GA avec des capacites de suggestion de refontes d’extensions. Ces fonctionnalites sont accessibles en priorite aux systemes Clean Core cloud public. Un systeme niveau D n’y aura pas acces.
Reduction du risque lors des audits de securite : un core standard non modifie est plus simple a auditer et a certifier (SOC2, ISO27001) qu’un systeme avec des modifications directes du code SAP. La surface d’attaque est plus previsible.
Meilleure lisibilite pour les equipes et les integrateurs : un registre clair des extensions BTP est appropriable lors de changements d’integrateur ou d’arrivees de nouveaux membres dans l’equipe IT.
Les risques et objections frequentes
Quatre objections reviennent systematiquement lors des phases de cadrage :
“Le BTP est trop cher en ajout au cout des licences S/4HANA.” C’est une objection legitime. Les couts BTP (licences, compute, integration) s’ajoutent effectivement au TCO. Ils doivent etre integres dans l’analyse economique des la phase de cadrage, pas apres la contractualisation. Un TCO incomplet sur BTP est une source frequente de revisions budgetaires a mi-projet.
“Certains besoins metier ne peuvent pas etre couverts par BTP.” Dans la majorite des cas, cette objection provient d’une analyse insuffisante des APIs publiees disponibles. Le Business Accelerator Hub compte plusieurs milliers d’APIs publiees couvrant l’ensemble des modules SAP. Il faut verifier ce qui existe avant de conclure que BTP ne peut pas repondre.
“Nos partenaires integrateurs ne sont pas formes BTP CAP.” C’est un risque reel. Les competences BTP CAP et Kyma sont encore inegalement distribuees dans l’ecosysteme integrateurs. La selection du partenaire de migration doit explicitement inclure une evaluation des competences BTP, avec des references de projets similaires en nombre d’objets Z traites.
“On perd le controle sur les evolutions du core si SAP peut le mettre a jour.” Ce risque est gere via les APIs publiees : SAP s’engage contractuellement a maintenir la compatibilite des APIs relasees entre les versions. Les extensions qui utilisent exclusivement des APIs publiees ne cassent pas lors des upgrades. C’est precisement l’interet du modele, formalise dans le Clean Core Certification Programme.
Clean Core et RISE with SAP : le package tout-en-un
RISE with SAP est l’offre commerciale de SAP qui emballe S/4HANA Cloud Public Edition, BTP, la gestion de l’infrastructure, et des services de transformation en un contrat unique.
Dans le cadre RISE, le Clean Core n’est pas optionnel : l’environnement cloud public impose techniquement l’utilisation des APIs publiees. SAP inclut dans RISE les outils de pilotage Clean Core : Custom Code Migration App, SAP Readiness Check, et acces a SAP Signavio pour l’analyse des processus metier.
GROW with SAP est la declinaison pour les PME (organisations avec des processus moins complexes et des volumes SAP plus faibles) : les contraintes Clean Core sont les memes, mais les volumes d’objets Z a traiter sont generalement moindres et les timelines de migration plus courtes.
Pour les grandes entreprises avec des systemes ECC anciens et des volumes de code specifique importants, RISE n’est pas un raccourci. Le programme de remediation Clean Core precede la migration et son cout doit etre budgete separement des licences RISE. Les organisations qui l’integrent dans le Business Case de depart evitent les surprises les plus courantes.
Pour aller plus loin sur l’evaluation de votre dependance a l’ecosysteme SAP avant de signer un contrat RISE, lisez notre guide ERP vendor lock-in : comment evaluer votre dependance et preparer votre reversibilite.
Pour approfondir, consultez notre comparatif SAP S/4HANA vs Oracle Cloud ERP 2026 et notre analyse de l’urgence de migration SAP S/4HANA pour le Mittelstand et les ETI en 2026.
