PD-252 — Specification Review¶

Analyse des documents¶

Je procède à l'audit indépendant de la spécification et des tests PD-252.

Points identifiés¶

1¶

Type : Ambiguïté Référence : Spec §5.1 — formatName regex ^[A-Z0-9/+.-]{1,32}$ Description : La regex autorise le caractère / dans formatName. Or §5.4 mentionne des formats comme "Factur-X" qui contient un tiret (couvert par - dans la regex via la classe de caractères). Cependant, le tiret - dans une classe de caractères [...] est un opérateur de range sauf s'il est en dernière position. La regex [A-Z0-9/+.-] place le - entre . et ], ce qui est valide (fin de classe), mais cela dépend de l'implémentation regex. De plus, aucune liste canonique des formatName autorisés n'est fournie dans la spec — seules les catégories sont mentionnées sans les noms exacts des formats. Impact : Sans liste exhaustive des valeurs formatName attendues, il est impossible de vérifier que la regex les accepte tous correctement. L'exhaustivité promise par INV-252-02 n'est pas vérifiable sur les noms canoniques. Gravité : Majeur

2¶

Type : Incohérence Spec↔Tests Référence : Spec §5.6, tableau "Statut implémentation" — PLANIFIE (PD-XXX) ; Tests TC-NOM-05 Description : La spec utilise le placeholder PD-XXX pour les stories de destination des validations planifiées (PDF/A et malware scan). INV-252-04 exige que les conversions mentionnent "story séparée", et le learning projet impose que les stubs inter-PD aient une story de destination exacte (cf. règle "Stubs inter-PD avec story destination OBLIGATOIRE"). TC-NOM-05 vérifie le statut PLANIFIE (PD-XXX) sans exiger une story réelle. Impact : En l'état, les deux validations planifiées ne sont pas traçables vers le backlog. Un auditeur ne peut pas vérifier si ces stories existent. Gravité : Majeur

3¶

Type : Ambiguïté Référence : Spec §5.4, point 5 — Factur-X en JSON conforme EN 16931 Description : La spec indique "Pour Factur-X : utiliser la représentation JSON conforme EN 16931, niveau de préservation COMPLETE". Factur-X est un standard basé sur PDF/A-3 avec facture XML embarquée (CII ou UBL). La mention "représentation JSON" est inhabituelle pour Factur-X — EN 16931 définit des syntaxes CII et UBL (XML), pas JSON. Si un mapping JSON propriétaire est visé, il devrait être défini contractuellement. Si c'est une erreur, c'est une contradiction factuelle. Impact : Un implémenteur tiers ne saurait pas quel format JSON produire ou accepter pour Factur-X. Risque de non-conformité EN 16931. Gravité : Bloquant

4¶

Type : Non testable Référence : Spec §5.7, Flux F4 — Matrice formats × durées légales ; CA-06 Description : CA-06 exige un "tableau complet avec durées et niveaux". La spec §5.2 donne 4 types documentaires avec durées fixes (10/10/30/5 ans). Mais la spec ne fournit pas la matrice elle-même (quels formats sont admissibles pour quels types documentaires). Le flux F4 décrit la procédure de construction ("pour chaque type, définir durée, associer formats, associer niveau") mais ne donne pas le résultat attendu. TC-NOM-08 vérifie que "chaque type documentaire a une durée, des formats et un niveau" sans pouvoir comparer à une valeur de référence. Impact : L'auditeur ne peut pas vérifier la cohérence de la matrice produite si les valeurs attendues ne sont pas spécifiées. Le test TC-NOM-08 vérifie la forme mais pas le fond. Gravité : Majeur

5¶

Type : Ambiguïté Référence : Spec §5.1 — normativeReference regex ^[A-Z0-9 .:-]+ §[0-9.]+$ Description : La regex n'autorise que les majuscules, chiffres, espaces et quelques symboles dans la partie "norme". Or "NF Z42-013" contient un tiret qui n'est pas dans le jeu [A-Z0-9 .:-] — le tiret - entre : et ] est un opérateur de range (: à ] en ASCII), pas un tiret littéral. Pour être littéral, il devrait être échappé \- ou placé en début/fin de classe. Selon l'implémentation, NF Z42-013 pourrait être rejeté par cette regex. Impact : Les références normatives légitimes (NF Z42-013) pourraient être rejetées par le contrat de données, contredisant CA-07 et INV-252-08. Gravité : Bloquant

6¶

Type : Contradiction Référence : Spec §5.8 (modèle d'états) vs §5.9 (mécanisme de validation) Description : §5.8 définit un modèle d'états avec transitions (UNCLASSIFIED -> COMPLETE, etc.) applicable "à l'issue de l'ingestion". §5.9 précise qu'"aucun moteur applicatif de validation n'est introduit par PD-252". Or le modèle d'états décrit un comportement runtime (classification à l'ingestion) qui ne sera implémenté que par une story future. La spec mélange documentation d'un comportement cible futur et périmètre de la story documentaire. Impact : Ambiguïté sur ce que l'auditeur doit vérifier : la présence de la documentation du modèle d'états, ou la conformité du comportement applicatif ? TC-NOM-07 vérifie la documentation, ce qui est cohérent, mais la spec ne distingue pas explicitement "documenter le modèle cible" de "implémenter le modèle". Gravité : Mineur

7¶

Type : Incohérence Spec↔Tests Référence : Spec §7 CA-02 — "5 catégories présentes et remplies" ; Tests TC-NOM-02 Description : CA-02 et TC-NOM-02 vérifient "5 catégories". La spec §5.4 nomme : Documents textuels, Images, Données structurées, Texte brut, Audio/Video. Or "Texte brut" pourrait être considéré comme un sous-ensemble de "Documents textuels". La distinction entre ces deux catégories n'est pas formellement définie dans la spec. Un auditeur pourrait contester le périmètre de chaque catégorie. Impact : Faible — les noms sont listés explicitement dans TC-NOM-02, ce qui lève l'ambiguïté au niveau du test. Mais la spec ne justifie pas pourquoi "Texte brut" est distinct de "Documents textuels". Gravité : Mineur

8¶

Type : Hypothèse dangereuse Référence : Spec §5.1 — mimeType normalisation lowercase Description : La spec exige "normalisation lowercase obligatoire avant validation" pour mimeType. Le test TC-NEG-02 vérifie que Application/PDF est normalisé en application/pdf puis accepté. Cependant, la spec ne précise pas qui effectue cette normalisation. Dans le contexte d'une story documentaire, cela signifie que la policy doit mentionner cette règle de normalisation. Mais si un auditeur humain effectue la revue documentaire (§5.9), la normalisation est un processus mental implicite, pas un mécanisme technique auditable. Impact : La règle de normalisation est pertinente pour l'implémentation future mais crée une ambiguïté dans le contexte purement documentaire de PD-252. Gravité : Mineur

9¶

Type : Incohérence Spec↔Tests Référence : Spec §6 ERR-252-04 — "hors matrice attendue" ; Tests TC-ERR-04 Description : ERR-252-04 rejette une durée "hors matrice attendue" (exemple P12Y pour factures). Cela implique que la policy a une liste fermée de valeurs de durée par type documentaire. Or la spec §5.2 donne des valeurs min=max (10/10/30/5) mais ne lie pas explicitement chaque valeur à un type documentaire dans un format validable. TC-ERR-04 teste P12Y pour factures mais la spec ne fournit pas la matrice de valeurs autorisées par type qui permettrait cette validation. Impact : Le test TC-ERR-04 suppose une matrice de correspondance type→durée qui n'est pas formalisée en §5.2 (les 4 valeurs sont listées mais le mapping type→valeur est dans le texte des labels, pas dans une structure validable). Gravité : Majeur

10¶

Type : Risque sécu/conformité Référence : Spec §5.6, validation "Scan malware" — PLANIFIE (PD-XXX) Description : Le scan malware est listé comme validation obligatoire à l'ingestion (INV-252-05) mais son implémentation est planifiée sans story tracée. La policy documentera que le scan est requis, mais entre la publication de la policy et l'implémentation effective, il y a un gap de conformité. La spec ne mentionne pas de mesure compensatoire ou de timeline pour cette validation critique. Impact : Un auditeur ISO 14641 pourrait relever que la policy déclare une obligation non satisfaite sans plan de remédiation daté. H-05 couvre partiellement ce risque mais ne mentionne pas spécifiquement le scan malware. Gravité : Mineur

11¶

Type : Non testable Référence : Spec §5.1 — integrityHashAlgorithm constante SHA3-384 Description : Le champ est défini comme une constante unique. INV-252-05 exige que SHA3-384 soit explicite. Cependant, la spec ne définit pas de mécanisme d'évolution de cet algorithme (versioning, deprecation path). H-02 mentionne l'hypothèse que SHA3-384 reste l'algorithme de référence, mais si cette hypothèse tombe, aucune procédure de mise à jour n'est documentée. Impact : Pas de risque immédiat (l'hypothèse H-02 couvre le cas). Mais l'absence de procédure d'évolution dans un document de policy long terme (30 ans pour documents probatoires) est un risque documentaire. Gravité : Mineur

Synthèse¶

Bloquants :

1. Point 3 — Factur-X "représentation JSON" vs EN 16931 (CII/UBL XML) : incohérence factuelle à lever.
2. Point 5 — Regex normativeReference rejette potentiellement les tirets (NF Z42-013) : contradiction contrat de données vs valeurs attendues.

Majeurs :

1. Point 1 — Pas de liste canonique des formatName pour vérifier INV-252-02.
2. Point 2 — Placeholders PD-XXX non traçables pour validations planifiées.
3. Point 4 — Matrice formats×durées non fournie, seule la procédure de construction est décrite.
4. Point 9 — Mapping type documentaire→durée autorisée non formalisé en structure validable.