Gate 3 — Specification Review v2¶
Story: PD-44 Gate: 3 (CONFORMITY_CHECK) Reviewer: ChatGPT (gpt-5.3-codex) Date: 2026-02-17
review:
story: PD-44
gate: 3
type: CONFORMITY_CHECK
version: 2
reviewer: chatgpt
date: 2026-02-17
scores:
completeness: 8.0/10
testability: 7.5/10
clarity: 7.5/10
traceability: 7.5/10
mean: 7.63/10
gaps:
- id: ECT-44-01
type: traceability
severity: MAJEUR
description: |
La matrice INV -> CA -> TC ne trace pas explicitement ERR-44-11
(modification administrative suspecte), alors que ce cas est défini
dans la spécification (Section 6) et clarifié contractuellement (Section 10.8).
Le tableau de couverture mentionne 24 lignes mappées, mais pas de ligne
dédiée à INV/CA/TC pour ce scénario (TC-ERR-11 n'est pas visible dans la matrice).
recommendation: |
Ajouter un mapping explicite pour ERR-44-11 dans la matrice
(invariant cible, CA cible, test case dédié), et détailler les observables
testables (présence ID Jira dans CloudTrail, appartenance IAM worm-administrators).
- id: ECT-44-02
type: clarity
severity: MAJEUR
description: |
Tension contractuelle entre INV-44-05 ("Tout objet du périmètre doit disposer
d'une rétention effective >= minimum requis") et Section 10.4
(DEEP_ARCHIVE validé bucket uniquement, objets exclus de l'échantillonnage).
La règle est opérationnellement compréhensible, mais la relation exacte avec
l'invariant objet n'est pas explicitée.
recommendation: |
Préciser explicitement que DEEP_ARCHIVE relève d'une modalité de preuve
compensatoire (preuve bucket + politique par défaut) et adapter la formulation
d'INV-44-05/CA-44-05 pour lever toute ambiguïté d'interprétation.
- id: ECT-44-03
type: testability
severity: MINEUR
description: |
Section 10.2 fixe 5% d'échantillonnage pour objets existants avec mention
"couverture statistique suffisante", mais sans paramètre mesurable
(niveau de confiance, marge d'erreur, stratégie de tirage reproductible).
Cela limite l'automatisation d'un verdict objectivement vérifiable.
recommendation: |
Ajouter un critère statistique contractuel minimal (ex. confiance, erreur tolérée)
et une méthode d'échantillonnage déterministe/reproductible (seed, période, strata).
resolved_reserves:
- id: R-44-01
status: RESOLVED
evidence: |
Section 10.1 définit intervalle nominal (60 min), tolérance (15 min)
et règle explicite de déclenchement ERR-44-09 à 75 min.
- id: R-44-02
status: RESOLVED
evidence: |
Section 10.2 fixe une couverture explicite:
objets récents 100%, objets existants 5%, buckets 100%.
- id: R-44-03
status: RESOLVED
evidence: |
Section 10.3 formalise le tag Compliance (NF-Z42-013/ISO-14641/eIDAS)
et le mode requis COMPLIANCE pour "probatoire strict".
- id: R-44-04
status: RESOLVED
evidence: |
Section 10.4 fige la règle DEEP_ARCHIVE bucket-only avec justification SLA.
- id: R-44-05
status: RESOLVED
evidence: |
Section 10.5 impose DeleteMarkerReplication.Status = Disabled
et le rattache à ERR-44-08 en cas d'écart.
- id: R-44-06
status: RESOLVED
evidence: |
Section 10.6 impose un schéma YAML canonique et hash SHA3-256,
avec règle de calcul d'intégrité explicite.
positive_points:
- description: |
La Section 10 transforme les réserves v1 en règles contractuelles mesurables,
avec seuils explicites (75 min), format de preuve normé et paramètres figés.
- description: |
La couverture fonctionnelle est globalement solide: 12 invariants et 12 CA
sont adressés dans la matrice avec scénarios nominaux et erreurs.
- description: |
L'approche multi-cloud et réplication (OVH/AWS + source/cible) est traitée
de façon homogène, ce qui renforce la conformité probatoire transverse.
verdict_suggestion: RESERVE
rationale: |
Les 6 réserves v1 sont bien traitées contractuellement et lèvent les ambiguïtés initiales.
Cependant, des écarts résiduels subsistent sur la traçabilité complète (ERR-44-11 non mappé),
la cohérence explicite de l'invariant objet avec le cas DEEP_ARCHIVE, et la mesurabilité
statistique du 5% d'échantillonnage. La moyenne est >= 7/10 mais plusieurs scores sont < 8/10,
ce qui conduit à une suggestion RESERVE.