PD-244 — Spécification canonique contractuelle¶

1. Contexte et motivation¶

L'architecture ProbatioVault v4.1 (doc 41) revendique une conformité ISO 14641 et NF Z42-013 utilisée comme claim externe (audit BPI, investisseurs, partenaires). À date, ces claims ne sont pas traçables de bout en bout vers des éléments vérifiables (stories, preuves, écarts), ce qui crée un risque juridique et commercial.

Cette story formalise un audit documentaire de conformité, à visée probatoire interne, produisant des matrices contractuelles de couverture des exigences normatives.

2. Objectif¶

L'audit DOIT produire une base de conformité exploitable, vérifiable et traçable pour :

cartographier chaque exigence applicable ISO 14641 ;
cartographier chaque exigence applicable NF Z42-013 ;
qualifier le statut de conformité par exigence ;
référencer les preuves existantes ;
identifier les gaps et les transformer en backlog actionnable (stories Jira sous l'epic parent PD-217).

3. Périmètre¶

3.1 Inclus¶

Audit documentaire des normes ISO 14641 et NF Z42-013 pour un contexte SAE B2C.
Analyse de couverture par les stories citées :
Backend : PD-37, PD-39, PD-40, PD-60, PD-31
Infra : PD-4, PD-5, PD-6, PD-44, PD-7
App : PD-33, PD-34, PD-42, PD-54
Blockchain : PD-52, PD-53, PD-245
Référencement des preuves de conformité existantes (code, tests, documentation, décisions d'architecture, tickets).
Qualification des gaps (PARTIEL, NON_IMPLEMENTE) avec création de stories associées.

3.2 Exclus¶

Certification officielle ISO/NF par organisme tiers.
Réalisation d'un audit externe (BPI, certificateur).
Analyse eIDAS (story dédiée).
Analyse RGPD (déjà couverte par PD-240 et PD-241).
Toute modification de code, d'infrastructure ou de comportement applicatif.

4. Format des matrices de conformité¶

4.1 Règle de format¶

Deux matrices DOIVENT être produites, une par norme, en format dual :

source YAML (référence contractuelle) ;
rendu Markdown (lisible audit/compliance).

Le Markdown DOIT être strictement dérivé du YAML, sans information additionnelle non présente dans le YAML source.

4.2 Schéma canonique YAML¶

schema_version: "1.0.0"
story_id: "PD-244"
audit_scope: "SAE-B2C"
generated_at: "YYYY-MM-DD"
norm:
  id: "ISO-14641" # ou "NF-Z42-013"
  version: "<version exacte>"
  source_reference:
    type: "pdf"
    title: "<titre officiel de la norme>"
    internal_reference: "<identifiant interne, pas de contenu PDF>"
applicability_rules:
  context: "SAE-B2C"
  inclusion_criteria:
    - "<critère d'applicabilité>"
  exclusion_criteria:
    - "<critère d'exclusion>"
sections:
  - id: "5.1"
    title: "Exigences générales"
    applicable: true
    applicability_justification: "<justification testable>"
    requirements:
      - id: "5.1.1"
        text: "<texte exigence normalisé>"
        status: "CONFORME" # CONFORME | PARTIEL | NON_IMPLEMENTE | HORS_PERIMETRE
        status_justification: "<justification factuelle>"
        stories:
          - "PD-37"
        evidence:
          - type: "code" # code | test | doc | architecture_decision | ticket
            path: "<chemin relatif ou identifiant artefact>"
            locator: "<fonction, section, test case, ancre doc>"
            verifiable: true
        gaps:
          - id: "GAP-ISO-5.1.1-01"
            description: "<écart constaté>"
            severity: "HIGH" # LOW | MEDIUM | HIGH | CRITICAL
            planned_story: "PD-XXX"
            epic_parent: "PD-217"
        controls:
          owner: "<role responsable>"
          review_frequency: "<mensuelle|trimestrielle|semestrielle|annuelle>"
quality_checks:
  total_requirements: 0
  by_status:
    CONFORME: 0
    PARTIEL: 0
    NON_IMPLEMENTE: 0
    HORS_PERIMETRE: 0
  traceability_coverage_percent: 0
  evidence_coverage_percent: 0
signoff:
  prepared_by: "<nom/role>"
  reviewed_by: "<nom/role>"
  approved_by: "<nom/role>"
  approval_date: "YYYY-MM-DD"

4.3 Contraintes de validité des données¶

Chaque requirements[].id DOIT être unique dans une matrice.
Chaque exigence applicable (applicable: true) DOIT avoir un status.
Chaque exigence en CONFORME ou PARTIEL DOIT avoir au moins une preuve verifiable: true.
Chaque exigence en PARTIEL ou NON_IMPLEMENTE DOIT contenir au moins un gaps[] avec planned_story.
Chaque exigence en HORS_PERIMETRE DOIT porter une justification explicite dans status_justification et ne DOIT pas masquer une absence de preuve.

5. Statuts de conformité¶

CONFORME : exigence applicable couverte intégralement, preuves vérifiables disponibles, aucune lacune bloquante identifiée.
PARTIEL : exigence applicable couverte partiellement, au moins un sous-aspect non couvert ou insuffisamment prouvé.
NON_IMPLEMENTE : exigence applicable non couverte à date, sans preuve d'implémentation active.
HORS_PERIMETRE : exigence explicitement non applicable au contexte SAE B2C, justification écrite obligatoire.

Règles de décision obligatoires :

Une exigence applicable sans preuve vérifiable NE PEUT PAS être classée CONFORME.
Une exigence avec couverture partielle ET plan de remédiation DOIT être classée PARTIEL.
Une exigence sans couverture ET sans preuve DOIT être classée NON_IMPLEMENTE.
HORS_PERIMETRE n'est autorisé que si une règle d'applicabilité objectivable est renseignée.

6. Processus d'audit¶

Le processus d'audit DOIT suivre les étapes contractuelles suivantes :

Inventaire normatif : lister toutes les sections/exigences des deux normes.
Filtrage d'applicabilité : qualifier chaque exigence comme applicable/non applicable au contexte SAE B2C avec justification.
Mapping de couverture : associer chaque exigence applicable aux stories ProbatioVault pertinentes.
Collecte de preuves : lier des artefacts vérifiables (code, tests, docs, décisions, tickets).
Qualification du statut : appliquer strictement les règles de la section 5.
Identification des gaps : documenter chaque écart PARTIEL/NON_IMPLEMENTE.
Backlog des remédiations : rattacher chaque gap à une story Jira sous PD-217.
Consolidation des scores : calculer les indicateurs de conformité par norme.
Relecture croisée : valider cohérence YAML ↔ Markdown et traçabilité complète.

6bis. Diagrammes¶

6bis.1 Diagramme d'états — Statut de conformité par exigence¶

Chaque exigence normative suit un cycle de qualification. Les transitions sont régies par les règles de décision de la section 5 et les invariants INV-PD244-02, INV-PD244-03, INV-PD244-04, INV-PD244-05.

stateDiagram-v2
    [*] --> INVENTORIEE : Étape 1 — Inventaire normatif

    INVENTORIEE --> HORS_PERIMETRE : Étape 2 — Filtrage applicabilité\n(non applicable au SAE B2C)\n[INV-PD244-05]
    INVENTORIEE --> APPLICABLE : Étape 2 — Filtrage applicabilité\n(applicable au SAE B2C)

    APPLICABLE --> CONFORME : Étape 5 — Qualification\n(couverture intégrale + preuve vérifiable)\n[INV-PD244-03]
    APPLICABLE --> PARTIEL : Étape 5 — Qualification\n(couverture partielle + gap documenté)\n[INV-PD244-04]
    APPLICABLE --> NON_IMPLEMENTE : Étape 5 — Qualification\n(aucune couverture, aucune preuve)\n[INV-PD244-04]

    PARTIEL --> CONFORME : Remédiation complète\n(story gap terminée + preuve ajoutée)\n[INV-PD244-03]
    NON_IMPLEMENTE --> PARTIEL : Remédiation partielle\n(story gap en cours)
    NON_IMPLEMENTE --> CONFORME : Remédiation complète\n(story gap terminée + preuve ajoutée)\n[INV-PD244-03]

    CONFORME --> [*]
    HORS_PERIMETRE --> [*]

6bis.2 Diagramme de séquence — Processus d'audit (section 6)¶

Le processus implique l'orchestrateur (Claude), les sources documentaires (normes, code, Jira) et le reviewer croisé. Le séquencement correspond aux 9 étapes contractuelles de la section 6.

sequenceDiagram
    participant O as Orchestrateur (Claude)
    participant N as Normes (ISO 14641 / NF Z42-013)
    participant C as Codebase ProbatioVault
    participant J as Jira (PD-217)
    participant R as Reviewer croisé

    Note over O,N: Étape 1 — Inventaire normatif [INV-PD244-01]
    O->>N: Lister toutes les sections/exigences
    N-->>O: Liste exhaustive des exigences

    Note over O: Étape 2 — Filtrage d'applicabilité [INV-PD244-02, INV-PD244-05]
    O->>O: Qualifier applicable / HORS_PERIMETRE (SAE B2C)

    Note over O,C: Étape 3 — Mapping de couverture
    O->>C: Associer exigences aux stories ProbatioVault
    C-->>O: Stories associées (PD-37, PD-39, PD-40, ...)

    Note over O,C: Étape 4 — Collecte de preuves [INV-PD244-03]
    O->>C: Lier artefacts vérifiables (code, tests, docs)
    C-->>O: Preuves avec path + locator + verifiable

    Note over O: Étape 5 — Qualification du statut [INV-PD244-02, INV-PD244-03]
    O->>O: Appliquer règles section 5 (CONFORME / PARTIEL / NON_IMPLEMENTE)

    Note over O,J: Étape 6-7 — Gaps et backlog [INV-PD244-04]
    O->>J: Créer stories de remédiation sous PD-217
    J-->>O: Stories GAP-ISO-*/GAP-NF-* créées

    Note over O: Étape 8 — Consolidation [INV-PD244-06]
    O->>O: Générer YAML + Markdown (matrices + dashboard)

    Note over O,R: Étape 9 — Relecture croisée [INV-PD244-06, INV-PD244-07]
    O->>R: Soumettre YAML + Markdown pour validation
    R-->>O: Cohérence YAML↔MD confirmée + traçabilité OK

7. Invariants¶

INV-PD244-01 : Toute exigence normative inventoriée DOIT apparaître exactement une fois dans la matrice de sa norme.
INV-PD244-02 : Toute exigence applicable DOIT avoir un statut parmi {CONFORME, PARTIEL, NON_IMPLEMENTE, HORS_PERIMETRE}.
INV-PD244-03 : Aucun statut CONFORME n'est autorisé sans preuve vérifiable attachée.
INV-PD244-04 : Toute exigence PARTIEL ou NON_IMPLEMENTE DOIT générer au moins un gap avec story planifiée sous PD-217.
INV-PD244-05 : Toute exigence HORS_PERIMETRE DOIT inclure une justification d'applicabilité testable.
INV-PD244-06 : Le Markdown publié DOIT être une représentation fidèle du YAML source (pas d'écart sémantique).
INV-PD244-07 : Chaque claim de conformité porté dans doc 41/42/43 et couvert par ce périmètre DOIT référencer au moins une exigence de norme et une preuve.
INV-PD244-08 : Les matrices ne DOIVENT contenir aucune citation réutilisable des PDF normatifs protégés par copyright au-delà des métadonnées nécessaires à l'audit interne.

8. Critères d'acceptation¶

CA-PD244-01 : Une matrice YAML ISO 14641 complète est produite avec 100% des exigences inventoriées et un statut par exigence applicable.
CA-PD244-02 : Une matrice YAML NF Z42-013 complète est produite avec 100% des exigences inventoriées et un statut par exigence applicable.
CA-PD244-03 : Pour chaque exigence CONFORME ou PARTIEL, au moins une preuve vérifiable est renseignée (verifiable: true).
CA-PD244-04 : Pour chaque exigence PARTIEL ou NON_IMPLEMENTE, au moins un gap est documenté avec une story de remédiation rattachée à l'epic parent PD-217.
CA-PD244-05 : Le rendu Markdown de chaque norme correspond sans divergence au YAML source (contrôle de cohérence réussi).
CA-PD244-06 : Un tableau de synthèse par norme est produit avec : total exigences, répartition par statut, score global de conformité, taux de traçabilité.
CA-PD244-07 : Une liste consolidée des stories de gap (uniques, sans doublon) est produite avec priorité et rattachement à PD-217.
CA-PD244-08 : Chaque exigence classée HORS_PERIMETRE contient une justification explicite fondée sur les règles d'applicabilité SAE B2C.
CA-PD244-09 : La traçabilité claim (doc 41/42/43) → exigence normative → preuve est démontrée pour tout claim dans le périmètre.

9. Matrice de traçabilité (INV → CA)¶

Invariant	Critères d'acceptation couverts
INV-PD244-01	CA-PD244-01, CA-PD244-02
INV-PD244-02	CA-PD244-01, CA-PD244-02, CA-PD244-08
INV-PD244-03	CA-PD244-03
INV-PD244-04	CA-PD244-04, CA-PD244-07
INV-PD244-05	CA-PD244-08
INV-PD244-06	CA-PD244-05
INV-PD244-07	CA-PD244-09
INV-PD244-08	CA-PD244-01, CA-PD244-02, CA-PD244-05

10. Fichiers produits¶

Les artefacts contractuels attendus sont :

PD-244-specification.md (présent document canonique).
PD-244-iso-14641-matrix.yaml (source contractuelle ISO).
PD-244-iso-14641-matrix.md (rendu lisible ISO).
PD-244-nf-z42-013-matrix.yaml (source contractuelle NF).
PD-244-nf-z42-013-matrix.md (rendu lisible NF).
PD-244-gaps.yaml (registre consolidé des écarts et stories de remédiation).
PD-244-gaps.md (vue lisible des gaps et priorisation).
PD-244-compliance-dashboard.md (synthèse des scores globaux par norme).

11. Clarifications contractuelles¶

11.1 Décisions prises¶

La story PD-244 est strictement documentaire : aucune action d'implémentation technique n'est incluse.
Le périmètre est limité aux exigences applicables à un SAE B2C.
Les exigences non applicables sont autorisées uniquement sous statut HORS_PERIMETRE avec justification testable.
Les gaps identifiés deviennent obligatoirement des stories rattachées à PD-217.

11.2 Informations manquantes explicitement identifiées¶

Version exacte de NF Z42-013 à auditer : non fournie (bloquant pour figer la référence normative).
Localisation/identifiant interne officiel des PDF ISO/NF : non fournie (requise pour source_reference.internal_reference).
Méthode contractuelle de calcul du "score global de conformité" : non fournie (nécessaire pour rendre CA-PD244-06 entièrement déterministe).
Règles formelles de priorité des gaps (ex. HIGH/MEDIUM/LOW) : non fournies.

Ces points sont hors hypothèse implicite : ils DOIVENT être fournis ou validés avant gel final des matrices.