PD-252 — Specification Review (Gate 3, itération v4)¶

Type : Contradiction interne + Incohérence Spec↔Tests
Référence : §5.4b (liste canonique, format TIFF) vs §5.7 (matrice légale)
Description : TIFF est listé dans la liste canonique des 14 formats acceptés (§5.4b,
  catégorie Images, preservationLevel=BITSTREAM). Il n'apparaît dans AUCUNE ligne de
  la matrice format × durée légale (§5.7). La seule ligne susceptible de l'accueillir
  — "Preuves numériques (mineurs)" — liste JPEG, PNG, MP4, WAV, MOV, mais pas TIFF.
  Aucun type documentaire n'admet TIFF.
  Incohérence Spec↔Tests : CA-02 et TC-NOM-02 vérifient que TIFF est dans la liste
  canonique. CA-06 et TC-NOM-08 vérifient les valeurs exactes de la matrice. Aucun
  critère ne vérifie que tout format de la liste canonique dispose d'un contexte
  d'usage dans la matrice. Le gap est invisible aux tests.
Impact : TIFF est un format de préservation formellement accepté (passe la validation
  §5.4b) mais sans durée légale applicable pour aucun type documentaire. La policy est
  opérationnellement incomplète pour ce format. Un auditeur ISO 14641 ne peut pas
  déterminer la durée de conservation applicable à un document TIFF.
Gravité : Majeur

Type : Non testable (règle conditionnelle sans définition contractuelle)
Référence : §5.8 (modèle d'états et transitions)
Description : Les transitions autorisées depuis UNCLASSIFIED sont conditionnées :
  "UNCLASSIFIED -> COMPLETE : AUTORISÉE (format compatible complete)"
  "UNCLASSIFIED -> BITSTREAM : AUTORISÉE (format compatible bitstream)"
  Le terme "format compatible complete" / "format compatible bitstream" n'est pas
  défini contractuellement. Il n'y a pas de référence explicite à §5.4b comme source
  de vérité pour déterminer quelle transition s'applique à quel format. Un lecteur
  tiers ne peut pas mécaniquement déduire que "compatible complete" = preservationLevel
  COMPLETE dans §5.4b sans inférence implicite.
Impact : La condition de transition n'est pas testable par revue documentaire sans
  ambiguïté d'interprétation. TC-NOM-07 vérifie la présence des transitions mais ne
  peut pas valider la condition d'application. Risque de divergence entre la policy et
  l'implémentation backend.
Gravité : Majeur

Type : Ambiguïté
Référence : §5.6 (Flux F3, point 2) — "Validation PDF/A pour documents PDF/A revendiqués"
Description : FACTUR-X est un format distinct (formatName=FACTUR-X, §5.4b) dont le
  mimeType est application/pdf et le preservationLevel est COMPLETE. Techniquement,
  FACTUR-X est un PDF/A-3b avec facture XML embarquée. La condition "documents PDF/A
  revendiqués" dans §5.6 ne précise pas si FACTUR-X est considéré comme "PDF/A
  revendiqué" (puisque son formatName diffère de PDF/A-xB) ou non. Si la validation
  PDF/A ne s'applique pas à FACTUR-X, un FACTUR-X non conforme à PDF/A-3b pourrait
  être accepté comme valide. Si elle s'applique, cela n'est pas documenté.
Impact : Gap de conformité pour les factures — type documentaire pour lequel FACTUR-X
  est un format accepté (§5.7). La validation d'intégrité du format est incomplète ou
  indéterminée pour ce format spécifique.
Gravité : Majeur

Type : Incohérence terminologique (Contradiction interne)
Référence : §5.4 (note Factur-X) vs §5.4b (liste canonique)
Description : La note §5.4 utilise "PDF/A-3b" (lowercase 'b') : "utiliser la
  représentation PDF/A-3b avec facture XML embarquée (CII ou UBL, conforme EN 16931)".
  §5.4b liste le format canonique comme "PDF/A-3B" (uppercase 'B'). Le principe de
  canonicalisation déclaré en §5.4 ("le nom canonique est celui utilisé dans ISO 19005")
  pointe vers "PDF/A-3b" (notation ISO standard, niveau b minuscule). Mais la regex
  formatName ^[A-Z0-9/+.-]{1,32}$ n'autorise que des majuscules, donc "PDF/A-3b" serait
  rejeté et la notation ISO ne peut pas être le nom canonique.
  Contradiction: la règle de canonicalisation (= notation ISO) est incompatible avec
  la regex (= majuscules uniquement). §5.4 affirme une règle que §5.1 rend inapplicable.
Impact : Un implémenteur appliquant la règle de canonicalisation §5.4 produirait un
  formatName "PDF/A-3b" rejeté par la regex §5.1. La règle de dérivation du nom
  canonique est non opérationnelle.
Gravité : Mineur

Type : Incohérence Spec↔Tests
Référence : CA-07 vs TC-NOM-09
Description : CA-07 spécifie : "References ISO 14641, NF Z42-013, ISO 19005-1/2/3
  citées". RFC-PV-PACK n'est pas dans CA-07. TC-NOM-09 ajoute la vérification de
  "RFC-PV-PACK" comme citation documentaire textuelle. Le test est plus strict que le
  critère d'acceptation : RFC-PV-PACK n'est pas exigé par CA-07 mais est vérifié par
  TC-NOM-09.
Impact : Si RFC-PV-PACK est absent de la policy, TC-NOM-09 échoue mais CA-07 passe.
  Le verdict de conformité dépend du référentiel utilisé (CA vs TC). Incohérence
  contractuelle mineure, mais auditable.
Gravité : Mineur

Type : Non testable (comportement "rejet" sans exécuteur défini)
Référence : §6 (Cas d'erreur, tous les ERR) + §5.9
Description : Tous les cas d'erreur §6 définissent "Rejet" comme règle de réponse.
  §5.9 précise explicitement "Aucun moteur applicatif de validation n'est introduit
  par PD-252". Le terme "rejet" dans §6 est ambigu : s'agit-il d'un rejet par revue
  humaine (lors de l'audit documentaire) ou d'un rejet par un mécanisme automatique ?
  TC-ERR-01 à TC-ERR-08 vérifient que le "motif explicite" est présent, mais
  l'observable "la ligne est rejetée" ne peut être évalué que subjectivement dans le
  cadre d'une revue documentaire.
Impact : Les cas d'erreur sont non déterministes dans leur vérification : deux
  reviewers peuvent diverger sur ce que "rejet" signifie dans ce contexte documentaire.
Gravité : Mineur

Type : Incohérence Spec↔Tests (couverture partielle ERR-252-01)
Référence : ERR-252-01 vs TC-NEG-01, TC-ERR-01
Description : ERR-252-01 couvre "Format non listé dans la policy". TC-ERR-01 vérifie
  ce cas via "une entrée de format apparaît hors liste autorisée". TC-NEG-01 teste
  formatName=pdf/a (casse invalide). Aucun test ne couvre le scénario : mimeType
  syntaxiquement valide selon la regex §5.1 (ex: audio/mpeg) mais format non présent
  dans §5.4b. Ce cas distinct (format absent de la liste ≠ format avec mimeType
  invalide) n'a pas de TC-ERR dédié.
Impact : ERR-252-01 est partiellement testé. Un implémenteur acceptant audio/mpeg
  (valide RFC 6838, regex OK, mais hors §5.4b) ne serait pas couvert contractuellement.
Gravité : Mineur

Type : Hypothèse dangereuse
Référence : §5.6 (validations PLANIFIE) + H-05
Description : La clause de non-conformité technique (§5.6 note) reconnaît le gap entre
  les obligations documentées et l'implémentation effective. Mais le délai entre
  publication de la policy et implémentation des validations critiques (PDF/A via
  VeraPDF, scan malware) n'est pas borné dans le temps. "Création prévue au sprint
  suivant" (H-05) n'est pas une date contractuelle. La policy affiche "Obligatoire"
  pour des validations non implémentées. Un audit ISO 14641 §10.3 réalisé avant
  l'implémentation des stories PD-NEW trouve une obligation sans moyen de contrôle,
  ce qui peut invalider la mesure compensatoire de gouvernance.
Impact : Risque d'auto-incrimination en audit si les stories PD-NEW ne sont pas créées
  et implémentées avant le premier audit externe. La mitigation (tracking backlog) est
  documentée mais non opposable sans référence à un sprint ou une date précise.
Gravité : Mineur