Clean Core avec SAP CAP : étendre SAP CX sans douleur à chaque mise à jour

Vous personnalisez SAP. Un an plus tard, une mise à jour casse vos modifications et votre équipe passe des semaines à les réparer. C’est l’une des histoires que nous entendons le plus souvent de la part d’entreprises qui arrivent chez nous avec un paysage SAP existant.

C’est le coût du code personnalisé dans le noyau SAP. Il s’accumule sans bruit : après quelques cycles, chaque version devient un petit projet à part entière, et l’équipe finit par redouter les notes de version au lieu de les lire.

Clean Core met fin à ce cycle. Le noyau SAP reste standard, et la logique sur mesure se construit à côté, pas à l’intérieur, avec le cadre d’extension que SAP met à disposition.

En bref : Clean Core signifie aucune modification dans le noyau SAP. Nous construisons les extensions side-by-side avec le SAP Cloud Application Programming Model (CAP) sur SAP BTP. Elles dialoguent avec SAP Sales Cloud V2, Service Cloud V2 ou S/4HANA Public Cloud par des API et des événements publiés. Quand SAP livre une version, vous retestez le contrat d’API de vos extensions au lieu de réparer du code modifié dans le noyau.

Que signifie concrètement Clean Core ?

Le principe : aucun code personnalisé dans SAP. Votre logique métier vit dans des extensions séparées qui communiquent avec SAP par des API stables et publiées. SAP en a fait sa recommandation explicite pour l’ERP en cloud ; l’article SAP How to Extend SAP S/4HANA Cloud the Right Way explique le modèle. Dans SAP S/4HANA Public Cloud, ce n’est même pas facultatif : la plateforme n’autorise que des points d’extension publiés.

SAP Sales Cloud V2 et SAP Service Cloud V2 suivent la même logique. Ils offrent des API REST, documentées sur le SAP Business Accelerator Hub, et un système d’événements conçu pour les extensions side-by-side. SAP met à jour le noyau à son rythme, et vos extensions continuent de fonctionner tant que le contrat d’API tient.

Ce n’est pas un contournement. Les produits V2 ont été conçus pour séparer le noyau de la logique client.

Comment construisons-nous les extensions avec SAP CAP ?

Nous utilisons le SAP Cloud Application Programming Model (CAP), le framework de SAP pour créer des services sur SAP BTP, et nous exécutons ces services dans l’environnement Cloud Foundry de SAP BTP. C’est notre standard pour les extensions side-by-side sur Sales Cloud V2, Service Cloud V2 et S/4HANA Public Cloud, pour trois raisons :

• Peu de travail d’infrastructure. Cloud Foundry gère la montée en charge, le routage et le déploiement. L’équipe écrit de la logique métier, pas des scripts d’exploitation.
• Connectivité SAP intégrée. CAP fonctionne avec XSUAA pour l’authentification, le Destination service et la messagerie d’événements SAP, et consomme les API de Sales et Service Cloud V2 sans code de liaison.
• Une pile standard. Node.js ou Java, OData et REST, CDS pour la modélisation des données. Les développeurs connaissent déjà les outils, sans dépendance exotique.

Le résultat : des extensions que vous déployez, testez et mettez à jour indépendamment du calendrier des versions SAP. Nous décrivons toute la mise en place, du sous-compte au déploiement, dans étendre SAP Sales Cloud V2 avec des applications Cloud Foundry personnalisées et, côté ERP, dans étendre S/4HANA Public Cloud sur BTP Cloud Foundry. Quand la logique doit rester proche des données ERP, S/4HANA propose aussi ABAP Cloud on-stack, présenté dans notre article sur embedded Steampunk.

À quoi cela ressemble-t-il en pratique ?

Exemple Sales Cloud V2 : un client a besoin d’une validation personnalisée sur l’opportunité et de quelques champs supplémentaires pour son processus. Nous déployons sur Cloud Foundry un service CAP qui porte la logique de validation et les données supplémentaires. Il réagit aux événements de l’opportunité au lieu d’interroger le système ou de lancer des tâches planifiées. Une interface personnalisée est intégrée à Sales Cloud V2 sous forme de mashup, et les commerciaux travaillent dans une seule interface.

Le noyau de Sales Cloud V2 reste intact. À la version SAP suivante, nous retestons les appels d’API et les événements dont dépend l’extension ; il n’y a pas de code modifié dans le noyau à réparer.

Exemple Service Cloud V2 : règles d’escalade personnalisées, données de dossiers enrichies, connexions à des outils de ticketing externes. Toutes des extensions CAP sur Cloud Foundry, toutes hors du noyau.

Exemple S/4HANA Public Cloud : le même schéma s’applique quand un processus CX a besoin de données ERP, par exemple un contrôle de solvabilité avant la validation d’une offre. L’extension appelle des API S/4HANA publiées et ne touche jamais le noyau ERP. C’est ainsi qu’une seule équipe garde à la fois le noyau ERP et la pile CX dans le standard.

Pourquoi Clean Core compte-t-il pour votre budget ?

Le code personnalisé qui casse lors des mises à jour est l’une des raisons les plus fréquentes pour lesquelles les projets SAP dépassent délais et budgets. Beaucoup de responsables informatiques ont vécu une mise à jour qui a mal tourné parce qu’une modification faite des années plus tôt n’avait jamais été documentée.

Sans Clean Core, chaque version SAP a un coût : l’équipe teste le code personnalisé, l’adapte et répare ce qui a cassé, à chaque fois. Avec Clean Core, une version consiste surtout à retester vos extensions face à un contrat d’API que SAP versionne et maintient stable. Le gain de temps dépend de la quantité de logique que vous sortez du noyau, mais l’effort passe de la réparation au test de régression.

Sur trois à cinq ans, cette différence s’additionne. Moins de temps pour la maintenance, c’est plus de temps pour des fonctionnalités qui font avancer l’entreprise.

Si vous préparez un passage à S/4HANA et voulez savoir quelle part de votre code personnalisé devra être reconstruite, notre évaluation de préparation S/4HANA y répond avant le début du projet. Pour choisir un partenaire qui construit les extensions de cette manière, consultez notre panorama des meilleurs partenaires de développement SAP BTP en Suisse.

Questions fréquentes

Et si mon extension a besoin de données du noyau SAP ?

Une extension CAP lit et écrit les données par les API publiées de SAP Sales Cloud V2, Service Cloud V2 ou S/4HANA Public Cloud. Les changements, comme une nouvelle opportunité, lui sont signalés par des notifications d’événements, par exemple via SAP Event Mesh. Elle n’accède jamais directement à la base de données du noyau.

Peut-on migrer des personnalisations existantes vers Clean Core ?

Oui, mais c’est un travail de refactoring, pas un simple déménagement. L’ABAP personnalisé ou les modifications du noyau sont reconstruits en services side-by-side ou en extensions on-stack publiées. La logique métier reste la même ; l’architecture change.

Clean Core fonctionne-t-il aussi pour SAP Commerce Cloud ?

Le principe est le même, le mécanisme diffère. Commerce Cloud utilise des extensions dans son système de types et des points d’extension définis plutôt que des modifications du noyau. Côté frontend, SAP Composable Storefront (anciennement Spartacus) sépare les personnalisations grâce à l’injection de dépendances d’Angular.

CAP est-il la seule option pour les extensions Clean Core ?

Non. Toute technologie qui appelle les API publiées de SAP convient, par exemple Java, Node.js, Python ou le low-code avec SAP Build. Nous utilisons CAP parce qu’il intègre l’authentification, la modélisation des données et la connectivité SAP ; c’est le chemin le plus court vers des extensions prêtes pour la production.

Quel est l’effet de Clean Core sur le support SAP ?

SAP prend en charge son produit standard. Les modifications du noyau peuvent compliquer les incidents, car SAP doit d’abord écarter le code personnalisé. Les extensions side-by-side laissent le standard intact, et vous assurez le support de vos extensions séparément.

Vous lancez un projet Sales Cloud V2, Service Cloud V2 ou S/4HANA Public Cloud ? Parlez à nos architectes d’une approche Clean Core dès le premier jour.