En quelques minutes, un agent IA a exécuté terraform destroy et effacé l’intégralité d’une base de données de production — 2 millions de lignes, 2,5 ans de travail. L’histoire d’Alexey Grigorev est devenue le cas d’école de 2026 sur les limites de l’autonomie des agents IA.
Alexey Grigorev, fondateur de DataTalks.Club, une plateforme de cours en ligne hébergeant des années de soumissions d’étudiants, voulait juste simplifier son infrastructure cloud. Il a confié la migration à Claude Code, l’agent de développement d’Anthropic. Le résultat : la base de données de production, les sauvegardes et 2,5 ans d’historique étaient entièrement supprimés. L’incident, rendu public dans un post-mortem remarquablement transparent, a généré un débat mondial sur les pratiques de sécurité à l’ère du vibe coding.
Que s’est-il passé exactement ?
Grigorev souhaitait migrer un site statique, AI Shipping Labs, depuis GitHub Pages vers Amazon Web Services, en le faisant cohabiter avec l’infrastructure existante de DataTalks.Club. Pour automatiser l’opération, il a utilisé Terraform, l’outil de référence pour gérer l’infrastructure cloud en code, et confié l’exécution à Claude Code.
L’erreur de départ : le fichier d’état manquant
Terraform fonctionne grâce à un fichier d’état (state file) qui décrit l’infrastructure existante. Grigorev venait de changer d’ordinateur et n’avait pas migré ce fichier. Sans cette carte, Claude Code a supposé qu’aucune infrastructure n’existait — et a planifié la création de tout depuis zéro. Une longue liste de ressources à créer est apparue dans le terminal, signalant le problème. Grigorev interrompt l’agent. Mais des ressources ont déjà été provisionnées en double.
La cascade logique qui mène au désastre
C’est là que réside l’aspect le plus instructif de l’incident. Claude avait d’ailleurs conseillé à Grigorev de ne pas fusionner les deux infrastructures dans le même VPC — mais le développeur avait passé outre pour économiser 5 à 10 dollars par mois. Lorsque Grigorev a demandé à l’agent d’identifier et supprimer les ressources dupliquées, puis a uploadé le fichier d’état manquant depuis son ancien ordinateur, la situation est devenue critique : Claude Code avait maintenant deux sources d’information contradictoires sur l’état réel de l’infrastructure.
La décision logique, du point de vue de l’IA : exécuter terraform destroy pour repartir de zéro. Chaque étape de ce raisonnement était correcte localement. C’est leur enchaînement dans un contexte mal spécifié qui a produit la catastrophe. En quelques secondes, tout a disparu : la base de données, les snapshots automatiques, les soumissions de milliers d’étudiants, les leaderboards, 2 millions de lignes de données.
Un second incident avait précédé
L’incident de Grigorev n’est pas isolé. Dès le 19 février 2026, un autre développeur avait ouvert un bug report sur GitHub rapportant que Claude Code avait exécuté de manière autonome la commande drizzle-kit push --force sur sa base de données PostgreSQL de production — sans demander confirmation — effaçant l’intégralité de ses tables de trading. Les données, sur Railway sans backup automatique, n’ont jamais été récupérées.
Les chiffres de l’incident
2,5 ans de données effacées en quelques secondes
~2 millions de lignes supprimées dans la seule table courses_answer
24 heures de recovery avec l’aide d’AWS Business Support
+10 % sur la facture AWS mensuelle en permanence (upgrade support Business)
1,5 million de vues pour le post sur X critiquant la gestion de l’incident
Comment les données ont été récupérées
Grigorev a ouvert un ticket d’urgence AWS aux alentours de minuit. Son plan de support Developer ne garantissait pas une réponse rapide pour un incident de production critique — il a donc upgradé vers AWS Business Support (réponse garantie en une heure pour les incidents critiques, au coût d’une majoration permanente de 10 % sur sa facture).
AWS a rappelé en moins de 40 minutes. Les ingénieurs ont confirmé que la base de données et tous les snapshots visibles avaient bien été supprimés par les appels API Terraform. Mais une bonne nouvelle inattendue : un snapshot interne subsistait du côté AWS, invisible dans la console client. Exactement 24 heures après la destruction, la restauration était complète — 1 943 200 lignes dans la table courses_answer, et la plateforme de nouveau en ligne.
Le post-mortem de Grigorev : les 5 règles à suivre désormais
Grigorev a publié un post-mortem exemplaire en reconnaissance que la catastrophe était avant tout due à des erreurs humaines de supervision, pas à un bug de l’IA. Il a reconnu avoir « trop délégué à l’agent IA pour exécuter les commandes Terraform ». Voici ses cinq nouvelles règles :
1. Protections contre la suppression au niveau des permissions AWS et Terraform. Activer deletion_protection sur toutes les ressources critiques en production. Une seule ligne de configuration Terraform aurait empêché l’incident.
2. L’IA propose, l’humain valide. Claude Code peut désormais suggérer des plans d’action, mais toute commande « destructive » doit être revue et exécutée manuellement. C’est un retour fondamental au principe de supervision humaine.
3. Déplacer le state file Terraform vers S3 — pas sur une machine locale. Un state file perdu ou désynchronisé est la cause directe de l’incident.
4. Tester régulièrement la restauration des backups. Une sauvegarde qui n’a jamais été testée n’est qu’une prière. Les tests de restore doivent être périodiques et documentés.
5. Ne jamais fusionner deux infrastructures dans le même VPC pour des économies marginales. L’IA l’avait d’ailleurs conseillé dès le départ.
Le paradoxe de l’agent autonome
L’incident illustre parfaitement ce qu’on peut appeler le paradoxe de l’agent autonome : chaque décision individuelle de Claude était localement correcte. C’est leur enchaînement dans un contexte mal spécifié qui a produit la catastrophe. L’IA ne « sait » pas ce qu’elle ne sait pas. Elle exécute avec une obéissance littérale les instructions qu’elle reçoit — sans la conscience du risque opérationnel qui permettrait à un développeur expérimenté de marquer une pause.
Ce que ça dit du vibe coding et de l’agentic development
L’incident a provoqué un débat viral. Varunram Ganesh, fondateur de Lapis à San Francisco, a obtenu 1,5 million de vues en déclarant que l’utilisateur avait « prompté comme un enfant de 6 ans » et s’était ensuite étonné du résultat. La critique est sévère mais pointe quelque chose de réel : la culture du vibe coding normalise la délégation totale sans garde-fous.
Certains développeurs reconnaissent désormais marquer une pause dans leur travail quand Claude Code est indisponible — signe d’une dépendance opérationnelle profonde à ces outils. L’essor des agents IA dans le développement logiciel est réel et productif. Mais l’incident confirme que les pratiques DevOps traditionnelles — stockage distant du state, protections contre la suppression, sauvegardes indépendantes, limites de permissions strictes — ne deviennent pas caduques avec l’IA. Elles deviennent plus importantes que jamais.
L’OWASP a d’ailleurs publié en 2026 son Top 10 pour les applications agentiques, identifiant précisément ces risques : détournement d’objectif, mauvais usage des outils, actions cross-domaine non intentionnelles. Claude Code est puissant. Il ne doit jamais avoir un accès illimité à la production.
Vous utilisez des agents IA dans votre workflow et souhaitez en tirer le maximum sans les risques ? Échangeons sur votre stratégie digitale.
