Documentation — Audit / Log

Journal d'audit (qui, quand, quoi) : modèle d'événement, politique de rétention, garanties d'intégrité et points d'intégration.

Modèle d'événement

Un événement d'audit est un enregistrement immuable : il répond à « qui » (acteur, acteurId, ip), « quand » (timestamp ISO 8601, posé côté serveur) et « quoi » (action, entite, detail avec l'avant/après lisible). La source distingue l'interface web, l'API et les tâches planifiées.

{
  "id": "EVT-1032",
  "timestamp": "2026-06-12T17:40:00",       // ISO 8601, jamais modifié
  "acteur": "Alice Martin",
  "acteurId": "a.martin",                   // identifiant stable (humain, service, système)
  "action": "modification",                 // creation | modification | suppression | connexion
  "entite": "Devis DV-2026-104",
  "detail": "statut : brouillon → validé",  // avant → après, lisible par un humain
  "ip": "10.20.4.18",
  "source": "Interface web"                 // Interface web | API | Tâche planifiée
}

Rétention

  • Journal chaud — 90 jours en base, interrogeable depuis l'interface (le simulateur montre une fenêtre de 10 jours).
  • Archive froide — export mensuel compressé vers un stockage objet, conservé 6 ans (exigence courante pour les pièces comptables et contractuelles).
  • Purge — la purge elle-même est journalisée (événement suppression émis par l'acteur Système), jamais silencieuse.

Conformité et intégrité

  • Append-only — la table audit_events n'autorise ni UPDATE ni DELETE applicatifs ; on corrige en ajoutant un événement, jamais en réécrivant l'historique.
  • Chaînage — chaque ligne peut embarquer le hachage SHA-256 de la précédente : toute altération a posteriori casse la chaîne et se détecte.
  • Horodatage de confiance — timestamps posés côté serveur, jamais par le client ; horloge synchronisée (NTP).
  • Données personnelles — le detail décrit le changement sans recopier de données sensibles (RGPD : minimisation) ; les adresses IP suivent la même politique de rétention que le journal.

Intégration en production

Le simulateur fonctionne en local (32 événements seedés, filtres et pagination côté client). Pour brancher un vrai backend : émettre un événement depuis un middleware à chaque mutation (création, modification, suppression) et à chaque authentification ; exposer une API de lecture paginée acceptant les mêmes paramètres que les filtres du simulateur (q, acteur, action, depuis) ; servir l'export CSV côté serveur au-delà de quelques milliers de lignes. La recherche plein texte gagne à être indexée (index trigram ou moteur dédié).

Ouvrir le simulateur