PD-244 — Specification canonique contractuelle (v2)¶

1. Contexte et motivation¶

L'architecture ProbatioVault v4.1 (doc 41) revendique une conformite ISO 14641 et NF Z42-013 utilisee comme claim externe (audit BPI, investisseurs, partenaires). A date, ces claims ne sont pas tracables de bout en bout vers des elements verifiables (stories, preuves, ecarts), ce qui cree un risque juridique et commercial.

Cette story formalise un audit documentaire de conformite, a visee probatoire interne, produisant des matrices contractuelles de couverture des exigences normatives.

2. Objectif¶

L'audit DOIT produire une base de conformite exploitable, verifiable et tracable pour :

1. cartographier chaque exigence applicable ISO 14641 ;
2. cartographier chaque exigence applicable NF Z42-013 ;
3. qualifier le statut de conformite par exigence ;
4. referencer les preuves existantes ;
5. identifier les gaps et les transformer en backlog actionnable (stories Jira sous l'epic parent PD-217).

3. Perimetre¶

3.1 Inclus¶

• Audit documentaire des normes ISO 14641:2018 et NF Z42-013:2020 pour un contexte SAE B2C.
• Analyse de couverture par les stories citees :
• 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
• Referencement des preuves de conformite existantes (code, tests, documentation, decisions d'architecture, tickets).
• Qualification des gaps (PARTIEL, NON_IMPLEMENTE) avec creation de stories associees.

3.2 Exclus¶

• Certification officielle ISO/NF par organisme tiers.
• Realisation d'un audit externe (BPI, certificateur).
• Analyse eIDAS (story dediee).
• Analyse RGPD (deja couverte par PD-240 et PD-241).
• Toute modification de code, d'infrastructure ou de comportement applicatif.

4. Format des matrices de conformite¶

4.1 Regle de format¶

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

• source YAML (reference contractuelle) ;
• rendu Markdown (lisible audit/compliance).

Le Markdown DOIT etre strictement derive du YAML, sans information additionnelle non presente dans le YAML source.

4.2 Schema 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>" # ISO-14641: "2018", NF-Z42-013: "2020"
  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:
    - "<critere d'applicabilite>"
  exclusion_criteria:
    - "<critere d'exclusion>"
sections:
  - id: "5.1"
    title: "Exigences generales"
    applicable: true
    applicability_justification: "<justification testable>"
    requirements:
      - id: "5.1.1"
        text: "<texte exigence normalise>"
        status: "CONFORME"
        status_justification: "<justification factuelle>"
        stories:
          - "PD-37"
        evidence:
          - type: "code"
            path: "<chemin relatif ou identifiant artefact>"
            locator: "<fonction, section, test case, ancre doc>"
            verifiable: true
        gaps:
          - gap_id: "GAP-ISO-5.1.1-01"
            requirement_id: "ISO-14641-5.1.1"
            description: "<ecart constate>"
            severity: "HIGH"
            planned_story: "PD-XXX"
            epic_parent: "PD-217"
            owner: "<role responsable>"
            status: "PLANNED" # PLANNED | IN_PROGRESS | DONE
            target_date: "YYYY-MM-DD"
        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 validite des donnees¶

• Chaque requirements[].id DOIT etre 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.
• Chaque gap DOIT contenir les champs obligatoires : gap_id, requirement_id, description, severity, planned_story, epic_parent, owner, status, target_date.
• gaps[].status DOIT appartenir strictement a {PLANNED, IN_PROGRESS, DONE}.

4.4 Methode de calcul du score global de conformite¶

Le score global est calcule de facon deterministe selon la formule contractuelle suivante :

score_global = ((CONFORME * 100) + (PARTIEL * 50)) / (total_applicable - HORS_PERIMETRE) * 100

Regles d'application :

• total_applicable = nombre total d'exigences evaluees dans la norme.
• HORS_PERIMETRE est soustrait du denominateur.
• Le score est borne dans [0, 100].
• Si (total_applicable - HORS_PERIMETRE) = 0, le score est N/A (cas non applicable global).

4.5 Regles de severite des gaps¶

Regles :

• Tout gap DOIT avoir une severite unique.
• La severite DOIT etre coherente avec la justification du gap.
• Les priorisations backlog DOIVENT s'aligner sur cette table.

5. Statuts de conformite¶

• CONFORME : exigence applicable couverte integralement, preuves verifiables disponibles, aucune lacune bloquante identifiee.
• PARTIEL : exigence applicable couverte partiellement, au moins un sous-aspect non couvert ou insuffisamment prouve.
• NON_IMPLEMENTE : exigence applicable non couverte a date, sans preuve d'implementation active.
• HORS_PERIMETRE : exigence explicitement non applicable au contexte SAE B2C, justification ecrite obligatoire.

Regles de decision obligatoires :

1. Une exigence applicable sans preuve verifiable NE PEUT PAS etre classee CONFORME.
2. Une exigence avec couverture partielle ET plan de remediation DOIT etre classee PARTIEL.
3. Une exigence sans couverture ET sans preuve DOIT etre classee NON_IMPLEMENTE.
4. HORS_PERIMETRE n'est autorise que si une regle d'applicabilite objectivable est renseignee.

6. Processus d'audit¶

Le processus d'audit DOIT suivre les etapes contractuelles suivantes :

1. Inventaire normatif : lister toutes les sections/exigences des deux normes.
2. Filtrage d'applicabilite : qualifier chaque exigence comme applicable/non applicable au contexte SAE B2C avec justification.
3. Mapping de couverture : associer chaque exigence applicable aux stories ProbatioVault pertinentes.
4. Collecte de preuves : lier des artefacts verifiables (code, tests, docs, decisions, tickets).
5. Qualification du statut : appliquer strictement les regles de la section 5.
6. Identification des gaps : documenter chaque ecart PARTIEL/NON_IMPLEMENTE.
7. Backlog des remediations : rattacher chaque gap a une story Jira sous PD-217.
8. Consolidation des scores : calculer les indicateurs de conformite par norme.
9. Relecture croisee : valider coherence YAML <-> Markdown et tracabilite complete.

7. Invariants¶

• INV-PD244-01 : Toute exigence normative inventoriee DOIT apparaitre 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 autorise sans preuve verifiable attachee.
• INV-PD244-04 : Toute exigence PARTIEL ou NON_IMPLEMENTE DOIT generer au moins un gap avec story planifiee sous PD-217.
• INV-PD244-05 : Toute exigence HORS_PERIMETRE DOIT inclure une justification d'applicabilite testable.
• INV-PD244-06 : Le Markdown publie DOIT etre une representation fidele du YAML source (pas d'ecart semantique).
• INV-PD244-07 : Chaque claim de conformite porte dans doc 41/42/43 et couvert par ce perimetre DOIT referencer au moins une exigence de norme et une preuve.
• INV-PD244-08 : Les matrices ne DOIVENT contenir aucune citation reutilisable des PDF normatifs proteges par copyright au-dela des metadonnees necessaires a l'audit interne.

8. Criteres d'acceptation¶

• CA-PD244-01 : Une matrice YAML ISO 14641 complete est produite avec 100% des exigences inventoriees et un statut par exigence applicable.
• CA-PD244-02 : Une matrice YAML NF Z42-013 complete est produite avec 100% des exigences inventoriees et un statut par exigence applicable.
• CA-PD244-03 : Pour chaque exigence CONFORME ou PARTIEL, au moins une preuve verifiable est renseignee (verifiable: true).
• CA-PD244-04 : Pour chaque exigence PARTIEL ou NON_IMPLEMENTE, au moins un gap est documente avec une story de remediation rattachee a l'epic parent PD-217.
• CA-PD244-05 : Le rendu Markdown de chaque norme correspond sans divergence au YAML source (controle de coherence reussi).
• CA-PD244-06 : Un tableau de synthese par norme est produit avec : total exigences, repartition par statut, score global de conformite, taux de tracabilite.
• CA-PD244-07 : Une liste consolidee des stories de gap (uniques, sans doublon) est produite avec severite et rattachement a PD-217.
• CA-PD244-08 : Chaque exigence classee HORS_PERIMETRE contient une justification explicite fondee sur les regles d'applicabilite SAE B2C.
• CA-PD244-09 : La tracabilite claim (doc 41/42/43) vers exigence normative vers preuve est demontree pour tout claim dans le perimetre.

9. Matrice de tracabilite (INV vers CA)¶

10. Fichiers produits¶

Les artefacts contractuels attendus sont :

1. PD-244-specification.md (present document canonique).
2. PD-244-inventaire-reference.yaml (inventaire de reference des exigences normatives par norme).
3. PD-244-iso-14641-matrix.yaml (source contractuelle ISO).
4. PD-244-iso-14641-matrix.md (rendu lisible ISO).
5. PD-244-nf-z42-013-matrix.yaml (source contractuelle NF, version 2020).
6. PD-244-nf-z42-013-matrix.md (rendu lisible NF).
7. PD-244-gaps.yaml (registre consolide des ecarts et stories de remediation).
8. PD-244-gaps.md (vue lisible des gaps et priorisation).
9. PD-244-compliance-dashboard.md (synthese des scores globaux par norme).

11. Clarifications contractuelles¶

11.1 Decisions prises¶

• La story PD-244 est strictement documentaire : aucune action d'implementation technique n'est incluse.
• Le perimetre est limite aux exigences applicables a un SAE B2C.
• Les exigences non applicables sont autorisees uniquement sous statut HORS_PERIMETRE avec justification testable.
• Les gaps identifies deviennent obligatoirement des stories rattachees a PD-217.
• La version normative retenue pour NF Z42-013 est fixee a NF Z42-013:2020.
• La version normative retenue pour ISO 14641 est fixee a ISO 14641:2018.
• La methode de calcul du score global est celle definie en section 4.4.
• Les regles de severite des gaps sont celles definies en section 4.5.

11.2 References normatives¶

Les fichiers sources des normes sont disponibles localement :

Ces fichiers constituent la reference canonique pour l'inventaire des exigences.