Refactoring du code custom
À jour au 2026-08-16
Le refactoring du code custom est le risque de périmètre caché sur toute migration analytics S/4. Les clients sous-estiment régulièrement le backlog de refactoring par un facteur 2 à 3 parce qu'ils confondent 'ça fonctionne aujourd'hui' avec 'ça fonctionnera après l'upgrade'. Le scan ATC est la seule méthode défendable pour quantifier le périmètre avant estimation. Trois catégories dominent l'effort de refactoring : les extracteurs SAPI (3 à 8 jours chacun), les couches de staging Z-table (5 à 15 jours) et les routines de transformation ABAP (2 à 10 jours). Obtenir ces estimations correctement en phase architecture évite les travaux d'urgence lors du sprint go-live.
Ce que vous apprendrez
- Exécuter un scan de compatibilité Clean Core ABAP Test Cockpit (ATC) sur un périmètre d'extraction analytics et classifier tous les constats en niveaux de sévérité Critical / High / Medium, produisant un backlog de remédiation prêt pour le programme
- Appliquer le cadre de classification en quatre compartiments (Retrait / Conservation telle quelle / Lift-and-shift vers ODP-CDS / Redesign en side-car BTP) à chaque objet analytics custom dans un inventaire de migration
- Estimer l'effort de refactoring pour les trois catégories à effort le plus élevé (extracteurs SAPI, couches de staging Z-table, routines de transformation ABAP BW) — incluant plage d'effort, hypothèses et risque de non-remédiation
- Produire un brief de décision d'architecture pour un périmètre de refactoring de code custom : chemin de remédiation recommandé par objet, logique de séquencement, critères go/no-go et exigences de validation client
Le refactoring de code personnalisé est le poste de périmètre le plus systématiquement sous-estimé de tout programme de migration S/4HANA ou BDC touchant à l'analytique, car il se situe dans l'angle mort entre deux équipes qui présument chacune qu'il revient à l'autre. L'équipe basis et développement ABAP y voit une décision d'architecture qui devrait venir du côté analytique; l'équipe d'architecture analytique y voit un détail d'implémentation qui revient aux développeurs. Laissé sans propriétaire, il refait surface en milieu de programme sous la forme d'une vague de demandes de changement non planifiées, exactement au moment du calendrier où elles coûtent le plus cher à absorber. Les clients portent couramment des centaines de programmes en Z, d'extracteurs ABAP hérités et de transformations BW personnalisées qui n'ont jamais été conçues pour un monde CDS-first, conforme ODP et Clean Core, et les refactoriser n'est pas une tâche que l'on confie à un développeur avec une instruction vague du type « rends-le compatible » — c'est une décision d'architecture avec de vraies conséquences en coût, en risque et en calendrier, qu'un consultant doit activement porter.
Ce que le refactoring de code personnalisé signifie réellement dans un contexte analytique
Module complet réservé aux abonnés. Le module complet ajoute : le cadre de décision · le cas guidé de bout en bout · la grille de KPI · les anti-patterns · les blocs de code · le contrôle de connaissances · les schémas.