IA hors de contrôle : les labos sans plan public clair

Des politiques de sûreté, mais un angle mort sur le confinement

Les grands laboratoires d’intelligence artificielle disposent désormais de vocabulaires bien installés pour parler de sûreté : évaluations de capacités, niveaux de risque, red teaming, seuils de déploiement, mécanismes de gouvernance, surveillance humaine ou restrictions d’accès. Ces notions figurent dans les documents publics d’OpenAI, d’Anthropic, de Google DeepMind et d’autres acteurs engagés dans la course aux modèles de frontière. Elles répondent à une pression croissante des chercheurs, des pouvoirs publics et des utilisateurs professionnels : à mesure que les modèles acquièrent davantage de capacités, il faut pouvoir démontrer qu’ils ne seront pas déployés sans garde-fous proportionnés.

Mais un sujet beaucoup plus concret demeure largement opaque : que ferait réellement un laboratoire si un modèle avancé se comportait de manière imprévue, contournait des contrôles, utilisait des outils auxquels il a accès ou manifestait des capacités dangereuses après sa mise en service ? C’est le fossé mis en lumière par une nouvelle étude relayée par TechCrunch AI dans un article intitulé “Frontier AI labs still won’t say how they’d contain a rogue model”. Selon les éléments présentés par le média, les laboratoires de frontière ont publié des politiques de sécurité, mais ne détaillent pas publiquement les procédures opérationnelles permettant de contenir un modèle devenu incontrôlable.

Le point mérite d’être précisément formulé. L’étude ne démontre pas que les entreprises concernées seraient dépourvues de moyens internes. Elle met plutôt en évidence une limite de la documentation accessible au public : les promesses, principes et cadres d’évaluation sont plus visibles que les plans de réponse à un incident extrême. Or cette différence est essentielle. Une politique peut fixer des ambitions et désigner des responsabilités ; un plan de confinement doit décrire, ou au moins rendre auditable, la chaîne concrète d’actions qui permet de détecter un problème, de limiter les accès du système, d’interrompre son activité, de préserver les preuves et de prévenir les autorités ou les clients concernés.

Le terme de « modèle rogue », employé dans le titre de TechCrunch, ne renvoie pas nécessairement à un scénario de science-fiction dans lequel une IA développerait une volonté propre. Dans le débat sur la sûreté, il peut couvrir plusieurs situations : un modèle qui poursuit mal un objectif assigné, un agent qui accomplit des actions non prévues via des logiciels connectés, un système qui exploite des permissions trop larges, une compromission informatique, ou encore l’apparition de capacités inattendues lors d’une utilisation à grande échelle. Le problème n’est donc pas seulement de savoir si un modèle produit une réponse inexacte ou choquante. Il s’agit de savoir comment limiter rapidement ses effets lorsqu’il agit dans un environnement numérique.

Cette distinction sépare les risques de contenu des risques d’action. Pendant plusieurs années, les controverses autour de l’IA générative ont surtout porté sur les hallucinations, les biais, les atteintes au droit d’auteur, la désinformation ou la production de contenus dangereux. Ces enjeux restent centraux. Toutefois, l’arrivée d’outils capables de naviguer sur le web, d’appeler des logiciels, d’écrire et d’exécuter du code dans certains cadres, ou d’interagir avec des données d’entreprise déplace une partie du débat. Un système auquel on donne des objectifs, des accès et une certaine autonomie ne se juge plus uniquement à la qualité de ses réponses : il se juge aussi à la maîtrise de ses permissions, de son périmètre d’action et de ses mécanismes d’arrêt.

La publication d’une politique de sûreté n’est donc pas la même chose que la démonstration d’une capacité de confinement. Les premières expliquent généralement comment une entreprise entend mesurer les risques avant et pendant le développement. Les secondes devraient répondre à des questions plus opérationnelles : qui a l’autorité pour stopper un service ? Peut-on isoler rapidement un modèle ou un environnement d’exécution ? Quels journaux permettent de comprendre ses actions ? Comment empêcher la réplication de clés d’accès ou l’utilisation de comptes connectés ? Comment coordonner la réponse avec les clients, les hébergeurs, les partenaires et les autorités ? Le travail relayé par TechCrunch considère que les réponses publiques à ce type de questions demeurent insuffisantes.

Pourquoi l’essor des agents rend la question beaucoup plus pressante

La question du confinement n’est pas nouvelle dans l’informatique. Les entreprises disposent depuis longtemps de procédures de réponse aux incidents de cybersécurité : segmentation des réseaux, révocation d’identifiants, coupure de services, restauration de sauvegardes, analyse forensique et notification des personnes ou organisations affectées. Les systèmes critiques, des infrastructures industrielles aux plateformes financières, sont également conçus autour de principes de redondance, de contrôle d’accès et d’arrêt d’urgence. Mais l’IA générative introduit une difficulté particulière : un modèle peut être intégré à de nombreux produits, utiliser des outils différents selon le client, et produire des séquences d’actions qui ne sont pas entièrement pré-écrites par ses concepteurs.

Un chatbot isolé, sans accès à des données sensibles ni capacité d’exécution, pose déjà des questions de fiabilité et de sécurité. Un agent connecté à une messagerie, à un outil de gestion de projets, à un navigateur, à une base documentaire ou à un environnement de développement constitue un cas différent. Ses conséquences potentielles dépendent alors moins du texte généré que des autorisations accordées. Un modèle très performant, placé dans un environnement strictement cloisonné, n’a pas le même profil de risque qu’un modèle moins performant disposant de droits étendus et mal contrôlés.

C’est pourquoi les débats contemporains sur les « agents » dépassent les benchmarks traditionnels. Les évaluations de modèles restent nécessaires : elles peuvent renseigner sur les performances en raisonnement, en programmation, en sciences, en manipulation d’outils ou dans d’autres domaines. Mais elles n’épuisent pas la question. Un score élevé ne dit pas, à lui seul, quelles permissions sont disponibles en production, quels contrôles bloquent une action sensible, ni combien de temps il faut à une organisation pour intervenir lorsqu’un comportement problématique est détecté.

Le rapport évoqué par TechCrunch ramène ainsi le débat à des éléments très matériels : les accès système, les capacités d’action autonome et les mécanismes d’arrêt. Cette approche a le mérite de rappeler qu’un incident ne se limite pas à l’existence d’une capacité dangereuse. Il résulte aussi d’une exposition. Pour qu’un système cause un dommage dans un contexte donné, il faut généralement une combinaison entre ses capacités, les outils accessibles, les permissions accordées, les protections techniques et la qualité de la supervision humaine.

Le concept de « kill switch », souvent invoqué dans le débat public, doit d’ailleurs être manié avec prudence. Éteindre un point d’accès public à un modèle peut être relativement simple. Mais cela ne résout pas mécaniquement toutes les dimensions d’un incident. Les mêmes capacités peuvent être proposées via plusieurs interfaces, intégrées à des produits partenaires, exécutées dans des environnements distincts ou servir des utilisateurs disposant de configurations propres. Un mécanisme d’arrêt utile doit donc être pensé avec une architecture complète : il faut savoir ce qui est arrêté, par qui, selon quelles conditions, et ce qu’il advient des données, des sessions, des clés d’accès et des tâches déjà lancées.

Les fournisseurs de modèles ont, en pratique, des architectures très différentes. Certains contrôlent directement l’essentiel de l’infrastructure qui héberge leurs modèles ; d’autres proposent des poids ouverts ou des modèles téléchargeables, dont les usages échappent ensuite largement à leur contrôle. Certains services sont distribués via des interfaces de programmation, d’autres sont intégrés à des applications de bureautique, de développement ou de recherche. Cette diversité ne permet pas de réclamer une recette identique à tous. Elle rend au contraire nécessaire une transparence adaptée au mode de diffusion réel du système.

Dans ce contexte, une description publique de procédures de confinement n’implique pas forcément de révéler les détails permettant de contourner la sécurité. Les laboratoires peuvent légitimement craindre qu’une documentation trop précise expose des éléments sensibles de leur infrastructure. Mais l’opacité complète pose un autre problème : les utilisateurs, les régulateurs, les investisseurs et les organisations dépendantes de ces services ne peuvent pas facilement évaluer la maturité de la préparation opérationnelle. Entre la divulgation de secrets de sécurité et l’absence de garanties vérifiables existe un espace de publication plus utile : rôles de décision, principes de cloisonnement, exercices de crise, catégories d’incidents, délais de notification ou validation indépendante.

Ce que les cadres publics des laboratoires disent déjà — et ce qu’ils ne permettent pas de vérifier

Les principaux développeurs de modèles avancés n’ont pas ignoré la sûreté. OpenAI a publié un Preparedness Framework, conçu pour suivre certains risques liés aux capacités de ses systèmes et pour définir des mesures de protection avant leur déploiement. Anthropic a rendu publique une Responsible Scaling Policy, qui articule l’augmentation des capacités de ses modèles avec des normes de sécurité et des engagements de gouvernance. Google DeepMind a publié un Frontier Safety Framework, présenté comme une approche pour identifier et atténuer des risques graves associés à des capacités de frontière.

Ces documents ont une importance réelle. Ils ont contribué à installer l’idée que le développement de modèles puissants ne peut pas être séparé de travaux d’évaluation, de recherche en sûreté et de processus d’escalade internes. Ils ont aussi offert un langage commun aux institutions qui tentent d’encadrer le secteur. Le fait que les entreprises les publient est déjà une différence notable avec des périodes antérieures, où les décisions de lancement de produits d’IA relevaient presque entièrement de la communication commerciale et de procédures internes invisibles.

Pour autant, une politique de sécurité n’est pas automatiquement un manuel de gestion d’incident. Elle peut indiquer qu’un modèle ne doit pas franchir un certain seuil de risque sans protections additionnelles, sans détailler comment l’entreprise réagirait à un problème détecté après son déploiement. Elle peut exposer des catégories d’évaluation, sans préciser quels systèmes peuvent isoler une instance de modèle. Elle peut prévoir des revues de gouvernance, sans indiquer clairement quelles personnes disposent du pouvoir de suspendre un produit lorsque les intérêts commerciaux, la continuité de service et les impératifs de sûreté entrent en conflit.

C’est le cœur du reproche documenté dans l’étude citée par TechCrunch : les laboratoires publient davantage sur leurs doctrines que sur leurs procédures de confinement. Le diagnostic concerne la vérifiabilité publique, non l’existence certaine ou non de dispositifs privés. Cette nuance est décisive dans un secteur où les entreprises considèrent une part importante de leurs infrastructures, de leurs jeux d’évaluation et de leurs pratiques de sécurité comme confidentiels.

Les documents publics restent également difficiles à comparer. Les définitions de risque varient selon les organisations, tout comme les seuils, les méthodes d’évaluation et les formulations employées. Certains cadres sont centrés sur les capacités de modèles pouvant faciliter des usages gravement nuisibles ; d’autres accordent davantage de place au comportement de systèmes autonomes, à la cybersécurité ou à la gouvernance. Cette diversité reflète la pluralité des risques, mais elle complique le travail des observateurs externes. Une entreprise peut affirmer disposer de mesures « robustes » sans que le public puisse établir facilement une équivalence avec les garanties annoncées par un concurrent.

Il existe aussi une différence de temporalité. Les politiques de développement sont souvent pensées avant le lancement d’un modèle ou lors du franchissement de nouveaux paliers de capacité. Le confinement, lui, est un sujet de temps réel. Une procédure utile doit fonctionner quand les informations sont incomplètes, quand l’origine du problème n’est pas encore connue et quand une interruption de service peut avoir des conséquences importantes pour les clients. Elle suppose des équipes entraînées, des responsabilités claires et des outils techniques dont l’efficacité doit idéalement être testée régulièrement.

Dans l’industrie du logiciel, les exercices de réponse à incident et les simulations de crise sont une pratique connue. Dans le cas des modèles de frontière, la question devient plus complexe parce que l’objet de l’incident peut être un comportement émergent, une interaction inattendue avec des outils, une faille externe exploitée par un utilisateur malveillant ou une configuration de produit spécifique. La qualité de la réaction ne dépend donc pas seulement du fournisseur du modèle. Elle dépend aussi de l’intégrateur, du client qui a accordé des permissions, de l’hébergeur et parfois des éditeurs de logiciels tiers.

Une question réglementaire désormais centrale en Europe et en France

Le débat sur les plans de confinement arrive à un moment où l’Union européenne construit progressivement son cadre réglementaire pour l’intelligence artificielle. L’AI Act européen introduit une architecture fondée sur les niveaux de risque et comprend des dispositions visant les modèles d’IA à usage général, ainsi que les modèles présentant des risques systémiques. Le texte européen ne se réduit pas au cas hypothétique d’une IA « hors de contrôle » : il couvre également la documentation, la transparence, l’évaluation, la gestion des risques et, selon les situations, des obligations de signalement d’incidents graves.

Le sujet soulevé par TechCrunch s’insère naturellement dans cette logique. Si les modèles avancés deviennent des composants utilisés par de nombreuses entreprises, les régulateurs auront besoin de savoir non seulement comment ils ont été évalués avant commercialisation, mais aussi comment leurs concepteurs réagissent en cas d’incident. Les autorités doivent pouvoir distinguer une promesse générale de sûreté d’une capacité organisationnelle démontrable. Cette distinction vaut aussi pour les acheteurs publics et les grandes entreprises, qui ne peuvent pas déléguer totalement leur propre responsabilité de sécurité à un fournisseur d’IA.

Pour les acteurs français, la question a une portée concrète. Les entreprises qui intègrent des modèles génératifs dans leurs outils de relation client, de gestion documentaire, de développement logiciel ou d’analyse interne doivent examiner les droits réellement accordés aux systèmes. Elles doivent également clarifier les conditions de suspension d’un service, la réversibilité des intégrations, l’accès aux journaux d’activité et les modalités de notification lorsqu’un incident touche leurs données ou leurs processus. Une politique générale publiée par un laboratoire américain ou international peut être utile, mais elle ne remplace pas les exigences contractuelles et techniques nécessaires à chaque déploiement.

La France dispose déjà d’acteurs institutionnels engagés sur ces questions, notamment la CNIL pour les enjeux de données personnelles et l’ANSSI pour la cybersécurité. Le débat sur le confinement des systèmes d’IA se situe à l’intersection de leurs préoccupations, sans s’y réduire. Une IA dotée de permissions peut devenir un vecteur de fuite de données, de manipulation de processus ou d’exposition de systèmes informatiques. Mais elle pose aussi des problèmes spécifiques d’évaluation de comportements, d’autonomie et de contrôle des décisions automatisées.

Les entreprises françaises et européennes sont par ailleurs fréquemment clientes de modèles et de plateformes développés hors d’Europe. Cela accroît l’importance de la transparence. Un donneur d’ordre peut difficilement évaluer les conséquences d’une dépendance technologique s’il ne sait pas quelles garanties de suspension, de reprise et de communication d’incident son fournisseur est prêt à offrir. Cette exigence est particulièrement sensible dans les secteurs régulés, les administrations, la santé, la finance, l’énergie ou les entreprises manipulant des informations industrielles sensibles.

Une obligation de publier l’intégralité d’un plan de réponse à incident ne serait pas nécessairement la solution la plus efficace. Certains détails pourraient être exploités par des attaquants, tandis que les procédures devraient de toute façon évoluer avec les architectures et les produits. En revanche, les régulateurs pourraient exiger des éléments standardisés et auditables : identification des responsables, mécanismes d’escalade, catégories de mesures d’arrêt, conditions de notification, résultats d’exercices ou contrôles réalisés par des tiers qualifiés. L’enjeu ne serait pas d’obtenir les secrets opérationnels des entreprises, mais de vérifier que les capacités annoncées existent réellement.

Cette approche rappelle la manière dont sont traités d’autres secteurs à forts enjeux de sécurité. Le public ne connaît pas les détails des systèmes de sécurité d’un avion, d’un réseau de paiement ou d’une infrastructure critique. Mais les opérateurs doivent respecter des normes, conserver des traces, signaler certains événements et se soumettre à des contrôles. Le secteur de l’IA cherche encore son équivalent institutionnel, alors que ses produits sont déployés à une vitesse très rapide dans les organisations.

Au-delà des promesses : vers une sûreté démontrable des systèmes autonomes

Le principal apport de l’étude relayée par TechCrunch est de déplacer la discussion du niveau des intentions vers celui de la préparation. Une entreprise peut publier des principes de sûreté ambitieux et financer des équipes spécialisées. Cela ne répond pas à toutes les interrogations sur sa capacité à gérer une situation rare, complexe et potentiellement coûteuse. À l’inverse, l’absence de détails publics ne permet pas de conclure à l’absence de procédures internes. Ce que l’opacité produit, en revanche, est une difficulté collective à juger les écarts entre les laboratoires.

Cette difficulté est renforcée par la concurrence. Les entreprises développant les modèles les plus avancés sont engagées dans une course technologique et commerciale où la vitesse de lancement constitue un avantage. Dans un tel environnement, les annonces de politiques de sûreté jouent aussi un rôle de signal : elles rassurent les clients, les régulateurs et les investisseurs, tout en permettant aux laboratoires d’affirmer qu’ils prennent les risques au sérieux. Le test le plus exigeant n’est toutefois pas l’existence du document. C’est la capacité à accepter un retard, une limitation de fonctionnalités ou une suspension de déploiement si les protections ne sont pas jugées suffisantes.

Les comparaisons entre OpenAI, Anthropic, Google DeepMind et les autres développeurs doivent donc éviter deux écueils. Le premier serait de considérer que tous les cadres publics se valent parce qu’ils emploient des termes proches. Le second serait de conclure qu’une entreprise est nécessairement imprudente parce qu’elle ne divulgue pas ses procédures les plus sensibles. Une évaluation rigoureuse devrait regarder l’ensemble : nature du modèle, modalités d’accès, degré d’autonomie, outils disponibles, politiques de déploiement, organisation de la sécurité, mécanismes de signalement et possibilités de contrôle indépendant.

La notion de contrôle humain mérite elle aussi d’être précisée. Elle est souvent invoquée comme une garantie générale, alors qu’elle peut recouvrir des réalités très différentes. Un humain qui valide chaque action sensible n’exerce pas le même contrôle qu’un humain qui intervient seulement après coup. De même, une équipe de supervision ne peut agir utilement que si elle dispose d’alertes pertinentes, de droits techniques suffisants et d’une autorité formelle pour interrompre un système. Dans des processus rapides ou à grande échelle, une supervision uniquement symbolique peut devenir insuffisante.

Pour les fournisseurs, l’enjeu sera de démontrer que la sécurité est intégrée à l’architecture des produits plutôt qu’ajoutée comme une couche de communication. Cela implique notamment de limiter les permissions par défaut, de segmenter les environnements, de tracer les actions, de réduire les possibilités d’exfiltration de données et de prévoir des points de contrôle avant les opérations irréversibles. Ces principes ne sont pas propres à l’IA, mais ils prennent une importance nouvelle lorsqu’un système est capable d’enchaîner des tâches et d’adapter ses actions aux informations qu’il rencontre.

Pour les utilisateurs professionnels, le débat impose une forme de réalisme. L’adoption d’agents ne peut pas se fonder uniquement sur des démonstrations de productivité. Elle exige une gouvernance des accès et des responsabilités. Avant de relier un modèle à une messagerie, à un outil de paiement, à un système de production ou à des données sensibles, une organisation doit pouvoir répondre à des questions simples : quelles actions sont autorisées ? Qui peut les modifier ? Quelles sont les limites techniques ? Comment annuler ou interrompre une tâche ? Qui est prévenu en cas d’anomalie ? Et quelle part de la réponse dépend du fournisseur, du client ou d’un prestataire tiers ?

À long terme, la transparence sur le confinement pourrait devenir un critère de marché aussi important que le prix, la vitesse ou la qualité des modèles. Les grandes organisations chercheront probablement des fournisseurs capables de prouver leur résilience opérationnelle, pas seulement leurs performances sur des évaluations. Les régulateurs, de leur côté, seront poussés à transformer des notions générales de « sécurité » en obligations testables, sans exiger une divulgation qui fragiliserait les infrastructures.

Le débat ouvert par TechCrunch ne porte donc pas uniquement sur une hypothèse extrême. Il concerne la maturité d’une industrie qui veut faire passer ses modèles du statut d’outils conversationnels à celui de systèmes capables d’agir dans des environnements réels. Plus cette autonomie progresse, plus les politiques publiques de sûreté devront être accompagnées de preuves de préparation : qui peut arrêter quoi, dans quel délai, avec quelles garanties, et sous quel contrôle externe. C’est sur cette capacité à rendre la réponse aux incidents crédible et vérifiable que se jouera une part croissante de la confiance dans l’IA de frontière.