PD-240 — Confrontation (Étape 5 v1)¶

Gate AMBIGUITY — Review du plan d'implémentation

Documents confrontés¶

1. Convergences¶

2. Divergences¶

DIV-01 — Incohérence interne à la spec (endpoint admin)¶

Constat :

La spec contient une incohérence interne entre deux sections :

• §4 Périmètre : DELETE /admin/users/{userId}/audit
• INV-240-05 : GET /admin/audit/user/{userId}

Différences : 1. Méthode HTTP : DELETE vs GET 2. Path : /admin/users/{userId}/audit vs /admin/audit/user/{userId}

Impact : Le plan et les code contracts suivent INV-240-05 (GET), ce qui est cohérent avec l'observable défini. Le périmètre semble contenir une erreur de rédaction.

Verdict partiel : L'écart identifié par ChatGPT est dû à une incohérence dans la spec, pas à une non-conformité du plan. La spec doit être corrigée pour aligner §4 sur INV-240-05.

DIV-02 — purgedAt optionnel vs obligatoire¶

Constat :

• Spec INV-240-05 : { "status": "purged", "purgedAt": "<ISO8601>" } — purgedAt présent dans la réponse type
• Code Contract audit-controller : { status: 'purged' | 'active', purgedAt?: ISO8601 } — purgedAt optionnel (?)
• Test T-240-POST-02 : attend { "status": "purged", "purgedAt": "<ISO8601>" } — purgedAt requis

Impact : Le code contract autorise une réponse sans purgedAt, ce qui ferait échouer le test T-240-POST-02.

Verdict partiel : Le code contract doit être aligné — purgedAt obligatoire quand status="purged".

DIV-03 — État dégradé post-invalidation sessions¶

Constat :

• Spec §8 : Si invalidation sessions échoue → ERR-240-SESSION-INVALIDATION-FAILED (rollback complet)
• Plan §7.3 : "Si échec purge/Keycloak après invalidation sessions → compte verrouillé (sessions mortes, Keycloak intact) — état dégradé acceptable"
• Plan §9 : Mitigation proposée (logs d'audit + job de réconciliation)

Le plan introduit un état "limbo" non spécifié pour le cas où la purge ou Keycloak échoue APRÈS l'invalidation des sessions.

Analyse :

La spec définit : - ERR-240-SESSION-INVALIDATION-FAILED → aucune suppression (rollback) - ERR-240-DELETE-FAILED → "compte non supprimé" mais ne précise pas l'état des sessions

Le plan fait une distinction pragmatique : 1. Échec sessions → rollback complet (conforme) 2. Échec purge/Keycloak après sessions → état dégradé (non spécifié mais sécuritaire)

Impact : L'état dégradé n'est pas une violation de sécurité (sessions mortes = utilisateur déconnecté), mais il n'est pas contractualisé.

Verdict partiel : Divergence à clarifier. La spec doit explicitement définir le comportement en cas d'échec purge/Keycloak après invalidation réussie des sessions.

3. Zones d'ombre¶

ZO-01 — Comportement exact en cas d'échec purge/Keycloak¶

La spec ne définit pas explicitement ce qui se passe si : 1. Les sessions sont invalidées avec succès 2. La purge RGPD ou la suppression Keycloak échoue

Questions : - Le compte reste-t-il actif dans Keycloak ? - Peut-on réessayer la suppression ? - Faut-il un mécanisme de réconciliation ?

ZO-02 — Contenu exact de la réponse succès¶

Le plan propose 200 OK avec { success: true } ou body vide. La spec ne contractualise pas le format de réponse succès.

4. Synthèse¶

5. Recommandation pré-verdict¶

DIV-01 est un écart dans la spec, pas dans le plan. La correction doit être apportée à PD-240-specification.md (§4 Périmètre).

DIV-02 et DIV-03 sont des écarts dans le plan/code contracts qui peuvent être corrigés par Claude.

Verdict recommandé : NON_CONFORME avec corrections ciblées sur : 1. Spec §4 : aligner endpoint sur GET /admin/audit/user/{userId} 2. Code contract audit-controller : purgedAt obligatoire si purged 3. Spec §8 ou Plan §7.3 : contractualiser l'état post-échec-purge