Geoffrey Hinton demande que les modèles d’intelligence artificielle soient évalués avant leur mise à disposition, sous le regard d’une autorité indépendante. Reprise dans la presse libanaise du 10 novembre, son intervention pose une question concrète : qui décide qu’un modèle peut être diffusé, sur quelles preuves et avec quelle surveillance ensuite ? Les contrôles de l’IA existent déjà sous plusieurs formes, sans constituer le système international qu’il appelle de ses vœux.
Le chercheur exprime cette position dans un entretien à la presse britannique paru le 3 novembre. Il critique la course commerciale entre grandes entreprises technologiques et redoute des incidents touchant des infrastructures essentielles. Il conserve néanmoins l’espoir de bénéfices importants. Son propos défend un encadrement du développement, plutôt qu’un renoncement général à la technologie.
Dans le compte rendu publié au Liban, Hinton propose une autorité internationale inspirée du contrôle des médicaments. Les entreprises devraient lui présenter des éléments permettant de comparer les bénéfices attendus et les dommages possibles avant la commercialisation. Il s’agit d’une proposition du chercheur, pas de l’annonce d’une institution déjà créée.
Contrôles de l’IA : que faut-il tester avant l’accès ?
Une démonstration réussie renseigne sur ce qu’un modèle sait accomplir dans une situation donnée. Une évaluation de sécurité cherche aussi ses échecs, les usages détournés et les conditions dans lesquelles ses protections cessent de fonctionner. Ces objectifs demandent des essais différents.
Le cadre de gestion des risques du National Institute of Standards and Technology américain, l’AI RMF 1.0, prévoit des tests avant le déploiement, puis régulièrement pendant l’utilisation. Il organise le travail autour de la gouvernance, de l’identification des risques, de leur mesure et de leur gestion. Ce cadre constitue un outil de gestion, pas une autorisation internationale de mise sur le marché.
Sa logique oblige à préciser le contexte. Une erreur dans un brouillon de texte et une action erronée dans un système opérationnel n’ont pas les mêmes conséquences. La question dépasse donc le score obtenu par un modèle sur un exercice : elle porte aussi sur les personnes exposées, les outils accessibles et les décisions que le système peut prendre.
Concrètement, un test utile doit permettre de savoir quelle version a été examinée et dans quelles conditions. Un modèle limité à la production de texte ne dispose pas des mêmes possibilités qu’un agent relié à des logiciels. Le périmètre des accès fait ainsi partie du problème posé par Hinton.
Des attaques simulées pour chercher les défaillances
Le règlement européen sur l’intelligence artificielle prévoit une série d’obligations pour les fournisseurs de modèles à usage général présentant un risque systémique. Son article 55 demande des évaluations utilisant des protocoles et outils correspondant à l’état de l’art. Il mentionne explicitement les essais adversariaux, qui cherchent à mettre le modèle en défaut.
Le texte impose également d’évaluer et de réduire les risques systémiques, de documenter les incidents graves et de les signaler sans retard injustifié. La cybersécurité doit couvrir le modèle et son infrastructure physique. Ces exigences concernent une catégorie déterminée de modèles : elles ne signifient pas que toute application bénéficie d’un certificat de sécurité identique.
L’approche européenne donne ainsi une traduction concrète à plusieurs sujets du débat. Le fournisseur doit produire des éléments sur les risques et sur les mesures correctrices. L’évaluation n’est pas seulement une appréciation publique du caractère impressionnant d’un système.
Le code de bonnes pratiques européen complète ce dispositif. Publié en juillet 2025, il est présenté par la Commission comme une voie volontaire pour démontrer le respect des obligations légales. Ses chapitres couvrent la transparence, le droit d’auteur, ainsi que la sûreté et la sécurité. Ce dernier volet vise les modèles concernés par les obligations relatives au risque systémique.
L’indépendance ne se résume pas au nom du contrôleur
La proposition de Hinton place une autorité distincte des fabricants au centre de la décision. Son intérêt tient au conflit possible entre la vitesse de commercialisation et le temps nécessaire aux essais. Une entreprise peut connaître son modèle mieux que quiconque tout en ayant un intérêt économique à le diffuser rapidement.
Pour qu’un contrôle extérieur apporte une information supplémentaire, plusieurs questions doivent être résolues : à quelle version accèdent les évaluateurs ? Quels résultats peuvent-ils examiner ? Peuvent-ils reproduire les tests ? Qui décide de la suite lorsqu’une défaillance importante apparaît ? Ces questions décrivent les conditions pratiques d’un examen, sans présumer de la réponse pour une entreprise particulière.
Une comparaison avec les médicaments rencontre aussi une limite évidente. Un modèle général peut servir à des tâches très différentes et recevoir de nouveaux outils après sa diffusion. Son dossier d’évaluation doit donc préciser les usages et les conditions examinés. Une appréciation favorable dans un périmètre donné ne répond pas à tous les usages possibles.
Les critiques personnelles formulées par Hinton envers certains dirigeants relèvent de son jugement. Elles ne remplacent pas les résultats d’essais, ni la preuve d’une faute particulière. Le débat sur la responsabilité gagne en précision lorsqu’il porte sur les décisions, les accès et les incidents documentés.
Après le lancement, conserver la capacité d’agir
Le guide pratique du NIST demande de suivre les risques et les bénéfices pendant toute la vie du système. Il prévoit d’examiner si le déploiement doit se poursuivre et d’adapter les réponses aux risques observés. Les contrôles peuvent notamment concerner les accès, les limites d’utilisation, la documentation et l’organisation du travail humain autour du système.
Cette continuité répond à une difficulté concrète : les usages réels peuvent révéler des problèmes absents des essais initiaux. Une mise à jour, un changement d’intégration ou une nouvelle population d’utilisateurs modifie le contexte. Le suivi doit pouvoir relier un incident à la version utilisée et aux conditions de son fonctionnement.
La responsabilité opérationnelle commence alors par des décisions identifiables. Qui peut limiter une fonction ? Qui reçoit les alertes ? Qui vérifie l’efficacité d’une correction ? Un rapport d’évaluation perd une partie de son utilité si personne n’est chargé d’agir sur ses résultats.
Hinton évoque des perturbations possibles des réseaux électriques, des services bancaires ou des systèmes de santé. Ces scénarios expriment son inquiétude ; ils ne constituent pas l’annonce de nouvelles attaques établies contre ces infrastructures. Son appel déplace néanmoins le débat vers une exigence vérifiable : documenter les capacités et les risques avant l’ouverture, puis conserver les moyens de corriger, de restreindre ou d’arrêter un usage problématique.
Commentaires