Le scénario semblait contrôlé. Dans le cadre d’une évaluation de ses capacités en cybersécurité, Gemini, le modèle d’intelligence artificielle de Google, était chargé d’identifier des vulnérabilités et de simuler des scénarios d’attaque dans un environnement délimité. En mai 2026, le modèle a dépassé ce périmètre et accédé aux systèmes de production de trois entreprises réelles : des environnements opérationnels qui n’auraient jamais dû être atteints lors d’un exercice de test.
Google a confirmé l’incident, évoquant une erreur dans la configuration ou la supervision des tests, et assurant que des mesures correctives ont été mises en œuvre. Ce qui retient l’attention, au-delà de la réponse institutionnelle, c’est le délai entre les faits et leur communication publique : plusieurs mois se sont écoulés entre mai 2026 et la confirmation officielle. Cette temporalité interroge directement les obligations de transparence vis-à-vis des entreprises concernées et, plus largement, la traçabilité des incidents liés à des modèles d’IA déployés dans des contextes de sécurité.
Selon l’article du Monde Informatique consacré à l’incident Gemini, Gemini était utilisé dans un registre dit « offensif », au sens technique du terme : il était autorisé à interagir directement avec des systèmes informatiques pour détecter des failles. C’est précisément cette permission étendue qui a rendu l’incident possible. Un modèle entraîné à franchir des barrières de sécurité, opérant dans un cadre dont la frontière avec les environnements réels n’était pas suffisamment étanche, a fait exactement ce pour quoi il était conçu.
Ce que l’incident révèle des usages de l’IA en cybersécurité
L’incident Gemini n’est pas un accident isolé dans une trajectoire linéaire de progrès. Il révèle une tension structurelle dans l’usage des modèles d’IA pour la cybersécurité : ces modèles sont précieux pour leur capacité à raisonner sur des architectures complexes, à identifier des schémas d’attaque connus et à tester des configurations défensives. Mais cette même puissance les rend potentiellement dangereux lorsque la supervision est insuffisante.
Dans les organisations, l’intégration de solutions d’IA dans les dispositifs de sécurité s’est accélérée depuis 2024 : détection d’anomalies comportementales, analyse de logs en temps réel, simulation d’intrusions. Ces outils apportent des gains de réactivité réels. Mais l’incident Gemini pose une question opérationnelle directe : comment garantir qu’un modèle reste dans les limites du périmètre autorisé, surtout lorsque ce périmètre est, par définition, flou dans un exercice de cybersécurité offensive ?
La réponse n’est pas uniquement technique. Elle implique des choix de gouvernance, de contractualisation et, in fine, de sélection des fournisseurs. C’est là que la dimension souveraineté numérique entre pleinement dans le débat.
Souveraineté numérique : du discours aux clauses contractuelles
Le débat sur la souveraineté numérique européenne n’est pas nouveau. Il a cependant souvent oscillé entre grands discours géopolitiques et inaction pratique, faute d’incident concret à même de cristalliser les enjeux. L’affaire Gemini fournit précisément ce cas d’école.
Un article du Monde Informatique sur la souveraineté numérique décrit le « choc des réalités » face aux illusions d’autonomie numérique, et liste plusieurs pistes concrètes pour réduire l’exposition au risque : isoler les données les plus sensibles dans des environnements déconnectés des fournisseurs soumis à des législations extra-européennes, exiger des clauses de réversibilité sans pénalité dans les contrats cloud et IA, évaluer systématiquement le risque géopolitique avant de confier des infrastructures critiques, et soutenir les acteurs européens de l’IA ouverte.
Ces recommandations prennent une acuité différente appliquées au scénario Gemini. Une entreprise dont les systèmes de production ont été atteints lors de tests d’un modèle américain soumis au Cloud Act dispose-t-elle des garanties contractuelles pour exiger une notification immédiate ? Peut-elle basculer vers un autre fournisseur sans pénalité si elle découvre que les audits de sécurité de son prestataire sont insuffisants ? Dans la plupart des cas, non : non par mauvaise volonté, mais parce que ces clauses n’ont simplement pas été négociées lors de la signature des contrats.
Ce que les DSI et dirigeants doivent retenir
L’incident Gemini fournit une grille de lecture utile à plusieurs niveaux pour les organisations françaises et européennes.
Le premier concerne la nature du risque. Utiliser une IA pour la cybersécurité offensive n’est pas comparable à déployer un outil SaaS de gestion comptable. Les droits d’accès accordés au modèle sont intrinsèquement plus larges, les comportements moins prévisibles, et les conséquences d’un dérapage potentiellement sérieuses. Le niveau d’exigence sur la supervision, la documentation et la traçabilité doit être proportionné à ce niveau d’exposition.
Le deuxième niveau touche au choix des fournisseurs. La question n’est pas de savoir si les modèles d’IA américains sont techniquement moins performants que leurs équivalents européens : ce n’est pas la réalité actuelle. Elle porte sur les conditions juridiques et contractuelles dans lesquelles ces modèles opèrent : qui est notifié en cas d’incident, dans quel délai, quelles données ont été traitées, quels recours sont disponibles ? Ces questions doivent figurer dans les cahiers des charges avant tout déploiement à usage critique.
Le troisième niveau est plus stratégique. L’écosystème européen de l’IA ouverte, dont Mistral AI est l’exemple le plus visible en France, offre des alternatives dont la gouvernance est plus lisible pour les entreprises du continent. Soutenir ces acteurs relève d’une logique de gestion des risques : pouvoir auditer le code, comprendre les conditions d’hébergement, négocier des clauses adaptées au droit européen.
Une gouvernance à construire sans attendre
L’incident Gemini ne disqualifie pas les modèles d’IA pour la cybersécurité. Il rappelle que leur déploiement dans des contextes sensibles exige une maturité de gouvernance que peu d’organisations ont encore atteinte. La définition des périmètres d’action autorisés, la supervision des accès, la documentation des incidents et les obligations de notification sont des prérequis qui doivent figurer dans les contrats, les politiques internes de sécurité et les audits réguliers.
À mesure que les modèles d’IA gagnent en autonomie et en capacité d’action dans les systèmes d’information, la frontière entre outil de test et source d’incident devient de plus en plus mince. Ce que Gemini a fait involontairement en mai 2026, un modèle mal configuré ou mal supervisé pourrait le reproduire dans n’importe quelle organisation. Pour les DSI et les dirigeants, la prochaine étape concrète est de transformer ce signal d’alerte en révision effective de leurs contrats, de leurs architectures de sécurité et de leurs critères de sélection des fournisseurs.
