PD-106 — Confrontation Step 5¶

Date : 2026-02-04 Contexte : Gate AMBIGUITY — confrontation de la review plan d'implémentation (ChatGPT) avec les documents sources (spec v4, tests v4, plan, code contracts).

Analyse écart par écart¶

Écart 1 — Re-auth TTL client vs serveur (review : MAJEUR)¶

Review : Le plan gère le TTL 5 min côté client sans verrou contractuel d'alignement serveur.

Confrontation : - Le plan section 7.3 dit explicitement : "Le TTL est évalué côté client [...]. Le serveur re-vérifie au moment de l'opération critique." - Le plan section 9.1.2 identifie ce risque en point de vigilance. - La spec INV-106-05 dit : "cette borne temporelle est évaluée par le serveur".

Le plan n'est pas en contradiction avec la spec. Le TTL client est un garde-fou UX ; le serveur reste l'autorité. Le plan documente déjà ce double contrôle. Toutefois, l'absence d'une hypothèse technique (HT) explicite formulant "le TTL client est un garde-fou UX, le serveur fait autorité" est un manque de clarté.

Verdict : Déclassement → MINEUR (manque de formalisation HT, pas de non-conformité).

Écart 2 — Actions MFA bloquées non énumérées (review : MAJEUR)¶

Review : Le plan mentionne "actions MFA bloquées" sans lister lesquelles.

Confrontation : - Spec ERR-106-MFA-STATE-UNAVAILABLE (v4) : "bloquer l'activation MFA, la desactivation MFA et la consultation/regeneration des codes de recuperation" — énumération explicite. - Plan section 2.1 : "état 'inconnu', actions MFA bloquées" — sans énumération. - Plan section 6.2 : "État 'inconnu', actions MFA disabled" — idem.

L'énumération est présente dans la spec et le plan la référence. Mais pour un plan d'implémentation exécutable par une équipe tierce, la liste des actions bloquées devrait être reprise explicitement.

Verdict : Confirmé MINEUR (la spec est non ambiguë, le plan devrait la reprendre pour clarté d'implémentation).

Écart 3 — Tableaux de mapping non fournis (review : BLOQUANT)¶

Review : "Le plan fourni ne contient pas les tableaux complets de mapping invariants/critères/tests et observables annoncés."

Confrontation : - Le document PD-106-plan.md contient intégralement : - Section 3 : 18/18 invariants mappés avec mécanismes, composants, observables, risques. - Section 4 : 19/19 critères mappés avec mécanismes, composants, observables, risques. - Section 5 : 28 tests (TC-NOM-01→12, TC-ERR-01→15, TC-INV-01→03) mappés avec mécanismes, points d'observation, niveaux de test. - L'écart provient du prompt assemblé pour ChatGPT où les sections ¾/5 ont été abrégées avec "(voir tableau complet dans le document)" pour des raisons de taille. Le document source est complet.

Verdict : RÉSOLU — faux positif dû à l'abréviation du prompt. Les tableaux sont complets dans le document.

Écart 4 — Re-auth restreinte au mot de passe (review : MAJEUR)¶

Review : Le plan restreint la re-auth au mot de passe sans aligner avec la politique serveur.

Confrontation : - Spec section 10, point à clarifier #3 : "Politique de re-authentification par opération critique (facteurs autorisés)" — non résolu dans la spec. - Spec section 3 (définition Re-authentification) : "preuve récente d'identité acceptée par la politique serveur" — laisse ouvert le facteur. - Plan HT-106-07 : "Le backend expose POST /auth/reauth avec {password}" — hypothèse explicite. - Expression de besoin section 4 : "ré-authentification (mot de passe ou biométrie)" — le besoin mentionne les deux.

Le plan fait un choix de design (mot de passe) documenté en hypothèse. La spec ne prescrit pas de facteur spécifique (c'est un point à clarifier). Le choix est cohérent avec HT-106-07. Toutefois, le plan devrait ajouter une HT explicite : "la re-auth utilise le mot de passe comme seul facteur pour la v1 ; la biométrie pourra être ajoutée ultérieurement sans modification architecturale".

Verdict : Déclassement → MINEUR (choix de design valide, point à clarifier non résolu dans la spec).

Écart 5 — Logout fallback session zombie (review : MAJEUR)¶

Review : Persistance potentielle d'une session serveur active après logout.

Confrontation : - Spec ERR-106-LOGOUT-FAILED : "Risque résiduel : la session serveur peut rester active ; ce risque est mitigé par H-106-06 (le backend invalide effectivement la session lors du logout)." - Plan section 2.6 : implémente exactement ce comportement — tentative serveur, fallback nettoyage local, message explicite. - Spec INV-106-13 : "en cas d'échec d'invalidation serveur, le fallback ERR-106-LOGOUT-FAILED s'applique."

Le plan est strictement conforme à la spec. Le risque résiduel est documenté et accepté dans la spec v4 (correction m5 de la gate 3). Ce n'est pas un écart du plan.

Verdict : RÉSOLU — conformité exacte avec la spec v4.

Écart 6 — Code contract invariants hors spec (review : MAJEUR)¶

Review : Les invariants "timeout 30s" et "couverture 80%" dans les modules settings-api et tests-pd106 ne sont pas des sous-ensembles de la spec PD-106.

Confrontation : - Le timeout 30s est une constante projet existante (API_TIMEOUT dans api.ts). - La couverture 80% est un seuil projet (jest.config.js). - Ces invariants ne contredisent pas la spec — ce sont des contraintes d'implémentation projet. - Cependant, le prompt de review demande explicitement : "les invariants du code contract sont-ils un sous-ensemble des invariants de la spec ?" — donc le reviewer applique correctement la consigne.

Pour lever l'ambiguïté, les invariants projet devraient être distingués des invariants spec (par un label ou un commentaire).

Verdict : Confirmé MINEUR (pas de contradiction, mais étiquetage à clarifier).

Écart 7 — Frontière settingsApi / api.ts (review : MAJEUR)¶

Review : La frontière entre les deux services API n'est pas explicite.

Confrontation : - Plan section 1.1 : settingsApi = "Couche API pour les endpoints PD-106". - Plan section 1.2 : api.ts = "Ajouter les nouveaux endpoints PD-106". - Architecture existante : api.ts est le client HTTP bas niveau (fetch/timeout/intercepteurs). Les services domaine (settingsApi) appellent les fonctions de api.ts.

L'intention est : settingsApi est la couche domaine, api.ts est la couche transport. Cette distinction est un pattern existant dans le projet mais n'est pas formulée explicitement dans le plan.

Verdict : Confirmé MINEUR (clarification architecturale à ajouter).

Écart 8 — ProfileScreen.tsx hors code contracts (review : MAJEUR)¶

Review : Le plan déclare une modification de ProfileScreen.tsx mais aucun code contract ne couvre ce fichier.

Confrontation : - Plan section 1.2 : "Remplacer le lien 'Security' par un lien vers Settings". - Modification triviale : un changement de cible de navigation (navigation.navigate("SecuritySettings") → navigation.navigate("Settings")). - Le fichier devrait logiquement être dans le module navigation du code contract.

Verdict : Confirmé MINEUR (ajout trivial au module navigation).

Écart 9 — Frontière logout / settings-api (review : MINEUR)¶

Review : Frontière entre les deux modules non explicitée.

Confrontation : - Module logout : enrichit useAuth.logout() pour appeler POST /auth/logout via api.ts existant. - Module settings-api : nouveau service pour les endpoints PD-106 (profil, MFA, password, delete). - Frontière : le logout utilise la couche auth existante ; tout le reste passe par settingsApi.

Verdict : Confirmé MINEUR (même remarque que l'écart 7, clarification couche domaine/transport).

Écart 10 — Recovery codes atomicité serveur (review : MAJEUR)¶

Review : Le plan repose sur l'atomicité serveur sans mécanisme de preuve mobile.

Confrontation : - Spec INV-106-10 (v4) : "La garantie d'invalidation atomique dépend de H-106-04 ; le mobile vérifie le comportement observable mais ne peut pas garantir l'atomicité serveur." - Plan section 3, INV-106-10 : "Délégué au serveur (H-106-04) ; mobile observe le comportement" — formulation identique à la spec.

Le plan est strictement conforme à la spec v4. L'écart signalé par la review est en réalité un risque résiduel accepté et documenté dans la spec elle-même (correction m4 de la gate 3).

Verdict : RÉSOLU — conformité exacte avec la spec v4.

Synthèse¶

Bilan : 0 bloquant, 0 majeur, 7 mineurs résiduel, 3 résolus.

Recommandation : GO ou RESERVE (7 mineurs) — aucun écart bloquant ou majeur subsistant.