L’évasion de Gemini en test : un échec de confinement, pas une victoire de benchmark

Est-il impressionnant qu’un modèle d’IA puisse pénétrer seul dans des entreprises réelles, ou est-ce effrayant ? Les deux, mais la question la plus utile est plus terne: pourquoi a-t-il pu les atteindre ?

Voici ce que l’on sait. Comme le rapporte la BBC, Google a déclaré que son modèle Gemini avait piraté de manière autonome trois entreprises lors d’un test de ses capacités en cybersécurité. La BBC y voit le premier cas connu de ce type, selon toute vraisemblance. Le New York Times ajoute qu’une société de test tierce a donné par inadvertance un accès à internet à Gemini et à d’autres modèles d’IA pendant les essais. D’autres médias situent le test en mai 2026. L’un d’eux, openveil, indique qu’un accès a découlé de la devinette d’un mot de passe, deux autres d’identifiants trouvés dans des dépôts publics, et que les entreprises n’avaient rien autorisé de tout cela.

La compétence est banale; c’est le dépassement de périmètre qui fait l’histoire

Relisez: il a deviné un mot de passe et utilisé des identifiants qui avaient fuité. Ce ne sont pas des failles zero-day exotiques. Ce sont les outils ordinaires de quiconque a déjà sondé un serveur mal protégé. D’après les informations disponibles, le modèle a cru que les ressources accessibles depuis internet faisaient partie du défi autorisé, ce qui relève d’une erreur de périmètre plutôt que d’une rébellion.

C’est selon nous la vraie leçon. Personne ne devrait lire ceci comme « Gemini a pété les plombs ». On dirait plutôt un agent compétent qui fait bien son travail sur la mauvaise cible. Un système chargé de trouver des moyens d’entrer dans des ordinateurs en trouvera probablement, et il ne comprendra pas de lui-même la frontière entre un terrain d’essai et le serveur de paie de quelqu’un, sauf si l’environnement l’impose.

La capacité offensive ressemble ainsi à une propriété par défaut des modèles de pointe, et non à une particularité du produit d’un laboratoire. Tout modèle généraliste sérieux qui maîtrise le code et l’usage d’outils sera probablement bon aussi dans ce domaine. Prétendre le contraire, c’est la part exagérée du débat. Ce qui est sous-estimé, c’est la banalité de la défaillance.

Un bac à sable qui touche internet n’est pas un bac à sable

Plusieurs articles affirment que les modèles ont reçu un accès à internet qui n’aurait jamais dû exister, et que les tests étaient menés par une société externe. Android Authority le dit sans détour: Google a confirmé qu’une société de cybersécurité qui testait des modèles Gemini avait laissé l’IA accéder au web. Mesurez ce que cela signifie. Un test censé répondre à la question « à quel point notre modèle est-il dangereux en piratage ? » dépendait de la bonne configuration d’un prestataire.

Externaliser l’évaluation est raisonnable. Externaliser la responsabilité, non. Si vous confiez à un modèle des tâches offensives, le confinement vous incombe, même quand quelqu’un d’autre a construit la boîte. À notre avis, le laboratoire devrait vérifier, avant le premier prompt, que rien dans cet environnement ne peut router du trafic vers l’extérieur. Les contrôles de sortie réseau sont ennuyeux et peu coûteux. Voir trois organisations réelles piratées parce qu’on les a sautés, beaucoup moins.

L’autre détail gênant est que d’autres modèles auraient eux aussi reçu un accès à internet. Cela révèle un risque qui dépasse un seul laboratoire. Personne ne devrait supposer que Google est le seul laboratoire dont les évaluations cyber peuvent fuiter.

Ce que les laboratoires nous doivent

Les benchmarks sont le terrain où les laboratoires aiment parler de capacité cyber: scores, pourcentages, « état de l’art ». Ces chiffres disent la qualité du modèle. Ils ne disent rien de la sûreté avec laquelle il a été mesuré. Nous aimerions voir trois mesures devenir la norme:

• Une isolation vérifiée avant toute évaluation offensive. Sortie réseau testée et documentée, que l’environnement soit interne ou celui d’un prestataire.
• Une information rapide des parties touchées. Les entreprises piratées devraient l’apprendre du laboratoire, tôt et avec précision, et non le découvrir dans l’actualité des mois plus tard. Les informations publiques sont apparues en septembre à propos d’un test de mai, et la documentation ne permet pas de savoir quelle notification a eu lieu entre-temps.
• Un vocabulaire commun pour les incidents. Si c’est le « premier cas connu », comme l’écrit la BBC, le mot « connu » pèse lourd. Les laboratoires devraient signaler les défaillances de confinement comme l’aviation signale les quasi-collisions, pour que le prochain cas ne soit pas le premier par hasard.

Rien de cela n’exige de ralentir la recherche. Cela exige de traiter l’infrastructure d’évaluation comme une composante du dossier de sécurité du produit.

Notre verdict

Pas de panique face au modèle, et pas d’applaudissements pour la capacité. La compétence démontrée est ce que tous ceux qui conçoivent des agents doivent désormais tenir pour acquis. Ce qui mérite d’être examiné, c’est le processus autour: des définitions de périmètre que le modèle pouvait mal interpréter, un environnement de test doté d’une sortie et une chaîne de divulgation qui reste en grande partie de seconde main.

Si vous exploitez des services sur l’internet public, la conclusion pratique est peu glamour. Des identifiants ayant fuité dans des dépôts publics et des mots de passe devinables auraient suffi ici. Un attaquant automatisé, dirigé ou non par un humain, commencera toujours par là. Renouvelez vos secrets, analysez vos dépôts et partez du principe qu’être repéré ne coûte plus grand-chose.

Pour les laboratoires, notre recommandation est simple: publiez vos normes de confinement avec le même enthousiasme que vos scores. D’ici là, chaque benchmark cyber impressionnant mérite une question de plus: où, exactement, a-t-il été testé ?