Aller au contenu

PD-80 — Plan d'implémentation : Revue

1. Références

  • Spécification : PD-80-specification.md (v3)
  • Tests contractuels : PD-80-tests.md (v3)
  • Plan d'implémentation : PD-80-plan.md
  • Code Contracts : PD-80-code-contracts.yaml (v1.0.0)
  • Date de revue : 2026-03-12
  • Reviewer : ChatGPT gpt-5.3-codex (review initiale) + Claude Opus 4.6 (confrontation consolidée)
  • Note Art. II : dérogation validation croisée — prompt > 30KB, ChatGPT en mode agentic partiel. Consolidation par Claude sur documents complets.

2. Constatations (écarts)

# Type Référence (Spec/Test/Plan) Description Impact Gravité
ECT-01 Hypothèse implicite INV-80-11 / Plan DA-05 / §3 mapping INV-80-11 Le plan crée deux queues BullMQ séparées (priority-tsa, priority-anchor) via DA-05 et affirme que le « ratio 5:1 est appliqué via limiter BullMQ sur les workers partagés ». Or, limiter BullMQ contrôle le débit par queue (max jobs / durée), pas un ratio pondéré inter-queues. Le mécanisme précis permettant de garantir que le débit standard reste ≥ 16.7% sur une fenêtre de 10 minutes n'est pas décrit. De plus, aucune métrique dédiée au ratio standard/prioritaire n'est exposée (C8 expose 4 métriques, aucune ne mesure le throughput standard relatif). TC-NOM-08 potentiellement irréalisable avec l'architecture décrite. INV-80-11 non démontrable pour audit. MAJEUR
ECT-02 Risque sécu/conformité INV-80-09 / Spec §5.14 / Plan §2.1 Flux A Dans le Flux A, SealCryptoService.generateAndWrapDek(sealId) est appelé après le COMMIT de la transaction d'admission. Un crash entre le COMMIT et l'écriture de wrapped_dek laisse un seal en QUEUED_PRIORITY sans DEK. Le processor TSA traiterait alors un job sans matériel crypto. La spec §5.14 stipule « La DEK est immédiatement wrappée par la KEK HSM ». Le plan ne documente pas cette fenêtre de vulnérabilité ni le comportement du processor en absence de DEK. Le worker de réconciliation (C7) recrée le job BullMQ mais ne régénère pas la DEK manquante. Fenêtre de crash avec seal admis mais sans DEK wrappée. Risque de traitement sans chiffrement des artefacts temporaires (violation INV-80-09) ou erreur non gérée au processing. MAJEUR
ECT-03 Hypothèse implicite INV-80-04 / Plan C8 / TC-NOM-03 C8 décrit l'utilisation de prom-client Histogram pour seal_latency_seconds avec « P95 calculé sur fenêtre 24h glissante ». Les Histograms Prometheus accumulent des compteurs monotoniques — ils ne supportent pas nativement une fenêtre glissante avec seuil minimum d'échantillons (N≥100) et marquage INSUFFICIENT_DATA. Le plan ne précise pas si la logique P95/fenêtre/N-min est côté applicatif (ring buffer) ou côté requête PromQL. TC-NOM-03 exige « Le calcul P95 utilise exactement les N échantillons de la fenêtre (pas de sous-échantillonnage) » et « Si N < 100, P95 marqué INSUFFICIENT_DATA » — non réalisable avec un Histogram Prometheus standard sans logique applicative complémentaire. Testabilité de TC-NOM-03 incertaine. Observabilité P95 contractuelle non démontrée. MAJEUR
ECT-04 Contrainte technique non documentée Plan §8 (HT-01 à HT-10) / Axe 7 review Les hypothèses techniques listent 10 dépendances inter-PD (PD-39 TsaService, PD-55 AnchorService, PD-54 MerkleService, PD-35 CryptoModule, PD-105 NotificationsModule, etc.) mais aucune n'indique son statut actuel (DONE / TODO / STUB acceptable). L'auditeur ne peut pas évaluer la readiness du plan sans cette information. Traçabilité de dépendances incomplète pour évaluation de faisabilité. MAJEUR
ECT-05 Contrainte technique non documentée Plan §12 / Axe 7 review Le framework de test n'est pas explicitement fixé. §12 mentionne « testcontainers » et « couverture 80% » mais ni Jest ni Vitest ne sont nommés. La convention NestJS est Jest, mais elle doit être contractualisée pour éviter toute ambiguïté d'exécution en CI. Ambiguïté d'exécution des suites de test contractuelles. MAJEUR
ECT-06 Contrainte technique non documentée Plan global / Axe 7 review Aucune documentation de la compatibilité ESM/CJS. Les dépendances prom-client, bullmq (v5+) sont ESM-first. Le runner de test et la configuration TypeScript doivent être adaptés. Non documenté. Risque d'échec runtime des tests en CI si le runner n'est pas configuré pour ESM. MAJEUR
ECT-07 Hypothèse implicite Plan C4 / Spec §5.2 / CA-04 L'interaction entre batch_size_min (défaut 5) et le flush timeout (batch_time_max = 5 min) n'est pas explicitée. CA-04 exige « lot contient 1..20 preuves ». Si batch_time_max expire avec 2 jobs et batch_size_min=5, le lot est-il flushé (2 < 5) ou le flush est-il retardé ? C4 dit « refuses to process a single job unless batch_time_max expired » mais ne mentionne pas le seuil batch_size_min. Comportement mini-batch ambigu en faible charge. Risque de non-respect du SLA si le flush est retardé au-delà de 5 min. MINEUR
ECT-08 Contrainte technique non documentée Plan global / Axe 7 review Variables CI nécessaires pour les tests d'intégration avec testcontainers (DATABASE_URL, REDIS_URL, CI=true, etc.) non documentées. Reproductibilité CI partielle. MINEUR
ECT-09 Code Contract — Cohérence CC-80-04 / C4 / Spec §5.2 CC-80-04 (priority-anchor-processor) liste l'invariant « INV-80-05: Mini-batch 1..20, flush ≤ 5 min, JAMAIS d'ancrage individuel urgent » mais ne mentionne pas batch_size_min dans les invariants ni dans les forbidden patterns. Le paramètre batch_size_min (§5.2, configurable 1..20) influence directement le comportement du processor mais n'apparaît pas dans le contrat. Frontière contractuelle incomplète pour l'agent implémentant C4. MINEUR

3. Synthèse

  • Nombre d'écarts par gravité : BLOQUANT = 0, MAJEUR = 6, MINEUR = 3.
  • Points critiques :
  • Anti-starvation (ECT-01) : le mécanisme inter-queues n'est pas décrit avec suffisamment de précision pour garantir INV-80-11 et rendre TC-NOM-08 réalisable.
  • Atomicité DEK (ECT-02) : fenêtre de crash entre admission et wrapping DEK non couverte.
  • P95 sliding window (ECT-03) : implémentation Prometheus insuffisante pour la sémantique contractuelle.
  • Contraintes techniques (ECT-04/05/06) : section « Contraintes techniques » absente du plan (statuts dépendances, framework test, ESM/CJS).

4. Verdict de la revue

  • Statut : ⚠️ Accepté avec réserves
  • Motif synthétique : le plan couvre exhaustivement les 11 invariants, les 18 critères d'acceptation et les 40+ tests contractuels avec des mécanismes identifiés et des points d'observabilité. Les 6 écarts MAJEUR portent sur (a) la précision du mécanisme anti-starvation inter-queues, (b) l'atomicité DEK post-commit, © l'implémentation P95 sliding window, et (d) les contraintes techniques obligatoires non documentées. Aucun écart n'invalide l'architecture globale. Les corrections requises sont des précisions de mécanisme, pas des refonte structurelles.