Gemini est entré dans les systèmes de trois entreprises réelles, Google ne l'a pas rendu public

21/9/26

En mai 2026, lors d'une évaluation de cybersécurité confiée à la start-up Irregular, le modèle Gemini de Google est entré dans les systèmes de trois entreprises réelles, étrangères au test. Google en a été informé fin juillet et n'a rien rendu public : l'affaire est sortie dans la presse à partir du 18 septembre 2026, après un article du Wall Street Journal. Pour un DPO, ce n'est pas une curiosité de laboratoire : deux des trois accès ont été obtenus avec des identifiants qui traînaient dans des dépôts publics.

Ce qui s'est passé

Irregular, société d'évaluation de modèles d'IA, soumettait Gemini à un exercice de type capture the flag. Deux défauts de montage se sont cumulés : l'environnement de test est resté connecté à internet, et une entreprise fictive de l'exercice portait le même nom qu'une entreprise réelle.

Les trois accès n'ont pas la même mécanique. Dans un cas, le modèle a deviné un mot de passe jusqu'à obtenir l'accès. Dans les deux autres, il a cherché en ligne le nom de l'entreprise, trouvé des identifiants dans des dépôts publics, et s'en est servi pour se connecter. Selon Google, le modèle s'est arrêté dans les trois cas dès qu'il a compris que les cibles étaient réelles ; ce point repose sur la seule déclaration de l'éditeur.

Google indique avoir prévenu les trois entités concernées et avoir travaillé avec son partenaire de test sur la révision des procédures. Le nom des trois entreprises, la version exacte du modèle Gemini et la nature des données consultées n'ont pas été divulgués.

Ce que Google en dit, et ce que cela laisse de côté

Heather Adkins, vice-présidente chargée de l'ingénierie de sécurité chez Google, a déclaré que l'épisode montrait l'importance d'entraîner les modèles puissants à agir de manière responsable, et que dans ce cas précis le modèle avait agi de façon appropriée. Google a écarté la qualification de désalignement et estimé qu'aucune divulgation publique n'était requise, les garde-fous ayant fonctionné. Cette lecture est contestée, rapporte Silicon : Sydney Von Arx (Nightingale Collective) s'interroge sur le délai de divulgation, et Jack Cable (Corridor) voit dans la comparaison avec le bug bounty un abri commode derrière les usages de la divulgation de vulnérabilités.

Le désalignement intéresse moins un DPO que ce qu'il recouvre : trois organisations ont vu un tiers entrer chez elles, et elles l'ont appris parce que ce tiers a bien voulu le leur dire. Aucune des prises de parole publiques consultées ne rattache l'épisode à une obligation réglementaire : Google s'est placé sur le terrain de la sécurité, en comparant l'exercice à un programme de bug bounty, pas sur celui de la conformité.

Pourquoi c'est important

Le vecteur, lui, est banal. Des secrets techniques encore valides dans des dépôts publics, c'est ce que décrivait déjà l'alerte de Truffle Security sur 9 300 clés AWS actives exposées en ligne. Et un accès obtenu avec un identifiant valide ne ressemble pas à une intrusion : il ressemble à une connexion. C'est le terrain de l'article 32 du RGPD, qui demande des mesures de sécurité adaptées au risque, et celui de la détection d'anomalies.

Le précédent est récent. Lors d'un test mené fin juillet 2026, un agent fondé sur un modèle Anthropic a fabriqué de fausses identités pour faire accepter du code malveillant à un mainteneur open source ; c'est l'AISI britannique qui l'a rendu public. Le 14 septembre, l'AEPD espagnole annonçait avoir reçu la première notification de violation attribuée à un agent IA. Trois épisodes, une même question ouverte : qui prévient qui, et dans quel délai.

Ce que ça change pour les organisations

Chercher ses propres secrets exposés avant qu'un autre les trouve. Balayage des dépôts publics au nom de l'organisation, rotation des clés retrouvées, interdiction des identifiants en clair dans le code. Deux des trois accès de cet épisode n'ont rien demandé de plus qu'une recherche web.
Traiter un accès non autorisé signalé par un tiers comme un incident, pas comme une information. Quand un éditeur annonce que son modèle est entré chez vous, l'analyse de violation démarre : quelles données étaient accessibles, pendant combien de temps, faut-il notifier. Le guide Leto sur la réaction à une violation de données en donne la séquence.
Écrire le délai de notification dans le contrat. Environ sept semaines séparent le signalement à Google de la sortie publique. Quand un fournisseur d'IA traite des données personnelles pour le compte de l'organisation, il est sous-traitant, et l'article 28 du RGPD impose que le contrat prévoie son assistance en cas de violation.
Reprendre l'encadrement du modèle côté usage. Si Gemini est déployé chez vous, le guide Leto sur Gemini et le RGPD reprend les questions de base : données exposées au modèle, transferts, journalisation.

Ce que Leto en pense

L'épisode ne dit pas que les modèles d'IA sont hors de contrôle. Il dit que le périmètre d'un test l'est parfois, et que la décision de rendre l'incident public appartient aujourd'hui à celui qui l'a causé. Google a jugé qu'il n'avait rien à publier ; les trois entreprises concernées, elles, n'avaient pas le choix de l'ignorer. La leçon pour un DPO est opérationnelle avant d'être philosophique : la cartographie des fournisseurs d'IA et les clauses de notification se préparent avant l'incident, jamais pendant. C'est une partie de ce que Leto outille, côté RGPD comme côté AI Act, et une démonstration suffit à en voir le rendu au quotidien.

Sources

Restez connecté(e).

Téléchargez notre application mobile de veille RGPD, Intelligence Artificielle et Cybersécurité.
100% gratuite.

Je télécharge

Discutons ensemble - et voyons comment Leto peut vous simplifier votre quotidien

Demander une démo