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...
La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.
Envoyé par Mister Nono
