Ce qu’est réellement un Custom Code Analyzer

En retirant la connotation marketing, il reste une pipeline qui ingère trois entrées et produit une sortie. Les entrées sont le référentiel du client, c’est-à-dire tout le path code PDEnvironnement de production dans JDE — l’environnement live. Son référentiel est la source de vérité sur les objets custom réellement présents côté client. ou équivalent, la baseline Oracle de la release source et la baseline Oracle de la release cible. La sortie est un verdict par objet : conserver, supprimer, retrofitter, réécrire.

L’arithmétique est impitoyable. Dans une installation mature, le référentiel client contient une longue traîne d’objets techniquement custom mais fonctionnellement morts — copies de standards jamais déployées, prototypes d’un proof of concept de 2014, BSFNs clonées lors d’une investigation UDC en 2017. Un tel analyzer empêche tout cela d’atteindre la phase de développement. Il applique d’abord un smart filter, et seuls les objets qui survivent au filtre peuvent consommer des heures d’ingénierie.

Le verdict par objet est ce qui rend le concept digne d’un nom. Sans lui, on traite les 12 000 objets comme du travail ; avec lui, on en traite 350 comme du travail et le reste comme du backup-and-restoreStratégie où les objets custom non modifiés sont préservés pendant l’upgrade en étant simplement copiés, sans analyse ni travail de retrofit.. Même upgrade, un sixième du budget.

Pourquoi le terme ressemble au nom d’un outil

Parce que deux ou trois fournisseurs à OpenWorld, il y a quelques années, ont commencé à vendre des produits dont le nom contient les mots analyzer, code et JDE. Ce sont de vrais produits, certains sont bons, mais aucun n’est magique. Ce que chacun de ces produits implémente en interne, c’est la même pipeline conceptuelle décrite plus haut — diff de référentiel, fingerprinting, classification — enveloppée dans une interface utilisateur.

La confusion que cela crée coûte cher. Un CIO entend l’expression et suppose que l’équipe cherche une SKU. L’équipe commence à comparer les frais de licence et passe à côté du point essentiel : la valeur est dans la discipline, pas dans l’emballage. Un tableur utilisé par un consultant senior qui a mené huit upgrades de 9.1 vers 9.2 fera mieux qu’une licence à six chiffres utilisée par quelqu’un qui n’en a jamais fait. L’outil vient après la méthode.

Traitez cette discipline comme l’intégration continue. Personne ne demande « quel CI dois-je acheter ? » sans d’abord se mettre d’accord sur ce que CI signifie. C’est la même chose ici. Décidez d’abord de la méthode, puis choisissez si vous l’implémentez avec une suite de scripts, une offre partenaire Oracle ou un outil sous licence — dans cet ordre.

Le smart filter : là où 95 % du travail disparaît

La première étape de tout analyzer digne de ce nom est le smart filter, et c’est là que chaque projet économise son budget ou le gaspille. Le filtre repose sur un principe unique : un objet ne mérite d’être analysé que si le client l’a modifié ET si Oracle l’a modifié entre la release source et la release cible.

Appliquez ce test à un référentiel typique de 12 000 objets, et environ 70 % sont retirés immédiatement comme obsolètes ou doublons — la traîne morte de la customisation cumulative. Sur les 30 % restants, la grande majorité a été touchée par le client mais pas par Oracle dans le delta de version, ce qui signifie que les modifications du client sont conservées sans travail de retrofit. Parmi ce qui reste, seuls 200 à 500 objets tombent dans la véritable intersection : modifiés par le client ET modifiés par Oracle. Ce sont les objets impactés, et ce sont ceux sur lesquels les développeurs travaillent réellement.

Les règles de filtrage semblent simples. Elles ne le sont pas, parce que chacune nécessite une liste d’exceptions. Les versions UBEUniversal Batch Engine — le moteur d’exécution batch de JDE. Les UBEs custom sont fréquents parce que chaque client a ses propres besoins de reporting. se filtrent différemment des modèles UBE sous-jacents, les ajouts UDCUser Defined Code — le terme JDE pour les tables de codes ou de lookup. Les ajouts UDC nécessitent presque jamais de retrofit, car Oracle ne possède pas le namespace. nécessitent presque jamais de retrofit, et les modifications de Business View suivent un chemin différent des vues elles-mêmes. Maîtriser ces règles est tout le savoir-faire de la discipline.

Fingerprinting : comment savoir ce qui a vraiment changé

Le smart filter indique quels objets regarder. Le fingerprint indique ce qui est réellement différent à l’intérieur. C’est la partie que la plupart des équipes sautent, puis paient pendant les tests.

Un diff naïf compare la BSFN du client avec la BSFN Oracle cible et signale chaque ligne différente. Cela produit un bruit qui noie le signal : un renommage de variable custom apparaît au même niveau qu’un changement de logique. Une comparaison basée sur le fingerprint est structurelle — elle canonicalise le code, supprime les différences de formatage, normalise les noms de variables dans un scope et produit un hash de la forme sémantique. Deux objets avec le même fingerprint sont fonctionnellement équivalents, même s’ils semblent différents dans l’éditeur.

Conséquence pratique : avec le fingerprinting, il est possible de distinguer en un seul passage un vrai conflit d’un conflit fantôme. Un vrai conflit signifie qu’Oracle a changé la logique A, que le client a changé la logique A, et que les deux changements interagissent. Un conflit fantôme signifie qu’Oracle a reformaté, que le client a renommé une variable, et qu’il n’y a aucune interaction réelle. Les vrais conflits vont à un développeur ; les conflits fantômes sont auto-résolus. Lors d’un récent passage de retrofit, le ratio fantôme/réel était proche de trois pour un — la différence entre trois semaines de développement et une.

Classification : le verdict par objet

Une fois que l’on sait ce qui a changé, on classe. Chaque objet survivant tombe exactement dans l’un de quatre buckets, et le bucket dicte le travail. L’étape de classification boucle la boucle et transforme l’analyse en plan projet.

Les quatre verdicts sont : keep — l’objet est custom, mais la baseline Oracle n’a pas changé dans le delta, donc on le conserve sans travail ; drop — l’objet était custom, mais l’équivalent Oracle dans la release cible couvre la même fonctionnalité, donc on supprime le custom et on utilise Oracle ; retrofit — Oracle l’a changé, le client l’a changé, les changements sont compatibles, donc on merge ; rewrite — les changements entrent en conflit, ou la customisation suppose un comportement runtime que la nouvelle Tools Release ne fournit plus, donc on recommence.

Le bucket drop est celui que les équipes sous-estiment. À chaque release, Oracle absorbe des fonctionnalités que les clients avaient construites en custom dans les versions précédentes : un Orchestrator fait désormais ce qu’une BSFN custom faisait, un UDO standard remplace une form extension custom, un endpoint AIS remplace une interface custom. Un analyzer qui ne vérifie pas la release cible à la recherche d’équivalents natifs laisse de l’argent sur la table — on retrofite du code qui aurait dû être supprimé. En passant de 9.1 à 9.2.7, dans une installation mature, le bucket drop représente typiquement 10 à 20 % des objets survivants.

Ce qui se trouve en amont et en aval

La pipeline n’existe pas isolément. En amont se trouvent le Planner ESUL’ESU spécial qui met à jour les schémas planner avant que tout autre ESU puisse être appliqué. C’est la fondation du processus d’upgrade. et le snapshot de l’environnement source — sans snapshot propre, l’analyzer n’a aucune entrée fiable. En aval se trouvent la phase de développement, les tests de régression, puis le cutover.

L’artefact que l’analyzer transmet à l’équipe de développement détermine les 6 à 9 semaines suivantes. Un bon handoff est un work order par objet : nom de l’objet, verdict, chemin de baseline Oracle cible, points de conflit identifiés et estimation. Un mauvais handoff est un tableur de 12 000 lignes avec une colonne « review needed ». Les équipes qui maîtrisent les connexions amont et aval terminent un upgrade de 9.1 vers 9.2 en neuf semaines de développement ; celles qui les ratent finissent en vingt-six.

Encore un point sur l’aval. La sortie de l’analyzer devrait aussi alimenter la sélection des tests de régression. Si l’analyzer indique que seuls 320 objets sont impactés, la régression devrait se concentrer sur les cas d’usage qui exercent ces 320 objets — pas sur un full-suite test de six semaines qui revalide 90 % d’un système inchangé. C’est le deuxième endroit où la discipline rapporte, et c’est souvent là que les CIO comprennent qu’ils ont acheté la bonne méthode.

Ce que cela signifie pour votre plan d’upgrade

Si vous êtes en train de cadrer un upgrade JDE et que la proposition devant vous ne décrit pas une pipeline d’analyzer sous un nom quelconque, la proposition est incomplète. L’expression n’a pas besoin d’apparaître littéralement — des synonymes comme retrofit analysis, customization assessment ou code impact study décrivent la même discipline — mais les quatre étapes doivent être présentes : snapshot, smart filter, fingerprint, classify.

Demandez au partenaire de vous présenter son analyzer sur un échantillon de cinquante de vos objets. S’il peut produire un verdict par objet en un après-midi, il possède la discipline. S’il lui faut trois semaines et un workshop, il la redécouvrira sur votre temps et votre budget. La différence, sur une installation mature avec douze mille objets custom, est l’écart entre une phase de développement de neuf semaines et une phase de six mois — et cet écart est exactement la valeur que le concept cherche à capturer.

Si vous souhaitez un second avis sur ce à quoi une telle pipeline devrait ressembler pour votre référentiel spécifique — la répartition de votre patrimoine custom, le nombre réaliste d’objets impactés pour votre delta et les buckets dans lesquels votre retrofit tombera — réservez une consultation gratuite. Nous parcourrons votre environnement ensemble, et vous repartirez avec une image concrète du travail qui vous attend réellement, ainsi que du travail que vous pouvez mettre de côté avec confiance.