Aller au contenu

PD-239 — Dossier de Conformité Step 5 (v1)

1. Informations générales

Champ Valeur
User Story PD-239
Étape 5 — Review plan d'implémentation
Gate AMBIGUITY
Date 2026-02-07
Version v1

2. Documents analysés

Document Version Auteur
PD-239-specification.md v2 ChatGPT
PD-239-tests.md v2 ChatGPT
PD-239-plan.md v1 Claude
PD-239-code-contracts.yaml v1 Claude
PD-239-plan-review.md v1 ChatGPT
PD-239-confrontation-step5-v1.md v1 Claude

3. Résumé de la review (ChatGPT)

Verdict review : ⛔ Rejeté

Écarts identifiés : 6 (2 BLOQUANTS, 3 MAJEURS, 1 MINEUR)

# Type Gravité Résumé
1 Non-conformité Spec BLOQUANT Format erreur {code} vs {error}
2 Code Contract BLOQUANT Format code contract incompatible avec spec
3 Non-conformité Spec MAJEUR Rate limiting introduit sans spécification
4 Couverture manquante MAJEUR Observable ≤30s insuffisant
5 Hypothèse implicite MAJEUR Confusion ReauthService/verifyOldPassword
6 Incohérence Plan↔Tests MINEUR Injection erreurs Keycloak non détaillée

4. Résumé de la confrontation (Claude)

Analyse : 6 écarts confrontés aux documents sources.

ID Écart Verdict confrontation
ECT-S5-01 Format code vs error ✅ CONFIRMÉ — Non-conformité INV-239-06
ECT-S5-02 Code contract incompatible ✅ CONFIRMÉ — Doublon ECT-S5-01
ECT-S5-03 Rate limiting non spécifié ⚠️ PARTIELLEMENT — Recommandation acceptable
ECT-S5-04 Observable ≤30s ⚠️ PARTIELLEMENT — Architecture synchrone suffit
ECT-S5-05 Confusion ReauthService ✅ CONFIRMÉ — Ambiguïté à lever
ECT-S5-06 Injection Keycloak tests ✅ CONFIRMÉ — Mineur, détail d'implémentation

5. Écarts résiduels après confrontation

Écarts BLOQUANTS confirmés

ID Description Impact Correction requise
ECT-S5-01 Plan §8.3 utilise code au lieu de error exigé par INV-239-06 Incompatibilité client PD-106 Renommer codeerror
ECT-S5-02 Code contract password-change-filter reprend le format incorrect Incohérence contractuelle Aligner sur {error, message}

Écarts MAJEURS confirmés

ID Description Impact Correction requise
ECT-S5-05 Ambiguïté entre ReauthService.verifyPassword() et vérification oldPassword du payload Conformité INV-239-03 non démontrable Clarifier que oldPassword est vérifié via SRP verifier, pas via ReauthService

Écarts reclassés (non bloquants)

ID Description Reclassement Justification
ECT-S5-03 Rate limiting non spécifié Recommandation Mentionné comme "point de vigilance", pas exigence
ECT-S5-04 Observable ≤30s Note architecturale Test fonctionnel + hypothèse H-IMPL-03 couvrent
ECT-S5-06 Injection Keycloak Détail implémentation Standard testing, pas écart contractuel

6. Matrice de conformité

Invariant Couvert par plan Couvert par code contract Écart
INV-239-01 ✅ OidcJwtAuthGuard ✅ password-change-controller -
INV-239-02 ✅ ReauthTokenGuard ✅ reauth-token-guard -
INV-239-03 ⚠️ Ambiguïté ✅ password-change-service ECT-S5-05
INV-239-04 ✅ Keycloak validation ✅ keycloak-admin-extension -
INV-239-05 ✅ revokeAllUserSessions ✅ password-change-service -
INV-239-06 ❌ Format code ❌ Format code ECT-S5-01/02
INV-239-07 ✅ Message exploitable ✅ password-change-errors -
INV-239-08 ✅ Keycloak Admin API ✅ keycloak-admin-extension -
INV-239-09 ✅ Hors périmètre - -
INV-239-10 ✅ Log structuré ✅ keycloak-admin-extension -

7. Recommandation PMO

Verdict recommandé : NON_CONFORME

Justification

  1. 2 écarts BLOQUANTS (ECT-S5-01, ECT-S5-02) : Le format d'erreur {code, message} du plan et code contract viole INV-239-06 qui exige {error, message}. C'est une non-conformité contractuelle directe.

  2. 1 écart MAJEUR (ECT-S5-05) : L'ambiguïté sur la vérification de l'ancien mot de passe (ReauthService vs oldPassword payload) rend la conformité à INV-239-03 non démontrable.

Corrections ciblées

Les corrections sont localisées et peuvent être effectuées rapidement :

  1. Plan §8.3 : Remplacer "code": "ERR-239-*" par "error": "ERR-239-*"
  2. Code contract password-change-filter : Mettre à jour l'invariant format
  3. Plan §5 étape 4 : Clarifier que verifyOldPassword() utilise l'oldPassword du payload
  4. Plan §3.3 : Préciser que ReauthService n'est pas utilisé pour la vérification oldPassword

Alternative

Si le format enrichi avec code est intentionnel pour des raisons techniques NestJS, la spec doit être amendée pour autoriser {error|code, message}. Cela constituerait une escalade vers l'auteur de la spec (ChatGPT).


8. Prochaine étape

En attente du verdict PMO (Phase 4/4).

Options : - GO : Improbable vu les écarts BLOQUANTS - RESERVE : Possible si escalade sur format acceptée - NON_CONFORME : Recommandé — corrections ciblées puis re-soumission - ESCALADE : Si débat sur format d'erreur nécessite arbitrage