Aller au contenu

PD-265 — Rapport de confrontation (Étape 3)

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 — « PD-265 — Monitoring TSA RFC 3161 et cycle de vie des clés opérationnelles » (document d’entrée : SPECIFICATION)
  • Tests — « PD-265 — Scénarios de tests contractuels » (document d’entrée : TESTS)

2. Convergences

  • Couverture directe des invariants et critères d’acceptation : la matrice de tests mappe explicitement INV-265-01..12 vers CA-02..10 (TESTS §2) conformément à la structure et aux exigences de testabilité (SPEC §4, §7).
  • Fail-closed et blocage d’émission TST en dégradé : les tests imposent le refus d’émission de nouveaux TST en DEGRADED_*, DEGRADED et MAINTENANCE (TESTS TC-NOM-01, TC-ERR-01..04, TC-NOM-09, TC-NOM-10), conforme à la politique d’émission (SPEC §5.4).
  • Modèle composite flags->state : les tests vérifient tsaServiceDegradationFlags comme source de vérité et tsaServiceState dérivé, y compris le cas multi-flags => DEGRADED (TESTS TC-ERR-13, TC-NOM-10), conforme (SPEC §5.4, INV-265-11).
  • Clearing contractuel : clearing NTS après 2 contrôles conformes (TESTS TC-NOM-02) conforme (SPEC §5.4), clearing REVOCATION seulement si OCSP=GOOD + CRL=NOT_LISTED + fraîcheur OK (TESTS TC-NOM-03) conforme (SPEC §5.4).
  • Formats/validations strictes (pas d’hypothèse implicite) : tests négatifs sur casse enum, UUIDv4, longueurs hash, bornes config, absence de clamp batch size (TESTS TC-ERR-06/07, TC-NEG-02/04/05/06) conforme au contrat de formats et bornes (SPEC §5.1, §5.2, INV-265-12, ECT-03).
  • Observabilité des alertes critiques signées/horodatées : les tests exigent des événements d’audit signés/horodatés pour les alertes critiques (TESTS TC-ERR-01/02/10/14, §8), cohérent avec le canal probatoire et le format PV_TSA_CRITICAL_ALERT (SPEC §5.9, INV-265-06).

3. Divergences

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

  • DIV-01 — Référence épique : placeholder vs “non renseignée”
  • Source A (SPEC §Références) : « Epic : Référence épique non renseignée »
  • Source B (TESTS §1) : « Epic : EPIC-XX »

  • Impact : ambiguïté de traçabilité (lien artefacts/tests <-> epic), risque de rejet PMO sur auditabilité documentaire (même si les deux indiquent une absence de valeur finale).

  • DIV-02 — Contrat de refus API (motifs normés) exigé par les tests mais non défini dans la spécification

  • Source A (SPEC) : politique de blocage définie par état (SPEC §5.4), mais aucun modèle de réponse de refus / enums de “motif normé” n’est contractualisé dans le modèle de données (§5.1) ni dans un contrat d’API.
  • Source B (TESTS) : exige des motifs normés de refus, ex. « motif normé "MAINTENANCE" » (TESTS TC-NOM-09) et « motif "transition interdite" » (TESTS TC-ERR-12), et mentionne « codes de refus … + motif normé » (TESTS §8).

  • Impact : un implémentateur peut être conforme à la SPEC (blocage effectif) tout en échouant les tests (attentes de payload/message non contractuels), et inversement (risque d’introduire un format implicite en contradiction avec INV-265-12).

  • DIV-03 — Journalisation/événementiel des changements d’état : attendu par les tests, non contractualisé comme “événement” dans la spécification

  • Source A (SPEC) : exige historique consultable et traçabilité, et impose des événements signés/horodatés uniquement pour alertes critiques (SPEC §5.4 “historiques consultables”, §5.9 “alertes critiques”).
  • Source B (TESTS TC-NOM-01) : « Un événement d’état horodaté est tracé » en nominal NTS (sans qualifier CRITICAL, signature, type d’événement).

  • Impact : divergence sur la nature contractuelle de l’événementiel “hors alerte critique” (type, format, signature, canal). Risque de non-conformité aux tests sans qu’une exigence équivalente soit explicitement définie côté SPEC.

  • DIV-04 — Alerte “rotation overdue” : exigée par les tests, statut/sevérité/canal non fixés explicitement par la spécification

  • Source A (SPEC) : KEY_LIFECYCLE défini et blocage TST en DEGRADED_KEY_LIFECYCLE (SPEC §5.4), mais la section “alertes critiques” liste explicitement certains domaines (NTS, révocation, trustlist, re-horodatage deadline, maxDegradedDuration) (SPEC §5.9) sans expliciter le cas “key overdue” dans cette liste, malgré la présence de reasonCode=KEY_OVERDUE dans l’enum (SPEC §5.9).
  • Source B (TESTS TC-ERR-05) : « Alerte de rotation overdue est émise » (sans préciser CRITICAL/signée).
  • Impact : ambiguïté documentée entre exigences de test (alerte attendue) et contrat d’alerting (critique vs non critique, signé vs non signé, canal métriques vs canal probatoire). Cette ambiguïté peut produire des implémentations incohérentes et des validations divergentes.

4. Zones d'ombre

  • Contrat API/IO (hors modèles internes) : format exact des erreurs, codes, et “motifs normés” (tests les supposent ; SPEC ne les définit pas explicitement).
  • Nomenclature des métriques (noms, labels, cardinalité) : explicitement non figée (SPEC §10.2) alors que les tests requièrent des métriques “minimales” (TESTS §8) sans contrat de nommage.
  • Liste normative des serveurs NTS de référence : non définie (SPEC §10.2 ; TESTS §9).
  • Politique d’exceptions en mode dégradé : SPEC mentionne un blocage explicite par état mais liste aussi un cas particulier pour re-horodatage en DEGRADED_KEY_LIFECYCLE (SPEC §5.4) ; les tests ne couvrent pas la matrice complète “re-horodatage autorisé/bloqué par état”, ni le cas “flag unique KEY_LIFECYCLE”.
  • Ordonnancement contractuel de tsaServiceDegradationFlags (tri lexicographique, liste ordonnée) : imposé (SPEC §5.1) mais non testé explicitement (TESTS vérifie “contient”, pas l’ordre ni l’absence de doublons).
  • Clearing TRUSTLIST et KEY_LIFECYCLE : règles définies (SPEC §5.4) mais pas de scénario de test dédié de retour à HEALTHY pour ces flags (coverage partielle).
  • Signature/canonicalisation : SPEC impose canonicalisation déterministe et signature (SPEC §5.9) ; les tests exigent des événements signés pour certaines alertes, mais ne détaillent pas de tests de non-conformité de signature/canonicalisation (ex: clés non triées, signature invalide) ni la vérification stricte “signature invalide => non conforme”.
  • “Export probatoire” : présent pour re-horodatage en retard (SPEC §6, TESTS TC-ERR-10) mais format exact et contenu minimal (colonnes/champs) non contractualisés.

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

Chemin de sauvegarde demandé (non écrit ici) : /Users/loic/Developpement/ProbatioVault/ProbatioVault-backend/docs/epics/legal-compliance/PD-265-monitoring-tsa-lifecycle/PD-265-confrontation-step3.md