Aller au contenu

PD-180 — Rapport de confrontation (Étape N)

Ce rapport est produit par l'orchestrateur Claude avant chaque gate PMO. Il confronte les documents produits pour identifier convergences, divergences et zones d'ombre.

1. Sources confrontées

  • Spécification canonique PD-180 (Étape 1 — Specification), sections 1 à 10.
  • Scénarios de tests contractuels PD-180 (Étape 2 — Tests & Validation), sections 1 à 10.

2. Convergences

  • Le périmètre fonctionnel est aligné : CRUD webhook org, ping, replay, rotation secret, livraison asynchrone, retry, journalisation append-only, isolation multi-tenant (Spec §2/§5 ; Tests §3/§4/§5).
  • Les invariants de sécurité sont couverts de façon cohérente : HMAC X-ProbatioVault-Signature, anti-rejeu ±5 min, HTTPS-only, refus des redirections 3xx, secret non exposé, orgId issu JWT (Spec §4 ; Tests matrice §2 + tests dédiés §5).
  • Le modèle d’états et les transitions critiques sont cohérents : ACTIVE/INACTIVE/DELETED côté webhook et PENDING/IN_PROGRESS/RETRY_SCHEDULED/DELIVERED/FAILED côté livraison, avec terminalité de DELETED, DELIVERED, FAILED (Spec §5.10 ; Tests TC-NOM-03/04, TC-NEG-08, TC-INV-13).
  • Les cas d’erreur contractuels sont repris sans contradiction (ERR-01 à ERR-12), y compris les statuts tolérés quand alternatifs (409 ou 422, 403 ou 404) (Spec §6 ; Tests §4).
  • La non-régression probatoire est explicitement convergente : le système webhook ne doit pas muter les états probatoires (Spec INV-11/CA-12 ; Tests TC-NOM-13, TC-NR-07).
  • Les deux documents reconnaissent explicitement des zones non fermées (formats/bornes/politiques temporelles), sans tenter de masquer ces manques (Spec §10 ; Tests §9).

3. Divergences

⚠️ Les conflits ne doivent JAMAIS être lissés. Chaque divergence est rendue visible.

  • DIV-01 : Contradiction sur la testabilité exhaustive du contrat.
  • Source A (Spécification, §1) : « Toute règle ci-dessous est testable, sauf mention explicite hors périmètre ».
  • Source B (Tests, §9 + §10) : plusieurs règles sont déclarées « non testables » (hash encoding, canonicalisation JSON, format secret, purge vs append-only, etc.) et verdict « testable partiellement ».

  • Impact : risque de gate biaisée (conformité déclarée sur un contrat incomplet) et interprétations divergentes entre équipes.

  • DIV-02 : Incohérence de référence Epic.

  • Source A (Spécification, Références) : Epic PD-186 — Backend Core.
  • Source B (Tests, §1 Références) : Epic EPIC-XX (placeholder).
  • Impact : rupture de traçabilité documentaire/audit (Art. III), risque de rattachement Jira/Gate incorrect.

4. Zones d'ombre

  • Encodage contractuel de data.hash non défini (hex/base64/base64url).
  • Longueur maximale de target_url non définie.
  • Taille maximale de data.metadata non définie.
  • Règle de canonicalisation JSON pour la signature <timestamp>.<body_json> non définie.
  • Format/longueur minimale du secret HMAC non définis.
  • Compatibilité exacte entre invariant append-only et purge/rétention 30 jours non explicitée.
  • Politique de retry incomplète au-delà des premiers paliers (après 1m, 5m, 15m, 1h).
  • Source de temps de référence anti-rejeu (horloge autoritative) non spécifiée.
  • Nature de la fenêtre de rate-limit (glissante vs fixe) non définie.
  • SLA de latence notification (p95/p99 contractuel) absent.

5. Recommandation

  • Procéder — convergence confirmée, aucun conflit bloquant
  • Rework nécessaire — divergences à résoudre avant de continuer
  • Escalade — décision humaine requise sur un point structurant