PD-60 — Review spécification¶

Type : Ambiguïté
Référence : Spec §3 (Définitions) — « Empreinte documentaire »
Description : La définition indique « valeur de référence fournie par le client pour lier document et preuve » mais ne précise pas l'algorithme de hachage attendu, le format d'encodage (hex, base64), ni la taille minimale/maximale. La spec ne dit pas non plus si le système vérifie la cohérence entre le contenu opaque soumis et l'empreinte fournie, ou s'il fait confiance au client.
Impact : Sans contrainte sur l'algorithme ou le format, deux implémentations pourraient produire des empreintes incompatibles. Si le système ne vérifie pas la cohérence contenu↔empreinte, un client pourrait soumettre une empreinte arbitraire, compromettant INV-60-08.
Gravité : Majeur

Type : Ambiguïté
Référence : Spec §5 FN-60-03 — « contexte dégradé »
Description : Le flux FN-60-03 mentionne « la confirmation probatoire ne peut pas être finalisée » sans définir les conditions exactes qui constituent un contexte dégradé. Aucun critère observable ne permet de distinguer un contexte dégradé d'un échec technique (ERR-60-06).
Impact : L'implémentation doit décider arbitrairement quand créer un NON_PROBATIVE_STAGING vs retourner une erreur technique. Deux implémentations pourraient diverger.
Gravité : Majeur

Type : Ambiguïté
Référence : Spec §3 (Définitions) — « Reçu probatoire » / Spec §5 FN-60-05
Description : Le reçu probatoire doit « permettre une vérification hors plateforme » (INV-60-05) mais la spec ne définit ni la structure du reçu, ni le mécanisme cryptographique de vérification (signature, HMAC, ancrage blockchain, etc.), ni le protocole de vérification tiers. Le test TC-NOM-05 suppose qu'un tiers peut vérifier « sans accès API ProbatioVault » mais ne précise pas quel outil ou procédure il utilise.
Impact : Sans structure définie, le reçu est non interopérable et la vérification tiers est non reproductible de manière déterministe.
Gravité : Majeur

Type : Ambiguïté
Référence : Spec §4 INV-60-06 — « non altérable a posteriori »
Description : La journalisation « non altérable a posteriori » n'est pas bornée techniquement. La spec ne précise pas le mécanisme garantissant la non-altérabilité (append-only, signature chaînée, stockage immuable externe, etc.).
Impact : Le test TC-INV-06 reconnaît cette limitation (couverture partielle). L'implémentation ne dispose d'aucun critère de conformité mesurable pour « non altérable ».
Gravité : Mineur (cohérent avec la section 9 des tests qui le marque NON TESTABLE au sens absolu)

Type : Ambiguïté
Référence : Spec §4 INV-60-12 / §3 « Notice minimale obligatoire »
Description : La notice est définie comme texte exact `"Vous réalisez un acte probatoire daté."` et le client doit envoyer `probative_notice_ack=true`. Mais la spec ne précise pas si le texte de la notice est envoyé par le client ou affiché par le système. Le champ `probative_notice_ack=true` est un booléen : comment le système vérifie-t-il que le client a bien présenté le texte exact à l'utilisateur ?
Impact : Le système ne peut vérifier que la présence du booléen, pas que la notice ait été effectivement présentée. La garantie d'information du déposant repose sur la bonne foi du client.
Gravité : Mineur (limitation architecturale inhérente aux API)

Type : Contradiction
Référence : Spec §5 FN-60-04 vs §6 ERR-60-08
Description : FN-60-04 décrit la confirmation ultérieure d'un pré-enregistrement : « le client rejoue avec le même client_request_id ». ERR-60-08 décrit le « rejeu après succès initial avec mêmes données » qui retourne « réponse de succès cohérente ». La distinction entre FN-60-02 (rejeu idempotent après succès), FN-60-04 (confirmation après staging) et ERR-60-08 repose sur l'état préexistant (succès vs staging). Mais la spec ne définit pas le comportement si un client rejoue après staging avec des données légèrement différentes (même client_request_id mais empreinte modifiée).
Impact : Cas limite non spécifié qui pourrait mener à un état incohérent.
Gravité : Mineur

Type : Non testable
Référence : Spec §4 INV-60-13 / CA-60-17 — « répartition contractuelle des responsabilités »
Description : La spec exige que la répartition « déposant / organisation / ProbatioVault » soit explicite dans l'acte/reçu. Les tests TC-INV-13 et TC-NOM-10 vérifient la présence syntaxique des trois volets mais reconnaissent que la « cohérence juridique complète » n'est pas testable via l'API seule.
Impact : Marqué correctement comme couverture partielle dans les tests. La qualification juridique reste hors périmètre fonctionnel.
Gravité : Majeur (cohérent avec tests §9)

Type : Non testable
Référence : Spec §4 INV-60-14 — « obligation irréversible limitée »
Description : Vérifier qu'« aucune autre obligation irréversible n'est créée » est un raisonnement d'absence, non prouvable par un jeu fini de tests. Le test TC-INV-14 vérifie l'absence de déclaration additionnelle dans les artefacts API, ce qui est le maximum testable.
Impact : Correctement identifié en couverture partielle.
Gravité : Majeur (cohérent avec tests §9)

Type : Incohérence Spec↔Tests
Référence : Spec §8 ST-60-12 vs Tests TC-NOM-09
Description : Le scénario ST-60-12 de la spec décrit « seule une des deux conditions (audit immuable / reçu) est présente ». Le test TC-NOM-09 implémente cela avec trois cas (A, B, C). Cependant, le test suppose la capacité d'observer un état où l'audit est écrit mais le reçu n'est pas émis (cas B) et inversement (cas C). La spec ne définit pas comment provoquer ces états partiels de manière déterministe, ni comment les observer. L'atomicité (INV-60-02) implique que normalement soit les deux existent, soit aucun.
Impact : Le test TC-NOM-09 pourrait être non reproductible sans un mécanisme d'injection de faute explicitement défini.
Gravité : Majeur

Type : Incohérence Spec↔Tests
Référence : Tests TC-NOM-03 — « contexte dégradé contrôlé »
Description : Le test TC-NOM-03 requiert un « contexte dégradé contrôlé empêchant la confirmation probatoire » comme précondition. La spec ne définit pas comment créer ce contexte de manière déterministe et reproductible en environnement de test.
Impact : Le test est correctement formulé mais sa reproductibilité dépend d'un mécanisme d'injection de faute non spécifié.
Gravité : Mineur (résolvable à l'implémentation sans modifier la spec)

Type : Hypothèse dangereuse
Référence : Spec §9 H-60-03 — « source d'horodatage UTC fiable »
Description : L'hypothèse suppose une source d'horodatage fiable sans définir la tolérance acceptable (drift maximal), ni le mécanisme de synchronisation, ni le comportement en cas de dérive détectée. L'existence_timestamp_utc est un pilier de la valeur probatoire (INV-60-03, INV-60-10).
Impact : Si l'horloge dérive silencieusement, tous les actes probatoires émis pendant la dérive auraient une date contestable. L'absence de borne de tolérance rend la détection de dérive non testable.
Gravité : Majeur

Type : Hypothèse dangereuse
Référence : Spec §9 H-60-02 — « Le client fournit une empreinte documentaire exploitable »
Description : Couplé à R-01, si le système fait confiance à l'empreinte fournie par le client sans vérification côté serveur, un client malveillant pourrait soumettre une empreinte ne correspondant pas au document. L'intégrité (INV-60-08) serait alors compromise dès l'origine.
Impact : La vérification tiers (FN-60-05) échouerait légitimement sur un document pourtant non altéré, ou réussirait sur un document falsifié.
Gravité : Majeur

Type : Risque sécu/conformité
Référence : Spec §4 INV-60-04 — zero-knowledge / Spec §2 Exclu — « mécanismes internes de stockage, de chiffrement »
Description : La spec exclut la définition des mécanismes de chiffrement mais exige que ProbatioVault ne voie jamais le contenu intelligible. La garantie zero-knowledge repose entièrement sur le fait que le contenu arrive chiffré côté client. Si un client soumet du contenu en clair, le système le stockerait sans pouvoir détecter la violation (puisqu'il ne connaît pas la nature du contenu).
Impact : Le zero-knowledge est une responsabilité client non vérifiable par le système. Un bug client pourrait exposer du contenu à ProbatioVault sans que le système le détecte.
Gravité : Mineur (limitation architecturale assumée par le modèle zero-knowledge)

Type : Risque sécu/conformité
Référence : Spec §6 ERR-60-01/02 — Refus explicite + audit
Description : Les refus d'authentification et d'autorisation sont audités (TC-ERR-01/02 vérifient « la tentative est auditée »). Cependant, la spec ne définit pas de mécanisme de rate-limiting ou de protection contre les tentatives massives. Un attaquant pourrait générer un volume massif de traces d'audit via des tentatives d'authentification échouées.
Impact : Risque de saturation du journal d'audit et potentiel déni de service sur la composante d'auditabilité.
Gravité : Mineur (relève de la couche infrastructure/opérationnelle, pas du contrat fonctionnel)