Le Clean Core est un standard que l’on tient, pas un projet que l’on termine — le moins invasif des trois niveaux SAP. VISCAP le tient : évaluation, remédiation, architecture des extensions, gouvernance des releases.
Huit domaines de capacités, énoncés avant tout outil — chacun est un livrable, pas une politique, une licence ou un score de maturité.
Extensibilité in-app SAP S/4HANAOutils key user
Le premier niveau à essayer — rien ne sort des points d’extension autorisés, si bien qu’il survit à chaque montée de version.
ABAP CloudExtensibilité développeur SAP S/4HANA
Au-delà des outils key user — même langage, contrat plus restreint.
SAP BTP ABAP environmentSAP Build CodeSAP Business Application StudioSAP Cloud Application Programming Model
Pour tout ce qui est substantiel : la logique hors du core, sur son propre cycle de release.
SAP Build AppsSAP Build Process AutomationSAP Build Work Zone
La gouvernance compte plus que l’outillage — un low-code non gouverné reconstruit la dette ailleurs.
SAP Integration SuiteAPI ManagementSAP Event Mesh
Les intégrations point à point qui atteignent les tables du core ne sont pas clean.
Analyse du code spécifique SAPGestion du transport et du cycle de vie
L’analyse d’usage révèle souvent des objets inutilisés depuis des années — les retirer est le travail Clean Core le moins coûteux qui soit.
Le Clean Core réussit comme une discipline, pas comme un édit — VISCAP couvre l’ensemble du parcours, de l’inventaire des objets spécifiques à la gouvernance des releases qui empêche la dette de se reconstituer. Voici la place de chaque étape et ce dont nous sommes responsables.
Le Clean Core touche presque toutes les composantes d’un environnement SAP — le code, les interfaces, le calendrier des releases, la façon dont on construit. Ces huit services le couvrent.
Tous les services VISCAPÉvaluer la position Clean Core : personnalisation, dette technique, extensibilité, préparation aux montées de version.
Maintenir le standard Clean Core tout au long des nouvelles implémentations et déploiements.
Inventaire du code spécifique, analyse d’usage, retrait, remédiation et reconstruction en extensions side-by-side.
Intégration Clean Core : rationalisation des interfaces, bascule des connexions point à point vers des API et événements gouvernés.
Reporting spécifique basculé des objets modifiés du core vers des vues publiées et une analytique gouvernée.
Exploiter l’inventaire des extensions, les contrôles de transport et de cycle de vie, et les garde-fous pour les nouveaux développements.
Évaluation de l’impact des releases, suivi des fonctionnalités obsolètes, périmètre de non-régression et backlog de montée de version.
Former les key users et les développeurs aux niveaux d’extensibilité, pour que le bon niveau soit choisi sans accompagnement.
RH et gestion des talents standardisées entre les équipes d’usine et de siège — un modèle unique pour les effectifs de la fabrication du verre.
L’ensemble du cycle de vie des employés sur une seule couche SuccessFactors, pour des opérations agroalimentaires et de produits biologiques distribuées.
Où doit résider la logique d’extension une fois le core hors limites, et ce que coûte le side-by-side sur SAP BTP.
Le rapport donne un nombre — pas quels objets comptent, sont morts, ou méritent d’être reconstruits.
Le Clean Core signifie que le core reste standard : la personnalisation passe par des points d’extension autorisés, pas par la modification. Les montées de version restent une routine puisque votre logique n’a jamais touché aux composants internes modifiables.
Non — la personnalisation existe toujours, seul son emplacement change : outils key user, ABAP Cloud, ou side-by-side sur SAP BTP, jamais par la modification du code standard.
Trois niveaux, du moins au plus invasif : in-app pour les key users ; extensibilité développeur via ABAP Cloud ; side-by-side sur SAP BTP. Arrêtez-vous au premier niveau qui fonctionne.
ABAP Cloud est le modèle de développement restreint pour le SAP moderne : même langage, limité aux API et objets publiés — compatible avec les montées de version, avec des compétences ABAP qui restent transférables.
Une API ou un événement publié est le contrat stable et officiel de SAP. Développez sur des objets publiés, pas sur des tables, pour garder vos extensions compatibles avec les montées de version.
SAP BTP héberge les extensions side-by-side — l’environnement ABAP, SAP Build Code et SAP Build Apps construisent des applications spécifiques sur les données SAP via des interfaces gouvernées, avec des releases indépendantes du core.
Un core avec des dizaines d’interfaces point à point vers ses tables n’est pas clean. Integration Suite fait basculer ces interfaces vers des API et des événements gouvernés — un contrat publié, pas une dépendance cachée.
Pas entièrement, mais commencer par l’inventaire et le retrait revient généralement moins cher : l’analyse d’usage révèle souvent des objets inutilisés depuis des années, une décision mieux prise avant la bascule qu’en pleine conversion.
Nous commençons par un inventaire des développements spécifiques et une analyse d’usage : ce qui existe, tourne, et dépend d’objets non publiés — une vision de la dette technique, un référentiel de préparation aux montées de version et une liste d’écarts qui fondent la stratégie d’extensibilité et le plan de remédiation.
Oui — c’est même l’engagement le plus courant, la plupart des environnements S/4HANA dérivant après la mise en production (go-live). Même nature de travail : inventaire, remédiation, reconstruction de la logique en side-by-side, rationalisation des interfaces, et gouvernance pour tenir la position.
Échangez avec les architectes SAP de VISCAP sur votre position en matière de code spécifique, votre cycle de montée de version, et l’ampleur du core que vous modifiez encore.