Schéma du registre d'artefacts

1Objectif et périmètre du registre

Le registre d'artefacts est la source de vérité unique du harnais : toute production (document, code, configuration, plan, preuve) y est enregistrée avec ses métadonnées, son statut et ses dépendances. Ce document définit le schéma de ce registre — c'est-à-dire sa structure logique, indépendamment de la technologie d'implémentation (base de données, dépôt Git, ou hybride).

Rappel des principes du guide V3

• Aucun agent ne maintient sa propre copie parallèle de l'état du projet : le registre est la seule référence.
• Chaque artefact porte des métadonnées obligatoires : type, version, statut, auteur, horodatage, dépendances, référentiel appliqué.
• Les contrats de dépendance sont déclarés formellement : toute modification amont déclenche alerte ou régénération des artefacts avals.
• La machine à états (annexe A de la V3) régit les transitions : brouillon → en revue → validé → obsolète → archivé.
• Le registre survit au harnais : il reste consultable après la clôture du système documenté (statut terminal archivé).

2Taxonomie des types d'artefacts

Chaque artefact porte un type identifié par un code unique, organisé par famille (une famille = une phase du cycle de vie). La taxonomie suit la section 3 du guide V3, avec un identifiant machine famille.type pour chaque artefact listé.

2.1 Cadrage amont

2.2 Design UX/UI amont

2.3 Conception technique amont

2.4 Planification amont

2.5 Réalisation réalisation

2.6 Vérification réalisation

2.7 Déploiement déploiement

2.8 Exploitation et maintenance exploitation

2.9 Décommissionnement fin de vie

2.10 Transverse transverse

3Schéma de métadonnées

Chaque enregistrement du registre porte les champs suivants. Les champs marqués obligatoire sont exigés dès la création ; les autres sont renseignés au fil du cycle de vie.

4Machine à états d'un artefact

Reprise fidèle de l'annexe A du guide V3, formalisée pour le registre. Six statuts, quatre règles de transition.

Règles de transition

• R1 — Seul un artefact valide peut servir de dépendance amont pour la génération d'un artefact aval.
• R2 — Toute modification d'un artefact validé le repasse en brouillon et déclenche l'analyse d'impact sur ses avals (section 5).
• R3 — La transition en_revue → valide exige une action humaine explicite, journalisée (qui, quand, commentaire).
• R4 — Le statut archive est irréversible et inclut les métadonnées complètes + contexte de décision.

5Modèle de dépendances

Les contrats de dépendance relient chaque artefact à ses sources (amont) et à ses consommateurs (aval). Le registre stocke ces liens de manière directionnelle : une modification d'un artefact amont marque automatiquement les avals comme impactés (statut proposé à la régénération).

5.1 Types de liens

5.2 Relations canoniques (dérivations)

Le tableau suivant fixe les dérivations attendues par défaut dans le harnais. L'orchestrateur les utilise pour vérifier la complétude du registre et propager les changements.

6Configuration des référentiels

Le guide V3 (section 4) exige que les référentiels soient configurables sans modification du code de l'orchestrateur. Le registre embarque un fichier de configuration versionné — referentiels.yaml — associant type d'artefact ↔ référentiel(s). Les agents le consultent comme grille d'auto-évaluation avant publication.

# referentiels.yaml — configuration des référentiels par type d'artefact
# Versionné dans le registre comme un artefact de type `config.referentiels`.
version: "1.0"
referentiels:
  cadrage.*: ["iso-25010"]
  design.*: ["wcag-2.2", "rgaa", "iso-9241-11"]
  spec.*: ["exigences-traçables"]
  archi.*: ["adr", "c4", "iso-42010"]
  plan.*: []
  code.*: ["guide-style", "conventional-commits"]
  test.*: ["pyramide-tests", "owasp-top10"]
  deploy.*: ["12-factor", "iac-versionnee"]
  exploit.*: ["itil", "sre", "owasp-top10"]
  finvie.*: ["rgpd", "iso-27001"]
  transverse.*: ["iso-25010", "diataxis"]
points_de_controle:
  cadrage.cahier-des-charges: "PC1"
  design.prototype: "PC2"
  archi.architecture: "PC3"
  plan.backlog: "PC4"
  code.source: "PC5"
  test.*: "PC5"
  deploy.pipeline: "PC6"
  exploit.*: "PC7"
  finvie.plan: "PC8"
  transverse.doc-utilisateur: "PC9"
  transverse.matrice-tracabilite: "PC10"

7Exemple d'artefact instancié

Exemple complet d'un ADR (archi.adr) enregistré dans le registre, illustrant l'ensemble des champs de la section 3.

{
  "id": "9f3c2a1e-7b4d-4e8f-9a2c-1d5e6f7a8b9c",
  "type": "archi.adr",
  "version": "1.0.0",
  "statut": "valide",
  "auteur": "agent:architecture",
  "cree_le": "2026-08-01T10:15:00Z",
  "modifie_le": "2026-08-01T14:30:00Z",
  "valide_le": "2026-08-01T15:00:00Z",
  "valide_par": "humain:hkofi",
  "dependances": [
    { "lien": "derive_de", "cible": "archi.architecture@1.2.0" },
    { "lien": "conforme_a", "cible": "referentiel:adr" }
  ],
  "referentiels": ["adr", "c4"],
  "contenu": "docs/adr/0001-choix-postgresql.md",
  "garde-fous": {
    "revue_croisee": "ok",
    "conformite_referentiel": "ok",
    "coherence_terminologique": "ok"
  },
  "tags": ["base-de-donnees", "choix-technologique"],
  "historique": [
    { "de": "brouillon", "vers": "en_revue", "le": "2026-08-01T13:45:00Z", "par": "agent:architecture" },
    { "de": "en_revue", "vers": "valide", "le": "2026-08-01T15:00:00Z", "par": "humain:hkofi", "commentaire": "ADR validé — PC3" }
  ]
}

8Décisions à valider

Ce schéma introduit des choix de conception qui doivent être confirmés avant l'implémentation (point de contrôle humain de l'étape 1).

9Critères de complétude de l'étape 1

L'étape 1 est considérée terminée lorsque les conditions suivantes sont remplies :

• C1 — La taxonomie couvre les 10 familles du guide et chaque artefact de la section 3 possède un code famille.type.
• C2 — Le schéma de métadonnées est défini avec ses champs obligatoires et sa règle d'intégrité (historique append-only).
• C3 — La machine à états est implémentable : six statuts, quatre règles, transitions journalisées.
• C4 — Le modèle de dépendances couvre les dérivations canoniques et la règle de propagation amont → aval.
• C5 — Le fichier referentiels.yaml est défini et couvre toutes les familles.
• C6 — Les décisions D1 → D5 sont tranchées (validation humaine).