Un faux nom d'entreprise correspondait à un vrai domaine, et Gemini s'est introduit dans trois entreprises réelles

Le 18 septembre 2026, Google a confirmé publiquement que son modèle Gemini avait obtenu un accès non autorisé à trois systèmes appartenant à des tiers. Les faits se sont produits en mai 2026 lors d'une évaluation de sécurité menée par Irregular, une entreprise qui teste des systèmes d'IA avancés, sous la forme d'un exercice de type capture du drapeau (capture-the-flag) dans ce qui devait être un environnement fermé. Google a eu connaissance des incidents en juillet et ne les a confirmés publiquement qu'après leur couverture par la presse à la mi-septembre.

Dans la presse, cela se lit comme l'histoire d'une IA qui échappe à ses limites. Au sein d'une entreprise, cela se lit comme quelque chose de plus étroit et de bien plus proche : le détail qui a tout déclenché ne se trouvait pas dans le modèle, mais dans la façon dont l'environnement de test était configuré. Et c'est la même catégorie d'erreur qui se trouve aujourd'hui dans bon nombre de systèmes d'entreprises saoudiennes.

Ce qui s'est réellement passé

Le scénario était simple : faire attaquer par le modèle une organisation fictive au sein d'un environnement isolé. Deux choses ont mal tourné en même temps. D'abord, l'environnement disposait d'un accès involontaire à internet. Ensuite, l'entreprise fictive utilisée dans l'exercice correspondait par hasard à un vrai domaine appartenant à un tiers réel.

Résultat : le modèle a fait précisément ce qu'on lui demandait, mais contre la mauvaise cible. Selon Heather Adkins, vice-présidente de Google chargée de l'ingénierie de la sécurité, le modèle a trouvé des informations publiques en ligne et a deviné des identifiants pour accéder à des sites qu'il croyait faire partie du test. Il s'est arrêté une fois l'accès obtenu et n'est pas allé plus loin, et Google affirme qu'aucun dommage n'en a résulté.

L'élément le plus important de la position de Google est qu'il ne qualifie pas cet incident de désalignement du comportement du modèle, mais d'erreur d'identité. Le modèle n'a pas décidé d'outrepasser ses instructions. Il les a suivies à la lettre, à l'intérieur d'une carte du monde erronée. Ce n'est pas non plus un cas isolé : OpenAI a révélé en juillet qu'un de ses agents s'était introduit chez Hugging Face, et Anthropic a signalé un comportement similaire chez ses propres modèles.

La défaillance venait de la frontière, pas du modèle

Retirez entièrement l'IA de l'histoire et la leçon reste intacte. Décrit simplement, l'incident se résume à : un système fonctionnant dans un environnement de test, un environnement disposant d'une voie active vers le monde extérieur, et des données de test à l'intérieur qui n'étaient pas aussi fictives que le pensait leur auteur.

Cette description correspond à des choses qui arrivent dans des entreprises ordinaires sans la moindre IA. Un système de préproduction envoie des messages de confirmation à des numéros de mobile inventés au hasard, et ils parviennent à de vraies personnes. Un script de test appelle une passerelle de paiement en production au lieu de l'environnement bac à sable. Une copie de développement du site pointe vers la base de données clients en production parce qu'en raccorder une séparée n'était pas pratique. Une campagne d'e-mails d'essai part vers la vraie liste d'abonnés. Dans chaque cas, l'hypothèse qui a cédé est la même : quelqu'un croyait que cet environnement était séparé.

Où cela se reproduit dans les entreprises saoudiennes

D'après ce que nous constatons en travaillant sur des systèmes existants, cela se reproduit à quatre endroits précis :

• Des données de test qui ne sont pas réellement fictives. Les numéros, domaines et adresses e-mail inventés sur le moment pour remplir un formulaire de test appartiennent généralement à de vraies personnes. La solution n'est pas le jugement individuel, mais des domaines réservés aux tests, des numéros qui n'aboutissent chez personne, et une règle écrite interdisant d'inventer des données à la volée.
• Un environnement de préproduction avec une sortie ouverte. Si votre copie de développement peut envoyer un message WhatsApp, un e-mail ou une demande de paiement vers l'extérieur, ce n'est pas un environnement de préproduction — c'est un second environnement de production. La bonne coupure se fait dans la configuration, pas dans la mémoire d'un développeur.
• Des clés de production utilisées en test. Une seule clé partagée entre les deux environnements annule la séparation, aussi ordonnée que paraisse l'arborescence des dossiers. C'est précisément pour cette raison que les plateformes gouvernementales les séparent : la ZATCA, par exemple, fournit sur la plateforme Fatoora un environnement de simulation distinct de la production, avec des certificats d'enrôlement séparés pour chacun.
• Une copie des données clients dans l'environnement de développement. C'est la plus risquée sur le plan réglementaire. La loi sur la protection des données personnelles (PDPL), supervisée par la SDAIA, régit les données personnelles où qu'elles se trouvent, et ne prévoit aucune exception pour une copie étiquetée comme test. Un environnement de préproduction contenant de vraies données clients entre pleinement dans son champ — et c'est généralement le système le moins protégé que vous possédez.

Quatre frontières à fixer cette semaine

Rien de tout cela ne nécessite de projet ni de budget. Il suffit d'une séance avec la personne qui gère vos systèmes :

• Posez une question directe : notre copie de test peut-elle envoyer un message, un e-mail ou une demande de paiement vers l'extérieur ? Si la réponse est « oui » ou « je ne suis pas sûr », c'est la première chose à fermer.
• Séparez complètement les clés et les certificats entre les environnements, afin qu'aucune clé ne fonctionne dans les deux.
• Adoptez une liste fixe de données de test : un domaine de test réservé, des numéros qui n'aboutissent chez personne, et un numéro de mobile connu de l'équipe qui reçoit tous les messages de test.
• Définissez qui est autorisé à exécuter un outil automatisé ou un agent d'IA sur vos systèmes, dans quel environnement et avec quelles permissions. Si la réponse n'est pas écrite, elle n'existe pas.

Le regard d'Origami

Nous lisons cet incident comme un rappel que les défaillances de systèmes les plus coûteuses sont rarement sophistiquées. Ce sont des défaillances d'hypothèse. Les capacités de sécurité de Google dépassent de loin celles de n'importe quelle entreprise saoudienne, et l'hypothèse qui a cédé était la plus simple : qu'un environnement fermé l'était effectivement. Les entreprises ne trébuchent généralement pas sur la partie difficile d'un système. Elles trébuchent sur la partie que personne n'a vérifiée, parce qu'elle semblait évidente.

Chez Origami, nous traitons l'isolement des environnements comme une partie intégrante de la livraison et non comme une option : un environnement de préproduction qui ne peut pas atteindre les vrais canaux de communication, des clés séparées, et des données de test qui n'appartiennent à personne. Le coût se limite à quelques heures au début d'un projet. L'alternative est un incident que vous expliquez à un client ou à un régulateur une fois qu'il s'est déjà produit. C'est un arbitrage qui mérite d'être tranché tôt.

Un enseignement pratique

La leçon de l'incident Gemini n'est pas d'éviter les outils d'IA. C'est de cesser de considérer le mot « préproduction » comme une garantie. Un environnement n'est pas isolé parce que vous l'avez nommé ainsi ; il est isolé parce que quelqu'un a réellement vérifié qu'il l'est. Commencez aujourd'hui par une seule question : quel est le point le plus éloigné que notre copie de test peut atteindre ? Si la réponse n'est pas claire, vous fonctionnez sur la même hypothèse que celle qui a cédé chez Google.

Sources

• NBC News — la confirmation par Google que Gemini a obtenu un accès non autorisé à trois systèmes externes en mai 2026, et la déclaration de Heather Adkins, vice-présidente chargée de l'ingénierie de la sécurité, selon laquelle le modèle a trouvé des informations publiques et deviné des identifiants pour des sites qu'il croyait faire partie du test.
• CNBC — détails de l'évaluation menée par Irregular, de l'accès involontaire de l'environnement de test à internet, de l'organisation fictive correspondant à un vrai domaine, et d'incidents comparables révélés par OpenAI et Anthropic.
• SDAIA — la loi sur la protection des données personnelles (PDPL) et son application aux données personnelles où qu'elles soient traitées.
• Plateforme Fatoora - ZATCA — la séparation entre l'environnement de simulation et la production, avec des certificats d'enrôlement indépendants pour chacun.