@nodefony/security 10.0.0-beta.1 → 10.0.0-beta.3

package/docs/webauthn.md

@@ -32,7 +32,7 @@ source: "src/packages/@nodefony/security/docs/webauthn.md"
 > l'authenticator (Touch ID, Windows Hello, clé FIDO). Le serveur ne détient que des **clés
 > publiques** et ne fait que **vérifier des signatures** : rien à hameçonner, rien à rejouer, rien à
 > voler dans la base. Nodefony orchestre les deux cérémonies FIDO2 dans `WebAuthnService`
-> (`webAuthn.ts:99`) et fournit les endpoints BFF prêts à l'emploi — tu n'écris que l'appel
+> (`webAuthn.ts:131`) et fournit les endpoints BFF prêts à l'emploi — tu n'écris que l'appel
 > navigateur.
 
 📍 [Documentation](../../../../../docs/index.md) › [Sécurité](index.md) › **WebAuthn / Passkeys**
@@ -52,9 +52,9 @@ flowchart LR
 ```
 
 Le défi vit **hors du service**, en session BFF, posé par le controller
-(`WebAuthnController.registerOptions()`, `WebAuthnController.ts:113`). Chaque `verify*` reçoit
+(`WebAuthnController.registerOptions()`, `WebAuthnController.ts:122`). Chaque `verify*` reçoit
 l'`expectedChallenge` qu'il a émis, et le controller **l'invalide dès sa lecture**
-(`WebAuthnController.#takeChallenge()`, `WebAuthnController.ts:281`) : un défi ne sert qu'une fois.
+(`WebAuthnController.#takeChallenge()`, `WebAuthnController.ts:294`) : un défi ne sert qu'une fois.
 
 ## 📖 Lexique
 
@@ -90,7 +90,7 @@ Quatre failles fermées **par construction** :
 2. **Fuite de base** — le serveur ne stocke que des clés **publiques** (`IWebAuthnCredential.publicKey`,
    `IWebAuthnCredential.ts:16`). Une base volée ne donne aucun accès.
 3. **Rejeu** — le défi est à usage unique, invalidé en session dès sa lecture
-   (`WebAuthnController.#takeChallenge()`, `WebAuthnController.ts:281`).
+   (`WebAuthnController.#takeChallenge()`, `WebAuthnController.ts:294`).
 4. **Clonage d'authenticator** — le `signCount` doit croître ; une régression signale une copie
    (`IWebAuthnCredential.signCount`, `IWebAuthnCredential.ts:22`).
 
@@ -99,29 +99,29 @@ matérielle attestée).
 
 ## La vision Nodefony — le serveur ne détient aucun secret
 
-`WebAuthnService` (`webAuthn.ts:99`) **orchestre**, il ne fait pas de cryptographie : le parsing
+`WebAuthnService` (`webAuthn.ts:131`) **orchestre**, il ne fait pas de cryptographie : le parsing
 CBOR/COSE et la vérification des signatures (ES256/RS256/EdDSA) sont délégués à
 `@simplewebauthn/server`, une bibliothèque auditée de l'écosystème, **importée paresseusement** au
-premier usage (`WebAuthnService.#ensureLib()`, `webAuthn.ts:545`) — l'enrôlement et le login sont des
+premier usage (`WebAuthnService.#ensureLib()`, `webAuthn.ts:578`) — l'enrôlement et le login sont des
 chemins froids, ils ne doivent rien coûter aux requêtes ordinaires.
 
 Trois partis pris assumés :
 
 - **Le service est sans état de session.** Le défi est porté par le controller BFF ; le service reçoit
   toujours l'`expectedChallenge` en paramètre (`WebAuthnService.verifyRegistration()`,
-  `webAuthn.ts:323`). Conséquence pratique : le service se teste sans transport, et un défi n'est
+  `webAuthn.ts:355`). Conséquence pratique : le service se teste sans transport, et un défi n'est
   jamais « oublié » quelque part côté serveur.
 - **Le stockage est pluggable** (`IWebAuthnCredentialStore`, `IWebAuthnCredentialStore.ts:75`) :
   mémoire par défaut, ORM ou Redis en production, avec le **même banc de contrat** pour tous.
 - **Les endpoints sont fournis**, pas à réécrire (`mountWebAuthnRoutes()`,
-  `WebAuthnController.ts:314`) : c'est là que vivent les gardes délicates (session du défi, usage
+  `WebAuthnController.ts:323`) : c'est là que vivent les gardes délicates (session du défi, usage
   unique, messages uniformes, anti-IDOR).
 
 ## 🚀 Démarrage rapide
 
 ### 1. Les passkeys sont déjà actives — la config utile
 
-`passkeys.enabled` vaut `true` par défaut (`config.ts:463`). Ce que tu déclares vraiment, c'est **ton
+`passkeys.enabled` vaut `true` par défaut (`config.ts:1460`). Ce que tu déclares vraiment, c'est **ton
 domaine** : sans `rpId`, le service prend le domaine de l'app, et bascule sur `localhost` si c'est une
 adresse IP (un navigateur refuse une IP comme `rpId`, `webAuthn.ts:141`).
 
@@ -155,7 +155,7 @@ export default defineConfig(() => ({
 ### 2. Les endpoints BFF sont FOURNIS
 
 Dès que `@nodefony/security` est chargé, le framework monte six routes
-(`mountWebAuthnRoutes()`, `WebAuthnController.ts:314`) :
+(`mountWebAuthnRoutes()`, `WebAuthnController.ts:323`) :
 
 | Route (`POST` sauf mention)                        | Rôle                                          | Firewall                  |
 | -------------------------------------------------- | --------------------------------------------- | ------------------------- |
@@ -167,10 +167,10 @@ Dès que `@nodefony/security` est chargé, le framework monte six routes
 | `DELETE …/webauthn/credentials/{id}`               | Révoquer **sa** passkey                       | zone protégée             |
 
 > [!IMPORTANT]
-> Les quatre routes de cérémonie sont `bypassFirewall: true` (`WebAuthnController.ts:365`) : elles
+> Les quatre routes de cérémonie sont `bypassFirewall: true` (`WebAuthnController.ts:384`) : elles
 > **sont** le mécanisme d'authentification — les protéger exigerait d'être déjà connecté pour se
 > connecter. Le contrôle d'accès de `register/*` est fait **dans le controller**
-> (`flow.me()` → 401, `WebAuthnController.ts:119`). Les deux routes self-service, elles, restent dans
+> (`flow.me()` → 401, `WebAuthnController.ts:128`). Les deux routes self-service, elles, restent dans
 > la zone protégée (`security.webauthn.credentials.list`, `WebAuthnController.ts:314`).
 
 ### 3. Ce que TU écris : l'appel navigateur
@@ -217,7 +217,7 @@ export async function enrollPasskey(): Promise<string> {
   return out.credentialId;
 }
 
-/** Se connecter sans mot de passe. `username` omis = passkey découvrable. */
+/** Se connecter sans mot de passe : un anonyme reçoit toujours un défi découvrable. */
 export async function loginWithPasskey(
   username?: string,
 ): Promise<{ username: string }> {
@@ -234,9 +234,9 @@ export async function loginWithPasskey(
 }
 ```
 
-Référence vivante dans le dépôt : Studio fait exactement ces deux appels —
-`AuthService.loginWithPasskey()` (`AuthService.ts:111`) et `AuthService.registerPasskey()`
-(`AuthService.ts:133`).
+Référence vivante dans le dépôt : la connexion passe par le déroulé partagé
+`NodefonyLogin.loginWithPasskey()` (`NodefonyLogin.ts:409`, `nodefony/client`), que Studio
+emploie tel quel ; l'enrôlement est `AuthService.registerPasskey()` (`AuthService.ts:36`).
 
 ### 4. Ce qu'on observe
 
@@ -283,23 +283,23 @@ sequenceDiagram
 
 ### Enrôler une passkey sur un compte existant
 
-`WebAuthnService.generateRegistrationOptions()` (`webAuthn.ts:282`) construit le défi et les
-contraintes. **`excludeCredentials`** y liste les passkeys déjà enrôlées (`webAuthn.ts:297`) : le même
-authenticator ne peut pas s'inscrire deux fois. Dans `authenticatorSelection` (`webAuthn.ts:301`),
+`WebAuthnService.generateRegistrationOptions()` (`webAuthn.ts:314`) construit le défi et les
+contraintes. **`excludeCredentials`** y liste les passkeys déjà enrôlées (`webAuthn.ts:329`) : le même
+authenticator ne peut pas s'inscrire deux fois. Dans `authenticatorSelection` (`webAuthn.ts:333`),
 `authenticatorAttachment` n'est transmis **que** s'il vaut autre chose que `"any"` — `"any"` rend la
 main au navigateur, téléphone par QR compris.
 
-`WebAuthnService.verifyRegistration()` (`webAuthn.ts:323`) enchaîne dans cet ordre :
+`WebAuthnService.verifyRegistration()` (`webAuthn.ts:355`) enchaîne dans cet ordre :
 
 1. **Vérification déléguée** à `verifyRegistrationResponse` — défi, origine, rpIdHash, flags,
-   attestation (`webAuthn.ts:330`). Tout échec devient un message uniforme
+   attestation (`webAuthn.ts:368`). Tout échec devient un message uniforme
    `WebAuthn registration failed` (`webAuthn.ts:345`).
 2. **Plafond d'enrôlement** — `countByUser`, refus `409` si `maxPerUser` est atteint
    (`webAuthn.ts:355`). Volontairement **après** la cryptographie et **avant** le `save` : un client
    peut poster `register/verify` sans jamais appeler `register/options` — c'est l'écriture qu'il faut
    garder, pas la génération du défi.
-3. **Persistance** de la clé publique + l'état initial (`webAuthn.ts:365`) — `backupEligible` dérive
-   de `credentialDeviceType === "multiDevice"` (`webAuthn.ts:365`).
+3. **Persistance** de la clé publique + l'état initial (`webAuthn.ts:397`) — `backupEligible` dérive
+   de `credentialDeviceType === "multiDevice"` (`webAuthn.ts:397`).
 
 ### Se connecter sans mot de passe
 
@@ -323,9 +323,9 @@ est ignoré.
 > produit des credentials non découvrables — leurs porteurs ne pourront plus se connecter, et le
 > service l'avertit au boot.
 
-`WebAuthnService.verifyAuthentication()` (`webAuthn.ts:420`) résout le credential par son id
+`WebAuthnService.verifyAuthentication()` (`webAuthn.ts:452`) résout le credential par son id
 (`webAuthn.ts:420`), vérifie la signature contre la clé publique stockée, puis **applique l'état** :
-`signCount`, `backupState`, `uvInitialized` (jamais rétrogradé), `lastUsedAt` (`webAuthn.ts:460`). Le
+`signCount`, `backupState`, `uvInitialized` (jamais rétrogradé), `lastUsedAt` (`webAuthn.ts:492`). Le
 controller ouvre alors la session BFF avec `authFlow.establishSessionFor()`
 (`WebAuthnController.ts:64`).
 
@@ -340,12 +340,15 @@ controller ouvre alors la session BFF avec `authFlow.establishSessionFor()`
 Deux chemins, deux portées :
 
 - **Self-service** : `DELETE …/webauthn/credentials/{id}` → `WebAuthnService.removeUserCredential()`
-  (`webAuthn.ts:502`). La suppression n'aboutit que si le credential **appartient** au demandeur
+  (`webAuthn.ts:535`). La suppression n'aboutit que si le credential **appartient** au demandeur
   (`webAuthn.ts:513`) ; sinon **404 indiscernable** (`WebAuthnController.ts:207`) — on ne révèle
   jamais l'existence de la passkey d'autrui.
 - **Reset administrateur** : `DELETE /nodefony/security/api/users/{id}/passkeys/{credentialId}`
-  (`SecurityAdminApi.ts:590`) — audité, et **404 identique** si la passkey n'appartient pas à
-  l'utilisateur visé, même pour un admin.
+  (`SecurityAdminApi.ts:649`) — audité, et **404 identique** si la passkey n'appartient pas à
+  l'utilisateur visé, même pour un admin. L'`id` de la route est d'abord traduit en
+  `identifier` : c'est sous lui que les passkeys sont rangées (`IWebAuthnCredentialStore.ts:81`).
+- **Suppression du compte** : la cascade `onUserRevoked` (`reason: "deleted"`) retire toutes ses
+  passkeys (`userRevocationCascade.ts:51`) — un compte recréé sous le même identifiant n'en hérite pas.
 
 Une passkey **non sauvegardée** (`backupState: false`) meurt avec son appareil — d'où le filtre
 `backedUp` du listing admin (`IWebAuthnListQuery`, `IWebAuthnCredentialStore.ts:47`), qui liste
@@ -353,23 +356,23 @@ exactement les porteurs à risque de verrouillage.
 
 ## ⚙️ Configuration
 
-Table dérivée du schéma Zod `passkeysSchema` (`config.ts:461`), monté sous la clé `passkeys`
-(`config.ts:1143`).
+Table dérivée du schéma Zod `passkeysSchema` (`config.ts:528`), monté sous la clé `passkeys`
+(`config.ts:1460`).
 
 | Option                    | Type                                       | Défaut       | Effet                                                                          |
 | ------------------------- | ------------------------------------------ | ------------ | ------------------------------------------------------------------------------ |
-| `enabled`                 | boolean                                    | `true`       | Active les cérémonies ; `false` → endpoints en 503 (`config.ts:463`)           |
-| `rpId`                    | string?                                    | domaine app  | Domaine de liaison des passkeys ; IP → `localhost` (`config.ts:469`)           |
-| `rpName`                  | string?                                    | `"Nodefony"` | Nom affiché dans l'invite OS/navigateur (`config.ts:473`)                      |
-| `origins`                 | string[]                                   | `[]`         | Liste blanche d'origines ; vide = déduction depuis `rpId` (`config.ts:469`)    |
-| `userVerification`        | `required` \| `preferred` \| `discouraged` | `preferred`  | Exiger biométrie/PIN — `required` = AAL2 (`config.ts:483`)                     |
-| `residentKey`             | `required` \| `preferred` \| `discouraged` | `preferred`  | Passkey découvrable → login sans identifiant (`config.ts:489`)                 |
-| `authenticatorAttachment` | `platform` \| `cross-platform` \| `any`    | `platform`   | Biométrie intégrée / clé externe / les deux (`config.ts:495`)                  |
-| `attestation`             | `none` \| `direct` \| `enterprise`         | `none`       | Conveyance du certificat fabricant (`config.ts:501`)                           |
-| `timeoutMs`               | number (ms)                                | `60000`      | Délai laissé à l'utilisateur pour la cérémonie (`config.ts:507`)               |
-| `maxPerUser`              | number                                     | `20`         | Plafond de passkeys par porteur, `409` au-delà (`config.ts:515`)               |
-| `challengeTtlS`           | number (s)                                 | `300`        | **RÉSERVÉ, non câblé** : le défi suit la session (`config.ts:523`)             |
-| `store`                   | string                                     | `"auto"`     | `auto`\|`memory`\|`drizzle`\|`mongoose`\|`redis` — pluggable (`config.ts:528`) |
+| `enabled`                 | boolean                                    | `true`       | Active les cérémonies ; `false` → endpoints en 503 (`config.ts:530`)           |
+| `rpId`                    | string?                                    | domaine app  | Domaine de liaison des passkeys ; IP → `localhost` (`config.ts:536`)           |
+| `rpName`                  | string?                                    | `"Nodefony"` | Nom affiché dans l'invite OS/navigateur (`config.ts:540`)                      |
+| `origins`                 | string[]                                   | `[]`         | Liste blanche d'origines ; vide = déduction depuis `rpId` (`config.ts:536`)    |
+| `userVerification`        | `required` \| `preferred` \| `discouraged` | `preferred`  | Exiger biométrie/PIN — `required` = AAL2 (`config.ts:550`)                     |
+| `residentKey`             | `required` \| `preferred` \| `discouraged` | `preferred`  | Passkey découvrable → login sans identifiant (`config.ts:556`)                 |
+| `authenticatorAttachment` | `platform` \| `cross-platform` \| `any`    | `platform`   | Biométrie intégrée / clé externe / les deux (`config.ts:562`)                  |
+| `attestation`             | `none` \| `direct` \| `enterprise`         | `none`       | Conveyance du certificat fabricant (`config.ts:568`)                           |
+| `timeoutMs`               | number (ms)                                | `60000`      | Délai laissé à l'utilisateur pour la cérémonie (`config.ts:574`)               |
+| `maxPerUser`              | number                                     | `20`         | Plafond de passkeys par porteur, `409` au-delà (`config.ts:582`)               |
+| `challengeTtlS`           | number (s)                                 | `300`        | **RÉSERVÉ, non câblé** : le défi suit la session (`config.ts:590`)             |
+| `store`                   | string                                     | `"auto"`     | `auto`\|`memory`\|`drizzle`\|`mongoose`\|`redis` — pluggable (`config.ts:552`) |
 
 ### Mise en situation — trois politiques, trois publics
 
@@ -393,7 +396,7 @@ passkeys: {
 
 > [!WARNING]
 > `attestation: "direct"` **récupère** le certificat, il ne le **valide pas** : Nodefony ne vérifie ni
-> l'AAGUID ni la chaîne contre la MDS FIDO (`config.ts:501`). Tant que cette vérification n'est pas
+> l'AAGUID ni la chaîne contre la MDS FIDO (`config.ts:568`). Tant que cette vérification n'est pas
 > faite dans ton application, tu as la donnée, pas la garantie AAL3 — et tu paies un coût de vie
 > privée (l'attestation identifie le modèle d'authenticator).
 
@@ -404,30 +407,31 @@ sans champ à remplir.
 passkeys: { residentKey: "required" }, // la passkey DOIT être découvrable
 ```
 
-Et côté client, **n'envoie pas** `username` à `login/options` : `allowCredentials` est alors omis et
-le navigateur propose les comptes qu'il connaît. C'est aussi la variante la plus sobre côté vie
-privée — voir la section suivante.
+Côté client, rien à faire de plus : le serveur **ignore** tout `username` posté par un anonyme.
+`allowCredentials` est omis et le navigateur propose les comptes qu'il connaît. Le ciblage ne vient
+jamais du corps de la requête, seulement de la session (`WebAuthnController.loginOptions()`,
+`WebAuthnController.ts:171`).
 
-| Ce que le client envoie à `login/options` | Ce que renvoie le serveur                       | Conséquence                                      |
-| ----------------------------------------- | ----------------------------------------------- | ------------------------------------------------ |
-| `{}`                                      | défi seul, **sans** `allowCredentials`          | l'authenticator propose ses comptes              |
-| `{"username":"alice"}` (alice a 3 clés)   | défi + `allowCredentials` de **3** identifiants | ciblage — mais l'anonyme apprend qu'ils existent |
-| `{"username":"fantome"}`                  | défi + `allowCredentials: []` (200, jamais 404) | pas d'erreur révélatrice — mais liste vide       |
+| Qui appelle `login/options`             | Ce que renvoie le serveur                            | Conséquence                                 |
+| --------------------------------------- | ---------------------------------------------------- | ------------------------------------------- |
+| anonyme, `{}`                           | défi seul, **sans** `allowCredentials`               | l'authenticator propose ses comptes         |
+| anonyme, `{"username":"alice"}`         | identique : le `username` est ignoré                 | aucun ciblage, rien à apprendre sur `alice` |
+| session authentifiée (ré-auth, step-up) | défi + `allowCredentials` des clés **de ce porteur** | ciblage de ses propres passkeys             |
 
 ## 🛡️ `rpId` et origines — l'ancre anti-phishing
 
 Le `rpId` est ce à quoi la passkey est **soudée**. Le navigateur refuse de signer pour un autre
 domaine : c'est ce lien, et pas une vérification côté serveur, qui rend l'hameçonnage impossible.
 
-Résolution au boot (`WebAuthnService.#build()`, `webAuthn.ts:120`) : `passkeys.rpId` sinon le domaine
+Résolution au boot (`WebAuthnService.#build()`, `webAuthn.ts:152`) : `passkeys.rpId` sinon le domaine
 de l'app ; une **adresse IP ou une adresse IPv6 bascule sur `localhost`** (`webAuthn.ts:134`), seul
 host non-domaine que la spécification autorise. En développement, accède donc au serveur par
 `https://localhost:5152`, jamais par `127.0.0.1`.
 
-L'origine attendue est calculée par `WebAuthnService.#expectedOrigin()` (`webAuthn.ts:528`) en trois
-temps : la **liste blanche `passkeys.origins`** si elle est non vide (`webAuthn.ts:529`, la voie de
+L'origine attendue est calculée par `WebAuthnService.#expectedOrigin()` (`webAuthn.ts:559`) en trois
+temps : la **liste blanche `passkeys.origins`** si elle est non vide (`webAuthn.ts:560`, la voie de
 production) ; sinon **l'origine de la requête, mais seulement si son hostname est exactement le
-`rpId`** (`webAuthn.ts:535` — en dev, `localhost:5173` et `localhost:5152` passent tous deux, le port
+`rpId`** (`webAuthn.ts:568` — en dev, `localhost:5173` et `localhost:5152` passent tous deux, le port
 est ignoré, sans jamais ouvrir à un domaine tiers) ; en dernier recours `https://{rpId}`
 (`webAuthn.ts:542`).
 
@@ -439,18 +443,20 @@ est ignoré, sans jamais ouvrir à un domaine tiers) ; en dernier recours `https
 
 ## 🔐 Le point à ne pas rater — plafond d'enrôlement et `login/options` ouvert
 
-`login/options` est **accessible à un anonyme** (`bypassFirewall`) et accepte un `username`
-(`WebAuthnController.ts:168`). C'est nécessaire — on ne peut pas exiger d'être connecté pour se
-connecter — mais cela ouvre deux surfaces qu'il faut regarder en face.
+`login/options` est **accessible à un anonyme** (`bypassFirewall`). C'est nécessaire — on ne peut
+pas exiger d'être connecté pour se connecter. Le ciblage, lui, ne vient jamais du corps : un anonyme
+reçoit toujours un défi découvrable, et seule une session authentifiée cible ses propres passkeys
+(`WebAuthnController.loginOptions()`, `WebAuthnController.ts:171`). Deux surfaces restent à
+regarder en face.
 
 ### Amplification : bornée par le plafond, pas par une pagination
 
-Avec un `username`, le serveur charge **toutes** les passkeys du porteur pour construire
-`allowCredentials` (`webAuthn.ts:399`). Cet appel `findByUser` est **volontairement non paginé** —
+Pour une session authentifiée, le serveur charge **toutes** les passkeys du porteur pour construire
+`allowCredentials` (`WebAuthnService.generateAuthenticationOptions()`, `webAuthn.ts:422`). Cet appel `findByUser` est **volontairement non paginé** —
 `allowCredentials` doit être complet ou il est faux : un authenticator absent de la liste ne peut pas
 répondre, et le protocole n'offre aucune « page suivante » (`IWebAuthnCredentialStore.ts:88`).
 
-Ce qui borne donc cette lecture, c'est **`passkeys.maxPerUser`** (défaut 20, `config.ts:515`) :
+Ce qui borne donc cette lecture, c'est **`passkeys.maxPerUser`** (défaut 20, `config.ts:582`) :
 
 - le refus est un `409` porté par `WebAuthnError` (`WebAuthnError.ts:15`), rendu **tel quel** au
   client parce qu'il est authentifié — rien à énumérer, et il doit comprendre qu'il faut retirer un
@@ -460,22 +466,17 @@ Ce qui borne donc cette lecture, c'est **`passkeys.maxPerUser`** (défaut 20, `c
   (3 comptages, 0 chargement) ;
 - retirer un appareil **libère une place** : le plafond est une borne, pas un compteur qui dérive.
 
-### Énumération : le statut est uniforme, la liste ne l'est pas
+### Énumération : rien ne distingue deux comptes
 
-Un compte inexistant reçoit **200 + un défi**, exactement comme un compte réel — le test d'attaque E3
-(`webauthn-attack.test.ts`) verrouille ce point. Aucun 404, aucun message différencié, aucune latence
-de recherche de mot de passe.
+Un anonyme reçoit **toujours le même défi découvrable**, sans `allowCredentials`, qu'il poste ou non
+un `username` : aucun statut, aucune liste, aucune latence ne dit si un compte existe ou porte une
+passkey, et l'appel ne touche même pas le store. C'est le remède que la spécification W3C WebAuthn
+propose contre la fuite des identifiants de credentials ; `webauthnLoginOptionsPrivacy.test.ts` le
+verrouille.
 
-Mais `allowCredentials` reflète la réalité : **vide** pour un identifiant sans passkey, **peuplé** (et
-portant les identifiants de credentials) pour un porteur enrôlé. Un anonyme peut donc distinguer
-« cet identifiant a au moins une passkey » de « il n'en a pas ».
-
-> [!WARNING]
-> C'est le comportement standard d'un `login/options` avec identifiant, et la parade est
-> architecturale : **ne transmets pas `username`**. Avec `residentKey: "required"` et un client qui
-> poste `{}`, `allowCredentials` est omis, aucun état de compte ne transparaît, et l'appel ne touche
-> même pas le store. Si ton UX exige la saisie d'un identifiant, place un rate-limit devant
-> `login/options` — le firewall ne le protège pas, c'est une route en `bypassFirewall`.
+> [!NOTE]
+> `login/options` reste une route en `bypassFirewall` : le firewall ne la protège pas. Un rate-limit
+> en amont reste de bonne hygiène, pour borner le coût des défis émis.
 
 Les autres gardes de cette surface, toutes couvertes par des tests d'attaque :
 
@@ -483,7 +484,7 @@ Les autres gardes de cette surface, toutes couvertes par des tests d'attaque :
 | ----------------------------------------- | -------------------------------------------------------------------------------------------------- |
 | Rejeu d'un défi                           | Invalidé à la lecture, avant la crypto (`WebAuthnController.ts:277`) — E1/E1bis                    |
 | Défi d'enrôlement réutilisé pour un login | Clés de session **disjointes** (`WebAuthnController.ts:74-75`) — E2                                |
-| Lecture de la cause d'échec               | Message uniforme `WebAuthn verification failed` (`WebAuthnController.ts:292`) — E4                 |
+| Lecture de la cause d'échec               | Message uniforme `WebAuthn verification failed` (`WebAuthnController.ts:309`) — E4                 |
 | Suppression de la passkey d'autrui        | Ownership vérifié → 404 indiscernable (`webAuthn.ts:513`)                                          |
 | Réassignation du porteur via `update`     | Le patch ne porte que l'état mutable (`WebAuthnAuthUpdate`, `IWebAuthnCredentialStore.ts:58`) — A1 |
 
@@ -495,7 +496,7 @@ clé privée n'existe que dans l'authenticator.
 | Champ            | Sens                                                 | SQL (`colKit`)      | Mongoose         | Redis (HASH)            |
 | ---------------- | ---------------------------------------------------- | ------------------- | ---------------- | ----------------------- |
 | `id`             | Identifiant du credential, base64url — clé naturelle | `text` PK           | `_id: String`    | clé `nf:wac:cred:<id>`  |
-| `userId`         | Porteur (= identifiant applicatif / `userHandle`)    | `text` notNull, idx | `String` indexé  | champ + SET `user:<id>` |
+| `userId`         | Porteur = `IUser.identifier` (jamais `IUser.id`)     | `text` notNull, idx | `String` indexé  | champ + SET `user:<id>` |
 | `publicKey`      | Clé publique **COSE**, base64url                     | `text` notNull      | `String` requis  | champ                   |
 | `signCount`      | Compteur anti-clone (§6.1.1)                         | `int64` notNull     | `Number` requis  | champ                   |
 | `transports`     | `usb`\|`nfc`\|`ble`\|`internal`\|`hybrid`            | `json` notNull      | `[String]`       | champ JSON              |
@@ -516,7 +517,7 @@ explicite, `IWebAuthnCredentialStore` n'a pas de maintenance (`IWebAuthnCredenti
 **`nickname` est
 stocké et rendu, jamais écrit par le framework** — aucune API publique ne le renseigne, le champ
 existe pour une UX « renommer cet appareil » côté application ; **`userId` est l'identifiant
-applicatif** (`me.username`, figé à l'enrôlement, `WebAuthnController.ts:109`) — renommer un compte
+applicatif** (`me.username`, figé à l'enrôlement, `WebAuthnController.ts:28`) — renommer un compte
 orphelinise donc ses passkeys.
 
 ## 🧩 Backends de stockage — quatre enregistrés, et comment brancher le tien
@@ -534,7 +535,7 @@ Le contrat `IWebAuthnCredentialStore` (`IWebAuthnCredentialStore.ts:75`) est ré
 | Flotte de pods, Redis déjà présent          | `redis`            | O(1) par credential ; listing **par curseur**, sans total (capacité réduite) |
 
 **`store: "auto"` (défaut)** suit l'infra déclarée, borné aux backends réellement enregistrés
-(`webAuthn.ts:155`) — la décision (configuré → résolu, raison) est publiée au kernel et visible dans
+(`webAuthn.ts:134`) — la décision (configuré → résolu, raison) est publiée au kernel et visible dans
 Studio (`webAuthn.ts:195`). Deux garde-fous de production :
 
 - un store **explicitement** configuré mais inconnu **avorte le boot en production**
@@ -572,10 +573,10 @@ Studio (`webAuthn.ts:195`). Deux garde-fous de production :
 - Enregistré par le module redis (`redis/nodefony/registerStores.ts:62`) ;
   `RedisWebAuthnCredentialStore` (`RedisWebAuthnCredentialStore.ts:93`) stocke un **HASH** par
   credential + un **SET** d'ids par porteur — `update` réécrit 1 à 4 champs sans relire
-  l'enregistrement (`RedisWebAuthnCredentialStore.ts:219`).
-- Listing par `SCAN`, curseur composite `skip:scanCursor` (`RedisWebAuthnCredentialStore.ts:257`) :
+  l'enregistrement (`RedisWebAuthnCredentialStore.ts:240`).
+- Listing par `SCAN`, curseur composite `skip:scanCursor` (`RedisWebAuthnCredentialStore.ts:299`) :
   **ni ordre global ni total**, pages de taille variable — capacité réduite **déclarée**, pas un
-  défaut. `countCredentials()` renvoie `-1` (`RedisWebAuthnCredentialStore.ts:330`).
+  défaut. `countCredentials()` renvoie `-1` (`RedisWebAuthnCredentialStore.ts:339`).
 
 ### Brancher son propre store
 
@@ -603,16 +604,16 @@ symbolique (`.ai/symbols.json`).
 
 | Méthode                           | Quand tu l'appelles                                                      |
 | --------------------------------- | ------------------------------------------------------------------------ |
-| `isEnabled()`                     | Savoir si les cérémonies sont opérationnelles (`webAuthn.ts:268`)        |
-| `generateRegistrationOptions()`   | Défi d'enrôlement pour un porteur (`webAuthn.ts:282`)                    |
-| `verifyRegistration()`            | Vérifier + stocker, plafond appliqué (`webAuthn.ts:323`)                 |
-| `generateAuthenticationOptions()` | Défi de login, ciblé ou découvrable (`webAuthn.ts:390`)                  |
-| `verifyAuthentication()`          | Vérifier l'assertion + appliquer l'état (`webAuthn.ts:420`)              |
-| `listUserCredentials()`           | « Mes appareils » — chemin chaud, non paginé (`webAuthn.ts:466`)         |
-| `listCredentialsPage()`           | Vue **transverse** admin, paginée, sans clé publique (`webAuthn.ts:479`) |
-| `countCredentials()`              | Total filtré, ou `-1` si le backend ne compte pas (`webAuthn.ts:490`)    |
-| `removeUserCredential()`          | Révocation self-service, owner-scopée (`webAuthn.ts:502`)                |
-| `removeCredential()`              | Révocation inconditionnelle, usage admin (`webAuthn.ts:492`)             |
+| `isEnabled()`                     | Savoir si les cérémonies sont opérationnelles (`webAuthn.ts:300`)        |
+| `generateRegistrationOptions()`   | Défi d'enrôlement pour un porteur (`webAuthn.ts:314`)                    |
+| `verifyRegistration()`            | Vérifier + stocker, plafond appliqué (`webAuthn.ts:355`)                 |
+| `generateAuthenticationOptions()` | Défi de login, ciblé ou découvrable (`webAuthn.ts:422`)                  |
+| `verifyAuthentication()`          | Vérifier l'assertion + appliquer l'état (`webAuthn.ts:452`)              |
+| `listUserCredentials()`           | « Mes appareils » — chemin chaud, non paginé (`webAuthn.ts:498`)         |
+| `listCredentialsPage()`           | Vue **transverse** admin, paginée, sans clé publique (`webAuthn.ts:510`) |
+| `countCredentials()`              | Total filtré, ou `-1` si le backend ne compte pas (`webAuthn.ts:520`)    |
+| `removeUserCredential()`          | Révocation self-service, owner-scopée (`webAuthn.ts:535`)                |
+| `removeCredential()`              | Révocation inconditionnelle, usage admin (`webAuthn.ts:525`)             |
 
 Types publics ré-exportés par `@nodefony/security` : `IWebAuthnCredential`,
 `IWebAuthnCredentialStore`, `IWebAuthnCredentialSummary`, `IWebAuthnListQuery`,
@@ -637,28 +638,28 @@ Le data plane admin du module expose trois routes (`SecurityAdminApi.ts:308`), t
 | `DELETE /nodefony/security/api/users/{id}/passkeys/{credentialId}` | Reset administrateur, audité (`SecurityAdminApi.ts:590`) |
 
 Deux comportements à connaître : la **redaction est par construction** — la vue admin omet la clé
-publique et le `userId` déjà présent dans le chemin (`toCredentialView()`, `SecurityAdminApi.ts:267`),
+publique et le `userId` déjà présent dans le chemin (`toCredentialView()`, `SecurityAdminApi.ts:308`),
 et ce n'est pas un masquage tardif, le contrat de store ne la produit jamais ; la **lecture est
 défensive** — passkeys désactivées → `{ enabled: false, items: [] }` et non une erreur, la console
 doit afficher « passkeys désactivées », pas un 503 (`SecurityAdminApi.ts:532`). `total: -1` signale un
 backend sans comptage (Redis).
 
 Côté UI, l'écran **Profil** (`/nodefony/profile`) de Studio porte l'enrôlement self-service et l'écran de login le bouton
-passkey (`AuthStore.loginWithPasskey()`, `AuthStore.ts:212`).
+passkey (`AuthStore.loginWithPasskey()`, `AuthStore.ts:316`, qui délègue au déroulé partagé).
 
 ## 📜 Normes appliquées
 
 | Domaine                             | Norme                              | Ancrage                                                            |
 | ----------------------------------- | ---------------------------------- | ------------------------------------------------------------------ |
-| Cérémonie d'enregistrement          | W3C WebAuthn L3 §7.1               | `WebAuthnService.verifyRegistration()` (`webAuthn.ts:323`)         |
-| Cérémonie d'authentification        | W3C WebAuthn L3 §7.2               | `WebAuthnService.verifyAuthentication()` (`webAuthn.ts:420`)       |
+| Cérémonie d'enregistrement          | W3C WebAuthn L3 §7.1               | `WebAuthnService.verifyRegistration()` (`webAuthn.ts:355`)         |
+| Cérémonie d'authentification        | W3C WebAuthn L3 §7.2               | `WebAuthnService.verifyAuthentication()` (`webAuthn.ts:452`)       |
 | Compteur anti-clone                 | W3C WebAuthn §6.1.1                | `IWebAuthnCredential.signCount` (`IWebAuthnCredential.ts:22`)      |
 | Flags de sauvegarde (BE/BS)         | W3C WebAuthn §6.1.3                | `IWebAuthnCredential.backupEligible` (`IWebAuthnCredential.ts:29`) |
-| Liaison à l'origine (anti-phishing) | W3C WebAuthn §13.4.8               | `WebAuthnService.#expectedOrigin()` (`webAuthn.ts:528`)            |
+| Liaison à l'origine (anti-phishing) | W3C WebAuthn §13.4.8               | `WebAuthnService.#expectedOrigin()` (`webAuthn.ts:559`)            |
 | Clé publique COSE                   | RFC 8152 / RFC 9052                | `IWebAuthnCredential.publicKey` (`IWebAuthnCredential.ts:16`)      |
-| FIDO2 / CTAP2                       | plafond `maxCredentialCountInList` | `passkeys.maxPerUser` (`config.ts:515`)                            |
-| Assurance d'authentification        | NIST SP 800-63B (AAL2)             | `passkeys.userVerification` (`config.ts:483`)                      |
-| Contrôle d'accès (IDOR)             | OWASP A01                          | `WebAuthnService.removeUserCredential()` (`webAuthn.ts:502`)       |
+| FIDO2 / CTAP2                       | plafond `maxCredentialCountInList` | `passkeys.maxPerUser` (`config.ts:582`)                            |
+| Assurance d'authentification        | NIST SP 800-63B (AAL2)             | `passkeys.userVerification` (`config.ts:550`)                      |
+| Contrôle d'accès (IDOR)             | OWASP A01                          | `WebAuthnService.removeUserCredential()` (`webAuthn.ts:535`)       |
 
 La conformité cryptographique fine (parsing CBOR, formats d'attestation, vérification des signatures
 ES256/RS256/EdDSA) est portée par `@simplewebauthn/server` — Nodefony fournit et prouve les
@@ -670,29 +671,28 @@ Les cérémonies sont un **chemin froid** : quelques appels par utilisateur et p
 requête. Le code en tire trois conséquences.
 
 - **Import paresseux de la bibliothèque** : `@simplewebauthn/server` n'est chargé qu'au premier usage
-  réel (`WebAuthnService.#ensureLib()`, `webAuthn.ts:545`) — une app qui n'enrôle personne ne paie
+  réel (`WebAuthnService.#ensureLib()`, `webAuthn.ts:578`) — une app qui n'enrôle personne ne paie
   jamais son coût de parse.
 - **Rien d'alloué quand c'est désactivé** : `passkeys.enabled: false` sort de `#build()` immédiatement
-  (`webAuthn.ts:119-130`) — pas de store, pas de `Map`.
+  (`webAuthn.ts:152-164`) — pas de store, pas de `Map`.
 - **Le listing admin ne matérialise jamais plus d'une page** : `listPage` applique les filtres au
   store (`IWebAuthnCredentialStore.ts:114`). Le seul appel non paginé, `findByUser`, est borné par
   `maxPerUser` — par conception (`IWebAuthnCredentialStore.ts:88`).
 
 ## ⚠️ Pièges (symptôme → cause → correction)
 
-| Symptôme                                             | Cause (dans le code)                                                       | Correction                                                     |
-| ---------------------------------------------------- | -------------------------------------------------------------------------- | -------------------------------------------------------------- |
-| `409` à l'enrôlement                                 | Plafond `passkeys.maxPerUser` atteint (`webAuthn.ts:355`)                  | Retirer un appareil, ou relever `maxPerUser`                   |
-| `400 No challenge` au `verify`                       | Défi absent : déjà consommé, ou pas de cookie renvoyé                      | Un défi = un `verify` ; envoyer le cookie (`credentials`)      |
-| `401` systématique en production                     | Origine hors liste blanche, ou `rpId` ≠ domaine servi                      | Renseigner `passkeys.origins` + `rpId` enregistrable           |
-| Passkey KO en dev sur `127.0.0.1`                    | Une IP n'est pas un `rpId` valide → repli `localhost`                      | Accéder par `https://localhost:<port>`                         |
-| Passkeys d'un sous-domaine inutilisables sur l'autre | `rpId` unique, résolu au boot, pas de résolution par `Host`                | Choisir un `rpId` parent commun (`example.com`)                |
-| Login refusé après restauration d'une sauvegarde     | `signCount` régressif → clone suspecté (§6.1.1)                            | Comportement voulu — ré-enrôler l'appareil                     |
-| Tout le monde verrouillé dehors après un déploiement | `store` resté en `memory` : credentials volatils (`webAuthn.ts:183`)       | Déclarer une infra durable ; le `WARNING` boot le disait       |
-| `503 WebAuthn unavailable`                           | `passkeys.enabled: false` ou boot du service échoué                        | Activer `passkeys` ; vérifier le store configuré               |
-| Un anonyme distingue les comptes à passkey           | `allowCredentials` peuplé vs vide sur `login/options`                      | Ne pas envoyer `username` (usernameless) ; rate-limit la route |
-| `total` absent du listing admin                      | Backend curseur (Redis) → `countCredentials()` rend `-1`                   | Paginer par `nextCursor`, ne pas afficher de total             |
-| Passkeys orphelines après renommage d'un compte      | `userId` = `me.username` figé à l'enrôlement (`WebAuthnController.ts:109`) | Ne pas renommer, ou ré-enrôler après renommage                 |
+| Symptôme                                             | Cause (dans le code)                                                      | Correction                                                |
+| ---------------------------------------------------- | ------------------------------------------------------------------------- | --------------------------------------------------------- |
+| `409` à l'enrôlement                                 | Plafond `passkeys.maxPerUser` atteint (`webAuthn.ts:355`)                 | Retirer un appareil, ou relever `maxPerUser`              |
+| `400 No challenge` au `verify`                       | Défi absent : déjà consommé, ou pas de cookie renvoyé                     | Un défi = un `verify` ; envoyer le cookie (`credentials`) |
+| `401` systématique en production                     | Origine hors liste blanche, ou `rpId` ≠ domaine servi                     | Renseigner `passkeys.origins` + `rpId` enregistrable      |
+| Passkey KO en dev sur `127.0.0.1`                    | Une IP n'est pas un `rpId` valide → repli `localhost`                     | Accéder par `https://localhost:<port>`                    |
+| Passkeys d'un sous-domaine inutilisables sur l'autre | `rpId` unique, résolu au boot, pas de résolution par `Host`               | Choisir un `rpId` parent commun (`example.com`)           |
+| Login refusé après restauration d'une sauvegarde     | `signCount` régressif → clone suspecté (§6.1.1)                           | Comportement voulu — ré-enrôler l'appareil                |
+| Tout le monde verrouillé dehors après un déploiement | `store` resté en `memory` : credentials volatils (`webAuthn.ts:183`)      | Déclarer une infra durable ; le `WARNING` boot le disait  |
+| `503 WebAuthn unavailable`                           | `passkeys.enabled: false` ou boot du service échoué                       | Activer `passkeys` ; vérifier le store configuré          |
+| `total` absent du listing admin                      | Backend curseur (Redis) → `countCredentials()` rend `-1`                  | Paginer par `nextCursor`, ne pas afficher de total        |
+| Passkeys orphelines après renommage d'un compte      | `userId` = `me.username` figé à l'enrôlement (`WebAuthnController.ts:28`) | Ne pas renommer, ou ré-enrôler après renommage            |
 
 ## 🧪 Tests & couverture
 

package/docs/webhooks.md

@@ -160,7 +160,7 @@ Trois partis pris, tous vérifiables dans le code :
 
 ### 1. Activer les webhooks et poser la clé de chiffrement
 
-Les webhooks sont **actifs par défaut** (`enabled: true` dans le schéma Zod, `security/nodefony/config/config.ts:785`).
+Les webhooks sont **actifs par défaut** (`enabled: true` dans le schéma Zod, `security/nodefony/config/config.ts:809`).
 La seule chose que tu dois vraiment fournir, c'est la **clé de chiffrement des secrets de signature** :
 sans elle, une clé éphémère est générée en dev (avec un WARNING), et en production les webhooks sont
 **désactivés** — un secret chiffré par une clé perdue au redémarrage serait illisible
@@ -168,7 +168,7 @@ sans elle, une clé éphémère est générée en dev (avec un WARNING), et en p
 
 ```bash
 # Génère les clés du module security et guide le câblage en 3 fichiers.
-npx nodefony security:secrets --write   # écrit NF_WEBHOOK_KEY dans .env.local
+npx nodefony security:secrets --write   # écrit NF_WEBHOOK_KEY dans .env
 ```
 
 ```typescript
@@ -251,7 +251,7 @@ import { Buffer } from "node:buffer";
 // prettier-ignore
 import { Controller, controller, Post, Body, Headers, BypassFirewall } from "@nodefony/framework";
 
-const SECRET = (process.env.NODEFONY_HOOK_SECRET ?? "").replace(/^whsec_/, "");
+const SECRET = (process.env.NF_HOOK_SECRET ?? "").replace(/^whsec_/, "");
 
 @controller("/hooks")
 class HookMiniController extends Controller {
@@ -308,7 +308,7 @@ import { Buffer } from "node:buffer";
 import { Controller, controller, Post, Body, Headers, BypassFirewall } from "@nodefony/framework";
 
 /** Secret `whsec_…` donné par l'émetteur — via l'environnement, jamais en dur. */
-const SECRET = process.env.NODEFONY_HOOK_SECRET ?? "";
+const SECRET = process.env.NF_HOOK_SECRET ?? "";
 /** Fenêtre anti-rejeu (s) : un message plus vieux est refusé. */
 const TOLERANCE_S = 300;
 
@@ -705,7 +705,7 @@ sont `unref()` (`webhooks.ts:222`), donc ils n'empêchent jamais Node de sortir.
 
 ## ⚙️ Configuration
 
-Section `webhooks` du schéma Zod (`webhooksSchema`, `security/nodefony/config/config.ts:783`), lue via
+Section `webhooks` du schéma Zod (`webhooksSchema`, `security/nodefony/config/config.ts:870`), lue via
 `use("@nodefony/security", { webhooks: … })`.
 
 | Option                 | Type       | Défaut     | Effet                                                                                                       |
@@ -956,21 +956,21 @@ secret, et sait **simuler des pannes** pour observer retries et auto-désactivat
 
 ## ⚠️ Pièges (symptôme → cause → correction)
 
-| Symptôme                                                | Cause (dans le code)                                                                                            | Correction                                                                   |
-| ------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------- |
-| Boot : « webhooks désactivés » en production            | Aucune `encryptionKey` — fail-safe (`webhooks.ts:299`)                                                          | `npx nodefony security:secrets` puis câbler `NF_WEBHOOK_KEY`                 |
-| Après redémarrage, les signatures ne valident plus      | Clé **éphémère** de dev : les secrets stockés sont illisibles                                                   | Poser une `encryptionKey` stable ; tourner les secrets des endpoints         |
-| `422` à la création d'un endpoint                       | `assertPublicUrl()` refuse la cible (IP interne, schéma, userinfo)                                              | Viser une URL publique en `https://` ; en dev, `denyPrivateIps: false`       |
-| Rien n'arrive alors que l'endpoint est actif            | Aucun `auditService` → dispatcher inactif (`webhooks.ts:191`)                                                   | Vérifier que l'audit est activé ; le CRUD seul ne livre rien                 |
-| Un événement « métier » n'arrive jamais                 | La source est le **journal d'audit**, pas un bus applicatif                                                     | S'abonner à une action d'audit existante                                     |
-| Signature invalide côté récepteur                       | Corps re-sérialisé avant le HMAC, ou en-tête `webhook-id`/`-timestamp` ignoré                                   | Lire le corps **brut** ; signer `{id}.{timestamp}.{body}`                    |
-| Le récepteur voit deux fois le même événement           | Un retry rejoue le **même** `webhook-id`                                                                        | Dédupliquer par `webhook-id` côté récepteur                                  |
-| Endpoint passé `enabled: false` tout seul               | 20 échecs consécutifs → auto-désactivation (`webhooks.ts:565`)                                                  | Réparer la destination, puis `PATCH … {"enabled":true}`                      |
-| Livraisons « abandonnées » dans les logs                | File pleine (`maxQueue`) — best-effort assumé                                                                   | Augmenter `maxQueue`/`maxConcurrent`, ou réduire le volume souscrit          |
-| Un `302` vers l'interne n'est pas suivi                 | **Voulu** : `node:http(s)` ne suit jamais les 3xx                                                               | Rien à corriger — configurer l'URL finale côté destinataire                  |
-| Le secret a été perdu                                   | Il n'est montré qu'à la création/rotation                                                                       | `POST …/reveal` (audité) ou rotation + redéploiement chez le tiers           |
-| Après un redémarrage, plus aucun endpoint               | `store: "memory"` — registre volatil et par pod                                                                 | Déclarer une infra durable (`store: "auto"` suffit alors)                    |
-| Multi-pod : un endpoint créé ne livre que depuis un pod | Le snapshot n'est chargé qu'au boot (`webhooks.ts:325`) ; les pods qui n'ont pas vu l'écriture gardent l'ancien | Redémarrage tournant après une mutation, ou router l'admin sur tous les pods |
+| Symptôme                                                                       | Cause (dans le code)                                                                                       | Correction                                                             |
+| ------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------- |
+| Boot : « webhooks désactivés » en production                                   | Aucune `encryptionKey` — fail-safe (`webhooks.ts:299`)                                                     | `npx nodefony security:secrets` puis câbler `NF_WEBHOOK_KEY`           |
+| Après redémarrage, les signatures ne valident plus                             | Clé **éphémère** de dev : les secrets stockés sont illisibles                                              | Poser une `encryptionKey` stable ; tourner les secrets des endpoints   |
+| `422` à la création d'un endpoint                                              | `assertPublicUrl()` refuse la cible (IP interne, schéma, userinfo)                                         | Viser une URL publique en `https://` ; en dev, `denyPrivateIps: false` |
+| Rien n'arrive alors que l'endpoint est actif                                   | Aucun `auditService` → dispatcher inactif (`webhooks.ts:191`)                                              | Vérifier que l'audit est activé ; le CRUD seul ne livre rien           |
+| Un événement « métier » n'arrive jamais                                        | La source est le **journal d'audit**, pas un bus applicatif                                                | S'abonner à une action d'audit existante                               |
+| Signature invalide côté récepteur                                              | Corps re-sérialisé avant le HMAC, ou en-tête `webhook-id`/`-timestamp` ignoré                              | Lire le corps **brut** ; signer `{id}.{timestamp}.{body}`              |
+| Le récepteur voit deux fois le même événement                                  | Un retry rejoue le **même** `webhook-id`                                                                   | Dédupliquer par `webhook-id` côté récepteur                            |
+| Endpoint passé `enabled: false` tout seul                                      | 20 échecs consécutifs → auto-désactivation (`webhooks.ts:565`)                                             | Réparer la destination, puis `PATCH … {"enabled":true}`                |
+| Livraisons « abandonnées » dans les logs                                       | File pleine (`maxQueue`) — best-effort assumé                                                              | Augmenter `maxQueue`/`maxConcurrent`, ou réduire le volume souscrit    |
+| Un `302` vers l'interne n'est pas suivi                                        | **Voulu** : `node:http(s)` ne suit jamais les 3xx                                                          | Rien à corriger — configurer l'URL finale côté destinataire            |
+| Le secret a été perdu                                                          | Il n'est montré qu'à la création/rotation                                                                  | `POST …/reveal` (audité) ou rotation + redéploiement chez le tiers     |
+| Après un redémarrage, plus aucun endpoint                                      | `store: "memory"` — registre volatil et par pod                                                            | Déclarer une infra durable (`store: "auto"` suffit alors)              |
+| Multi-pod : un endpoint créé ne livre pas tout de suite depuis les autres pods | Le snapshot est relu après `webhooks.snapshotTtlS` (30 s par défaut, `webhooks.ts:406`), pas immédiatement | Attendre au plus `snapshotTtlS`, ou le baisser                         |
 
 ## 🧪 Tests & couverture
 
@@ -983,7 +983,7 @@ depuis vitest, jamais figés ici :
   historique, bornes de perf, arrêt) ; `webhookSignature` (vecteur officiel Standard Webhooks,
   altération du corps/id/timestamp) ; `webhookDelivery` (pin d'IP, non-suivi des 3xx, timeout,
   politique de protocole, capture du corps de réponse) ; `webhookStore` (CRUD mémoire + copie
-  défensive) ; `webhookAdminApi` (les 8 endpoints, rôles, `400`/`404`/`422`/`503`, audit des
+  défensive) ; `webhookAdminApi` (les 9 endpoints, rôles, `400`/`404`/`422`/`503`, audit des
   mutations) ; `webhookPagination` (harnais du banc de contrat sur le store mémoire).
 - **attaque (red-team)** — `webhookSsrf.attack.test.ts` : matrice threat-first dérivée d'OWASP SSRF
   et de CAPEC-664 (IPv4-mapped IPv6 sous 7 notations, confusion `userinfo`, IP encodée