PD-240 — Retour d'expérience (REX)¶

Story : PD-240 — Suppression de compte utilisateur Date : 2026-02-07 Auteur : Claude (Opus 4.5)

1. Résumé exécutif¶

Verdict final : GO avec réserves techniques documentées.

2. Objectifs vs. Réalisé¶

3. Difficultés rencontrées¶

3.1 Gate 8 v1 : NON_CONFORME¶

Cause : 4 écarts bloquants identifiés par les reviews ChatGPT : 1. ECT-240-02 : Purge RGPD limitée à la table User (device_trust, key_envelopes non purgées) 2. ECT-240-04 : Tests E2E n'injectaient pas d'erreurs déterministes pour ERR-240-DELETE-FAILED 3. ECT-240-06 : Reauth token réutilisable (pas de one-time token) 4. ECT-240-07 : Absence de rate limiting sur l'endpoint critique

Impact : Boucle de correction + cycle d'acceptabilité v2 complet.

3.2 Zones d'ombre Gate 8 v2¶

Cause : Le PMO a exigé la résolution des 3 zones d'ombre avant GO : - ZO-01 : Monitoring Redis - ZO-02 : X-Forwarded-For - ZO-03 : Contraintes DB

Résolution : Analyse code source pour clarifier chaque point (patterns existants, comportement intentionnel).

4. Enseignements techniques¶

4.1 Pattern fail-open Redis¶

Constat : Les protections Redis (blacklist, rate limit) dégradent gracieusement si Redis est indisponible.

Décision : Compromis de disponibilité accepté. L'alternative (fail-closed) bloquerait l'endpoint en cas de panne Redis.

Règle : Pour les endpoints critiques dépendant de Redis, documenter explicitement le comportement fail-open/fail-closed.

4.2 Purge RGPD transactionnelle¶

Constat : La purge doit couvrir toutes les tables liées à l'utilisateur, pas seulement la table principale.

Tables identifiées : user, device_trust, key_envelopes.

Règle : Avant d'implémenter une purge RGPD, lister exhaustivement les tables avec FK vers userId.

4.3 One-time token via Redis blacklist¶

Constat : L'invalidation d'un token JWT après usage nécessite un état serveur (blacklist).

Implémentation : SHA-256 du token comme clé Redis, TTL = durée de vie du token.

Règle : Pour les tokens one-time, utiliser une blacklist Redis avec TTL aligné sur l'expiration du token.

4.4 Buffer.alloc(0) pour champs bytea NOT NULL¶

Constat : Mettre un champ bytea à "vide" sans violer NOT NULL est possible avec Buffer.alloc(0).

Comportement : Un verifier SRP vide empêche toute authentification (design intentionnel).

Règle : Pour anonymiser des champs bytea NOT NULL, utiliser Buffer.alloc(0) plutôt que null.

5. Enseignements processus¶

5.1 Reviews LLM après corrections¶

Constat : La règle de validation croisée impose des reviews ChatGPT même après corrections Claude.

Bénéfice : Les reviews v2 ont identifié des points résiduels (fail-open) que Claude n'avait pas documentés.

Règle : Toujours exécuter les 3 reviews LLM (code, tests, sécurité) après toute modification significative.

5.2 Résolution des zones d'ombre¶

Constat : Le PMO peut exiger zéro zone d'ombre avant GO.

Méthode : Analyse du code source pour clarifier chaque point avec références précises (fichier:ligne).

Règle : Anticiper les zones d'ombre en documentant les choix techniques dès l'implémentation.

6. Dette technique acceptée¶

7. Recommandations futures¶

8. Métriques de qualité¶

9. Artefacts produits¶

Document généré le 2026-02-07 Orchestrateur : Claude (Opus 4.5)