Le journal d'audit est l'historique complet des changements au sein de votre organisation. Chaque action significative (création, modification, suppression, déplacement, changement de paramètre, opération de facturation, changement de droit) est enregistrée sous forme d'entrée distincte avec l'auteur, l'heure et le contexte.

Pourquoi vous en avez besoin :

  • Enquête — « qui a supprimé cet article ? », « qui a changé le rôle de quelqu'un la semaine dernière ? »
  • Conformité — SOC 2, ISO 27001, GDPR exigent une piste d'audit pour les changements de données et de consentements
  • Annuler des changements — comprendre ce qui existait avant un changement et prendre une décision
  • Contrôle de l'activité de l'équipe — qui fait quoi, en particulier dans les organisations Enterprise avec une grande équipe

#Où l'ouvrir

Menu de gauche → Journal d'audit.

Accessible aux rôles Owner et Admin de l'organisation sur les forfaits Team, Pro, Business et Enterprise (indicateur de forfait allows_audit_logs). Sur Free et Starter, l'élément de menu s'affiche pour l'Owner et l'Admin avec un cadenas et « Offre … requise » (pour l'Owner, il mène à « Offre et limites ») ; les autres ne le voient pas.

Editor et User ne voient pas le journal par défaut : le droit « Journal d’audit » peut leur être accordé dans Paramètres → Gestion des droits — l'élément apparaît alors aussi pour eux. Guest ne voit jamais le journal.

Les entrées liées à l'argent et au forfait (type de ressource billing) ne sont visibles que par le Owner : le rôle Admin n'a pas accès aux paiements, et le journal ne doit pas servir de contournement.

#À quoi ressemble une entrée

Chaque ligne du journal est une carte comportant l'auteur, l'action, la ressource, l'heure et une courte description :

AP
Anna P. [email protected] deleted article
« Comment configurer le SSO dans Google Workspace »
Article supprimé de la collection « Instructions IT » (espace « Base de connaissances corporate »)
19.05.2026, 14:32:18 Détails →

Champs d'une entrée :

Champ Description
Auteur nom + email de l'utilisateur ayant effectué l'action
Action (action) ce qui s'est passé : created, updated, deleted, restored, moved, published, etc.
Type de ressource (resource_type) l'objet sur lequel l'action a été effectuée : article, collection, user, consent, billing, tenant
Titre de la ressource le nom de l'article, de la collection, de l'utilisateur — ce que vous voyez dans l'interface habituelle
Résumé (summary) explication lisible de l'action
Détails (details) JSON contenant des données supplémentaires : ce qui a exactement changé, ancienne/nouvelle valeur, adresse IP, clé d'idempotence — se déploie en cliquant sur « Détails »
Heure horodatage à la seconde près

#Ce qui entre dans le journal

Le journal enregistre les opérations clés sur le contenu, les membres, les consentements et la facturation. Ci-dessous, les types de ressources et actions réels.

#Articles (resource_type=article)

Action Quand elle se déclenche
created création d'un nouvel article
updated enregistrement de modifications (y compris un changement de visibilité — details indique quels champs ont changé)
trashed déplacement d'un article vers la corbeille
restored restauration depuis la corbeille
article_moved déplacement d'un article
article_copied copie d'un article
permanently_deleted suppression définitive depuis la corbeille ou après expiration de la conservation

#Collections et espaces (resource_type=collection)

Les espaces sont stockés comme des collections de premier niveau, ils sont donc journalisés sous le même type de ressource.

Action Quand
created création d'une collection ou d'un espace
collection_moved déplacement d'une collection (changement de son parent)
collection_copied_recursive copie d'une collection avec son contenu
collection_bulk_move_articles déplacement en masse d'articles entre collections
trashed déplacement vers la corbeille
restored restauration depuis la corbeille
permanently_deleted suppression définitive

#Équipe (resource_type=user)

Action Quand
invited invitation dans l'organisation
role_changed changement du rôle d'un membre dans l'organisation
deleted retrait d'un membre de l'organisation

#Consentements GDPR (resource_type=consent)

Action Quand
updated un utilisateur a modifié son consentement cookies (scope: all / essential)

Ces entrées apparaissent automatiquement lorsque la bannière de cookies est modifiée. Voir l'article sur l'inscription et l'onboarding pour le contexte du consentement GDPR.

#Facturation et organisation

Action Ressource Quand
subscription_paid billing paiement de l'abonnement (premier paiement et renouvellement)
plan_upgraded billing passage à un plan supérieur
plan_downgrade_scheduled billing rétrogradation ou résiliation d'abonnement planifiée
plan_changed_by_provider billing changement de plan suite à un événement du prestataire de paiement
scheduled_change_cancelled billing annulation d'une modification planifiée
subscription_cancelled / subscription_cancel_failed billing résiliation de l'abonnement / tentative échouée
reactivated billing abonnement repris
seats_changed billing modification du nombre de sièges
refund_issued billing remboursement
topup_checkout_started / topup_granted billing début de l'achat d'un pack / pack crédité
billing_address_updated billing adresse de facturation modifiée
plan_granted / plan_grant_revoked, limit_override_granted / limit_override_revoked, addon_granted_by_operator billing modifications effectuées par un collaborateur de Lynkora
trash_emptied tenant vidage complet de la corbeille de l'organisation

#Filtres

En haut de la page se trouve un panneau de filtres pour retrouver rapidement l'événement recherché :

Rechercher par description ou titre… Action ▾ Ressource : article ✕ Utilisateur ▾ Période Trouvés : 247 événements
  • Recherche — par texte dans summary ou resource_title (insensible à la casse)
  • Action — liste déroulante avec tous les types d'actions présents dans le journal de l'organisation
  • Ressource — liste déroulante avec les types réellement présents dans le journal (article / collection / user / consent / billing / tenant)
  • Utilisateur — filtrer par l'auteur de l'action
  • Période — une plage de dates « de » et « à »
  • Pagination — jusqu'à 200 entrées par page

Les filtres peuvent être combinés : par exemple, « toutes les actions deleted par l'utilisateur Anna au cours de la semaine passée ».

#Détails d'une entrée

Cliquer sur une carte ouvre le JSON déployé dans le champ « Détails » — c'est le contenu de la colonne details dans la base de données. Ce que vous pouvez généralement y voir :

  • Pour updated — la liste des champs modifiés (fields)
  • Pour role_changed — l'ancien et le nouveau rôle
  • Pour consent updated — le scope (all / essential)
  • Pour les opérations de facturation — un court summary de ce qui s'est passé

Astuce. Si vous devez comprendre ce qui a exactement changé dans un article, regardez le champ fields_changed dans details. Le contenu complet de l'article n'est pas stocké dans le journal (cela serait coûteux en espace) — pour le versionnage, utilisez l'historique des versions de l'article dans l'éditeur.

#Conservation et conformité

  • Les entrées du journal ne peuvent pas être supprimées via l'interface — c'est une limitation délibérée (sinon la piste d'audit perd son sens)
  • Les entrées très anciennes sont périodiquement supprimées par une tâche automatique selon la politique de conservation d'audit — le journal n'est pas conservé indéfiniment
  • Lorsque l'organisation elle-même est supprimée, le journal est supprimé avec elle (via ON DELETE CASCADE)

#Ce qui n'entre pas dans le journal

Pour éviter de gonfler les logs et de transformer le journal en bruit, les éléments suivants ne sont pas journalisés :

  • Les requêtes de recherche des utilisateurs — pour l'analytique, utilisez la section Analytique
  • Les consultations d'articles — également Analytique
  • Les opérations IA à l'intérieur de l'éditeur (AI Improve, AI Rewrite) — c'est le workflow de l'auteur, pas un changement auditable
  • Les événements techniques (tâches en arrière-plan, exécutions de synchronisation) — ils figurent dans les logs système du backend, pour les admins de la plateforme
  • Les actions des utilisateurs système (par exemple, platform-help-system lors de l'amorçage de la documentation) — filtrées

#Sections associées

  • Corbeille — les événements trashed / restored / permanently_deleted pour les articles, collections et espaces sont journalisés précisément ici
  • Gestion de l'équipe — les changements de rôle et les retraits de membres sont enregistrés dans le journal avec resource_type=user
  • Analytique — pour les métriques d'usage (requêtes, consultations) — c'est un outil distinct, pas le journal