Control Room d’OpenAI : ce que son « bouton d’arrêt » coupe vraiment, et ce que l’AI Act exige

En une phrase : Control Room, le système d’arrêt présenté par OpenAI le 9 novembre 2026, empêche un travail de recherche d’obtenir de nouvelles réponses d’un modèle au plus 35 secondes après qu’un humain ou un système de surveillance a décidé de l’arrêter ; il ne couvre ni la détection du problème ni les modèles servis au public, et l’AI Act n’impose aucun dispositif de ce type, seulement une maîtrise des risques dès le développement.

Présenté en France comme un « kill switch » capable de stopper une IA qui dérape, comme dans l’article de Numerama du 11 novembre 2026, Control Room fait quelque chose de plus étroit et de plus vérifiable. Pour le mesurer, il faut lire la description technique publiée par OpenAI, puis la confronter à deux textes européens : l’AI Act et le chapitre sécurité du code de bonnes pratiques pour les modèles d’IA à usage général.

Ce que fait Control Room, pièce par pièce

D’après la description publiée par OpenAI, le dispositif relie trois éléments : le travail lancé par les chercheurs (une expérience d’apprentissage par renforcement, une évaluation, un traitement de données), le moteur d’inférence qui fait tourner le modèle sur les GPU, et un service central qui tient la liste des travaux autorisés.

Le fonctionnement tient en quelques étapes :

1. Enregistrement : au démarrage, le travail demande un identifiant à Control Room. Chaque travail qui fait de l’inférence « agentique » doit être rattaché à un dossier de sécurité approuvé (safety case).
2. Contrôle à chaque requête : quand le travail demande des réponses au modèle, le moteur interroge Control Room avant de répondre.
3. Arrêt : un chercheur ou un système de surveillance marque le travail comme arrêté. À la requête suivante, Control Room refuse l’autorisation et le moteur renvoie un refus au lieu d’une réponse.

Le choix d’architecture est le point le plus intéressant. OpenAI ne compte pas sur le code des chercheurs, qui change souvent, pour respecter l’arrêt : la vérification se fait dans la couche d’inférence, où il n’existe selon l’entreprise qu’un très petit nombre de chemins de code. Des balayages automatiques cherchent en plus les moteurs qui tourneraient sans Control Room, par erreur ou par malveillance.

Le système est aussi conçu pour échouer « fermé » : si le service tombe, ou s’il est désactivé, y compris par un acteur malveillant, toutes les requêtes sont refusées jusqu’à son rétablissement. D’après OpenAI, ce mode est actif pour tous les travaux de recherche sur ses modèles de pointe et devait être étendu aux autres travaux de recherche « dans les prochains jours ».

Ce que mesurent vraiment les 35 secondes

Le chiffre repris partout mesure un intervalle précis : le délai maximal entre le moment où Control Room reçoit l’ordre d’arrêter et le moment où le travail ne peut plus progresser. OpenAI l’attribue à une couche de cache des autorisations, nécessaire pour absorber le volume de requêtes, et dit vouloir le ramener à zéro.

Trois choses ne sont pas dans ces 35 secondes :

• La détection. Quelqu’un ou quelque chose doit d’abord repérer le problème. Tous les travaux d’apprentissage par renforcement de pointe tournent avec un « moniteur », un autre modèle qui inspecte ce que fait le modèle entraîné et lève une alerte, écrit OpenAI, qui cite un incident récent lié au DNS repéré de cette façon. Le temps de détection n’est pas chiffré.
• La décision. Selon la gravité, le système de surveillance « peut » décider seul d’arrêter le travail ; sinon, la décision revient à un humain. Le délai de cette étape n’est pas communiqué non plus.
• Ce qui a déjà été produit. Control Room bloque les réponses suivantes. Les réponses déjà renvoyées au travail, et ce que le travail en a fait, restent hors de son périmètre.

Autre précision qui change la lecture du mot « kill switch » : après l’arrêt, le processus du chercheur peut rester en vie et le moteur reste disponible pour les autres travaux autorisés. On coupe le robinet des réponses d’un travail donné, on n’éteint ni le modèle ni les machines.

Ce que le système ne couvre pas

Control Room est déployé sur l’infrastructure de recherche. Pour les modèles servis aux clients, ChatGPT et l’API compris, OpenAI explique que la pile de service externe est déjà beaucoup plus centralisée et dispose d’une capacité opérationnelle éprouvée pour retirer rapidement un déploiement. Aucun délai n’est donné pour ce retrait, et aucun détail technique comparable n’est publié.

C’est logique au regard du risque visé : les travaux de recherche sont ceux où des modèles plus puissants que les versions publiques tournent de façon autonome, parfois pendant des jours, avec des outils. C’est là que la catégorie de risque appelée « perte de contrôle » a le plus de sens. Pour ce que recouvre ce type de fonctionnement, voir notre explication des agents IA.

Ce que l’AI Act et le code européen demandent

L’AI Act impose des obligations renforcées aux fournisseurs de modèles d’IA à usage général présentant un risque systémique, une catégorie présumée au-delà de 10^25 opérations de calcul d’entraînement selon l’article 51 du règlement. Ces obligations, à l’article 55, tiennent en quatre points : évaluer les modèles, y compris par des essais contradictoires ; évaluer et atténuer les risques systémiques, y compris leurs origines, qui peuvent découler « du développement, de la mise sur le marché ou de l’utilisation » ; signaler sans retard injustifié les incidents graves au Bureau de l’IA ; assurer la cybersécurité du modèle et de son infrastructure physique.

Un détail juridique compte ici. La définition du modèle d’IA à usage général, à l’article 3 du règlement, exclut les modèles utilisés pour la recherche, le développement ou le prototypage avant leur mise sur le marché. Un modèle expérimental qui ne sortira jamais n’entre donc pas, en lui-même, dans le champ. Mais pour un modèle qui sera commercialisé, l’article 55 vise bien les risques nés du développement.

Le chapitre sécurité du code de bonnes pratiques, publié le 10 juillet 2025 et signé par OpenAI selon la liste tenue par la Commission, est plus explicite. Il demande de gérer les risques « tout au long du cycle de vie du modèle », y compris pendant le développement avant et après la mise sur le marché, et de ne poursuivre le développement, la mise sur le marché ou l’usage d’un modèle que si ses risques sont jugés acceptables (mesure 4.2). La « perte de contrôle » y figure parmi les risques systémiques à traiter, définie comme le risque que des humains perdent la capacité de diriger, modifier ou arrêter un modèle de façon fiable.

Source : description de Control Room par OpenAI, chapitre sécurité du code, mesures 4.2 et 9.3, règlement (UE) 2024/1689, articles 3, 51, 55, 101 et 113, relevés le 12 novembre 2026.

Les délais de signalement du code dépendent de la gravité, d’après sa mesure 9.3 : deux jours pour une perturbation grave et irréversible d’une infrastructure critique, cinq jours pour une faille de cybersécurité grave, y compris l’exfiltration des poids d’un modèle par lui-même, dix jours pour un décès, quinze jours pour une atteinte grave à la santé, aux droits fondamentaux, aux biens ou à l’environnement.

Quant aux sanctions, l’article 101 permet à la Commission d’infliger jusqu’à 3 % du chiffre d’affaires annuel mondial ou 15 millions d’euros, le montant le plus élevé étant retenu. L’article 113 l’exclut de l’entrée en application du 2 août 2025 : ce pouvoir s’applique depuis le 2 août 2026, date générale d’application, détaillée dans notre calendrier de l’AI Act.

Ce que ça change pour toi

Si tu utilises ChatGPT ou l’API d’OpenAI, rien ne change : Control Room ne touche pas aux modèles publics. Si tu travailles sur la conformité d’un fournisseur de modèles, ou si tu évalues ceux de tes prestataires, Control Room donne une grille de questions concrètes : qui peut ordonner un arrêt, en combien de temps il prend effet, ce qui se passe si le système d’arrêt lui-même tombe, et si le dispositif couvre aussi la recherche interne.

La comparaison avec Anthropic est instructive. Sa politique de sécurité, que nous avons décortiquée dans notre lecture du seuil RSP « imminent », prévoit des contrôles plus lourds au-delà d’un seuil de capacité, mais pas d’arrêt automatique. OpenAI publie ici l’inverse : un mécanisme d’arrêt rapide, sans dire quels seuils ou quelles alertes le déclenchent. Le même jour, OpenAI a d’ailleurs signé l’Appel de Paris pour la sécurité de l’IA, dont les développeurs signataires s’engagent à pouvoir interrompre leurs modèles, y compris pendant l’entraînement.

Ce qu’on ne sait pas encore

• Le temps de détection et de décision, qui pèse sans doute plus que les 35 secondes dans un incident réel : non communiqué.
• Les critères d’arrêt automatique du système de surveillance : la description d’OpenAI dit seulement qu’il décide « selon les détails et la gravité ».
• Le délai de retrait d’un modèle public, pour lequel OpenAI parle d’une capacité éprouvée sans la chiffrer.
• Une vérification indépendante : aucun audit externe du dispositif n’est publié, et le code européen ne prévoit pas de contrôle spécifique d’un mécanisme d’arrêt.

Les autres notions de fond sur la sécurité des modèles sont rassemblées dans la rubrique Comprendre.