Le Clean Core n'est pas une option : le cas d'architecture pour S/4HANA

Tout paysage SAP de plus de quelques années porte du code spécifique qui a résolu un vrai problème métier en son temps et qui bloque aujourd'hui silencieusement le suivant. Modifications d'objets standards, logique spécifique glissée dans des exits utilisateur, tables Z devenues structurantes — rien de tout cela ne semblait risqué à la livraison. Cela le devient le jour où l'on veut monter de version, aller vers le cloud, ou connecter un agent IA au processus concerné.

Le Clean Core est la réponse de SAP : garder le cœur digital proche du standard, et pousser les extensions vers une couche side-by-side ou on-stack avec des interfaces définies et versionnées. On le présente souvent comme une bonne pratique à adopter progressivement. Dans notre expérience de transformations S/4HANA, il se comporte moins comme une bonne pratique que comme une condition préalable — pour la capacité à monter de version, pour l'extensibilité BTP, et de plus en plus pour l'IA.

Un agent IA qui appelle SAP a besoin d'une surface stable et bien définie à appeler. Si le processus qu'il automatise est enchevêtré avec une logique spécifique non documentée, l'agent hérite de cette fragilité — chaque appel au modèle devient un pari sur du code que personne n'a totalement cartographié. Les points d'extension Clean Core (BAdIs, vues CDS, API basées RAP) donnent aux humains comme aux clients IA un contrat sur lequel s'appuyer.

C'est aussi pourquoi nous traitons Clean Core et Business AI comme une seule conversation d'architecture, pas deux. Un serveur MCP exposant des capacités SAP n'est fiable qu'à la hauteur des interfaces qui se trouvent derrière lui. Le Clean Core est précisément ce qui rend ces interfaces fiables.

En pratique, un programme Clean Core démarre par un inventaire honnête du code spécifique — basé sur des données d'usage, pas des suppositions — suivi d'une décision par objet : retirer, remplacer par du standard, ou migrer vers une extension side-by-side sur BTP en CAP ou RAP. La difficulté est rarement technique ; elle consiste à prioriser quels enchevêtrements démêler en premier, sur une activité qui ne peut pas s'arrêter.

Nous séquençons cela avec votre calendrier de transformation S/4HANA plutôt que d'en faire une initiative séparée, car les deux partagent presque toutes les décisions : ce qui reste dans le cœur, ce qui va vers la plateforme, et quelle interface relie les deux.