Audit Licences JD Edwards
L'Audit Licences JD Edwards est un rapport généré, pas une grille. Il s'exécute sur une application connectée et assemble un livrable complet de conformité et d'optimisation : ce qui est souscrit, ce qui est réellement utilisé, où se trouve le risque financier et comment le réduire. La sortie est un PDF soigné — ou un Markdown — prêt à remettre à un comité de pilotage.
Il s'appuie sur les données que Nomasx-1 collecte déjà — Object Usage Tracking, affectations de rôles et de droits, matrice de séparation des tâches et inventaire des licences par application — et les transforme en un document narratif unique.
Ce rapport cible une application JD Edwards EnterpriseOne et son socle technologique Oracle. L'application connectée est identifiée par son apps_id Nomasx-1.
En un coup d'œil
Le livrable
Un document confidentiel, aux couleurs de la marque, d'environ trente à quarante pages — PDF pour le comité de pilotage, Markdown quand on veut l'éditer ou l'intégrer. La couverture porte le titre Audit Licences JD Edwards – {client}, le sous-titre Analyse de conformité et plan d'optimisation des licences Oracle, et un bloc Client / Date / Auteur / Version ; chaque page est marquée Confidentiel en pied. La rédaction est en français, langue de travail de l'audit.
C'est un document interne de conformité et d'optimisation — la base de vos propres décisions et de la préparation d'un renouvellement de contrat, pas une déclaration à remettre à l'éditeur.
Ce que contient le rapport
Neuf sections, chacune construite à partir des données collectées par Nomasx-1 :
- Synthèse — résumé pour la direction : contexte et objectifs, les constats principaux assortis chacun d'un niveau de risque, le risque financier estimé et les recommandations clés.
- Périmètre de l'audit — composants audités, ce qui est hors périmètre, le tableau des environnements JD Edwards (production vs hors production) et l'architecture technique : versions logicielles, inventaire des serveurs et un schéma d'architecture que le rapport génère automatiquement.
- Méthodologie — les outils et données utilisés, les règles d'analyse (l'usage se mesure à la consommation réelle, pas aux autorisations) et un tableau des sources de données qui date chaque entrée.
- Licences acquises — l'inventaire souscrit : Oracle Database Enterprise Edition (NUP), les options et packs, les composants détectés en usage, la règle des minimas et le minimum NUP calculé à partir du nombre de processeurs ; puis l'Oracle Technology Foundation de JD Edwards et les modules applicatifs.
- Utilisation et conformité — le cœur du rapport :
- les modules JD Edwards croisés OUT × transactions — consommation réelle face à l'activité d'écriture — avec un détail sur les modules peu utilisés (quel utilisateur a touché quel objet) ;
- les autorisations face à l'usage réel par module (utilisateurs autorisés vs OUT vs transactions vs nombre de rôles), qui met en évidence des accès bien plus larges que l'usage effectif ;
- l'analyse d'optimisation (voir plus bas) ;
- l'analyse des utilisateurs Oracle Technology Foundation (déclarés / actifs / désactivés, comptes techniques, affectations de rôles) et le décompte des utilisateurs de la base Oracle.
- Risque financier — la méthode de calcul (prix public Oracle plus trois ans d'arriérés de support), chaque risque identifié chiffré ligne à ligne, un montant consolidé, les leviers priorisés et l'analyse des devis Oracle éventuellement en cours de négociation.
- Plan de remédiation — un nettoyage concret : désactivation des comptes jamais utilisés, et rationalisation des rôles et des accès (suppression des rôles non affectés, revue des cumuls de rôles excessifs, alignement des accès sur l'usage réel).
- Recommandations et plan d'action — chaque action classée par priorité, effort et impact financier, un planning indicatif en quatre phases, et les indicateurs de suivi à surveiller ensuite.
- Annexes — la liste détaillée des utilisateurs à désactiver (avec dates de création et de dernière modification, et les précautions de validation à appliquer avant désactivation) et un glossaire.
L'analyse d'optimisation
Au-delà de la seule conformité, le rapport exploite l'extraction OUT détaillée — une ligne par utilisateur × module × objet — pour dimensionner les licences au besoin réel plutôt qu'à l'octroi global d'« usage complet » :
- la répartition du nombre de modules par utilisateur (la plupart ne touchent qu'une poignée de modules) ;
- les combinaisons de modules les plus fréquentes, qui se regroupent autour d'un noyau commercial / logistique ;
- deux profils d'usage — Standard (le noyau) et Étendu (le noyau plus au moins un module spécialisé) ;
- une proposition de répartition en bundles différenciés à porter dans un renouvellement de contrat.
C'est ce qui fait passer l'audit d'un instantané de conformité à un levier d'optimisation des coûts — la section sur laquelle se construit la négociation du renouvellement.
Exécuter le rapport
Le rapport se trouve sous Rapports dans la barre latérale de Nomasx-1, sur la page Exécuter un rapport et télécharger le résultat en PDF ou markdown. du framework. Choisir Audit Licences JD Edwards dans la liste, renseigner les paramètres, choisir un Format, puis Exécuter et télécharger.
| Paramètre | Requis | Valeur par défaut | Ce qu'il définit |
|---|---|---|---|
| Application | Oui | — | L'apps_id à auditer. Doit exister dans le registre des applications (Configuration → Global → Applications). |
| Connecteur cible | Non | nomasx1 | Le pool de connecteurs qui héberge les tables Nomasx-1. |
| Schéma | Non | public | Le schéma de base de données sur ce connecteur. |
| Libellé de date d'audit | Non | mois + année en cours | Le libellé imprimé sur la page de couverture (ex. Mai 2026). |
| Nom du client | Non | le nom de l'application | Le nom du client sur la page de couverture. |
Format — PDF pour le livrable du comité de pilotage, markdown quand on veut éditer ou intégrer le contenu. L'exécution renvoie le fichier directement dans le navigateur.
Avant d'exécuter
L'audit lit les données que Nomasx-1 a déjà collectées pour l'application — il ne collecte pas à la volée. Pour un état fidèle, vérifier au préalable que la dernière collecte a bien été réalisée. Le rapport s'appuie sur :
- Object Usage Tracking — la synthèse (utilisateurs distincts par module), le détail (utilisateurs / objets / dates) et le détail fin (une ligne par utilisateur × module × objet) qui alimentent les sections Utilisation et conformité et optimisation.
- Les modules avec transactions — les utilisateurs ayant généré au moins une écriture par module.
- La liste des utilisateurs JD Edwards — utilisateurs déclarés, actifs et désactivés, avec dates de création et de dernier usage.
- Les rôles, les affectations utilisateur-rôle et les droits d'accès par rôle, plus les menus JDE (mapping objet → module) qui relient l'usage aux modules.
- L'inventaire des options et packs de la base — composants Oracle en usage face à ceux souscrits.
- L'inventaire des licences et la tarification (Licences et Configuration → Pricing), faute de quoi les chiffres financiers s'écartent du price book réel.
Une exécution sur une application sans usage collecté produit tout de même le document, mais les sections usage et finance apparaîtront vides plutôt que fausses.
Conseils et bonnes pratiques
- Exécutez-le après une collecte fraîche. L'audit est un instantané des tables courantes — planifiez-le juste après la collecte nocturne pour que les chiffres collent à la réalité.
- Renseignez le Libellé de date d'audit et le Nom du client pour une page de couverture prête à transmettre à l'extérieur ; laissez-les vides pour un brouillon interne.
- Utilisez markdown pour itérer, PDF pour livrer. La sortie Markdown reprend le même contenu sans la mise en forme de couverture, pratique pour relire avant l'export final.
- Lisez-le à côté des écrans sources. Chaque chiffre remonte à un écran — Object Usage Tracking, Conflits, Licences — pour qu'un relecteur puisse descendre de l'audit vers les données vivantes.