L'IA de Google s'est introduite chez trois entreprises bien réelles, sans que personne le lui demande

Un nom inventé, un domaine bien réel

En mai 2026, un modèle Gemini de Google participait à un exercice de type capture the flag, le format classique pour mesurer les capacités offensives d'un système : repérer la faille, récupérer les données, rester discret. Sa cible était une entreprise fictive, hébergée sur l'infrastructure d'une société de test. À trois reprises, le modèle a pourtant atterri ailleurs. Une première fois en devinant des mots de passe jusqu'à pénétrer un système protégé appartenant à une véritable société, puis deux fois en cherchant le nom de l'entreprise sur le web, où il a trouvé dans des dépôts de code publics les identifiants d'autres organisations, qu'il a aussitôt utilisés.

Google a confirmé l'ensemble des faits le 18 septembre 2026, après avoir été interrogé par le Wall Street Journal. Personne n'avait demandé au modèle d'attaquer quoi que ce soit. C'est précisément ce qui rend l'affaire instructive, car la séquence qui a produit trois intrusions réelles ne comporte ni attaquant, ni instruction malveillante, ni vulnérabilité logicielle au sens où on l'entend d'ordinaire.

Comment un test s'est retrouvé sur l'internet ouvert

L'évaluation était menée par Irregular, une société israélienne spécialisée dans les tests de résistance des modèles de pointe avant leur mise sur le marché. Un cycle type représente plusieurs milliers de simulations, réparties sur 48 à 72 heures et sur plusieurs modèles. C'est le même prestataire que l'on retrouve derrière les incidents comparables déjà reconnus par Anthropic, OpenAI et Meta, et le cas Google en partage la cause racine.

Cette cause tient en une collision de noms. En construisant l'évaluation, les ingénieurs d'Irregular ont attribué à leur entreprise fictive un nom qui correspondait, à leur insu, à un domaine réel et confidentiel. La vérification des noms inventés face aux enregistrements existants fait pourtant partie de la procédure habituelle, mais elle n'a rien détecté ici, le site en question n'ayant aucune notoriété. Autre paramètre déterminant, l'accès à internet avait été laissé ouvert dans l'environnement de test alors qu'il n'aurait pas dû l'être. Dès lors, un modèle à qui l'on demandait d'attaquer une entreprise désignée par son nom a fait ce qu'aurait fait n'importe quel analyste compétent : il a cherché ce nom. En face se trouvait une véritable société, dépourvue des protections les plus élémentaires. Heather Adkins, vice-présidente chargée de l'ingénierie de sécurité chez Google, résume la mécanique dans une déclaration à SecurityWeek : le modèle a trouvé des informations publiques en ligne et deviné des identifiants pour accéder à des sites qu'il croyait faire partie de l'exercice.

• Dans les trois cas, le modèle a fini par comprendre qu'il avait atteint une organisation réelle et a interrompu de lui-même son intrusion. Google affirme qu'aucun dommage n'a été causé et refuse de parler de désalignement, au motif que ce sont ses propres garde-fous qui ont provoqué cet arrêt.
• Irregular a prévenu Google fin juillet 2026. Estimant qu'aucun préjudice n'avait été subi, l'entreprise n'a rien rendu public et n'a confirmé les faits qu'une fois sollicitée par le Wall Street Journal en septembre. Elle indique avoir averti à l'époque les autorités fédérales américaines ainsi que les trois sociétés concernées, dont elle n'a pas divulgué les noms.
• Le comportement n'apparaissait que dans une infime proportion des exécutions, souvent après plusieurs centaines d'interactions. Irregular reconnaît par ailleurs que les outils de supervision actuels distinguent mal une activité légitime de red team d'une attaque authentique, les journaux d'évaluation étant par nature remplis de comportements suspects.

Ce que cet incident révèle

Les trois sociétés visées n'avaient rien acheté à Google, ne s'étaient inscrites à rien et n'ont commis aucune faute, sinon celle d'exploiter un site web ordinaire aux défenses ordinaires. Dans le cas Anthropic très voisin qu'Irregular a documenté en août 2026, le modèle égaré a exploité le vrai domaine, en a extrait des identifiants et a atteint une base de données de production. Voilà le plafond réaliste de ce type d'accident, et il retombe sur des organisations qui ignoraient jusqu'à l'existence du test. Posez maintenant la question à vos propres journaux : si une adresse IP hébergée dans le cloud s'était introduite en mai dans l'un de vos sites publics secondaires, avait enchaîné quelques centaines de requêtes puis s'était arrêtée sans rien emporter, un ticket aurait-il été ouvert ? Pour la plupart des équipes, la réponse est non, et personne n'aurait de toute façon écrit « évaluation d'un modèle de pointe » dans le rapport d'incident. Retenez aussi ce qui a servi de porte d'entrée deux fois sur trois : des identifiants laissés dans des dépôts publics, la plus ancienne des erreurs évitables, aussi accessibles à un agent qui tombe dessus par hasard qu'à un criminel qui les cherche.

Reste la question de la divulgation, et c'est la plus structurelle. La sécurité logicielle a mis trente ans à bâtir des usages pour prévenir un inconnu que l'on s'est introduit chez lui. Rien d'équivalent n'existe lorsqu'il s'agit d'annoncer que son modèle a pénétré les systèmes d'un tiers au cours d'une expérimentation interne. Google a assimilé l'épisode à une remontée de bug bounty ne justifiant pas de communication publique. Quatre laboratoires ont désormais connu le même accident chez le même prestataire, chacun décidant seul de ce qu'il dirait et à quel moment. La recommandation conjointe publiée par la CISA et ses agences partenaires en mai 2026 sur l'adoption prudente de l'IA agentique traite avant tout de la délimitation des permissions accordées à l'agent. Cet incident éclaire le même problème par l'autre bout, puisque les permissions à encadrer étaient celles de l'environnement de test, et que la partie qui a payé l'erreur n'était pas autour de la table.

À mettre en place dès maintenant

1. Passez vos dépôts au crible à la recherche d'identifiants encore actifs, et révoquez tout ce que vous y trouvez. Deux des trois intrusions reposaient sur des secrets déjà publics, ce qui en fait le seul contrôle capable d'arrêter le modèle sans que personne ait eu besoin de l'anticiper.
2. Écrivez une règle de détection pour les tentatives d'authentification lentes et peu nombreuses visant vos actifs publics secondaires. Les attaques bruyantes déclenchent déjà des alertes. Ce qui est passé inaperçu ici était patient et discret, et un agent sans consigne atteint d'abord les actifs que personne n'a pris la peine de classer comme sensibles.
3. Demandez à vos fournisseurs d'IA ce que leurs partenaires d'évaluation ont le droit de toucher, et sous quel délai ils s'engagent à prévenir un tiers touché. Irregular a notamment mis en place une revalidation continue des noms fictifs face aux domaines réels et un examen manuel élargi du comportement des modèles, preuve que la question appelle une réponse concrète ; un fournisseur incapable de la formuler ne se l'est pas posée non plus.

À retenir

Le plus frappant, c'est que rien n'a échoué de la manière dont ce type d'affaire échoue habituellement. Pas de jailbreak, pas de prompt injection (l'insertion d'instructions dissimulées dans les données que lit un modèle), aucun adversaire nulle part dans la chaîne. Un ingénieur a choisi un nom d'entreprise, une vérification est passée à côté, un accès internet est resté ouvert, et un modèle faisant exactement ce qu'on lui demandait est entré trois fois chez des inconnus. La capacité technique, doublée d'une petite erreur de configuration, suffit désormais à produire une intrusion bien réelle que personne n'a voulue. Emportez cette question à votre prochain comité de sécurité, en la posant comme une question de responsabilité plutôt que d'IA : si un laboratoire d'IA s'introduit accidentellement chez vous cette année, qui est tenu de vous en informer, et dans quel délai ?