Que reste-t-il après une migration d'ECC vers S/4HANA ?

L'échéance de 2027 n'est pas la date à laquelle il faut commencer une migration d'ECC vers S/4HANA. C'est la date à laquelle les décisions difficiles, les réécritures, les répétitions et les validations métier doivent être terminées. La conversion SAP standard fait rarement dérailler les programmes. Le problème vient du système privé construit autour de SAP pendant vingt ans : programmes Z, includes modifiés, user exits, BAdI, traitements en arrière-plan, échanges de fichiers, formulaires, rapports et hypothèses que personne n'a consignées.

Traiter ce patrimoine comme un tas d'ABAP qui doit simplement compiler produit un système techniquement au vert dont le comportement métier est cassé. L'évaluation doit établir quatre faits distincts pour chaque objet : fonctionne-t-il encore, SAP autorise-t-il toujours son point d'extension, quelqu'un l'utilise-t-il encore et son résultat reste-t-il juste ? Ces questions demandent des preuves différentes. Un seul scan ne peut pas répondre aux quatre.

L'échéance de 2027 change l'ordre des travaux

L'engagement de maintenance publié par SAP prévoit la maintenance standard des applications principales de SAP Business Suite 7 jusqu'à la fin de 2027, avec une maintenance étendue facultative jusqu'à la fin de 2030 pour les clients qui l'achètent. Cette extension donne de l'air, pas une conception de migration. Les achats peuvent payer une couverture de support. Ils ne peuvent pas racheter les années nécessaires pour comprendre une logique de clôture non documentée ou reconstruire sans risque une interface d'entrepôt.

Le premier jalon raisonnable est donc une évaluation qui produit des preuves, pas une diapositive d'architecture cible. Elle doit laisser un inventaire des objets, des données d'usage réelles, des groupes de dépendances, les impacts connus des simplifications, des comportements métier testables et des responsables nommés. Si elle ne produit qu'un nombre d'objets personnalisés par package, elle a compté le problème sans le décrire.

Commencez pendant qu'ECC représente encore la vérité. La charge de production, l'historique des jobs, le trafic des interfaces et les résultats financiers rapprochés sont bien plus utiles que des souvenirs recueillis après un gel. Dès que les équipes arrêtent des jobs ou changent les intégrations pour le programme, la référence est contaminée. J'ai vu des équipes tenter de reconstruire un ancien comportement de clôture mensuelle à partir de comptes rendus parce que personne n'avait capturé une exécution propre. On peut l'éviter.

L'échéance change aussi le séquencement. L'analyse du code personnalisé doit précéder un périmètre de conversion ferme, car ses conclusions peuvent modifier la destination. Une transaction ECC très modifiée peut devenir une extension S/4HANA, un service séparé, une fonction standard ou être retirée. Impossible d'estimer honnêtement ces options avant de connaître le code et les données touchés par chaque transaction.

Le patrimoine personnalisé dépasse l'espace de noms Z

Une liste des objets Z est un bon point de départ et une définition dangereuse du périmètre. Le comportement propre au client peut vivre dans des espaces de noms, des modifications d'objets SAP, des implémentations d'extensions, du code généré, des variantes, des règles de workflow, du contenu BRFplus, des formulaires, des chaînes de jobs, des branches liées aux autorisations et des programmes externes qui appellent des RFC ou lisent des fichiers. Certains codes très sensibles ne contiennent aucune transaction Z qu'un responsable métier reconnaîtrait.

Construisez l'inventaire depuis plusieurs sources et gardez les clés de jointure. Les métadonnées du référentiel montrent ce qui existe. ATC et les contrôles S/4HANA indiquent les motifs statiques incompatibles avec la version cible. SCMON et SUSG montrent les procédures exécutées sur une période d'observation représentative. Les données de charge ST03N relient transactions et utilisateurs. L'historique SM37 expose les chemins batch. SPAU et SPDD montrent où le client s'est écarté de SAP. Les catalogues d'interfaces, destinations RFC, configurations IDoc et calendriers de transfert couvrent les chemins hors dialogue.

Ne réduisez pas trop tôt ces données à un score de risque. Conservez au moins, pour chaque objet, son identité dans le référentiel, package, composant, dernière modification, relations appelant-appelé, exécution observée, processus métier, données touchées, constat de simplification, mécanisme d'extension, preuve de test et responsable. Un objet non observé peut être un rapport de fin d'année. Un utilitaire très appelé peut présenter peu de risque s'il ne fait que formater des dates. Fréquence et conséquence sont deux axes distincts.

Le code atteint indirectement est la catégorie délicate. Un user exit invoqué par le traitement standard peut ne jamais apparaître comme transaction nommée dans les statistiques de charge. Un module fonction peut s'exécuter uniquement via un RFC externe. Une routine de formulaire peut être choisie par le customizing. L'analyse des dépendances doit partir des points d'entrée métier et traverser les appels, tables, messages, jobs et interfaces. Compter les objets isolés cache les groupes qui doivent migrer ensemble.

J'inclus aussi les artefacts d'exploitation. Variantes de jobs, destinations d'impression, chemins de fichiers logiques, déclencheurs d'événements, certificats et utilisateurs techniques ne sont pas de l'ABAP, mais le comportement reconstruit en dépend souvent. Une équipe qui déclare le code terminé alors que Basis reconstitue ces dépendances pendant la bascule n'a pas terminé son évaluation.

La compilation prouve moins qu'on ne le voudrait

Un contrôle syntaxique propre prouve que le compilateur accepte le programme dans le nouvel environnement. Il ne prouve pas que le programme lit les mêmes enregistrements, applique le même ordre, comptabilise les mêmes pièces, respecte les mêmes verrous ou finit dans sa fenêtre batch. La compatibilité est un passage obligatoire et un test métier faible.

S/4HANA modifie les modèles de données et propose par endroits des vues de compatibilité pour faciliter la transition. Les anciennes lectures peuvent ainsi continuer tout en cachant un défaut d'architecture. Un code peut lire des données plausibles dans une vue de compatibilité tout en contournant l'API publiée ou le modèle sémantique attendu. La bonne décision peut être de remplacer l'accès, de retirer le chemin personnalisé ou de le garder temporairement avec une date d'expiration explicite. Un résultat ATC vert ne prend pas cette décision de conception.

Le comportement implicite de la base crée aussi une fausse confiance. Prenez cette ancienne routine :

SELECT * FROM vbap
  INTO TABLE @DATA(items)
  WHERE vbeln = @order_number.

READ TABLE items INDEX 1 INTO DATA(first_item).

Sans ORDER BY, la base ne garantit pas la première ligne. Si le code suivant considère l'index un comme le poste le plus ancien, un changement de base ou de plan d'exécution peut modifier le résultat sans erreur de syntaxe. La réparation ne consiste pas à ajouter un tri arbitraire jusqu'à ce qu'un test passe. L'équipe doit retrouver la règle métier voulue, la coder explicitement et tester les cas limites comme les postes rejetés, renumérotés ou supprimés.

SQL natif, hints de base, hypothèses sur les tables pool ou cluster, mises à jour directes des tables SAP et larges SELECT * méritent une attention particulière, mais ils ne forment pas toute l'évaluation. Les appels dynamiques, les routines chargées en field-symbols et les instructions générées peuvent échapper au traçage statique simple. Associez les constats automatisés à une lecture ciblée autour des points d'entrée aux conséquences fortes. L'analyse statique donne une carte. Elle n'explique pas pourquoi la route existe.

User exits et BAdI sont des contrats

On ne peut pas juger une implémentation d'extension d'après son seul contenu. Son véritable contrat comprend le moment où SAP l'appelle, les données complètes à cet instant, l'exécution en dialogue ou en update task, les exceptions gérées par l'appelant et la logique standard ultérieure susceptible d'écraser les changements. Un BAdI de remplacement au nom proche peut avoir un contrat différent.

Les user exits et customer exits classiques portent souvent peu de code mais beaucoup de poids métier. Quelques lignes peuvent dériver un centre de profit, rejeter une commande, changer un prix ou orienter une validation. Pendant l'évaluation, notez pour chaque implémentation le déclencheur, l'état d'entrée, les effets de bord, le comportement en erreur et le consommateur en aval. Associez-la ensuite au point d'extension recommandé pour la version et le modèle de déploiement S/4HANA exacts. Ne supposez pas qu'une option sur site existe sous la même forme dans chaque cible.

La recommandation courante qui consiste à remplacer immédiatement chaque exit par un BAdI est trop grossière. Elle paraît moderne et donne au programme un indicateur facile, mais le conteneur ne détermine pas la qualité de la conception. Certaines logiques appartiennent à une extension in-app publiée, d'autres à un service side-by-side, d'autres à la configuration standard et d'autres doivent disparaître. Déplacer une logique opaque dans un hook plus récent préserve son opacité.

Les modifications d'objets SAP exigent une décision encore plus ferme. Demandez pourquoi elles existaient, si SAP a ensuite fourni la fonction et si le métier dépend toujours de l'écart. Le travail SPAU ne doit pas devenir un rituel qui réapplique chaque changement historique. Toute modification réappliquée alourdit les futures montées de version. Son responsable doit donc la défendre avec des preuves actuelles et un test qui échoue en son absence.

Documentez la décision comme un contrat : pour cet événement et cet état métier, l'extension doit produire ces changements ou cette erreur, sans modifier ces champs protégés. Cette formulation reste utile que la cible soit ABAP, de la configuration, Go ou un workflow hors du coeur.

Les données d'usage ont besoin d'un calendrier métier

Les preuves d'exécution sont indispensables, mais une fenêtre d'observation n'est pas représentative uniquement parce qu'elle est longue. Les systèmes SAP comportent clôture trimestrielle, fiscalité de fin d'année, inventaire annuel, tarification saisonnière, extractions d'audit et jobs réservés aux opérations exceptionnelles. Décider qu'un code est inutilisé exige un calendrier métier et un responsable, pas seulement une date de dernière exécution.

Utilisez SCMON pour recueillir l'usage au niveau des procédures et SUSG pour agréger les résultats destinés à l'analyse du code personnalisé. Croisez ces preuves avec l'historique de charge, les calendriers batch et le suivi des interfaces. La période d'observation doit inclure volontairement les événements importants pour l'organisation. Si elle ne peut couvrir un événement annuel, examinez les preuves de l'exécution précédente et interrogez l'opérateur qui rapproche ses résultats.

Classez les candidats en conserver, modifier, retirer ou non résolu. Ne supprimez pas du code non résolu pour améliorer un tableau. Un retrait réclame trois preuves : aucune exécution pertinente, aucun point d'entrée configuré ou indirect et l'accord d'un responsable métier. Archivez la décision et les dépendances afin qu'une objection tardive puisse être traitée sans recommencer la découverte.

L'usage aide aussi à choisir les tests. Le code fréquent fournit beaucoup de trafic de production, mais les chemins rares et lourds de conséquences exigent des scénarios préparés. Une libération de crédit ou correction fiscale peu fréquente peut mériter plus de tests qu'un rapport ouvert chaque matin. Classez selon les dommages d'un résultat faux, la difficulté de détection et les possibilités de reprise.

La logique dupliquée est un autre piège. Deux programmes Z peuvent calculer différemment la même notion en dialogue et en batch. L'analyse d'exécution voit deux objets actifs. L'analyse métier doit voir une règle contestée. Faites apparaître ces désaccords avant la migration. Réécrire fidèlement les deux préserverait un défaut dans la connaissance de l'organisation.

Les constats de simplification exigent une décision

SAP Readiness Check, le Simplification Item Catalog et les contrôles ATC apportent des preuves essentielles, mais chaque constat demande une interprétation locale. Un élément de simplification signale un changement technique ou fonctionnel pertinent. Il ignore si votre programme est devenu inutile, si une compatibilité temporaire suffit ou quel résultat métier doit survivre.

Pour chaque constat, consignez l'objet et le processus touchés, la décision proposée, le mécanisme cible, le test qui la prouve et la personne qui l'accepte. Évitez les clôtures comme "adapté" ou "sans objet" sans preuve. Six mois plus tard, personne ne saura si "sans objet" signifiait code inaccessible, faux positif, processus retiré ou hypothèse jamais contrôlée.

Une séquence de revue pratique ressemble à ceci :

1. Exécutez les contrôles ATC de la version cible sur tout le périmètre personnalisé, modifications et espaces de noms compris.
2. Reliez les constats à l'usage observé et aux groupes de dépendances au lieu de traiter les objets par ordre alphabétique.
3. Retracez chaque groupe à fort impact jusqu'à un point d'entrée métier et un responsable.
4. Choisissez retrait, maintien temporaire, adaptation ou nouvelle conception, et écrivez la raison.
5. Joignez une preuve exécutable : cas de régression, résultat rapproché, échange d'interface enregistré ou exception approuvée.

Cette séquence évite un échec courant : les développeurs ferment des milliers de constats locaux alors que le programme manque un processus intersystème. Le nombre de constats mesure la taille d'une file de travail, pas l'état de préparation. Un groupe avec douze constats et un test de parité connu peut être plus sûr qu'une routine de comptabilisation construite dynamiquement qu'aucun outil ne résout.

Gardez les exemptions limitées et datées. Si un constat demeure parce qu'une vue de compatibilité est admise pendant la transition, nommez l'hypothèse de version et la condition de retrait. Les dérogations permanentes sans décision documentée deviennent le chantier archéologique de la prochaine migration.

Les interfaces cassent aux frontières de responsabilité

Une évaluation d'interface doit couvrir le protocole, le sens des données et l'accord d'exploitation. Les équipes inventorient souvent RFC, IDoc, API et fichiers, puis estiment une interface comprise parce qu'elles connaissent son endpoint. Les pannes se cachent dans le sens des champs, l'ordre, les doublons, les accusés de réception et la réparation manuelle quand un côté est indisponible.

Partez des échanges observés et de la configuration, pas du nom du catalogue. Notez qui initie l'échange, son calendrier ou déclencheur, l'authentification, la version du payload, la forme des volumes, le timeout, les règles de reprise, l'idempotence, l'ordre supposé et le responsable du rapprochement. Pour les fichiers, ajoutez noms, encodage, séparateurs, totaux de contrôle, répertoires de dépôt et archivage. Pour les IDoc, gardez type de message, type de base, extensions, profils partenaire, statuts et jobs de retraitement. Pour les RFC, cherchez les appelants externes autant que les destinations SAP.

L'ABAP personnalisé expose souvent un contrat par accident. Un consommateur peut dépendre d'un champ non documenté, d'un texte précis, du vide plutôt que zéro ou de l'ordre des lignes. S/4HANA peut offrir une API publiée plus propre, mais changer d'endpoint n'efface pas ces hypothèses. Comparez ancien et nouveau contrats champ par champ, puis décidez d'adapter le consommateur, de placer une couche de compatibilité à la frontière ou de versionner l'échange.

Le rapprochement mérite son propre test. Une réponse HTTP réussie ou un statut IDoc vert prouve une livraison jusqu'à une étape technique. Cela ne prouve pas que les deux systèmes ont accepté exactement une fois le même événement métier. Définissez la clé métier de rapprochement, les totaux ou états comparés par les opérateurs, le délai admis et la procédure de reprise sans doublon de comptabilisation. Capturez les exceptions actuelles, car le traitement manuel peut contenir des règles absentes du programme.

Je demande aux équipes de suivre une panne de bout en bout. Imaginons qu'ECC écrive chaque nuit un fichier de prix, le transfère à un entrepôt et archive la source. Le transfert expire après le stockage chez le destinataire mais avant qu'ECC note le succès. La reprise envoie une seconde copie. Si le destinataire identifie les fichiers seulement par leur nom d'arrivée, il importe les deux et modifie deux fois la valeur de stock. La migration doit préserver ou améliorer la détection de doublons, pas seulement reproduire le chemin heureux. Un test de parité doit provoquer expiration, reprise et rapprochement.

Les interfaces contraignent aussi l'ordre de bascule. Si un système externe ne peut pas adopter le nouveau contrat le même jour, définissez une coexistence bornée et le responsable de sa suppression. Évitez les couches de compatibilité bidirectionnelles sans propriétaire clair des données. Elles paraissent souples dans le plan et deviennent permanentes quand personne ne peut prouver quel côté fait autorité.

Considérez chaque consommateur non documenté comme un risque ouvert. Examinez les traces réseau et gateway disponibles, l'activité des utilisateurs techniques, les journaux de collecte de fichiers et demandez aux opérateurs quels extraits ils déplacent à la main. Explicitez le contrat avant de changer le producteur. Le pire moment pour découvrir qu'une petite base de bureau consomme encore un rapport Z est après la première clôture du nouveau système.

La parité doit être enregistrée avant la réécriture

Le meilleur moment pour capturer le comportement attendu est celui où ECC traite encore le travail réel et où finance, chaîne logistique et opérations rapprochent encore les résultats. Une réécriture testée uniquement sur des exemples fabriqués manque les combinaisons étranges accumulées par des années d'usage.

Construisez un harnais de parité autour des frontières métier. Pour les rapports, comparez ensembles triés et totaux, avec des tolérances documentées pour les champs dont la représentation change légitimement. Pour les interfaces, enregistrez requêtes, réponses, IDoc, fichiers et effets de bord, puis rejouez des cas assainis sur la cible. Pour les écritures, comparez types de pièces, imputations, montants, devises, taxes, changements de statut et messages d'erreur dont dépendent les opérateurs. Masquez les données sensibles sans détruire les combinaisons qui déclenchent la logique.

Un enregistrement de test utile peut rester simple :

{
  "case_id": "sales-order-credit-hold",
  "entry_point": "order_create",
  "input_ref": "fixture/credit-hold-017.json",
  "expected": {
    "status": "HELD",
    "posted_documents": 0,
    "message_id": "ZCREDIT-014"
  }
}

Les identifiants sont illustratifs, mais la forme oblige l'équipe à dire ce qui compte comme égal. Ajoutez préconditions et effets de bord protégés si nécessaire. Conservez le résultat capturé brut et la comparaison normalisée pour que les réviseurs voient ce que le harnais ignore. Si la normalisation retire horodatages, ordre ou identifiants générés, documentez pourquoi ces écarts n'ont pas de sens métier.

Le trafic de production enregistré demande une sélection attentive. Rejouer chaque appel est rarement nécessaire, et le volume brut peut surreprésenter les cas simples. Choisissez classes d'équivalence, montants limites, combinaisons de statuts rares, erreurs et chaque branche réglementaire ou contractuelle connue. Ajoutez les règles trouvées à la lecture du code même si elles n'apparaissaient pas pendant la capture.

La parité n'oblige pas à préserver une mauvaise architecture. Elle fixe le comportement externe utile et permet des frontières et une propriété des données plus nettes. CodeHero suit cette approche pour réécrire l'ABAP : sa plateforme lit tout l'arbre, puis un harnais compare le nouveau système au trafic de production enregistré pendant que l'architecture change. Le harnais soutient la validation, pas la ressemblance entre ancien et nouveau code source.

Certains codes ABAP ne doivent pas entrer dans S/4HANA

Une migration permet de réduire le coeur personnalisé, mais le "clean core" n'ordonne pas de déplacer chaque programme discutable vers une autre plateforme. L'emplacement dépend du comportement, de la transaction, de la propriété des données, de la latence et du modèle de support. Déporter une validation étroitement couplée peut ajouter des pannes sans créer de frontière utile.

Gardez la logique près du coeur quand elle doit participer de façon synchrone à une transaction SAP et que la cible fournit une extension publiée avec le bon contrat. Sortez-la quand elle porte une capacité distincte, peut utiliser API ou événements publiés et profite d'un cycle indépendant. Remplacez le code par le standard S/4HANA quand le métier accepte la règle standard. Retirez-le quand les preuves montrent que le processus n'existe plus.

Le langage cible vient ensuite. Go peut convenir aux services avec interfaces et exploitation claires. Rust peut convenir aux noyaux numériques où exactitude et contrôle comptent. TypeScript peut convenir aux clients et workflows. Aucun ne répare un contrat métier absent. Si l'équipe ne sait pas dire ce qu'une routine ABAP doit faire, la traduire dans un langage à la mode rend seulement l'incertitude plus chère.

Méfiez-vous du code distant qui traite toujours les tables SAP comme sa base privée. Extraire un programme Z en gardant le couplage direct crée un monolithe distribué auquel s'ajoutent les pannes réseau. Définissez un contrat d'API ou d'événement, la propriété de l'état, les reprises et l'idempotence, puis testez les pannes partielles. Un schéma propre qui omet le rapprochement n'est pas une conception achevée.

Il existe aussi une frontière humaine. Les spécialistes ABAP connaissent souvent les exceptions que les architectes classent comme dette technique. Associez-les aux responsables de processus et aux ingénieurs cibles. Il ne s'agit pas de préserver toutes les anciennes implémentations, mais de ne pas jeter leur connaissance avant que la règle métier ait un autre foyer.

Le livrable doit permettre une décision go ou no-go

Une évaluation crédible montre à un dirigeant ce qui peut être retiré, adapté ou redessiné, ce qui reste inconnu et les preuves de chaque affirmation. Elle permet aussi à un ingénieur de remonter d'un risque majeur aux objets, dépendances, trafics et tests. Si l'un des deux a besoin d'une histoire orale séparée, le livrable est incomplet.

Organisez le travail par capacité métier et groupe de dépendances, pas par milliers d'objets. Pour chaque groupe, montrez périmètre, points d'entrée, usage, impacts de simplification, dépendances de données et interfaces, cible, couverture de parité, responsable et décisions ouvertes. Estimez et séquencez par groupe, car les objets d'un flux de comptabilisation ou d'exécution migrent rarement seuls.

Fixez des critères de sortie explicites. Chaque objet personnalisé doit appartenir à un groupe ou à un ensemble de retrait justifié. Chaque groupe à forte conséquence a besoin d'une cible et d'un responsable. Chaque comportement conservé doit avoir une source de test. Chaque point ouvert a besoin d'une date de décision et des preuves requises. Ces critères exposent l'incertitude au lieu de la cacher dans un pourcentage.

Ne laissez pas le programme déclarer la découverte terminée tant que les preuves de production manquent. Enregistrez maintenant trafic représentatif, résultats rapprochés et exécutions exceptionnelles pendant qu'ECC est disponible et fiable. Les contrôles statiques peuvent être relancés plus tard. Une branche de fin d'année ou un appelant externe oubliés ne se recréent pas sur commande.

L'échéance 2027 est réelle, car les choix de maintenance se resserrent et coûtent plus cher. La panique reste une mauvaise méthode. L'action immédiate est précise : autoriser la collecte d'exécution, figer le format d'inventaire, choisir le premier groupe métier à forte conséquence et capturer son comportement. Avec ces preuves, architecture, coût et calendrier deviennent des décisions d'ingénierie plutôt que des suppositions.

Budgétez l'incertitude, pas seulement les corrections connues. Réservez une capacité de décision aux objets sans responsable, appels dynamiques, rapports non reproductibles et interfaces dont les consommateurs restent inconnus. Ce ne sont pas des détails administratifs. C'est là que le périmètre change tard, quand quelqu'un découvre enfin la fonction du code.

Placez les preuves sous gestion de versions et mettez-les à jour quand le programme modifie ECC. Un transport urgent, une variante de job revue ou un changement d'interface après la capture initiale peut invalider carte et tests. Appliquez une règle simple : tout changement de production pendant la migration doit nommer le groupe, la décision et les scénarios de parité qu'il touche. La référence ne dérivera pas en silence loin du système à convertir.

Enfin, répétez le processus de décision autant que le logiciel. Donnez aux responsables un groupe réellement ambigu et exigez le choix d'une cible, l'approbation du comportement retiré et l'acceptation des preuves de parité. Si personne n'a cette autorité pendant l'évaluation, le même sujet attendra en réunion de bascule avec moins de temps et de moins bonnes options.