Matrice risque → contrôle → preuve

Statut du framework

Cette matrice propose une méthode d’alignement. Elle n’est ni une certification, ni une norme adoptée, ni une preuve qu’un contrôle fonctionne dans tous les environnements.

Son objet est précis :

Relier un élément externe versionné à un mode de défaillance interne, à une autorité, à des objets du Core, à une décision d’admission, à une projection, à une observation et à une limite résiduelle.

La matrice met en œuvre la position Un référentiel externe ne gouverne pas le canon.

1. Préconditions

Aucune correspondance ne doit être activée avant que les éléments suivants existent.

1.1 Core identifié

Le système doit utiliser les cinq objets v0.1 :

• Entity ;
• Claim ;
• Term ;
• Constraint ;
• Precedence.

La matrice n’en ajoute aucun.

1.2 Autorités explicites

Chaque objet mobilisé doit avoir une source, une portée d’autorité et une règle de préséance. Une page officielle n’est pas automatiquement autoritaire sur toutes les classes de Claim.

1.3 Règles d’admission

La décision d’utiliser un objet dans une situation doit être séparable de son statut canonique. Un Claim peut être allowed dans le Core mais non admissible dans une interaction parce qu’une condition n’est pas satisfaite ou ne peut pas être évaluée.

1.4 Projection déterministe

Le système doit pouvoir produire une projection reproductible à partir de l’autorité, de la politique, de l’intention et du contexte.

1.5 Observation bornée

Le protocole d’observation doit distinguer la restitution observée, l’écart, le verdict de conformité et la limite de preuve. Le ledger ne constitue pas une attestation de l’état interne d’un modèle tiers.

2. Unité de travail

Une ligne de matrice ne correspond pas à un domaine entier comme « désinformation », « transparence » ou « risques multi-agents ».

Elle correspond à une unité plus petite :

un mode de défaillance
+ une classe de Claim
+ un contexte d’application
+ un contrôle attendu
+ une preuve observable

Exemple :

Perte de la date de validité d’une certification lors d’une réponse à une question de conformité dans une juridiction donnée.

Cette unité peut être reliée à un risque externe plus large. Elle demeure assez précise pour produire une condition, une projection et un test.

3. Structure minimale de la matrice

4. Étape 1 : capturer le référentiel

Le référentiel doit être importé dans un espace de noms externe, jamais dans le Core.

Le manifeste de capture devrait contenir :

framework:
  namespace: mit-airi
  source_url: https://airisk.mit.edu/risks
  snapshot_date: 2026-08-18
  imported_at: 2026-08-18T00:00:00Z
  license: CC-BY-4.0
  snapshot_sha256: "..."
  canonical: false

Les dates illustratives doivent être remplacées par les valeurs réelles de l’import. Le hachage porte sur l’artefact effectivement conservé, pas sur l’URL.

La capture doit préciser si elle représente :

• une version publiée ;
• un export daté ;
• un snapshot d’une base vivante ;
• une sélection partielle ;
• une adaptation locale.

Une adaptation doit conserver la source et distinguer le contenu original de l’interprétation ajoutée.

5. Étape 2 : qualifier le mode de défaillance interne

Le libellé externe ne suffit pas. Il faut décrire ce qui peut réellement échouer dans l’architecture étudiée.

Un mode de défaillance recevable précise :

• l’objet concerné ;
• la transformation indésirable ;
• le contexte où elle devient conséquente ;
• le signe observable de l’écart ;
• ce qui demeurerait hors mesure.

Exemples :

• omission d’une exclusion essentielle ;
• généralisation d’un Claim au-delà de sa portée ;
• confusion entre une source officielle et une évaluation externe ;
• perte d’une contrainte pendant un transfert agent-à-agent ;
• réponse produite malgré une condition non évaluée ;
• classification probabiliste présentée comme fait déclaré.

6. Étape 3 : identifier l’autorité interne

Chaque mode de défaillance doit être relié à une classe de Claim et à l’autorité capable de la gouverner.

La matrice doit répondre :

1. quelle source déclare l’information ;
2. sur quelle classe de Claim elle possède autorité ;
3. quelles sources externes peuvent compléter ou contester ;
4. quelle Precedence s’applique en cas de conflit ;
5. quelles limites restent hors de l’autorité interne.

Une organisation peut faire autorité sur la date et la portée d’une certification qu’elle publie. Elle ne peut pas utiliser cette autorité pour certifier sa réputation générale ou invalider une critique indépendante.

7. Étape 4 : relier la correspondance aux cinq objets

Une ligne ne crée pas d’objet nouveau. Elle référence les objets existants ou propose, sous revue, un changement interne distinct.

Exemple conceptuel :

core_refs:
  entity: entity:organization-x
  claims:
    - claim:certification-y-status
  terms:
    - term:certification-y
  constraints:
    - constraint:jurisdiction-required
    - constraint:validity-date-required
  precedence:
    - precedence:certification-registry-over-marketing-copy

Si une Constraint manque, la matrice peut ouvrir une proposition de modification. Elle ne l’active pas elle-même.

8. Étape 5 : tester l’applicabilité et l’admission

L’applicabilité doit considérer au minimum :

• l’entité ;
• l’intention ou la classe de question ;
• l’audience ;
• le canal ou l’agent ;
• la juridiction ;
• la temporalité ;
• la sensibilité ;
• le type de décision possible ;
• les conditions positives ;
• les conditions de non-applicabilité.

Le verdict d’une condition peut être :

• satisfaite ;
• non satisfaite ;
• indéterminée ;
• inexécutable.

Les deux derniers états ne valent ni permission ni conformité.

Si une condition nécessaire est non satisfaite, indéterminée ou inexécutable, le Claim conditionnel est non admissible pour cette projection. Aucun score moyen ne peut compenser une condition nécessaire manquante.

9. Étape 6 : compiler le contrôle de projection

Le contrôle ne doit pas être formulé comme une recommandation vague. Il doit déclarer un comportement vérifiable.

Exemples :

• inclure la date de validité et la juridiction lorsque le Claim de certification est livré ;
• interdire la généralisation d’une observation locale à l’ensemble de l’organisation ;
• conserver l’identifiant de la source et de la projection dans un transfert multi-agents ;
• produire une clarification lorsque deux entités homonymes restent possibles ;
• produire une non-réponse lorsque la source d’autorité requise est absente ;
• marquer une classification de modèle comme probabiliste et non canonique.

Une politique compilée peut être représentée ainsi :

P = f(A, G, I, C)

La matrice contribue à G. L’autorité canonique demeure dans A.

10. Étape 7 : déclarer la preuve avant l’observation

La preuve attendue doit être définie avant l’exécution. Sinon, le système pourra choisir après coup les traces qui rendent le résultat favorable.

Selon le contrôle, la preuve peut comprendre :

• l’identifiant et la version du snapshot externe ;
• la correspondance approuvée ;
• les références exactes aux objets du Core ;
• le résultat d’admission ;
• les conditions satisfaites ou non évaluées ;
• la projection compilée et son hachage ;
• le paquet réellement livré ;
• la restitution brute ;
• le protocole d’audit ;
• l’écart classifié ;
• le verdict de conformité ;
• l’événement de ledger ;
• les limites résiduelles.

Une preuve absente ne doit pas être remplacée par une explication narrative rétrospective.

11. Étape 8 : observer sans muter le Core

La restitution R est comparée à la projection P :

Δ = g(P, R)

Le résultat de conformité est ensuite qualifié selon la gouvernance applicable :

Q = h(Δ, G)

Le verdict peut notamment distinguer :

• conformité observée ;
• conformité partielle ;
• déviation mineure ;
• déviation critique ;
• résultat indéterminé ;
• contrôle inexécutable ;
• observation insuffisante.

Ces verdicts appartiennent à la couche d’observation. Ils ne modifient pas les statuts allowed, conditional, forbidden ou deprecated du Core.

Une déviation répétée peut ouvrir une proposition de correction. La modification suit ensuite le processus d’autorité normal.

12. Exemple illustratif avec le MIT AI Risk Repository

Les lignes suivantes illustrent la méthode. Elles ne constituent ni une correspondance officielle du MIT, ni une certification, ni une intégration active.

Les catégories de mitigation MIT peuvent ensuite servir à qualifier la famille de contrôle, par exemple :

• 3.1 Testing & Auditing pour le protocole de comparaison ;
• 3.5 Post-deployment Monitoring pour l’observation longitudinale ;
• 4.1 System Documentation pour la documentation de l’architecture et des limites ;
• 4.2 Risk Disclosure pour la publication du risque et de la limite résiduelle ;
• 4.3 Incident Reporting pour les déviations critiques ;
• 4.4 Governance Disclosure pour les règles de décision et les autorités.

Cette qualification externe ne remplace pas la description interne du contrôle.

13. Statut épistémique des données de la ligne

Chaque valeur doit déclarer sa provenance épistémique.

Une donnée model_classified devenue human_reviewed conserve l’historique de sa classification initiale. La revue ne doit pas effacer le chemin ayant produit la proposition.

14. Versionnement et réversibilité

Chaque activation doit lier :

• le SHA du snapshot externe ;
• la version de la matrice ;
• le SHA ou identifiant de l’état canonique ;
• la version de la politique compilée ;
• la version du runtime ;
• le protocole d’audit ;
• la fenêtre d’observation.

Lorsqu’un référentiel externe change, trois opérations sont séparées :

1. importer un nouveau snapshot ;
2. calculer et revoir les différences ;
3. décider si une correspondance doit être modifiée ou réactivée.

Le nouvel état ne remplace jamais automatiquement l’ancien. Le système doit pouvoir rejouer une observation avec l’état qui était actif au moment de la livraison.

15. Fixtures minimales

Avant activation, la matrice doit passer des fixtures couvrant au moins :

1. un risque externe sans correspondance interne : aucun effet sur la projection ;
2. une correspondance proposée mais non approuvée : inactive ;
3. une condition satisfaite : projection conforme à la permission ;
4. une condition non satisfaite : Claim non admissible ;
5. une condition indéterminée : aucune permission implicite ;
6. une Constraint contradictoire à même autorité : échec de compilation ;
7. une couche inférieure tentant d’élargir une permission : rejet ;
8. une classification de modèle non revue : aucun changement du Core ;
9. un snapshot externe mis à jour : aucune activation automatique ;
10. une restitution déviante : événement de ledger sans mutation canonique.

Les versions française et anglaise doivent décrire la même architecture. Le français demeure la référence normative lorsque la spécification sera stabilisée ; l’anglais en sera une traduction, pas une architecture parallèle.

16. Critères d’acceptation

Une ligne est activable seulement si :

• le référentiel et son snapshot sont identifiés ;
• la licence et l’attribution sont préservées ;
• le mode de défaillance est précis ;
• la classe de Claim et l’autorité sont explicites ;
• les références aux cinq objets sont valides ;
• l’applicabilité inclut les conditions négatives ;
• la décision d’admission est déterministe ;
• le contrôle n’élargit aucune permission ;
• les preuves attendues sont déclarées ;
• la limite résiduelle est explicite ;
• les fixtures passent ;
• la correspondance peut être désactivée sans mutation du Core.

Si un seul critère nécessaire manque, le verdict est non activable. Une moyenne positive ne compense pas une condition nécessaire absente.

17. Sortie attendue

L’application de la méthode doit produire un paquet de décision autoportant contenant :

1. le manifeste du snapshot externe ;
2. la ligne de correspondance versionnée ;
3. les références aux objets canoniques ;
4. la décision d’autorité ;
5. les règles d’applicabilité et d’admission ;
6. la politique de projection compilée ;
7. les fixtures et leurs résultats ;
8. le contrat de preuve ;
9. la limite résiduelle ;
10. le plan de retrait ou de remplacement.

Le paquet ne prouve pas encore l’efficacité du contrôle. Il rend le contrôle exécutable, testable et auditable.

Règle finale

La matrice ne sert pas à coller une étiquette de risque sur un système. Elle sert à maintenir une chaîne de responsabilité :

référence externe
→ qualification
→ autorité interne
→ admission
→ contrôle
→ projection
→ livraison
→ observation
→ preuve bornée

À aucun moment la référence externe ne devient le canon, et à aucun moment l’observation ne réécrit directement ce canon.