SAP Clean Core : la personnalisation qui vous coûte plus cher que la migration
Chaque ligne de code ajoutée dans le noyau SAP se paie deux fois : une fois pour l'écrire, une fois pour la porter lors de chaque montée de version. Le clean core n'est pas une contrainte technique, c'est un choix économique.
Quand une entreprise prépare son passage à S/4HANA, la question posée est presque toujours la même : combien de temps, combien de coût, combien de ressources. Rarement celle qui détermine réellement le budget : combien de personnalisations allons-nous devoir porter, tester et maintenir pendant les dix prochaines années.
Le noyau SAP n'est pas figé. Il évolue deux fois par an avec les versions de S/4HANA Cloud, et chaque évolution doit cohabiter avec ce que l'entreprise a ajouté. Une modification posée en 2019 dans un user exit peut bloquer une montée de version en 2027 — et personne ne s'en apercevra avant la phase de test.
Ce que le clean core veut dire concrètement
Le clean core n'est pas l'interdiction de personnaliser. C'est une hiérarchie explicite des manières d'étendre le standard, de la plus durable à la plus coûteuse.
- Configuration : le paramétrage prévu par SAP. Aucun coût de maintenance, aucune rupture lors des montées de version.
- Extension in-app : les objets d'extension proposés par SAP (points d'extension, BAdI). Ils suivent le cycle de vie du standard.
- Extension side-by-side : un service externe qui lit et écrit via API. Coût d'intégration, mais indépendance des versions.
- Modification du noyau : le code SAP lui-même. C'est la seule catégorie qui casse à chaque mise à jour.
« Est-ce que SAP sait déjà le faire ? » Si la réponse est oui, c'est de la configuration. Si la réponse est non, la vraie question devient : « est-ce que cela doit vivre dans le noyau, ou à côté ? » Dans la très grande majorité des cas, à côté.
Pourquoi la personnalisation coûte plus cher qu'on ne le croit
Le coût visible d'une personnalisation est celui du développement. Le coût réel est ailleurs : il est dans les tests de non-régression à chaque montée de version, dans la documentation qui n'est jamais à jour, dans la personne qui a écrit le code et qui est partie, et dans le délai de mise à jour que l'entreprise repousse parce que « ça marche comme ça ».
Un rapport de force s'installe alors : l'entreprise ne peut plus suivre le rythme des versions, donc elle accumule du retard, donc elle finit par ne plus mettre à jour du tout. Le système reste en service, mais il cesse de progresser. C'est le scénario le plus fréquent, et le plus coûteux à corriger.
Trois décisions qui changent la trajectoire
1. Cartographier l'existant avant de migrer
Un inventaire des objets personnalisés, avec leur criticité et leur usage réel, révèle souvent qu'une part significative n'est plus utilisée. Supprimer avant de migrer coûte moins cher que porter.
2. Poser une règle d'extension, pas une interdiction
La règle utile est simple : toute demande de personnalisation passe par une revue qui qualifie le niveau d'extension. Sans cette revue, chaque demande locale devient une dette globale.
3. Mesurer ce que coûte une montée de version
Suivre le nombre d'objets personnalisés, le nombre de tests de non-régression et le délai de mise à jour. Ce sont les trois indicateurs qui disent si le clean core progresse ou recule.
« Le standard n'est pas une limite. C'est ce qui vous permet de bénéficier, gratuitement, de ce que les autres ont appris. »
Ce qu'il faut retenir
Le clean core ne se décide pas au moment de la migration. Il se décide à chaque demande de personnalisation, pendant des années. Une entreprise qui n'a jamais posé la règle se retrouve, au moment du passage à S/4HANA, à devoir arbitrer entre reporter sa migration et financer un chantier de nettoyage qu'elle n'avait pas prévu.
La bonne question n'est donc pas « comment migrer plus vite », mais « qu'est-ce que nous acceptons de porter pendant dix ans ».
Retour aux articles