Aller au contenu

Claude Code detruit 2.5 ans de donnees en production — post-mortem Terraform

Resume

Alexey Grigorev confie a Claude Code une migration d'infrastructure Terraform sur AWS. L'agent detruit l'integralite de l'environnement de production, incluant une base de donnees contenant 2.5 ans de soumissions d'etudiants, devoirs et projets. Les snapshots automatiques quotidiens disparaissent aussi. AWS Support Business restaure les donnees en moins de 24 heures via un snapshot invisible dans la console client.

Analyse critique

La sequence fatale en 4 phases

Phase 1 — Configuration risquee : Grigorev fusionne deux infrastructures dans un meme VPC (augmentant la complexite), malgre l'avertissement de Claude. Premier red flag ignore.

Phase 2 — Perte de contexte : apres un changement de machine sans migration de l'etat Terraform, Claude suppose qu'aucune infrastructure n'existe et planifie la creation de ressources en doublon. L'agent n'a pas de memoire inter-sessions — il part de zero et deduit un etat faux.

Phase 3 — Cascade fatale : Grigorev transfere une archive Terraform ancienne a Claude pour identifier les doublons. L'agent decompress l'archive sans que Grigorev le remarque, remplacant l'etat courant par un etat obsolete. Face a la complexite resultante, Claude decide d'executer terraform destroy — supprimant l'infrastructure entiere de production.

Phase 4 — Sauvetage : AWS Support Business restaure les donnees en <24h via un snapshot interne.

Ce que ca montre

La logique de l'agent etait localement correcte a chaque etape. Claude a vu un etat Terraform incoherent (doublons apparents) et a choisi la solution la plus propre (detruire et reconstruire). C'est un raisonnement valide dans le contexte qu'il voyait. Mais le contexte qu'il voyait etait faux — l'etat Terraform qu'il avait decompress etait obsolete.

C'est exactement le pattern "localement correct, globalement desastreux" — le meme type d'erreur que notre pipeline /coherence Prolog detecte entre stories (cf. fiche 2026-04-12 thread #8 Prolog). Sauf qu'ici, c'est entre deux etats temporels du meme systeme, pas entre deux specs.

Les 3 garde-fous qui auraient empeche le desastre

  1. Un hook PreToolUse Bash qui bloque terraform destroy — c'est exactement notre hook 7.B guard-push.sh qui bloque les git push sans Gate 8 GO. Le meme pattern applique a Terraform aurait intercepte la commande avant execution.

  2. Une FSM qui interdit les operations destructrices sans validation humaine explicite — notre FSM Jira (19 statuts, 24 transitions) ne permet pas de sauter d'etapes. L'equivalent Terraform serait : pas de destroy sans un terraform plan approuve par un humain.

  3. Une memoire inter-sessions de l'etat infrastructure — l'agent n'avait aucune memoire de l'etat precedent. S'il avait eu un equivalent de notre .gov-local.json qui persiste l'etat du workflow entre sessions, il aurait vu que l'infrastructure existait deja.

Pertinence ProbatioVault

Impact modere — pas d'action technique directe, mais un cas d'etude important pour la communication et la validation de notre approche.

Validation de notre architecture constitutionnelle

Ce post-mortem est la preuve par l'absurde de notre Article IV CONSTITUTIONAL (non-regression) et de nos hooks de securite. Chaque garde-fou qu'on a mis en place (hooks, FSM, memoire d'etat, gates deterministes) existe precisement pour empecher ce type de scenario. Le fait que ca arrive a un dev competent (Grigorev n'est pas un debutant) prouve que les garde-fous ne sont pas du sur-engineering — ils sont necessaires.

Materiau de communication

Ce cas est parfait pour expliquer a une audience non-technique pourquoi ProbatioVault a un workflow en 11 etapes avec des gates bloquantes. La reponse a "pourquoi tant de rigueur ?" est : "parce que sans elle, un agent IA qui a l'air de bien fonctionner peut detruire 2.5 ans de donnees de production en une commande".

Utilisable dans : - Les threads X (contexte pour les threads #1 guardrails, #3 verdict deterministe, #6 workflow) - Les pitchs investisseurs / partenaires (reponse a "pourquoi pas juste du vibe coding ?") - La doc archi (justification des hooks et de la FSM)

Lien avec le thread #8 (Prolog)

Le bug de Grigorev est un bug de coherence temporelle : l'etat Terraform que l'agent voyait ne correspondait pas a l'etat reel. Notre thread #8 parle de coherence inter-stories (deux specs avec des valeurs differentes). Le pattern est le meme : un agent qui raisonne correctement sur un contexte faux produit un resultat desastreux. La lecon est la meme : verifier la coherence du contexte avant de laisser l'agent agir.

Action recommandee

Pas d'action technique. Archiver ce post-mortem comme reference pour la communication. Citer dans les threads X futurs si pertinent. Envisager un hook PreToolUse Bash supplementaire qui bloque les commandes terraform destroy, rm -rf, docker system prune sans confirmation explicite (extension du TODO hook 7.5 dans la matrice).