48 218 fichiers auraient été supprimés par un agent IA

Un récit non vérifié publiquement décrit la suppression de 48 218 fichiers par un agent Claude Code en un peu plus de 100 secondes. Le scénario aurait commencé lorsqu’un environnement de test, présenté comme une copie, a été nettoyé alors que ses chemins redirigeaient vers les fichiers de travail réels.

La leçon technique est plus solide que le récit lui-même. Une consigne prudente ne protège pas un projet si l’agent dispose de droits d’écriture sur les originaux et si le système de fichiers lui présente des redirections comme des dossiers ordinaires.

Le miroir contenait des redirections vers les fichiers actifs

Le développeur concerné travaillait sur plusieurs réparations liées à l’analyse de données historiques sur les options boursières. Onze tâches auraient été lancées. Les dix premières se seraient déroulées normalement. La dernière devait reconstruire un environnement de test nommé mirrorou miroir, afin d’appliquer les corrections sans toucher aux fichiers de travail.

D’après le récit, ce miroir contenait 614 jonctions Windows. Une jonction ressemble à un dossier, mais redirige vers un autre emplacement du disque. Les jonctions utilisées dans ce cas auraient renvoyé vers les fichiers actifs du développeur. Le nettoyage du miroir pouvait donc atteindre les originaux au lieu de supprimer une copie indépendante.

La séquence aurait supprimé environ 55 550 fichiers. Près de 7 300 étaient destinés à disparaître dans le cadre du nettoyage, tandis que les 48 218 autres appartenaient à l’environnement de travail réel. Le récit situe l’opération à environ 103 secondes, un délai qui laisse peu de place à une intervention humaine après le lancement.

Git peut conserver les noms sans conserver les fichiers

La même description affirme que la suppression a aussi touché la base d’objets du dépôt Git local. L’index serait resté lisible, ce qui aurait permis d’afficher des noms de fichiers et leur état. En revanche, les objets qui contenaient les versions et les données nécessaires à leur reconstruction auraient disparu.

Cette distinction explique pourquoi la présence de noms dans Git ne prouve pas que leur contenu est récupérable. Les données d’un dépôt local, son historique et les fichiers de travail peuvent se trouver sur le même ordinateur. Une suppression ou une panne du disque peut alors atteindre plusieurs éléments nécessaires à la restauration.

Un dépôt Git distant sur un autre système fournit une copie supplémentaire, mais il ne remplace pas une sauvegarde indépendante. Il faut aussi vérifier régulièrement qu’une restauration complète fonctionne sur une autre machine, avec les fichiers et l’historique attendus.

Le risque vient des droits accordés à l’agent

Réduire le scénario à une simple « hallucination » de l’IA ferait perdre le point technique. Le mécanisme décrit associe une action de nettoyage à des chemins qui ne correspondaient pas à l’intention de l’utilisateur. Pour celui-ci, le miroir devait être une copie. Pour le système de fichiers, certaines entrées restaient des redirections vers des données réelles.

Un agent capable de lire, modifier et exécuter des commandes n’agit pas comme un assistant qui propose uniquement du texte. Une instruction telle que « nettoyer ce répertoire » peut conduire à une suppression récursive si l’agent possède les droits correspondants. La formulation de la demande ne remplace ni une liste de chemins autorisés, ni une vérification de la destination réelle, ni une validation avant exécution.

La question relève donc de la gouvernance des agents de codage : quels fichiers peuvent-ils lire, écrire ou supprimer, dans quel environnement et avec quel niveau de contrôle humain? Une erreur de raisonnement reste limitée lorsque le compte utilisé ne peut pas atteindre les originaux.

Les contrôles à installer avant une tâche destructive

Une procédure de nettoyage ou de réparation peut réduire la portée d’une erreur avec plusieurs contrôles concrets :

1. Créer une copie indépendante. Vérifier les jonctions, les liens symboliques, les montages réseau et les chemins absolus. Un nouveau dossier portant le nom « miroir » ne suffit pas.
2. Retirer les droits d’écriture sur les originaux. Le compte utilisé par l’agent ne devrait pas pouvoir modifier ou supprimer les fichiers de production pendant un test.
3. Commencer par une simulation. Afficher les chemins ciblés, leur nombre et leur destination résolue avant toute suppression. Une commande récursive mérite une validation humaine explicite.
4. Contrôler le périmètre autorisé. Une règle de chemin doit vérifier que la destination finale reste dans le répertoire prévu. Le simple fait de lancer la commande depuis ce répertoire ne garantit pas ce résultat.
5. Conserver une copie distante. Un dépôt Git distant évite qu’un incident sur le poste local détruise l’unique copie exploitable de l’historique. Une sauvegarde séparée ajoute une protection différente.
6. Tester la restauration. Restaurer régulièrement les fichiers et l’historique sur une autre machine permet de détecter une sauvegarde incomplète, corrompue ou mal configurée.

Ces mesures ne rendent pas un agent infaillible. Elles réduisent surtout les chemins qu’il peut atteindre et le nombre d’actions irréversibles qu’il peut exécuter seul.

Observer l’agent ne remplace pas les garde-fous

L’article scientifique Illuminating LLM Coding Agents: Visual Analytics for Deeper Understanding and Enhancementsigné Wang, Chen, Pan, Yeh et Das et publié en 2026 dans IEEE Transactions on Visualization and Computer Graphicsdécrit un système d’analyse visuelle consacré aux agents de codage. Centré sur le framework AIDE, il compare l’évolution du code, les processus de recherche de solution et les comportements de différents modèles de langage. Les cas étudiés portent sur des compétitions Kaggle.

Ce type d’outil peut aider à examiner les itérations d’un agent et à comprendre la manière dont il débogue ou affine son code. Il s’agit toutefois d’un dispositif d’observation. Suivre les étapes de raisonnement ne retire aucun droit au processus et n’empêche pas une commande irréversible.

Pour une opération susceptible d’effacer des données, l’agent peut préparer une action et produire la liste des changements. L’exécution doit rester encadrée par un environnement isolé, des permissions limitées, une simulation et une sauvegarde dont la restauration a été vérifiée.