Anciens systèmes R/3 et ECC

Mais ce que nous et nombre de mes sœurs et frères de la tribu SAP avons autrefois célébré comme un avantage concurrentiel se révèle être un héritage de plomb face à la transformation numérique vers S/4. Les monolithes SAP ERP qui se sont développés, parsemés de millions de lignes de notre code personnalisé, ressemblent aujourd'hui davantage à des sites de fouilles archéologiques qu'à des architectures informatiques modernes. Nombre de ces systèmes ont grandi au fil des années pour devenir de purs colosses, modifiés au point d'être méconnaissables, avec souvent jusqu'à 60% du code qui n'est plus utilisé en cours d'exploitation - comme j'ai pu le constater - mais qui génère néanmoins des coûts de maintenance et des risques de sécurité.

Le défi de la conversion d'Abap est ici bien plus qu'une tâche technique assidue ; c'est une coupe brutale dans l'histoire de notre groupe. Alors que les précédents changements de version étaient souvent de nature purement technique et confirmaient le slogan „Never change a running system“ (comme le rédacteur en chef Färbinger ne se lasse pas de le souligner), S/4 exige un changement radical de paradigme. Le passage à Hana et le nouveau modèle de données ERP rendent obsolètes de nombreuses anciennes constructions Abap. Les simples instructions SQL qui faisaient confiance à l'existence de certains agrégats ou index tombent à l'eau, et les fameux "Simplification Items" de SAP obligent les développeurs à revoir leur code en profondeur, voire à le rejeter.

Attention : de nombreuses anciennes fonctions qui ont continué à fonctionner dans le cadre de la première migration S/4, voir Compatibility Packs, ont dû être converties aux nouvelles fonctions S/4 avant la fin 2025. La SAP Simplification List définit pour chaque version S/4 des milliers de modifications et de suppressions fonctionnelles qui déterminent en grande partie le processus de conversion du système. Il ne suffit plus d'adapter le code sur le plan syntaxique ; il faut l'aligner sémantiquement sur la nouvelle logique du „Principle of One“, qui élimine rigoureusement les fonctions redondantes. Dans ce contexte de tension entre conservation et innovation, SAP promeut la stratégie „Clean Core“ comme la seule issue au piège de la modification. La philosophie est simple, mais sa mise en œuvre est pour le moins douloureuse pour nous ! Mais nous voyons la lumière au bout du tunnel : un ancien compagnon de route du professeur Hasso Plattner au HPI de l'université de Potsdam, le professeur Dr Alexander Zeier, a présenté un système d'IA comme stratégie de sortie pour Clean Core et les modifications Abap.

Le noyau numérique du système ERP doit rester propre, exempt de modifications, afin de garantir la capacité de mise à niveau et l'agilité dans le cloud. L'époque où l'on bidouillait directement dans le programme SAP standard (modification) est révolue. Le nouveau modèle exige une stricte séparation du code standard et des extensions. Pour les clients SAP existants, cela signifie qu'ils doivent transférer leurs chers programmes Z et applications Dynpro vers des architectures modernes et natives du cloud.

Mais comment réussir ce grand écart sans étouffer les processus commerciaux ? La réponse réside dans un modèle d'extension différencié. Les extensions critiques, qui sont étroitement liées aux données et aux transactions du noyau, peuvent être réalisées en tant que „On-Stack Extensions“ au moyen d'Abap-Cloud. Tout le reste, en particulier les innovations détachées ou les applications mobiles, appartient à la BTP en tant qu'extension side-by-side, découplée du noyau ERP. Pour les anciens systèmes, cela signifie souvent un refactoring massif : le code doit être analysé, nettoyé et, s'il ne correspond pas au standard, soit emballé dans un wrapper, soit entièrement réécrit.

Dans cette tempête de transformation, le Customer Center of Expertise (CCoE) de SAP revêt une toute nouvelle importance existentielle, ce qui a donné lieu à de vives discussions à notre table ronde SAP. Alors que dans le monde on-prem, le CCoE (CCC à l'époque où je dirigeais activement l'informatique) était souvent responsable en premier lieu du support de premier niveau et de la gestion des licences, il doit désormais se transformer en centre de contrôle stratégique de l'environnement informatique hybride. Le CCoE ne représente plus seulement l'exploitation opérationnelle, mais la gouvernance de l'ensemble de l'architecture. Il doit surveiller le respect des principes du "clean core" et s'assurer que les services spécialisés ne retombent pas dans les anciens schémas et ne produisent pas de croissance sauvage.