Panorama de la sécurité de l’IA

Cadres publics de sécurité et de gestion des risques

Les cadres sont comparés selon leur couverture du cycle de vie, la gouvernance, l’identification, la mesure et le traitement des risques, la surveillance, la gestion des incidents et l’amélioration continue. Le NIST AI RMF et la norme ISO/IEC 42001 remplissent des fonctions différentes : le corpus enregistre leur champ d’application officiel et leurs caractéristiques d’évaluation de la conformité, sans les traiter comme des certifications interchangeables.

Les instruments de l’OCDE et de l’UNESCO apportent un contexte normatif et politique. Leur présence dans le corpus n’établit ni leur adoption ni leur mise en œuvre par une entreprise ou un pays donné en l’absence de preuves distinctes.

Informations des développeurs sur les modèles et les systèmes

Les fiches de modèles conservent les capacités déclarées, les approches d’évaluation, les limites, les mesures d’atténuation, les conditions d’accès et les dates de mise à jour, sans compléter les champs non documentés. L’éditeur est affiché afin que le lecteur puisse identifier une preuve de première partie.

La déclaration d’un développeur selon laquelle des essais ont eu lieu constitue une information vérifiable. Elle ne confirme pas à elle seule, de manière indépendante, le résultat, l’exhaustivité du jeu de tests ou l’efficacité des mesures d’atténuation.

Limites de l’assurance

Un cadre publié atteste un engagement de gouvernance, et non la preuve de sa mise en œuvre ou de la sécurité d’un modèle. Une fiche de modèle constitue une preuve de divulgation, non une certification. Une évaluation indépendante est limitée par sa méthode et la version testée, tandis qu’une constatation réglementaire est limitée par sa juridiction et son action juridique.

Pour ces raisons, le Panorama de la sécurité publie des volumes de preuves et des catégories de provenance, et non un classement global de sécurité.

Quatre couches de preuves distinctes

Le rapport distingue les cadres publics, les informations des développeurs, les évaluations indépendantes et les incidents ou mesures d’exécution. Un même dossier peut éclairer plusieurs questions analytiques, mais sa provenance ne change pas. Une fiche système, par exemple, reste une déclaration du développeur même lorsqu’elle décrit des essais approfondis.

Cette structure évite de confondre le volume d’informations divulguées avec une sécurité démontrée de façon indépendante, et empêche de généraliser un incident isolé en une conclusion non étayée sur l’ensemble d’un modèle.

Registre des évaluations indépendantes

Une évaluation indépendante exige un évaluateur distinct du développeur du modèle, une date d’évaluation, une méthodologie documentée, des constatations attribuables et une source admissible. Les dossiers qui ne précisent pas ces éléments restent exclus du nombre d’évaluations indépendantes examinées.

Le graphique de lancement indique directement le nombre issu du registre des évaluations de modèles. Zéro signifie qu’aucun dossier lié n’a achevé la vérification ; cela ne signifie pas qu’il n’existe aucune recherche externe.

Incidents, réponse et exécution

Les dossiers d’incidents conservent la date de l’événement, sa gravité, son statut, le résumé de son impact, la réponse apportée et la source principale. Les mesures d’exécution restent attribuées à l’autorité compétente et sont reliées à la chronologie. Ces dossiers peuvent éclairer une évaluation ultérieure, mais la plateforme ne déduit ni causalité technique ni risque à l’échelle du modèle au-delà des preuves officielles.

Graphiques et données

Méthodologie

Les preuves admissibles comprennent les cadres officiels et dossiers d’exécution de niveau 1, les évaluations universitaires de niveau 2 assorties de méthodes attribuables, ainsi que les fiches de modèles, fiches système et rapports de sécurité de niveau 3 rédigés par les développeurs. Les médias peuvent faciliter la découverte, mais ne constituent jamais une preuve principale.

Les déclarations des développeurs sont identifiées par leur éditeur et leur type de source, et restent rattachées au modèle ou à l’entreprise comme informations de première partie. Les évaluations indépendantes sont enregistrées dans le registre des évaluations de modèles avec l’évaluateur, la date, la méthodologie, les résultats, les constatations et les sources. Les deux catégories de preuves sont présentées séparément et ne sont jamais fusionnées en une note de sécurité non étayée.

Références

1. Cadre de gestion des risques liés à l’intelligence artificielle (AI RMF 1.0)Institut national des normes et de la technologie · Niveau 1 · 26 janv. 2023
2. ISO/IEC 42001:2023 — Système de management de l’intelligence artificielleOrganisation internationale de normalisation · Niveau 1 · 1 déc. 2023
3. Principes de l’OCDE sur l’intelligence artificielleOrganisation de coopération et de développement économiques · Niveau 1 · 3 mai 2024
4. Recommandation sur l’éthique de l’intelligence artificielleUNESCO · Niveau 1 · 23 nov. 2021
5. La NHTSA annonce une ordonnance par consentement avec Cruise après la communication incomplète d’un accident impliquant un piétonAdministration nationale de la sécurité routière · Niveau 1 · 30 sept. 2024
6. Fiche système de GPT-5.6OpenAI · Niveau 3 · 9 juil. 2026
7. Fiches système des modèles AnthropicAnthropic · Niveau 3 · 1 juin 2026
8. Fiche du modèle Gemini 3.5 FlashGoogle DeepMind · Niveau 3 · 19 mai 2026
9. Documentation du modèle LlamaMeta · Niveau 3 · 9 août 2026
10. Fiche du modèle NVIDIA Nemotron 3.5 NanoNVIDIA · Niveau 3 · 15 déc. 2025