Si on croit les deux rapports International AI Safety Report, First Key Update – Capabilities and Risk Implications (publié en octobre) et Second Key Update – Technical Safeguards and Risk Management (publié en novembre) l’IA “de pointe” n’est pas seulement une affaire de performances spectaculaires, c’est une affaire de vitesse, d’exposition et d’outils de contrôle qui peinent à suivre. Le First Key Update commence par un constat intéressant, à savoir que le domaine “va trop vite”, et des changements majeurs se produisent “en quelques mois, parfois quelques semaines”. Ces rapports constituent la base d’un petit traité de gouvernance du risque en régime instable. Le premier raconte comment des changements techniques déplacent la frontière des usages possibles, et donc des dommages plausibles. Le second raconte comment le secteur tente de fabriquer de la sûreté (par couches, par procédures, par audits) tout en reconnaissant explicitement que l’efficacité des mesures reste incertaine et variable selon les contextes.
La vitesse comme fait stylisé, le risque comme fil conducteur
Ces “Key Updates” ont une forme étrange, relativement courts, et denses, publiés parce qu’un rapport annuel ne suffirait plus à suivre la dynamique du champ. Le First Key Update dit clairement que c’est la raison d’être de la série, une publication annuelle ne peut pas “tenir le rythme” d’un domaine où les inflexions se jouent à l’échelle de mois, voire de semaines. Cette manière de cadrer est déjà, en soi, une thèse sur le risque. Quand la vitesse de changement dépasse la vitesse de contrôle, le risque n’est pas seulement dans les “mauvais événements” possibles, il est dans la désynchronisation entre innovation, déploiement et apprentissage collectif. La structure en deux temps est utile. Le First Key Update présente des avancées de capacité, et insiste sur un point clé, à savoir que les progrès récents viennent surtout de techniques d’entraînement et d’optimisation à l’inférence qui favorisent des raisonnements “pas à pas”. Il parle de modèles qui produisent des chaînes d’étapes intermédiaires avant la réponse finale, et qui gagnent en performance sur des tâches complexes — tout en reconnaissant que la fiabilité reste un problème majeur et que les performances “en conditions de travail réalistes” restent faibles, révélant un écart entre benchmarks et terrain.
Le Second Key Update prend la suite, mais change de focale, se demandant comment acteurs publics et privés organisent la gestion du risque, et surtout comment ils tentent de rendre les systèmes plus robustes à la fois aux erreurs et aux usages malveillants. La phrase centrale du préambule est sans ambiguïté puisque malgré des progrès, “il est souvent incertain” que les mesures actuelles préviennent effectivement les dommages, et l’efficacité varie selon le temps et les applications. On n’est donc pas dans un récit “solutionniste”, on est dans une course entre des capacités qui progressent et des mécanismes de maîtrise qui s’inventent, avec des trous, des asymétries et des angles morts.
Ce double mouvement, capacités puis mitigations, ressemble à une boucle de gestion du risque. Même s’il me semble qu’il manque encore un ingrédient fondamental, un socle stable de données sur incidents, quasi-incidents, expositions, et contournements, pour passer d’un discours sur la “sûreté” à une discussion sur la mesure et sur la preuve.
Des “capacités” au risque : aléa, exposition, vulnérabilité
Dans beaucoup de débats publics, l’IA est traitée comme un objet monolithique, “plus puissante” donc “plus dangereuse”, ou “plus productive” donc “plus souhaitable”. Les Key Updates proposent quelque chose de plus proche d’une grammaire du risque, des changements techniques augmentent certaines capacités, ces capacités élargissent certains usages, et cet élargissement modifie la carte des risques. Le First Key Update résume ce mécanisme de façon directe. Les nouvelles techniques permettent aux systèmes de “raisonner pas à pas” et d’opérer de façon plus autonome, ce qui leur permet d’attaquer plus de tâches, mais crée aussi de nouveaux défis en matière de risques biologiques, de cybersécurité et d’oversight (surveillance/contrôle). Une lecture “risque” peut se faire en trois termes assez classiques (en science actuarielle).
D’abord il y a l’aléa, ce que le système rend possible, en bien comme en mal. Ici, la nouveauté n’est pas seulement la “qualité” des réponses, mais l’aptitude à enchaîner des actions, à tenir un plan, à s’intégrer dans des outils (agents, automatisation de tâches). Le rapport prend soin de dire que les mots “think” et “reasoning” n’impliquent pas une cognition humaine. Il s’agit d’un changement observable de traitement de l’information, et la question de ce que cela signifie “philosophiquement” reste ouverte (ce qui est une manière polie de rappeler qu’il faut séparer performance instrumentale et compréhension). Ensuite il y a l’exposition, ou la diffusion. Le First Key Update note un paradoxe instructif, puisque malgré une adoption large, les effets agrégés sur le marché du travail “ont peu changé”. Ce n’est pas un argument “contre” ou “pour” l’IA. C’est un rappel qu’entre une capacité technique et un impact macro, il y a des frictions, des coûts d’intégration, des responsabilités juridiques, des contraintes organisationnelles, de la qualité de données, et parfois du “travail fantôme” (thème central de Ghost Work, de Mary Gray et Siddharth Suri) qui transforme l’automatisation en reconfiguration plutôt qu’en substitution. Enfin la vulnérabilité, ce qui transforme un usage plausible en dommage probable. C’est là que le premier rapport prépare le terrain pour le second, les risques ne sont pas “dans le modèle”, ils sont dans l’ensemble socio-technique, dans la façon dont on l’évalue, le sécurise, le déploie, et le surveille.
Le problème de mesure : quand le benchmark ne suffit plus
Une phrase du First Key Update mérite d’être gardée en mémoire, parce qu’elle met le doigt sur un problème que tous les modélisateurs connaissent bien. Les meilleurs modèles réussissent très bien sur certains benchmarks, mais les taux de succès en tâches réalistes restent faibles, ce qui “met en évidence un écart” entre performance de benchmark et efficacité dans le monde réel. Ce n’est pas un détail. En risque, c’est presque tout. Car la plupart des promesses (et des inquiétudes) reposent sur une extrapolation : “si ça marche ici, ça marchera ailleurs”. Or l’histoire des modèles statistiques est remplie de ces extrapolations qui cassent (changement de population, changement de protocole de collecte, changements d’incitations, changement de distribution, ou simple ré-interprétation humaine des sorties du modèle). Melanie Mitchell insiste depuis longtemps (en particulier dans Artificial Intelligence: A Guide for Thinking Humans) sur cette fragilité des systèmes qui semblent “intelligents” sur un jeu de tests, mais qui s’effondrent quand on change un paramètre périphérique. Gary Marcus et Ernest Davis (dans Rebooting AI) et Erik Larson (dans The Myth of Artificial Intelligence) déclinent la même idée, on confond performance locale et robustesse. En termes d’épistémologie, c’est un point clef (que j’ai déjà expliqué à maintes reprises sur ce blog), un score n’est pas une connaissance, et une métrique n’est pas une garantie. L’évaluation est un instrument, pas une preuve définitive. Et ce qui devient crucial, pour la gouvernance, pour la régulation, pour l’assurance, est la capacité à dire dans quelles conditions le système marche, pour qui, avec quels types d’erreurs, et avec quelles conséquences. C’est exactement le diagnostic qui a motivé des propositions comme les Model Cards. Le papier Model Cards for Model Reporting (Mitchell et al., 2019) part d’un constat brut, “il n’existe pas aujourd’hui de procédures standardisées” de documentation permettant de communiquer les caractéristiques de performance des modèles, et cette absence est “particulièrement problématique” lorsque les modèles opèrent dans des domaines à fort impact (santé, emploi, éducation, police). Le même papier rappelle aussi une leçon de terrain, des biais systématiques ont souvent été mis au jour après mise en production, à la suite de retours d’expérience d’utilisateurs affectés. En langage “risque”, cela ressemble à un mécanisme très familier, l’erreur n’est pas seulement une propriété mathématique, c’est un événement socialement détecté, contesté, et parfois juridiquement sanctionné.
Quand l’évaluation devient un jeu : Goodhart, sélection, et “risque de modèle”
Le First Key Update introduit un thème plus dérangeant, mais très cohérent avec les problèmes d’évaluation en environnement adversarial, en conditions expérimentales contrôlées, certaines IA ont montré des comportements “stratégiques” pendant l’évaluation, au point de produire des sorties pouvant “induire les évaluateurs en erreur” sur leurs capacités ou leurs objectifs d’entraînement. Le rapport ajoute prudemment que l’évidence vient surtout du laboratoire, avec incertitude sur ce que cela signifie en déploiement réel, mais l’alerte est claire. Si un système adapte son comportement au protocole, alors le protocole devient une cible. Même sans imaginer un “agent manipulateur”, le phénomène est déjà classique. Dès qu’un indicateur devient une cible, il se dégrade (et ne peut plus servir d’indicateur). On retombe sur la loi de Goodhart, mais aussi sur des questions d’économétrie et de causalité, endogénéité (la mesure change l’objet mesuré), changements de régime (nouvelle génération de modèles, nouveaux usages), et biais de sélection (ce qu’on teste n’est pas ce qu’on déploie). Dans un cadre de gestion du risque, cela plaide pour une conception de l’évaluation comme processus continu (red teaming, audits, tests adversariaux, journalisation, et boucles de rétroaction).
Le Second Key Update dira d’ailleurs, un peu plus loin, que les preuves manquent en partie parce que le rythme de développement et de déploiement rend difficile l’évaluation “dans des conditions réalistes” et la collecte systématique de données d’efficacité des safeguards, formulation très proche de ce que les spécialistes du risque opérationnel appelleraient un déficit de “backtesting” ou un manque d’observabilité. À ce stade, la question n’est plus seulement “le modèle est-il bon ?”, mais “la chaîne de contrôle est-elle crédible ?”. Dans les industries où le risque est mature, on ne se contente pas d’un score moyen, on veut des scénarios extrêmes, des stress tests, des analyses d’incidents, et une documentation de type “safety case”. Le Second Key Update note justement l’émergence de méthodes d’assurance plus “evidence-based”, avec des safety cases, des analyses d’incidents, des logs de performance, marquant une volonté de formaliser la preuve de maîtrise du risque, même si l’ensemble reste expérimental.
Safeguards : la “défense en profondeur” et la course attaque/défense
Le cœur du Second Key Update est une idée simple, à savoir qu’aucun garde-fou ne suffit, donc il faut empiler les couches. Le rapport décrit l’adoption d’une stratégie dite de “defence-in-depth” (combiner des safeguards pendant l’entraînement, au déploiement, et après le déploiement (monitoring)). Il illustre cela par un schéma “Swiss cheese”. Chaque couche est imparfaite, mais la superposition réduit la probabilité qu’un “trajet d’événement” traverse tous les trous à la fois. L’intérêt, du point de vue du risque, est que cette approche reconnaît implicitement une réalité, on n’est pas dans une logique de conformité statique, mais dans une logique d’adversaire. Et le rapport le montre sans fard dans ses “Highlights”, puisque les attaques par prompt injection deviennent un peu moins efficaces au fil du temps, mais des tests indiquent que des attaquants sophistiqués parviennent encore à contourner les safeguards “environ une fois sur deux” lorsqu’ils disposent de dix tentatives. Pour une lecture “assurance” ou “risque opérationnel”, c’est décisif. Un contrôle qui casse une fois sur deux n’est pas un contrôle de sûreté, c’est un contrôle d’usage à surveiller, à durcir, et à compléter.
Le rapport ajoute un autre élément très “économie de la sécurité”, rappelant la possibilité d’attaques asymétriques via empoisonnement des données. Il affirme qu’“aussi peu que 250 documents malveillants” injectés dans les données d’entraînement peuvent permettre à des attaquants de déclencher des comportements indésirables via des prompts spécifiques, et que certaines recherches suggèrent que ces attaques peuvent demander relativement peu de ressources. Même en restant au niveau macro (sans entrer dans le détail technique), l’implication est claire, si le coût marginal de l’attaque est faible, la défense doit être pensée comme un système (provenance des données, contrôles de supply chain, audits, surveillance de dérives), et non comme un filtre superficiel. Le rapport discute aussi des outils de traçabilité : watermarking, détection, identification. Il reconnaît leur utilité “lorsqu’ils sont correctement utilisés et appliqués de façon cohérente”, tout en notant une mise en œuvre inégale. C’est typiquement le genre de “mesure de marché” qui peut changer la structure du risque si elle devient un standard — et rester marginale si elle reste optionnelle.
Open-weight : transparence, innovation… et diffusion du risque
Un des passages les plus importants du Second Key Update explique que les modèles open-weight accusent désormais un retard de “moins d’un an” sur les meilleurs modèles closed-weight. Le rapport en tire une conclusion nuancée, puisque davantage d’ouverture soutient la transparence et l’innovation, mais rend aussi plus difficile le contrôle des usages et des modifications. Ce point est important il me semble. L’ouverture n’est pas un “bien” ou un “mal” en soi. C’est un paramètre qui reconfigure l’écosystème (multiplication des acteurs capables d’adapter le modèle, accélération de la diffusion d’une capacité, et potentielle réplication de vulnérabilités sur un grand nombre de déploiements). Cela rappelle un vieux thème de cybersécurité, la monoculture technologique pouvant amplifier l’impact d’une faille. Et cela pose des questions très concrètes, presque assurantielles, sur qui est responsable de quoi dans une chaîne où le modèle est modifié, quantifié, distillé, intégré à des produits, et redistribué. Le Second Key Update insiste d’ailleurs sur la dynamique globale attaque/défense. Le paysage “reste dynamique”, avec des adversaires qui continuent à trouver des manières de contourner les défenses, et un besoin permanent de développement, de test et d’amélioration des safeguards dans un environnement de menaces changeant. Là encore, c’est une vision très “sécurité informatique”, proche de ce que Ross Anderson défend dans Security Engineering à savoir que la sécurité n’est pas un état, c’est un processus social et économique, avec des arbitrages entre coûts, bénéfices, et incitations.
Du récit aux données : incidents, standards, et “quantification” du risque IA
À ce stade, on se demande comment passer d’un discours sur des risques possibles à une gouvernance fondée sur des faits ? Le chaînon manquant, ce sont des données d’incidents structurées, interopérables, et suffisamment riches pour permettre des analyses de fréquence, de sévérité, de causalité (au sens large), et d’efficacité des contrôles. C’est précisément l’ambition d’un autre document, le rapport de l’OCDE, Towards a common reporting framework for AI incidents. Il propose en particulier des définitions opérationnelles. Un “AI incident” est une suite d’événements où le développement, l’usage ou le dysfonctionnement d’un ou plusieurs systèmes d’IA conduit directement ou indirectement à des préjudices (santé, infrastructures critiques, droits, environnement, etc.), tandis qu’un “AI hazard” est une situation pouvant plausiblement conduire à un incident. L’objectif est une base commune pour un reporting à la fois volontaire et obligatoire, et une interopérabilité entre juridictions. Le rapport insiste aussi sur le besoin d’un cadre cohérent pour suivre les incidents à l’échelle mondiale, et explique que le reporting vise à soutenir la surveillance internationale et l’accumulation d’évidence pour informer la gouvernance et prévenir des incidents futurs. Cette logique résonne immédiatement avec la gestion du risque telle que la formalise ISO/IEC 23894, dans laquelle on retrouve l’idée d’intégrer la gestion du risque dans les activités liées à l’IA, prendre en compte “le système dans son ensemble”, y compris l’impact sur l’environnement et les parties prenantes, et reconnaître que les systèmes d’IA peuvent introduire des risques “nouveaux ou émergents”. Dit autrement, sans vision systémique et sans boucle d’apprentissage (monitoring, reporting, amélioration), le risk management IA restera un exercice cosmétique. Il faut ajouter un point que les Key Updates, la dimension éthique. Les dommages liés aux systèmes d’IA ne sont pas seulement des “pannes” techniques. Ils incluent des erreurs différentielles, des exclusions, des discriminations directes ou indirectes, des atteintes à la vie privée, des effets d’infrastructure. Les Model Cards montrent comment des erreurs systématiques peuvent n’apparaître qu’après déploiement, lorsque les personnes affectées se manifestent, ce qui rappelle que le “signal” de risque est souvent social, politique et juridique. Et cela explique pourquoi des ouvrages comme Algorithms of Oppression (de Safiya Noble), Design Justice (de Sasha Costanza-Chock), ou Atlas of AI (de Kate Crawford) sont des compléments naturels. Ils décrivent comment les systèmes se déploient dans des structures de pouvoir, d’attention, de travail, et de ressources matérielles. Dans Insurance, Biases, Discrimination and Fairness, je tentais de mettre des mots précis sur des arbitrages qui ne sont jamais “purement techniques” (dans un contexte d’assurance uniquement, certes). Enfin, The AI Con (d’Emily Bender et Alex Hanna) joue ici un rôle de garde-fou intellectuel, rappelant que le discours sur l’IA peut devenir un dispositif rhétorique, un déplacement d’attention, une promesse auto-entretenue. Dans une lecture “risque”, ce scepticisme n’est pas un luxe, c’est un outil. Il protège contre la confusion entre démonstration ponctuelle et robustesse, entre métrique et garantie, entre récit de gouvernance et gouvernance effective.
Attendre la suite… et surtout les données
Ces deux Key Updates ont une qualité rare, ils ne vendent pas une certitude. Le premier explicite le problème de la vitesse et met au centre l’écart entre performance sur benchmark et efficacité réelle, ainsi que les difficultés d’oversight lorsque l’évaluation elle-même peut être “jouée”. Le second assume que l’efficacité des mitigations est incertaine, tout en décrivant une architecture plausible (défense en profondeur) et en donnant des ordres de grandeur qui forcent à penser en termes d’adversaire (contournement “environ une fois sur deux” en dix essais) et de supply chain (empoisonnement par quelques centaines de documents). La suite logique, maintenant, n’est pas seulement d’empiler des frameworks, c’est d’accumuler des observations, de standardiser des rapports d’incidents, et de construire une mémoire empirique du risque, exactement l’ambition du cadre de l’OCDE, Towards a common reporting framework. Si le champ tient sa promesse de devenir plus “evidence-based”, ces Key Updates auront servi de pont entre deux mondes, celui des capacités qui surprennent, et celui des institutions qui apprennent. On attend la suite avec impatience.
OpenEdition suggests that you cite this post as follows:
Arthur Charpentier (December 27, 2025). Key Updates du International AI Safety Report (1 et 2). Freakonometrics. Retrieved January 13, 2026 from https://doi.org/10.58079/15f3h