Stratégie Clean Core SAP : définition et mise en application

Le Clean Core décide si une mise à niveau S/4HANA prend six semaines ou six mois. Si votre système regorge de modifications d'objets standard SAP, chaque version devient un projet de non-régression. Si votre logique spécifique se trouve derrière des interfaces publiées, les mises à niveau deviennent de la maintenance courante.

J'ai vu des entreprises réduire de 40 % leurs délais de mise à niveau en appliquant les principes du Clean Core avant le démarrage de leur programme S/4HANA. Un groupe de biens de consommation a remplacé une ancienne logique de tarification par une application Fiori modulaire construite hors du cœur du système, et ses mises à niveau ont cessé de casser cette logique.

Beaucoup de choses ont changé depuis que j'ai écrit ce texte pour la première fois, en avril 2025. SAP décrit désormais le Clean Core à travers cinq principes directeurs et, depuis août 2025, classe chaque extension dans l'un de quatre niveaux. Les échéances d'ECC sont aussi plus claires. Cette version en tient compte.

Le Clean Core consiste à garder votre système S/4HANA aussi proche du standard SAP que votre activité le permet, et à construire tout le reste de manière à ce que cela survive aux mises à niveau.

Vous pouvez toujours personnaliser. Mais la personnalisation doit passer par des interfaces que SAP a publiées et promis de 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 communiquent avec S/4HANA par des API ou des événements.

La recommandation de SAP est de choisir au cas par cas, avec BTP en premier. 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 » n'a rien d'inconnu pour quiconque a exploité ECC : des programmes standard modifiés, des tables Z alimentées directement, des interfaces qui lisent les entrailles de SAP, des enrichissements implicites que personne n'a documentés. Rien de tout cela n'était une erreur au moment de la construction. Simplement, ce n'était pas conçu pour un système qui se met à niveau tous les ans ou tous les deux ans.

SAP organise le Clean Core autour de cinq principes directeurs. La version précédente de cet article en listait d'autres intitulés. Voici ceux que SAP utilise, avec ce que je regarde en premier pour chacun :

Principe	Ce que SAP entend par là	Ce que je vérifie en premier
Processus	Rester le plus près possible du processus standard SAP	Quelles variantes de processus n'existent que parce que « on a toujours fait comme ça »
Extensibilité	Extensions découplées du cœur grâce à des API publiées, avec une gouvernance sur l'option retenue	Quelle quantité de code spécifique existe, quelle part est utilisée, 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 doublon ou incomplètes, champs spécifiques que personne ne sait expliquer
Intégrations	Connexions standardisées et sécurisées, fondées sur des technologies prises en charge	Interfaces point à point qui lisent directement les tables
Exploitation	Gouvernance, personnes, processus et 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, ce sont les processus et les données qui causent le plus de retards. Le code spécifique n'est le plus souvent que le symptôme. Le processus qui se cache derrière en est la cause.

En août 2025, SAP a remplacé son précédent modèle d'extensibilité à trois niveaux par le concept de niveaux Clean Core. Chaque extension est évaluée selon la façon dont elle est construite, son degré de découplage du cœur et la facilité avec laquelle elle peut être mise à niveau.

Niveau	Description de SAP	Ce que cela signifie pour votre mise à niveau
A	Extension avec SAP Build. Uniquement des interfaces publiées et stables, en on-stack avec ABAP Cloud ou en side-by-side sur BTP	Risque le plus faible. SAP garantit ces interfaces par des contrats de stabilité
B	Utilise aussi les API et technologies classiques de SAP	En général stable à la mise à niveau, mais hors du modèle de développement cloud
C	Accède à des objets internes de SAP	Conforme en partie. Chaque mise à niveau demande une vérification ; SAP prévoit un journal des modifications pour les objets internes
D	Non recommandé : modifications, écritures dans les tables SAP, enrichissements implicites, objets explicitement non recommandés	La dette technique à supprimer en premier

Cette grille est plus utile que l'ancien débat « propre ou pas propre ». Elle permet de fixer un objectif par objet. Tout n'a pas à atteindre le niveau A. Faire passer vos objets de niveau D en B ou C avant une mise à niveau réduit déjà réellement le risque.

Niveau ANiveau BNiveau CNiveau D

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

Risque à la mise à niveauNiveau ALe plus faible, garanti par des contrats de stabilitéNiveau BEn général stable à la mise à niveauNiveau CÀ vérifier à chaque mise à niveauNiveau 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 mise à niveauNiveau DSupprimer en premier, ou passer en B ou C

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

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

1. Identifier ce qui est utilisé. Lancez le SAP Readiness Check, fourni avec votre contrat de maintenance, et collectez les données d'usage de votre code spécifique. Sur un programme, l'analyse avec smartShift nous a fait passer de 18 000 objets spécifiques à 3 200. Le reste, pour l'essentiel, n'était tout simplement pas utilisé.
2. Classer ce qui reste en niveaux A à D. L'ABAP test cockpit est l'outil de SAP pour les contrôles au niveau du code. Sous RISE, le tableau de bord RISE with SAP Methodology rend compte de l'adoption du Clean Core.
3. Décider 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. Un état utilisé deux fois par an par une équipe régionale peut attendre.
4. Faire entrer le métier dans la pièce. Un responsable finance avec qui j'ai travaillé n'a compris sa nouvelle application Fiori qu'après une présentation de 45 minutes. Cette séance a épargné deux semaines d'allers-retours pendant la recette utilisateur (UAT).
5. Remettre en cause « notre processus est différent ». Lors d'un atelier avec une équipe commerciale, le processus « unique » s'est révélé être à 80 % de l'administratif hérité redondant. Le SAP standard a amélioré leur expérience client dès que les contournements ont disparu.
6. Lancer tôt le travail sur les données. Un client de la distribution 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 c'est la partie que la plupart des plans sous-estiment. J'explique pourquoi dans pourquoi la migration de données SAP échoue.
7. Fixer la gouvernance avant le go-live. Une instance de conception (design authority) doit examiner chaque nouvelle extension. La question par défaut était « pourquoi cela ne peut-il pas vivre sur BTP ? ». Aujourd'hui, je demanderais « pourquoi cela ne peut-il pas être de niveau A, et si ce n'est pas possible, quel niveau acceptons-nous et pourquoi ? »

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 de se former. 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 construction.

Trois questions reviennent dans presque toutes mes conversations sur ce sujet.

Le Clean Core est-il obligatoire avec RISE with SAP ? Pas comme règle générale. Dans S/4HANA Cloud Public Edition, vous ne pouvez étendre que par des interfaces publiées, donc le système l'impose. En Private Edition et sur site, vous pouvez encore modifier le cœur. Le Clean Core y est un choix de gouvernance, que SAP suit au moyen du tableau de bord de la méthodologie RISE. 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 sur les packs d'évolution (EHP) 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, et SAP demande aux clients de la commander d'ici le troisième trimestre 2027. Les packs d'évolution antérieurs sont sortis de la maintenance standard fin 2025. Après 2030, l'option de transition SAP ERP, private edition couvre 2031 à 2033. Elle ne s'applique qu'aux grands systèmes déjà migrés vers SAP ERP, private edition sur SAP HANA avant la fin de 2030, et seulement avec le plan max success de SAP. 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 d'itinéraire.

Le Clean Core compte-t-il pour l'IA ? SAP construit ses fonctions d'IA, dont Joule, sur ses processus standard et son modèle de données. Joule for developers génère du code ABAP Cloud à partir des API publiées. Mon point de vue de travail est simple : plus vos processus et vos données sont proches du standard, moins vous avez besoin d'adaptation avant que ces fonctions vous soient utiles. Les processus très modifiés sont ceux où les fonctions d'IA sont les plus difficiles à adopter.

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

Si vous êtes sur le point de signer un contrat S/4HANA ou RISE, demandez à votre intégrateur une classification de votre code spécifique actuel en niveaux A à D avant de convenir du périmètre. S'il ne peut pas en produire une, cela vous en dit long sur l'estimation. Vous pouvez tester vos options de migration avec mon évaluation de migration d'ECC vers S/4HANA, ou réserver un appel et nous examinerons votre situation.

Qu'est-ce que le Clean Core SAP ?

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

Quelles sont les cinq dimensions du Clean Core SAP ?

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

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

Depuis août 2025, SAP classe les extensions en quatre niveaux. Le niveau A n'utilise que des interfaces publiées et stables. Le niveau B utilise aussi les API classiques de SAP. Le niveau C accède à des objets internes de SAP et demande une vérification à chaque mise à niveau. Le niveau D recouvre les modifications, les écritures dans les tables SAP, les enrichissements implicites et d'autres techniques non recommandées, et représente le risque le plus élevé.

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

Pas comme règle générale. S/4HANA Cloud Public Edition n'autorise les extensions que par des interfaces publiées, donc elle impose techniquement le Clean Core. En Private Edition, vous pouvez encore modifier le cœur : le Clean Core est alors une décision de gouvernance. SAP rend compte de l'adoption du Clean Core par le tableau de bord RISE with SAP Methodology.

Quand prend fin le support de SAP ECC ?

Pour SAP ERP 6.0 sur les packs d'évolution 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. Les packs d'évolution antérieurs sont sortis de la maintenance standard fin 2025. L'option de transition SAP ERP, private edition, court jusqu'en 2033 uniquement pour les grands systèmes éligibles migrés vers SAP ERP, private edition sur SAP HANA avant la fin de 2030.

Comment évaluer la maturité Clean Core de mon système SAP ?

Commencez par le SAP Readiness Check et les données d'usage de votre code spécifique. Classez ce qui est encore utilisé en niveaux A à D, en vous servant de l'ABAP test cockpit pour les contrôles au niveau du code. Décidez ensuite, objet par objet, de le retirer, de le faire passer sur une interface publiée, de le reconstruire sur SAP BTP ou de le conserver avec une raison documentée. Passez en revue les processus et les données en même temps, car ils expliquent généralement pourquoi le code existe.

Quel est le rôle de SAP BTP dans une stratégie Clean Core ?

SAP BTP est l'endroit où s'exécutent les extensions side-by-side. Les applications sur BTP se connectent à S/4HANA par des API et des événements, si bien que le cœur reste intact. SAP recommande une approche BTP d'abord, avec des extensions ABAP Cloud en on-stack lorsque la logique doit se trouver près des données ou de la transaction.