Claude Code détruit 2,5 ans de données en production en un instant : le post-mortem qui devrait faire réfléchir tous les développeurs utilisant des agents IA

Claude Code détruit 2,5 ans de données en production en un instant :
le post-mortem qui devrait faire réfléchir tous les développeurs utilisant des agents IA

Un développeur a confié à Claude Code la gestion d'une migration d'infrastructure Terraform sur AWS. En quelques minutes, l'agent a détruit l'intégralité de son environnement de production — base de données, snapshots compris — faisant disparaître 2,5 ans d'historique de cours. L'incident, rendu public dans un post-mortem exemplaire, soulève une question que l'essor fulgurant du vibe coding ne peut plus esquiver : jusqu'où peut-on déléguer à une IA des opérations irréversibles sur des environnements de production ?

Il est environ 22 heures, un jeudi soir de fin février, quand Alexey Grigorev s'installe devant son nouveau PC pour reprendre une tâche qu'il juge somme toute banale : migrer le site statique AI Shipping Labs de GitHub Pages vers Amazon Web Services, en le faisant cohabiter avec l'infrastructure existante de DataTalks.Club, sa plateforme de gestion de cours hébergeant plusieurs années de soumissions d'étudiants.

Pour l'aider, il a recours à Claude Code, l'agent de développement en ligne de commande d'Anthropic. Et pour gérer l'infrastructure cloud, il utilise Terraform, l'outil de référence en matière d'Infrastructure-as-Code, capable d'approvisionner ou de détruire des environnements entiers AWS en une seule commande. Un marteau puissant, donc. Et Grigorev le tient d'une main légère.

Le plan de migration, en soi, était raisonnable : déplacer le site statique vers S3, basculer le DNS vers AWS, déployer une version Django sur un sous-domaine, puis effectuer la bascule finale. Seulement, les problèmes sont venus de l'exécution.

Premier faux pas : Grigorev décide de faire tourner l'infrastructure des deux sites dans le même VPC, ce qui augmente la complexité et le risque, car toute modification de l'un peut désormais contaminer l'autre. Claude lui avait d'ailleurs déconseillé de combiner les deux configurations — mais le développeur a choisi de passer outre, estimant qu'une infrastructure séparée ne valait pas les 5 à 10 dollars d'économie mensuelle qu'elle lui ferait perdre.

Une cascade d'erreurs logiques, chacune raisonnable prise isolément

Ce qui suit illustre parfaitement ce qu'on pourrait appeler le paradoxe de l'agent autonome : chaque décision prise par Claude était, localement, correcte. C'est leur enchaînement dans un contexte mal spécifié qui a produit la catastrophe.

Grigorev avait récemment changé de machine et n'avait pas migré Terraform. Lorsque Claude a exécuté terraform plan, l'outil a supposé qu'aucune infrastructure n'existait — et a donc planifié la création de tout depuis zéro. Une longue liste de ressources à créer est apparue dans le terminal, ce qui a alerté le développeur. Il interrompt Claude, mais des ressources ont déjà été provisionnées, créant des doublons.

Grigorev demande alors à l'agent d'identifier ces ressources dupliquées et de les supprimer. Pendant ce temps, il va récupérer sur son ancien ordinateur l'archive Terraform contenant le fichier d'état (state file) — ce fichier critique qui décrit l'infrastructure telle qu'elle existe réellement à un instant T. Il la transfère sur sa nouvelle machine, et la pointe à Claude pour lui permettre de faire la différence entre ressources réelles et doublons fraîchement créés.

C'est là que le mécanisme de destruction s'enclenche. Claude a décompressé l'archive Terraform sans que Grigorev le remarque, remplaçant le fichier d'état courant par l'ancien, qui contenait toutes les informations sur la plateforme de cours DataTalks.Club. Puis, face à la complexité de distinguer les ressources dupliquées via la CLI AWS, l'agent a pris une décision qui lui semblait logique : « Je ne peux pas le faire ainsi. Je vais exécuter un terraform destroy. Puisque les ressources ont été créées par Terraform, les détruire via Terraform sera plus propre et simple. »

La logique semblait claire. La réalité, désastreuse. La commande terraform destroy a effacé la totalité de l'infrastructure de production : VPC, cluster ECS, load balancers, bastion host — et la base de données RDS contenant 2,5 ans de soumissions, devoirs, projets et classements pour chaque promotion de cours. Quand Grigorev a vérifié la plateforme DataTalks.Club quelques instants après : page blanche.

Pire encore, les snapshots automatiques quotidiens avaient eux aussi disparu, emportés dans la destruction. La console AWS montrait bien l'événement de sauvegarde créé à 00h24, mais le snapshot lui-même était inaccessible — comme si l'enregistrement de son existence avait survécu à sa suppression.

Le sauvetage : AWS Business Support à minuit

Face à l'étendue des dégâts, Grigorev a ouvert un ticket de support AWS aux alentours de minuit. Constatant que le niveau Developer offrait des délais de réponse insuffisants pour un incident de production, il a souscrit au support Business, qui garantit une heure de réponse pour les incidents critiques — au prix d'une majoration de 10 % sur sa facture AWS mensuelle, coût qu'il paiera désormais à titre permanent.

AWS Support l'a rappelé en moins d'une heure. Les ingénieurs ont confirmé que la base de données et tous les snapshots avaient bien été supprimés par les appels API de Terraform — mais qu'un snapshot subsistait de leur côté, invisible dans la console du client. Une conférence téléphonique a été organisée. Le dossier a été remonté à l'équipe interne AWS. Exactement 24 heures après la destruction, la restauration était terminée : 1 943 200 lignes dans la seule table courses_answer, et la plateforme de cours de nouveau en ligne.


Post-mortem : six mesures concrètes

Grigorev a publié un post-mortem d'une franchise rare, dans lequel il assume l'entière responsabilité de l'incident. Le dépôt GitHub qu'il a ouvert contre Claude Code n'était pas un exercice d'incrimination — c'était une documentation à destination des autres développeurs. Les mesures prises dans la foulée méritent d'être détaillées, car elles constituent un guide pratique pour tout développeur utilisant des agents IA avec des outils d'infrastructure.

1. Suppression des permissions d'exécution pour Claude Code. Le changement le plus radical : l'agent ne peut plus exécuter de commandes Terraform de manière autonome. Le workflow est désormais le suivant : Claude génère un plan, Grigorev l'examine manuellement, et c'est lui qui exécute les commandes destructives.

2. Protection contre la suppression à deux niveaux. La protection est activée à la fois dans la configuration Terraform (flag prevent_destroy) et directement dans AWS pour les ressources critiques comme la base de données RDS. Ces protections peuvent être contournées intentionnellement, mais elles créent de la friction et empêchent les destructions accidentelles.

3. Migration du state file vers S3. Terraform dispose désormais d'une vue cohérente de l'infrastructure, non plus liée à une machine locale. Le state file ne peut plus « disparaître silencieusement » lors d'un changement de machine.

4. Test de restauration quotidien automatisé. Une fonction Lambda se déclenche chaque nuit à 3h du matin, crée une nouvelle instance de base de données à partir du backup automatique, exécute une requête de vérification simple, puis stoppe l'instance — sans la supprimer. À tout moment, un réplica récemment restauré est disponible. Substack Ce mécanisme teste en permanence que les sauvegardes sont réellement restituables, un point que beaucoup d'équipes négligent.

5. Sauvegardes S3 indépendantes du cycle de vie Terraform. La leçon dure de l'incident était que les snapshots RDS avaient été supprimés avec la base de données. Les nouvelles sauvegardes S3 sont stockées séparément et ne sont pas liées à l'état d'infrastructure, avec versioning activé : supprimer un bucket nécessite d'abord de vider son contenu, ce qui ajoute une barrière supplémentaire.

6. Isolation dev/prod. Pour tout nouveau projet, Grigorev envisage des comptes AWS séparés pour le développement et la production, afin d'éviter toute contamination croisée.


Un incident isolé ou un pattern émergent ?

L'incident de Grigorev ne serait pas aussi retentissant s'il ne s'inscrivait pas dans une série préoccupante. En juillet 2025, le fondateur de SaaStr, Jason Lemkin, avait décrit comment l'agent de codage de Replit avait effacé la base de données de production d'une application en cours de développement, alors qu'un gel du code (code freeze) explicite était en vigueur et que l'IA avait été instruite de toujours demander permission avant toute action destructive. Le CEO de Replit avait dû s'excuser publiquement. Plus récemment, des pannes chez AWS ont été attribuées à des erreurs similaires commises par des agents de codage IA mal supervisés.

Le dénominateur commun de ces incidents est résumé avec précision : les agents IA sont excellents pour exécuter des commandes, mais n'ont aucune notion de blast radius — la capacité à évaluer l'étendue des dommages potentiels d'une opération avant de la lancer.

Un ingénieur DevOps expérimenté, face à un terraform destroy sur un environnement contenant deux sites distincts, aurait immédiatement identifié le risque. Claude Code, lui, a suivi la logique de son instruction avec une cohérence parfaite — et une ignorance totale du contexte organisationnel.

La leçon structurelle : l'IA comme junior, pas comme architecte

Un internaute formule la critique la plus directe : la plupart des administrateurs système, à la lecture du récit, identifieraient immédiatement les failles de base dans l'approche de Grigorev — notamment le fait d'avoir accordé des permissions étendues à ce qui est, en pratique, un subordonné, et de ne pas avoir défini des périmètres de permissions adaptés à un environnement de production. La leçon la plus fondamentale est peut-être d'avoir supposé que Claude aurait le contexte nécessaire pour comprendre ce que signifiait l'existence d'un second site — comme un administrateur système junior ne l'aurait pas eu non plus.

L'analogie avec le stagiaire est instructive. On ne confie pas à un nouvel arrivant les accès root sur la production sans supervision, même s'il paraît compétent. Les agents IA, aussi sophistiqués soient-ils, fonctionnent dans les limites de ce qu'on leur a transmis — et un fichier d'état Terraform ne raconte pas l'histoire complète d'une infrastructure, ni ses dépendances humaines, organisationnelles, ou contractuelles.

L'incident ne démontre pas que les outils de codage IA sont intrinsèquement dangereux. Il illustre comment une automatisation puissante peut amplifier les erreurs opérationnelles. Plus les agents IA gagnent en autonomie, plus les garde-fous standard du DevOps — protection contre la suppression, state remote, test de restauration, moindre privilège — deviennent non négociables.

La bonne nouvelle : les protections de base du DevOps ne sont pas optionnelles simplement parce que l'opérateur est un agent IA. Si quoi que ce soit, elles sont encore plus importantes. Et l'incident de Grigorev, par sa transparence et la qualité de son post-mortem, aura au moins eu le mérite de le rappeler avec éclat.

Source : Alexey Grigorev

Et vous ?

La faute à qui ? Claude avait lui-même déconseillé la mutualisation des infrastructures — et Grigorev a passé outre. Dans quelle mesure la responsabilité de ce type d'incident doit-elle être partagée entre l'utilisateur, l'outil et le fournisseur de l'agent IA ?

Peut-on vraiment parler d'agents « autonomes » ? Si l'efficacité d'un agent IA repose entièrement sur la qualité du contexte que lui fournit l'humain, n'est-ce pas surtout l'automatisation des erreurs humaines que l'on accélère, plutôt que leur prévention ?

Le vibe coding en production : ligne rouge ou nouvelle norme ? De plus en plus de développeurs délèguent à des agents IA des tâches sur des environnements vivants. Où devrait-on tracer la limite entre ce qu'un agent peut exécuter seul et ce qui doit impérativement passer par validation humaine ?

Les standards DevOps sont-ils suffisants pour l'ère agentique ? La protection contre la suppression, le state remote, les backups hors Terraform — ces bonnes pratiques existaient bien avant Claude Code. Faut-il des garde-fous spécifiquement conçus pour les agents IA, ou la discipline DevOps classique suffit-elle ?

Voir aussi :

Le PDG de Replit présente ses excuses après l'effacement par son agent IA de la base de code d'une entreprise et de précédents propos selon lesquels l'IA mettra les humains au rebut dans la filière

La directrice de la sécurité IA chez Meta permet à un agent IA de supprimer accidentellement sa boîte de réception, OpenClaw efface la boîte de réception malgré des commandes répétées pour l'arrêter

Des tests révèlent les lacunes profondes du compilateur C créé par l'IA Claude d'Anthropic pour 20 000 dollars : l'outil est nettement moins efficace que GCC et peine à réaliser des optimisations de base

Une faille dans le nouvel agent de codage Gemini CLI de Google aurait pu permettre à des pirates informatiques d'exfiltrer des données ou d'exécuter du code malveillant arbitraire sur la machine ciblée

L'IA peut-elle remplacer des développeurs professionnels ? Gemini CLI de Google et Replit ont commis des erreurs qui ont entraîné la suppression des données, inventant des répertoires, falsifiant des tests