Dans un projet de migration vers S/4HANA, le code spécifique (les objets ABAP du « namespace client », communément appelés code Z) est rarement le sujet des premiers comités de pilotage. Il devient pourtant, quelques mois plus tard, l’un des principaux facteurs de dérive du calendrier et du budget. Ce guide compare les quatre stratégies de traitement du custom code, puis les outils qui permettent de décider objet par objet, et propose une recommandation selon le profil de l’entreprise.
Pourquoi le code spécifique pèse sur le calendrier et le coût d’un projet S/4HANA
Les échéances de maintenance fixent le cadre. D’après SAPinsider, la maintenance standard de SAP ERP 6.0 et des autres applications cœur de Business Suite 7 s’arrête fin 2027, avec une maintenance étendue optionnelle de début 2028 à fin 2030, moyennant une majoration du socle de maintenance. Pour une ETI encore sous ECC, la fenêtre de décision se resserre, et le code spécifique est précisément ce qui allonge la phase de préparation.
Trois mécanismes expliquent son poids :
- Le modèle de données change. S/4HANA simplifie plusieurs structures de la base (documents financiers, partenaires commerciaux, gestion des stocks). Tout programme qui lit ou écrit directement ces tables doit être revu. SAP fournit pour cela des contrôles dédiés dans l’ABAP Test Cockpit (ATC), avec des variantes de contrôle « S/4HANA readiness ».
- Le code est rarement documenté. Les développements ont dix ou quinze ans, leurs auteurs sont partis, les spécifications ont disparu.
- Chaque objet conservé doit être testé. Le coût d’un objet ne se limite pas à sa correction : il inclut les tests, la recette métier et la maintenance future.
La conséquence est simple : plus on conserve de code, plus la phase de remédiation et de test s’allonge. À l’inverse, chaque objet retiré avant le projet est un objet qu’on ne corrige, ne teste ni ne maintient. Cette logique est au cœur de la doctrine Clean Core de SAP, qui vise à garder le cœur de l’ERP aussi proche du standard que possible.
Étape 1 : mesurer avant de décider
Aucune stratégie ne se choisit sans inventaire. Trois mesures sont nécessaires, dans cet ordre.
Mesurer l’usage réel
Le premier réflexe est de savoir ce qui est réellement exécuté en production. SAP propose pour cela deux mécanismes. L’Usage and Procedure Logging (UPL) s’appuie sur SAP Solution Manager. Son successeur, l’ABAP Call Monitor (transaction SCMON), enregistre les appels d’unités ABAP en production et, en plus de leur fréquence, le processus appelant. Il est disponible nativement à partir d’AS ABAP 7.50, et via l’add-on ST-PI pour les versions antérieures à partir de 7.00.
Point de méthode : la collecte doit couvrir au moins un cycle métier complet, avec clôtures mensuelle, trimestrielle et annuelle. Un programme exécuté une fois par an pour la clôture fiscale paraît « mort » sur une fenêtre de trois mois.
Identifier les objets obsolètes
Une fois l’usage connu, on classe l’inventaire : objets jamais appelés sur la période, objets appelés uniquement par des utilisateurs partis, doublons de fonctions désormais couvertes par le standard, programmes de migration ou de reprise de données utilisés une seule fois. Ces objets sont les candidats naturels à la suppression.
Évaluer le taux de code mort : une hypothèse, pas une statistique
On entend souvent qu’une large part du code spécifique n’est jamais exécutée. Cette idée est plausible, et l’on trouve des ordres de grandeur dans la documentation des éditeurs d’outils, mais ils proviennent de leurs propres bases clients et ne se transposent pas à votre système. Traitez donc la fameuse « règle 80/20 » comme une hypothèse de travail à vérifier par la mesure : l’objectif de l’étape 1 est précisément de remplacer cette intuition par un chiffre propre à votre périmètre. Dans certains systèmes, le code mort sera marginal ; dans d’autres, il représentera une part considérable de l’inventaire.
Les 4 stratégies de traitement du custom code
Une fois l’inventaire qualifié, chaque objet actif relève de l’une de ces quatre voies.
1. Retirer
L’objet n’est plus utilisé, ou son besoin est désormais couvert par le standard. On le supprime (ou on le désactive avant suppression définitive). C’est la voie la moins chère et la plus rentable, mais elle suppose de valider avec les métiers que le besoin a réellement disparu.
2. Conserver et adapter
L’objet est utile, son périmètre est stable et sa correction est mécanique (remplacement d’accès à des tables simplifiées, adaptation de syntaxe). On le corrige pour qu’il fonctionne sur S/4HANA. C’est la voie la plus rapide pour les objets à faible valeur de différenciation, mais elle maintient de la dette si l’objet touche profondément au cœur de l’ERP.
3. Réécrire en extensibilité in-app
Le besoin métier demeure, mais il doit être réimplémenté avec les mécanismes d’extension officiels et stables de S/4HANA (champs et logiques personnalisés, BAdI, extensions key user, modèles CDS étendus). Le coût initial est plus élevé que pour une simple adaptation, mais l’objet devient compatible avec les mises à jour futures.
4. Déporter en side-by-side sur BTP
La fonction est extraite du cœur et reconstruite comme une extension découplée sur SAP Business Technology Platform, communiquant avec S/4HANA par API et événements. C’est la voie la plus conforme au Clean Core, adaptée aux développements volumineux, aux applications à interface spécifique ou aux fonctions partagées entre plusieurs systèmes. Elle exige en revanche des compétences nouvelles (développement cloud, intégration) et une gouvernance des coûts d’exploitation BTP. Le détail des options techniques figure dans notre guide sur les extensions BTP et le Clean Core.
Tableau de critères de choix
| Critère | Retirer | Conserver et adapter | Réécrire in-app | Déporter sur BTP |
|---|---|---|---|---|
| Usage constaté | Nul ou négligeable | Régulier | Régulier | Régulier, à forte valeur |
| Proximité du cœur (tables standard) | Sans objet | Forte, correction mécanique | Forte, à remplacer par API/extension | Faible après découplage |
| Coût initial | Le plus bas | Faible à moyen | Moyen à élevé | Élevé |
| Dette technique résiduelle | Aucune | Élevée | Faible | Faible |
| Compatibilité avec les mises à jour | Sans objet | Incertaine | Bonne | Bonne |
| Compétences requises | Analyse métier | ABAP classique | ABAP moderne, extensibilité S/4HANA | BTP, API, cloud |
| Bon candidat si | Besoin disparu ou couvert par le standard | Objet stable, peu différenciant | Besoin différenciant proche des processus cœur | Fonction volumineuse, transverse ou orientée utilisateur |
Règle pratique : commencer par la colonne de gauche. Chaque objet doit « mériter » sa place dans une colonne plus coûteuse.
Comparatif des outils d’analyse du custom code
Les outils se répartissent en deux familles : ceux fournis par SAP, souvent suffisants pour l’analyse technique, et les solutions tierces qui ajoutent l’analyse d’impact métier, le test et la sécurité. Les descriptions ci-dessous reprennent ce que les éditeurs publient sur leurs sites ; à vous de demander une démonstration sur votre propre système avant de trancher.
Outils SAP
- ABAP Test Cockpit (ATC). Outil de contrôle qualité intégré à ABAP, il permet d’exécuter des variantes de contrôle de compatibilité S/4HANA et de lister les écarts à corriger, selon SAPinsider. Il est aussi utilisé en continu pour appliquer les règles de développement Clean Core.
- Custom Code Migration app. Application Fiori fondée sur l’infrastructure ATC distante, proposée par SAP pour analyser le code spécifique dans le cadre d’une conversion S/4HANA, selon un billet du blog SAP. Elle regroupe les résultats d’analyse et aide à suivre la remédiation.
- SAP Readiness Check. Outil d’évaluation de la préparation à S/4HANA, qui inclut une vue sur le code spécifique ; il donne une première image de l’effort, à compléter par une analyse détaillée.
- SCMON / UPL. Non destinés à l’analyse de compatibilité mais à la mesure de l’usage, indispensables en amont, comme vu plus haut.
Outils tiers
- Panaya. Plateforme d’analyse d’impact et de test pour SAP. D’après la documentation de l’éditeur, elle analyse le code spécifique à partir de l’usage réel, propose des corrections automatiques et prend en charge la désactivation du code inutilisé.
- Tricentis LiveCompare. Outil d’analyse d’impact entre l’état actuel et l’état cible. Sa documentation décrit des applications dédiées : Impacted Custom Code (code à corriger du fait des changements de dépendances SAP) et Code Guard (comparaison entre usage du code spécifique et du standard, identification du code inutilisé).
- Onapsis. Spécialiste de la sécurité SAP. Selon son site, il analyse le code ABAP nouveau ou migré pour vérifier qu’il est « propre et sûr » avant la mise en production, et intègre ces contrôles aux chaînes DevSecOps, y compris pour BTP.
Tableau comparatif
| Outil | Périmètre | Forces | Limites | Profil client |
|---|---|---|---|---|
| ATC (SAP) | Contrôles techniques de compatibilité et de qualité du code | Natif, sans licence additionnelle spécifique, base de tous les autres outils | Pas d’analyse d’impact métier ni de plan de test | Toute ETI, point de départ obligatoire |
| Custom Code Migration app (SAP) | Analyse du code en vue de la conversion, via ATC distant | Suivi centralisé des résultats, évite d’installer l’analyse sur chaque système | Reste centrée sur le code, peu sur les processus et les tests | ETI avec équipe ABAP interne |
| SAP Readiness Check | Évaluation globale de préparation, dont une vue custom code | Vision rapide pour cadrer le projet | Niveau de détail insuffisant pour piloter la remédiation | Phase de cadrage de toute ETI |
| Panaya | Analyse d’impact, remédiation, tests | Combine usage réel, corrections proposées et tests | Solution commerciale, à budgéter ; rentabilité liée au volume de code | ETI très customisée, intégrateur en appui |
| Tricentis LiveCompare | Analyse d’impact et priorisation des tests | Compare état actuel et état cible, utile pour le périmètre de test | Mêmes réserves de coût et de prise en main | Groupe multi-systèmes, programmes de tests lourds |
| Onapsis | Sécurité du code ABAP et des transports | Détecte des failles que les contrôles de compatibilité ignorent | Ne traite pas la compatibilité S/4HANA en tant que telle | Secteurs régulés, code exposé |
Ces outils ne sont pas exclusifs. Une combinaison courante : SCMON et ATC pour l’inventaire et la compatibilité, un outil tiers si le volume justifie l’automatisation, un contrôle de sécurité sur le code conservé.
Recommandation par profil
ETI avec un parc de code spécifique modeste. Si l’inventaire reste limité (de l’ordre de quelques milliers d’objets, seuil que vous devrez définir avec votre équipe plutôt que de le prendre pour une norme), les outils SAP suffisent. Démarrez par SCMON sur un cycle complet, exécutez ATC avec les variantes S/4HANA, supprimez le code mort, adaptez le reste. Réservez la réécriture aux objets réellement différenciants.
ETI très customisée. Quand le code touche tous les processus (finance, logistique, production), l’analyse manuelle devient le goulot d’étranglement. Un outil tiers d’analyse d’impact et de remédiation assistée devient défendable, à condition de le justifier par un chiffrage comparant son coût à celui des heures de développement et de test évitées. Engagez ici une vraie réflexion de fond : une application historique très modifiée peut aussi plaider pour une approche Greenfield, que nous comparons dans notre guide de décision Greenfield, Brownfield et SDT.
Groupe multi-systèmes. Plusieurs systèmes ECC partagent souvent des développements copiés, légèrement divergents. Dédupliquez d’abord, harmonisez ensuite, puis traitez un référentiel commun. Les outils d’analyse d’impact et de test à l’échelle (LiveCompare, Panaya) trouvent ici leur meilleur usage, et le side-by-side sur BTP permet de mutualiser les extensions entre entités.
Gouvernance : éviter de recréer la dette après la migration
Nettoyer le code ne sert à rien si de nouveaux développements non conformes réapparaissent dix-huit mois plus tard. Quatre mesures structurent la gouvernance.
- Un comité de design des extensions. Toute demande de développement passe par une instance qui vérifie d’abord si le standard, la configuration ou une extension key user couvre le besoin. Le développement spécifique devient l’exception argumentée. Pour les besoins simples, des approches low-code évitent d’ouvrir un chantier ABAP.
- Des règles de développement Clean Core écrites. Interfaces stables uniquement, pas de modification du standard, pas d’accès direct aux tables non publiées. Ces règles sont appliquées automatiquement par ATC dans la chaîne de transport.
- Un registre des extensions. Chaque objet a un propriétaire métier, un but documenté et une date de revue.
- Des indicateurs de suivi. Par exemple : nombre d’objets spécifiques actifs, part des objets sans propriétaire, nombre d’écarts ATC ouverts, répartition des extensions entre in-app et BTP. Choisissez peu d’indicateurs, suivez-les chaque trimestre.
Budget et planification : où le code spécifique ajoute du temps
Sans avancer de chiffres qui varieraient d’un projet à l’autre, on peut situer les postes où le custom code pèse sur le planning :
- La phase d’inventaire et d’analyse, souvent sous-estimée, surtout si la collecte d’usage (SCMON) démarre tard : un cycle métier complet ne se raccourcit pas.
- La remédiation, qui dépend directement du nombre d’objets conservés. C’est le poste que l’étape 1 permet de réduire le plus.
- Les tests, généralement le poste le plus long : chaque objet conservé ou réécrit doit être rejoué par les métiers.
- La réécriture et les extensions BTP, qui demandent des compétences rares et une montée en charge de l’équipe.
- La période de gel des développements, durant laquelle les évolutions courantes de l’ECC doivent être limitées pour ne pas déplacer la cible.
Pour le calendrier, lancez la mesure d’usage dès que le principe de migration est acté, bien avant le choix de l’intégrateur : elle conditionne le chiffrage. Pour le budget, présentez au comité de pilotage un coût par stratégie (retirer, adapter, réécrire, déporter) plutôt qu’une enveloppe globale « custom code ».
Pour aller plus loin
DigitsLane propose un audit du custom code : inventaire, mesure d’usage, classement des objets selon les quatre stratégies et chiffrage de la remédiation, pour arriver au comité de pilotage avec des chiffres propres à votre système. Contactez DigitsLane pour cadrer cet audit.
Pour approfondir le choix de trajectoire, lisez notre guide Greenfield, Brownfield ou Selective Data Transition et notre analyse de la stratégie Clean Core et des extensions BTP.
