Voici l'audit technique indépendant :

PD-85 — Specification Review¶

1. Ambiguïtés¶

A-01 — Valeur par défaut signedUrlTtl non définie¶

• Type : Ambiguïté
• Référence : Spec §5.2, H-03, INV-85-04
• Description : Le tableau §5.2 indique explicitement signedUrlTtl = "NON SPECIFIE (bloquant)" avec borne max 30 min, mais aucune valeur par défaut n'est contractualisée. Le code d'erreur 400 est prévu pour "config invalide" mais on ne peut pas distinguer absence de config vs config hors borne.
• Impact : CA-10 et TC-INV-8504 invérifiables de manière stable — le TTL effectif est indéterminé.
• Gravité : Bloquant

A-02 — Comportement proofIds avec doublons non contractualisé¶

• Type : Ambiguïté
• Référence : Spec §5.1 / Tests TC-NEG-01
• Description : Le test TC-NEG-01 admet explicitement deux comportements possibles ("déduplication explicite OU rejet 400") sans qu'aucun ne soit contractualisé dans la spec. Une équipe tierce ne peut pas implémenter ce cas.
• Impact : Comportement non-déterministe en cas de doublons, risque de divergence entre implémentations.
• Gravité : Majeur

A-03 — Enum documentType non figée¶

• Type : Ambiguïté
• Référence : Spec §10 point 5, Tests §9
• Description : La spec référence un documentType dans le manifest mais ne fournit aucune liste normative de valeurs. Les tests ne peuvent pas valider l'appartenance à un ensemble contractuel.
• Impact : Validation côté client et tests d'invariants impossibles.
• Gravité : Majeur

A-04 — Format contractuel de proofEnvelopeRef non défini¶

• Type : Ambiguïté
• Référence : Spec §10 point 6
• Description : Le format de proofEnvelopeRef (UUID, URN, autre) n'est pas contractualisé. La spec le mentionne comme point à clarifier mais aucun test ne couvre sa validation.
• Impact : Interopérabilité avec PD-283 (consommateur) impossible à garantir.
• Gravité : Majeur

A-05 — Canonicalisation RFC 8785 implicite vs contractuelle¶

• Type : Ambiguïté
• Référence : Spec §9 H-01, INV-85-03
• Description : La canonicalisation JCS est une hypothèse (H-01), pas un invariant. Si H-01 est invalidée, INV-85-03 devient non-vérifiable. Or TC-INV-8503 et TC-NOM-05 supposent JCS sans réserve.
• Impact : Hash non reproductible inter-systèmes si canonicalisation différente. Incohérence entre le statut "hypothèse" et les tests qui l'utilisent comme acquis.
• Gravité : Majeur

2. Contradictions¶

C-01 — Référence Epic incohérente¶

• Type : Contradiction
• Référence : Spec §11 ("PD-185") vs Tests §1 ("EPIC-XX")
• Description : La spec référence l'epic PD-185 (B2C-MINEURS) tandis que les tests indiquent EPIC-XX avec une note d'incohérence. Deux identifiants d'epic coexistent.
• Impact : Traçabilité d'audit brisée — impossible de rattacher les artefacts à un seul epic.
• Gravité : Mineur

C-02 — Incohérence 404 : "par identifiant" vs comportement agrégé non défini¶

• Type : Contradiction
• Référence : Spec §6 (404 "Erreur explicite par identifiant"), Spec §10 point 9, TC-ERR-03
• Description : La spec §6 indique un 404 "par identifiant" mais la requête accepte un tableau proofIds. Si 5 proofIds dont 1 non possédé : retourne-t-on 404 pour tout le lot (bloquant) ou rejette-t-on uniquement cette preuve (partiel comme le 422) ? TC-ERR-03 teste un seul proofId invalide, pas le cas mixte.
• Impact : Ambiguïté entre comportement fail-fast (404 global) et comportement partiel. Le test est insuffisant.
• Gravité : Bloquant

C-03 — Scénario ST-04 vs flux F2 : motifs de rejet¶

• Type : Contradiction
• Référence : Spec §5.5 (F2), §8 ST-04
• Description : ST-04 mentionne "2 invalides (INV-02/INV-03)" mais F2 ne liste pas quels invariants provoquent un rejet partiel vs un rejet total. INV-11 (seal invalide) devrait aussi provoquer un rejet, mais la spec ne contractualise pas la liste exhaustive des motifs de rejet partiel vs erreur bloquante.
• Impact : Implémentation arbitraire de la frontière entre rejet partiel et blocage.
• Gravité : Majeur

3. Règles non testables¶

NT-01 — Politique d'audit WORM pour erreurs 4xx/422¶

• Type : Non testable
• Référence : INV-85-05, CA-12, Spec §10 point 7
• Description : CA-12 mentionne "200/4xx/422 selon politique à confirmer". La politique de journalisation des erreurs n'est pas contractualisée. TC-INV-8505 ne peut tester que le cas 200.
• Impact : Auditabilité partielle — les tentatives échouées potentiellement non tracées.
• Gravité : Majeur

NT-02 — Performance P95 sans contexte matériel¶

• Type : Non testable
• Référence : Spec §5.2 (latence 50/100 preuves)
• Description : Les seuils P95 sont donnés sans environnement de référence. La spec elle-même l'admet ("contexte matériel non spécifié"). Aucun test ne les couvre.
• Impact : Critères de performance inapplicables.
• Gravité : Mineur (explicitement hors périmètre)

NT-03 — INV-85-01 (absence de déchiffrement) : observable limité¶

• Type : Non testable a priori
• Référence : INV-85-01, CA-11, TC-INV-8501
• Description : TC-INV-8501 vérifie l'absence de déchiffrement via "logs techniques/audit". Cet observable est fragile : il dépend de la couverture des traces applicatives. Un appel de déchiffrement non instrumenté passerait inaperçu.
• Impact : Test non fiable sans instrumentation dédiée ou analyse statique.
• Gravité : Majeur

4. Incohérences Spec ↔ Tests¶

IST-01 — TC-ERR-03 couvre partiellement CA-04¶

• Type : Incohérence Spec↔Tests
• Référence : CA-04, TC-ERR-03, Spec §10 point 9
• Description : CA-04 exige "code 404 corrélé proofId". TC-ERR-03 teste séparément proofId non possédé et inexistant, mais le cas mixte (mélange valides + non possédés + inexistants dans la même requête) n'est couvert ni par la spec ni par les tests. La matrice de couverture note "Partiel".
• Impact : Cas réel le plus fréquent non testé.
• Gravité : Majeur

IST-02 — CA-12 couverture audit : matrice indique "Partiel"¶

• Type : Incohérence Spec↔Tests
• Référence : INV-85-05, CA-12, matrice §2
• Description : La matrice de couverture reconnaît explicitement une couverture "Partiel" pour INV-85-05 avec "politique 4xx/422 ambiguë". Le test ne couvre donc pas l'invariant de manière exhaustive.
• Impact : Couverture incomplète d'un invariant non-négociable.
• Gravité : Majeur

IST-03 — INV-85-08-transitions et INV-85-09 sans critère d'acceptation¶

• Type : Incohérence Spec↔Tests
• Référence : Matrice §2 (colonne "ID Critère" = — pour INV-85-08 et INV-85-09)
• Description : Les invariants INV-85-08-transitions et INV-85-09-envelope-encryption ont des tests dédiés (TC-INV-8508, TC-INV-8509) mais aucun critère d'acceptation associé dans la spec §7. La traçabilité INV → CA → TC est brisée.
• Impact : Invariants non contractualisés comme critères d'acceptation — risque de perte lors d'un audit.
• Gravité : Majeur

IST-04 — TC-NOM-04 couvre à la fois CA-09 et CA-14¶

• Type : Incohérence Spec↔Tests
• Référence : TC-NOM-04, CA-09, CA-14
• Description : Un seul test couvre deux critères d'acceptation distincts (tri chronologique ET validité exportedBy). Si le test échoue, on ne peut pas discriminer quel critère est violé. Les tests contractuels devraient idéalement avoir une correspondance 1:1 ou au minimum des assertions séparables.
• Impact : Diagnostic de défaillance imprécis.
• Gravité : Mineur

5. Hypothèses dangereuses¶

HD-01 — Atomicité audit WORM dans le flux synchrone¶

• Type : Hypothèse dangereuse
• Référence : Spec §5.7 (Audit WORM = Synchrone)
• Description : La spec impose l'écriture audit WORM de manière synchrone dans le flux requête. Si le stockage WORM est indisponible ou lent, le flux export entier est bloqué. Aucun mécanisme de fallback ni de timeout n'est contractualisé.
• Impact : Indisponibilité WORM = indisponibilité export. Risque de cascade.
• Gravité : Majeur

HD-02 — Calcul taille "estimée" pour garde-fou 1 GB¶

• Type : Hypothèse dangereuse
• Référence : INV-85-07, CA-05, TC-ERR-04
• Description : La spec mentionne "taille totale chiffrée estimée" sans contractualiser la méthode d'estimation. La taille réelle peut différer de l'estimation (métadonnées, padding, overhead URLs signées). Un export pourrait passer le check 1 GB en estimation mais dépasser en réel.
• Impact : Faux négatif du garde-fou de taille.
• Gravité : Majeur

HD-03 — Accessibilité des données B2C-mineurs (H-05)¶

• Type : Hypothèse dangereuse
• Référence : Spec §9 H-05, §5.9 (contraintes inter-modules)
• Description : H-05 suppose que "les données B2C-mineurs requises sont accessibles au backend export" mais §5.9 note explicitement que la "FK/résolution cross-module" est non spécifiée. Le test TC-NOM-03 suppose implicitement que ces données sont disponibles.
• Impact : Si la résolution cross-module n'est pas implémentée, le cas mineur échoue silencieusement.
• Gravité : Majeur

6. Risques sécurité / conformité¶

RS-01 — Fenêtre d'exposition URLs signées sans borne inférieure opérationnelle¶

• Type : Risque sécu/conformité
• Référence : INV-85-04, §5.2
• Description : La borne min est 1 min et max 30 min, mais sans valeur par défaut (A-01). Un opérateur pourrait configurer 30 min par défaut, créant une fenêtre d'exposition maximale systématique. Le principe de moindre exposition n'est pas contractualisé (pas de "SHOULD use shortest viable TTL").
• Impact : Exposition prolongée non nécessaire des fichiers chiffrés.
• Gravité : Majeur

RS-02 — Pas de rate limiting contractualisé sur l'endpoint¶

• Type : Risque sécu/conformité
• Référence : Spec §5.4, §6
• Description : L'endpoint génère des URLs signées et des écritures audit WORM. Aucune limitation de débit n'est contractualisée. Un utilisateur Premium pourrait saturer le stockage WORM et générer un nombre illimité d'URLs signées.
• Impact : Déni de service applicatif (DoS lent via saturation WORM ou quota URLs S3).
• Gravité : Majeur

RS-03 — readmeVerification injecté sans validation de contenu¶

• Type : Risque sécu/conformité
• Référence : Spec §5.1 (readmeVerification : texte UTF-8, max 200 KB, non vide)
• Description : Le readmeVerification est spécifié comme "texte UTF-8 max 200 KB non vide" mais aucune validation de contenu n'est contractualisée. Si ce contenu est généré dynamiquement ou accepte une entrée, il pourrait contenir des instructions trompeuses dans un dossier probatoire.
• Impact : Intégrité du dossier probatoire — un README falsifié pourrait guider un tiers vers une vérification incorrecte.
• Gravité : Mineur (si contenu statique serveur-side, le risque est mitigé mais non contractualisé)

RS-04 — Absence de contrôle anti-rejeu sur les exports¶

• Type : Risque sécu/conformité
• Référence : INV-85-02 (exportId unique)
• Description : L'exportId garantit l'unicité mais aucun mécanisme anti-rejeu n'est contractualisé (ex: nombre max d'exports par preuve/jour, cooldown). Un utilisateur pourrait générer des centaines de manifests pour les mêmes preuves, chacun avec un exportId différent et des timestamps différents.
• Impact : Prolifération d'artefacts probatoires non contrôlée, confusion en contexte judiciaire.
• Gravité : Mineur

Synthèse¶

Points bloquants à résoudre avant Gate 3 GO : 1. A-01 : Figer la valeur par défaut de signedUrlTtl (contractuel). 2. C-02 : Contractualiser le comportement 404 en cas de mix proofIds valides + non possédés dans la même requête (fail-fast vs rejet partiel).