Gate 5 — Confrontation PD-63¶

Défenseur : Claude (auteur du plan) Date : 2026-02-20

ECT-01 — Journalisation rejets 401 non couverte¶

Verdict : ACCEPTÉ

Argumentation : Le reviewer a raison. Le plan se concentre sur les deltas Δ1-Δ8 par rapport à PD-46, mais ne traite pas explicitement la journalisation des rejets précoces (401 par OidcJwtAuthGuard).

La spec INV-63-05 est claire : "Chaque demande de téléchargement (acceptée ou rejetée) produit un événement journalisé probatoire". Cela inclut les 401.

Cependant, il faut noter que : - PD-46 existant a probablement un intercepteur global d'audit - Le plan devrait expliciter si cet intercepteur est déjà présent ou doit être ajouté

Action corrective : Ajouter une tâche 0 (Phase 0) : "Vérifier/implémenter intercepteur audit global pour rejets 401/403/404 précoces".

ECT-02 — Champs modèle incomplets¶

Verdict : ACCEPTÉ

Argumentation : Le reviewer a factuellement raison. La spec §3 définit clairement : - deleted_at (timestamp nullable) — présent dans le plan - deletion_reason (enum/code) — absent du plan - legal_lock (bool) — présent dans le plan - legal_lock_reason (code) — absent du plan - legal_lock_until (timestamp nullable) — absent du plan

Le plan Δ6 mentionne "Champs modèle 410/423" mais ne détaille que deleted_at et legal_lock, omettant 3 champs requis.

Action corrective : Compléter la migration (tâche 1) pour inclure les 5 champs : - deleted_at TIMESTAMP NULL - deletion_reason VARCHAR(50) NULL - legal_lock BOOLEAN DEFAULT false - legal_lock_reason VARCHAR(50) NULL - legal_lock_until TIMESTAMP NULL

AMB-01 — Critère "restauré" pour ARCHIVED non défini¶

Verdict : NUANCÉ

Argumentation : Le reviewer identifie une vraie ambiguïté. Cependant :

1. La spec §3.1 dit "Oui (si restauré)" mais ne définit pas le mécanisme de restauration
2. La restauration Glacier est une opération asynchrone externe (AWS Glacier restore)
3. Le critère "restauré" est hors périmètre PD-63 (cf. spec §10 "Points à clarifier" point 3)

Le plan ne peut pas définir ce que la spec laisse explicitement ambigu. Le critère correct est : si le document est ARCHIVED et que l'objet S3 n'est pas accessible (Glacier), retourner 503.

Action corrective : Ajouter une note dans la tâche 8 : "Si statut=ARCHIVED, vérifier accessibilité S3 via HEAD Object. Si non accessible (Glacier non restauré), retourner 503 (ERR-63-10)".

Gravité ajustée : Mineur (ambiguïté héritée de la spec, comportement déterministe possible).

ECT-03 — Matrice d'erreurs ERR-63 non exhaustivement couverte¶

Verdict : NUANCÉ

Argumentation : Le reviewer demande un mapping exhaustif ERR-63-01..11 vers tâches/tests. Le plan fournit : - Section 3 : mapping INV → mécanismes (tous les 10 INV couverts) - Section 4 : mapping CA → tests (tous les 10 CA couverts)

Les codes d'erreur ERR-63-* sont des conséquences observables des mécanismes, pas des mécanismes eux-mêmes. Le plan couvre implicitement : - ERR-63-01 (400) : validation ID dans guard existant - ERR-63-02 (401) : OidcJwtAuthGuard existant - ERR-63-03/04 (403) : DocumentAccessGuard (tâches 6-8) - ERR-63-05 (404) : query DB existant - ERR-63-06 (410) : check statut (tâche 8) + champs modèle (tâche 1-2) - ERR-63-07 (423) : check legal_lock (tâche 8) - ERR-63-09 (500) : gestionnaire d'erreurs NestJS existant - ERR-63-10 (503) : S3 indispo → géré par S3PresignService existant - ERR-63-11 (503) : audit fail-closed (tâche 11)

Cependant, un tableau de mapping explicite ERR → tâche améliorerait la lisibilité.

Action corrective : Ajouter une section 4b "Mapping ERR → Mécanismes/Tâches" pour expliciter la couverture.

Gravité ajustée : Mineur (couverture implicite présente, formalisation manquante).

SEC-01 — Ambiguïté fail-closed vs retry¶

Verdict : ACCEPTÉ

Argumentation : Le reviewer a raison. La mention "file d'attente + retry" dans les points de vigilance est mal formulée et pourrait être interprétée comme un contournement du fail-closed.

Le comportement correct (INV-63-05) est : 1. Appeler le service d'audit de façon synchrone 2. Si l'audit échoue → rejeter immédiatement (ERR-63-11) 3. Ne jamais délivrer d'URL si l'audit n'est pas confirmé

La "file d'attente + retry" concerne l'infrastructure audit (haute disponibilité du service), pas le comportement applicatif.

Action corrective : Reformuler le point de vigilance 1 : "Risque : Audit fail-closed peut bloquer téléchargements si service audit indisponible. Mitigation : Infrastructure haute disponibilité pour le service audit (réplication, health checks). Le comportement applicatif reste fail-closed strict — pas de retry applicatif."

AMB-02 — Hypothèses sans vérification go/no-go¶

Verdict : ACCEPTÉ

Argumentation : Le reviewer a raison. Les hypothèses H-IMPL-01 à H-IMPL-04 sont documentées avec leur "impact si faux" mais aucune tâche ne les vérifie explicitement avant l'implémentation.

Cela crée un risque de blocage tardif.

Action corrective : Ajouter une Phase 0 — Vérifications préalables : | # | Tâche | Agent | Critère | |---|-------|-------|---------| | 0a | Vérifier table document_shares | agent-developer | Table existe ou créer ticket | | 0b | Vérifier claims JWT tenant_id/roles | agent-developer | Claims présents ou ticket Keycloak | | 0c | Vérifier RLS vault_secure.documents | agent-developer | RLS active ou documenter migration | | 0d | Vérifier schéma audit enrichi | agent-developer | Service compatible ou adapter |

Si un critère échoue → créer ticket bloquant et escalader avant Phase 1.

Synthèse confrontation¶

Écarts confirmés : 2 bloquants, 2 majeurs, 2 mineurs

Actions correctives requises : 1. Ajouter Phase 0 — Vérifications préalables (4 tâches) 2. Compléter migration avec 5 champs (pas 2) 3. Ajouter note ARCHIVED → HEAD Object → 503 4. Ajouter section 4b mapping ERR → tâches 5. Reformuler mitigation fail-closed (infra vs appli) 6. Ajouter tâche intercepteur audit global

Généré par : Claude (défenseur du plan) Date : 2026-02-20