Je vais analyser les deux documents d'entrée pour produire la review de spécification.

PD-80-specification-review.md¶

Résultats de la revue de spécification PD-80¶

E-01 — Note de brouillon non résolue dans §5.3¶

Type : Ambiguïté Référence : Spec §5.3, transition TSA_PENDING -> TSA_SEALED, colonne Min Description : La cellule contient 1h? non, 1 min min — une annotation de rédaction non résolue, laissée en l'état dans un document présenté comme contractuel. Impact : Valeur minimale contractuelle indéterminable pour cette transition. Gravité : Bloquant

E-02 — QUEUED_PRIORITY absent du tableau SLA §5.3¶

Type : Contradiction Référence : Spec §5.3 (transitions SLA) vs §5.4 (machine d'états) Description : La machine d'états §5.4 définit l'état QUEUED_PRIORITY avec deux transitions (RECEIVED -> QUEUED_PRIORITY et QUEUED_PRIORITY -> TSA_PENDING). Le tableau SLA §5.3 omet entièrement cet état : il liste RECEIVED -> TSA_PENDING comme "immédiat" sans passer par QUEUED_PRIORITY. Les deux sections décrivent des flux incompatibles. Impact : Impossible de déterminer le SLA contractuel de la phase d'admission en queue prioritaire. Gravité : Bloquant

E-03 — Fenêtre P95 non contractualisée¶

Type : Non testable Référence : Spec §5.2 sla_global_max, INV-80-04, CA-03, H-03, §10.2.1 ; Tests TC-NOM-03, §9 Description : Le SLA P95 < 60 min est l'exigence centrale de la story, mais la fenêtre d'agrégation (1h glissante, 24h, 7j) n'est pas définie. La spec le reconnaît elle-même en H-03 et §10.2.1. Le test TC-NOM-03 mentionne "fenêtre d'observation définie" sans la fournir. Impact : Le critère CA-03 est non testable en l'état — tout résultat de mesure est contestable faute de définition de la fenêtre. Gravité : Bloquant

E-04 — Interaction retries/backoff vs transitions retour de la machine d'états¶

Type : Ambiguïté Référence : Spec §5.2 retry_delays [1,5,15,30] vs §5.4 transitions retour Description : §5.2 définit des délais de retry [1,5,15,30] minutes. §5.4 autorise TSA_PENDING -> QUEUED_PRIORITY (retry requeue) et TSA_SEALED -> TSA_PENDING (retry technique). Mais la spec ne définit pas : (a) si chaque retry implique un changement d'état ou reste dans le même état, (b) comment le compteur de retry se corrèle aux transitions retour, © quel état est atteint après épuisement des 4 retries (le 5e échec). Impact : Comportement indéterminé aux transitions de retry — l'implémenteur doit deviner la sémantique. Gravité : Majeur

E-05 — TC-ERR-04 teste la validation d'artefacts produits par le système¶

Type : Incohérence Spec↔Tests Référence : Tests TC-ERR-04 vs Spec §5.1, §5.5, §5.6 Description : TC-ERR-04 teste le rejet 422 pour tsa_token non parseable, merkle_proof invalide, blockchain_tx invalide. Or ces artefacts sont des sorties générées par le pipeline interne (TSA, Merkle, blockchain), pas des entrées utilisateur. Les flux §5.5 et §5.6 ne montrent aucun point où l'utilisateur soumet ces artefacts. Le test suppose un scénario d'injection que la spec ne décrit pas. Impact : Le test couvre un cas non spécifié — soit la spec manque un flux de validation interne, soit le test est hors périmètre. Gravité : Majeur

E-06 — "Résolution manuelle uniquement" non définie¶

Type : Ambiguïté Référence : Spec §5.4, états SEALED et FAILED_TIMEOUT Description : Les deux états terminaux portent la mention "résolution manuelle uniquement" mais aucun mécanisme de résolution manuelle n'est spécifié (API admin, procédure opérationnelle, transition de correction). Le terme est utilisé comme si une définition existait ailleurs. Impact : Un opérateur ne sait pas comment intervenir sur un FAILED_TIMEOUT pour relancer ou corriger. Gravité : Majeur

E-07 — "Progression continue" sans seuil observable¶

Type : Non testable Référence : Spec INV-80-11, CA-13 ; Tests TC-NOM-08 Description : INV-80-11 exige "pas de starvation du flux standard" avec ratio 5:1. CA-13 demande "progression continue des jobs standard sous charge mixte". TC-NOM-08 vérifie "progression continue (pas de blocage durable)". Aucun seuil n'est défini : débit minimum, latence maximale d'un job standard, durée maximale sans traitement. "Durable" est subjectif. Impact : Un test ne peut que constater débit > 0 sur une fenêtre arbitraire — insuffisant pour discriminer conformité vs non-conformité. Gravité : Majeur

E-08 — Politique de retry webhook absente¶

Type : Ambiguïté Référence : Spec INV-80-08, CA-11, §5.1 webhook_payload ; Tests TC-NOM-06 Description : TC-NOM-06 vérifie que "la tentative et le résultat de livraison sont journalisés", mais la spec ne définit aucune politique de retry pour les webhooks échoués (timeout endpoint, nombre de retentatives, backoff). INV-80-08 impose "notification de résultat obligatoire" — si le webhook échoue sans retry, l'invariant est violé. Impact : Comportement indéterminé en cas d'échec de livraison webhook. Gravité : Majeur

E-09 — Atomicité async post-commit et réconciliation non testable¶

Type : Hypothèse dangereuse Référence : Spec §5.7, INV-80-10 ; Tests TC-NOM-10 Description : §5.7 indique que la publication en queue prioritaire est "async post-commit, idempotent, retry-safe" et que le rattrapage post-crash se fait "via worker reconciliation". TC-NOM-10 teste le crash mais le mécanisme de réconciliation n'est pas spécifié : fréquence de scan, critère de détection d'orphelin, délai maximal de rattrapage. L'hypothèse implicite est que le worker de réconciliation existe et fonctionne, mais il n'est défini nulle part. Impact : En cas de crash post-commit, le délai de rattrapage est non borné — le SLA < 60 min peut être violé silencieusement. Gravité : Majeur

E-10 — Enterprise "illimité" sans plafond technique¶

Type : Hypothèse dangereuse Référence : Spec §5.2 quota_enterprise_month = illimité, H-04 Description : Le quota enterprise est "illimité" avec "non applicable" pour min/max/hors bornes. La spec reconnaît le risque en H-04 mais ne le résout pas. Sans plafond technique, un seul compte enterprise peut saturer la queue prioritaire et provoquer la starvation des autres, violant INV-80-11. Impact : Contradiction potentielle entre quota illimité (INV-80-07) et anti-starvation (INV-80-11). Gravité : Majeur

E-11 — Comportement "clamp" silencieux vs observable¶

Type : Ambiguïté Référence : Spec §5.2, colonne "Hors bornes" — batch_size_min, batch_size_max, batch_time_max, priority_weight, standard_weight Description : Plusieurs paramètres sont "clampés" quand hors bornes, avec ou sans "alerte". La spec ne précise pas si le clamp est (a) silencieux, (b) journalisé, © remonté en erreur de démarrage, ni si l'alerte est un log, une métrique, ou une notification opérationnelle. Impact : Comportement non déterministe — un opérateur peut configurer une valeur invalide sans le savoir. Gravité : Mineur

E-12 — Disclosure plan utilisateur via codes erreur différenciés¶

Type : Risque sécu/conformité Référence : Spec §6 (codes 403 vs 429), CA-07, CA-08 Description : Un attaquant peut distinguer 403 (quota épuisé) de 429 (rate-limit dépassé). La combinaison des deux réponses permet de déduire le plan de l'utilisateur (freemium = quota faible, enterprise = jamais 403). Cela constitue une fuite d'information sur le niveau d'abonnement. Impact : Énumération du type de plan par observation des codes d'erreur — risque faible mais réel en contexte B2C. Gravité : Mineur

E-13 — Fallback push sans device non spécifié¶

Type : Ambiguïté Référence : Spec INV-80-08, §10.2.3 ; Tests §9 "Fallback push sans device" Description : INV-80-08 impose "notification de résultat obligatoire" mais §10.2.3 reconnaît que le canal push mobile pour comptes sans device n'est pas défini. Le document de tests le classe comme "non testable" en §9 mais INV-80-08 reste formulé comme non négociable. Impact : Contradiction entre l'exigence de notification obligatoire et l'absence de fallback défini. Gravité : Majeur

E-14 — TC-NOM-03 : N et significativité statistique non définis¶

Type : Incohérence Spec↔Tests Référence : Tests TC-NOM-03 Description : TC-NOM-03 mentionne "N scellements urgents" sans définir N ni la significativité statistique requise pour un calcul P95. Un P95 sur N=20 n'a pas la même valeur qu'un P95 sur N=1000. Impact : Le test est exécutable mais son résultat n'est pas interprétable de manière contractuelle. Gravité : Mineur

E-15 — Synchronisation horloge non spécifiée¶

Type : Hypothèse dangereuse Référence : Spec INV-80-04, §5.1 timestamp_rfc3339 ; Tests TC-NOM-03 Description : Le calcul de latence upload -> SEALED repose sur des timestamps UTC. TC-NOM-03 mentionne "horodatage synchronisé UTC". Mais la spec ne spécifie pas d'exigence NTP/PTP ni de tolérance de dérive d'horloge entre les composants (API, workers BullMQ, TSA externe). Impact : Une dérive d'horloge de quelques secondes entre services pourrait fausser les mesures de SLA, notamment pour les cas proches du seuil 60 min. Gravité : Mineur

Synthèse¶

Points bloquants à lever avant Gate 3 : 1. Note de brouillon non résolue dans §5.3 (E-01) 2. Incohérence machine d'états vs tableau SLA sur QUEUED_PRIORITY (E-02) 3. Fenêtre P95 non définie — critère central non testable (E-03)