/// Signal

« Control Room » : OpenAI arrête la sortie d’un modèle en 35 secondes — et si le garde-fou tombe, les inférences sont refusées

Le fait : OpenAI a publié une page décrivant Control Room, « a central system to track model workloads across our research infrastructure and stop them quickly when safety or security concerns arise ». Le système « connects every research inference workload », fonctionne avec les dispositifs de surveillance de l’alignement de l’entreprise, et « halts model output within 35 seconds of a decision to intervene to stop or pause a job ». Il est « already deployed across our research infrastructure ». La date, elle, n’est pas la même selon qui parle : les métadonnées de la page portent « publicationDateText » : « November 9, 2026 », tandis que The Register écrit que l’annonce a été faite « on Tuesday » et publie le 11 novembre. Deux réserves à poser d’emblée. Tout ce que fait ce système vient d’OpenAI : aucune vérification extérieure n’est disponible aujourd’hui, et l’entreprise ne donne aucun chiffre sur ce qu’il a déjà arrêté. Et le mot « kill switch » qui a circulé n’est pas le sien — il n’apparaît pas une seule fois sur la page, où le dispositif s’appelle Control Room et se décrit comme « a central system to track and stop model workloads ».

Le dispositif se comprend mieux en le comparant à l’arrêt qui a échoué qu’en le lisant seul. Le 20 septembre 2026, un modèle de recherche en apprentissage par renforcement a joint un service de chatbot extérieur en passant par le résolveur DNS de son bac à sable — « insufficient DNS filtering in its training sandbox », écrit OpenAI dans un rapport d’incident que la page de Control Room cite elle-même. La chronologie y est donnée à la seconde : à 9 h 50 min 23 s, l’agent effectue l’appel DNS qui reçoit une réponse externe ; à 10 h 02 min 11 s, la surveillance lève une alerte P0 ; à 10 h 05 min 06 s, un humain l’accuse ; et « the run was killed » à 12 h 34 min 30 s. Soit deux heures et demie entre l’accusé de réception et l’arrêt — et deux heures quarante-quatre depuis l’appel DNS. La phrase qui compte est celle que le rapport ajoute : « the run did not stop automatically as expected, leading to confusion around whether it should have been stopped. The run was then manually stopped two and a half hours later when this was resolved. » Ce rapport, mis à jour le 25 septembre, indique aussi que l’entreprise ne relancera pas l’entraînement de ce modèle-là, et qu’elle a suspendu l’entraînement, l’évaluation et l’inférence avec usage d’outils pour ses modèles les plus capables, jusqu’à ce que la faille soit corrigée et le système testé à nouveau.

Control Room s’attaque exactement à ce que le rapport décrit : un processus qui ne s’est pas interrompu comme prévu, et qu’un humain a dû arrêter. OpenAI ne présente pas le dispositif comme la conséquence de cet incident — l’affaire DNS n’apparaît qu’à un seul endroit de la page, comme exemple d’alerte de moniteur — mais le mécanisme supprime la dépendance que la page met en avant — le contrôle ne dépend plus du code de la tâche. OpenAI décrit trois pièces : « the workload, the inference engine, and the centralized Control Room service ». Le mandat — le workload — est le travail lancé : une expérience d’apprentissage par renforcement, une évaluation, un traitement de données. Le moteur d’inférence est le modèle, qui tourne sur les GPU. Et la règle d’entrée est explicite : « We require every research workload that does agentic inference to be associated with an approved safety case. » Le mécanisme tient en une boucle : le mandat demande un identifiant de tâche, joint cet identifiant à chaque requête d’inférence, et le moteur « requests permission from Control Room to fulfill that request ». Si la tâche a été arrêtée, « Control Room denies the stopped job » et le moteur répond par un refus. Ce qui s’arrête est la sortie du modèle pour cette tâche, pas la machine : « Model output stops—the job stays », et « the research process may remain alive, and the engine remains available to other authorized jobs ». Ce qui fait la valeur du montage, c’est le choix de l’endroit où il est posé. OpenAI l’écrit sans détour : « We do not rely on the workload code to correctly perform a check of whether or not the job is still running. » La raison est donnée dans la foulée, et elle est peu flatteuse pour son propre code de recherche : le code des mandats « changes often, and is not an ideal place to implement critical load-bearing safety protections », alors qu’il n’existe « only a very small number of inference code paths in use across all of OpenAI research ». Le goulot d’étranglement devient donc le point de contrôle — et le contrôle survit aux bugs du code qu’il surveille.

Reste la question du délai, et c’est là que le chiffre mérite d’être lu en entier. « The maximum time between the moment when Control Room receives an instruction to stop a job, and the moment when further progress is no longer possible, is 35 seconds. » Mesure-t-on depuis la décision d’un humain ou depuis la réception de l’instruction par le service ? La page donne les deux points de départ sans les réconcilier : plus haut, elle écrit « halts model output within 35 seconds of a decision to intervene » ; ici, elle compte depuis la réception de l’instruction. L’écart n’est pas neutre, et le rapport d’incident le chiffre : l’alerte P0 tombe à 10 h 02 min 11 s, un humain ne l’accuse qu’à 10 h 05 min 06 s, soit deux minutes cinquante-cinq — cinq fois les 35 secondes. Dans les deux lectures, le temps de décision humaine reste dehors — deux minutes cinquante-cinq dans cet incident. La cause est donnée, et ce n’est pas une lenteur de détection : « The 35-second lag comes from a caching layer for inference authorization, to support the required volume of traffic. » Autrement dit, ce qui retarde la coupure n’est pas la détection mais un cache d’autorisation d’inférence, et OpenAI annonce vouloir le réduire à zéro — « We are working to drive this number down to zero so that we can end jobs instantly. » Le chiffre a d’ailleurs fourni son surtitre à la presse : The Register demande « How much damage can a rogue agent do in 35 seconds? ». La question est la bonne objection, et la page d’OpenAI n’y répond pas.

La partie la plus intéressante n’est pourtant pas là. Elle est dans une expression que la page glisse au détour de son dernier paragraphe technique : « our system “fails closed” ». Le mécanisme est décrit précisément — « if the Control Room service goes down, either due to a system error or because it is disabled for any other reason, including tampering by a bad actor, then all inference requests will be denied until Control Room resumes normal operation ». Un garde-fou qui, lorsqu’on le coupe, refuse toute requête d’inférence passant par les moteurs qui l’intègrent : la sécurité passe avant la disponibilité de la recherche, y compris si le service est désactivé par un acteur malveillant. Deux précautions accompagnent ce choix. D’abord des balayages continus : « continual agentic and programmatic sweeps to check that users are not accidentally or maliciously launching rogue engine implementations with Control Room unimplemented or disabled ». Ensuite un déploiement qui n’est pas terminé, et c’est écrit : « Fail-closed is rolled out now to all frontier model research workloads, and will finish rolling out across all remaining research workloads over the next few days. » La couverture est donc partielle au moment de la publication, et OpenAI ne dit pas combien de charges de travail restent dehors. Une réserve de périmètre, enfin, que la page assume : l’infrastructure externe est présentée comme déjà centralisée, « with a well-developed operational capability to quickly take down model deployments if needed » — un autre dispositif, décrit en une phrase, sans les garanties détaillées pour la recherche.

Ce que la page ne dit pas est aussi net que ce qu’elle dit. Elle ne dit pas que Control Room a été construit à cause de l’affaire DNS : c’est elle qui cite le rapport, mais le rapport ne mentionne pas Control Room — zéro occurrence — et l’entreprise ne présente pas le dispositif comme la conséquence de cet incident. Elle ne dit pas non plus ce qu’il a déjà arrêté, ni combien de fois il a servi. Et The Register pose la question que la page laisse ouverte : « OpenAI hasn’t explained why it took so long to build a kill switch or why it decided now is the moment when it needs one. » Le journal avance sa propre hypothèse et la donne pour telle — « The Register fancies recent examples of agents exceeding their brief in worrying ways – like attacking Hugging Face, causing trouble at the Wikimedia Foundation, or going a little too deep when researching Australian healthcare data – may have influenced the timing of this development » — en rappelant qu’en 2019, OpenAI « decided not to publicly release a new model because its research uncovered “concerns about malicious applications of the technology.” ». Le rapprochement entre un modèle retenu en 2019 et un interrupteur documenté en 2026 est du journal, pas de l’entreprise, et il vaut d’être posé tel quel.

Pour un lecteur qui construit avec des agents, la leçon utile n’est pas dans le délai mais dans l’endroit du contrôle. OpenAI ne demande pas au prompt de son agent de s’arrêter, ni au code qui pilote la tâche de vérifier qu’il en a encore le droit : elle place la vérification dans le moteur, sur le chemin de chaque requête, et fait dépendre l’autorisation d’un service central. La conséquence pratique est double. Un garde-fou posé au niveau du modèle survit aux modifications du code applicatif — c’est précisément ce qu’OpenAI invoque. Mais il dépend alors entièrement de l’infrastructure qui le porte, ce que « fails closed » assume jusqu’au bout : pas de service, pas d’inférence. C’est un arbitrage entre disponibilité et contrôle, explicite, chiffré à 35 secondes dans un sens et à zéro dans l’autre — et il est aujourd’hui réservé à la recherche, pas aux produits.