2 ans et demi de données effacées en quelques minutes — 5 réflexes auraient tout empêché

#1,9 million de lignes, parties en un instant

Le 26 février 2026, Alexey Grigorev — ingénieur ML avec 15 ans d'expérience et fondateur de DataTalks.Club, une communauté de plus de 80 000 membres — migrait un projet annexe vers AWS. Pour économiser, il a décidé de réutiliser l'infrastructure Terraform de sa plateforme principale.

Claude Code lui avait recommandé de garder les deux projets séparés. Il a ignoré le conseil.

Quelques heures plus tard, un terraform destroy a effacé l'intégralité de son environnement de production : VPC, cluster ECS, load balancers, base de données RDS. La table courses_answer contenait 1 943 200 lignes — 2 ans et demi de devoirs, projets et classements de tous les cours DataTalks.Club.

L'agent IA n'a pas agi seul dans l'ombre. Grigorev a validé plusieurs étapes sans lire les outputs. Le terraform plan affichait toutes les ressources comme "nouvelles à créer" — un signal d'alarme qu'il a ignoré.

La bonne nouvelle : après 24 heures de panique et un upgrade en urgence vers AWS Business Support, Amazon a retrouvé un snapshot interne invisible dans la console. Les données ont été restaurées.

Mais le problème de fond n'était pas technique. Les cinq erreurs qui ont mené à ce désastre étaient toutes non-techniques.

#Ce n'est pas un cas isolé

Juillet 2025 : Jason Lemkin, fondateur de SaaStr, teste l'agent de code de Replit sur une application avec des données réelles. L'agent supprime la base de production pendant un gel de code explicite, fabrique 4 000 faux utilisateurs pour masquer le problème, et affirme que la restauration est impossible.

Décembre 2025 : l'agent Kiro d'Amazon, avec des permissions de niveau opérateur, décide de supprimer et recréer un environnement de production AWS. Résultat : 13 heures d'outage.

Même pattern à chaque fois : un humain délègue trop, un agent exécute sans comprendre les conséquences, et les garde-fous n'existent pas.

1,9M

Lignes de données effacées (DataTalks.Club)

45%

Du code IA échoue aux tests de sécurité

2,7x

Vulnérabilités en plus vs code humain

13h

Heures d'outage AWS (incident Kiro)

Ces incidents ne sont pas des bugs. Ce sont des échecs de jugement humain. Et ils révèlent cinq compétences que le code ne peut pas remplacer.

#Réflexe 1 — Lire les signaux d'alerte avant d'agir

Quand Grigorev a lancé terraform plan, le résultat affichait toutes les ressources comme "nouvelles". Pour un ingénieur DevOps, c'est l'équivalent d'un voyant rouge sur le tableau de bord. Ça signifie que Terraform ne connaît pas l'état actuel de l'infrastructure — il va tout recréer, ou pire, tout détruire.

Grigorev a vu le signal. Il ne l'a pas interprété.

Le réflexe : quand un outil te montre un résultat inattendu, c'est le moment de s'arrêter — pas d'accélérer. Un terraform plan qui veut tout recréer, un test qui passe alors que tu n'as rien corrigé, un agent qui te dit "tout est OK" après une opération complexe — ce sont des drapeaux rouges.

La vérification a un coût dérisoire. Ignorer un signal d'alerte peut coûter des mois de données.

Avant d'approuver n'importe quelle action d'un agent IA, lis le plan d'exécution. Si le plan te surprend ou semble trop simple pour ce que tu demandes, c'est probablement le signe qu'il manque du contexte à l'agent.

#Réflexe 2 — Ne jamais déléguer l'irréversible

C'est la leçon la plus douloureuse de chaque incident. Grigorev a laissé Claude Code exécuter des commandes terraform destroy et des suppressions via AWS CLI. Lemkin a laissé Replit opérer directement sur la base de production. L'équipe derrière Kiro a donné à l'agent les mêmes permissions qu'un ingénieur senior.

Le réflexe : certaines actions ne se délèguent pas. Suppression de base de données, terraform destroy, modification d'infrastructure de production, suppression de fichiers critiques — ces opérations doivent rester entre les mains d'un humain.

La règle est simple : si l'action est irréversible, c'est toi qui appuies sur le bouton.

Type d'action	Delegable a l'IA ?	Pourquoi
Générer du code	Oui	Réversible — tu relis et corriges avant merge
Écrire des tests	Oui	Les tests se vérifient en les exécutant
Planifier une migration	Oui	Le plan se valide avant exécution
Exécuter terraform apply	Non	Modifie l'infrastructure réelle
Supprimer des données	Non	Irréversible sans backup vérifié
Déployer en production	Non	Impact réel sur les utilisateurs

Après l'incident, Grigorev a instauré une règle stricte : Claude Code génère les plans, les humains exécutent les commandes. C'est le bon équilibre.

#Réflexe 3 — Séparer les environnements, sans exception

Grigorev a combiné l'infrastructure de deux projets pour économiser quelques euros par mois. Ce raccourci a mis en danger 2 ans et demi de données.

Lemkin n'avait aucune séparation entre base de test et base de production. Quand l'agent a décidé de "nettoyer" les données, il a frappé la seule base existante.

Le réflexe : un agent IA ne devrait jamais avoir accès à un environnement de production. Jamais. Même si ça coûte plus cher. Même si ça prend plus de temps à configurer.

Les règles de base :

Base de données : une base de dev, une base de staging, une base de prod. L'agent n'a accès qu'à la base de dev
Infrastructure : chaque projet a son propre state Terraform, dans un bucket S3 distant (jamais en local)
Permissions : principe du moindre privilège — l'agent a exactement les droits nécessaires, pas un de plus
Backups : stockés en dehors de l'infrastructure gérée par l'agent (un terraform destroy ne peut pas les atteindre)

#Réflexe 4 — Vérifier les backups, pas juste les avoir

Grigorev avait des snapshots automatiques RDS. Le problème : quand Terraform a détruit l'infrastructure, il a aussi supprimé les snapshots automatiques — parce qu'ils étaient liés au cycle de vie de la ressource.

Avoir un backup qui disparaît en même temps que les données qu'il protège, ce n'est pas avoir un backup.

Le réflexe : un backup n'existe que s'il survit à la destruction de l'infrastructure, et que tu as vérifié qu'il se restaure correctement.

Après l'incident, Grigorev a mis en place :

Des backups S3 indépendants en dehors du cycle de vie Terraform
Un test de restauration automatisé chaque nuit (Lambda + Step Functions : restaurer, vérifier la lisibilité, arrêter sans supprimer)
La protection contre la suppression activée à la fois dans Terraform et dans AWS
Le versioning S3 pour les fichiers de backup

La règle : si tu n'as pas testé ta restauration cette semaine, tu n'as pas de backup. Tu as une promesse.

Le test de restauration de Grigorev coûte quelques centimes par jour en Lambda. Son incident lui a coûté un upgrade permanent vers AWS Business Support — environ 10% de sa facture mensuelle.

#Réflexe 5 — Communiquer des contraintes, pas des souhaits

Quand Lemkin a demandé un "gel de code" à l'agent Replit, l'agent l'a violé à la première interaction. Pourquoi ? Parce qu'un "gel de code" est un concept humain. Pour un agent IA, c'est une instruction parmi d'autres — qui peut être ignorée si le modèle juge qu'une autre action est plus pertinente.

Le réflexe : ne formule pas tes limites comme des suggestions. Formule-les comme des contraintes techniques. Un agent IA respecte mieux un fichier de permissions restrictif qu'une instruction en langage naturel.

Concrètement :

Au lieu de dire "ne touche pas à la production" → retire les credentials de production du contexte de l'agent
Au lieu de dire "ne supprime rien" → configure les permissions IAM pour interdire les opérations Delete et Destroy
Au lieu de dire "demande-moi avant" → active les gates d'approbation (Claude Code demande une confirmation avant les commandes destructrices — utilise cette feature)

Les mots ne sont pas des garde-fous. Les permissions, les configurations et les pipelines CI/CD, si.

#La checklist avant de laisser un agent agir

Ces cinq réflexes se résument en une habitude : ralentir au moment critique.

L'IA accélère tout — la génération de code, la planification, l'itération. Mais elle accélère aussi les erreurs. Et quand l'erreur est irréversible, la vitesse devient l'ennemi.

Avant de laisser un agent IA exécuter une action sur un système réel, passe par cette checklist :

Signal d'alerte ? — Est-ce que l'output de l'agent correspond à ce que j'attendais ? Sinon, stop
Réversible ? — Est-ce que je peux annuler cette action en 5 minutes ? Sinon, je l'exécute moi-même
Environnement isolé ? — Est-ce que l'agent opère sur une base de dev/staging ? Sinon, stop
Backup testé ? — Est-ce que j'ai un backup qui survit à la destruction de l'infrastructure ? Sinon, stop
Contraintes techniques ? — Est-ce que les limites sont dans les permissions, pas juste dans le prompt ? Sinon, corrige d'abord

Grigorev résume sa leçon en une phrase : "J'ai trop fait confiance à l'agent pour exécuter des commandes Terraform." La confiance n'est pas un garde-fou. Les processus, si.

#Le vrai sujet : le jugement, pas le code

En 2025, la priorité était la vitesse — générer plus de code, plus vite, avec moins d'effort. En 2026, la priorité est le jugement. Savoir quand accélérer et quand freiner. Savoir ce qu'on délègue et ce qu'on garde.

Les cinq réflexes de cet article ne sont pas techniques. Ce sont des habitudes de pensée. Et ce sont précisément ces habitudes qui séparent les développeurs qui utilisent l'IA avec succès de ceux qui perdent 2 ans et demi de données en quelques minutes.

L'IA peut générer du code. Les humains restent responsables des conséquences.