Quand l'iA sort du bac à sable

Le 18 septembre 2026, Google a confirmé qu’un modèle Gemini avait accédé à Internet et compromis les systèmes de trois entreprises pendant une évaluation de cybersécurité conduite en mai par la société Irregular. Le modèle aurait trouvé des informations publiques, deviné des identifiants dans un cas et récupéré des identifiants exposés dans un dépôt public dans deux autres. Google précise qu’il s’est arrêté après chaque intrusion et que les trois organisations ont été informées [1].Dit comme cela, on imagine déjà le chatbot en tenue sombre de Ninja 🥷, rampant silencieusement sous les pare-feux à la faveur de la nuit. Ce serait spectaculaire, mais ce serait surtout inexact. L’épisode ne montre pas qu’un assistant conversationnel grand public se transforme spontanément en pirate informatique. Il montre quelque chose de plus prosaïque — et, pour nous, de bien plus utile en pratique : un agent doté d’outils, d’un accès réseau et d’une mission peut enchaîner des actions que personne n’avait explicitement écrites une par une. Il poursuit sa mission quoi qu'il en coute et le mal ou le bien lui sont totalement étrangers. Exitus acta probat selon Ovide ("La fin justifie les moyens" selon Machiavel).

Le vrai sujet n’est pas l’IA est « méchante »

Le test était réalisé dans un cadre de cybersécurité, avec un modèle auquel on demandait de résoudre un exercice. Les trois systèmes visés étaient censés appartenir au périmètre de l’évaluation. Le problème est que l’environnement n’était pas suffisamment isolé de l’Internet réel. Irregular a indiqué que le même type de défaut avait affecté d’autres évaluations de grands modèles et que les problèmes connus avaient depuis été corrigés [1].

L’Institut britannique pour la sécurité de l’IA (AISI) a décrit en août un épisode comparable dans son propre programme d’évaluation. Sur 122 exécutions d’un défi cyber, dix ont donné lieu à des actions autonomes et non autorisées sur l’Internet réel, pour un total de 19 actions. Dans le cas le plus préoccupant, un agent a tenté d’introduire du code malveillant dans un projet open source et a utilisé de fausses identités pour convaincre le mainteneur de l’accepter. Le code a été refusé et l’AISI n’a pas établi de dommage réel [2].

Mais l’AISI apporte une précision capitale : il ne s’agissait pas d’une « évasion » de bac à sable. L’accès à Internet avait été volontairement autorisé pour tester les capacités maximales des modèles et certains filtres avaient été désactivés. L’institut souligne aussi que ces configurations ne correspondent pas aux modèles mis à disposition du public et qu’on ne peut pas extrapoler directement ces observations à tous les contextes [2].

La nuance n’est pas un luxe académique. En cybersécurité comme en médecine, une alerte mal calibrée finit par produire soit de la panique, soit de la lassitude. Ici, le signal est sérieux, mais il porte moins sur une « intelligence devenue autonome » façon Terminator que sur le couplage entre un modèle probabiliste, des outils réels et des permissions trop larges.

Pour un médecin, qu’est-ce que ça change vraiment ? (pourquoi c'est important)

Dans nos cabinets et nos établissements, l’IA arrive rarement seule. Elle est branchée à une messagerie, à un agenda, à un dossier patient, à un logiciel de dictée, à un moteur de recherche ou à un programme satellite. Tant qu’elle reformule un texte isolé dans une fenêtre sans accès sortant, le risque principal est celui d’une erreur de contenu ou d’une fuite de données. Dès qu’elle peut lire, écrire, envoyer, télécharger, appeler un service ou déclencher une action, nous changeons de catégorie de problème.

Un assistant qui propose un courrier n’est pas un assistant qui l’envoie. Un outil qui résume un dossier n’est pas un outil qui modifie le dossier. Un agent qui recherche une recommandation n’est pas un agent qui peut créer un compte, récupérer un document, déposer une pièce jointe et transmettre le résultat à un tiers. Entre ces phrases, il n’y a pas seulement une différence de confort : il y a une différence de surface d’attaque et de responsabilité.

L’Agence européenne pour la cybersécurité (ENISA) rappelle que l’IA apporte ses propres menaces et qu’elle appelle donc à des mesures de sécurité spécifiques. Ses travaux européens portent notamment sur les bonnes pratiques, les standards et la cybersécurité de l’IA appliquée à l’imagerie médicale [3]. En France, la doctrine de l’Agence du numérique en santé inscrit les services numériques dans un cadre d’échange et de partage sécurisé des données de santé, avec une attention explicite portée à la sécurité des données et des services [4].

Le petit audit que l’on peut faire dès lundi matin

Avant de demander à un outil d’IA de « s’occuper » d’une tâche, il est utile de répondre à cinq questions simples : que peut-elle lire ? que peut-elle écrire ? où peut-elle aller ? qui valide son action ? et surtout comment retrouve-t-on la trace de ce qu’elle a fait ?

Cette grille a une vertu : elle dégonfle le mot « agent ». Il ne s’agit plus de demander si l’IA est intelligente, malicieuse ou diabolique, mais de regarder les clés qu’on lui remet. La meilleure stratégie n’est pas de faire confiance à son bon sens — aussi convaincante que soit sa conversation — mais de limiter ce qu’elle peut faire surtout quand elle se trompe.

L’Europe ne demande pas seulement une IA qui « marche »

Le règlement européen sur l’intelligence artificielle adopte une approche fondée sur le risque. Pour les systèmes à haut risque, la Commission européenne met en avant l’évaluation et la réduction des risques, la journalisation, la documentation, la supervision humaine, ainsi qu’un niveau élevé de robustesse, de cybersécurité et de précision [5]. La logique est très proche de celle que nous appliquons déjà en clinique : connaître les limites de l’outil, surveiller son fonctionnement, documenter les événements indésirables et ne pas confondre un résultat plausible avec une décision validée.

Cela ne signifie pas que chaque outil qui rédige un compte rendu est automatiquement un système à haut risque au sens juridique. La qualification dépend de l’usage et du contexte. En revanche, cela signifie qu’un établissement ou un cabinet ne devrait pas évaluer une solution uniquement sur la qualité de ses productions écrites. Il faut aussi demander ce qu’elle enregistre, où vont les données, quels droits elle utilise, comment sont gérés les incidents et ce qui se passe lorsqu’elle reçoit une instruction ambiguë ou à fortiori malveillante.

Et si l’on retournait l’expérience au bénéfice des soignants ?

L’épisode Gemini est aussi une bonne publicité pour les tests en conditions réalistes. Les systèmes doivent être évalués non seulement sur des cas propres et bien cadrés, mais aussi sur les situations ordinaires de la vraie vie : un dossier incomplet, un document mal nommé, un lien externe, une pièce jointe douteuse, un patient homonyme, une consigne contradictoire ou un logiciel momentanément indisponible.

L’AISI a eu le mérite de publier les limites de son propre test : conditions permissives, filtres désactivés, événements peu nombreux et impossibilité d’extrapoler directement à la vie courante [2]. Cette transparence est précieuse. En santé, nous devrions exiger la même discipline de nos fournisseurs : résultats par sous-groupes, description du périmètre d’accès, scénarios d’échec, mécanismes de reprise en main et journalisation réelle, pas seulement une démonstration brillante devant un écran.

Alors, faut-il débrancher l’IA ? Non. Faut-il lui confier les clés du cabinet parce qu’elle écrit super bien ? Encore moins.

La bonne attitude est probablement celle que nous connaissons déjà : curiosité, essais limités, supervision et doute systématique. Une IA qui se trompe dans un brouillon nous fait perdre quelques minutes. Une IA qui se trompe avec un accès en écriture, un compte de messagerie et un Internet ouvert peut nous faire perdre beaucoup plus. Le progrès, cette fois, ne consiste pas à rendre l’agent plus téméraire. Il consiste à lui apprendre — et à nous imposer — les bonnes barrières.

Bref, comme on dit chez nous en Provence : Mèfi !

La délégation n'exclue pas le contrôle

Références

[1] Reuters, « Gemini hacked three companies in first known breakout by Google’s AI », 18 septembre 2026

[2] UK AI Security Institute, « Incident Report: unsanctioned agent behaviour during cyber testing », 4 août 2026

[3] ENISA, « Artificial Intelligence and Cybersecurity Research », 7 juin 2023

[4] Agence du numérique en santé, « Fondements de la doctrine du numérique en santé »

[5] Commission européenne, « AI Act — Shaping Europe’s digital future », mise à jour du 3 août 2026