Journal d'audit
Deux traces écrites une seule fois des actions qui touchent à la confiance - rôles, membres et jetons dans un espace, sièges, propriété et authentification unique dans l'organisation - chacune conservée 90 jours. Les modifications de contenu ne figurent volontairement dans aucune des deux.
Chaque espace de travail conserve une trace des actions qui changent qui peut faire quoi. Elle est écrite une fois, jamais modifiée, et élaguée après 90 jours.
Ce qui est enregistré
- Rôles - créés, modifiés, supprimés. Une modification porte un diff : quelles permissions ont été ajoutées, lesquelles retirées, et si le nom, la description, la couleur ou l'indicateur par défaut ont changé.
- Personnes - ajoutées, avec le rôle qu'elles ont reçu, retirées, rôle changé, statut changé, et droits limités à certaines pages accordés ou révoqués. Quand quelqu'un quitte un espace de lui-même, c'est enregistré comme un retrait, cette personne étant son propre auteur.
- Jetons - créés et révoqués, y compris les jetons d'asset qui signent les médias privés.
- L'espace de travail - réglages modifiés et secret de brouillon régénéré.
- Points de terminaison webhook - créés, modifiés, supprimés, secret rotationné, et une livraison stockée renvoyée. Une modification porte l'endroit où l'URL pointait avant, quels événements ont été ajoutés ou retirés, et si le point a été désactivé. Une rotation porte la fenêtre de grâce pendant laquelle l'ancien secret signe encore : sans grâce, toute livraison échoue jusqu'au redéploiement du consommateur. Un point de terminaison que le worker de livraison désactive après vingt livraisons échouées consécutives est enregistré aussi, comme sa propre action avec le compteur d'échecs - jamais comme la modification de quelqu'un.
- Publication d'une page - publiée, dépubliée, un brouillon abandonné, une mise en page publiée, un brouillon de mise en page abandonné, un brouillon de développement promu, et un changement d'étape éditoriale. La publication est le moment où une modification devient visible du public : elle appartient donc ici, même si la modification qui l'a produite n'y appartient pas. Une publication de mise en page est une action à part : elle change ce que la page affiche sans la rendre publique.
- Suppressions - une page, et combien de pages enfants sont parties avec elle ; un verrou de page repris à celui qui le détenait ; un modèle, et combien d'enregistrements sont partis avec lui ; un enregistrement seul ; une suppression groupée de produits, avec le nombre et si la sélection s'est faite par identifiants ou par un filtre ; un formulaire, et combien de soumissions sont parties avec lui ; et une soumission seule. Une entrée de soumission nomme le formulaire, son statut et le moment où elle est arrivée - jamais ce que le visiteur a saisi. Le journal d'audit se lit avec une permission différente de celle des soumissions elles-mêmes : y répéter les réponses les livrerait à quelqu'un qui ne peut pas ouvrir la boîte de réception.
Chaque entrée nomme l'objet, le moment et qui a agi - une personne, ou la plateforme elle-même quand elle a agi seule, par exemple un point de terminaison webhook désactivé par des échecs répétés.
Chaque entrée dit d'où vient l'écriture. Une modification faite dans l'administration ne porte aucune origine. Une modification faite par l'assistant IA est marquée comme telle et nomme l'outil utilisé ; une modification passée par le serveur MCP est marquée comme cette surface. L'action est la même dans les deux cas - une publication par l'assistant est la même entrée publiée qu'écrit une personne - donc la trace se lit comme une seule histoire, puis se restreint aux écritures machine quand c'est la question. L'auteur reste la personne dont le jeton a exécuté la modification : l'assistant agit pour le compte de quelqu'un, jamais pour le sien.
L'organisation tient son propre journal
Une organisation possède le forfait, les sièges et la configuration de l'authentification unique. Ces événements n'appartiennent à aucun espace de travail en particulier : ils sont donc écrits dans une trace distincte, avec son propre droit de lecture. Cette séparation est ce qui garde le journal d'espace honnête : une entrée y nomme toujours un espace, et un événement d'organisation n'en a aucun à nommer.
Enregistré au niveau de l'organisation :
- L'organisation elle-même - créée, renommée, supprimée, réglages modifiés. Un renommage porte si le nom, le slug ou les deux ont bougé ; une modification de réglages porte le nouveau rôle par défaut des membres et si les membres peuvent créer leurs propres espaces.
- La propriété - transférée, en nommant qui l'a cédée et qui l'a reçue.
- Les sièges - quelqu'un invité, avec le rôle d'organisation qui lui a été proposé ; une invitation annulée ; une invitation acceptée ; un membre retiré ; le rôle d'organisation d'un membre changé. Ce sont les entrées sur lesquelles se joue un litige de siège - et le siège est l'unité dans laquelle le forfait se compte.
- Les espaces de travail - déplacés dans l'organisation ou hors d'elle, en nommant les deux côtés du déplacement.
- L'authentification unique - un domaine ajouté, vérifié ou retiré, la connexion configurée, une connexion de test avec son résultat, et l'application obligatoire activée ou désactivée. Elle décide qui peut encore se connecter avec un mot de passe : elle est donc enregistrée comme une action à part, et non comme une modification de réglages de plus.
Le rôle d'organisation - propriétaire, administrateur ou membre - est autre chose que le rôle d'espace qui accorde des permissions à l'intérieur d'un espace. Un changement de l'un n'est jamais enregistré comme un changement de l'autre, et les deux traces ne mélangent pas leurs vocabulaires.
Une action qui n'a rien changé n'écrit rien. Enregistrer le formulaire de réglages sans toucher un champ, ou donner à un membre le rôle qu'il détient déjà, ne laisse aucune entrée : une trace remplie de non-événements, personne ne la lit.
Ce qui n'y est pas, et pourquoi
Les modifications de contenu ne sont pas dans le journal d'audit. Ni enregistrements de page, ni retouches de bloc, ni envois de médias.
La publication et la suppression sont les deux exceptions, et toutes deux figurent dans la liste ci-dessus. La ligne ne passe pas entre « contenu » et « accès », mais entre récupérable et non. Une modification de brouillon est réversible et privée : elle reste dehors. Le moment où le contenu devient public est enregistré, et le moment où il cesse d'exister l'est aussi - une suppression est la seule opération de contenu à laquelle rien d'autre ne peut répondre ensuite, puisque ce dont on voudrait s'informer a disparu.
C'est une limite délibérée, pas un oubli. Ces événements sont très nombreux - un après-midi chargé en produit des centaines - et les mélanger enterrerait les quinze entrées qui comptent sous des milliers qui ne comptent pas. Le journal d'audit répond à « qui a changé les accès » ; pour « qui a changé cette page », l'historique des versions enregistre chaque enregistrement avec son auteur.
La règle derrière cette liste : elle couvre ce qui touche à la confiance, à l'authentification et à la facturation - et ce dont un attaquant voudrait effacer les traces.
Qui peut le lire
Le journal d'espace exige le droit de gérer les rôles. C'est voulu : le journal est surtout un relevé de changements de permissions, donc ceux qui peuvent accorder l'accès voient qui l'a accordé.
Le journal d'organisation exige de gérer l'organisation : en être le propriétaire, ou détenir son rôle d'administrateur. La permission d'espace n'y atteint pas. Quelqu'un qui peut gérer les rôles dans un espace n'a aucun droit sur le relevé de qui a été invité dans l'organisation au-dessus - et détenir cette permission dans chaque espace que l'organisation possède ne l'ouvre toujours pas.
Quatre-vingt-dix jours
Les entrées plus anciennes sont élaguées par une tâche planifiée, qui balaie les deux traces dans le même passage. Si vos obligations de conservation vont au-delà, exportez régulièrement plutôt que de découvrir le trou pendant un audit.
Une entrée survit à son sujet à dessein : la suppression d'une organisation est enregistrée, et cet enregistrement n'est pas supprimé avec elle. Il expire avec le reste une fois les quatre-vingt-dix jours passés.
Étapes suivantes
- Membres et rôles - les permissions dont les changements atterrissent ici.
- Jetons d'API - création et révocation, toutes deux enregistrées.
- Webhooks - les points de terminaison dont les changements atterrissent ici.
- Authentification unique - domaines, configuration et application obligatoire, tout enregistré au niveau de l'organisation.
- Historique des versions - la trace de contenu que ce journal laisse volontairement de côté.