Aller au contenu

Opérateurs & audit

À quoi ça sert

Ce module regroupe deux écrans complémentaires : la liste des comptes opérateurs de la plateforme (les personnes internes Jigi qui utilisent admin-jigi) et le journal d'audit qui trace toutes les actions sensibles réalisées par ces opérateurs, à des fins de conformité et d'investigation en cas d'incident.

Prérequis

Prérequis

  • Modules sous licence : PLATFORM (espace opérateur Jigi)
  • Permissions : platform.tenants.read, platform.tenants.manage, audit.read
  • Rôles : JIGI_OPERATOR, JIGI_ADMIN

Comment ça marche

Consulter la liste des opérateurs

  1. Ouvrir Opérateurs (/admin-jigi/operators).
  2. L'écran affiche la liste paginée des comptes opérateurs existants (JIGI_OPERATOR et JIGI_ADMIN), avec leurs informations de base.
  3. Cet écran est en lecture seule : il n'y a aujourd'hui aucun bouton pour créer, désactiver ou réinitialiser le mot de passe d'un opérateur depuis l'interface. Ces actions existent côté serveur (voir Détails techniques) mais ne sont pour l'instant accessibles que par appel API direct — pas via admin-jigi.

Gestion des opérateurs non exposée dans l'UI

Si vous devez créer un nouvel opérateur, désactiver un compte qui quitte l'équipe, ou réinitialiser un mot de passe, il n'existe pas encore de bouton dans /admin-jigi/operators pour le faire. Cette action doit être réalisée via un appel direct à l'API backend (POST/DELETE /admin-jigi/operators/...), typiquement par une personne technique de l'équipe.

Consulter le journal d'audit

  1. Ouvrir Monitoring → Journal d'audit (/admin-jigi/audit).
  2. Le tableau liste les entrées d'audit avec une pagination simple précédent/suivant.
  3. Chaque entrée trace : l'opérateur à l'origine de l'action (operatorId), le type d'action réalisée (par exemple LICENSE_SUSPENDED, LICENSE_REVOKED), le type et l'identifiant de l'objet ciblé (targetType/targetId), un contenu détaillé libre (payload), l'adresse IP de l'opérateur et la date/heure.
  4. Il est possible de consulter l'historique d'audit filtré sur un opérateur précis via l'endpoint dédié (voir Détails techniques) pour vérifier ce qu'une personne précise a fait sur une période donnée — utile en cas de doute sur une manipulation ou pour un contrôle de conformité.

À quoi sert concrètement ce journal ?

C'est la première chose à consulter en cas de question du type « qui a suspendu ce tenant/cette licence, et quand ? ». Toutes les actions d'administration sensibles (suspension, réactivation, révocation de licence, décisions sur les paiements, etc.) y laissent une trace horodatée et attribuée à un opérateur nommé.

Qui peut faire quoi

Permission requise Rôles concernés
platform.tenants.read JIGI_OPERATOR, JIGI_ADMIN
platform.tenants.manage JIGI_OPERATOR, JIGI_ADMIN
audit.read JIGI_OPERATOR, JIGI_ADMIN
Action JIGI_OPERATOR JIGI_ADMIN
Lister les opérateurs (platform.tenants.read) ✅ ✅
Créer/désactiver un opérateur, réinitialiser un mot de passe (platform.tenants.manage) ✅ ✅
Consulter le journal d'audit (audit.read) ✅ ✅

audit.read a été ajoutée par la migration V138__operator_catalog_permission.sql et attribuée aux deux rôles ; elle n'existait pas dans la migration fondatrice V121.

Détails techniques

Détails techniques
  • Endpoints opérateurs (OperatorAdminController, base /admin-jigi/operators) :
    • GET racine — platform.tenants.read — liste paginée
    • POST racine — platform.tenants.manage — création (CreateOperatorRequest)
    • DELETE /{operatorId} — platform.tenants.manage — désactivation
    • POST /{operatorId}/reset-password — platform.tenants.manage — réinitialisation (UpdateOperatorRequest)
  • Endpoints audit (OperatorAuditController, base /admin-jigi/audit), tous en audit.read :
    • GET racine — liste paginée de toutes les entrées
    • GET /operator/{operatorId} — entrées filtrées sur un opérateur précis
  • Table : subscription.operator_audit_log (entité OperatorAuditLog : id, operatorId, action, targetType, targetId, payload JSONB, ipAddress, createdAt), créée par V121__jigi_operator_platform.sql. Distincte de subscription.payment_audit_log, spécifique aux paiements.
  • Frontend : frontend/src/app/admin-jigi/operators/page.tsx (lecture seule), frontend/src/app/admin-jigi/audit/page.tsx (table + pagination précédent/suivant).

Cas d'erreur et FAQ

Comment créer un compte pour un nouvel opérateur qui rejoint l'équipe Jigi ? Il n'y a pas encore de formulaire dans l'interface admin-jigi. La création se fait aujourd'hui via un appel direct à POST /admin-jigi/operators, à réaliser par une personne technique de l'équipe.

Un opérateur quitte l'équipe, comment couper son accès ? De la même façon, via DELETE /admin-jigi/operators/{operatorId} — pas encore de bouton dédié dans l'interface.

Comment savoir qui a révoqué la licence d'un client précis ? Consultez /admin-jigi/audit, ou filtrez directement sur l'opérateur suspecté via GET /admin-jigi/audit/operator/{operatorId} si vous connaissez déjà son identifiant.

Le journal d'audit trace-t-il aussi les actions sur les paiements ? Les décisions de paiement (validation, rejet, demande d'information) sont tracées dans une table séparée, subscription.payment_audit_log, et non dans le journal d'audit opérateur général — voir Paiements.

Quelle est la différence entre JIGI_OPERATOR et JIGI_ADMIN pour gérer les opérateurs ? Aucune différence de permission constatée dans les migrations actuelles : les deux rôles possèdent platform.tenants.manage et peuvent donc créer/désactiver des comptes opérateurs via l'API.

Voir aussi