Aller au contenu

PD-106 — Rapport de confrontation (Étape 3 — CONFORMITY_CHECK)

Ce rapport est produit par l'orchestrateur Claude avant la gate PMO. Il confronte la spécification et les scénarios de tests pour identifier convergences, divergences et zones d'ombre.

1. Sources confrontées

  • PD-106-specification.md (étape 1 — spécification canonique contractuelle)
  • PD-106-tests.md (étape 2 — scénarios de tests contractuels)
  • PD-106-specification-review.md (étape 3, phase 1 — review ChatGPT)

2. Convergences

  • Structure de couverture : la matrice de couverture des tests référence l'intégralité des 18 invariants et 19 critères d'acceptation de la spec. Aucun invariant n'est orphelin.
  • Flux nominaux : les 7 flux nominaux (F-106-01 à F-106-07) ont chacun au moins un scénario de test associé (TC-NOM-01 à TC-NOM-10).
  • Cas d'erreur : les 15 codes d'erreur de la spec sont couverts par les scénarios TC-ERR-01 à TC-ERR-15.
  • Re-authentification non réutilisable : INV-106-06 est explicitement testé par TC-NOM-03 avec un scénario dédié (opération A puis opération B sans nouvelle reauth).
  • Affichage unique des codes : convergence entre INV-106-09, F-106-03 et les tests TC-NOM-02, TC-NOM-10, TC-ERR-07.
  • Hors périmètre RGPD : spec et tests s'accordent sur INV-106-18/CA-106-19 comme NON TESTABLE dans le périmètre mobile, renvoyé aux artefacts backend/compliance.
  • Localisation i18n : TC-NOM-09 couvre correctement INV-106-17/CA-106-18.

3. Divergences

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

DIV-01 : Re-authentification pour changement de mot de passe — contradiction spec interne

  • Source A (spec, INV-106-05) : « Chaque opération critique DOIT exiger une re-authentification réussie immédiatement avant exécution. » Le changement de mot de passe est listé comme opération critique (section 3).
  • Source B (spec, F-106-05 étape 3) : « Le système exige une re-authentification (si distincte du formulaire de changement selon politique serveur). »
  • Tests (TC-NOM-06) : ne mentionne pas de re-authentification explicite séparée, seulement « toute re-authentification requise par la politique serveur est validée ».
  • Impact : contradiction interne à la spec, propagée dans les tests. L'invariant est impératif (DOIT), le flux est conditionnel (si). Le test ne tranche pas. Bloquant — confirmé par la review ChatGPT (Point 05).

DIV-02 : Périmètre de non-persistance des secrets — imprécision propagée

  • Source A (spec, INV-106-08) : « NE DOIVENT PAS être persistés en stockage local durable ni journalisés en logs applicatifs. »
  • Source B (tests, TC-INV-01) : vérifie « aucun stockage local durable » et « aucun log applicatif accessible en environnement de test ».
  • Divergence : la spec ne définit pas les surfaces exactes de « stockage local durable » (Keychain, AsyncStorage, SQLite, fichiers cache, UserDefaults ?) ni de « logs applicatifs » (console, fichiers log, Sentry, crashlytics ?). Le test hérite de cette imprécision : « surfaces de persistance applicative » reste non borné.
  • Impact : un audit peut donner des résultats différents selon les surfaces inspectées. Confirmé par review ChatGPT (Point 08).

DIV-03 : TC-NOM-02 rattaché à CA-106-17 sans observable correspondant

  • Source A (tests, matrice) : la ligne INV-106-08/CA-106-17 → TC-NOM-02 marque une couverture.
  • Source B (tests, TC-NOM-02 corps du scénario) : TC-NOM-02 vérifie l'activation MFA réussie et l'affichage des codes. Il ne contient aucun observable de non-persistance/non-journalisation.
  • Impact : la matrice de couverture déclare une couverture que le scénario ne délivre pas réellement. TC-INV-01 est le vrai test pour CA-106-17. Incohérence mineure mais trompeuse. Confirmé par review ChatGPT (Point 11).

DIV-04 : TC-NOM-06 introduit une attente non contractualisée

  • Source A (spec, F-106-05) : le flux s'arrête à « l'état utilisateur est cohérent avec la politique de session serveur ». Aucune obligation de vérifier l'ancien/nouveau mot de passe par tentative d'authentification ultérieure.
  • Source B (tests, TC-NOM-06 THEN) : « Une tentative d'authentification ultérieure avec ancien_mdp échoue et avec nouveau_mdp réussit. »
  • Impact : le test va au-delà de ce que la spec contractualise explicitement. Ce n'est pas contradictoire mais c'est un ajout de preuve non fondé sur une exigence formelle. Confirmé par review ChatGPT (Point 10).

DIV-05 : Fenêtre temporelle de re-authentification non bornée

  • Source A (spec, INV-106-05) : « immédiatement avant exécution ».
  • Source B (tests) : aucun scénario ne teste une re-authentification devenue périmée par délai.
  • Impact : « immédiatement » n'a pas de borne temporelle contractuelle. Aucun test ne vérifie l'expiration d'une re-authentification. Confirmé par review ChatGPT (Point 01).

4. Zones d'ombre

ZO-01 : Politique de session post-changement de mot de passe

La spec renvoie au serveur (F-106-05 étape 6), les tests marquent la politique comme NON TESTABLE (section 9). Aucun document ne tranche si le changement de mot de passe invalide la session courante, force une reconnexion, ou maintient la session active.

ZO-02 : Comportement après échec logout serveur

La spec renvoie à la section 10 (point à clarifier). Les tests marquent TC-ERR-11 comme partiellement couvert, comportement final NON TESTABLE. Aucun document ne contractualise la stratégie (forcer déconnexion locale vs maintenir session).

ZO-03 : Fenêtre de coexistence des codes de récupération

INV-106-10 exige l'invalidation « de l'ensemble des codes précédents » après régénération. Ni la spec ni les tests ne bornent la fenêtre temporelle d'atomicité. Si la régénération n'est pas atomique côté serveur, il existe un intervalle où anciens et nouveaux codes coexistent. Confirmé par review ChatGPT (Point 12).

ZO-04 : Canaux d'exfiltration visuels/système

La spec interdit la persistance et la journalisation, mais ne traite pas les captures d'écran système, les caches système (pasteboard, preview d'app en background), ni les sauvegardes iOS automatiques. Les tests ne couvrent pas ces vecteurs. Confirmé par review ChatGPT (Point 14).

ZO-05 : Seuils de rate-limit

Ni la spec ni les tests ne contractualisent les seuils de rate-limit. TC-ERR-15 suppose un seuil défini par le serveur mais ne peut pas être déterministe sans paramètres fixes.

ZO-06 : Liste des actions bloquées quand état MFA = inconnu

ERR-106-MFA-STATE-UNAVAILABLE dit « bloquer les actions nécessitant un état fiable » sans liste exhaustive. TC-ERR-03 vérifie le blocage mais sans périmètre précis des actions concernées. Confirmé par review ChatGPT (Point 04).

5. Recommandation

  • Procéder — convergence confirmée, aucun conflit bloquant
  • Rework nécessaire — divergences à résoudre avant de continuer
  • Escalade — décision humaine requise sur un point structurant

Justification : 1 divergence bloquante (DIV-01 — contradiction interne sur la re-authentification pour changement de mot de passe) et 2 points bloquants issus de la review ChatGPT (contradiction INV-106-05 vs F-106-05, et preuve RGPD hors périmètre). Les zones d'ombre ZO-01 à ZO-06 sont des risques majeurs pour l'implémentation mais peuvent être traités par réserves conditionnelles. La contradiction DIV-01 nécessite un arbitrage contractuel avant de poursuivre.