Audit trail: qui a fait quoi, quand, et pourquoi croire la réponse
Comment les event logs append-only, mutation records protégés par RLS et activity log forment une preuve acceptée par l’auditeur.
Une audit trail modifiable n’est pas une audit trail. C’est un document de travail. L’infrastructure d’audit de la plateforme est conçue pour que la trail ne puisse pas être réécrite en silence — et pour que l’équipe opérations puisse le prouver.
Tables d’événements append-only
Plusieurs tables sont conçues en append-only : escrow_events, audit_events, settlement_events, et quelques autres. Des triggers database refusent UPDATE et DELETE sur ces tables. De nouvelles lignes peuvent être insérées (un événement de correction avec référence à l’original), mais les originaux restent. Chaque événement porte un timestamp, l’acteur (user_id) et le contexte pertinent.
Activity log
La page /admin/activity est la vue événementielle à l’échelle de la plateforme. Elle expose les actions utilisateurs à travers les modules : modifications de sociétés, résiliations de contrats, changements de rôles, mises à jour de settings. Filtrable par utilisateur, type d’action et période. Utilisée pour la question “qui a changé ça mardi à 16 h ?” qui revient dans les revues d’incident.
Protection RLS
La Row-Level Security sur les tables d’événements garantit que même une lecture au niveau SQL ne sort pas des limites du tenant — un tenant ne voit que ses propres lignes d’audit. Les platform admins (vérifiés via getAdminScope() avec le niveau plateforme) peuvent lire entre tenants pour des requêtes cross-tenant, mais cet accès est lui-même journalisé.
Historique par entité
La plupart des entités exposent leur propre historique sur la page détail : une company montre les changements de champs principaux, un asset montre les transitions de statut et changements de grade, un contrat montre les amendments. La vue history est la tranche par entité de l’audit trail, formatée pour une lecture humaine plutôt que machine.
Ce que vérifie l’auditeur
L’audit trail prouve : l’intégrité (les enregistrements n’ont pas été édités), l’auteur (l’utilisateur nommé a réellement fait l’action, avec login vérifié), la chronologie (les timestamps sont côté serveur, pas fournis par le client) et l’exhaustivité (l’événement de l’action existe, au bon endroit). Quand les quatre tiennent, l’audit passe au sujet suivant.