Un journal qu'on peut effacer ne prouve rien

L'un trace les rôles et les permissions : rôle créé, rôle attribué ou retiré, permission accordée ou révoquée, à l'échelle du compte comme de l'espace de travail. L'autre trace les ressources du compte : création et révocation de clés API, configuration de la connexion unique, changements de marque. Ils restent séparés pour ne pas faire dépendre une écriture de l'autre.

• Rôles créés, attribués, retirés
• Permissions accordées et révoquées
• Clés API créées et révoquées
• Connexions réussies et échouées

Le nom de l'acteur est figé au moment du fait, pas relu depuis la fiche actuelle. Si la personne est renommée, anonymisée ou supprimée plus tard, le journal continue de dire qui a agi. C'est une exigence des normes de sécurité, mais c'est surtout la seule façon qu'un journal raconte quelque chose six mois après.

• Identité de l'acteur figée, même après suppression
• Actions du système distinguées de celles d'une personne
• Adresse IP et navigateur, pour reconstituer un incident
• Détail propre à l'événement conservé à côté

Au-delà du flux, on veut souvent répondre à une question précise : qu'a fait cette personne, et que peut-elle faire aujourd'hui ? Les événements se filtrent par acteur et par cible, et les droits réels d'un utilisateur se résolvent à l'écran. Cette consultation est elle-même journalisée — regarder les droits de quelqu'un est une action sensible.

• Filtrage par acteur, par cible et par période
• Droits effectifs d'un utilisateur, résolus
• La consultation des droits est tracée
• Journaux en lecture seule par l'API