# ADR-021 : Journal d'activité de l'entreprise sans les actions de la plateforme

**Statut :** Accepté
**Date :** 2026-10-27
**Contexte :** Journal d'activité du tenant (`company_activity_logs`, `TenantActivityLogService`, écran Rapports > Journal d'activité) et journal de la plateforme (`superadmin_activity_logs`, `ActivityLogService`)

---

## Contexte

Deux journaux coexistent :

- celui de l'**entreprise**, que consulte son administrateur : ventes, achats, produits, utilisateurs ;
- celui de la **plateforme**, réservé au superadmin, propriétaire du SaaS : entreprises, formules, paiements, démos.

Le journal de l'entreprise est alimenté par des observateurs de modèles (`OrderActivityObserver`, `UserActivityObserver`, etc.), quel que soit l'auteur de l'action. Quand le superadmin agit dans le contexte d'une entreprise (création de son administrateur, intervention de support), son action apparaît dans le journal de cette entreprise, sous son nom. Le client voit alors l'activité du fournisseur dans son propre journal. C'est une fuite d'information sur l'exploitation de la plateforme, et une source de confusion (« qui est ce Super Admin ? »).

Il faut pourtant garder la trace : une action privilégiée sur les données d'un client doit rester traçable (ISO 27001, A.8.15 journalisation).

## Décision

1. **À l'écriture** : `TenantActivityLogService::log` détecte un auteur superadmin et écrit l'entrée dans le **journal de la plateforme** (`ActivityLogService::log`), avec l'entreprise concernée (identifiant et nom) et la même action, description, charge utile et sujet. Rien n'est écrit dans le journal de l'entreprise.
2. **À la lecture** : le journal de l'entreprise (liste et filtre des actions) passe par le scope `CompanyActivityLog::visibleToCompany`, qui écarte les entrées dont l'auteur est superadmin. Les entrées enregistrées avant cette règle disparaissent ainsi de l'écran sans être supprimées.
3. Les entrées « System » (sans auteur : tâches planifiées, traitements de fond) restent dans le journal de l'entreprise : elles concernent ses données.

## Alternatives Considérées

### Ne rien journaliser pour le superadmin
Le journal de l'entreprise serait propre, mais l'action privilégiée ne laisserait aucune trace. Rejeté : une intervention du fournisseur sur les données d'un client doit rester auditable.

### Garder l'écriture et filtrer seulement à l'affichage
Le plus simple. Rejeté seul : les actions de la plateforme resteraient rangées chez le client, à portée d'un export ou d'une future API du tenant. Le filtre à la lecture est gardé, mais seulement pour l'historique.

### Déplacer l'historique vers le journal de la plateforme
Rejeté pour l'instant : aucune entrée de ce type en production ni sur staging (une seule en local). Le filtre à la lecture suffit, sans migration de données.

## Conséquences

- Le journal de la plateforme reçoit des actions de tenant (`user.created`, `sale.created`…) avec l'entreprise concernée. Son écran affiche le code de l'action quand il ne lui connaît pas de libellé.
- La lecture du journal de l'entreprise ajoute une sous-requête sur les superadmins (quelques lignes, colonne `is_superadmin`).
- Toute nouvelle écriture dans le journal d'entreprise doit passer par `TenantActivityLogService`, et toute nouvelle lecture par `visibleToCompany`.

## Quand Réviser

- Si le client doit pouvoir voir qu'une intervention du support a eu lieu (transparence contractuelle) : entrée neutre « Intervention du support Welely » dans son journal, sans le détail.
- Si un rôle « support » distinct du superadmin est créé : l'inclure dans la même règle.