# La preuve de conformité du système que vous livrez

Pour l'équipe qui livre un système agentique avec runward : les artefacts de la mission deviennent une preuve prête pour l'audit, cadrée pour ISO 42001, NIST AI RMF et l'EU AI Act, exportée en OSCAL pour alimenter votre programme de conformité, jamais le satisfaire.

Toute cette page tient sur une invariance : un cœur universel constant, un prisme réglementaire interchangeable au-dessus, et deux sorties dont une seule porte l'étiquette du régime.

> **Schéma.** La porte déterministe vérifie un cœur universel (OWASP ASI01–ASI10), sans aucune régulation dans le chemin de décision. Un prisme réglementaire (ISO/IEC 42001, NIST AI RMF ou EU AI Act Annexe IV), donnée versionnée, se pose au-dessus : on en choisit un seul, les autres sont interchangeables. Il alimente deux sorties : un brouillon de readiness étiqueté au régime, et un export OSCAL 1.2.2 neutre, identique quel que soit le prisme (seule l’étiquette de citation change).

## La preuve du système agentique que vous livrez

Cette page s'adresse à l'équipe qui construit et livre un système agentique avec runward. L'objectif est précis et concret : transformer les artefacts d'ingénierie de la mission en **preuve d'appui prête pour l'audit sur le système que vous livrez**, sous une forme que votre programme de conformité peut consommer. Le public visé, c'est votre équipe de livraison et les personnes de la conformité, du risque ou de l'audit qui liront ce que vous remettez.

> Évaluer runward-l'outil comme fournisseur dans une organisation réglementée est une autre question, avec un autre public. Si une équipe TPRM, sécurité ou achats doit valider la CLI elle-même, orientez-la plutôt vers [Adopter runward en environnement régulé](https://runward.dev/docs/compliance/regulated-adoption/).

Les garde-fous ici sont des propriétés de la **preuve**, pas de la façon dont l'outil est hébergé :

- **Elle alimente, elle ne valide jamais.** Ce que runward produit appuie votre travail de conformité ; ce n'est pas un validateur de conformité et cela ne prétend jamais l'être. La formulation est appliquée : jamais « conforme / certifié / satisfait », toujours « preuve d'appui prête pour l'audit » et « alimente / appuie ».
- **Un brouillon, jamais une affirmation.** Chaque artefact est généré comme un brouillon incomplet, porteur d'un en-tête non négociable qui le dit. Il est assemblé de façon déterministe à partir d'artefacts au repos, sans aucun appel de modèle.
- **L'acceptation relève de l'auditeur.** runward assemble la preuve ; il ne la note pas. Seul un organisme accrédité certifie, et le go/no-go est toujours la décision de quelqu'un d'autre.

## La garde universelle et les prismes réglementaires

### La garde ne connaît aucune réglementation

[La garde déterministe](https://runward.dev/docs/concepts/the-gate/) est **universelle et ne connaît aucune réglementation** : elle vérifie les décisions tracées et la conformité aux règles au regard de l'OWASP Top 10 for Agentic Applications (ASI01–ASI10), une taxonomie de sécurité indépendante de toute région. Aucune branche propre à une réglementation n'entre jamais dans le chemin de décision. La posture par défaut honnête est **sécurité seule** : elle ne fait aucune affirmation réglementaire.

### Une réglementation est un prisme interchangeable et versionné

Une réglementation est une **couche de cadrage interchangeable** posée sur ce noyau universel (ADR-0015). Trois prismes sont livrés aujourd'hui :

- **ISO/IEC 42001** : l'ancrage indépendant de toute région (certifiable, n'offense aucun marché).
- **NIST AI RMF** : le prisme américain.
- **EU AI Act (Annexe IV)** : le prisme européen.

C'est tout l'objet : la preuve produite au build voyage presque partout où l'on attend de la gouvernance ; ce qui change d'un régime à l'autre, c'est l'**étiquette de citation**, pas l'artefact. Intégrer l'EU AI Act dans la garde a été rejeté : cela sacrifierait le marché américain, vieillirait mal à mesure que les réglementations évoluent, et casserait l'invariant zéro-LLM / universel.

Chaque prisme est une **donnée versionnée** (`regimes/<regime>@<version>.json`), pas du code. La voix produit stable (cadrage du brouillon, narration) vit dans le code de la CLI ; chaque fichier JSON ne porte que ce qui suit un texte externe daté : références de clauses, lignes de l'Annexe IV, le tableau de correspondance, la liste de ce qui incombe à l'opérateur. Un changement réglementaire est un **nouveau fichier, jamais une modification** d'une version livrée, de sorte qu'un pack reste réassemblable au regard du prisme exact que son auditeur a vu. Les chaînes de version ont une forme de date / à zéros de remplissage, si bien que l'ordre lexicographique équivaut à l'ordre chronologique, et le choix par défaut est la plus haute version livrée.

## `runward compliance <regime>` : la commande

`runward compliance <regime>` est une **commande déterministe, en lecture seule, zéro-LLM, hors de la garde**. Elle lit les artefacts réels de la mission au repos et assemble un *brouillon* de préparation à l'évaluation sur le système agentique que cette mission gouverne. Aucun appel de modèle, aucune extraction d'état en direct, rien ne s'exécute.

Utilisation et options :

```
runward compliance [regime]          # regime: iso-42001 | nist-ai-rmf | eu-ai-act
  -p, --path <path>                  # project directory
  --regime-version <version>         # pin the lens (default: highest shipped, see regimes/)
```

**Ce qu'elle lit** (tout au repos, dans le répertoire `runward/` de la mission) :
- Les **règles** de l'artisanat et leurs étiquettes OWASP ASI. Elle préfère le `rules/` propre à la mission, avec repli sur les règles livrées avec le paquet. Les fichiers sont lus dans l'ordre trié, si bien que la sortie est identique octet pour octet d'un système de fichiers à l'autre.
- Les **manifestes de conformité** : les mêmes paires (phase, livrable) gardées que `runward check --strict` vérifie, depuis une source unique.
- Le **journal des ADR** dans `runward/adr/`, en ignorant le gabarit, le README et les fichiers DRAFT.
- La présence des documents de gouvernance : `governance/threat-model.md` et `governance/evaluation-rubric.md`.

**Ce qu'elle écrit** (dans `runward/compliance/`) :
- Le brouillon de préparation lisible `<regime>-readiness.md`.
- Le fichier lisible par machine, neutre vis-à-vis du régime, `oscal-component-definition.json`.

Les deux sont toujours régénérés (artefacts générés, `force: true`).

**Elle exige une mission.** La commande ne s'exécute que contre une mission `runward/`. **Codes de sortie :** `0` = brouillon écrit ; `2` = aucune mission `runward/` trouvée, régime absent/non pris en charge, ou version de correspondance inconnue. Un agent doit traiter le code 2 comme un mauvais usage de l'opérateur, pas comme un échec de la garde.

**Chaque brouillon porte un en-tête DRAFT non négociable** indiquant qu'il s'agit d'un brouillon, incomplet, qui n'est pas une déclaration de conformité, assemblé de façon déterministe sans aucun appel de modèle, et que seul un organisme accrédité certifie. Chaque prisme se termine aussi par une section **« Requis de la part de l'opérateur / de l'organisation (runward ne peut pas le produire) »** : les parties managériales, juridiques et organisationnelles qu'aucun outil ne peut assembler à partir d'artefacts d'ingénierie.

## Ce que chaque prisme remplit et ce qu'il vous laisse

Chaque prisme remplit les parties qu'un auditeur peut lire directement dans les artefacts d'ingénierie, et découpe explicitement les parties qui incombent à l'organisation.

- **ISO/IEC 42001** : remplit les colonnes statut d'implémentation + preuve de la Déclaration d'Applicabilité, le tableau de couverture des risques ASI (alimente les clauses 6.1.2 / 6.1.3), et les enregistrements de décisions de conception ADR. Laisse à l'opérateur : la politique IA (5.2), le périmètre du SMIA (4.3), le *jugement d'applicabilité* lui-même, la méthodologie et l'acceptation des risques, l'évaluation d'impact, l'audit interne et la revue de direction, ainsi que les journaux d'événements IA à l'exécution (A.6.2.8).
- **NIST AI RMF** : remplit la documentation MEASURE/TEVV et un tableau de correspondance indicatif (non approuvé par le NIST) ASI→AI RMF qui se range surtout sous MEASURE et MANAGE. L'AI RMF est explicitement présenté comme **une orientation volontaire, sans réussite/échec et sans certification**. Laisse à l'opérateur : tout GOVERN, MAP, la décision go/no-go de MANAGE, et les choix de profil / tolérance au risque.
- **EU AI Act (Annexe IV)** : solide sur le **Point 2** (architecture, validation, cybersécurité) et sur la justification de conception / l'historique des changements (le journal des ADR y correspond presque mot pour mot). Le brouillon indique qu'il ne satisfait **pas** la journalisation à l'exécution de l'Article 12 et **n'est pas** une déclaration de conformité signée. La carte de couverture de l'Annexe IV détaille, point par point, ce que runward fournit et ce que le fournisseur doit fournir. À noter, les faits datés de ce prisme : les obligations à haut risque s'appliquent à partir du **2 décembre 2027** (reportées par le Digital Omnibus on AI), tandis que l'échéance du 2 août 2026 reste réelle pour *d'autres* obligations (transparence de l'Article 50, GPAI) mais **n'est pas** la date limite pour le haut risque.

Le fil commun : l'applicabilité, l'acceptation des risques, la politique, la validation par la direction, la déclaration de conformité et les journaux d'exécution sont toujours **requis de la part de l'opérateur / de l'organisation**. Aucun outil ne peut les produire à partir d'artefacts d'ingénierie, et chaque brouillon le dit.

## L'export OSCAL 1.2.2 et ce qu'il alimente

À côté du brouillon de préparation, la commande émet `oscal-component-definition.json` : une **component-definition OSCAL, version 1.2.2**, intitulée « le système agentique gouverné par cette mission runward ». C'est la **couche d'interopérabilité lisible par machine, neutre vis-à-vis du régime**, pour que la preuve circule vers les outils GRC / auditeur que runward ne possédera jamais.

### Comment il est construit

- Les 10 catégories OWASP ASI deviennent 10 `implemented-requirements`, chacune visant un contrôle OSCAL (`asi-01`…`asi-10`) issu du catalogue OWASP Agentic Top 10. Chaque exigence renvoie aussi au brouillon de préparation co-généré.
- **Le statut d'implémentation est *dérivé*, jamais affirmé :** `planned` si aucune règle ne couvre ce risque (une lacune) ; `implemented` seulement s'il existe au moins une ligne de manifeste et que chaque ligne de manifeste de chaque règle de correspondance est `applied` ; sinon `partial` (couvert mais dévié / n-a / pas encore dans un manifeste). Une règle couverte mais non justifiée donne `partial`, jamais `implemented`. Le statut agrège *toutes* les lignes de manifeste de tous les livrables, en évitant délibérément la dépendance à l'ordre de la première ligne.
- **Les UUID sont déterministes** : de forme RFC-4122 v5, dérivés d'une graine SHA-256, si bien que deux exécutions sur les mêmes artefacts produisent un OSCAL identique octet pour octet, sans UUID aléatoire.
- Le prisme qui a cadré le pack est estampillé dans `metadata.props` sous `runward-regime-lens` (par ex. `eu-ai-act@2024-1689`) ; la structure de contrôle elle-même reste neutre vis-à-vis du régime.
- Le champ `remarks` des métadonnées inscrit en dur qu'il s'agit d'un BROUILLON / d'une preuve d'appui uniquement : PAS une déclaration de conformité, PAS une certification, PAS une évaluation de conformité.

### Ce qu'il alimente, et la limite honnête

Parce que c'est une component-definition OSCAL 1.2.2 standard, tout outil GRC compatible OSCAL l'ingère tel quel. La preuve hors ligne de sa bonne forme est la validation de schéma au regard du schéma NIST embarqué, avec des contrôles négatifs.

Au-delà, un job CI distinct charge le pack dans **IBM compliance-trestle** : une véritable boîte à outils de conformité utilisée dans les flux FedRAMP/NIST, dont les modèles sont générés à partir des métaschémas NIST, ce qui prouve qu'il est ingérable par un outil indépendant authentique. Ce job trestle tourne dans un job Python *séparé* avec réseau pour `pip install` ; le chemin de test Node central reste sans dépendance et isolé du réseau.

L'ingestion de bout en bout dans *votre* GRC SaaS spécifique (RegScale, Paramify, Xacta) est **votre étape de vérification, pas une garantie de runward**. La procédure d'ingestion manuelle (générer, éventuellement pré-vérifier au regard du schéma embarqué avec `ajv-cli`, importer comme component definition, joindre le brouillon de préparation comme narration, remplir les sections opérateur) est documentée étape par étape.

### Publié comme mini-spécification citable

La correspondance est aussi publiée comme **mini-spécification versionnée et citable** (`docs/spec/runward-oscal-mapping.md`, v1.0) accompagnée d'un `CITATION.cff`, de sorte qu'un fournisseur GRC ou un auditeur puisse implémenter ou critiquer la correspondance sans lire le TypeScript de runward.

## Garder les faits réglementaires honnêtes

runward épingle deux types de faits qui vivent **hors** du dépôt et évoluent à leur propre rythme : la version du schéma OSCAL, et les faits réglementaires datés dans `regimes/*.json`. Les garder honnêtes est un mécanisme délibéré, l'ADR-0032.

La défaillance que l'ADR-0032 corrige : le pin OSCAL de runward avait silencieusement pris deux générations de retard (émettant encore 1.1.2 alors que le NIST était passé à 1.2.2) **et aucun test n'a rougi**, parce que chaque garde intra-gate compare *le dépôt à la doc*, jamais *le dépôt au monde*.

La décision a deux volets :

1. **Suivre la version OSCAL courante : passée à 1.2.2 maintenant.** Le passage s'est révélé trivial et sans risque : la sortie de runward valide au regard du schéma NIST 1.2.2, trestle 4.2.0 ingère un pack estampillé 1.2.2, la différence de schéma ne retire aucune définition et ne touche rien de ce que runward émet, et `oscal-version` n'alimente pas les graines d'UUID. Les packs précédemment émis en 1.1.2 restent valides ; aucune migration n'est due. Un passage futur reste un acte humain de *versioned-port* tracé, jamais automatique.
2. **Surveiller les faits datés hors bande, jamais dans la garde.** Un workflow planifié et **non bloquant** : `.github/workflows/watch-external-facts.yml`, hebdomadaire (lundis 06:17 UTC), avec réseau, hors de la garde déterministe, compare le `OSCAL_VERSION` épinglé à la dernière release `usnistgov/OSCAL`, et chaque date `reviewBy` de `regimes/*.json` à aujourd'hui. À la moindre dérive, il **ouvre ou rafraîchit une unique issue de suivi** ; il ne bump jamais un pin et ne fait jamais échouer un build.

### Les dates reviewBy

Les dates `reviewBy` : EU AI Act → `2026-08-02` (juste après l'échéance de l'Article 50), ISO 42001 et NIST AI RMF → un point de contrôle annuel `2027-01-01`. Point crucial, `reviewBy` est une métadonnée qui **n'entre jamais dans l'OSCAL** et n'altère jamais le contenu du prisme : elle enregistre *quand re-vérifier*, pas *ce que dit la correspondance*, si bien qu'elle ne viole pas la règle « ne jamais modifier une correspondance livrée ».

### Pourquoi pas d'horloge ni de réseau dans la garde

Un test piloté par l'horloge ou par le réseau *à l'intérieur* de la garde a été rejeté : il mettrait l'horloge murale et le réseau dans le chemin critique déterministe et zéro-réseau : un test qui rougit un mardi sans aucun changement de code est exactement le non-déterminisme que runward existe pour bannir. La veille tourne là où le non-déterminisme est inoffensif : hors bande, non bloquante, issue uniquement.

## Pourquoi OSCAL, et non un format européen

C'est un choix délibéré et documenté. Le cadre stratégique : **il n'existe aucun format machine européen (ni autre) vers lequel migrer.**

- **EUCS et SecNumCloud sont des certifications de service cloud.** Elles certifient un *fournisseur de service cloud*, pas un outil de développement local, et ne peuvent structurellement pas s'appliquer à une CLI qui tourne dans votre propre dépôt sans surface hébergée.
- **La documentation technique de l'EU AI Act (Annexe IV) n'a aucun format exécutable / machine.** C'est un dossier technique en prose. Il n'y a rien de lisible par machine à émettre en tant qu'Annexe IV. runward *alimente* plutôt ce fichier en prose via le prisme EU AI Act (Point 2, le journal des ADR).
- **OSCAL est le seul format machine mature,** et il gagne du terrain hors des États-Unis : l'ECSO OSCAL Task Force et le contexte du CRA, si bien que le pari sensé est de rester sur OSCAL et de le garder *à jour*, plutôt que d'inventer un format. Adopter ou inventer un format machine européen a été explicitement rejeté : aucun n'existe comme norme adoptée, et en inventer un est l'inverse de la promesse « prête pour l'audit ».

La question n'a donc jamais été « quel format » mais « comment garder honnêtes et à jour dans le temps le pin OSCAL et la formulation réglementaire datée », ce que fait exactement la veille de dérive ci-dessus.

## Voir aussi

- [Adopter runward en environnement régulé](https://runward.dev/docs/compliance/regulated-adoption/)
- [Preuve et intégrité](https://runward.dev/docs/concepts/evidence/)
- [Sceller, règles et méthode](https://runward.dev/docs/concepts/six-phases/sealing-and-method/)
- [ADR / décisions](https://runward.dev/docs/reference/adr/)