# Surveillance de l'activité

Sovrium enregistre chaque action significative dans l'application — création/mise à jour/suppression d'enregistrements, événements d'authentification et opérations administratives — dans un journal d'activité à l'échelle du système. Le journal est interrogeable via une API authentifiée avec filtrage et pagination, offrant aux opérateurs et aux auditeurs un endroit unique pour répondre à « qui a fait quoi, et quand ».

Il s'agit de la surface de lecture destinée à l'opérateur sur le magasin d'événements canonique du journal d'audit de la plateforme. Chaque entrée est immuable et survit aux lignes qu'elle référence lorsque la conformité l'exige (un événement `account.deletion.purged` survit à l'effacement de l'utilisateur qui l'a déclenché — voir [GDPR & Confidentialité](/fr/docs/gdpr-privacy)).

## Ce qui est suivi

| Catégorie                         | Exemples                                                                                                  |
| --------------------------------- | --------------------------------------------------------------------------------------------------------- |
| **CRUD sur enregistrements**      | `create`, `update`, `delete`, `restore` sur tout enregistrement de table.                                 |
| **Événements d'authentification** | Connexion, inscription, réinitialisation de mot de passe, révocation de session.                          |
| **Actions administratives**       | Création d'utilisateur, changements de rôle, bannissements, publications de schéma, suppressions forcées. |
| **Événements système**            | Migrations, planification et purge de suppression de compte.                                              |

Chaque entrée porte l'action, la table et l'identifiant d'enregistrement concernés (le cas échéant), un horodatage et l'utilisateur agissant (id, nom, e-mail). La référence à l'acteur est liée par clé étrangère avec `ON DELETE SET NULL`, de sorte qu'une entrée d'audit reste un enregistrement de conformité valide même après l'effacement du compte de l'acteur.

## Interrogation du journal d'activité

L'API d'activité est protégée par administration. Les requêtes non authentifiées renvoient `401` ; les sessions non administrateur renvoient `403`.

```
GET /api/activity?page=1&pageSize=20&table=orders&action=update
```

```json
{
  "activities": [
    {
      "id": "act_123",
      "action": "update",
      "tableName": "orders",
      "recordId": 456,
      "createdAt": "2025-01-15T10:30:00Z",
      "user": { "id": "1", "name": "Alice", "email": "alice@example.com" }
    }
  ],
  "pagination": { "total": 150, "page": 1, "pageSize": 20, "totalPages": 8 }
}
```

| Point de terminaison            | Description                                        |
| ------------------------------- | -------------------------------------------------- |
| `GET /api/activity`             | Liste paginée et filtrable des entrées d'activité. |
| `GET /api/activity/:activityId` | Détail complet pour une seule entrée d'activité.   |

### Paramètres de requête

| Paramètre  | Type   | Description                                                     |
| ---------- | ------ | --------------------------------------------------------------- |
| `page`     | number | Numéro de page (par défaut : `1`).                              |
| `pageSize` | number | Entrées par page.                                               |
| `table`    | string | Filtre sur une seule table par nom.                             |
| `action`   | string | Filtre par action (`create`, `update`, `delete`, `restore`, …). |

:::callout
**Journal d'activité vs historique d'enregistrement.** Le journal d'activité est un flux inter-tables, à l'échelle du système, répondant à « ce qui s'est passé dans l'application ». Pour l'ensemble de modifications avant/après au niveau du champ d'un seul enregistrement, utilisez l'[Historique des enregistrements](/fr/docs/record-history) — il capture le diff de chaque édition individuelle. Les deux se complètent : l'activité pour la largeur, l'historique pour la profondeur.
:::

## Conservation

Les entrées d'activité sont conservées conformément à la politique de conservation de la plateforme. Les lignes sources supprimées en douceur vieillissent elles-mêmes selon l'horizon `ECO_RETENTION_PURGE_DAYS` (voir [Écoconception](/fr/docs/ecoconception)), mais les entrées d'audit requises pour la conformité — notamment les enregistrements d'effacement — sont préservées indépendamment des lignes qu'elles décrivent.

## Usage de conformité

La même forme renvoyée aux administrateurs est renvoyée aux auditeurs, de sorte que la documentation de revue SOC2 / GDPR reflète exactement ce que voient les opérateurs. Combiné au magasin d'événements canonique immuable, le journal d'activité fournit la « piste d'audit de l'effacement » requise lors de l'honneur d'une demande de [droit à l'oubli](/fr/docs/gdpr-privacy) : la suppression est elle-même consignée, avec la référence à l'acteur null-ifiée une fois le compte purgé.

## Pages connexes

- [Historique des enregistrements](/fr/docs/record-history) — diffs avant/après au niveau du champ par enregistrement.
- [Suppression en douceur](/fr/docs/records-soft-delete) — suppressions récupérables et la pierre tombale `deleted_at`.
- [Tableau de bord d'administration](/fr/docs/admin-dashboard) — API de lecture opérateur sur le reste de la plateforme.
- [GDPR & Confidentialité](/fr/docs/gdpr-privacy) — enregistrements d'effacement et la piste d'audit de la suppression.
- [Gestion des utilisateurs](/fr/docs/user-management) — les actions administratives qui produisent les entrées d'activité.