PD-240 — Plan d'implémentation¶

1. Références¶

• Spec : PD-240-specification.md (v3)
• Tests : PD-240-tests.md (v3)
• Verdict Gate 3 : GO v3

2. Découpage en composants¶

2.1 Composants à créer¶

2.2 Composants existants à modifier¶

3. Flux de traitement¶

3.1 Flux nominal (F-240-01)¶

Client                 Controller           Service              External
  |                        |                    |                    |
  |-- DELETE /user/account |                    |                    |
  |   + JWT                |                    |                    |
  |   + X-Reauth-Token     |                    |                    |
  |   + body: {confirm}    |                    |                    |
  |                        |                    |                    |
  |                        |-- validateJWT() ---|                    |
  |                        |-- validateReauth() |                    |
  |                        |-- validateConfirm()|                    |
  |                        |                    |                    |
  |                        |-- deleteAccount() ----------------->   |
  |                        |                    |                    |
  |                        |                    |-- invalidateSessions()
  |                        |                    |   |                |
  |                        |                    |   |-- Redis.del() -|
  |                        |                    |                    |
  |                        |                    |-- purgeUserData() -|
  |                        |                    |   |                |
  |                        |                    |   |-- PostgreSQL   |
  |                        |                    |                    |
  |                        |                    |-- deleteKeycloakUser()
  |                        |                    |   |                |
  |                        |                    |   |-- Keycloak API |
  |                        |                    |                    |
  |<-- 200 OK -------------|                    |                    |

3.2 Ordre transactionnel¶

1. Validation (pré-conditions)
2. JWT valide (JwtAuthGuard)
3. Reauth token valide (ReauthMiddleware)

4. Confirmation renforcée valide (confirm === "DELETE_MY_ACCOUNT")

5. Invalidation sessions (point de non-retour si succès)

6. Supprimer toutes les clés Redis session:{userId}:*

7. Si échec → rollback, retourner ERR-240-SESSION-INVALIDATION-FAILED

8. Purge RGPD

9. Anonymiser table users (email, name)
10. Purger tables liées (à définir selon schéma)
11. Créer entrée audit { status: "purged", purgedAt }

12. Si échec → ERR-240-DELETE-FAILED (sessions déjà invalidées, compte non supprimé)

13. Suppression Keycloak

14. Appeler DELETE /admin/realms/{realm}/users/{keycloakId}

15. Si échec → ERR-240-DELETE-FAILED

16. Réponse succès

17. Retourner 200 OK avec body vide ou { success: true }

4. Diagrammes Mermaid¶

4.1 Graphe de dépendances des composants¶

graph TD
    subgraph "Couche HTTP"
        DAC[DeleteAccountController]
        AC[AuditController]
    end

    subgraph "Guards & Middleware"
        JAG[JwtAuthGuard]
        RAM[ReauthMiddleware<br/><i>PD-238</i>]
    end

    subgraph "Couche Services"
        DAS[DeleteAccountService]
        SIS[SessionInvalidationService]
        UDPS[UserDataPurgeService]
        KUS[KeycloakUserService]
    end

    subgraph "Externes"
        Redis[(Redis)]
        PG[(PostgreSQL)]
        KC[Keycloak API]
    end

    DAC -->|"protège"| JAG
    DAC -->|"protège"| RAM
    DAC -->|"appelle"| DAS

    AC -->|"protège"| JAG

    DAS -->|"1. invalidate"| SIS
    DAS -->|"2. purge"| UDPS
    DAS -->|"3. delete"| KUS

    SIS -->|"DEL session:userId:*"| Redis
    UDPS -->|"anonymise + audit"| PG
    KUS -->|"DELETE /users/keycloakId"| KC
    AC -->|"SELECT audit"| PG

4.2 Diagramme de séquence — Flux nominal (F-240-01)¶

sequenceDiagram
    actor Client
    participant Ctrl as DeleteAccountController
    participant Guard as JwtAuthGuard
    participant Reauth as ReauthMiddleware<br/>(PD-238)
    participant Svc as DeleteAccountService
    participant Session as SessionInvalidationService
    participant Purge as UserDataPurgeService
    participant KC as KeycloakUserService
    participant Redis as Redis
    participant PG as PostgreSQL
    participant KCApi as Keycloak API

    Client->>Ctrl: DELETE /user/account<br/>JWT + X-Reauth-Token<br/>body: {confirm}
    Ctrl->>Guard: validateJWT()
    Guard-->>Ctrl: userId
    Ctrl->>Reauth: validateReauth()
    Reauth-->>Ctrl: OK
    Ctrl->>Ctrl: validateConfirm("DELETE_MY_ACCOUNT")

    Ctrl->>Svc: deleteAccount(userId)
    activate Svc

    Svc->>Session: invalidateSessions(userId)
    activate Session
    Session->>Redis: DEL session:{userId}:*
    Redis-->>Session: OK
    Session-->>Svc: sessions invalidées
    deactivate Session

    Svc->>Purge: purgeUserData(userId)
    activate Purge
    Purge->>PG: UPDATE users SET email=anon, name=anon
    Purge->>PG: INSERT audit_log (status: purged)
    PG-->>Purge: OK
    Purge-->>Svc: données purgées
    deactivate Purge

    Svc->>KC: deleteKeycloakUser(keycloakId)
    activate KC
    KC->>KCApi: DELETE /admin/realms/{realm}/users/{id}
    KCApi-->>KC: 204 No Content
    KC-->>Svc: OK
    deactivate KC

    deactivate Svc
    Ctrl-->>Client: 200 OK

4.3 Diagramme de séquence — Échec purge après invalidation sessions¶

sequenceDiagram
    actor Client
    participant Ctrl as DeleteAccountController
    participant Svc as DeleteAccountService
    participant Session as SessionInvalidationService
    participant Purge as UserDataPurgeService
    participant Redis as Redis
    participant PG as PostgreSQL

    Client->>Ctrl: DELETE /user/account
    Ctrl->>Svc: deleteAccount(userId)

    Svc->>Session: invalidateSessions(userId)
    Session->>Redis: DEL session:{userId}:*
    Redis-->>Session: OK
    Session-->>Svc: sessions invalidées

    Svc->>Purge: purgeUserData(userId)
    Purge->>PG: UPDATE users ...
    PG-->>Purge: ERROR (constraint violation)
    Purge-->>Svc: échec

    Note over Svc: État dégradé :<br/>sessions mortes,<br/>Keycloak intact.<br/>Audit log + job réconciliation.

    Svc-->>Ctrl: ERR-240-DELETE-FAILED
    Ctrl-->>Client: 500 Internal Server Error

5. Mapping Invariants → Mécanismes¶

6. Mapping Critères d'acceptation → Tests¶

7. Gestion des erreurs¶

8. Sécurité¶

8.1 Contrôles d'accès¶

• Route protégée par JwtAuthGuard (authentification)
• ReauthMiddleware exige une re-authentification récente (< 5 min)
• Confirmation explicite empêche suppression accidentelle

8.2 Données sensibles¶

• Les tokens JWT ne sont jamais loggés
• Les données purgées sont anonymisées, pas supprimées (audit trail)
• L'endpoint admin est protégé par rôle ADMIN

8.3 Atomicité¶

• L'ordre (sessions → purge → Keycloak) garantit qu'aucune session ne survit à une suppression réussie
• Si échec sessions → rollback complet
• Si échec purge/Keycloak après invalidation sessions → compte verrouillé (sessions mortes, Keycloak intact) — état dégradé acceptable

9. Hypothèses techniques¶

10. Points de vigilance¶

1. Rollback limité : Si la purge RGPD échoue après invalidation des sessions, le compte est dans un état "limbo" (sessions mortes mais Keycloak actif). Mitigation : logs d'audit + job de réconciliation.

2. Performance : La purge RGPD peut impacter plusieurs tables. Considérer une exécution asynchrone pour les tables volumineuses, mais garantir l'atomicité sur les tables critiques.

3. Keycloak latence : La suppression Keycloak est synchrone. S'assurer du timeout approprié.

11. Livrables¶