PD-103 — Dossier de conformité (Gate 3 — v3)¶
1. Documents de référence¶
- Spécification v3 :
PD-103-specification.md(2000 lignes, 35 INV, corrections BLOQUANTS v2 + MAJEURS v2) - Tests v3 :
PD-103-tests.md(1641 lignes, matrice couverture 35 INV, GIVEN/WHEN/THEN) - Review P1 v3 (Claude) :
PD-103-review-step3-v3.md - Confrontation P2 v3 (ChatGPT) :
PD-103-confrontation-step3-v3.md
2. Corrections v2→v3 appliquées¶
| Écart v2 | Statut v3 |
|---|---|
| ECT-01-v2 « payload canonique identique » non défini | CORRIGÉ — §5.12 fingerprint canonique SHA-256, champs définis, normalisation |
| ECT-11-v2 Échec unwrap DEK backend | CORRIGÉ — ER-103-16 (422) + ER-103-17 (503), TC-ERR-16/17 |
| ECT-19-v2 Q-103-07 conservation locale bloquant | CORRIGÉ — politique rétention locale explicite §5.8, Q-103-07 résolu |
| ECT-07-v2 SHA3-256/RSA-OAEP React Native | CORRIGÉ — §10.1 dépendances crypto documentées |
| ECT-05-v2 Effacement DEK mémoire JS | CORRIGÉ — zéroïsation buffer TypedArray, limitation JS reconnue, INV-103-32 |
| ECT-06-v2 Orphelins S3 | CORRIGÉ — §5.9 GC orphelins S3, INV-103-33, TC-INV-11 |
| ECT-08-v2 « Cycle conforme » non défini | CORRIGÉ — §5.9 définition cycle = réconciliation, conforme = toutes PENDING_SEAL scellées |
| ECT-02-v2 « ReKey » fantôme | CORRIGÉ — retiré de INV-103-09 |
| ECT-03-v2 capture_id case-insensitive | CORRIGÉ — INV-103-31 normalisation lowercase, TC-NOM-15, TC-INV-06 |
| ECT-13-v2 Effacement DEK non testé | CORRIGÉ — TC-INV-12 test zéroïsation buffer |
| ECT-17-v2 Captures UPLOAD_DEFERRED après rotation KEK | CORRIGÉ — §5.11 keyring KEK + kek_id, INV-103-34, TC-NOM-16, TC-INV-13 |
| ECT-09-v2 Trigger SEAL_DELAYED | CORRIGÉ — §5.9 trigger automatique sur SLA, INV-103-35, TC-INV-14 |
12/12 écarts v2 traités (3 BLOQUANTS + 9 MAJEURS tous corrigés).
3. Nouveaux écarts v3¶
BLOQUANTS (1)¶
| ID | Source | Description |
|---|---|---|
| ECT-01-v3 | Review P1 | upload_object_key non défini dans §5.1 mais inclus dans le fingerprint canonique §5.12. Champ fantôme dans la forme canonique d'idempotence. |
MAJEURS (4)¶
| ID | Source | Description |
|---|---|---|
| ECT-02-v3 | Review P1 | Q-103-07 rétention locale : résolution spec (purge post-UPLOADED) mais gap pour captures UPLOAD_DEFERRED > TTL → politique juridique non tranchée. |
| ECT-03-v3 | Review P1 | Aucune annulation possible depuis UPLOAD_DEFERRED (transition manquante). |
| ECT-04-v3 | Review P1 | upload_object_key variable entre tentatives casse l'idempotence en reprise différée (nouvelle URL pré-signée = nouveau key = nouveau fingerprint). |
| ECT-05-v3 | Review P1 | Exclusion de timestamp_device/device_id du canonique non justifiée ni testée adversarialement. |
MINEURS (5)¶
| ID | Source | Description |
|---|---|---|
| DIV-01-v3 | Confrontation | Baseline documentaire non univoque (v2 + v3 dans même fichier spec). |
| DIV-02-v3 | Confrontation | Contrat API §10.2 Q-103-03 liste 202/200/409/400/429 mais tests exigent aussi 422/503. |
| DIV-03-v3 | Confrontation | Traçabilité INV-103-38/CA-103-27 partiellement incohérente. |
| DIV-04-v3 | Review P1 | device_id sans règle de normalisation. |
| DIV-05-v3 | Review P1 | Échec AbortMultipartUpload non contractualisé. |
Analyse du BLOQUANT ECT-01-v3¶
Le champ upload_object_key est cité dans le fingerprint canonique mais : - N'est pas défini dans le modèle de données §5.1 - Est lié à ECT-04-v3 : si l'URL pré-signée change entre tentatives, le key change, le fingerprint change, l'idempotence casse
Proposition de résolution : Exclure upload_object_key du fingerprint canonique. La forme canonique d'idempotence devrait être basée sur les champs immutables de la capture : capture_id (normalisé) + content_hash. Le upload_object_key est un artefact d'infrastructure, pas de la capture elle-même.
4. Scoring v3¶
| Critère | Score v1 | Score v2 | Score v3 | Delta v2→v3 |
|---|---|---|---|---|
| completeness | 5.0 | 6.5 | 8.0 | +1.5 |
| testability | 5.0 | 6.5 | 8.0 | +1.5 |
| clarity | 6.0 | 7.0 | 7.5 | +0.5 |
| traceability | 7.0 | 8.0 | 8.5 | +0.5 |
Justification des scores :
- completeness 8.0 : 12/12 écarts v2 corrigés. 35 invariants (vs 30 v2). Seul gap :
upload_object_keyfantôme (1 BLOQUANT résiduel, mais avec proposition de résolution claire). La couverture crypto, rotation KEK, GC orphelins, clearing SEAL_DELAYED sont tous contractualisés. - testability 8.0 : Matrice couverture 35/35 INV → TC. Tous les tests en GIVEN/WHEN/THEN. Les 4 MAJEURS résiduels sont des précisions de périmètre (annulation UPLOAD_DEFERRED, justification exclusion champs canonique) et non des gaps de testabilité.
- clarity 7.5 : Structure améliorée mais coexistence v2/v3 dans le même document crée du bruit (DIV-01-v3). Le contrat API a une incohérence mineure entre §10.2 et les tests (DIV-02-v3).
- traceability 8.5 : INV → CA → TC matrice complète. Seule faiblesse : INV-103-38/CA-103-27 mapping partiellement incohérent (DIV-03-v3).
Moyenne v3 : (8.0 + 8.0 + 7.5 + 8.5) / 4 = 8.0
5. Avis auditeur¶
Progression significative et continue sur les 3 itérations (5.75 → 7.0 → 8.0).
Le BLOQUANT résiduel ECT-01-v3 (upload_object_key dans fingerprint canonique) a une proposition de résolution claire et consensuelle : exclure ce champ de la forme canonique. C'est un ajustement mineur de la définition §5.12, pas une refonte.
Les 4 MAJEURS résiduels sont des précisions de périmètre (politique UPLOAD_DEFERRED, annulation, justification exclusion champs) qui ne remettent pas en cause l'architecture ni la testabilité du flux principal.
La recommandation est RESERVE avec lever des réserves : les écarts identifiés sont résolubles en correction mineure et ne justifient pas une itération supplémentaire de gate.