PD-106 — Confrontation Step 3 v3¶

Date : 2026-02-04 Documents confrontés : - PD-106-specification.md (v3) - PD-106-tests.md (v3) - PD-106-specification-review.md (v3)

Contexte : troisième confrontation. Les corrections v3 ont résolu les 3 majeurs et 5 mineurs de v2. Le review v3 identifie 9 points résiduels, dont plusieurs sont des récurrences atténuées de points déjà traités.

Méthodologie¶

Chaque point du review v3 est confronté aux documents source. Classification : divergence réelle, écart accepté par design, zone d'ombre résiduelle, ou faux positif / point déjà traité.

Analyse point par point¶

Point 01 — « Même flux de navigation » non défini par états stricts (Majeur)¶

Review : La notion de « même flux de navigation, sans sortie vers un autre parcours » n'est pas définie par des états de navigation contractuels stricts.

Confrontation : Ce point a été identifié en v2 (ZO-v2-01 partie flux). La correction v3 a ajouté TC-NOM-12 qui vérifie explicitement le rejet après sortie de flux + retour. La spec ne peut pas définir des « états de navigation stricts » car c'est un détail d'implémentation (modal, sous-écran, pile de navigation) qui relève du plan d'implémentation (étape 4). La définition contractuelle est suffisante : « dans le même flux, sans sortie vers un autre parcours ». Le test TC-NOM-12 prouve la contrainte.

Verdict : Point traité. La spec définit le comportement attendu, le test le prouve. Le « comment » (états de navigation) est du ressort de l'implémentation.

Gravité ajustée : Mineur (amélioration optionnelle de la spec, reportable à l'étape 4)

Point 02 — INV-106-13 vs ERR-106-LOGOUT-FAILED vs CA-106-13 (Majeur)¶

Review : Tension entre exigence absolue d'invalidation serveur et fallback accepté en erreur.

Confrontation : Ce point a été traité en v2 (DIV-v2-01) et corrigé en v3. INV-106-13 inclut maintenant explicitement « en cas d'échec d'invalidation serveur, le fallback ERR-106-LOGOUT-FAILED s'applique ». ERR-106-LOGOUT-FAILED mentionne « Ce comportement constitue le fallback de dégradation gracieuse du cas nominal INV-106-13 ». Le lien est bidirectionnel. CA-106-13 teste le cas nominal ; TC-ERR-11 teste le fallback. Il n'y a plus de contradiction — c'est un pattern de dégradation gracieuse explicitement documenté.

Verdict : Point résolu. Le review réitère un point déjà corrigé. La seule trace résiduelle est la traçabilité matrice (voir Point 05).

Gravité ajustée : Résolu (seul le rattachement matrice reste, traité au Point 05)

Point 03 — « Actions nécessitant un état fiable » non énumérées (Mineur)¶

Review : ERR-106-MFA-STATE-UNAVAILABLE bloque les actions nécessitant un état MFA fiable, mais la liste n'est pas exhaustive.

Confrontation : Confirmé mais par design. Les opérations qui nécessitent un état MFA fiable sont celles qui modifient l'état MFA : activation (F-106-02), désactivation (F-106-04), consultation/régénération codes (F-106-03). C'est implicitement déductible des flux nominaux. Énumérer explicitement serait une amélioration de traçabilité mineure.

Verdict : Zone d'ombre mineure résiduelle, déjà identifiée en v2. Non bloquante.

Gravité confirmée : Mineur

Point 04 — Testabilité logs tiers vs CA-106-17 (Majeur)¶

Review : Services tiers hors surface d'audit vs CA-106-17 qui porte une exigence globale.

Confrontation : Ce point a été traité en v2 (ZO-v2-05) et corrigé en v3. La définition de « Logs applicatifs » borne maintenant explicitement les surfaces auditables en test : « en environnement de test, les surfaces auditables sont console, journaux système et logs de debug exportables ; les services tiers de crash reporting/télémétrie sont hors surface d'audit quand l'accès n'est pas garanti ». CA-106-17 reste valide sur le périmètre auditable. La spec a fait un choix explicite et documenté de bornage. Le review pointe une tension légitime mais elle est résolue par le bornage de la définition.

Verdict : Point traité par la v3. La tension résiduelle est inhérente à tout système utilisant des services tiers — elle ne peut pas être éliminée, seulement documentée (ce qui est fait).

Gravité ajustée : Mineur (tension documentée et bornée)

Point 05 — Matrice : INV-106-13 non rattaché à TC-ERR-11 (Mineur)¶

Review : La matrice rattache INV-106-13 uniquement à TC-NOM-07, pas à TC-ERR-11 qui teste le fallback.

Confrontation : Confirmé. Puisque INV-106-13 inclut explicitement le fallback ERR-106-LOGOUT-FAILED, la matrice devrait aussi rattacher INV-106-13 à TC-ERR-11 pour une traçabilité complète. C'est une lacune de traçabilité, pas un trou de couverture (TC-ERR-11 existe et teste le bon comportement).

Verdict : ✅ Divergence réelle mineure — ajouter une ligne INV-106-13 | - | TC-ERR-11 dans la matrice.

Gravité confirmée : Mineur

Point 06 — Rate-limit non borné (Mineur)¶

Review : Reproductibilité de TC-ERR-15 dépendante de configurations serveur.

Confrontation : Point identique à ZO-v2-07, confirmé comme « par design » en v2. La v3 a ajouté dans ERR-106-RATE-LIMIT : « le seuil et la fenêtre de rate-limit sont définis par la politique serveur et ne sont pas contractualisés côté mobile ». Le choix est documenté et assumé.

Verdict : Point résolu — choix de design documenté.

Gravité ajustée : Résolu

Point 07 — Invalidation atomique codes de récupération = hypothèse backend (Majeur)¶

Review : L'invalidation atomique des anciens codes repose sur H-106-04 sans contrat backend détaillé.

Confrontation : C'est le rôle même de la section « Hypothèses explicites » — documenter les dépendances backend non contrôlables par le mobile. H-106-04 dit explicitement : « Le backend supporte la régénération des codes de récupération avec invalidation atomique des anciens. Impact si faux : Invariant de sécurité sur les codes non garanti. » La spec mobile ne peut pas garantir le comportement backend — elle peut seulement le documenter comme hypothèse et tester le comportement observable côté mobile (TC-NOM-04 : « Tout code RC1 devient invalide et au moins un code RC2 est valide »).

Verdict : Point inhérent au périmètre mobile. L'hypothèse est documentée, l'impact si faux est explicité, le test mobile vérifie le comportement observable. Pas un défaut de la spec mobile.

Gravité ajustée : Mineur (documentation existante adéquate)

Point 08 — Session serveur zombie après ERR-106-LOGOUT-FAILED (Majeur)¶

Review : Risque résiduel de session serveur persistante.

Confrontation : Point identique au Point 02 et à DIV-v2-01 / ZO-v2-01 des itérations précédentes. Le risque est réel mais explicitement accepté et documenté : - INV-106-13 documente le fallback - ERR-106-LOGOUT-FAILED documente la dégradation gracieuse - Le comportement côté client est déterministe (purge locale + forçage état non-auth) - Le risque serveur est mitigé par H-106-06 (« Le backend invalide effectivement la session lors du logout »)

La session zombie est un risque résiduel accepté, pas un défaut de spécification.

Verdict : Risque résiduel documenté et accepté. Pas d'action corrective possible côté spec mobile.

Gravité ajustée : Mineur (risque résiduel accepté par design)

Point 09 — RGPD art. 17 hors périmètre (Bloquant)¶

Review : Preuve RGPD complète impossible depuis le mobile.

Confrontation : Point identique à v1 (Point 13) et v2 (ZO-v2-06). Déjà déclassé deux fois. INV-106-18, CA-106-19 et TC-INV-03 documentent explicitement le hors-périmètre. PD-106 ne prétend pas couvrir la conformité RGPD globale. Le classement « Bloquant » par le review est systématiquement excessif dans le contexte PD-106.

Verdict : Déclassé. Hors périmètre PD-106 explicitement documenté.

Gravité ajustée : Mineur (hors périmètre, action requise au niveau programme)

Synthèse v3¶

Progression v1 → v2 → v3¶

Recommandation : GO — sous réserve de l'ajout d'une ligne matrice (INV-106-13 → TC-ERR-11), correction triviale intégrable à l'étape 4.