Les journaux d’audit enregistrent chaque action qui modifie l’état de votre organisation — attributions de rôles, modifications de moteur, émission de clés API, changements de facturation — et les présentent dans une chronologie consultable et filtrable. Disponible avec le forfait Enterprise, aux côtés de Rôles et permissions.
Le journal est en ajout seul au niveau de la base de données : la connexion de l’application ne peut ni mettre à jour, ni supprimer, ni tronquer les lignes d’audit. Ce qui est écrit le reste.
Ce qui est enregistré#
Chaque événement capture l’acteur, l’action, la cible et le contexte HTTP de la requête.
| Champ | Notes |
|---|---|
| Acteur | L’utilisateur ou la clé API à l’origine de l’action |
| Action | Une valeur typée comme engine.created ou member.role_changed |
| Cible | L’entité concernée (par ex. un moteur, un rôle ou un élément de glossaire) |
| Métadonnées | Les ID des entités associées — jamais de noms, d’e-mails ni d’extraits de contenu |
| Contexte de la requête | request_id, adresse IP, agent utilisateur — capturés à l’arrivée de l’appel via HTTP |
| Horodatage | UTC, avec en plus un numéro de séquence monotone pour détecter les écarts |
Uniquement des ID, par conception
La colonne de métadonnées stocke des ID, pas des valeurs lisibles. L’interface rattache les noms actuels à la lecture, donc renommer un moteur ou un utilisateur ne réécrit pas l’historique. Cela évite aussi les conflits avec le droit à l’effacement du RGPD — il n’y a aucun contenu à masquer.
Actions couvertes#
Les événements sont regroupés en catégories qui correspondent au filtre du tableau de bord.
| Catégorie | Actions prises en charge aujourd’hui |
|---|---|
| Organisation | org.created, org.settings_updated, org.ownership_transferred, org.deleted |
| Membres | member.invited, member.removed, member.role_changed |
| Rôles | role.created, role.updated, role.deleted |
| Moteurs | engine.created, engine.updated, <C03></C02> |
| Clés API | api_key.created, api_key.revoked |
| Contenu | glossary_item.*, instruction.*, brand_voice.* (opérations unitaires uniquement) |
Accéder au journal#
L’entrée Journaux d’audit n’apparaît dans la barre latérale Organisation que si cette fonctionnalité est activée pour votre organisation. Vous y trouverez :
- Liste filtrable — affinez par acteur, catégorie d’action, type de cible et plage de dates. Les dates futures sont bloquées et la borne supérieure est toujours ≥ à la borne inférieure.
- Défilement infini — les événements les plus récents s’affichent en premier ; les plus anciens se chargent à mesure que vous faites défiler.
- Panneau de détails — cliquez sur n’importe quelle ligne pour afficher l’ensemble des métadonnées, l’ID de requête, l’IP et l’agent utilisateur.
- Actualiser — récupère les derniers événements sans perdre votre sélection de filtres. Les filtres et l’événement ouvert sont reflétés dans l’URL, donc chaque vue est partageable.
Qui peut y accéder#
L’accès à la page est contrôlé par deux conditions :
- Droit — la fonctionnalité audit-logs doit être activée pour l’organisation (forfait Enterprise).
- Permission — le rôle de l’utilisateur doit inclure
org:view_audit_logs. Le rôle Accès complet fourni par défaut l’inclut ; les propriétaires l’ont toujours.
Les membres sans cette permission voient une page « accès refusé » au lieu de la chronologie. Les membres d’une organisation sans ce droit voient un paywall.
Si votre forfait Enterprise expire
Les journaux d’audit font partie du même niveau de droits RBAC. Les événements passés restent dans la base de données, mais la page est masquée et les endpoints de lecture renvoient 403 jusqu’à la réactivation du forfait.
Protection contre les altérations#
Les journaux d’audit ne sont pas qu’un simple historique — ils sont concrètement difficiles à modifier a posteriori.
- Ajout seul au niveau de la base de données. La migration qui installe la table exécute
REVOKE UPDATE, DELETE, TRUNCATEsur le rôle API. Tout futur chemin de code — bug, nouvel endpoint, même injection SQL — est rejeté par Postgres avant de pouvoir modifier une ligne. - Séquence monotone. Chaque ligne comporte une colonne
seqstrictement croissante. Un auditeur qui parcourt la séquence peut repérer les suppressions sous forme de trous.
C’est suffisant pour des contrôles de type SOC 2. En revanche, cela ne protège pas contre un attaquant disposant d’identifiants directs sur la base de données de production — des niveaux de protection plus élevés (rôle propriétaire séparé, miroir WORM) sont disponibles sur demande.
Conservation#
Les événements d’audit sont conservés indéfiniment par défaut. Des durées de conservation personnalisées — généralement 1, 3 ou 7 ans — sont disponibles avec Enterprise. Contactez-nous si vous avez besoin d’une politique de conservation spécifique pour la conformité ou des questionnaires de sécurité.
Ce qui n’est pas couvert#
Quelques limites délibérées de la v1 à connaître :
- Émission en best effort, non transactionnelle. L’émission transactionnelle fait partie de la feuille de route à court terme. L’événement d’audit est écrit après l’action qu’il décrit — pas dans la même transaction de base de données. Dans de rares cas de défaillance (une action réussit, puis l’insertion de l’audit échoue), l’action peut avoir lieu sans événement correspondant.
- Certains types d’actions ne sont pas encore pris en charge. Les changements d’appartenance à un moteur, la connexion / mise à jour / déconnexion d’intégrations, les modifications de configuration de modèle, les changements d’abonnement de facturation et les opérations de contenu en masse (import CSV,
createMany/updateMany/deleteMany) ne produisent pas encore d’événements. Le vocabulaire d’action est déjà réservé afin qu’ils apparaissent dans les catégories de filtre existantes une fois pris en charge. - Les lectures ne sont pas auditées. Consulter le journal d’audit lui-même, parcourir les logs de requêtes du moteur ou télécharger un glossaire ne produit pas d’événements. Seules les actions qui modifient l’état le font.
- Pas encore d’exports. Les données d’audit sont accessibles via le tableau de bord. L’export CSV, le webhook SIEM et le miroir S3 font partie de la feuille de route — dites-nous si vous en avez besoin.
- Pas de vue par moteur. Tous les événements d’audit de l’organisation apparaissent dans une seule chronologie. Filtrez par type de cible ou par ID de cible pour affiner.
- Pas de flux en direct. La liste se met à jour à la demande ou lorsque vous cliquez sur Actualiser — il n’y a pas de flux WebSocket.
