PD-295 — Dossier de conformité (Étape 3, itération v3 — dernière avant plafond Art. I)¶

Type de gate : CONFORMITY_CHECK¶

1. Documents de référence¶

• PD-295-besoin — présent
• PD-295-specification (v3) — présent
• PD-295-tests (v3) — présent
• PD-295-review-step3-v3 (Claude, P1) — présent
• PD-295-confrontation-step3-v3 (Codex, P2) — présent
• PD-295-verdict-step3-v1 (NON_CONFORME 5.812) — présent
• PD-295-verdict-step3-v2 (NON_CONFORME 6.188, convergence ESCALADE) — présent

2. Évolution v1 → v2 → v3¶

La v3 révèle des problèmes qualitativement nouveaux que les v1/v2 n'avaient pas détectés. Ce n'est plus une dérive de précision : c'est une remontée en profondeur dans les invariants de sécurité et de conformité.

3. Écarts v3 — Vue synthétique¶

3.1 BLOQUANTS (5)¶

3.2 MAJEURS (17 — synthèse)¶

Parmi les plus saillants :

• G3v3-M1 : INV-295-22 (top reuse_score) non observable — TC-NOM-08 vérifie seulement le code retour 0, un /morning arbitraire passerait.
• G3v3-M2 : Contradiction tests §9 ↔ TC-NOM-21..32 (testabilité CS-⅔/4). Les tests se contredisent eux-mêmes sur la mesurabilité des KPI.
• G3v3-M3 : Réentrance fcntl.flock en B5 non spécifiée — un même processus peut-il prendre deux read-locks imbriqués ?
• G3v3-M4 : NFS / atomicité écriture JSONL : les write-locks fcntl ne garantissent rien sur NFS v3, pas de contrat.
• G3v3-M5 : Étape 8 de N3 (gel baseline CS-1 dans flux périodique) indéfinie — qui déclenche le gel, quand exactement ?
• G3v3-M6 : HMAC symétrique sans chaîne append-only : un administrateur qui rote la clé peut réécrire l'historique.
• G3v3-M7 : Mapping ST-295-XX ↔ TC-NOM-XX absent de la section 2 des tests.
• G3v3-M8 : Encodage clé Vault (hex vs bytes) sous-spécifié.
• G3v3-M9 : schema_version: 3 sans politique de compatibilité/migration des événements historiques.
• G3v3-M10 : Bornes numériques min_score_default = 0.99 sans justification vs plafond tanh(100/10) ≈ 1.000000.
• G3v3-M11 à M17 : divers points d'observabilité, de dérive d'horloge, de comportement bord purge 18 mois, de politique de démotion manuelle, de Q-295-03 / Q-295-07 non tranchées.

3.3 MINEURS (17)¶

Les 17 mineurs touchent l'ergonomie des tests, les bornes numériques non chiffrées, des ambiguïtés de wording, et des manques d'observables. Impact individuel : -0.25 point.

4. Scoring par critère¶

completeness — 5 bloquants touchent directement la complétude (payload HMAC, contradiction invariants, RGPD incomplet, trou d'audit, vérification non testable) + plusieurs majeurs :

• 10 − (5×2) − (8×1) − (10×0.25) = 10 − 10 − 8 − 2.5 = -10.5 → plancher 0

testability — HMAC non testable + contradiction tests internes + observabilité INV-295-22 :

• 10 − (2×2) − (6×1) − (5×0.25) = 10 − 4 − 6 − 1.25 = -1.25 → plancher 0

clarity — ambiguïtés payload_canonique, contradictions INV↔ERR, encodage clé Vault, bord purge :

• 10 − (1×2) − (5×1) − (8×0.25) = 10 − 2 − 5 − 2 = 1.0

traceability — trou d'audit (traçabilité bypassable), HMAC non reproductible, RGPD non traçable :

• 10 − (3×2) − (4×1) − (5×0.25) = 10 − 6 − 4 − 1.25 = -1.25 → plancher 0

Ces scores sont extrêmes car la v3 a révélé des problèmes qualitatifs profonds. Je retiens les valeurs arithmétiques strictes (plancher 0 pour les critères négatifs).

5. Analyse de convergence¶

Delta v2 → v3 = -5.938 : régression massive. Ce n'est pas un plateau, c'est une régression qualitative : la v3 a introduit des corrections qui ont révélé des problèmes plus profonds que celles qu'elle résolvait.

6. Verdict¶

Plafond Art. I atteint : 3 itérations effectuées, la dernière est NON_CONFORME avec régression. La règle est absolue :

CONSTITUTIONAL Article I — Si NON_CONFORME après v3 → ESCALADE systématique, quelle que soit la convergence.

• GO
• RESERVE
• NON_CONFORME (correction v4 possible) → INTERDIT par le plafond Art. I
• ESCALADE — décision PO requise. Plafond 3 itérations atteint. La v3 a révélé des problèmes qualitatifs profonds (RGPD, design de chaîne d'audit, sérialisation canonique HMAC) qui dépassent le cadre d'une correction de spec — c'est un signal "pause et refonte".

7. Recommandation à l'escalade¶

Les 5 bloquants v3 ne sont pas des défauts de Codex : ils sont la trace d'une exploration incomplète du périmètre au moment de rédiger le besoin. Trois directions possibles pour trancher :

1. Descope : retirer B2 (clarifications PO) du périmètre PD-295. La brique B2 est la source de 3 des 5 bloquants (B4 RGPD, et indirectement B1+B3 via la nécessité d'auditer les accès aux clarifications). Les 4 autres briques B1+B3+B4+B5 sont implémentables sans B2. Créer une story séparée PD-29X "B2 clarifications avec design RGPD correct" à traiter après un travail amont sur le filtrage PII.

2. Design upfront : produire un document de design séparé (hors workflow gov) sur (a) format payload HMAC canonique, (b) chaîne d'audit append-only (append-only log + Merkle, ou chaînage hash), © filtrage PII à l'ingestion des clarifications. Puis relancer PD-295 avec ce design en entrée du step 0.

3. Abandon : fermer PD-295 sans merge, capitaliser les 3 itérations en learnings (plafond atteint signale un besoin sous-exploré), réintégrer les 5 briques dans des stories plus petites et mieux cadrées.

Ma recommandation : option 1 (descope B2). C'est la plus pragmatique, elle préserve 80 % de la valeur (B1+B3+B4+B5 = veille + scoring + promotion/éviction + injection unifiée des 2 sources restantes), et elle isole le problème RGPD dans une story dédiée qui pourra être traitée correctement avec un design amont.