Journaux d’audit
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 Journal d’audit apparaît toujours dans Paramètres, sous Admin. Sans cette autorisation, la page affiche "Le journal d’audit n’est pas disponible avec votre offre" au lieu de la chronologie. Vous y trouverez :
- Liste filtrable — affinez par Action, Acteur et Période (avec un préréglage comme 7 derniers jours ou une plage de dates Du / Au). Les dates futures ne sont pas autorisées.
- Charger les événements plus anciens — les événements les plus récents apparaissent en premier ; cliquez sur Charger les événements plus anciens en bas de la liste pour charger la page suivante.
- Détail de l’événement — cliquez sur n’importe quelle ligne pour la développer sur place et afficher l’ensemble des métadonnées, l’ID de requête, l’adresse IP et l’agent utilisateur.
- Vues partageables — les filtres et l’événement ouvert se reflètent dans l’URL, de sorte que chaque vue peut être partagée.
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 relèvent du même niveau d’autorisation RBAC. Les événements passés restent dans la base de données, mais la page affiche "Le journal d’audit n’est pas disponible avec votre offre" et les points de terminaison de lecture renvoient 403 jusqu’à ce que l’offre soit rétablie.
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.
- Aucune vue limitée à un moteur. Tous les événements d’audit de l’organisation figurent sur une seule chronologie. Filtrez par action ou par acteur pour affiner.
- Pas de suivi en direct. Il n’y a ni bouton Actualiser ni flux WebSocket — rechargez la page pour afficher les événements plus récents.