PD-243 — Confrontation (Gate 3 Phase 2)¶

Contre-auditeur : ChatGPT (cross-validation — revieweur: Claude) Date : 2026-02-19 Mode : Factuel

Analyse des écarts¶

ECT-01 — Contradiction label K_doc¶

Verdict : NUANCE

Justification : L'écart est partiellement fondé mais la qualification "Contradiction" est excessive. Le TC-REG-03 documente explicitement les deux scénarios possibles ("Si migration label" vs "Si pas de migration") avec une note de risque. Ce n'est pas une contradiction mais une décision architecturale pendante qui doit être tranchée. La spec pourrait clarifier le choix retenu, mais le cahier de tests anticipe correctement les deux issues.

La vraie question est : la spec impose REQ-243-06 (K_doc avec underscore) MAIS exclut la migration historique. L'interprétation correcte est que les nouvelles dérivations utilisent le nouveau label, tandis que les anciennes données restent avec l'ancien label. C'est un dual-label temporaire jusqu'à migration (hors périmètre PD-243).

Gravité finale : Majeur (décision à clarifier, mais pas bloquant car interprétable)

ECT-02 — Ambiguïté migration K_doc¶

Verdict : CONFIRME

Justification : L'écart est réel. REQ-243-06 impose le label K_doc mais le périmètre exclut la migration. Il manque une clarification explicite du comportement attendu pour les documents existants vs nouveaux. La spécification devrait expliciter : - Les nouveaux documents utilisent ProbatioVault::K_doc::v1 - Les anciens documents restent lisibles avec l'ancien label (code doit supporter les deux en lecture)

Gravité finale : Bloquant (ambiguïté contractuelle non résolue)

ECT-03 — Vecteurs de test non calculés¶

Verdict : NUANCE

Justification : L'écart est réel mais la gravité "Majeur" est discutable. Les vecteurs marqués [a calculer] sont une pratique courante dans les cahiers de tests pour indiquer qu'ils seront produits lors de l'implémentation. Le cahier de tests définit correctement la structure des vecteurs (IKM, salt, info, output_length). Le calcul effectif est une tâche d'implémentation, pas de spécification.

Cependant, pour un audit contractuel, des vecteurs pré-calculés avec une implémentation de référence externe (ex: Python cryptography) renforcerait la testabilité.

Gravité finale : Mineur (structure définie, calcul en implémentation)

ECT-04 — Dépendance interopérabilité non bornée¶

Verdict : CONFIRME

Justification : L'écart est fondé. HYP-243-03 crée une dépendance externe sans date limite ni plan de production des vecteurs. TC-INTEROP-01 ne peut être exécuté sans ces vecteurs. L'hypothèse devrait être transformée en tâche de l'étape 4 (Plan) avec responsable et deadline.

Gravité finale : Majeur

ECT-05 — Couverture partielle INV-243-03¶

Verdict : CONTESTE

Justification : L'écart est erroné. Relecture d'INV-243-03 : "K_auth != K_encryption, K_auth != K_doc, K_encryption != K_doc".

• TC-ISO-01 vérifie K_auth !== K_encryption ✓
• TC-ISO-02 vérifie K_auth !== K_doc ✓

Il manque effectivement un test explicite pour K_encryption !== K_doc. MAIS : cette propriété découle mathématiquement des labels HKDF différents. Si K_encryption utilise label K_encryption::v1 et K_doc utilise label K_doc::v1, alors par construction cryptographique, les sorties sont distinctes (propriété HKDF avec labels différents).

Toutefois, un test explicite renforcerait la couverture.

Gravité finale : Mineur (couverture implicite, test explicite recommandé)

ECT-06 — Encodage UTF-8 non précisé¶

Verdict : CONTESTE

Justification : L'écart est théorique mais non pertinent pour PD-243. Tous les labels utilisés (ProbatioVault::K_auth::v1, K_doc::v1, K_encryption::v1) sont composés exclusivement de caractères ASCII (plage 0x00-0x7F). La question NFC/NFD ne se pose que pour les caractères non-ASCII. Pour de l'ASCII pur, UTF-8 = ASCII, pas d'ambiguïté possible.

Gravité finale : Non applicable

ECT-07 — Zeroization non vérifiable automatiquement¶

Verdict : CONFIRME

Justification : L'écart est réel et correctement qualifié. L'invariant INV-243-04 est marqué "Testable: Partiel" dans la spec elle-même, ce qui indique une conscience du problème. Le cahier de tests documente cette limitation dans "Scenarios non testables". La qualification "Mineur" est appropriée car le risque est connu, documenté, et inhérent au runtime JavaScript.

Gravité finale : Mineur (limitation documentée et acceptée)

Synthèse confrontation¶

Écarts consolidés¶

Recommandation Phase 2¶

RESERVE — 1 écart bloquant (ECT-02) nécessite clarification PO avant poursuite. Les écarts majeurs (ECT-01, ECT-04) peuvent être adressés en étape 4 (Plan).

Action requise : Clarifier dans la spécification si le code doit supporter un dual-label (lecture anciens Kdoc + écriture nouveaux K_doc) ou si c'est un breaking change assumé.