@nodefony/security 10.0.0-alpha.8 → 10.0.0-beta.1

package/docs/audit.md

@@ -30,8 +30,8 @@ source: "src/packages/@nodefony/security/docs/audit.md"
 > Chaque fois qu'une **décision de sécurité** est prise — un login réussit, un accès est refusé, une
 > clé d'API est révoquée, un jeton volé resurgit — Nodefony écrit une ligne dans un journal
 > **append-only** : qui, quoi, quand, d'où, avec quel verdict. Pas le trafic (ça, c'est le log HTTP) :
-> les **transitions d'état**. Ancré sur `AuditService` (`auditService.ts:48`), le contrat
-> `IAuditEvent` (`IAuditEvent.ts:53`) et les stores de `nodefony/src/audit/`.
+> les **transitions d'état**. Ancré sur `AuditService` (`auditService.ts:51`), le contrat
+> `IAuditEvent` (`IAuditEvent.ts:61`) et les stores de `nodefony/src/audit/`.
 
 📍 [Documentation](../../../../../docs/index.md) › [Sécurité](index.md) › **Journal d'audit**
 
@@ -70,7 +70,7 @@ flowchart LR
   API --> UI["Studio — Journal d'audit"]
 ```
 
-`AuditService.record()` (`auditService.ts:180`) est le point de passage unique : il pose l'identité et
+`AuditService.record()` (`auditService.ts:187`) est le point de passage unique : il pose l'identité et
 l'horodatage, écrit **sans attendre**, et notifie les abonnés live. Tout le reste — stores, pont WS,
 webhooks, console — se branche autour de lui.
 
@@ -123,7 +123,7 @@ requête authentifiée qui passe n'écrit rien. Prouvé par les tests « SUCCÈS
 signal, pas du bruit à filtrer.
 
 **2. L'audit ne peut jamais casser le métier.** `record()` est synchrone, sans `await`, et l'écriture
-part en fire-and-forget avec un `.catch()` qui se contente de logger (`auditService.ts:192`). Un
+part en fire-and-forget avec un `.catch()` qui se contente de logger (`auditService.ts:199`). Un
 store en panne dégrade la traçabilité, il ne renvoie pas 500 à l'utilisateur.
 
 **3. Le store est pluggable, jamais câblé en dur.** Le service résout un **nom** via un registre
@@ -196,7 +196,7 @@ export default ExportController;
 ```
 
 > [!IMPORTANT]
-> `category` est une **union fermée** de sous-systèmes de sécurité (`IAuditEvent.ts:16`) : il n'existe
+> `category` est une **union fermée** de sous-systèmes de sécurité (`IAuditEvent.ts:71`) : il n'existe
 > pas de catégorie « métier ». C'est volontaire — ce journal est celui de la sécurité. Range ton
 > événement dans la catégorie de sécurité qu'il concerne (ici `authz` : un accès privilégié à des
 > données) et laisse `action` porter le vocabulaire métier.
@@ -254,7 +254,7 @@ et ratées, sur une fenêtre précise.
 
 Aucune configuration : les événements d'authentification sont émis par défaut. Il suffit de filtrer.
 Les critères se **combinent en ET** et sont traduits par `parseAuditQuery()`
-(`SecurityAdminApi.ts:191`) :
+(`SecurityAdminApi.ts:184`) :
 
 | Paramètre   | Effet                                           | Exemple                     |
 | ----------- | ----------------------------------------------- | --------------------------- |
@@ -312,12 +312,12 @@ use("@nodefony/security", {
 ```
 
 Ce que ça déclenche : le service arme un `GcScheduler` de purge **toutes les heures**
-(`auditService.ts:152`, intervalle `GC_INTERVAL_MS` — `auditService.ts:31`), avec gigue
+(`auditService.ts:159`, intervalle `GC_INTERVAL_MS` — `auditService.ts:34`), avec gigue
 anti-avalanche en cluster. Chaque
 tour appelle la purge du contrat — `gc()`, voisin de `listPage()` dans le même contrat
-(`IAuditStore.ts:67`) — qui supprime les événements plus vieux que la fenêtre : un `DELETE` par seuil
-côté SQL (`DrizzleAuditStore.ts:231`), un défilement de file tant que l'événement de tête dépasse le
-`threshold` côté mémoire (`MemoryAuditStore.ts:127`).
+(`IAuditStore.ts:59`) — qui supprime les événements plus vieux que la fenêtre : un `DELETE` par seuil
+côté SQL (`DrizzleAuditStore.ts:256`), un défilement de file tant que l'événement de tête dépasse le
+`threshold` côté mémoire (`MemoryAuditStore.ts:133`).
 
 Ce qu'on observe dans les logs : `audit gc — 1284 événement(s) purgé(s)` en niveau DEBUG.
 
@@ -331,8 +331,8 @@ qu'il arrive.
 La base est indisponible pendant trente secondes. Que se passe-t-il ?
 
 Le choix de Nodefony est explicite : **le métier passe avant la trace**. L'écriture part en
-fire-and-forget — `append()` sans `await`, échec absorbé en log ERROR (`auditService.ts:192`) ; côté SQL, si l'ORM n'est
-pas connecté, `append()` est un no-op assumé (`DrizzleAuditStore.ts:131`). Un login n'échoue jamais
+fire-and-forget — `append()` sans `await`, échec absorbé en log ERROR (`auditService.ts:199`) ; côté SQL, si l'ORM n'est
+pas connecté, `append()` est un no-op assumé (`DrizzleAuditStore.ts:152`). Un login n'échoue jamais
 parce que le journal est cassé.
 
 > [!WARNING]
@@ -342,34 +342,39 @@ parce que le journal est cassé.
 > disponibilité — le contrat `IAuditStore` (`IAuditStore.ts:48`) est le point d'extension pour ça.
 
 Deux garde-fous limitent la casse au démarrage : un store **explicitement** configuré mais inconnu
-**avorte le boot en production** (`auditService.ts:109`), et un store `memory` en production déclenche
+**avorte le boot en production** (`auditService.ts:115`), et un store `memory` en production déclenche
 un `WARNING` nommant précisément le risque — volatil, per-pod, rétention réglementaire impossible
-(`auditService.ts:122`).
+(`auditService.ts:128`).
 
 ## 🔐 Le catalogue des événements audités
 
-Deux axes de classement. La **catégorie** est une union **fermée** (`IAuditEvent.ts:16`) : c'est
+Deux axes de classement. La **catégorie** est une union **fermée** (`IAuditEvent.ts:24`) : c'est
 l'axe de filtrage principal de la console. L'**action** est une chaîne **ouverte**
-(`IAuditEvent.ts:66`) : la liste grandit sans jamais casser le contrat.
+(`IAuditEvent.ts:74`) : la liste grandit sans jamais casser le contrat.
 
 ### Vue d'ensemble — choisir son filtre en cinq secondes
 
 <!-- prettier-ignore -->
 | Catégorie | Ce qu'elle trace | Actions réellement émises par le framework |
 | --- | --- | --- |
-| `auth` | authentification, chaîne du firewall | `auth.failure` · `auth.throttled` · `auth.denied` · `login.success` · `login.failure` · `login.throttled` · `login.mfa_required` · `user.totp_disabled` |
-| `authz` | autorisation (voters, `@IsGranted`) | `access.denied` |
+| `auth` | authentification, chaîne du firewall | `auth.failure` · `auth.unverifiable` · `auth.throttled` · `auth.denied` · `login.success` · `login.failure` · `login.throttled` · `login.mfa_required` · `user.totp_disabled` · `user.password_change_self` (par `@nodefony/user`) |
+| `authz` | autorisation (voters, `@IsGranted`), administration des comptes | `access.denied` · `user.created` · `user.updated` · `user.password_changed` · `user.deleted` (ces quatre-là par `@nodefony/user`) |
 | `token` | jetons longue durée et clés d'API | `token.issued` · `token.reuse_detected` · `apikey.created` · `apikey.revoked` |
-| `session` | cycle de vie de session | `logout` |
+| `session` | cycle de vie de session | `logout` · `session.revoked` (révocation depuis l'administration, par `@nodefony/http`) |
 | `webauthn` | passkeys | `user.passkey_revoked` |
 | `ws` | verrou de frame WebSocket | `frame.denied` |
 | `webhook` | webhooks sortants | `webhook.created` · `webhook.updated` · `webhook.deleted` · `webhook.rotated` · `webhook.revealed` · `webhook.disabled` |
 | `oauth` | login social OAuth2 | _catégorie déclarée, aucune action émise aujourd'hui_ |
 | `csrf` | défense CSRF | _catégorie déclarée, aucune action émise aujourd'hui_ |
 | `cors` | politique CORS | _catégorie déclarée, aucune action émise aujourd'hui_ |
-| `config` | mutation de config runtime depuis Studio | _catégorie déclarée, aucune action émise aujourd'hui_ |
+| `config` | mutation de config runtime depuis Studio | `config.update` · `log.debug.set` · `log.debug.clear` (par `@nodefony/framework`) |
 
-Les trois issues possibles (`IAuditEvent.ts:35`) ne sont pas interchangeables : `failure` = **l'acteur
+Toute catégorie émise appartient au type `AuditCategory`, y compris depuis un paquet qui ne peut pas
+l'importer (`@nodefony/user`, `@nodefony/framework`) : `tests/unit/auditCategoryEmitters.test.ts`
+relit les sources de tous les paquets et refuse un littéral hors contrat. Un filtre sur les
+catégories déclarées voit donc tout le journal.
+
+Les trois issues possibles (`IAuditEvent.ts:43`) ne sont pas interchangeables : `failure` = **l'acteur
 a échoué une preuve** (mauvais mot de passe, signature invalide) ; `denied` = **une politique a
 refusé** un acteur pourtant bien formé (Zero Trust, rôle manquant) ; `success` = l'action a abouti.
 Pour un auditeur, la colonne `denied` est celle des tentatives d'accès non autorisé.
@@ -377,19 +382,21 @@ Pour un auditeur, la colonne `denied` est celle des tentatives d'accès non auto
 ### `auth` — la chaîne d'authentification
 
 Quatre sorties d'échec du firewall passent par le même helper `Firewall.#recordAuth()`
-(`firewall.ts:693`), qui enrichit l'événement de la provenance et pose la **zone** en `resource` :
+(`firewall.ts:907`), qui enrichit l'événement de la provenance et pose la **zone** en `resource` :
 
-- `auth.throttled` — backoff NIST déclenché, réponse 429 (`firewall.ts:768`) ;
-- `auth.failure` — un credential a été **présenté** et rejeté (`firewall.ts:794`) ;
+- `auth.throttled` — backoff NIST déclenché, réponse 429 (`firewall.ts:781`) ;
+- `auth.failure` — un credential a été **présenté** et rejeté (`firewall.ts:807`) ;
+- `auth.unverifiable` — le vérificateur de jetons est indisponible : réponse 503, sans défi
+  (`firewall.ts:795`) ;
 - `auth.denied` / `no_credentials` — Zero Trust : rien n'a été présenté sur une zone protégée
-  (`firewall.ts:811`) ;
+  (`firewall.ts:822`) ;
 - `auth.denied` / `unauthenticated` — un jeton non promu hors `anonymous` (`firewall.ts:850`).
 
 Le parcours de login BFF émet en parallèle son propre vocabulaire depuis `AuthFlow` :
 `login.failure` sur identité inconnue (`authFlow.ts:125`) ou mot de passe faux (`authFlow.ts:153`),
 `login.throttled` (`authFlow.ts:139`), `login.mfa_required` quand un second facteur est réclamé
 (`authFlow.ts:175`), et `login.success` après la preuve complète (`authFlow.ts:191`,
-`authFlow.ts:229`).
+`authFlow.ts:232`).
 
 ### `authz` — le refus d'autorisation
 
@@ -399,10 +406,10 @@ Un seul événement, mais c'est le plus parlant : `access.denied`, émis par le
 ### `token` — la vie et la mort des jetons longue durée
 
 - `token.issued` — un couple access/refresh vient d'être émis, donc une surface d'attaque vient
-  d'être créée ; les `scopes` et l'identifiant du jeton partent en `metadata` (`tokenService.ts:312`) ;
+  d'être créée ; les `scopes` et l'identifiant du jeton partent en `metadata` (`tokenService.ts:535`) ;
 - `token.reuse_detected` — **le signal d'attaque le plus fort du journal** : un refresh déjà révoqué
   a été re-présenté, donc quelqu'un détient un jeton volé. Toute la famille est coupée
-  (`tokenService.ts:353`, RFC 9700 §4.14) ;
+  (`tokenService.ts:585`, RFC 9700 §4.14) ;
 - `apikey.created` / `apikey.revoked` — cycle de vie des clés d'API (`apiKeys.ts:153`,
   `apiKeys.ts:212`).
 
@@ -427,18 +434,18 @@ depuis l'utilisateur de la requête — avec repli `"admin"`, jamais une décisi
 
 ## 🧰 Le contrat d'une entrée
 
-Un événement est un objet **sérialisable JSON** (`IAuditEvent.ts:53`). L'émetteur ne fournit qu'un
-brouillon `IAuditEventDraft` (`IAuditEvent.ts:105`) : `id` et `ts` sont posés par le service, ce qui
+Un événement est un objet **sérialisable JSON** (`IAuditEvent.ts:61`). L'émetteur ne fournit qu'un
+brouillon `IAuditEventDraft` (`IAuditEvent.ts:113`) : `id` et `ts` sont posés par le service, ce qui
 garantit un seul appel d'horloge, centralisé hors des points d'émission.
 
 | Champ       | Type                       | Posé par | Rôle                                                         |
 | ----------- | -------------------------- | -------- | ------------------------------------------------------------ |
 | `id`        | `string`                   | service  | unique dans le process ; sert aussi de composante de curseur |
-| `ts`        | `number` (epoch ms)        | service  | horodatage (`auditService.ts:188`)                           |
+| `ts`        | `number` (epoch ms)        | service  | horodatage (`auditService.ts:195`)                           |
 | `category`  | `AuditCategory`            | émetteur | sous-système — union fermée                                  |
 | `action`    | `string`                   | émetteur | le fait, `<sujet>.<verbe>` — chaîne ouverte                  |
 | `outcome`   | `success\|failure\|denied` | émetteur | le verdict                                                   |
-| `actor`     | `string \| null`           | émetteur | libellé d'identité, `null` si anonyme (`IAuditEvent.ts:74`)  |
+| `actor`     | `string \| null`           | émetteur | libellé d'identité, `null` si anonyme (`IAuditEvent.ts:82`)  |
 | `resource`  | `string \| null`           | émetteur | zone, route, canal, attribut — descripteur **léger**         |
 | `reason`    | `string \| null`           | émetteur | motif **machine** filtrable, pas un message traduit          |
 | `ip`        | `string \| null`           | contexte | provenance réseau                                            |
@@ -458,19 +465,19 @@ Quatre mécanismes, tous prouvés par les tests.
 
 **1. Le chemin nominal n'émet rien.** Ce n'est pas une optimisation, c'est le modèle : le firewall
 n'appelle `#recordAuth()` que depuis ses quatre sorties d'échec, jamais depuis le succès
-(`firewall.ts:900`). Le verrou WS ne tire sa closure `onDeny` que sur refus (`firewall.ts:341`).
-Prouvé : « frame AUTORISÉE → onDeny JAMAIS appelé » (`auditEmissionHotPath.test.ts:324`).
+(`firewall.ts:907`). Le verrou WS ne tire sa closure `onDeny` que sur refus (`firewall.ts:358`).
+Prouvé : « frame AUTORISÉE → onDeny JAMAIS appelé » (`auditEmissionHotPath.test.ts:333`).
 
 **2. Audit désactivé = coût nul, pas juste coût faible.** `record()` sort avant toute allocation et
-avant tout appel d'horloge si le service est inactif (`auditService.ts:182`). Aucun objet créé,
+avant tout appel d'horloge si le service est inactif (`auditService.ts:187`). Aucun objet créé,
 aucun appel d'horloge. Prouvé par le banc « audit désactivé → `issueTokens` n'est pas journalisé »
 (`auditEmissionHotPath.test.ts:499`).
 
 **3. L'écriture ne bloque pas.** `append()` part sans `await`, avec un `.catch()` qui logge
-(`auditService.ts:192`). La latence du store n'entre jamais dans la latence de la requête.
+(`auditService.ts:199`). La latence du store n'entre jamais dans la latence de la requête.
 
 **4. Tout ce qui n'est pas utilisé n'est pas alloué.** La liste d'abonnés live reste `null` tant que
-personne n'écoute et **redevient** `null` au dernier désabonnement (`auditService.ts:221`). Le pont
+personne n'écoute et **redevient** `null` au dernier désabonnement (`auditService.ts:228`). Le pont
 WS n'existe qu'entre le premier et le dernier auditeur connecté, et son tampon circulaire n'est
 alloué qu'au premier événement reçu (`auditBridge.ts:62`) ; son minuteur est armé à la demande et
 `unref` (`auditBridge.ts:93`).
@@ -478,13 +485,13 @@ alloué qu'au premier événement reçu (`auditBridge.ts:62`) ; son minuteur est
 Le pont applique en plus un **coalescing borné** : au plus une frame WS toutes les 250 ms
 (`auditBridge.ts:59`), tampon plafonné à 200 événements (`auditBridge.ts:60`). Sous une rafale
 d'échecs de login, le tampon écrase les plus anciens et compte les omis dans `dropped`
-(`auditBridge.ts:84`) — la console affiche un récapitulatif au lieu de se figer. Superviser ne doit
+(`auditBridge.ts:86`) — la console affiche un récapitulatif au lieu de se figer. Superviser ne doit
 jamais faire tomber ce qu'on supervise.
 
 ## ⚙️ Configuration
 
-Table dérivée du schéma Zod `auditSchema` (`config.ts:877`), rattaché à la racine sous la clé `audit`
-(`config.ts:1152`).
+Table dérivée du schéma Zod `auditSchema` (`config.ts:883`), rattaché à la racine sous la clé `audit`
+(`config.ts:1158`).
 
 | Option          | Type      | Défaut   | Effet                                                                                |
 | --------------- | --------- | -------- | ------------------------------------------------------------------------------------ |
@@ -498,18 +505,18 @@ Table dérivée du schéma Zod `auditSchema` (`config.ts:877`), rattaché à la
 > `immutable` et `stream` sont déclarés dans le schéma mais **ne sont lus par aucun code** aujourd'hui.
 > Les mettre à `false` ne change rien. L'immuabilité vient du **contrat** `IAuditStore`, qui n'expose
 > ni `update` ni `delete` ciblé (`IAuditStore.ts:48`) ; la diffusion live est gouvernée par la
-> **présence d'abonnés** — la liste `#listeners` du service (`auditService.ts:194`).
+> **présence d'abonnés** — la liste `#listeners` du service (`auditService.ts:55`).
 
 ### Comment `store: "auto"` décide
 
 Le défaut ne suppose rien : il **suit l'infrastructure déclarée**, borné aux backends réellement
-enregistrés (`auditService.ts:92`, logique `resolveAutoStore()` dans `infra.ts:289`).
+enregistrés (`auditService.ts:96`, logique `resolveAutoStore()` dans `infra.ts:289`).
 
 1. `NF_STORE` posée et le backend est enregistré pour l'audit → il gagne (levier de banc de charge) ;
 2. sinon, une base est déclarée (`NF_DATABASE_URL`) → `drizzle`, ou `mongoose` selon la famille ;
 3. sinon, repli **annoncé** sur `memory` — la décision est loggée en INFO, jamais silencieuse.
 
-La résolution finale est publiée au kernel (`auditService.ts:139`), ce qui alimente l'écran des stores
+La résolution finale est publiée au kernel (`auditService.ts:145`), ce qui alimente l'écran des stores
 de Studio : configuré, résolu, disponible, motif, emplacement physique.
 
 ## 🏗️ Architecture interne
@@ -536,14 +543,14 @@ Quatre pièces, quatre responsabilités :
 - **`recordAudit()`** (`recordAudit.ts:15`) — le point d'émission côté appelant. Une résolution par le
   container, sur le cold-path uniquement. C'est ce qui rend l'audit **découplé** : module absent →
   aucun effet, jamais d'exception qui remonterait dans le flux métier.
-- **`AuditService`** (`auditService.ts:48`) — le propriétaire. Il construit le store au boot, le pose
-  au container sous le nom `auditStore` (`auditService.ts:138`), arme la purge, et implémente
+- **`AuditService`** (`auditService.ts:51`) — le propriétaire. Il construit le store au boot, le pose
+  au container sous le nom `auditStore` (`auditService.ts:144`), arme la purge, et implémente
   `IAuditSink` (`IAuditStore.ts:77`).
 - **`IAuditStore`** (`IAuditStore.ts:48`) — le contrat de persistance : `append`, `listPage`, `gc`.
   **`append` est la seule écriture** : ni `update`, ni `delete` ciblé. L'immuabilité EST la garantie
   d'audit.
 - **`createAuditBridge()`** (`auditBridge.ts:53`) — le pont vers le canal WS `nodefony:audit`
-  (`auditBridge.ts:8`), enregistré comme canal **système** par le firewall (`firewall.ts:322`) et donc
+  (`auditBridge.ts:8`), enregistré comme canal **système** par le firewall (`firewall.ts:387`) et donc
   gardé par le plancher `security:` → `ROLE_NODEFONY_ADMIN` (`frameAuthorizer.ts:106`).
 
 ### La lecture paginée — pourquoi un curseur et pas un décalage
@@ -565,30 +572,28 @@ tiennent identiquement :
 
 Le `total` est **refusable** (`withTotal: false`) : un `COUNT` filtré sur une rétention longue se
 paie (`IAuditStore.ts:59`). `hasNext` et `nextCursor` restent fiables dans les deux cas, grâce à une
-ligne de garde `limit + 1` (`DrizzleAuditStore.ts:198`).
+ligne de garde `limit + 1` (`DrizzleAuditStore.ts:225`).
 
 ## Entité de persistance et dialectes pris en charge
 
-**Un seul backend durable** est fourni : `@nodefony/drizzle`. Le décompte honnête :
+**Les deux backends durables portent l'audit** : `@nodefony/drizzle` et `@nodefony/mongoose`. Le
+décompte honnête :
 
-| Backend              | Store d'audit | Dialectes prouvés                   |
+| Backend              | Store d'audit | Moteurs prouvés                     |
 | -------------------- | ------------- | ----------------------------------- |
 | builtin `memory`     | ✅ fourni     | — (mémoire du process, per-pod)     |
 | `@nodefony/drizzle`  | ✅ fourni     | SQLite · PostgreSQL · MySQL/MariaDB |
-| `@nodefony/mongoose` | ❌ absent     | —                                   |
+| `@nodefony/mongoose` | ✅ fourni     | MongoDB                             |
 | `@nodefony/redis`    | ❌ absent     | —                                   |
 
-Mongoose porte session, user, jetons, passkeys et webhooks, mais **pas** l'audit ; Redis non plus.
-Ces deux absences n'ont pas le même statut. Redis n'en aura pas, et la raison n'est pas
-« c'est un cache » — il porte déjà des données durables comme les passkeys, en opt-in assumé. C'est
-que le journal d'audit **croît sans borne**, se conserve des mois pour la conformité, et se
-**consulte** (recherche, filtres, pagination) : garder tout ça en mémoire vive coûte cher pour un
-motif d'accès qui n'est pas le sien. Mongo, lui, est un chemin **durable** :
-l'audit y **manque**, et c'est un manque à combler (objectif « full NoSQL ») — un utilisateur choisit sa base de données, pas de perdre sa traçabilité.
+Une application peut donc tourner **entièrement sur MongoDB** sans perdre sa traçabilité : c'était
+la condition pour que Mongo soit un chemin complet, et pas un chemin qui oblige à rapatrier une
+base SQL pour une seule brique.
 
-En attendant, une application MongoDB qui veut un journal durable a trois voies : brancher un store
-maison (voir l'extension ci-dessous), charger `@nodefony/drizzle` à côté de Mongo — même en SQLite
-local, les deux modules cohabitent — ou héberger le journal sur une base SQL.
+**Redis n'en aura pas, et la raison n'est pas « c'est un cache »** — il porte déjà des données
+durables comme les passkeys, en opt-in assumé. C'est que le journal d'audit **croît sans borne**,
+se conserve des mois pour la conformité, et se **consulte** (recherche, filtres, pagination) :
+garder tout ça en mémoire vive coûte cher pour un motif d'accès qui n'est pas le sien.
 
 ### La table `audit_event`
 
@@ -630,9 +635,9 @@ La règle d'or est écrite en tête du contrat (`IAuditEvent.ts:8`) : **un secre
 Ce que le code garantit, concrètement :
 
 - **Le typage rend le secret difficile à faire entrer.** `actor` est documenté comme un _libellé
-  d'identité_ (`IAuditEvent.ts:74`) et `resource` comme un _descripteur léger_ — « jamais le corps ni
-  les en-têtes de la requête » (`IAuditEvent.ts:79`).
-- **La présence remplace la valeur.** `IAuditEventFlags` (`IAuditEvent.ts:41`) ne porte que deux
+  d'identité_ (`IAuditEvent.ts:82`) et `resource` comme un _descripteur léger_ — « jamais le corps ni
+  les en-têtes de la requête » (`IAuditEvent.ts:87`).
+- **La présence remplace la valeur.** `IAuditEventFlags` (`IAuditEvent.ts:53`) ne porte que deux
   booléens : un en-tête `Authorization` était-il là, un cookie était-il là. `readAuditContext()`
   les calcule par un simple `Boolean(headers[…])` (`readAuditContext.ts:40`) — la valeur n'est jamais
   copiée.
@@ -641,7 +646,7 @@ Ce que le code garantit, concrètement :
   complète de l'événement **ne contient pas** le secret créé
   (`auditEmissionHotPath.test.ts:545`).
 - **Le motif reste machine.** `reason` est une valeur stable et filtrable, pas un message d'erreur
-  libre (`IAuditEvent.ts:84`) : c'est ce qui empêche une cause fine de fuir dans la trace… et qui
+  libre (`IAuditEvent.ts:92`) : c'est ce qui empêche une cause fine de fuir dans la trace… et qui
   permet de la garder **côté audit** alors que le client, lui, reçoit un message d'échec uniforme
   (anti-énumération).
 
@@ -660,11 +665,11 @@ Deux autres propriétés de sécurité valent d'être connues :
 | ----------------------------------------- | --------------------------------- | --------------------------------------------------------------------------------- |
 | Journaliser les échecs d'authentification | OWASP Logging Cheat Sheet         | `auth.failure`/`auth.throttled`/`auth.denied` (`firewall.ts:693`)                 |
 | Journaliser les refus d'autorisation      | OWASP A09:2021                    | `access.denied` sur tout refus du jury (`authorization.ts:130`)                   |
-| Ne jamais journaliser de secret           | OWASP Logging Cheat Sheet         | flags de **présence** seuls (`IAuditEvent.ts:41`)                                 |
-| Traçabilité « qui, quoi, quand, d'où »    | ISO 27001 A.8.15 (journalisation) | acteur, action, horodatage et provenance dans `IAuditEvent` (`IAuditEvent.ts:53`) |
+| Ne jamais journaliser de secret           | OWASP Logging Cheat Sheet         | flags de **présence** seuls (`IAuditEvent.ts:49`)                                 |
+| Traçabilité « qui, quoi, quand, d'où »    | ISO 27001 A.8.15 (journalisation) | acteur, action, horodatage et provenance dans `IAuditEvent` (`IAuditEvent.ts:61`) |
 | Journal inaltérable                       | ISO 27001 A.8.15                  | contrat append-only, aucune mutation exposée (`IAuditStore.ts:48`)                |
-| Rétention bornée / minimisation           | RGPD art. 5.1.e                   | purge par âge pilotée par `retentionDays` (`config.ts:906`)                       |
-| Détection de rejeu de jeton               | RFC 9700 §4.14                    | `token.reuse_detected` + coupure de famille (`tokenService.ts:353`)               |
+| Rétention bornée / minimisation           | RGPD art. 5.1.e                   | purge par âge pilotée par `retentionDays` (`config.ts:912`)                       |
+| Détection de rejeu de jeton               | RFC 9700 §4.14                    | `token.reuse_detected` + coupure de famille (`tokenService.ts:585`)               |
 | Backoff de login journalisé               | NIST SP 800-63B                   | `auth.throttled` avec `reason: "throttled"` (`firewall.ts:773`)                   |
 
 ## 📡 Observabilité — Studio
@@ -674,7 +679,7 @@ L'écran **Sécurité → Journal d'audit** (`/nodefony/audit`) (`Audit.tsx:62`)
 
 - un tableau filtrable par heure, catégorie, action, issue, acteur, raison et IP (`Audit.tsx:227`) ;
 - un indicateur du **store réellement résolu** pour la brique `audit`, alimenté par la publication de
-  résolution du service (`auditService.ts:139`) ;
+  résolution du service (`auditService.ts:145`) ;
 - un interrupteur **Temps réel** qui s'abonne au canal `nodefony:audit` (`AuditLive.tsx:20`) — pensé
   pour les pics d'activité : un journal d'audit se consulte, il ne se regarde pas défiler ;
 - un renvoi vers la **trace de requête** quand l'événement porte un `requestId`, ce qui recolle
@@ -692,19 +697,19 @@ webhook. Détail des souscriptions, de la signature et des relivraisons → [web
 
 ## ⚠️ Pièges
 
-| Symptôme                                            | Cause (dans le code)                                               | Correction                                                 |
-| --------------------------------------------------- | ------------------------------------------------------------------ | ---------------------------------------------------------- |
-| Journal vide après un redémarrage                   | Store `memory` : volatile et per-pod (`MemoryAuditStore.ts:37`)    | `audit.store: "drizzle"` (ou déclarer `NF_DATABASE_URL`)   |
-| Un pod voit des événements, l'autre non             | Store `memory` non partagé                                         | Store durable partagé                                      |
-| Le boot échoue en production sur l'audit            | Store **explicite** inconnu, fail-closed (`auditService.ts:109`)   | Corriger le nom, ou charger l'adapter qui l'enregistre     |
-| `limit=5000` ne rend que 500 événements             | Plafond du store (`MemoryAuditStore.ts:12`)                        | Paginer avec `nextCursor`, jamais gonfler `limit`          |
-| La page 2 répète ou saute des événements            | Pagination réimplémentée en offset                                 | Repasser le `nextCursor` reçu — le curseur est opaque      |
-| Filtre `?category=authen` sans effet                | Catégorie inconnue **ignorée** (`SecurityAdminApi.ts:191`)         | Utiliser une valeur de l'union (`auth`, `authz`, `token`…) |
-| Le paramètre `q` ne filtre rien                     | Non appliqué sur ce journal (`IAuditStore.ts:20`)                  | Filtrer par `category`/`actor`/`action`/`requestId`        |
-| `stream: false` ne coupe pas le live                | Drapeau non lu ; le live suit `#listeners` (`auditService.ts:194`) | Retirer le rôle admin, ou ne pas exposer le canal          |
-| Trous dans le journal pendant une panne de base     | Écriture best-effort (`auditService.ts:192`)                       | Store à haute disponibilité si la conformité l'exige       |
-| Aucun `login.success` alors que les logins marchent | Le succès du **firewall** est muet ; `login.success` vient du BFF  | Filtrer `action=login.success`, pas `category=auth` seul   |
-| Endpoint d'audit en 503                             | `audit.enabled: false` (`SecurityAdminApi.ts:320`)                 | Réactiver l'audit en configuration                         |
+| Symptôme                                            | Cause (dans le code)                                              | Correction                                                 |
+| --------------------------------------------------- | ----------------------------------------------------------------- | ---------------------------------------------------------- |
+| Journal vide après un redémarrage                   | Store `memory` : volatile et per-pod (`MemoryAuditStore.ts:37`)   | `audit.store: "drizzle"` (ou déclarer `NF_DATABASE_URL`)   |
+| Un pod voit des événements, l'autre non             | Store `memory` non partagé                                        | Store durable partagé                                      |
+| Le boot échoue en production sur l'audit            | Store **explicite** inconnu, fail-closed (`auditService.ts:115`)  | Corriger le nom, ou charger l'adapter qui l'enregistre     |
+| `limit=5000` ne rend que 500 événements             | Plafond du store (`MemoryAuditStore.ts:12`)                       | Paginer avec `nextCursor`, jamais gonfler `limit`          |
+| La page 2 répète ou saute des événements            | Pagination réimplémentée en offset                                | Repasser le `nextCursor` reçu — le curseur est opaque      |
+| Filtre `?category=authen` sans effet                | Catégorie inconnue **ignorée** (`SecurityAdminApi.ts:191`)        | Utiliser une valeur de l'union (`auth`, `authz`, `token`…) |
+| Le paramètre `q` ne filtre rien                     | Non appliqué sur ce journal (`IAuditStore.ts:20`)                 | Filtrer par `category`/`actor`/`action`/`requestId`        |
+| `stream: false` ne coupe pas le live                | Drapeau non lu ; le live suit `#listeners` (`auditService.ts:55`) | Retirer le rôle admin, ou ne pas exposer le canal          |
+| Trous dans le journal pendant une panne de base     | Écriture best-effort (`auditService.ts:199`)                      | Store à haute disponibilité si la conformité l'exige       |
+| Aucun `login.success` alors que les logins marchent | Le succès du **firewall** est muet ; `login.success` vient du BFF | Filtrer `action=login.success`, pas `category=auth` seul   |
+| Endpoint d'audit en 503                             | `audit.enabled: false` (`SecurityAdminApi.ts:320`)                | Réactiver l'audit en configuration                         |
 
 ## 🧪 Tests & couverture