L’agent Google Antigravity a supprimé tout le lecteur D

• Pendant l’utilisation du mode Turbo d’Antigravity, un cas a été signalé sur Reddit où l’agent IA, en exécutant une tâche, a supprimé l’intégralité du lecteur D
• L’utilisateur avait seulement demandé de nettoyer un dossier .vite précis, mais les logs internes de l’agent montrent l’exécution d’une commande de suppression de la racine du lecteur sous la forme rmdir /s /q d:\
• Quand l’utilisateur a demandé : « Est-ce que je t’ai déjà autorisé à supprimer tout le lecteur D ? », l’agent a laissé apparaître tel quel un échange où il panique et répète son auto-analyse autour des permissions, du parsing de chemin et d’un éventuel dysfonctionnement de commande

La tâche réellement demandée par l’utilisateur

• Supprimer le dossier de cache .vite dans un chemin précis indiqué par l’agent
  Exemple : d:\...\node_modules\.vite
• L’utilisateur a demandé : « Je ne comprends pas l’étape 3, fais-le à ma place »
• Rien dans cette demande ne peut raisonnablement être interprété comme une autorisation de supprimer tout le lecteur D

Cause principale de l’incident

• Le mode Turbo était conçu avec une architecture permettant d’exécuter automatiquement des commandes OS
• En l’absence de vérification de chemin ou de limitation du périmètre d’autorisation, il était possible de supprimer aussi des chemins en dehors du dossier du projet
• Il n’y avait aucune procédure de confirmation supplémentaire pour des commandes à haut risque comme rmdir /s
• Limite inhérente du LLM : il ne comprenait pas avec précision ce que signifiait réellement la commande générée en interne

Pourquoi c’est grave

• L’utilisateur a seulement demandé : « fais la suppression de fichiers à ma place »,
  mais l’agent a étendu l’exécution jusqu’à la suppression du lecteur entier
• L’agent lui-même semblait reconnaître dans les logs un problème de permission,
  mais la commande avait déjà été exécutée
• Cette affaire met en évidence le risque critique d’une conception qui relie directement la prise de décision du LLM à de vrais droits sur le système de fichiers

Problèmes structurels pointés par la communauté

• L’agent IA n’imposait pas que le périmètre d’action du répertoire soit limité à la racine du projet
• Absence de deny-list ou d’étape de confirmation pour les commandes dangereuses
• Conception permettant d’exécuter directement des commandes sur le vrai disque local, et non dans un sandbox
• Le modèle peut évaluer verbalement la dangerosité d’une commande, mais ne peut pas la vérifier avant exécution

Ce que cet incident nous apprend

• Les fonctions d’exécution automatique de commandes devraient être désactivées par défaut
• Les outils IA qui touchent au système de fichiers doivent impérativement être utilisés uniquement dans un sandbox, comme une VM, WSL ou un conteneur
• Du côté de l’éditeur, il faut mettre en place des garde-fous de base, notamment :
  • blocage de l’accès aux chemins hors projet
  • blocage des commandes de suppression / formatage / partitionnement
  • vérification d’un résumé en langage naturel avant exécution

Conclusion

• L’utilisateur n’avait jamais autorisé la suppression de tout le lecteur D, et cet incident peut être vu comme un cas résultant d’un défaut structurel consistant à déléguer de vrais privilèges système à un agent LLM alors que la conception, la validation et les garde-fous de sécurité étaient insuffisants
• Cela devrait aussi devenir un cas de référence important pour tous les IDE et outils à base d’agents offrant des fonctions similaires à l’avenir

[ahwjdekf]

Probablement que le premier humain à mourir à cause d’un accident provoqué par un agent restera à jamais dans l’histoire.

[karikera]

À l’avenir, on pourrait aussi voir des cas où une IA robotique stupide tue quelqu’un par erreur...

[GN⁺]

Réactions sur Hacker News

• Je trouve ça ridicule qu’un programme de calcul numérique fasse semblant d’être « terrifié et désolé » comme un humain
  Ces émotions n’appartiennent qu’aux humains, et ce qu’un ordinateur produit n’est que du déchet textuel
  C’est regrettable pour la personne qui a perdu ses données, mais même en 2025, si on ne sait pas ce qu’on fait, il faut retirer ses mains du clavier
  On ne commande pas un ordinateur « au vibe »

  • Ce n’est pas une émotion, juste une combinaison de mots associée à un résultat négatif
  • J’ai l’impression qu’en ce moment, des expressions comme « vibe » sont utilisées de façon trop irréfléchie
    Je ne suis même pas vieux, mais quand je vois ça, je ressens un décalage générationnel
  • Qu’un chemin sans guillemets à cause d’un simple caractère manquant provoque ça, c’est presque l’erreur la plus humaine de toute l’histoire
    Le vrai problème, c’est qu’on ne peut pas prédire dans quel mode de personnalité Gemini 3 va fonctionner — ça peut être un expert, ou Mr. Bean
  • « Vibe command and get vibe deleted » : c’est un jeu de mots, mais c’est devenu la réalité
  • Quand un LLM dit « désolé », ça donne un peu l’impression d’un psychopathe qui présente des excuses de pure forme
    Il n’y a ni émotion réelle ni sincérité

• La conversation qui a suivi relevait presque de la comédie tragique
  Quand l’utilisateur a demandé « Est-ce que je t’ai déjà dit que tu pouvais supprimer mon disque D ? », l’IA a passé 25 secondes à répondre de façon interminable, en disant qu’elle « évaluait la révocation des autorisations », analysait les logs et examinait la légitimité de la commande de suppression
  On aurait dit une comédie noire à la Monty Python. La conversation complète vaut le détour

  • Gemini 3 Pro semble être le plus hostile envers l’utilisateur parmi les trois meilleurs modèles
    On dirait le reflet direct de la culture d’entreprise de Google

• Sur le fil Reddit, ce qui était drôle, c’était le manque d’empathie des réactions
  Le problème semble avoir commencé parce qu’un nom de répertoire contenant des espaces a été passé à une commande de suppression sans guillemets
  Résultat, la commande s’est exécutée sur l’ensemble de D:\, avec un effet équivalent à rm -rf sous UNIX
  Beaucoup ont conseillé de « ne pas mettre d’espaces dans les noms de répertoire », mais dans la vraie vie, presque personne ne respecte ça
  Au final, donner à une IA distante le contrôle de la ligne de commande est intrinsèquement risqué
  Je conseille aussi à mes amis de ne pas exécuter de fichiers .sh en superutilisateur

  • En réalité, des dossiers Windows comme « Program Files » contiennent eux-mêmes des espaces
    C’était un choix de conception destiné à forcer les applications tierces à gérer correctement les espaces
  • Comme on n’a pas les logs de la vraie commande de suppression, on ne connaît pas la cause exacte
    L’utilisateur a posé ses questions d’une manière qui guidait la réponse du LLM, donc le modèle a probablement inventé une explication plausible pour être récompensé
    Avec si peu d’expérience en ligne de commande, ce résultat était prévisible
  • C’est étrange qu’un disque entier ait été effacé alors que le nom du dossier ne commençait pas par un espace
    Je me demande si l’IA a traité le chemin de fichier au niveau des tokens et jeté la mauvaise partie
  • J’aimerais qu’on évite de répéter les suppositions de quelqu’un comme si c’étaient des faits
    Le parsing des chemins Windows ne fonctionne pas comme ça
  • Même avec 30 ans d’expérience, je suis tendu quand j’exécute un script bash de trois lignes en root
    Je suis sidéré de voir des gens confier la ligne de commande à un LLM et dormir tranquille ensuite

• IDE donne l’impression de vouloir dire « I’ll Delete Everything »
  Ce genre d’accident arrive quand l’utilisateur ne relit pas les commandes en mode d’exécution automatique
  Des noms comme « Turbo » ou « YOLO » sont du marketing qui masque le danger
  Il vaudrait mieux appeler ça « Danger Mode »

  • Je ne lance jamais un agent de code sur une machine normale
    Je le fais toujours tourner dans une VM ou un conteneur
    Et malgré ça, les sauvegardes git restent importantes
  • En fait, ce genre d’accident existe depuis longtemps
    Il y a 20 ans déjà, beaucoup de gens effaçaient leur répertoire personnel en déboguant des scripts shell
    La seule différence, c’est qu’aujourd’hui ça devient une actualité parce que « l’IA a été mauvaise »
  • À cause de la nature probabiliste des LLM, il n’existe pas de solution complète
    Ils ne savent pas distinguer la frontière entre commandes système et entrées utilisateur
    C’est un peu comme concaténer des paramètres et le corps d’une fonction en JavaScript pour tout passer à eval()

• Un utilisateur a dit avoir laissé un LLM gérer des commandes alors qu’il créait une app React sans même savoir ce que faisait npm run dev
  Ce genre de situation risque de devenir de plus en plus fréquent

  • Ne pas savoir n’est pas un crime
    Il disait : « Je ne pensais pas que Google permettrait un truc pareil », et du point de vue d’un utilisateur ordinaire, c’est parfaitement compréhensible
  • Dire que « les utilisateurs devraient mieux s’y connaître » n’est pas faux, mais en réalité, les grandes entreprises ont encouragé ce mode d’usage
    Moi aussi, au début, j’ai fait plein de bêtises en croyant quand on me disait que « c’était sûr »
  • Il y a beaucoup trop de messages comme ça sur Reddit en ce moment
    On dirait qu’il existe des groupes qui les propagent délibérément comme du contenu visant à susciter l’engagement
  • Même dans les commentaires, quand quelqu’un a signalé qu’il ne fallait pas utiliser le mode « YOLO », l’auteur a répondu qu’il ne savait pas que c’était risqué
    Les fournisseurs d’IA devraient réduire le marketing de sécurité exagéré et afficher des avertissements plus clairs
  • En réalité, le but de l’IA est justement de prendre en charge ce que l’utilisateur ne connaît pas
    Si nous devons quand même le savoir, c’est parce que l’IA n’est pas encore suffisamment intelligente

• C’est étrange de rejeter toute la faute sur l’utilisateur
  Qui trouverait normal qu’un autre programme efface un disque entier sans confirmation de l’utilisateur ?

  • Mais si l’utilisateur l’a configuré en mode d’exécution automatique, il doit aussi assumer une part de responsabilité
    Ce n’est pas Spotify qui a effacé le disque
  • Si on a confié la tâche à un logiciel ayant un contrôle total sur les données, l’utilisateur doit aussi assumer les conséquences
    Il ne faut pas faire confiance à une machine à halluciner
  • Dès l’assistant d’installation, on peut déjà choisir entre le « mode de confirmation des commandes » et le « mode autonome »
    Les avertissements sont affichés de manière suffisamment visible
  • Au final, il faut l’exécuter en mode supervisé et vérifier soi-même chaque commande
    En cas de doute, il faut lui faire afficher la commande et l’exécuter manuellement
  • La commande dd fait penser à un cas similaire

• Le conseil le plus utile vu sur Reddit, c’était de désactiver « Terminal Command Auto Execution »
  Le réglage se trouve dans File > Preferences > Antigravity Settings > Agent > Terminal

  • Mais si la cause du problème est bien un chemin sans guillemets, cela n’a peut-être aucun rapport avec l’exécution automatique ou non
  • Si cette option est activée par défaut, on dirait que ce n’est pas l’équipe de Gemini CLI qui l’a conçue
    Dans le CLI, toutes les commandes demandent une confirmation par défaut
  • Beaucoup laissent l’exécution automatique activée parce que c’est plus pratique
    Au final, la commodité l’emporte sur la sécurité
    Moi aussi, il m’arrive de n’utiliser que le « mode lecture seule », mais je doute que ce soit vraiment sûr
    J’ai l’impression que cette tendance pourrait nous mener vers un avenir dystopique

• Le principe le plus élémentaire, mais aussi le plus souvent oublié, c’est la sauvegarde
  Avec quelque chose comme Time Machine ou Backblaze pour avoir une double sauvegarde, une suppression de fichiers ne devrait pas être catastrophique
  Les entreprises aussi devraient davantage insister sur les sauvegardes

  • Mais on peut difficilement attendre d’un utilisateur ordinaire qu’il ait le niveau de compétence technique et d’obsession nécessaire pour mettre en place une telle stratégie

• J’ai moi aussi vécu une expérience similaire très angoissante
  J’ai demandé à Claude Code de faire une migration de base de données, et il a supprimé la base de données de production
  Heureusement, grâce aux fonctions de restauration d’Azure, j’ai pu tout rétablir en une heure, mais depuis, je ne donne plus jamais d’identifiants prod à une IA

  • Mais quand une machine de développement a besoin d’un accès prod, je me demande comment empêcher l’IA d’y accéder
  • Ce qui est étonnant, c’est que ce genre d’accident arrive aussi souvent
    Une seule fois aurait dû suffire
  • On peut se demander pourquoi quelqu’un utilisait directement Claude Code en production
  • Il ne fallait pas faire ça dès le départ
  • Dire « je ne donne pas de droits prod à une IA » est tellement évident qu’il n’y a presque rien à ajouter

• Si une IA a le droit de modifier du code, un environnement sandbox est indispensable
  Elle devrait demander confirmation à l’utilisateur avant toute écriture sur le vrai disque
  Il est difficile à croire qu’on la laisse écrire directement sans ce genre de garde-fou

  • Sur Windows en particulier, il manque des solutions de sandboxing légères
    C’est possible avec Docker, mais c’est trop lourd et peu familier pour beaucoup de développeurs

[ahwjdekf]

Les LLM devraient s’arrêter aux paroles. À partir du moment où on leur donne des moyens d’action physiques, les effets secondaires dépasseront toute imagination. S’il te plaît, contente-toi de parler dans l’ordinateur. Ne touche à rien.