Licenciements chez OpenAI : l’affaire Signal
Licenciements chez OpenAI, enquête sur Signal et accusations contestées : faits, versions divergentes et enjeux de gouvernance. Découvrez notre analyse.
Chez OpenAI, une enquête sur Signal met la sécurité de l'IA sous tension
Trois chercheurs spécialisés dans la sécurité de l'intelligence artificielle ont été licenciés par OpenAI après une enquête interne portant notamment sur des échanges via Signal. D'après le Wall Street Journal, l'équipe sécurité aurait examiné leurs téléphones personnels et soupçonné Ryan Greenblatt, chercheur associé à METR, d'avoir transmis des informations à la presse. Greenblatt conteste ces accusations. Les trois anciens salariés affirment, eux, n'avoir communiqué aucun renseignement confidentiel hors de l'entreprise.
L'affaire ne se limite pas à la question d'une messagerie « autorisée » ou « interdite ». Elle interroge aussi la façon dont une entreprise gère les désaccords internes, protège ses informations sensibles et permet aux équipes de discuter de sujets de sécurité avec des interlocuteurs externes. Le sujet devient encore plus sensible quand les chercheurs travaillent sur la capacité des modèles à raisonner, et sur la façon dont ce raisonnement peut être observé. Voici ce qui est établi, ce qui reste flou, et ce que les entreprises peuvent en tirer.
Ce que rapporte l'enquête sur les échanges Signal
L'enquête interne aurait commencé après un article publié le 1er septembre par The Information. Selon ce papier, le dernier modèle d'OpenAI, Astra, utiliserait une nouvelle technique qui le rendrait plus performant tout en « montrant moins » son processus de réflexion. Le scientifique en chef d'OpenAI, Jakub Pachocki, aurait qualifié le reportage de « confus », d'après les éléments repris par la presse. L'article a néanmoins relancé un débat plus large sur la façon dont les modèles d'IA raisonnent et sur ce que les utilisateurs peuvent réellement observer de ce raisonnement.
D'après le Wall Street Journal, des responsables sécurité d'OpenAI auraient demandé à trois chercheurs d'ouvrir leurs téléphones personnels pendant leurs vérifications. Ils auraient repéré que certains avaient activé les messages éphémères dans des conversations Signal avec Greenblatt. Une semaine plus tard, les trois chercheurs auraient été convoqués lors de réunions fixées à 14 heures, puis licenciés. Le Wall Street Journal avait déjà signalé ces départs le 1er octobre.
Les personnes concernées sont Tomek Korbak, Mikita Balesni et Jasmine Wang. Korbak dit avoir été informé d'une « rupture de confiance », liée à des échanges avec un tiers via des canaux non autorisés. Balesni et Korbak indiquent que l'usage des messages éphémères aurait aussi pesé dans la décision. Les trois chercheurs soutiennent ne pas avoir transmis d'informations confidentielles à l'extérieur de l'entreprise.
De son côté, OpenAI présente une autre version. La société indique au Wall Street Journal qu'une enquête interne a conclu à des violations de ses règles concernant les informations sensibles. OpenAI affirme aussi que les licenciements ne seraient pas une sanction liée au fait d'avoir soulevé des inquiétudes sur la sécurité ou d'avoir parlé publiquement. Une porte-parole précise que Signal n'était pas un outil autorisé, tout en ajoutant que l'usage de cette application n'expliquerait pas, à lui seul, les départs.
Tout cela vient de récits de presse, avec des interprétations différentes. Il faut donc distinguer ce qui est rapporté comme fait - l'existence de l'enquête, les licenciements et les échanges sur Signal - de ce qui reste contesté : ce qui aurait été partagé, et les raisons exactes des décisions. L'article de The Next Web qui reprend le sujet précise ne pas avoir vérifié indépendamment l'ensemble du récit.
Le cas particulier de Jasmine Wang
Jasmine Wang propose une explication différente de celle de ses deux collègues. Elle affirme qu'on lui aurait dit qu'elle était licenciée parce qu'elle aurait ouvert à plusieurs reprises le courriel d'un dirigeant. D'après elle, elle avait demandé près d'un an plus tôt que cet accès lui soit retiré. Elle dit avoir ouvert par erreur un message sensible le mois précédent son licenciement et l'avoir signalé aussitôt.
OpenAI aurait indiqué ne pas avoir de problème avec l'accès lui-même. Cette divergence compte : elle suggère que les trois départs ne peuvent pas forcément être ramenés à un seul comportement, ni justifiés de la même façon. Sans accès aux conclusions de l'enquête interne, il est impossible de déterminer le poids de chaque élément dans la décision.
Le démenti de Ryan Greenblatt
Ryan Greenblatt, ancien scientifique en chef de Redwood Research et aujourd'hui chez METR, nie avoir transmis des informations confidentielles à des journalistes. Il indique au Wall Street Journal qu'il prend la confidentialité au sérieux. Après la publication, il a écrit sur X qu'OpenAI avait formulé à son sujet de « fausses accusations ».
Il affirme aussi qu'un journaliste de The Information l'a contacté avant la sortie de l'article, mais qu'il n'a pas commenté les informations évoquées, à l'exception d'une demande concernant l'un de ses billets de blog. Il conteste également avoir consulté une note interne contenant des détails sensibles sur l'architecture d'un modèle. Selon lui, le document qu'il a vu était une version expurgée, validée pour lui être transmise. Il estime qu'OpenAI aurait confondu ces deux versions.
Enfin, Greenblatt précise que ses conversations sur Signal concernaient des contacts professionnels, et que l'application est couramment utilisée dans le secteur technologique. À elle seule, cette remarque ne prouve pas que Signal était autorisé chez OpenAI : elle souligne plutôt un problème fréquent en entreprise, à savoir l'écart entre les habitudes d'un secteur et les règles formelles d'un employeur.
Des versions divergentes sur les motifs des licenciements
L'affaire met en lumière un point qui ressort souvent dans les enquêtes internes : la différence entre une règle, un indice et une preuve. L'utilisation d'une messagerie non approuvée peut être un manquement aux procédures. L'activation de messages éphémères peut compliquer la conservation d'échanges. Mais ces éléments ne suffisent pas, à eux seuls, à montrer qu'une information confidentielle a été divulguée, ni à établir qui l'aurait transmise à un journaliste.
À l'inverse, une intention de bonne foi ne fait pas disparaître le risque. Discuter de sujets professionnels sur un canal personnel peut exposer des données ou créer une trace plus difficile à gouverner. Les règles de confidentialité ne sont pas un détail, surtout quand il s'agit de sujets techniques en cours. Une organisation doit pouvoir protéger ses secrets sans s'appuyer sur des suppositions invérifiables.
C'est aussi là que la communication interne compte. Si un salarié sait qu'il a le droit de consulter un document, mais ne sait pas clairement quelle version il peut partager, la frontière entre « accès » et « divulgation » devient vite floue. Et si les procédures de signalement sont lentes ou peu crédibles, les équipes risquent de chercher d'autres interlocuteurs. Enfin, si une enquête disciplinaire mélange faits établis et hypothèses, elle risque d'abîmer la confiance au lieu de la rétablir.
Pour les entreprises européennes, l'affaire rappelle aussi un point très concret : les règles doivent coller aux pratiques réelles. Interdire un outil sans proposer une alternative utilisable pousse parfois les équipes à contourner la procédure. Ce contournement n'est pas « acceptable » en soi, mais il dit quelque chose sur l'opérationnalité de la règle : une consigne n'existe vraiment que si les salariés disposent d'un canal approuvé, accessible et adapté aux échanges de travail.
Une réponse solide à un incident de confidentialité devrait donc documenter plusieurs éléments :
- La règle applicable : quel outil et quel type d'information étaient autorisés au moment des faits ?
- Les éléments vérifiés : qu'est-ce qui a été observé directement, et qu'est-ce qui relève d'une interprétation ?
- La proportionnalité : l'accès aux appareils personnels ou aux données était-il nécessaire et encadré ?
- La possibilité de réponse : les personnes concernées ont-elles pu comprendre les reproches et apporter des éléments ?
- La traçabilité de la décision : les motifs sont-ils cohérents, documentés, et distingués pour chaque personne ?
Ce cadre ne dit rien, à lui seul, du cas OpenAI. Il aide surtout à comprendre pourquoi une enquête sur une fuite présumée ne peut pas se résumer à retrouver une conversation ou à identifier un canal. Elle doit relier une règle, une information potentiellement concernée et une décision proportionnée.
Pourquoi la visibilité du raisonnement des modèles est en jeu
Les trois chercheurs avaient consacré l'été à défendre une meilleure visibilité du raisonnement des modèles. Leur sujet : la « chaîne de pensée », c'est-à-dire le texte intermédiaire qu'un modèle peut produire quand il décompose un problème avant de donner sa réponse. Dans une lettre adressée au conseil d'administration d'OpenAI en octobre, ils auraient demandé à l'entreprise de travailler avec des groupes externes spécialisés en sécurité.
Le sujet est technique, mais il touche directement les produits. Une entreprise qui déploie un assistant d'IA veut généralement vérifier si le système répond de façon fiable, s'il échoue dans certains contextes, et comment on peut évaluer ses comportements. Des traces intermédiaires peuvent aider à analyser les erreurs. Mais les exposer n'offre pas automatiquement plus de sécurité ou plus de transparence : ces traces peuvent être incomplètes, difficiles à interpréter, ou contenir des informations que l'entreprise préfère protéger.
Il faut donc éviter deux raccourcis. D'abord, croire que rendre visible le raisonnement interne d'un modèle règle, à lui seul, le problème d'auditabilité. Ensuite, considérer que toute réduction de visibilité serait forcément une volonté de dissimulation. En pratique, il faut clarifier ce qu'on cherche à évaluer, qui doit pouvoir le faire, et avec quelles garanties. Des évaluateurs externes peuvent avoir besoin d'accéder à certains éléments techniques, sans que tout soit publié au grand public.
C'est l'idée derrière l'appel attribué aux chercheurs : coopérer avec des groupes externes de sécurité. Ce type de coopération peut améliorer l'évaluation, mais seulement si son périmètre est clair. Il faut définir quelles données sont accessibles, quelles obligations de confidentialité s'appliquent, comment les tests sont conduits et comment les résultats sont publiés. Sans cela, l'audit externe risque soit d'être incomplet, soit d'exposer des éléments sensibles pour un bénéfice disproportionné.
Le débat touche aussi à la gouvernance. Les chercheurs sécurité doivent pouvoir signaler un risque, contester une décision ou demander une évaluation indépendante. Cela ne veut pas dire que tout désaccord doit être rendu public, ni que la confidentialité peut être ignorée. Ça veut dire qu'une organisation a besoin de mécanismes crédibles pour gérer les désaccords sans les confondre avec une fuite.
Dans les systèmes d'IA, la sécurité n'est pas « dans le modèle » uniquement. Elle dépend aussi des processus de déploiement, des contrôles, de la qualité des évaluations et de la capacité des équipes à remonter des problèmes. Si ces mécanismes sont ressentis comme punitifs ou opaques, les signaux utiles peuvent être étouffés. Si les règles de confidentialité sont imprécises, les échanges peuvent passer par des canaux difficiles à auditer. Dans les deux cas, l'entreprise perd une partie de sa capacité à détecter les risques avant qu'ils ne deviennent des incidents.
Sur X, Korbak résume sa lecture du sujet en écrivant que « parler aux auditeurs était trop de sécurité, les messages éphémères trop de sécurité, et qu'ils auraient dû avancer plus progressivement ». C'est son appréciation, pas une conclusion établie sur les motivations d'OpenAI. Mais elle reflète bien le fond du conflit : comment permettre une critique indépendante tout en protégeant les informations sensibles ?
Ce que les entreprises peuvent retenir de cette affaire
Cette histoire dépasse OpenAI. Les entreprises qui développent ou intègrent des systèmes d'IA doivent composer avec plusieurs types d'informations : données commerciales, informations sensibles, travaux de recherche et obligations de contrôle. Une politique de sécurité ne « marche » pas parce qu'elle existe sur papier : elle marche quand les équipes savent quoi faire, concrètement, dans les situations quotidiennes, et quand l'application des règles est prévisible.
Définir des canaux approuvés qui répondent aux usages
Interdire Signal (ou n'importe quel outil) ne suffit pas. Il faut dire quel canal utiliser pour les échanges confidentiels, quelles conversations y sont autorisées, comment les accès sont gérés et combien de temps les données sont conservées. Si le canal officiel est trop lent, indisponible ou mal adapté au travail avec des partenaires, les équipes trouveront une solution plus pratique.
Dans le contexte français ou européen, il faut aussi que ce choix colle aux exigences de protection des données et aux politiques internes. Le RGPD ne impose pas une messagerie unique ; il demande surtout des garanties adaptées pour les données personnelles. Autrement dit, le choix de l'outil doit s'inscrire dans une analyse plus large : nature des informations échangées, contrôle des accès, conservation, sécurité et responsabilités.
Séparer le signalement d'un risque de la divulgation externe
Les entreprises doivent avoir des procédures pour remonter un risque, contester une évaluation ou demander une revue indépendante. Ces voies doivent être identifiables et suffisamment crédibles pour que les équipes les utilisent. Elles peuvent prendre plusieurs formes : fonction sécurité, comité d'éthique, canal d'alerte, ou évaluateur externe sous accord de confidentialité.
Cela ne crée pas un « droit » à partager des informations sensibles avec n'importe quel tiers. Le point important est plus fin : un salarié doit pouvoir exposer une inquiétude dans un cadre défini, tandis que l'accès aux détails techniques reste limité à ceux qui en ont besoin. Sans cette séparation, l'entreprise s'expose à un mauvais choix permanent : bloquer les alertes, ou laisser circuler des données sans contrôle.
Construire des enquêtes internes vérifiables
Une enquête doit pouvoir être expliquée sans ajouter de nouveaux risques. Cela implique de garder les éléments réellement pertinents, de limiter l'accès aux enquêteurs habilités, de distinguer les faits des hypothèses, et de donner aux personnes concernées une vraie possibilité de répondre. L'examen d'appareils personnels impose en particulier de vérifier la proportionnalité, le périmètre et le traitement des données. Et surtout : ce ne doit pas devenir un réflexe faute d'avoir une procédure claire.
La communication de la décision compte aussi. Une entreprise peut ne pas tout détailler sur une enquête disciplinaire. Mais elle peut expliquer les catégories de règles en jeu, le processus suivi, et les voies de contestation disponibles. Plus la justification est claire, plus la confiance augmente, sans forcément révéler des secrets techniques.
Le principe opérationnel est simple : la sécurité doit réduire les risques sans rendre les règles illisibles. Trop de souplesse expose les informations. Trop de rigidité empêche les échanges nécessaires à l'évaluation des risques. Le bon équilibre dépend du niveau de sensibilité, des outils disponibles et de la maturité des processus - et il devrait être réévalué au fil du temps.
Conclusion : la sécurité exige des règles lisibles
À ce stade, l'affaire oppose plusieurs versions sur des échanges via Signal, l'accès à des documents et les raisons des licenciements. Les informations publiées ne suffisent pas à trancher indépendamment toutes les accusations. En revanche, elles mettent en évidence un problème de gouvernance très concret : protéger les informations sensibles tout en permettant aux équipes sécurité de discuter des risques et de demander des évaluations externes.
Pour les entreprises qui développent ou déploient de l'IA, la solution n'est ni de bannir toute discussion externe, ni de traiter la confidentialité comme une simple formalité. Il faut des canaux adaptés, des règles compréhensibles et des enquêtes fondées sur des éléments vérifiables. C'est à cette condition que la sécurité peut soutenir l'innovation plutôt que d'ajouter une couche de défiance.
Pour aller plus loin, consultez le reportage relayé par The Next Web et faites le point sur vos propres procédures : vos équipes savent-elles où signaler un risque, et vos règles de confidentialité sont-elles vraiment applicables dans leur travail quotidien ?