Le code spécifique n’a pas cessé d’être nécessaire. Il a cessé d’être gratuit.
La plupart des paysages ECC portent des années de modifications, et chacune avait du sens en son temps. Le coût n’est devenu visible que plus tard, au moment des montées de version — quand chaque changement devait être retesté, réconcilié ou réécrit, et que les montées de version sont passées en silence de la routine à l’exception.
Le clean core est la discipline qui empêche ce cycle de recommencer sur S/4HANA. Ce n’est pas une règle contre la personnalisation. C’est une règle sur l’endroit où la personnalisation a le droit de vivre.
Le core reste standard pour pouvoir continuer d’avancer. Tout ce qui est spécifique vit à côté et évolue à son propre rythme.
Ce que signifie réellement le clean core
Le principe s’énonce simplement : le core digital exécute des processus standard, paramétrés mais non modifiés, afin que les mises à jour de plateforme puissent être prises en continu plutôt qu’au cours d’événements pluriannuels redoutés. Les besoins que le standard ne peut véritablement pas couvrir sont construits en extensions — reliées au core par des interfaces publiées, jamais tissées à l’intérieur.
Conséquence pratique : une montée de version cesse d’être une négociation avec une décennie d’objets spécifiques. Le core avance ; les extensions continuent de fonctionner, parce qu’elles n’ont jamais touché le core qu’à travers des contrats qui survivent à la montée de version.
Les recommandations clean core de SAP distinguent l’extensibilité in-app — des points d’extension publiés à l’intérieur de S/4HANA — des extensions side-by-side construites sur SAP Business Technology Platform et reliées par des API publiées.
Trois questions avant toute extension
Le standard le couvre-t-il après paramétrage ?
Une part surprenante des “besoins” sont des habitudes importées de l’ancien système. Un atelier fit-to-standard existe pour séparer ce dont l’entreprise a besoin de ce que l’implémentation précédente faisait par hasard.
Sinon — peut-il vivre dans les points d’extension publiés ?
Champs ajoutés, adaptations d’interface et logique métier circonscrite entrent souvent dans l’extensibilité in-app, conçue pour survivre aux montées de version. C’est le foyer le moins coûteux qu’une extension puisse avoir.
Sinon — il va à côté du core, pas dedans
Applications entières, logique lourde et orchestration inter-systèmes relèvent de la plateforme d’à côté, qui dialogue avec le core via des API publiées. La seule réponse inacceptable est l’ancienne : modifier le core parce qu’il est à portée de main.
Besoin→Contrôle fit-to-standard→Point d’extension in-app→Side-by-side sur BTP
Ce que coûte réellement le side-by-side
L’honnêteté compte ici, car l’arbitrage est réel. Une extension side-by-side est une application en exploitation : elle porte un abonnement de plateforme, une surface d’intégration à superviser et un cycle de vie propre. Ramenée à un besoin isolé, elle peut sembler plus coûteuse que la modification qu’elle remplace.
Rapportée à la durée de vie de la plateforme, la comparaison s’inverse généralement. Le vrai prix de la modification n’a jamais été son coût de construction — ce fut chaque montée de version qu’elle a compliquée ensuite, multipliée par chacune des autres modifications à ses côtés. Le clean core transforme un passif futur ouvert en un coût d’exploitation borné.
Ce qui va où
- Paramétrage, pas modification, à l’intérieur du core — des processus standard ajustés par des réglages supportés.
- Extensibilité in-app pour les champs ajoutés, les écrans adaptés et la logique circonscrite qui appartient au processus qu’elle touche.
- Side-by-side sur la plateforme pour les applications spécifiques, la logique différenciante et tout ce qui intègre plusieurs systèmes.
- Rien dans le code source du core. Si un besoin semble l’exiger, c’est le besoin qui mérite un second regard avant le core.
Le point de vue de VISCAP
Traitez chaque demande d’extension comme une créance sur toutes les montées de version futures. La plupart des demandes ne survivent pas à ce cadrage.
Les organisations qui peinent avec le clean core sont rarement celles qui ont le plus de besoins. Ce sont celles qui n’ont pas de chemin de décision — où chaque demande se plaide au cas par cas et où la voix la plus forte l’emporte. Les trois questions ci-dessus sont volontairement mécaniques : elles transforment la gouvernance des extensions d’un débat en une règle d’orientation.
Les montées de version sont le sujet
Un core propre n’est pas une esthétique. C’est ce qui fait de la feuille de route de la plateforme — y compris tout ce que SAP livrera ensuite — quelque chose que votre organisation reçoit plutôt qu’elle ne rachète. La discipline se rembourse la première fois qu’une montée de version est ennuyeuse.