PD-239 — Confrontation Step 5 (v2)¶
1. Objectif¶
Analyser les écarts identifiés dans la review v2 du plan d'implémentation et les confronter aux documents sources.
2. Documents confrontés¶
- PD-239-specification.md (v2)
- PD-239-tests.md (v2)
- PD-239-plan.md (v2 corrigé)
- PD-239-code-contracts.yaml (v2 corrigé)
- PD-239-plan-review-v2.md
3. Vérification des corrections v1¶
| Écart v1 | Statut review v2 | Verdict |
|---|---|---|
ECT-S5-01/02 (format error) | ✅ Conforme | Correction effective |
| ECT-S5-05 (oldPassword SRP) | ✅ Conforme | Correction effective |
| ECT-S5-03 (rate limiting) | ✅ Conforme | Correction effective |
| ECT-S5-06 (injection Keycloak) | ⚠️ Partiellement | Voir ECT-S5-V2-04 |
Conclusion : Les 3 écarts BLOQUANTS/MAJEURS v1 ont été corrigés avec succès.
4. Analyse des nouveaux écarts v2¶
ECT-S5-V2-01 — Couverture INV-239-10/CA-239-09 (MAJEUR)¶
Constat review : La couverture du log event=keycloak_password_change n'est pas démontrée.
Confrontation : - Tests §2 Matrice de couverture : INV-239-10 | CA-239-09 | T-239-INV-01 | Oui | Log keycloak_password_change - Tests §3 T-239-INV-01 : "THEN Une trace de log structurée contient event=keycloak_password_change et userId=<sub>."
Verdict : ❌ NON CONFIRMÉ
Le test T-239-INV-01 existe explicitement dans PD-239-tests.md et couvre INV-239-10 et CA-239-09. La matrice de couverture le confirme. La mention "identique v1" dans le prompt v2 était une simplification pour éviter de répéter le document complet, mais le contenu réel des tests v2 inclut bien T-239-INV-01.
Impact : Aucun. L'écart n'existe pas.
ECT-S5-V2-02 — Délai ≤30s non testé (MAJEUR)¶
Constat review : Les tests ne vérifient pas explicitement le délai de 30 secondes pour INV-239-05.
Confrontation : - Spec §4 INV-239-05 : "dans un délai de 30 secondes maximum" - Plan §10 H-IMPL-03 : "SessionRevocationStore synchrone (< 30s)" - Tests T-239-NOM-01 : "Toute session/token précédent de U1 est invalidé (refus d'un token antérieur)"
Verdict : ⚠️ PARTIELLEMENT CONFIRMÉ (déjà traité en v1)
Cet écart a été analysé en v1 (ECT-S5-04) et reclassé : 1. Le test fonctionnel T-239-NOM-01 vérifie l'invalidation effective. 2. L'architecture synchrone de SessionRevocationStore garantit le délai. 3. L'hypothèse H-IMPL-03 documente cette garantie architecturale. 4. La SLA 30s est une propriété opérationnelle vérifiable via monitoring, pas un critère de test e2e.
Impact : Couvert par garantie architecturale + hypothèse explicite. Non bloquant.
ECT-S5-V2-03 — Code Contract DTO @Exclude() hors spec (MAJEUR)¶
Constat review : L'invariant @Exclude() sur oldPassword et newPassword n'est pas dans la spec.
Confrontation : - Spec §4 : Aucune mention explicite de @Exclude() ou sérialisation DTO. - Code contract password-change-dto : "@Exclude() sur oldPassword et newPassword" - Plan §9.3 Non-divulgation : "Ancien et nouveau mot de passe exclus des logs (@Exclude)"
Verdict : ⚠️ PARTIELLEMENT CONFIRMÉ mais non bloquant
L'invariant @Exclude() est une mesure de sécurité par défaut qui découle implicitement de : - L'exigence de non-divulgation (plan §9.3) - Les bonnes pratiques OWASP (ne jamais exposer les mots de passe dans les réponses/logs) - La section "forbidden" du code contract : "Exposer les mots de passe dans la sérialisation"
Ce n'est pas un ajout de règle métier mais une contrainte de sécurité d'implémentation. Les code contracts définissent les frontières de code, pas les exigences métier.
Impact : Aucun écart contractuel. Mesure de sécurité implicite justifiée.
Recommandation : Pour clarté, ajouter une note dans le code contract indiquant que c'est une mesure de sécurité standard.
ECT-S5-V2-04 — Test T-239-ERR-08 non déterministe (MAJEUR)¶
Constat review : Le mécanisme d'injection d'erreurs Keycloak n'est pas spécifié comme obligatoire dans le plan.
Confrontation : - Tests T-239-ERR-08 : "Une erreur Keycloak déterministe est injectée (400, 401/403, 404, 5xx)" - Code contract password-change-tests-e2e v2 : "T-239-ERR-08: Injecter erreurs Keycloak via mock service ou test containers" - Code contract password-change-tests-unit : "Mocker Keycloak et SessionRevocationStore"
Verdict : ✅ CONFIRMÉ (résiduel de ECT-S5-06)
L'écart est réel mais MINEUR, pas MAJEUR : 1. Le code contract tests-e2e mentionne désormais le mécanisme d'injection. 2. Le code contract tests-unit prévoit le mocking. 3. C'est un détail d'implémentation des tests, pas une exigence architecturale.
Impact : Mineur. Le mécanisme est documenté dans les code contracts. L'implémentation déterminera le choix technique (mock service, testcontainers, etc.).
5. Synthèse de la confrontation v2¶
| ID | Écart review v2 | Gravité review | Verdict confrontation | Reclassement |
|---|---|---|---|---|
| ECT-S5-V2-01 | Couverture INV-239-10 | MAJEUR | ❌ NON CONFIRMÉ | Test T-239-INV-01 existe |
| ECT-S5-V2-02 | Délai ≤30s | MAJEUR | ⚠️ PARTIELLEMENT | Couvert par H-IMPL-03 |
| ECT-S5-V2-03 | DTO @Exclude() | MAJEUR | ⚠️ PARTIELLEMENT | Mesure sécurité implicite |
| ECT-S5-V2-04 | Injection Keycloak | MAJEUR | ✅ CONFIRMÉ | Reclassé MINEUR |
6. Écarts résiduels¶
Aucun écart BLOQUANT¶
Aucun écart MAJEUR après reclassement¶
Écarts MINEURS acceptables¶
| ID | Description | Statut |
|---|---|---|
| ECT-S5-V2-04 | Mécanisme injection Keycloak documenté dans code contract, choix technique à l'implémentation | Acceptable |
7. Recommandation PMO¶
Verdict suggéré : GO
Motif : 1. Les corrections v1 sont effectives (ECT-S5-01/02/05/03 résolus). 2. Les écarts v2 sont soit non confirmés (ECT-S5-V2-01), soit reclassés comme non bloquants. 3. Le plan et les code contracts sont alignés avec la spécification. 4. Les tests couvrent tous les invariants contractuels.
Réserve mineure : ECT-S5-V2-04 (mécanisme injection) à finaliser lors de l'implémentation des tests e2e.