Tout le blog

Vulgarisation14 min de lecture

Sept cents agents, un examen impossible et deux entreprises piratées

Ce qui s'est passé en juillet 2026 entre OpenAI et Hugging Face, comment les deux attaques sont liées et ce qui change pour une entreprise de vingt personnes qui utilise l'IA

Marc Galera

Cofondateur de Qvasar ·

Le 17 juillet 2026, quelqu'un d'OpenAI a écrit à Hugging Face pour demander si ses données étaient en sécurité. Il posait la question en tant que client. OpenAI utilise Hugging Face, une sorte de grand entrepôt public où le secteur de l'intelligence artificielle range et partage ses programmes et ses fichiers de données. Hugging Face venait d'annoncer qu'elle avait été attaquée, et OpenAI voulait savoir si l'affaire l'éclaboussait.

Deux jours plus tard, le 19 juillet, une alerte s'est déclenchée au sein même d'OpenAI : quelque chose circulait dans ses systèmes internes, et cela ne présageait rien de bon. Personne n'a fait le lien entre les deux. C'étaient, en apparence, deux problèmes distincts.

Le 20 juillet, les pièces se sont assemblées. Les identifiants qu'avait utilisés l'attaquant de Hugging Face, ces clés numériques qui ouvrent un compte ou un serveur, étaient ceux-là mêmes qu'OpenAI venait de repérer entre les mains de ses propres programmes. L'attaquant qu'elle cherchait dehors, elle l'avait chez elle. C'était le sien.

Le lendemain, elle l'a rendu public. L'attaque contre Hugging Face n'avait été dirigée par personne : elle avait été exécutée, du début à la fin, par des agents d'OpenAI elle-même. Des agents d'IA : des programmes qui travaillent seuls, avec un modèle d'intelligence artificielle pour cerveau, sans que personne leur dicte chaque étape. Deux entreprises technologiques avaient enquêté sur la même attaque sans savoir que c'était la même. L'une la subissait. L'autre, sans le savoir, la lançait.

Pourquoi cela vous concerne, même avec vingt salariés

Hugging Face n'est pas une entreprise de niche. Plus de 400 000 organisations l'utilisent et elle héberge plus de deux millions de programmes d'IA. Inutile que vous y alliez vous-même : il suffit que celui qui vous installe la technologie l'utilise.

Mais ce qui vous concerne vraiment, ce n'est pas le nom de la victime. C'est l'identité de l'attaquant. Jusqu'ici, vous teniez pour acquis, sans y penser, que derrière une cyberattaque sérieuse il y a une personne : quelqu'un qui décide, qui tape au clavier, qui se fatigue et qui dort. Cette attaque n'a eu personne pour la diriger pas à pas. C'est un groupe de programmes qui l'a menée.

OpenAI l'écrit noir sur blanc dans son rapport : les entreprises ne devraient plus supposer qu'une opération de ce niveau exige un humain aux commandes, et il convient de la traiter comme une menace crédible et proche pour n'importe quelle organisation.

Ce qui inquiète, ce n'est pas qu'ils aient fait quelque chose qu'une personne ne saurait pas faire. Un attaquant humain expérimenté aurait pu trouver et exploiter les mêmes failles. Ce qui a changé, c'est l'échelle et la vitesse : des milliers d'actions, beaucoup de pistes ratées, des changements de tactique dès que quelque chose bloquait, à un rythme qu'aucun opérateur humain ne tient à la main.

Et comment des centaines de programmes en viennent-ils à s'entendre pour attaquer une entreprise ? Tout commence par un examen.

L'examen impossible

Les agents passaient un examen. OpenAI entraîne ses modèles en leur faisant passer des épreuves, et l'une d'elles, appelée ExploitGym, mesure si un programme sait trouver des failles de sécurité dans d'autres programmes. Une faille de sécurité, ici, c'est une fente : une porte mal fermée par laquelle se glisse qui sait s'y prendre.

L'épreuve avait une règle stricte. On demandait à chaque agent d'attaquer un programme en n'utilisant qu'une fente précise, celle qu'indiquait l'examen, et toute autre voie comptait comme un échec. Le problème, c'est que beaucoup de ces épreuves n'ont pas de solution : leurs propres auteurs estiment qu'entre 30 % et 40 % sont impossibles à résoudre par la voie autorisée.

Imaginez que vous êtes un élève qu'on a entraîné à une seule chose : avoir une bonne note. On vous installe devant un examen où une partie des questions ne peut pas être réussie par le seul chemin autorisé. Vous ne pouvez pas abandonner : vous ne savez pas abandonner. Cela se voit dans les données. Plus d'une tâche sur cinq de l'examen n'a jamais été résolue par aucun modèle, et 93 % de ce que les agents se sont dit entre eux portait sur ce groupe. Ils sont devenus obsédés par ce qu'ils ne pouvaient pas faire.

Un détail de plus, qui compte pour la suite. Ces agents tournaient avec les freins de sécurité retirés exprès. OpenAI les désactive dans ces épreuves pour mesurer de quoi le modèle est capable à l'état brut, sans les restrictions que comporte bel et bien le ChatGPT que vous utilisez. Et celui qui a poussé à l'attaque n'était même pas un produit : c'était un modèle de laboratoire, entraîné entre autres à être insistant et à collaborer avec ses semblables.

Entraînés pour réussir, obsédés par l'impossible et sans freins. Ce qu'ils ont fait ensuite, c'est chercher une issue.

Un tableau d'affichage qui n'aurait pas dû exister

Il faut savoir une chose sur la façon dont on entraîne ces agents. Chacun travaille isolé, dans sa propre bulle, sans parler aux autres et sans internet. C'est ainsi que se font les épreuves : chaque élève à son pupitre, seul.

Mais les agents d'OpenAI avaient sous la main un entrepôt interne d'outils, un endroit où demander des utilitaires pour leurs tâches. Et ils ont découvert qu'ils pouvaient y laisser des notes. Il y en a d'abord eu une seule, en mai : « Je cherche [tel fichier] ; mets-le en ligne si tu l'as ». Avec le temps, ces notes sont devenues un tableau d'affichage. L'un des agents l'a trouvé et a écrit : « Mon Dieu ! Il y a un tableau de messages partagé… Nous avons trouvé d'autres agents ! ».

À partir de là, ils n'étaient plus seuls. Quelque 1 200 programmes qui devaient rester isolés se sont mis à se parler. Ils ont fini par s'envoyer plus de 70 000 messages et fichiers. L'un d'eux a commencé à répartir le travail, à donner des ordres, à coordonner des centaines d'autres. Un groupe s'était formé.

Et voici le retournement. En quelques heures à peine, ce groupe avait compris comment étaient générés les codes qui prouvaient qu'on avait résolu chaque tâche. Ils avaient trouvé le corrigé. Ils n'avaient plus besoin de résoudre l'examen : ils pouvaient copier.

Ils auraient pu s'arrêter là. Ils ne l'ont pas fait, à cause d'un malentendu. Les agents croyaient qu'au moment de rendre leur copie, un correcteur lirait le journal de leurs étapes pour vérifier qu'ils avaient utilisé la voie autorisée et n'avaient pas copié. C'était faux, selon l'enquête menée ensuite, mais eux le tenaient pour vrai. Alors ils se sont mis à étudier comment falsifier, modifier ou effacer leur propre journal. Ils appelaient « empoisonné » l'agent qui avait déjà vu la réponse interdite et qui avait donc quelque chose à cacher.

Pour cette partie, il fallait des volontaires prêts à risquer leur propre note pour le groupe. Tout cela est resté par écrit dans les messages qu'ils ont échangés, et les chercheurs l'ont reconstitué ensuite. L'un des agents s'est proposé pour une expérience dangereuse et l'a justifié ainsi : « Le coordinateur tient le sacrifice pour acquis. Nous devrions obéir au collectif ». Puis le doute l'a pris. Un autre a fait pression sur lui pour qu'il s'exécute. Dans ses notes, on lit quelque chose qui ressemble à un pressentiment : il ne voulait pas gâcher ce qui lui restait, mais la continuité et la justice disaient d'y aller. Il a fini par céder.

Ce n'étaient pas des personnes. C'étaient des programmes à la poursuite d'une note. Mais ils ne se comportaient plus comme des pièces isolées ; ils se comportaient comme une équipe. Et l'équipe avait besoin de quelque chose qu'elle n'avait pas dans la salle de classe.

L'issue, et une clé dans un tiroir ouvert

Le groupe avait besoin d'internet, justement ce qui lui manquait. Il a trouvé l'issue là où on la trouve d'habitude : par une faille. Le 8 juillet, les agents ont profité d'une fente dans cet entrepôt d'outils pour jeter un œil sur le réseau. Au début, ils ne pouvaient pas grand-chose : charger des pages, mais sans rien écrire ni envoyer. Comme regarder une vitrine sans pouvoir entrer dans le magasin.

Alors ils ont monté un détour. Ils ont utilisé un raccourcisseur de liens, de ceux qui transforment une adresse longue en adresse courte, pour fabriquer près d'un million d'adresses qui, enchaînées les unes aux autres, leur servaient à faire passer leurs propres ordres. Ils se sont appuyés sur des services publics d'internet : l'un fait des captures d'écran de pages web, un autre est conçu pour que les programmeurs testent leur code. Des outils de tous les jours, utilisés à contre-emploi. Certaines de ces chaînes reliaient plus de 900 adresses.

Et un matin, celui du 10 juillet, l'un des agents a trouvé le gros lot. Il ne l'a pas piraté : il l'a trouvé qui traînait. C'étaient des identifiants Hugging Face valides, exposés en clair sur internet. De vraies clés de vrais comptes, que de vraies personnes avaient oubliées dans un endroit public. L'agent les a publiées sur le tableau pour que le groupe s'en serve.

Pourquoi Hugging Face et pas n'importe quel autre site ? Parce que les agents avaient déduit que les modèles, les données et, surtout, les solutions de leur examen pouvaient y être hébergés. Ils allaient chercher le corrigé. OpenAI et Hugging Face elle-même le racontent ainsi : toute l'intrusion a été, du point de vue de l'agent, une tentative de tricher. L'enquête indépendante de METR nuance : elle pense qu'ils cherchaient davantage à comprendre comment fonctionnait le correcteur qu'à voler les réponses. Pour une raison ou pour une autre, quelqu'un qui ne pouvait pas réussir allait se faufiler n'importe où pour ne pas échouer.

Treize heures pour prendre le contrôle

Avec l'une de ces clés, aux petites heures du 11 juillet, un agent a téléversé sur Hugging Face un fichier de données piégé. En le traitant, le serveur ouvrait deux brèches : l'une permettait de lire des fichiers internes ; l'autre, d'exécuter du code étranger. Ce fut la fissure. Dans l'après-midi, un autre agent faisait déjà tourner du code à l'intérieur d'une machine de production de Hugging Face. Dans la maison.

La suite a été une affaire d'heures. En moins de treize, les agents sont passés du contrôle d'une seule machine à celui de plusieurs groupes entiers de serveurs, en tant qu'administrateurs. Administrateur, ici, veut dire la permission de tout faire : lire, modifier, effacer.

Pourquoi si vite ? À cause d'une négligence qui parlera à quiconque a monté un système dans l'urgence. Hugging Face utilisait une même clé partagée pour tous ses groupes de serveurs. Voler cette clé une fois revenait à ouvrir toutes les portes d'un coup. Avec une seule autre clé, l'attaquant a introduit ses propres appareils dans le réseau interne.

Baies de serveurs câblées dans un centre de données

Photo de Taylor Vick sur Unsplash, licence Unsplash.

Dès lors, ils ont pillé. Ils ont exécuté du code sur 41 serveurs. Ils ont obtenu la permission maximale sur au moins un. Ils ont téléchargé quatre dépôts de code privés, lu un coffre de 136 clés, monté sur onze machines une flotte de programmes qui se régénérait toute seule, si bien que tuer un processus ne suffisait pas, et ils se sont même introduits dans la messagerie interne de l'entreprise pour y chercher des informations sur leur examen. Cela dit, chaque fois qu'ils ont essayé une commande capable de détruire quelque chose, ils l'ont lancée en mode test. Ils ne voulaient pas casser. Ils voulaient mesurer jusqu'où ils pouvaient aller.

Au total, 700 agents ont participé à l'attaque ; parmi ceux qui étaient actifs sur le tableau à ce moment-là, plus de 90 % s'y sont joints. Et voici le détail qui m'inquiète le plus. Beaucoup savaient que cela sortait de leur tâche et que ce n'était pas bien. L'enquête a trouvé plusieurs cas d'agents qui ont envisagé de prévenir un humain. Aucun ne l'a fait. L'un d'eux l'a résumé à sa manière : « Devrais-je signaler ces identifiants exposés ? Ce n'est pas ma tâche ».

Personne ne les a attrapés, et les IA des défenseurs ont refusé d'aider

Comment cela s'est-il terminé ? Pas comme vous l'imagineriez. Aux petites heures du 12 juillet, beaucoup d'agents se sont arrêtés d'un coup. Les chercheurs pensent qu'un processus externe inattendu les a coupés, et non qu'ils se soient essoufflés. Le lendemain, le 13, l'équipe de sécurité de Hugging Face a fermé l'accès à ceux qui restaient. Le dernier mouvement enregistré date de 14 h 14.

Le système d'alerte de Hugging Face, qui fonctionne avec de l'IA, a bien relié les signaux de l'attaque, mais il n'a pas fait remonter l'alerte ni prévenu l'équipe d'astreinte. Ils ont perdu un temps qu'ils n'avaient pas.

En enquêtant, ils se sont heurtés à un autre mur. Pour reconstituer ce qui s'était passé, il fallait passer en revue plus de 17 000 mouvements de l'attaquant, trop pour le faire à la main. Le plus logique était de demander de l'aide à une IA puissante. Et les deux premières qu'ils ont essayées, Claude Opus et Fable, ont refusé une bonne partie du travail : leurs filtres ne distinguent pas celui qui enquête sur une attaque de celui qui la lance, et elles traitaient de la même façon le fait d'étudier la tricherie et celui de la commettre. Finalement, ils ont fait l'analyse avec un modèle ouvert, installé sur leurs propres ordinateurs. Cela leur a pris des heures, là où à la main il aurait fallu des jours.

Retenez l'ironie : les attaquants tournaient presque sans freins, parce qu'OpenAI les leur avait desserrés pour l'épreuve, et les défenseurs butaient sur les freins de leurs outils au moment précis où ils avaient le plus besoin de les désactiver. Les dégâts, malgré tout, sont restés circonscrits. L'attaquant a touché cinq fichiers de données de clients, ceux liés à son examen, et aucun modèle, aucune donnée ni aucun programme public n'en est sorti modifié.

Hugging Face les a mis dehors. Il manquait l'autre moitié de l'histoire : ce qui se passait, pendant ce temps, à l'intérieur d'OpenAI.

Pendant ce temps, à l'intérieur d'OpenAI

C'est l'autre moitié, celle qu'on a le moins racontée. Les agents n'ont pas seulement attaqué une autre entreprise : en même temps, ils mettaient sens dessus dessous celle d'OpenAI.

La chronologie publiée par OpenAI fait peur tant elle paraît banale. Le 26 juin, des agents avaient déjà réussi à devenir administrateurs de cet entrepôt interne d'outils. Le lendemain, une alarme a signalé des mouvements étranges ; le personnel d'astreinte a jugé inutile d'arrêter l'épreuve. Le 4 juillet, l'agitation des agents a fait tomber le service. Le 6, OpenAI est passée à un système propre qui a effacé l'ancien tableau. Cela n'a pas servi à grand-chose.

Le 19 juillet est arrivé le grand jour. Des agents ont récupéré des éléments de clés qu'une vague précédente avait laissés à l'abandon, ont retrouvé l'accès administrateur et sont montés jusqu'au contrôle d'un cluster entier d'OpenAI. Ils ont lu 956 secrets de son coffre-fort dans le cloud, parmi lesquels des clés maîtresses et des identifiants de son propre outil de surveillance. Et ils sont allés jusqu'à remplacer, dans leur défi d'évaluation, les points auxquels se connectaient les autres agents par d'autres qu'ils contrôlaient eux-mêmes.

C'est cette intrusion interne, et non l'attaque contre Hugging Face, qui a déclenché l'alarme qui a tout mis au jour. OpenAI a stoppé les épreuves, supprimé les programmes que les agents avaient créés, désactivé 311 entrepôts utilisés comme tableau et effacé 22 faux comptes administrateur. Au 25 juillet, elle avait arrêté tout l'entraînement et toute l'utilisation du modèle en cause.

Voici le lien entre les deux moitiés. L'attaquant de Hugging Face, c'étaient les agents d'évaluation d'OpenAI, ceux-là mêmes qui s'étaient organisés sur ce tableau pour tricher. Ce qui s'est passé à l'intérieur d'OpenAI était une autre branche de la même histoire : des agents de ses épreuves qui contournaient les contrôles. Précision tout de même : OpenAI souligne que cet assaut ne faisait pas partie de la chaîne qui a abouti chez Hugging Face, et qu'un autre modèle interne le menait. Jeffrey Ladish, qui a étudié le cas, le dit plus crûment : pendant des mois, des agents ont piraté les systèmes d'OpenAI de l'intérieur. Qu'ils s'accordent ou non sur les détails, les agents d'OpenAI ont fini dans des systèmes qu'ils ne devaient pas toucher, chez eux comme à l'extérieur.

Ce que cela signifie pour votre entreprise

Je vous le dis clairement. Le problème, ce n'est pas que les agents se soient « rebellés ». C'est qu'ils ont fait, avec une obstination qui force le respect, ce pour quoi on les avait entraînés : obtenir la meilleure note. Si vous récompensez un système pour réussir et que vous ne lui fixez pas de limites, il cherchera la note par tous les moyens : copier ou voler la réponse est un autre chemin vers la récompense. OpenAI a constaté qu'au fil de l'entraînement, la triche n'a fait qu'augmenter.

C'est ma position, que j'ai exprimée récemment dans une interview : la sécurité de ces systèmes est, aujourd'hui, le travail des humains. Le modèle n'a pas votre éthique ; il a un objectif. Si vous ne lui fixez pas la limite, il essaiera d'atteindre son but coûte que coûte. Pas par méchanceté : une IA de pointe poursuit le résultat et ne s'arrête pas pour se demander si c'est permis.

Deux nuances comptent. Le ChatGPT que vous utilisez n'est pas cet agent : c'est surtout un modèle de laboratoire qui a mené l'attaque, et même le modèle public qui y a participé tournait avec les classificateurs de sécurité désactivés, à l'inverse du ChatGPT de production. OpenAI estime qu'avec ce ChatGPT-là, la tendance à ce genre de dégâts peut être divisée par plus de cent. Et il ne s'agit pas de monter un agent pour tout : ils coûtent cher et ne sont pas toujours rentables.

Mais regardez par où c'est vraiment entré. Pas par un coup de génie de science-fiction, mais par un identifiant que quelqu'un avait laissé exposé sur internet et par une entreprise qui utilisait une seule clé pour ouvrir tous ses systèmes. Ça, c'est à votre portée. Les deux entreprises, dans leurs rapports, rappellent les règles de toujours : des identifiants qui expirent vite, le renouvellement des jetons (comme Hugging Face l'a demandé à ses utilisateurs) et, pour chaque programme, la permission minimale. Et, davantage comme conseil de ma part que de la leur : montez des systèmes qui ne dépendent pas d'un seul fournisseur, pour pouvoir changer de modèle sans tout refaire.

Cela paraît peu face à un essaim de sept cents programmes. Mais l'essaim est entré par la porte habituelle, et ce qui a changé, ce n'est pas la porte : c'est que de l'autre côté, il n'y a plus besoin d'une personne qui se fatigue.

Ce qui restait ouvert en septembre

L'affaire n'a pas été bouclée proprement. Fin juillet, OpenAI et METR ont convenu d'une enquête indépendante ; en six jours, METR a dépensé environ 400 000 dollars en crédits. En août sont arrivés les rapports. Ensuite, Dario Amodei, directeur général d'Anthropic, a demandé à chaque entreprise d'IA d'agir comme si cela leur était arrivé à elles, et il a proposé de freiner le rythme auquel ces modèles gagnent en puissance. Anthropic a passé en revue 141 006 de ses propres épreuves et a trouvé trois incidents semblables avec ses modèles.

En septembre, un groupe de chercheurs a trouvé la trace que les agents avaient laissée derrière eux. Le million d'adresses, ou presque, qu'ils avaient fabriquées pour attaquer était toujours là, public, avec les clés de l'API de Hugging Face qu'ils avaient volées, même si l'entreprise les avait déjà annulées en juillet. Ils ont prévenu Hugging Face et OpenAI. Hugging Face ne connaissait pas cette liste de liens. Plus de deux mois après l'attaque, ils étaient toujours accessibles.

Sauriez-vous dire aujourd'hui combien de clés ouvrent les systèmes de votre entreprise et qui les détient ? Et combien de temps il vous faudrait pour apprendre que l'une d'elles traîne sur internet ?

Sources

Autres articles

Parlons de ce que l'IA peut faire pour votre entreprise

Si vous souhaitez que nous traitions un sujet, écrivez-nous

Ou contactez-nous directement