SAP Readiness Check vous dit ce qui va casser. Il ne peut pas vous dire ce qui mérite de survivre.
Tout programme de conversion démarre avec le même artefact : un rapport qui compte les objets spécifiques, les conflits avec les simplification items et les constats d’ajustement. Le chiffre se compte généralement en milliers, la première réaction est généralement l’alarme, et le premier réflexe — corriger tout ce que le rapport signale — est généralement l’erreur la plus coûteuse à disposition.
Le rapport est un inventaire. Le plan est un tri. Confondre les deux revient à intégrer le passé au prix du futur.
L’essentiel du code spécifique est mort, et les données d’usage le prouvent. Corrigez ce qui mérite sa place ; retirez le reste sans cérémonie.
Ce que l’outillage vous apporte réellement
Trois choses, et elles sont précieuses : un inventaire des objets spécifiques, une cartographie des points de collision avec les simplifications de S/4HANA et — lorsque la journalisation d’usage tourne depuis assez longtemps — la preuve de ce qui s’exécute réellement en production. Ensemble, elles font passer “nous avons beaucoup de code spécifique” du folklore à la donnée.
La panoplie SAP ici — Readiness Check plus les contrôles de migration du code spécifique dans ABAP Test Cockpit — identifie les conflits et l’effort d’ajustement. Les statistiques d’usage demandent des mois de collecte pour être fiables ; les activer est l’un des gestes précoces les moins coûteux qu’un programme puisse faire.
Ce qu’il ne peut pas vous dire
Si quelqu’un exécute encore l’objet
Un constat de conflit sur un état que personne n’a exécuté depuis 2019 n’est pas une tâche — c’est un candidat à la suppression déguisé en tâche. Sans données d’usage, le rapport traite les morts et les vivants à l’identique.
Si le besoin qui le justifiait existe encore
Les objets spécifiques survivent aux changements de processus, aux réorganisations et aux réglementations qui les justifiaient. La question “quelle capacité métier cela sert-il aujourd’hui ?” ne figure dans aucun journal — elle appartient aux responsables de processus, et la poser retire plus de code que n’importe quelle correction de syntaxe.
Ce que les survivants doivent devenir
“Ajuster le code” n’est qu’un verdict sur quatre. Le rapport ne peut pas voir qu’un besoin survivant est désormais couvert par le standard, ou qu’il est suffisamment différenciant pour mériter une vraie reconstruction en extension propre. Ce sont des décisions de conception, pas des constats.
Les quatre verdicts
Mesurer l’usage→Retirer ce qui est mort→Interroger les survivants→Orienter selon le clean core
Pourquoi le tri change le programme
L’arithmétique est spectaculaire et typique : sur le chiffre affiché, une large part ne s’exécute jamais, une autre duplique ce que le standard fait désormais, et le reste véritablement différenciant — le code qui mérite une vraie ingénierie — représente une fraction du nombre initial. L’estimation bâtie sur le chiffre brut et celle bâtie sur le chiffre trié sont deux projets différents.
Le tri produit en outre ce que le rapport brut ne pourra jamais donner : un récit défendable devant l’audit et le comité de pilotage sur les raisons pour lesquelles chaque objet a vécu ou disparu — capacité par capacité, et non ligne par ligne.
Le point de vue de VISCAP
L’unité de correction est une capacité métier, pas un objet. Le code n’est jamais que la trace d’un besoin — interrogez le besoin.
Nous traitons le Readiness Check comme l’ouverture d’une conversation avec les responsables de processus, pas comme un backlog. Le rapport dit où le passé est incompatible avec le futur ; seule l’entreprise peut dire quelles parties du passé méritaient d’être gardées. Les programmes qui sautent cette conversation paient des ingénieurs pour préserver des habitudes.
Le chiffre qui compte
Pas le nombre de constats en page une — mais la part de votre patrimoine spécifique avec zéro exécution sur la dernière année. Demandez ce chiffre en premier. Il recadre toutes les conversations qui suivent, généralement en une seule réunion.