Nomasx-1
Le connecteur JD Edwards de Nomasx-1 est le moteur d'origine du produit et il est inclus en standard. Il accède aux tables de sécurité JDE (utilisateurs, rôles, environnements, security workbench, menus), rapatrie l'historique Object Usage Tracking depuis le JDE Object Librarian et lit les vues DBA Oracle de la base sous-jacente — le tout depuis une seule datasource configurée. Un client JDE-sur-Oracle passe de l'installation à une première photographie prête pour l'audit en quelques heures, pas en semaines.
Le problème que Nomasx-1 résout
Les équipes qui doivent répondre aux questions de conformité ne regardent jamais le même écran. Les données de sécurité sont dans le security workbench de l'ERP, les données de licence dans un tableur tenu à la main par les achats, les analyses SoD dans une matrice Excel inchangée depuis des mois, et les options de base de données dans des vues DBA que personne hors IT ne sait lire.
Nomasx-1 remplace les tableurs, les exports manuels et la course annuelle par une photographie continue, maintenue par le produit lui-même.
Ce qu'est Nomasx-1
Une plateforme unique qui aspire chaque source utile — ERP, base de données, annuaire — et la transforme en un petit ensemble de grilles, tableaux de bord et rapports utilisés au quotidien par l'équipe conformité.
Les quatre piliers
- Liste maître des utilisateurs avec création, dernière connexion, dernière activité et attributs ERP.
- Affectations de rôles avec dates d'effet et d'expiration — expiré-mais-toujours-actif remonte en rouge.
- Réconciliation LDAP / AD — chaque compte ERP est rapproché de l'annuaire.
- Doublons, comptes dormants, comptes sans rôle — détectés automatiquement.
- Enregistre chaque appel d'objet sur les applications connectées et l'agrège par composant de licence.
- Distingue les accès dormants (accordés mais jamais utilisés) des accès actifs.
- Comptes d'utilisateurs et dates de dernière utilisation par composant — la preuve derrière les chiffres de licence.
- Capture passive — aucun besoin d'activer l'audit ERP, aucun impact opérationnel.
- Customer Support Identifiers et licences rattachées — le côté contractuel.
- Par base de données, la liste des options Oracle requises selon ce que les scripts de collecte ont trouvé sur l'instance.
- Cohortes JDE par application — utilisateurs activés, transactionnels, dormants, transactions orphelines.
- Rapport d'utilisation et Rapport financier — requis vs acquis et l'écart monétaire.
- Matrice SoD éditable — risques ERP prédéfinis plus vos propres ajouts.
- Modèle processus / activité / risque — conflits décrits en langage métier, pas en couples de rôles bruts.
- Conflits classés par utilisateur, par rôle, par objet — l'ordre de remédiation.
- Conflits prouvés isolés des conflits théoriques — seules les actions utilisateur réellement effectuées.
Un aperçu de ce qu'on voit
La photographie côté licence, une ligne par base × composant, avec un indicateur vert / rouge issu des scripts de collecte — le tableau de bord qu'un responsable licence ouvre avant chaque renouvellement.
Un deuxième exemple : une synthèse de Séparation des tâches par utilisateur, conflits classés par sévérité et conflits prouvés repérés.
La carte de l'application
La barre latérale découpe le travail quotidien en cinq sections plus la zone de configuration.
| Section | Ce qu'elle couvre |
|---|---|
| Vue d'ensemble | Le tableau de bord — conflits ouverts, affectations qui expirent, écart de licence, statut du dernier rafraîchissement. |
| Sécurité | Utilisateurs, rôles, affectations, matrice des rôles (combinaisons), utilisateurs en doublon, utilisateurs sans rôle, réconciliation LDAP / AD. |
| Applications | Par application connectée : menus, droits (par utilisateur, par rôle, combinés), Object Usage Tracking (composants, objets, détails), conflits (synthèse, par utilisateur, par rôle, par objet), journal d'activité. |
| Base de données | Propriétés Oracle (édition, packs, options, partitions), Audit Trail (changements issus des archive logs Oracle), Audit Lookup (avant / après ligne à ligne). |
| Licences | Contrats CSI, photographie JD Edwards, licences Oracle requises, licences acquises, rapport d'utilisation, rapport financier. |
| Paramètres | Définitions des sources (applications, schémas JDE, catalogues Oracle), mappage des départements LDAP, configuration SoD (processus, activités, risques, objets, matrice), catalogue de prix, sécurité et indicateurs AD. |
Qui s'en sert
| Rôle | Pourquoi on ouvre Nomasx-1 |
|---|---|
| Auditeur interne | La revue SoD trimestrielle — conflits ouverts, validations d'exceptions, tendance dans le temps. |
| Responsable sécurité | Le « qui a accès à X » du quotidien — catalogue utilisateurs et rôles, avec comptes dormants et affectations expirées repérés. |
| Administrateur sécurité JDE | Catalogue inter-environnements des utilisateurs et rôles, plus simple que le security workbench JDE, avec édition en masse dans Nomajde quand des changements sont nécessaires. |
| Responsable licences | Réconciliation requis-vs-acquis, preuves issues d'Object Usage Tracking, rapport d'écart financier avant chaque renouvellement. |
| CISO / Risque | Le tableau de bord de conformité — posture SoD, indicateurs d'hygiène des comptes, exposition de licence. |
| DBA | La photographie Oracle — options, fonctionnalités, partitions — sans écrire une seule requête. |
Les rôles dans Nomasx-1
L'application embarque quatre rôles. Ils contrôlent ce que chaque utilisateur voit et peut modifier.
| Rôle | Ce qu'il accorde |
|---|---|
| Viewer | Lit chaque écran, exécute les rapports, aucune modification. |
| Editor | Tout ce que fait un Viewer, plus la mise à jour des matrices SoD, la planification des scans, la gestion des notifications. |
| Auditor | Tout ce que fait un Viewer, plus la validation des exceptions. Seul rôle habilité à clôturer un conflit signalé. |
| Administrator | Tout ce qui précède, plus la gestion de la configuration des sources (datasources ERP, comptes Oracle, mappage LDAP / AD). |
Un déploiement typique sépare Auditor d'Administrator — le principe que Nomasx-1 fait respecter ailleurs : la personne qui configure l'analyse ne doit pas être celle qui en valide les constats.