PD-240 — Rétrospective¶

1. Contexte¶

2. Métriques¶

3. Learnings clés¶

• Fail-open Redis documenté : Les protections Redis (blacklist, rate limit) dégradent gracieusement si Redis est indisponible. Compromis de disponibilité accepté.

• Purge RGPD transactionnelle : La purge doit couvrir toutes les tables liées à l'utilisateur (user, device_trust, key_envelopes), pas seulement la table principale.

• One-time token via Redis blacklist : SHA-256 du token comme clé Redis, TTL = durée de vie du token.

• Buffer.alloc(0) pour bytea NOT NULL : Permet d'anonymiser des champs bytea sans violer la contrainte NOT NULL.

4. Patterns applicables¶

Pattern existant : Fail-closed par défaut¶

Malgré le fail-open documenté, la règle générale reste fail-closed.

Nouveau pattern : Purge RGPD multi-tables¶

await this.dataSource.transaction(async (manager) => {
  await manager.delete(KeyEnvelope, { userId });
  await manager.delete(DeviceTrust, { userId });
  await manager.update(User, { id: userId }, {
    email: anonymizedEmail,
    srpVerifier: Buffer.alloc(0), // Empêche toute authentification
    deletedAt: new Date(),
  });
});

Nouveau pattern : Registre RGPD centralisé¶

Maintenir une liste des tables à purger :

# rgpd-registry.yaml
user_tables:
  - table: user
    action: anonymize
  - table: device_trust
    action: delete
  - table: key_envelopes
    action: delete

5. Signal CLAUDE.md¶

Priorité haute : Documenter le pattern de purge RGPD.

### Purge RGPD — Multi-tables obligatoire (2026-02-XX)

Avant d'implémenter une purge RGPD Article 17 :
1. Lister exhaustivement les tables avec FK vers userId
2. Définir l'action par table (delete vs anonymize)
3. Exécuter dans une transaction atomique
4. Vérifier que l'anonymisation empêche toute réidentification

**Registre** : `docs/rgpd/tables-registry.yaml`

6. Conclusion¶

PD-240 a livré la suppression de compte avec purge RGPD multi-tables. Les zones d'ombre Gate 8 v2 ont exigé une analyse code source pour clarifier les comportements fail-open. Le pattern de purge RGPD transactionnelle est critique et doit être appliqué à toutes les données utilisateur.

Rétrospective générée 2026-02-19 (Étape 10 batch auth-identity)