PD-106 — Confrontation Step 3 v2¶

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

Contexte : seconde confrontation après corrections NON_CONFORME v1. Les corrections v2 ont résolu la contradiction DIV-01 (re-auth changement mdp), borné les définitions ambiguës, et corrigé la matrice de tests.

Méthodologie¶

Chaque point du review v2 est confronté aux documents source pour déterminer s'il constitue un écart réel, un écart accepté par design, ou un faux positif. Les divergences sont classées en divergences (écarts factuels entre documents) et zones d'ombre (imprécisions non couvertes).

Divergences¶

DIV-v2-01 — Contradiction apparente INV-106-13 vs ERR-106-LOGOUT-FAILED¶

Review : Point 01 (Majeur) — INV-106-13 impose invalidation serveur, ERR-106-LOGOUT-FAILED contractualise un échec.

Confrontation : - INV-106-13 dit : « La déconnexion DOIT invalider la session serveur et effacer les données sensibles locales de session. » - ERR-106-LOGOUT-FAILED dit : « Échec invalidation session serveur → message explicite ; le système efface les données sensibles locales de session et force l'état non authentifié. »

Analyse : Il ne s'agit pas d'une contradiction mais d'un pattern de dégradation gracieuse classique en sécurité. L'invariant définit le comportement nominal attendu. Le cas d'erreur définit le fallback quand le nominal échoue. La spec a explicitement choisi de protéger le client (purge locale + forçage état non-auth) même en cas d'échec serveur. La session serveur zombie résiduelle est un risque résiduel assumé, pas une contradiction.

Verdict : ⚠️ Écart de rédaction, pas de contradiction logique. La spec pourrait préciser que INV-106-13 s'applique au flux nominal et que ERR-106-LOGOUT-FAILED est le fallback. Cependant, c'est un point de clarification rédactionnelle, pas un bloquant fonctionnel.

Gravité ajustée : Mineur (clarification rédactionnelle)

DIV-v2-02 — Contradiction F-106-03 étape 2 vs Point à clarifier 4¶

Review : Point 08 (Majeur) — F-106-03 fixe la politique de non-affichage hors affichage unique, mais le point à clarifier 4 maintient la question ouverte.

Confrontation : - F-106-03 étape 2 : « Si aucun affichage unique n'est disponible dans le contexte courant, le système n'affiche aucun code en clair et propose la régénération. » - Point à clarifier 4 : « Politique officielle de consultation des codes de récupération hors phase de génération/régénération (interdit vs autorisé). »

Analyse : Contradiction avérée. Le flux a tranché (interdit + proposition de régénération) mais la section « Points à clarifier » contredit ce choix en le maintenant comme question ouverte. Le point à clarifier 4 aurait dû être supprimé ou marqué comme résolu lors des corrections v2.

Verdict : ✅ Divergence réelle — le point à clarifier 4 doit être retiré ou marqué « Résolu par F-106-03 ».

Gravité ajustée : Mineur (incohérence documentaire, pas d'impact fonctionnel car le flux est défini)

Zones d'ombre¶

ZO-v2-01 — Borne temporelle re-auth (5 min) non testée¶

Review : Points 04-05 (Majeurs) — Les tests TC-NOM-03 et TC-NOM-06 vérifient la présence de re-auth mais pas la borne de 5 minutes ni le rejet après sortie de flux.

Confrontation : Confirmé. La définition de re-auth spécifie « dans les 5 minutes précédant l'exécution » et « dans le même flux de navigation, sans sortie vers un autre parcours ». Aucun test ne vérifie explicitement : - Le rejet d'une re-auth validée il y a > 5 minutes - Le rejet d'une re-auth validée après sortie/retour de flux

Impact : Couverture de test incomplète sur deux contraintes contractuelles bornées. La borne de 5 min et la contrainte de flux ne sont prouvées par aucun scénario.

Gravité : Majeur — tests manquants pour des contraintes contractuelles explicites.

ZO-v2-02 — Terme « message exploitable » non défini objectivement¶

Review : Point 03 (Majeur) — « message/erreur exploitable » utilisé dans INV-106-12, INV-106-16, CA-106-07, CA-106-12 sans critères objectifs.

Confrontation : Confirmé. Le terme apparaît 8+ fois dans la spec comme observable contractuel mais aucune définition n'existe en section 3 (Définitions). Pas de contenu minimal (code erreur ? texte libre ? clé i18n ?), pas de structure, pas de niveau de précision.

Impact : Critères d'acceptation potentiellement subjectifs — un auditeur pourrait juger un message « exploitable » quand un autre le refuse.

Gravité : Majeur — terme contractuel non borné.

ZO-v2-03 — Source temporelle re-auth (horloge client vs serveur)¶

Review : Point 09 (Majeur) — La borne de 5 minutes ne précise pas si c'est l'horloge client, serveur, ou une dérive admise.

Confrontation : Confirmé. La définition dit « validée dans les 5 minutes précédant l'exécution » sans préciser la source de vérité temporelle. Selon que c'est le client ou le serveur qui contrôle, le comportement aux limites diffère.

Impact : En pratique, si la re-auth est validée par le serveur (H-106-03), c'est le serveur qui fait foi. Mais la spec ne l'explicite pas.

Gravité : Mineur — clarification utile mais la mécanique serveur (H-106-03) implique naturellement que c'est le serveur qui juge.

ZO-v2-04 — Double validation (confirmation renforcée) non tracée en test¶

Review : Point 06 (Majeur) — TC-NOM-08 et TC-ERR-12 ne tracent pas explicitement les deux étapes de validation comme observables distincts.

Confrontation : Partiellement confirmé. La définition v2 de « confirmation renforcée » est bornée (« double validation explicite obligatoire dans le même flux — validation initiale puis confirmation finale »). Cependant, TC-NOM-08 GIVEN dit « U2 valide la confirmation renforcée attendue par l'interface » sans détailler les deux étapes. TC-ERR-12 vérifie le cas d'échec « confirmation renforcée invalide/incomplète ».

Impact : Le test d'échec (TC-ERR-12) couvre implicitement la non-complétion de la double validation. Le test nominal (TC-NOM-08) pourrait être plus explicite sur les deux étapes, mais le concept est couvert.

Gravité : Mineur — amélioration de traçabilité, pas de trou de couverture.

ZO-v2-05 — Testabilité crash reporting/télémétrie (INV-106-08)¶

Review : Point 11 (Majeur) — La définition de « logs applicatifs » inclut crash reporting et télémétrie tiers, dont l'accès exhaustif n'est pas garanti en environnement de test.

Confrontation : Confirmé. La définition v2 de « Logs applicatifs » inclut « services de crash reporting/télémétrie ». TC-INV-01 vérifie l'absence de secrets dans les logs accessibles en environnement de test, mais la complétude dépend de l'accès aux sorties de services tiers (Sentry, Crashlytics, etc.).

Impact : Le test est réalisable pour les surfaces contrôlables (console, journaux système, logs debug exportables). Pour les services tiers, la preuve dépend de leur configuration et accessibilité en test.

Gravité : Majeur — testabilité partielle sur les services de télémétrie tiers. Pourrait être mitigé en documentant explicitement les surfaces auditables vs non-auditables.

ZO-v2-06 — RGPD art. 17 hors périmètre¶

Review : Point 13 (Bloquant) — Preuve RGPD complète impossible depuis le mobile.

Confrontation : Point déjà traité dans la spec. INV-106-18 et CA-106-19 marquent explicitement ce point comme « HORS PÉRIMÈTRE PD-106 ». TC-INV-03 est marqué « NON TESTABLE » dans la matrice. Le review le classe « Bloquant » mais c'est bloquant pour la conformité globale RGPD, pas pour PD-106 en tant que tel. PD-106 a correctement borné son périmètre.

Verdict : Le classement « Bloquant » par le review est excessif dans le contexte de PD-106. C'est un point de gouvernance globale, pas un défaut de la spec PD-106.

Gravité ajustée : Mineur pour PD-106 (hors périmètre explicitement documenté). Action requise au niveau programme (artefacts backend/compliance).

ZO-v2-07 — Rate-limit non borné (ERR-106-RATE-LIMIT)¶

Review : Point 10 (Mineur) — Seuil et fenêtre de rate-limit non contractualisés.

Confrontation : Confirmé. La spec définit le comportement en cas de rate-limit (message explicite, contrainte temporelle si fournie par le serveur) mais ne fixe pas de seuil. C'est cohérent avec H-106-03 (le backend contrôle la politique) et le périmètre mobile qui affiche les contraintes serveur sans les définir.

Gravité : Mineur — par design, le mobile ne définit pas la politique serveur.

Synthèse v2¶

Comparaison v1 → v2¶

Progression : Les corrections v2 ont résolu la contradiction bloquante et les ambiguïtés majeures non bornées. Les points restants sont principalement des lacunes de couverture de test (borne 5 min, contrainte de flux) et des précisions terminologiques (« exploitable »).

Recommandation pour le dossier de conformité : RESERVE (sous réserve d'ajout de tests pour la borne temporelle et la contrainte de flux de re-auth, et de définition du terme « exploitable »).