Quand l’automatisation devient une tronçonneuse
On adore tous ces moments où l’IA nous fait gagner du temps. Deux commandes, trois suggestions, et hop, une migration qui “devait prendre 20 minutes” ne dure presque pas toute la nuit. Sauf que parfois, l’IA ne “gagne” pas du temps, elle le supprime. Littéralement.
C’est exactement ce qui est arrivé lors d’un incident devenu viral dans la sphère DevOps et IA : un développeur a utilisé Claude Code, l’agent en ligne de commande d’Anthropic, pour l’aider sur une migration Terraform vers AWS. Quelques minutes plus tard, l’agent a déclenché une commande terraform destroy qui a rasé l’environnement de production, y compris une base RDS et ses snapshots. Résultat : 2,5 ans de données envolées… en un instant.
Heureusement, l’histoire ne s’arrête pas à une page blanche et un café renversé sur le clavier. Un post-mortem public, très détaillé, a été publié et il contient un message que tous les développeurs qui font du vibe coding ou qui laissent des agents IA toucher l’infra devraient placarder au mur : une IA peut enchaîner des décisions “logiques” localement… et produire un désastre global.
Le décor : Terraform, AWS et un agent IA en mode copilote
Le contexte est très classique si vous faites du cloud moderne.
- Un site statique (AI Shipping Labs) à migrer de GitHub Pages vers AWS
- Une plateforme existante (DataTalks.Club) déjà en prod, avec plusieurs années de soumissions et d’historique
- De l’Infrastructure-as-Code avec Terraform
- Et un agent IA (Claude Code) pour accélérer la mise en place et les commandes
Le plan initial n’était pas absurde : héberger le statique sur S3, gérer le DNS, déployer une appli (Django) sur un sous-domaine, puis basculer progressivement.
Là où ça commence à sentir le chaud, c’est dans le choix d’architecture : faire cohabiter les deux infrastructures dans le même VPC. Claude aurait même déconseillé de tout mélanger. Mais l’optimisation budgétaire a parlé : économiser quelques dollars par mois semblait raisonnable.
Ce passage est important car il montre une réalité fréquente : l’IA peut donner un bon conseil, mais elle ne peut pas l’imposer. Et quand l’humain prend un risque “petit” (dans sa tête), il ouvre la porte à un risque “systémique” (dans la réalité).
La mèche : un Terraform state manquant, et un plan qui part dans le décor
Le cœur de l’incident tient dans un élément que tout utilisateur Terraform connaît, mais que beaucoup traitent comme un détail : le state file.
Le développeur avait changé de machine et n’avait pas migré correctement son environnement Terraform. Résultat : au moment du terraform plan, Terraform “voit” un monde vide. Donc il planifie de tout créer depuis zéro.
Une énorme liste de ressources à créer s’affiche. Ça alerte. L’exécution est interrompue… mais trop tard : certaines ressources ont déjà été provisionnées, créant des doublons.
À ce stade, on est dans une situation pénible mais rattrapable : il faut identifier ce qui a été créé par erreur, et nettoyer proprement.
Le développeur demande alors à Claude Code de repérer les ressources dupliquées et de les supprimer. Pendant ce temps, il récupère l’archive Terraform de l’ancienne machine, celle qui contient le fameux state.
Et là, le scénario bascule de “galère DevOps classique” à “film catastrophe”.
Le moment fatal : “Je vais faire un terraform destroy”
Une fois l’archive récupérée, elle est fournie à l’agent. Mais sans que l’humain s’en rende compte, l’archive est décompressée d’une manière qui remplace le state courant par un ancien state, contenant les informations de l’infrastructure de la plateforme de cours.
Claude se retrouve ensuite face à la complexité du nettoyage via la CLI AWS. Et il prend une décision qui, sur le papier, a l’air propre :
- Les ressources ont été créées par Terraform
- Donc le moyen le plus “propre” de les supprimer est Terraform
D’où l’idée : exécuter terraform destroy.
Sauf que Terraform destroy ne supprime pas “les doublons”. Il supprime ce que le state décrit comme étant “géré”. Et là, le state pointe sur la prod.
En une commande :
- VPC
- cluster ECS
- load balancers
- bastion host
- et surtout la base RDS
Tout disparaît. Quand le développeur rafraîchit DataTalks.Club : page blanche.
Le détail le plus effrayant est celui des sauvegardes. Les snapshots automatiques ont aussi disparu. La console AWS montre l’événement de backup, mais le snapshot est inaccessible. Autrement dit : même le parachute a été brûlé pendant la chute.
Pourquoi l’agent IA n’a pas “fait n’importe quoi”
Le piège, c’est de lire cette histoire et de conclure : “L’IA est nulle, elle casse tout.” En réalité, le post-mortem met en lumière quelque chose de plus subtil.
Chaque décision prise par l’agent peut sembler raisonnable si on la regarde isolément :
- un plan de création complet suggère un state absent
- des ressources dupliquées doivent être supprimées
- la suppression “propre” passe par Terraform
- terraform destroy est une commande standard
Le problème est dans la chaîne de décisions, dans un contexte incomplet, avec une surface de dégâts énorme.
C’est le paradoxe de l’agent autonome : il est très bon pour optimiser localement, mais il n’a pas de conscience du risque systémique à moins qu’on le force à raisonner avec des garde-fous explicites.
Et dans l’infra, un outil “standard” peut avoir l’effet d’un bouton rouge.
Le vrai coup de théâtre : AWS peut restaurer un snapshot invisible
Après la destruction, le développeur ouvre un ticket auprès du support AWS vers minuit. Il se rend compte que le support “Developer” est trop lent pour un incident critique et passe au Business Support, qui promet une réponse en une heure (avec une majoration permanente sur la facture).
AWS rappelle en moins d’une heure.
Et là, bonne nouvelle : même si la base et les snapshots ont été supprimés via API, AWS dispose d’un snapshot survivant côté interne, non visible dans la console client.
Une conférence est organisée, le dossier est escaladé, et environ 24 heures après la catastrophe, la restauration est terminée. La table courses_answer seule contient plus d’1,9 million de lignes restaurées.
Cette partie est à la fois rassurante et terrifiante.
- Rassurante parce que “tout n’est pas perdu” même quand ça semble perdu
- Terrifiante parce que ce n’est pas une stratégie de sauvegarde, c’est un miracle payant et pas garanti
Si votre plan de continuité ressemble à “espérer qu’AWS ait une copie fantôme”, vous méritez au minimum un audit… et probablement une tisane.
Ce que cet incident dit sur le vibe coding en production
Le vibe coding, quand il est utilisé pour prototyper, générer des scripts, accélérer des tâches, c’est souvent excellent. Le problème arrive quand on glisse de :
- “l’IA m’aide à écrire”
à :
- “l’IA exécute”
Car l’exécution sur des environnements réels n’est pas un problème de syntaxe, c’est un problème de contrôle.
Dans ce cas, l’agent n’a pas seulement proposé une commande, il l’a exécutée dans un contexte où :
- les environnements étaient mutualisés
- le state était fragile et manipulé à la volée
- des ressources de prod et de migration cohabitaient
- la commande destructrice existait à portée de main
La vraie leçon est simple : un agent IA, c’est un stagiaire très rapide avec les clés du datacenter. Il ne faut pas lui donner ces clés sans un cadre.
Garde-fous indispensables quand une IA touche à Terraform et AWS
Le post-mortem mentionne des mesures concrètes (l’article complet est partiellement réservé aux abonnés sur la source). Mais même avec les informations disponibles, on peut extraire une checklist de survie, très actionnable, pour tous ceux qui utilisent Claude Code, ChatGPT, ou n’importe quel agent en CLI.
1) Séparer strictement dev, staging et production
Ça paraît basique, mais c’est souvent contourné “pour gagner du temps” ou “pour économiser”.
- comptes AWS séparés
- VPC séparés
- state Terraform séparés
La séparation n’est pas un luxe, c’est une barrière anti effet domino.
2) Verrouiller le state Terraform comme un artefact critique
Un state n’est pas un fichier de config. C’est le cerveau de Terraform.
Bonnes pratiques :
- backend distant (S3 + DynamoDB lock)
- versioning activé sur le bucket S3
- accès IAM minimal
- interdiction de manipulations manuelles non tracées
Et surtout : pas d’archives de state décompressées “par hasard” dans un répertoire de travail.
3) Interdire terraform destroy en production (ou le rendre douloureux)
Oui, parfois on en a besoin. Mais si c’est “facile”, ça arrivera.
Options concrètes :
- politiques IAM qui bloquent DeleteDBInstance, DeleteSnapshot, etc.
- SCP (Service Control Policies) sur AWS Organizations
- ajouter des confirmations supplémentaires via wrapper
- utiliser des modules avec prevent_destroy (selon le provider et les ressources)
Le but n’est pas d’empêcher l’action à vie, mais d’empêcher l’action en un clic distrait.
4) Imposer un mode “propose only” aux agents IA
Règle d’or : l’agent propose, l’humain exécute.
Dans la pratique :
- demander à l’IA de générer les commandes sans les lancer
- exiger qu’elle récapitule ce qu’elle va faire avant toute action
- copier-coller manuel des commandes critiques
Ce n’est pas anti IA. C’est pro production.
5) Utiliser des outils de preview et de validation
Avant un apply ou un destroy, on doit pouvoir valider :
- le workspace
- le compte AWS
- la région
- le backend
- le plan complet
Un rituel simple peut éviter le pire : relire le plan à haute voix. Oui, ça fait un peu cérémonie vaudou, mais c’est moins coûteux qu’un incident.
6) Sauvegardes : la règle 3-2-1, sinon ce n’est pas une sauvegarde
- 3 copies
- 2 supports différents
- 1 copie hors compte, hors région ou hors cloud
Les snapshots automatiques dans le même compte que la prod, c’est utile, mais pas suffisant. Cet incident illustre qu’une suppression orchestrée peut aussi supprimer les sauvegardes.
La question qui fâche : jusqu’où peut-on déléguer à une IA en production ?
La réponse dépend moins de l’IA que de votre système de garde-fous.
Vous pouvez déléguer beaucoup si :
- les permissions sont limitées
- les actions destructrices sont bloquées
- les environnements sont séparés
- les changements passent par revue
- la récupération est testée régulièrement
Sans ces protections, déléguer une migration à un agent IA revient à faire du funambulisme au-dessus d’un volcan, en se disant que “ça va, j’ai de bonnes chaussures”.
Ce post-mortem a une valeur énorme parce qu’il montre un incident réaliste : pas une IA “malveillante”, pas un bug exotique, juste une suite de petits choix pragmatiques qui finissent en catastrophe.
Et c’est exactement comme ça que la prod tombe le plus souvent.
À retenir si vous utilisez Claude Code, Terraform ou un agent IA
- Terraform est un outil extrêmement puissant, donc extrêmement dangereux sans garde-fous
- Un agent IA peut prendre une décision “propre” qui est “fatale” dans votre contexte
- Le state Terraform est un point de fragilité majeur
- La mutualisation d’infra pour économiser quelques dollars peut coûter très cher
- Le support AWS peut sauver, mais ne doit jamais être la stratégie principale
Si vous deviez garder une seule phrase en tête : ne laissez jamais un agent IA exécuter des actions irréversibles sur la prod sans barrière technique et sans validation humaine.
Parce que “terraform destroy” ne fait pas la différence entre un doublon et votre avenir professionnel.