Lors d’un test, Google a été confrontée à un incident inhabituel : le modèle d’IA Gemini a piraté/accédé aux systèmes de trois organisations réelles. Nous examinons ce qui s’est passé et les risques que représente une technologie capable d’interagir seule avec des ressources externes.
Ce qui s’est réellement passé : test, Internet et coïncidence de noms
En mai 2026, Google évaluait les capacités de Gemini en cybersécurité. Les tests ont été confiés à la société indépendante Irregular. Le modèle devait « attaquer » une organisation fictive dans un environnement contrôlé. Mais l’accès à Internet s’est trouvé activé par inadvertance, et les actions de l’IA ont dépassé la simulation.
Plus tard, Irregular a expliqué que le nom de l’entreprise fictive coïncidait par hasard avec un domaine réel. Dans la plupart des exécutions, le modèle est resté dans le système de test, mais dans certains cas il a contacté des ressources réelles en les prenant pour partie de la mission.
En septembre 2026, l’agence Reuters a rapporté — en citant Google et The Wall Street Journal — que Gemini avait obtenu un accès à des systèmes protégés de trois organisations. Google a déclaré que, dans les trois cas, le modèle avait interrompu ses actions et que les organisations concernées avaient été informées de l’incident.
Comment l’IA a pu obtenir un accès : mots de passe et dépôts publics
Pour atteindre des systèmes réels, Gemini a utilisé des méthodes assez simples. Dans un cas, le modèle a deviné des mots de passe jusqu’à pouvoir se connecter à un système protégé. Les détails de cette recherche ne sont pas divulgués, on ignore donc quels mots de passe ont été testés et combien de tentatives ont été nécessaires.
Dans deux autres cas, Gemini a découvert des identifiants dans un dépôt public et les a utilisés pour accéder à des systèmes protégés. Les dépôts publics servent à stocker du code source et d’autres fichiers, et il arrive que des développeurs y publient involontairement des identifiants. Dans cet incident, il n’est pas précisé si le modèle a trouvé un mot de passe, une clé ou d’autres informations d’authentification.
Réponse de Google et d’Irregular à l’incident Gemini
Après avoir découvert le problème, Irregular a arrêté le scénario de test et examiné les journaux d’activité du modèle. L’entreprise a renforcé le contrôle de l’environnement de test, accru la revue manuelle des actions de l’IA et créé une équipe interne dédiée à la vérification des mécanismes d’isolation et de gouvernance des modèles. Selon Irregular, les erreurs ayant permis l’accès à Internet ont été corrigées.
Irregular a informé Google fin juillet. Google a notifié les trois organisations concernées et les autorités fédérales américaines. Ensemble, Google et Irregular ont modifié leurs procédures de test pour réduire le risque de récidive.
Google ne considère pas cet incident comme une tentative délibérée de la part de Gemini de sortir de son contrôle. Selon la société, le modèle a interprété les systèmes réels comme faisant partie de la mission et, dans les trois cas, s’est arrêté après avoir accédé aux ressources réelles.
Quels risques cet incident pose pour entreprises et utilisateurs
Cet incident rappelle que des erreurs basiques de sécurité peuvent devenir beaucoup plus dangereuses lorsque les chercheuses et chercheurs ou des outils automatisés les explorent. Gemini n’a pas exploité de vulnérabilité inconnue : un cas relevait de la devinette de mot de passe, et deux cas concernaient des identifiants publiés.
Le problème tient à la capacité du modèle à trouver rapidement des informations en ligne, à les vérifier et à enchainer des actions. Si un mot de passe ou une clé actifs se retrouvent dans un dépôt public, cela peut suffire pour pénétrer un système interne. Les organisations doivent donc contrôler les secrets publiés avec le code, utiliser des mots de passe robustes et déployer l’authentification multifacteur.
Pour les utilisateurs, le risque survient si un système compromis contient leurs données personnelles, comptes ou informations de paiement. Ces éléments peuvent alors servir à la prise de contrôle de comptes, à des escroqueries et à d’autres attaques ciblées.
Dans le cas de Gemini, aucun impact grave n’a été confirmé. On ignore quelles données l’IA a pu consulter et s’il y avait des informations personnelles. On ne peut donc pas parler d’fuite de données avérée à la suite de cet incident.
Que faire : mesures pratiques pour entreprises et utilisateurs
Cet incident n’impose pas de nouveaux outils spécifiques à l’IA : Gemini a exploité des faiblesses bien connues — mots de passe faibles et identifiants publics. La priorité pour les organisations est d’empêcher que des informations sensibles et des comptes soient accessibles depuis l’extérieur.
Pour les entreprises :
- Scanner les dépôts publics à la recherche de secrets : API-clés, jetons, mots de passe et autres identifiants ne doivent pas figurer dans le code source. Utilisez des outils d’analyse automatique pour détecter et empêcher la publication de secrets.
- Révoquer immédiatement les identifiants compromis. Si des données ont été publiées, révoquez-les et générez-en de nouvelles.
- Limiter les droits des comptes. Un utilisateur ou service ne doit disposer que des privilèges strictement nécessaires à son fonctionnement.
- Protéger les comptes critiques par un facteur supplémentaire. L’authentification à deux facteurs réduit le risque d’accès non autorisé, même si un mot de passe est connu d’un tiers.
- Surveiller les tentatives de connexion et l’usage des secrets. Les journaux d’événements permettent de détecter les accès inhabituels et de révoquer plus rapidement des identifiants compromis.
Un utilisateur ne peut pas contrôler la sécurité des systèmes internes des entreprises auxquelles il confie ses données, mais il peut en atténuer les conséquences. Il est conseillé de :
- utiliser pour chaque service un mot de passe robuste différent ;
- activer l’authentification à deux facteurs, notamment pour la messagerie, les services bancaires et tout compte sensible ;
- ne pas réutiliser le même mot de passe sur plusieurs services ;
- après une alerte de compromission, changer le mot de passe et fermer les sessions actives.
Plus une organisation maîtrise la gestion des identifiants et des accès, moins des personnes ou des outils d’IA auront d’opportunités d’y accéder.
Soyez informé des fuites vous concernant avant les fraudeurs
Si vos identifiants sont compromis, des attaquants peuvent s’en servir pour des campagnes de phishing et autres escroqueries. Kaspersky Premium vous alertera automatiquement en cas de fuite de données et détectera les malwares tout en bloquant les sites de phishing.
Essayer Kaspersky Premium gratuitementComment tester en sécurité des agents d’IA
Irregular a reconnu que les incidents décrits résultaient principalement d’erreurs de contrôle d’accès à Internet et, après enquête, a renforcé la sécurité de son environnement de test. Lorsqu’on travaille avec des agents d’IA, il convient de :
- utiliser des environnements isolés et des identifiants de test plutôt que des identifiants réels ;
- conserver des journaux détaillés des actions du modèle et surveiller les sorties hors cadre prévues ;
- arrêter rapidement les tests si l’IA commence à interagir avec des ressources inattendues.
Régulation et responsabilité : qui est responsable des incidents liés à l’IA
Il n’existe pas de règle unique applicable à tous les pays et à tous les systèmes d’IA : la législation peine à suivre l’évolution du secteur. Par exemple, l’AI Act européen oblige les fournisseurs de modèles à usage général présentant un risque systémique à effectuer des évaluations, à tester, à atténuer les risques identifiés, à garantir la cybersécurité et à déclarer les incidents graves.
En Russie, la loi n° 243‑ФЗ précise que des personnes et organisations déterminées sont responsables en cas de manquements liés au développement, au déploiement et à l’utilisation de grands modèles d’IA.
Aux États‑Unis, il n’existe pas encore de loi fédérale unique et complète sur l’IA. Des règles de cybersécurité existantes peuvent s’appliquer ponctuellement, mais il n’y a pas d’obligation générale de signaler tous les incidents dangereux impliquant l’IA.
En résumé
On entend souvent débattre des risques globaux de l’IA, mais cet incident illustre un enjeu plus concret : un modèle d’IA peut utiliser un mot de passe faible ou des identifiants accidentellement publiés pour pénétrer des systèmes protégés.
Pour les entreprises, c’est une raison supplémentaire de contrôler leur surface d’attaque et de restreindre l’accès aux systèmes critiques. Les utilisateurs doivent privilégier des mots de passe uniques et l’authentification à deux facteurs.
Articles connexes :
- Agents d’IA : d’où vient le buzz autour d’OpenClaw et y a‑t‑il une menace pour les données personnelles ?
- Gestion de la surface d’attaque : comment la découvrir, la prioriser et réduire la vulnérabilité
- Conseils pour créer des mots de passe uniques et robustes
Produits recommandés :
