PD-241 — Rapport de confrontation (Étape 5)¶

Ce rapport est produit par l'orchestrateur Claude avant la gate PMO AMBIGUITY. Il confronte le plan d'implémentation avec la spécification et les tests.

1. Sources confrontées¶

PD-241-specification.md — Spécification canonique
PD-241-tests.md — Scénarios de tests contractuels
PD-241-plan.md — Plan d'implémentation (Claude)
PD-241-code-contracts.yaml — Code contracts
PD-241-plan-review.md — Review ChatGPT

2. Convergences¶

CVG-01 : Mapping invariants → mécanismes complet (INV-241-01 à INV-241-05 couverts)
CVG-02 : Mapping critères → tests complet (CA-241-01 à CA-241-05 couverts)
CVG-03 : Découpage en composants cohérent avec l'architecture existante (AuthController, AuthService, KeycloakAdminService)
CVG-04 : Erreurs typées avec format {error, message} conforme à INV-241-04
CVG-05 : Code contracts couvrent tous les modules du plan
CVG-06 : Réutilisation du circuit breaker existant cohérente avec les patterns établis

3. Divergences¶

Les conflits ne doivent JAMAIS être lissés. Chaque divergence est rendue visible.

DIV-01 (BLOQUANT) : @HttpCode(401) sur le contrôleur
Source A (Plan §2.1) : "Décorateur @HttpCode(401) pour ERR-241-UNAUTHENTICATED"
Source B (Spec §5) : Flux nominal retourne "succès explicite"
Analyse Claude : Le décorateur @HttpCode définit le statut par défaut de la route. Si @HttpCode(401) est utilisé, TOUTES les réponses auraient 401, y compris le succès. C'est manifestement une erreur de rédaction dans le plan.
Correction évidente : Le plan aurait dû dire "@HttpCode(200) pour succès" et "401 via exception pour ERR-241-UNAUTHENTICATED"
Impact : Erreur de rédaction, pas de divergence fonctionnelle réelle
DIV-02 (BLOQUANT) : Comportement si revokeRefreshToken échoue
Source A (Plan §8) : "Si invalidateSession réussit mais revokeRefreshToken échoue, le logout est considéré comme réussi"
Source B (Spec INV-241-03) : "Le refresh token DOIT être invalidé s'il est présent"
Analyse Claude : Le plan introduit une interprétation non conforme à la spec. Si le refresh token est présent et que son invalidation échoue, le logout DOIT échouer (ERR-241-LOGOUT-FAILED).
Impact : Violation d'invariant contractuel. Nécessite correction.
DIV-03 (Mineur) : Affirmation d'idempotence non contractuelle
Source A (Plan §8) : "Le logout est idempotent par nature"
Source B (Spec) : Aucune mention d'idempotence
Analyse Claude : L'idempotence est une propriété technique raisonnable mais non contractuelle. Peut être accepté comme hypothèse technique.
Impact : Pas de divergence fonctionnelle, mais hypothèse à documenter explicitement.
DIV-04 (Majeur) : Contrainte timeout 5s non dérivée de la spec
Source A (Code contracts) : "Timeout supérieur à 5s interdit"
Source B (Spec) : Aucune contrainte de timeout
Analyse Claude : Cette contrainte vient des patterns existants (KeycloakAdminService) et est une bonne pratique. Peut être accepté comme contrainte d'implémentation (non contractuelle).
Impact : Pas de divergence fonctionnelle, mais à documenter comme contrainte technique.

4. Zones d'ombre¶

ZO-01 : Format exact de la réponse succès (spec dit "succès explicite" mais pas le format JSON, plan dit { success: true })
ZO-02 : Comportement si le refresh token est absent du body mais présent côté Keycloak

5. Analyse des écarts BLOQUANTS¶

DIV-01 — Erreur de rédaction @HttpCode¶

Contexte : Dans NestJS, @HttpCode(401) définirait le statut par défaut pour TOUTES les réponses de la route. Le plan mentionne à la fois @HttpCode(200) pour succès et @HttpCode(401) pour erreur, ce qui est impossible sur une seule route.

Réalité technique : Le plan décrit correctement le comportement attendu (200 en succès, 401 en erreur), mais la formulation est incorrecte. En pratique : - @HttpCode(200) sur la route pour le succès - UnauthorizedException levée par JwtAuthGuard → 401 automatiquement

Verdict : Erreur de rédaction dans le plan, pas de divergence fonctionnelle. Correction mineure requise.

DIV-02 — Comportement échec revokeRefreshToken¶

Contexte : Le plan dit que si invalidateSession réussit mais revokeRefreshToken échoue, le logout est réussi.

Analyse de la spec : - INV-241-03 : "Le refresh token DOIT être invalidé s'il est présent" - Le verbe "DOIT" indique une obligation contractuelle

Verdict : Divergence réelle. Si le refresh token est présent et que son invalidation échoue, le logout DOIT retourner ERR-241-LOGOUT-FAILED. Le plan doit être corrigé.

6. Recommandation¶

Procéder — convergence confirmée, aucun conflit bloquant
Rework nécessaire — divergences à résoudre avant de continuer
DIV-01 : Corriger la formulation @HttpCode dans le plan (mineure)
DIV-02 : Corriger le comportement si revokeRefreshToken échoue (majeure)
Escalade — décision humaine requise sur un point structurant

Généré par Claude Orchestrateur — 2026-02-07