Le MIT cartographie les risques IA. Le prochain enjeu est de rendre les contrôles exécutables

Le MIT AI Risk Repository accomplit un travail essentiel : rendre le paysage des risques liés à l’intelligence artificielle plus lisible et plus comparable. En août 2026, sa page principale présente plus de 1 700 risques extraits de 74 cadres, puis les classe selon une taxonomie causale et une taxonomie de domaines comportant 7 domaines et 24 sous-domaines.

Le programme ne s’arrête plus à la question « qu’est-ce qui peut mal tourner ? ». Le MIT AI Risk Mitigation Map rassemble 831 mesures issues de 13 cadres et les organise en 4 grandes familles de contrôles. Le MIT AI Incident Tracker classe plus de 1 400 incidents réels. Le projet de cartographie de la gouvernance IA analyse environ 1 000 documents de gouvernance selon leurs risques couverts, secteurs, acteurs, étapes du cycle de vie, statut législatif et portée technique.

Cet ensemble devient progressivement une infrastructure de navigation entre quatre questions :

1. quels risques sont reconnus ;
2. quels incidents se sont matérialisés ;
3. quelles mitigations sont proposées ;
4. quels instruments de gouvernance couvrent ces objets.

Cette progression est majeure. Elle révèle aussi la couche suivante, beaucoup moins développée :

Comment passer d’un risque reconnu à un contrôle effectivement appliqué, puis démontrer ce que ce contrôle a changé dans l’information livrée et dans la restitution produite par un système ?

C’est à cet endroit que la gouvernance cesse d’être seulement descriptive.

Une taxonomie n’est pas un mécanisme d’exécution

Une taxonomie peut nommer un risque comme l’information fausse ou trompeuse, le manque de transparence, le défaut de robustesse ou les risques multi-agents. Une base de mitigations peut recommander des tests, de la documentation, de la surveillance après déploiement ou de la déclaration d’incidents.

Ces ressources répondent très bien à la question :

Quel type de problème devons-nous considérer et quelle famille de réponse paraît pertinente ?

Elles ne répondent pas automatiquement aux questions suivantes :

• quelle information interne détient l’autorité sur le cas précis ;
• quelles affirmations sont admissibles dans cette situation ;
• quelles contraintes doivent accompagner leur projection ;
• ce qui a réellement été livré au système ;
• ce que le système a restitué ;
• où l’écart est apparu ;
• quelle preuve permet de reconstruire la décision.

Aucune faiblesse n’est imputable au MIT ici. Ce n’est simplement pas le même objet. Une classification commune organise le territoire. Elle ne devient pas, par elle-même, l’autorité sémantique d’une organisation ni le moteur qui arbitre chaque interaction.

Le piège serait de fabriquer une taxonomie concurrente

La réaction la moins productive consisterait à créer un nouveau registre général des risques IA, avec son propre vocabulaire, ses propres catégories et une ambition de couverture universelle.

Ce travail existe déjà à une échelle académique, institutionnelle et internationale difficile à reproduire. Le besoin stratégique n’est pas de remplacer ces référentiels. Il est de rendre une architecture interne interopérable avec eux sans leur abandonner l’autorité sur son canon.

La distinction doit être nette :

• un référentiel externe qualifie un risque, une mitigation ou une obligation ;
• le canon interne déclare les entités, affirmations, termes, contraintes et règles de préséance qui gouvernent l’organisation ;
• une couche d’admission détermine ce qui peut être mobilisé dans un contexte donné ;
• une projection assemble l’information autorisée pour l’interaction ;
• le runtime livre cette projection sans élargir les permissions ;
• l’audit compare la restitution à ce qui devait être préservé ;
• le ledger conserve les événements et limites de preuve.

Le référentiel externe aide donc à expliquer pourquoi un contrôle compte. Il ne décide pas ce que l’organisation affirme ni ce que le runtime est autorisé à livrer.

Cette frontière est développée dans Un référentiel externe ne gouverne pas le canon et rendue opératoire par la Matrice risque → contrôle → preuve.

La leçon directe pour les Codebooks

Le même raisonnement s’applique à un Codebook, à un document d’identité, à un manuel de marque ou à toute formalisation sémantique externe.

Un Codebook peut être très riche. Il peut décrire une identité, des relations, une terminologie, des exclusions, une posture, des objets et des règles. Il peut servir à amorcer une architecture canonique. Il peut aussi devenir une vue lisible, régénérée à partir d’un canon plus structuré.

Il ne devrait toutefois pas être simultanément :

• la source d’entrée ;
• le format canonique ;
• le mécanisme de compilation ;
• la projection de sortie ;
• la preuve que la projection a été respectée.

Cette concentration crée une circularité. Le document finit par s’auto-valider : il fournit les assertions, définit leur lecture, produit la sortie et sert ensuite de preuve que la sortie est correcte.

La règle de sortie est simple :

Un Codebook peut être une source de bootstrap ou une vue régénérée. Il ne doit pas être les deux au même moment.

Un référentiel de risques suit la même frontière. Il peut être importé, versionné et cité. Il ne doit jamais se transformer silencieusement en autorité interne capable de modifier le canon ou d’élargir les permissions du runtime.

Le noyau doit rester plus petit que ses sources

L’alternative en cours de formalisation repose sur un Core volontairement réduit à cinq objets :

• Entity : l’objet auquel une affirmation, un terme ou une contrainte se rapporte ;
• Claim : ce qui est affirmé avec une portée, une autorité et des conditions ;
• Term : le vocabulaire gouverné et ses significations admises ou exclues ;
• Constraint : ce qui limite une interprétation, une projection ou une livraison ;
• Precedence : la règle qui arbitre l’autorité et les conflits.

Les états du Core demeurent bornés : allowed, conditional, forbidden et deprecated.

Un risque MIT ne devient pas un sixième objet. Une catégorie NIST ne devient pas un sixième objet. Un Codebook ne devient pas un sixième objet. Ils peuvent être reliés aux objets du Core par des correspondances versionnées, mais ces correspondances restent des projections dérivées.

Cette réduction protège l’architecture contre deux dérives :

1. chaque nouvelle source externe impose son propre modèle au noyau ;
2. l’accumulation documentaire remplace progressivement la décision d’autorité.

Le Core ne doit pas refléter tous les formats du monde. Il doit fournir le minimum stable permettant de les admettre, de les comparer et de les projeter sans perdre la provenance.

Du risque au contrôle, puis du contrôle à la preuve

Une architecture exécutable peut représenter la chaîne suivante :

référentiel externe versionné
        ↓
risque ou mitigation sélectionné
        ↓
mode de défaillance interprétative applicable
        ↓
autorité interne concernée
        ↓
objets du Core mobilisés
        ↓
décision d’admission
        ↓
projection contextuelle
        ↓
livraison par le runtime
        ↓
restitution observée
        ↓
écart et conformité
        ↓
événement de ledger

Le point important n’est pas la beauté du diagramme. C’est la possibilité de reconstruire chaque transition.

Pour un sous-domaine comme 3.1, information fausse ou trompeuse, la correspondance interne pourrait cibler la préservation d’une affirmation factuelle, de sa date, de sa portée et de ses exclusions.

Pour 7.4, manque de transparence ou d’interprétabilité, elle pourrait exiger la provenance de la source, la justification de l’admission, la règle de préséance appliquée et le mode de sortie sélectionné.

Pour 7.6, risques multi-agents, elle pourrait exiger la conservation de l’identité de la projection, des contraintes reçues, des transformations permises et du contexte transmis entre agents.

Ces correspondances ne prouvent pas que le risque général est résolu. Elles délimitent un sous-problème contrôlable et les éléments de preuve attendus.

Le statut épistémique ne peut plus rester implicite

Les travaux du MIT montrent eux-mêmes pourquoi cette distinction devient nécessaire. Le projet de cartographie de la gouvernance utilise des modèles pour classer des documents, mais précise que les scores restent indicatifs et que les classifications peuvent surattribuer une couverture. Son équipe a réduit une échelle de cinq niveaux à trois niveaux pour améliorer la fiabilité. Son étude de juin 2026 sur l’Incident Tracker compare plusieurs modèles à un petit consensus humain, documente les désaccords et envisage des scores de pertinence multiples plutôt qu’une catégorie unique.

Une architecture gouvernée doit donc distinguer au minimum :

• ce qui est déclaré par une autorité ;
• ce qui est dérivé par une règle déterministe ;
• ce qui est classifié par un modèle ;
• ce qui a été revu par un humain ;
• ce qui a été observé pendant une interaction.

Ces statuts ne sont pas interchangeables.

Une classification produite par un modèle peut aider à proposer une correspondance. Elle ne doit jamais muter silencieusement un Claim, activer une Constraint ou modifier une Precedence. Elle doit transporter son modèle, sa version, son protocole, sa date, son niveau de confiance et son statut de revue.

La règle est stricte :

Une observation ou une classification peut déclencher une révision. Elle ne modifie jamais directement le Core.

Le runtime ne doit pas interroger un référentiel vivant

Brancher directement le runtime sur une feuille distante, une interface Airtable ou une base externe créerait une dépendance non maîtrisée. Une modification éditoriale, un changement de schéma, une indisponibilité ou une nouvelle classification pourrait alors affecter la livraison sans compilation ni approbation locale.

Le bon chemin est un mécanisme de capture gouvernée :

source externe
        ↓
version ou état sélectionné
        ↓
snapshot local
        ↓
hachage et attribution
        ↓
normalisation dans un espace de noms externe
        ↓
revue des correspondances
        ↓
compilation
        ↓
activation contrôlée

Le MIT publie ses données sous licence CC BY 4.0. Cette licence facilite la réutilisation avec attribution. Elle ne change pas la frontière d’autorité : une donnée réutilisable n’est pas automatiquement une donnée canonique pour l’organisation qui l’importe.

Le runtime doit consommer uniquement une projection compilée et approuvée. Il ne doit pas aller chercher une interprétation nouvelle au moment de répondre.

Une mitigation déclarée n’est pas encore une mitigation efficace

La taxonomie des mitigations du MIT contient des catégories particulièrement compatibles avec une chaîne de gouvernance interprétative :

• tests et audits ;
• gouvernance des données ;
• surveillance après déploiement ;
• réponse aux incidents ;
• documentation des systèmes ;
• divulgation des risques ;
• déclaration des incidents ;
• divulgation de la gouvernance.

Mais le MIT précise aussi une limite essentielle : sa taxonomie ne classe pas encore les mitigations selon leur efficacité, leur difficulté d’implantation ou leurs interactions.

C’est exactement l’espace expérimental intéressant.

La valeur ne consiste pas à écrire qu’un contrôle existe. Elle consiste à observer, sous un protocole défini, si ce contrôle :

• réduit un type d’écart ;
• préserve mieux une contrainte ;
• améliore la stabilité entre répétitions ;
• empêche une extrapolation interdite ;
• conserve la provenance dans une chaîne multi-agents ;
• produit une décision plus reconstructible.

Cette mesure doit rester proportionnelle à ce qui a réellement été testé. Une amélioration dans un banc d’essai ne prouve pas que tous les modèles externes respecteront la gouvernance. Une observation de conformité ne devient pas une attestation cryptographique. Un contrôle efficace sur une classe de Claim ne résout pas un domaine de risque entier.

La boucle complète

La proposition peut être résumée par une boucle courte :

Authority
    → admissibility
    → projection
    → delivery
    → restitution
    → deviation
    → conformance
    → ledger

La projection dépend de l’autorité, de la politique de gouvernance, de l’intention et du contexte :

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

L’écart compare la projection à la restitution observée :

Δ = g(P, R)

La conformité qualifie cet écart selon la gouvernance applicable :

Q = h(Δ, G)

Un référentiel comme celui du MIT peut contribuer à G en fournissant une qualification externe du risque ou une famille de contrôle. Il ne remplace ni A, ni le Core, ni la décision d’admission.

Ce que cette direction permet réellement

Cette architecture ne promet pas de contrôler les modèles tiers. Elle permet quelque chose de plus précis et de plus défendable :

• relier un risque reconnu à un périmètre interne explicite ;
• transformer une recommandation générale en exigence de contrôle contextualisée ;
• conserver la provenance de la décision ;
• livrer une projection déterministe ;
• comparer la restitution à ce qui devait être préservé ;
• publier une preuve bornée et contestable ;
• mesurer l’efficacité du contrôle dans le temps.

Le marché produit déjà beaucoup de documents expliquant ce qui devrait être gouverné. La rareté se déplace vers la capacité de répondre à une question plus exigeante :

Montre-moi quel contrôle a été activé, sur quelle autorité il reposait, ce qui a été livré, ce que le système a reconstruit et quelle limite demeure après l’observation.

C’est là que se situe le passage d’une gouvernance déclarative à une assurance interprétative.

Frontière de cette proposition

Aucune affiliation, validation ou approbation du MIT n’est revendiquée. Le MIT AI Risk Repository sert ici de référentiel externe et de cas d’interopérabilité.

Cette proposition ne couvre qu’un sous-ensemble des risques : ceux pour lesquels une information d’autorité peut être gouvernée, projetée, livrée et comparée à une restitution. Elle ne remplace ni la sécurité des modèles, ni la cybersécurité, ni la sûreté générale, ni la conformité réglementaire complète.

Elle fournit toutefois un pont qui manque souvent entre les taxonomies de risques et les systèmes réels : risque reconnu → contrôle exécutable → preuve observable → limite résiduelle.

Références externes

• MIT AI Risk Repository, consulté le 18 août 2026.
• MIT AI Risk Mitigation Map, consulté le 18 août 2026.
• MIT AI Incident Tracker, consulté le 18 août 2026.
• Mapping the AI Governance Landscape: April 2026 Update, MIT AI Risk Initiative.
• AI Incident Tracker June 2026 Update, MIT AI Risk Initiative.