Tout système JD Edwards ayant quelques années d'existence porte en lui une question sans réponse facile : combien des objets personnalisés développés au fil du temps sont encore fondamentalement identiques au standard Oracle dont ils sont issus, et combien ont évolué au point de devenir quelque chose de complètement différent ? Cette question devient urgente lors d'un upgrade, d'une migration ou d'un audit des personnalisations. Dans la plupart des cas, la réponse n'existe pas — parce que personne ne l'a jamais cherchée de façon systématique. Dans cet article, je décris comment j'aborde ce problème dans mon travail, et l'outil propriétaire que j'ai développé pour le résoudre.

Qu'est-ce que JD Edwards et pourquoi ce problème existe-t-il ?

JD Edwards (communément appelé JDE) est un ERP d'entreprise développé par Oracle, très répandu dans les secteurs de la fabrication, de la distribution, ainsi que dans l'industrie pétrolière, gazière et de la construction. Comme tous les systèmes ERP haut de gamme, JDE propose un ensemble d'objets « standard » — applications, rapports, business functions et business views — qui couvrent les processus métier de base.

La réalité opérationnelle, cependant, est qu'aucune entreprise n'utilise JDE pur. Chaque implémentation s'accompagne de dizaines, voire de centaines de personnalisations : des objets standard sont copiés, renommés avec un préfixe personnalisé (typiquement dans la plage 55–69 selon la nomenclature JDE), et modifiés pour s'adapter aux processus spécifiques du client.

Cela crée un problème très concret : comment savoir, des années plus tard, quel standard se trouve à la base d'un objet personnalisé ? La traçabilité se perd. Les développeurs changent. La documentation vieillit ou n'existe pas.

Le problème technique : retrouver l'origine d'un objet personnalisé

Dans mon travail de conseil JDE, je dois souvent analyser des repositories entiers d'objets personnalisés — parfois des centaines de fichiers — pour répondre à des questions telles que :

• Ce P55001 est-il une copie du P4210 ? Et dans quelle mesure s'en est-il éloigné ?
• Cette Business Function est-elle encore fondamentalement identique au standard, ou a-t-elle été réécrite ?
• Quels objets ont été modifiés de façon substantielle et lesquels correspondent encore à l'original ?

Le problème n'est pas trivial pour plusieurs raisons.

Le contenu est bruité. Les exports JDE contiennent une grande quantité de boilerplate : commentaires standard, en-têtes de copyright, déclarations de structure répétitives. Si l'on compare le texte brut, le bruit l'emporte sur le signal.

Les noms ne suffisent pas. Un P554210 dérive probablement du P4210, mais un P55001 pourrait dériver de P4101, P4201 ou d'un objet complètement différent. La convention de nommage n'est pas toujours respectée, et dans certains cas le préfixe personnalisé ne suit aucune logique par rapport à l'original.

L'échelle rend la comparaison manuelle impraticable. Avec 200 standards et 400 objets personnalisés, une comparaison manuelle génère 80 000 combinaisons possibles. Ce n'est pas une opération humaine.

L'approche : un moteur d'analyse hybride

Pour résoudre ce problème, j'ai développé COS-Analysis, un outil desktop propriétaire qui aborde la comparaison sur trois niveaux distincts, combinés en un score pondéré final.

Niveau 1 — Nettoyage et normalisation du contenu

Avant toute comparaison, chaque fichier est soumis à une phase de preprocessing :

• Suppression du boilerplate fixe (en-têtes de copyright, déclarations structurelles répétitives spécifiques à JDE)
• Suppression du bruit de mise en page (positions, dimensions, identifiants UI)
• Remplacement du nom spécifique de l'objet par un placeholder générique, afin de neutraliser les différences de nommage lors de la comparaison textuelle

Cette étape est critique : sans normalisation, deux objets identiques dans leur comportement mais avec des en-têtes de copyright différents apparaîtraient comme dissemblables, et deux objets différents mais portant le même nom pourraient sembler artificiellement similaires.

Niveau 2 — Comparaison du contenu textuel via WinnowingAlgorithme de fingerprinting documentaire : représente chaque texte comme un ensemble de hachages extraits de fenêtres glissantes de séquences de caractères. Conçu à l'origine pour la détection du plagiat académique, il est robuste face aux modifications partielles du texte.

Le cœur de la comparaison textuelle est basé sur l'algorithme WinnowingAlgorithme de fingerprinting documentaire : représente chaque texte comme un ensemble de hachages extraits de fenêtres glissantes de séquences de caractères. Conçu à l'origine pour la détection du plagiat académique, il est robuste face aux modifications partielles du texte., une technique de fingerprinting documentaire développée à l'origine pour la détection du plagiat académique. L'idée est de représenter chaque document comme un ensemble de fingerprints de k-grammesUn k-gramme est une séquence contiguë de k caractères (ou tokens) extraite d'un texte. Par exemple, avec k=4, le mot « HELLO » génère les k-grammes : HELL, ELLO. Le fingerprinting sur k-grammes permet de comparer des textes même lorsqu'ils ont été partiellement modifiés. textuels, extraits via une fenêtre glissante.

Cette approche présente un avantage fondamental par rapport au TF-IDFTerm Frequency–Inverse Document Frequency : technique statistique qui mesure la pertinence d'un mot dans un document par rapport à une collection. Les mots très fréquents reçoivent un faible poids ; les mots rares et spécifiques reçoivent un poids élevé. classique (que j'utilise comme solution de repli) : il est robuste face aux transformations partielles. Si un objet n'a été modifié que dans certaines sections, Winnowing détecte quand même le chevauchement structurel dans les parties inchangées, produisant un score de similarité significatif même en présence de modifications substantielles.

La partie la plus lourde du calcul Winnowing est implémentée via un module natif compilé en Rust, intégré en Python. Cela réduit considérablement les temps d'analyse sur de grands repositories par rapport à une implémentation purement Python.

Niveau 3 — Fingerprint structurelUne « empreinte digitale » de l'objet JDE : au lieu de comparer le texte complet, on extrait un ensemble réduit de tokens sémantiquement significatifs (forms, tables, views, joins) qui représentent la structure logique de l'objet, indépendamment du code. via JaccardL'indice de Jaccard mesure la similarité entre deux ensembles : c'est le rapport entre les éléments communs (intersection) et le total des éléments distincts (union). Valeur 1 = ensembles identiques, valeur 0 = aucun élément commun.

La comparaison textuelle seule n'est pas suffisante. Deux objets JDE peuvent avoir un contenu textuel similaire mais une structure complètement différente. C'est pourquoi j'ai ajouté une deuxième couche basée sur le concept de structural fingerprintUne « empreinte digitale » de l'objet JDE : au lieu de comparer le texte complet, on extrait un ensemble réduit de tokens sémantiquement significatifs (forms, tables, views, joins) qui représentent la structure logique de l'objet, indépendamment du code. : un ensemble de tokens sémantiquement pertinents extraits du fichier.

Pour chaque type d'objet JDE, le jeu de tokens est différent :

• Pour les APPL : Form ID et Business View associée
• Pour les UBE : View et Report Interconnect
• Pour les BSVW : tables et définitions de jointures
• Pour les BSFN : nom de la fonction interne et DSTR associée

La similarité entre les deux ensembles de tokens est calculée via l'indice de JaccardL'indice de Jaccard mesure la similarité entre deux ensembles : c'est le rapport entre les éléments communs (intersection) et le total des éléments distincts (union). Valeur 1 = ensembles identiques, valeur 0 = aucun élément commun. (rapport entre intersection et union), qui mesure dans quelle mesure les deux objets partagent la même « anatomie », indépendamment de la façon dont le code est écrit.

Niveau 4 — Méta-logique sur le nom normalisé

La quatrième composante est plus simple mais a un impact important sur la précision. Chaque objet personnalisé est analysé pour identifier son « parent théorique » : en supprimant le préfixe numérique personnalisé du nom (ex. P55 → P, R564 → R), on obtient le nom de l'objet standard dont il dérive très probablement.

Si cette correspondance existe dans le repository des standards, le score du candidat correspondant reçoit un bonus pondéré. Ce mécanisme réduit drastiquement les faux positifs dans les cas où la convention de nommage a été respectée.

Le score final et la classification

Les trois composantes — Winnowing, Jaccard structurel et méta-logique — sont combinées avec des poids définis pour produire un score de similarité final compris entre 0 et 1. Le résultat est ensuite classifié en quatre catégories :

Pour chaque correspondance, l'outil génère automatiquement la commande de comparaison pour Beyond Compare (un outil de diff très répandu dans l'écosystème JDE), permettant à l'analyste d'ouvrir immédiatement le diff visuel entre l'objet personnalisé et son standard de référence en un seul clic.

Résultats et utilisation pratique

À l'issue de l'analyse, COS-Analysis produit un rapport Excel avec tous les résultats, triés par type d'objet et score de similarité décroissant. Chaque ligne contient le nom de l'objet analysé, la meilleure correspondance standard trouvée, le pourcentage de similarité, la classification et la commande Beyond Compare prête à l'emploi.

Dans ma pratique quotidienne, ce rapport devient le point de départ pour les activités d'upgrade assessment, de gap analysis et de documentation des personnalisations. Dans les contextes où l'on aborde une migration vers une nouvelle release JDE, savoir précisément quels objets personnalisés sont encore proches de l'original et lesquels s'en sont éloignés permet de planifier les activités de réingénierie de façon éclairée, et non intuitive.

Conclusions

Le problème de l'identification des copies des standards JDE est un problème réel, récurrent et souvent sous-estimé dans la planification des projets. L'approche hybride multi-niveaux que j'ai implémentée dans COS-Analysis — combinant preprocessing sémantique, Winnowing avec moteur Rust, similarité structurelle Jaccard et méta-logique sur le nommage — permet d'obtenir des résultats précis même sur de grands repositories, dans des délais qui rendent l'analyse praticable.

Si vous gérez un système JDE et que vous faites face à ces défis, je suis disponible pour en discuter.