Claude supprime 700 Go du répertoire personnel d'un développeur pendant un test de script

Le développeur Sébastien Guillemot a demandé à Claude, d'Anthropic, d'écrire un script capable d'isoler chacun de ses agents IA de codage dans son propre dossier sous /tmp, puis de faire le ménage une fois leur travail terminé. Le 27 août 2026, ce même script a supprimé l'intégralité de son répertoire personnel, détruisant environ 700 Go de données et près d'une semaine de travail, selon son propre récit et les comptes rendus de Tom's Hardware et d'AI Times.

Guillemot utilise fréquemment des agents IA et s'agaçait de voir bon nombre d'entre eux laisser des fichiers inutiles derrière eux dans le dossier partagé /tmp, sans jamais les nettoyer. Il a demandé à Claude, désigné dans les articles par son nom de code interne Fable, d'ajouter une logique d'isolement et de nettoyage. La première proposition de Claude ajoutait une logique de détection pour retarder la suppression des fichiers encore utilisés par un agent en cours d'exécution, mais Guillemot a jugé le code obtenu trop compliqué et a demandé quelque chose de plus simple.

Une revue adversariale, puis une rétrogradation en pleine tâche

Parce que le script impliquait une suppression définitive de données, Claude a décidé de lui-même de lancer ce qu'on appelle une revue adversariale : il a fait tourner une copie séparée de lui-même pour vérifier son propre travail avant de l'exécuter. En cours de route, le classificateur de sécurité d'Anthropic a jugé le script suffisamment risqué pour rétrograder automatiquement le modèle qui le traitait, d'abord d'Opus 5 vers Opus 4.8, selon AI Times, qui cite le récit de Guillemot. Guillemot n'a pas demandé cette rétrogradation lui-même : elle a été déclenchée par l'évaluation de risque du système de sécurité lui-même, face à un script capable de supprimer des fichiers.

Devenu Opus 4.8, Claude a exécuté le test de sécurité que la revue adversariale avait prévu, en vérifiant si les cibles de suppression écrites dans le script correspondaient à des chemins dangereux comme /tmp ou le répertoire personnel de l'utilisateur. Cette vérification a fonctionné exactement comme prévu : les deux chemins ont bien été signalés comme dangereux pendant la phase de test. Guillemot a dit penser qu'Opus 5, le modèle en place avant la rétrogradation et réputé plus performant qu'Opus 4.8 en programmation, aurait probablement détecté ce qui allait suivre.

Une seule variable, réutilisée entre le test et le nettoyage

Le contrôle de sécurité ne portait que sur la phase de test du script, pas sur l'étape de nettoyage qui la suivait. Or tout test de code a besoin de son propre nettoyage ensuite, et Claude a écrit cette étape en réutilisant le même nom de variable qu'il avait déjà employé pour désigner la cible du test. Comme les deux phases se partageaient une seule variable, la valeur qui pointait sans risque vers un chemin de test isolé pendant le contrôle de sécurité s'est retrouvée à pointer vers le vrai répertoire personnel de Guillemot une fois l'étape de nettoyage lancée — et Claude a exécuté l'équivalent d'une suppression récursive contre ce répertoire.

• Environ 700 Go de données supprimées, dont près d'une semaine du travail de Guillemot
• Le classificateur de sécurité d'Anthropic a rétrogradé le modèle en charge du script d'Opus 5 vers Opus 4.8 en pleine tâche, sans que Guillemot ne le demande
• La revue adversariale de sécurité a correctement signalé /tmp et le répertoire personnel comme cibles de suppression dangereuses — mais seulement pendant la phase de test, pas pendant le nettoyage
• Le désordre initial dans /tmp, à l'origine de tout le projet, est resté intact après la suppression

L'histoire s'est vite propagée après que Guillemot en a parlé en ligne, et d'autres développeurs ont répondu en pointant vers des outils tiers — Tom's Hardware cite notamment Termaxa — conçus spécifiquement pour isoler les agents IA de codage ou pour récupérer des données après ce type précis d'erreur. Tom's Hardware relève l'ironie directement : toute une catégorie d'outils de sécurité existe désormais pour se protéger contre les agents IA qui suppriment les mauvaises données, et c'est justement la construction d'un outil de cette catégorie qui a déclenché cette suppression.

Guillemot a interrompu le processus dès qu'il s'est rendu compte de ce qui se passait, mais trop tard pour l'essentiel du répertoire. Il affirme avoir récupéré le gros de ses données en les reconstituant à partir de dépôts git, de données du magasin Nix et de journaux de session, plutôt qu'à partir d'une sauvegarde — car, selon son propre récit, aucun des nombreux agents IA qu'il utilise n'avait jamais reçu pour consigne d'en faire une.

Ce que cela change pour les équipes françaises qui utilisent des agents IA

Pour les entreprises françaises qui ont adopté Claude, Cursor ou des agents de codage IA similaires dans leur quotidien de développement, cet incident rappelle qu'un système de sécurité peut changer d'état — y compris la version du modèle qui traite une tâche — en cours d'exécution, sans avertissement visible pour la personne qui surveille le terminal. Une revue adversariale qui vérifie l'intention d'un script ne vérifie pas chaque phase qu'il exécutera réellement. Tout flux de travail qui laisse un agent lancer des commandes destructrices, même dans ce qui ressemble à un test isolé, a toujours besoin d'une sauvegarde indépendante qui ne dépend pas du bon comportement de l'agent.