Stratégie Clean Core : Comment préparer vos systèmes aux futurs upgrades SAP sans douleur

Pendant des décennies, la force d'un système SAP résidait dans sa capacité à être tordu dans tous les sens grâce aux développements spécifiques (le fameux programme « Z »). Sur ECC, cette flexibilité a permis aux entreprises de modeler l'ERP au plus près de leurs processus. Mais sur S/4HANA, ce qui était une force est devenu le pire ennemi des DSI.

Pourquoi le Clean Core est devenu critique sur S/4HANA

Trois ruptures majeures expliquent ce changement de paradigme :

• Cadence d'upgrade accélérée. SAP livre une version S/4HANA chaque année (2020, 2021, 2022, 2023, 2024). Sur ECC, on restait sur une release pendant 5 à 10 ans. Aujourd'hui, un système figé devient obsolète très vite.
• Modifications du standard interdites. SAP a verrouillé l'accès en écriture aux objets du noyau. Toute modification du standard (Modification Assistant) doit désormais passer par les API et BAdI officiels.
• RISE with SAP et le Cloud. Les offres cloud privé et public imposent un cadre strict : le code spécifique est cantonné à des espaces dédiés (ABAP Cloud, BTP), sans contact avec le noyau.

Le coût caché de la dette technique

Chaque BAdI mal implémenté, chaque User Exit codé à la hâte et chaque User Interface modifiée hors framework est une bombe à retardement pour le prochain upgrade. Concrètement, voici ce que nous observons sur des systèmes ECC arrivés à maturité avant migration :

• Plusieurs milliers d'objets dans le namespace Z, dont 30 à 50 % sont morts ou redondants ;
• Des dépendances croisées qui rendent impossible la suppression d'un programme sans tests de non-régression complets ;
• Des phases d'upgrade qui passent de 3 mois prévus à 9 mois réels, avec un budget multiplié par 2 ou 3 ;
• Une équipe maintenance qui passe 70 % de son temps à corriger les régressions plutôt qu'à apporter de la valeur métier.

Les trois piliers de l'extensibilité Clean Core

L'objectif du Clean Core n'est pas d'interdire le spécifique mais de le déplacer hors du chemin critique. SAP propose un modèle à trois niveaux, à choisir selon la complexité du besoin :

1. Extensibilité In-App (Key User Extensibility)

C'est le niveau le plus simple. Un Key User crée un champ personnalisé sur une commande de vente, ajoute une règle de validation ou enrichit une fiche article via les outils Fiori standards (Custom Fields, Custom Logic, Adaptation Project). Aucune ligne de code ABAP. Idéal pour 60 à 70 % des extensions métiers courantes.

2. Extensibilité Developer (On-Stack avec ABAP Cloud)

Quand le besoin dépasse le Key User, on entre dans le terrain du développeur ABAP. La règle d'or : utiliser uniquement les objets SAP marqués « Released » (API et CDS Views libérés par SAP, listés dans la transaction ADT ou sur le portail SAP Business Accelerator Hub). Le modèle RAP (RESTful Application Programming Model) est la pierre angulaire : il permet de construire des applications Fiori complètes (List Report, Object Page, Analytical Page) en s'appuyant sur des CDS Views et des Behavior Definitions, exposées en OData V4.

Avantage clé : les API SAP « Released » bénéficient d'un contrat de stabilité. Si SAP modifie la signature d'un objet libéré, l'ancienne version reste disponible plusieurs releases.

3. Extensibilité Side-by-Side (SAP BTP)

Pour les applications très spécifiques (portail fournisseur, application mobile sur mesure, intégration tierce complexe), on déporte le code en dehors de S/4HANA, sur la SAP Business Technology Platform. Le système ERP reste vierge. La communication se fait via OData ou événements (SAP Event Mesh).

Comment auditer votre code existant

Avant tout chantier Clean Core, il faut mesurer la dette. Trois outils sont incontournables :

• ABAP Test Cockpit (ATC) avec le check variant S4HANA_READINESS : il identifie les objets non compatibles avec S/4HANA et les modifications du standard.
• Custom Code Migration App (cockpit Fiori) : génère un rapport sur la complexité de chaque objet Z et propose des recommandations.
• SAP Readiness Check : analyse l'utilisation effective de votre code (combien d'objets Z sont réellement appelés en production sur les 12 derniers mois ?).

Dans 9 cas sur 10, ces outils révèlent que 30 à 50 % du code spécifique peut être purement et simplement supprimé.

Cas Kuhn Group : Clean Core dès le jour 1

Chez Kuhn Group, leader mondial du matériel agricole, nous avons appliqué la rigueur Clean Core dès le premier jour de la migration Greenfield. Concrètement, cela s'est traduit par :

• Une charte de développement validée par le COMEX projet, interdisant tout accès direct aux tables standard et imposant les CDS Views libérées ;
• Un ATC bloquant en transport : aucun objet ne franchit l'étape DEV → QA sans note ATC inférieure à 3 ;
• Des revues de code systématiques menées par les Tech Leads avant fusion en branche principale ;
• Un modèle 100 % RAP/Fiori Elements pour toutes les nouvelles applications, sans Web Dynpro ni Module Pool.

Résultat : le passage de la version S/4HANA 2020 à la version 2023 s'est effectué en 6 semaines, sans rupture majeure d'activité. À titre de comparaison, un upgrade équivalent sur un système chargé en code Z classique dure typiquement 4 à 6 mois.

Le Clean Core n'est pas un concept marketing. C'est une discipline d'architecture logicielle qui transforme l'upgrade SAP d'une crise majeure en routine maîtrisée.

Plan d'action en six étapes

1. Audit du code existant via ATC, Custom Code Migration App et Readiness Check.
2. Cartographie des objets Z par criticité métier et par catégorie d'extensibilité cible.
3. Décommissionnement du code mort (en moyenne 30 à 50 % du périmètre).
4. Refonte progressive des objets restants vers In-App, RAP ou BTP selon leur complexité.
5. Mise en place de la gouvernance : charte, ATC bloquant, revues de code, certification des Tech Leads.
6. Formation continue des équipes sur ABAP Cloud, RAP et Fiori Elements.

Questions fréquentes

Faut-il être en cloud public pour appliquer le Clean Core ?

Non. Les principes Clean Core s'appliquent aussi bien sur du S/4HANA on-premise que sur du cloud privé (RISE) ou public. Le cloud public impose simplement une discipline plus stricte (uniquement ABAP Cloud, uniquement objets Released).

Que faire des programmes Z stratégiques qu'on ne peut pas refondre tout de suite ?

Les isoler dans un package dédié, documenter leur dette technique dans un registre, et planifier leur refonte sur 18 à 24 mois. L'important est de ne plus créer de nouveaux objets non Clean Core.

Combien de temps prend la mise en place d'une gouvernance Clean Core ?

L'outillage technique (ATC, charte, processus) se met en place en 4 à 6 semaines. L'adoption culturelle par les équipes prend 6 à 12 mois selon la maturité initiale.

Le RAP remplace-t-il complètement l'ABAP classique ?

Pour les nouvelles applications avec interface Fiori, oui. Pour les batches, traitements de masse et certaines logiques métier complexes, l'ABAP classique reste pertinent, à condition de respecter le périmètre des objets Released.