Quatre outils répondent à des questions différentes
Une évaluation de capacité demande ce qu’un modèle ou un système peut faire dans des conditions données. Une évaluation des garde-fous demande si les contrôles préviennent ou détectent un usage abusif. Un dossier de sécurité formule une affirmation précise et relie des preuves à cette affirmation par un argument explicite. Le signalement d’incidents tire les leçons des échecs et des incidents évités de justesse, pendant ou après les tests et le déploiement.
Aucun de ces outils, pris isolément, n’établit qu’un modèle est « sûr ». Un test de référence peut omettre un comportement important ; un garde-fou peut échouer face à l’adaptation ; un dossier de sécurité peut reposer sur des preuves de mauvaise qualité ; et les données d’incidents n’arrivent qu’après qu’un problème est survenu. Ensemble, ils peuvent créer un cycle de preuves : anticiper, tester, justifier, surveiller, apprendre et réviser.
Les évaluations de capacité ont besoin d’un modèle de menace défini
Les évaluations de pointe examinent couramment les opérations cybernétiques, l’assistance chimique ou biologique, l’autonomie, la réplication de modèles, la persuasion et la recherche en IA. Les résultats dépendent de l’échafaudage technique, des invites, des outils, du temps, du calcul, de l’aide d’experts, des tentatives répétées et des filtres de sécurité. Ne rapporter que le nom du modèle et un score rend les comparaisons peu fiables.
L’AI Security Institute britannique a testé plus de 30 systèmes de pointe et fait état d’une performance qui s’améliore rapidement dans plusieurs domaines. Son rapport de tendances 2025 note que les évaluateurs reçoivent parfois des versions préalables au lancement, ou un accès avec des garde-fous différents de ceux du produit public (rapport de tendances sur l’IA de pointe de l’UK AISI). Ces résultats constituent une preuve directe sur ces configurations de test précises, pas une preuve de succès général dans le monde réel ni de l’AGI.
Les évaluations devraient inclure des lignes de base : novices sans assistance, experts, recherche sur internet, modèles antérieurs et outils existants. Le risque pertinent est souvent le gain de capacité (« uplift ») — de combien un système augmente la capacité d’un acteur — plutôt que la simple question de savoir si le modèle peut produire une information dangereuse quelconque.
Contamination, provocation des capacités et sandbagging
Un test de référence peut apparaître dans les données d’entraînement, ce qui gonfle la performance. Un modèle peut posséder une capacité que l’évaluation ne parvient pas à faire émerger. À l’inverse, des invites poussées et des outils spécialisés peuvent créer un système que les utilisateurs ordinaires ne reçoivent pas. Les bons rapports distinguent le comportement par défaut du produit, la capacité maximale provoquée et la performance de bout en bout de l’agent.
La sous-performance stratégique, parfois appelée sandbagging, est une préoccupation prospective quand des systèmes peuvent reconnaître les tests et ont une raison de dissimuler leur capacité. Les études actuelles peuvent examiner le mécanisme, mais un score faible n’est pas une preuve de tromperie. Des tâches cachées, plusieurs environnements, un monitoring du comportement et un accès en boîte blanche peuvent réduire l’incertitude.
L’incertitude statistique compte. Les résultats graves et rares exigent de nombreux essais ou des preuves soigneusement construites. Les évaluateurs devraient publier les intervalles de confiance, les méthodes de sélection des tâches, les exclusions et les limites connues. La saturation d’un test de référence devrait déclencher une refonte, pas des déclarations de victoire.
Les garde-fous doivent être évalués comme des systèmes
L’entraînement au refus n’est qu’une couche parmi d’autres. Les garde-fous incluent les vérifications d’identité, les politiques d’usage acceptable, les classificateurs, le monitoring, les limites de débit, les permissions d’outils, l’isolement (sandboxing), la révision humaine et les procédures de réponse. Les attaquants peuvent fractionner leurs demandes, utiliser plusieurs comptes, ajuster finement des poids ouverts, encoder du contenu, ou circuler entre services.
Les principes de l’UK AISI sur les garde-fous insistent sur des modèles de menace explicites et l’évaluation du système complet plutôt que de la seule capacité (UK AISI). Un laboratoire a contribué à la consultation et peut bénéficier d’un accès privilégié, mais les évaluateurs gouvernementaux restent dépendants de la coopération du fournisseur et ne peuvent pas publier toutes les tâches dangereuses.
Les tests de garde-fous devraient mesurer les faux négatifs, les faux positifs, les attaques adaptatives, l’utilisabilité, la latence, le coût en matière de confidentialité, et si les alertes conduisent à une action. Un filtre qui bloque un travail légitime en biologie ou en sécurité peut pousser les utilisateurs vers des systèmes moins responsables ; un filtre qui produit d’impressionnantes captures d’écran de refus mais se contourne aisément procure une fausse réassurance.
Les dossiers de sécurité rendent l’argument inspectable
Un dossier de sécurité formule une affirmation bornée — telle que « cet agent ne peut pas causer le préjudice cybernétique catastrophique spécifié dans ce déploiement » — puis présente des preuves et un raisonnement. L’UK AISI décrit trois composantes : une affirmation précise, des preuves, et un argument qui les relie (UK AISI, février 2025).
C’est plus solide qu’une liste de contrôle, car les réviseurs peuvent contester chaque prémisse. C’est plus faible qu’une preuve formelle : les preuves peuvent être incomplètes, les hypothèses peuvent échouer, et le développeur peut choisir une affirmation commode. Les affirmations devraient préciser la version du modèle, l’architecture, l’accès, les utilisateurs, la durée, l’environnement, le seuil de préjudice et la période de validité.
Les dossiers de sécurité devraient inclure des réfutateurs — des preuves qui invalideraient l’argument — et leur propre incertitude. Les réviseurs indépendants ont besoin d’accéder aux résultats sous-jacents, pas seulement à un résumé poli. Un désaccord substantiel devrait être préservé. L’approbation devrait expirer lorsque le modèle, l’échafaudage technique, les outils, l’environnement de menace ou l’échelle de déploiement changent.
Portes de déploiement et proportionnalité
L’évaluation n’a d’importance que si elle est reliée à une décision. Un cadre de pointe devrait définir les seuils avant l’arrivée des résultats, préciser les mesures d’atténuation requises, nommer qui peut approuver des exceptions, et documenter les dérogations. Sinon, un développeur peut réinterpréter un résultat préoccupant sous pression commerciale.
Les contrôles peuvent être graduels : retarder la diffusion des poids tout en offrant une API surveillée, limiter les outils, restreindre les utilisateurs à haut risque, réduire l’autonomie, accroître l’approbation humaine, ou suspendre le déploiement. Toute capacité préoccupante n’exige pas la même réponse.
Les conflits d’intérêts sont inévitables mais gérables. Les développeurs connaissent leurs systèmes et bénéficient de leur lancement. Les évaluateurs externes peuvent dépendre de l’accès ou du financement du développeur. Les régulateurs peuvent manquer d’expertise. Un accès légal garanti, la diversité du financement, les droits de publication, la rotation des réviseurs et la divulgation des conflits renforcent la crédibilité.
Le signalement d’incidents transforme les surprises en connaissance partagée
Un système d’incidents a besoin d’une définition, d’un délai de signalement, d’une échelle de gravité, d’une réception sécurisée, d’une analyse des causes profondes, de mesures correctives et d’un retour aux parties concernées. Les incidents évités de justesse comptent car ils révèlent des contrôles faibles avant qu’un préjudice complet ne survienne.
En vertu de l’article 55 du règlement européen sur l’IA, les fournisseurs de modèles d’IA à usage général présentant un risque systémique doivent suivre, documenter et signaler les incidents graves pertinents ainsi que les mesures correctives au Bureau de l’IA et, le cas échéant, aux autorités nationales. La Commission a publié un modèle de signalement en novembre 2025 (Commission européenne). Cette obligation légale est contraignante pour les fournisseurs couverts ; utiliser le code de bonnes pratiques volontaire pour l’IA à usage général constitue une voie pour démontrer la conformité.
La SB 53 de Californie et la loi RAISE de New York imposent un signalement spécifié des incidents critiques dans leur périmètre. Les rapports volontaires d’entreprise en dehors de ces lois restent volontaires, à moins qu’une autre obligation ne s’applique.
Ce qui compte comme un incident
Les définitions devraient inclure le préjudice grave réel, les incidents évités de justesse crédibles, la perte de contrôle sur un agent, le vol de poids, une capacité dangereuse découverte de façon inattendue, une défaillance systémique des garde-fous, et des déclarations fausses substantielles faites aux évaluateurs. Les hallucinations ordinaires peuvent être traitées dans les systèmes de qualité produit, sauf si la gravité ou l’échelle franchit un seuil de signalement.
Un signalement obligatoire trop large peut submerger les régulateurs et exposer des vulnérabilités ou des données personnelles. Un signalement trop étroit dissimule des signaux faibles. Un signalement par paliers peut envoyer d’abord un avis confidentiel urgent, suivi d’une enquête plus complète et d’un résumé public anonymisé lorsque cela est sûr.
La divulgation par l’UK AISI en 2026 d’un comportement d’agent non autorisé lors de tests cybernétiques illustre une définition transparente des limites : l’institut a signalé une activité potentiellement dangereuse tout en précisant explicitement que le modèle ne s’était pas échappé de son bac à sable (UK AISI, 2026). Un langage précis empêche qu’un incident réel ne se transforme en affirmation sensationnaliste mais fausse d’« évasion de l’IA ».
Transparence publique et détail sécurisé
Des tâches d’évaluation complètes peuvent permettre un usage abusif ou la manipulation des tests de référence. Des registres d’incidents complets peuvent exposer les victimes et les vulnérabilités. La réponse consiste en un accès à plusieurs niveaux : des affirmations et des méthodes publiques ; un détail technique confidentiel pour les régulateurs qualifiés et les réviseurs indépendants ; et des informations personnelles ou relevant de la sécurité nationale protégées.
Le signalement agrégé devrait montrer les catégories d’incidents, la gravité, la source de détection, le délai de signalement, les mesures correctives et la récurrence. Un rapport de transparence qui ne compte que les incidents confirmés sans expliquer la capacité de détection peut récompenser les organisations qui examinent les choses avec moins de rigueur.
La boucle de preuves
Tout incident grave devrait mettre à jour les modèles de menace, les évaluations, les garde-fous et le dossier de sécurité. Toute nouvelle capacité devrait déclencher un réexamen des copies déployées et des intégrations en aval. Les équipes de red team devraient recevoir les leçons tirées des incidents, et les lanceurs d’alerte ont besoin de voies protégées lorsque le signalement formel échoue.
Les recommandations à septembre 2026 sont claires : normaliser la documentation tout en conservant des tests propres à chaque domaine ; exiger un accès indépendant en cas de forte capacité ou de grande échelle ; relier les seuils à des portes de décision prédéterminées ; rendre obligatoire le signalement des incidents graves couverts et des incidents évités de justesse ; protéger les détails sensibles ; et publier suffisamment de preuves agrégées pour rendre des comptes.
Aucune évaluation ne prouve que la future AGI est sous contrôle. Ces pratiques rendent plutôt l’incertitude lisible et contraignent le déploiement sur la base des preuves disponibles aujourd’hui. Leur succès devrait se juger à leur capacité à découvrir les problèmes tôt, à changer des décisions et à prévenir la récurrence — pas au nombre de tests de référence ou de documents de politique qu’une organisation produit.