Code Z et clean core : quand vos développements custom cassent après un upgrade
Un développement Z hors du périmètre clean core, une mise à jour SAP qui modifie un objet standard, et votre code plante en production. Décryptage d'un risque technique devenu juridique.
- Le clean core est la doctrine SAP : tout développement custom doit être isolé via les API et extensions stables, jamais en modifiant le standard.
- Un code Z qui s'appuie sur des objets internes non garantis peut casser silencieusement après n'importe quelle mise à jour S/4HANA.
- Quand votre custom plante en production après un upgrade, le client cherche un responsable : le consultant qui a écrit ou validé le code.
- La RC Pro couvre votre responsabilité de développeur, et une assurance matériel protège votre poste de travail et licences, outil de production indispensable.
Le clean core, une promesse fragile
SAP a fait du clean core le pilier de sa stratégie S/4HANA. L'idée : ne plus jamais modifier le cœur standard, isoler tout besoin spécifique dans des extensions propres, via les BAdI relâchés, les CDS Views d'extension, l'in-app extensibility ou les API stables. Objectif : pouvoir mettre à jour le système sans casser le custom, et préparer le terrain pour le cloud et les montées de version trimestrielles.
Sur le papier, la promesse est séduisante. En pratique, l'héritage de vingt ans de développements Z dans ECC pèse lourd. Lors d'une conversion brownfield, des centaines de programmes Z, includes, user-exits et modifications du standard remontent. Tout reprendre selon le clean core coûte cher et prend du temps. Alors on transige. On garde du code Z qui s'appuie sur des tables et des objets non garantis par SAP.
C'est là que le risque se loge. Un objet interne non relâché peut changer de structure, disparaître ou se comporter différemment à la prochaine mise à jour. Votre code ne lèvera aucune alerte au moment de la conversion. Il cassera plus tard.
Pourquoi le custom plante après coup, et pas avant
Le piège du code Z mal isolé, c'est son caractère différé. Tout fonctionne au go-live. Les tests passent. Le client est satisfait. Puis arrive une mise à jour de support package ou une montée de version, et soudain un programme planche en production.
Les causes typiques :
- Un appel direct à une table standard dont la clé ou la structure a évolué.
- L'usage d'un module fonction interne, non relâché, supprimé ou modifié par SAP.
- Une modification du standard via une enhancement mal placée qui entre en conflit avec une correction SAP.
- Un accès à un champ qui n'existe plus depuis la bascule vers le modèle de données simplifié de S/4HANA.
Le délai entre votre intervention et le crash est précisément ce qui rend le sinistre vicieux : au moment où ça casse, vous n'êtes peut-être plus sur la mission. Mais votre nom est dans les commentaires du programme.
Du bug technique à la mise en cause juridique
Quand un développement Z fait tomber un flux critique, l'entreprise ne raisonne pas en termes de doctrine SAP. Elle constate une perte, cherche une cause, et la cause a un auteur. Le consultant qui a écrit le code, ou celui qui l'a relu et validé dans le cadre d'une revue d'architecture, peut être mis en cause.
La question juridique devient : avez-vous respecté les règles de l'art ? Or les règles de l'art en S/4HANA incluent désormais explicitement le clean core et l'usage des API stables. Avoir codé en accédant directement à des objets internes non garantis, sans alerte écrite au client, fragilise sérieusement votre position en cas de litige.
C'est un dommage immatériel consécutif à une faute professionnelle : exactement le périmètre d'une RC Pro adaptée au conseil ERP. Elle prend en charge l'indemnisation du préjudice client et vos frais de défense, y compris quand le débat technique nécessite une expertise contradictoire pointue.
Le matériel, votre angle mort souvent oublié
On pense responsabilité, on oublie l'outil. Un consultant S/4HANA travaille sur un poste puissant : licences de développement, environnements locaux, accès VPN clients, documentation technique, jeux de tests sensibles. Si ce poste est volé, détruit par un dégât des eaux ou rendu inutilisable, votre activité s'arrête net.
Reconstituer un environnement de travail complet, racheter le matériel et restaurer les configurations peut représenter plusieurs milliers d'euros et plusieurs jours d'arrêt facturable perdus. Une assurance du matériel informatique couvre le vol, la casse et les dommages sur votre équipement professionnel, partout où vous intervenez, y compris en clientèle.
Pour un freelance dont le poste de travail est l'outil de production, c'est une protection complémentaire logique de la RC Pro : l'une couvre ce que vous faites, l'autre ce avec quoi vous le faites.
Cinq réflexes pour rester dans les règles de l'art
Réduire le risque de custom qui casse passe par une discipline d'architecture et une traçabilité de vos décisions.
- Privilégier systématiquement les extensions relâchées : API stables, BAdI relâchés, CDS Views d'extension plutôt que l'accès direct au standard.
- Utiliser l'ATC (ABAP Test Cockpit) avec les variantes de contrôle S/4HANA et clean core pour détecter les usages non conformes avant la livraison.
- Documenter chaque écart au clean core par écrit, avec validation explicite du client, en mentionnant le risque sur les futures mises à jour.
- Tester le custom après chaque support package et inclure cette vérification dans le contrat de maintenance.
- Conserver vos rapports d'architecture et vos alertes : ce sont vos meilleures preuves en cas de mise en cause différée.
La bonne pratique technique est aussi votre meilleure défense juridique. Le reste relève de l'assurance.
Questions fréquentes
Le clean core est la doctrine SAP qui impose d'isoler tout développement custom via des extensions et API stables, sans modifier le standard. S'en écarter sans alerter le client peut être qualifié de manquement aux règles de l'art en cas de litige.
Potentiellement, si le code s'appuyait sur des objets internes non garantis sans que vous ayez alerté le client par écrit. La RC Pro couvre ce type de mise en cause différée et les frais de défense associés.
Oui. La responsabilité s'attache à la faute, pas à votre présence. C'est pourquoi la traçabilité de vos préconisations et une RC Pro avec une bonne gestion de la reprise du passé sont essentielles.
Votre poste de travail est votre outil de production : licences, environnements locaux, accès clients. Vol, casse ou dégât des eaux peuvent arrêter votre activité. L'assurance matériel couvre le remplacement et limite l'interruption.
L'ABAP Test Cockpit détecte beaucoup d'usages non conformes au clean core et constitue une excellente preuve de diligence, mais il ne supprime pas le risque résiduel. Il se combine avec une documentation écrite et une RC Pro.
Souscrivez votre assurance pro en 2 minutes
Toutes nos protections pour votre activité de Consultant SAP S/4HANA — attestation immédiate, sans engagement.
* Tarifs indicatifs « à partir de », selon votre profil, votre activité et les garanties choisies. · Voir la fiche Consultant SAP S/4HANA →
Article rédigé et vérifié par l'équipe Insurio — Tutassûr, courtier en assurance immatriculé à l'ORIAS sous le n° 22001730. Information à caractère général ne se substituant pas aux conditions de votre contrat.