Audit Gate 3 — PD-55 Worker ancrage blockchain périodique¶

Synthèse¶

La spécification PD-55 est globalement solide : périmètre bien cadré, invariants formulés de manière contractuelle, et cahier de tests structuré avec matrices de traçabilité. Cependant, l'audit identifie 19 écarts dont 3 bloquants, 9 majeurs et 7 mineurs, principalement concentrés sur des ambiguïtés de seuils/formats non spécifiés, des trous de couverture dans les tests, et des hypothèses temporelles insuffisamment contractualisées.

Écarts identifiés¶

ECT-01¶

Type : Ambiguïté Référence : Spec §5 (flux nominal, étape 1) + §7 CA-55-01 Description : La cadence est définie comme "cible 10 minutes" avec une "tolérance explicitée" dans CA-55-01, mais cette tolérance n'est jamais quantifiée dans la spécification. Aucun seuil numérique (ex: ± 30s, ± 2min) n'est fourni. Le terme "tolérance explicitée" dans le CA renvoie à une valeur qui n'existe pas dans le document. Impact : Impossible de rédiger un test de conformité de cadence : quel écart temporel fait échouer le test ? Un cycle à 12 minutes est-il conforme ou non ? Gravité : Majeur

ECT-02¶

Type : Ambiguïté Référence : Spec §4 INV-55-05 + §3 "Merkle root" Description : Le déterminisme de la racine exige un "même ensemble ordonné" mais la clé de tri normative n'est définie nulle part. Le §10 point 5 le mentionne comme "à clarifier" — or c'est un prérequis à INV-55-05 et au test T55-03. Sans ordre canonique défini, le déterminisme est invérifiable. Impact : Deux implémentations conformes pourraient produire des racines différentes pour le même lot. La vérification externe (INV-55-08) devient impossible si l'ordre n'est pas contractuel. Gravité : Bloquant

ECT-03¶

Type : Ambiguïté Référence : Spec §4 INV-55-08 + §10 point 9 Description : INV-55-08 exige une preuve vérifiable "à partir d'artefacts exportables et données publiques", mais le format de ces artefacts n'est pas spécifié. Le point 9 des "Points à clarifier" le reconnaît explicitement. Sans format contractuel (JSON ? CBOR ? Structure du Merkle proof ?), l'implémentation et le test T55-10 ne peuvent être acceptés formellement. Impact : Le test T55-10 ("vérification de preuve réussie, reconstruction complète") ne peut pas être rédigé car on ne sait pas quoi vérifier ni quel format parser. Gravité : Bloquant

ECT-04¶

Type : Ambiguïté Référence : Spec §6 ERR-55-05 + §10 point 3 Description : Le "timeout contractuel" de finalité n'est pas quantifié. ERR-55-05 fait référence à un timeout, le point 3 des clarifications demande "nombre de confirmations et timeout de décision" — mais ce sont des paramètres structurants pour le cycle de vie du lot. Le test T55-07 ("finalité non atteinte avant timeout") ne peut pas définir ses préconditions. Impact : Impossible de tester ERR-55-05 sans valeur de timeout. L'état "intermédiaire" du lot pourrait durer indéfiniment sans seuil contractuel. Gravité : Majeur

ECT-05¶

Type : Ambiguïté Référence : Spec §3 "Événement éligible" + §10 point 6 Description : La définition d'événement éligible mentionne "événement probatoire validé, non ancré, appartenant à la fenêtre d'agrégation active" mais le périmètre des types d'événements probatoires n'est pas une liste fermée. Le point 6 le reconnaît. Sans liste fermée, la sélection en étape 2 du flux nominal est ambiguë. Impact : Risque d'inclusion/exclusion non déterministe d'événements selon l'interprétation de l'implémenteur. Un type d'événement oublié = trou de couverture probatoire. Gravité : Majeur

ECT-06¶

Type : Incohérence Spec↔Tests Référence : Spec §6 ERR-55-09 + Tests §3 Description : ERR-55-09 spécifie "Échec de persistance d'un lien événement↔lot → pas de finalisation partielle silencieuse". Le test T55-13 couvre INV-55-06 (pas de perte d'événement) mais ne vérifie pas explicitement l'absence de finalisation partielle. Le scénario T55-13 dit "aucune finalisation partielle" mais ne décrit pas comment détecter une finalisation partielle (ex: lot finalisé avec N-1 événements liés sur N). Impact : Le test pourrait passer alors qu'une finalisation partielle a eu lieu si le critère de détection est mal implémenté. Gravité : Majeur

ECT-07¶

Type : Incohérence Spec↔Tests Référence : Spec §4 INV-55-10 + Tests matrice §1 Description : INV-55-10 exige que "toute transition d'état d'un lot ou d'un événement DOIT être journalisée de façon horodatée et corrélable". Le test T55-17 couvre INV-55-10 mais ne vérifie que "trace complète des transitions". La corrélabilité (capacité à relier les logs entre eux via un ID de corrélation cycle/lot) n'est pas un attendu explicite du test. Impact : Le test pourrait valider des logs non corrélables (sans cycle_id ou lot_id dans chaque entrée), rendant l'audit forensic impossible en pratique. Gravité : Mineur

ECT-08¶

Type : Hypothèse dangereuse Référence : Spec §9 HYP-55-02 Description : L'hypothèse "une horloge de référence cohérente est disponible" est critique car elle conditionne INV-55-07 (pas de trou de couverture) et ERR-55-08 (détection des trous). Mais aucun mécanisme de détection de dérive d'horloge n'est spécifié. L'impact documenté ("trous/superpositions") est correct mais la mitigation n'est pas contractualisée. Impact : Un NTP drift non détecté pourrait créer des trous de couverture silencieux, violant INV-55-07 sans déclenchement d'ERR-55-08. Gravité : Majeur

ECT-09¶

Type : Incohérence Spec↔Tests Référence : Tests §3.2 — test T55-06 Description : T55-06 couvre ERR-55-04 mais n'apparaît dans aucune matrice de couverture INV→Tests (§1) ni CA→Tests (§2). ERR-55-04 implique un contrôle d'intégrité qui relève d'INV-55-09 (validation entrées), mais T55-06 n'est pas listé contre INV-55-09. Impact : Écart de traçabilité : T55-06 est orphelin des matrices, rendant la couverture apparemment complète alors qu'un lien manque. Gravité : Mineur

ECT-10¶

Type : Incohérence Spec↔Tests Référence : Tests §3.2 — test T55-07 Description : T55-07 couvre ERR-55-05 mais ne figure dans aucune matrice INV ou CA. ERR-55-05 concerne la non-finalisation avant timeout, ce qui impacte directement INV-55-03 (traçabilité complète — l'état de finalité doit être présent) et potentiellement INV-55-06 (pas de perte). T55-07 devrait apparaître dans la matrice. Impact : Même problème que ECT-09 : test orphelin des matrices de traçabilité. Gravité : Mineur

ECT-11¶

Type : Incohérence Spec↔Tests Référence : Tests §3.2 — test T55-12 Description : T55-12 couvre ERR-55-02 mais ne figure dans aucune matrice INV ou CA. ERR-55-02 (échec calcul racine) est directement lié à INV-55-06 (pas de perte, ré-ancrable). T55-12 devrait apparaître dans la matrice INV-55-06. Impact : Traçabilité incomplète dans les matrices. Gravité : Mineur

ECT-12¶

Type : Non testable Référence : Spec §4 INV-55-12 + Tests T55-14 Description : INV-55-12 exige une "stratégie de continuité documentée et testée au niveau procédure". T55-14 attend "procédure exécutable". Mais les critères de succès de cette procédure ne sont pas définis : qu'est-ce qu'une exécution réussie ? Quel est le délai max acceptable d'accumulation ? Quel est le trigger de reprise ? Impact : Le test T55-14 est subjectif en l'état — un testeur pourrait le valider sur la seule existence d'un document, sans exécution réelle. Gravité : Majeur

ECT-13¶

Type : Ambiguïté Référence : Spec §10 point 8 Description : Aucune volumétrie n'est spécifiée : taille max d'un lot, backlog max acceptable, SLA de résorption. Or ces limites conditionnent le comportement en cas d'indisponibilité prolongée (ERR-55-07). Sans limite, l'accumulation "contrôlée" n'a pas de borne. Impact : En cas d'indisponibilité blockchain de plusieurs jours, le backlog pourrait croître indéfiniment. Aucun test ne vérifie le comportement aux limites de volumétrie. Gravité : Majeur

ECT-14¶

Type : Risque sécu/conformité Référence : Spec §4 INV-55-01 + Tests T55-15 Description : INV-55-01 interdit la publication de "contenu métier brut" on-chain. Mais la frontière entre "empreinte cryptographique" et "métadonnée déductible" n'est pas précisée. Par exemple, si le hash est calculé sur un champ unique prévisible (ex: email), un attaquant pourrait vérifier l'appartenance par brute-force du hash. La spécification ne traite pas le risque de déduction par corrélation. Impact : Conformité RGPD potentiellement compromise si les inputs du hash sont à faible entropie. Gravité : Majeur

ECT-15¶

Type : Hypothèse dangereuse Référence : Spec §9 HYP-55-05 + INV-55-05 Description : HYP-55-05 suppose "le format canonique d'entrée de calcul de hash est défini et stable". Cette hypothèse est critique car elle conditionne INV-55-05 (déterminisme) et INV-55-08 (vérification externe). Mais aucune référence à un standard de canonicalisation (ex: RFC 8785 pour JSON) n'est donnée, ni aucune spécification du format d'entrée du hash. Impact : Sans référence normative, deux implémentations pourraient sérialiser différemment les mêmes données, brisant le déterminisme. Gravité : Bloquant

ECT-16¶

Type : Incohérence Spec↔Tests Référence : Spec §6 ERR-55-08 + Tests T55-09 Description : T55-09 teste la détection de trou de fenêtre temporelle. Cependant, les attendus sont "détection du trou + alerte critique" sans préciser : comment le trou est créé en test ? Quelle est la durée minimale pour constituer un "trou" ? Le test ne spécifie pas de précondition mesurable. Impact : Le scénario de test est difficile à reproduire de manière déterministe sans définition quantitative d'un "trou". Gravité : Mineur

ECT-17¶

Type : Ambiguïté Référence : Spec §5 (flux nominal, étape 7) + §3 "Finalité" Description : La finalité est définie comme "état où la transaction est considérée confirmée selon le seuil configuré" mais ce seuil n'est pas dans la spécification. La distinction entre "publié" et "finalisé" implique un état intermédiaire du lot dont la durée n'est pas bornée. Impact : Le cycle de vie du lot a un état intermédiaire potentiellement indéfini, ce qui complique la gestion des cas limites (restart worker pendant cet état, par exemple). Gravité : Majeur

ECT-18¶

Type : Incohérence Spec↔Tests Référence : Tests §3.3 T55-18 Description : T55-18 teste la "reprise après restart worker" avec attendu "idempotence de reprise". Mais le concept d'idempotence de reprise n'est pas spécifié formellement : que se passe-t-il si le worker restart entre l'étape 5 (publication on-chain) et l'étape 6 (enregistrement tx_id) ? La transaction est publiée mais le lot ne connaît pas encore le tx_id. Ce scénario critique n'est pas couvert explicitement ni dans la spec ni dans les tests. Impact : Risque de double publication on-chain (coût gas, pollution chain) ou de lot orphelin sans tx_id. Gravité : Majeur

ECT-19¶

Type : Mineur — Complétude matrices Référence : Tests §1-2 matrices Description : Les tests T55-06, T55-07, T55-12, T55-18 ne figurent dans aucune matrice de couverture (ni INV ni CA). Inversement, aucun test ne figure dans la matrice pour les cas d'erreur ERR-55-* de manière systématique. Les matrices ne couvrent que INV et CA, pas les ERR. Impact : La traçabilité ERR→Tests n'est pas formalisée, ce qui affaiblit la couverture apparente. Gravité : Mineur

Tableau récapitulatif¶

Statistiques¶

Verdict auditeur¶

NON CONFORME en l'état — 3 bloquants empêchent l'acceptation formelle :

1. ECT-02 : L'ordre canonique des événements dans le lot n'est pas défini — le déterminisme (INV-55-05) et la vérification externe (INV-55-08) sont invérifiables.
2. ECT-03 : Le format des artefacts de preuve externe n'est pas spécifié — INV-55-08 est non testable.
3. ECT-15 : Le standard de canonicalisation des entrées de hash n'est pas référencé — le déterminisme repose sur une hypothèse non contractualisée.

Ces trois points convergent vers un même risque systémique : l'impossibilité de vérification indépendante, qui est pourtant l'objectif fondamental de cette story.

Les 9 majeurs concernent principalement des seuils non quantifiés (cadence, timeout, volumétrie) et des scénarios de crash insuffisamment spécifiés. Ils sont corrigeables sans refonte.