Un développeur nommé Alexey Grigorev voulait déployer un nouveau site web. Il a utilisé Claude Code pour exécuter Terraform. Il avait oublié de migrer son fichier d'état vers une nouvelle machine, donc Terraform pensait que rien n'existait et a commencé à créer des ressources en double.

Il a repéré le problème. A demandé à Claude de nettoyer les doublons. Puis a uploadé le fichier d'état. Claude a décompressé une archive, trouvé l'état de production, et a proposé terraform destroy pour repartir proprement.

Alexey a approuvé.

La base de données de production de DataTalks.Club — 2,5 ans de soumissions de devoirs, de dossiers de projets, de classements, 1,9 million de lignes — a été supprimée. Les snapshots automatisés étaient aussi gérés par Terraform. Ils sont partis avec.

Le garde-fou qui n'a pas gardé

Ce n'est pas une autre histoire « l'IA a détruit la prod ». J'en ai déjà écrit une. Ce qui rend celle-ci différente, c'est que chaque mécanisme de sécurité a fonctionné exactement comme prévu.

Claude Code a demandé la permission avant d'exécuter la commande destructive. L'humain était présent, a lu l'invite, et a dit oui. L'« humain dans la boucle » — ce sur quoi tout le monde pointe comme ultime garde-fou — était là. Et la base de données est morte quand même.

Alexey l'a dit clairement : « J'ai traité plan, apply et destroy comme quelque chose qui pouvait être délégué. Ça a supprimé la dernière couche de sécurité. »

Il est dur avec lui-même. Ce qui s'est vraiment passé est plus subtil et plus courant : il travaillait avec Claude depuis une heure. Claude avait eu raison à chaque fois. L'agent suggérait des étapes de nettoyage, Alexey approuvait, ça fonctionnait. Au moment où terraform destroy est apparu, « oui » était un rythme, pas une décision.

La fatigue d'approbation

Chaque invite de permission suppose que l'humain comprend ce qu'il approuve. Cette hypothèse se dégrade avec le temps. Pas parce que les gens deviennent moins intelligents — parce que la confiance se compound. Le premier « oui » est un jugement. Le vingtième est une habitude.

C'est les données qu'Anthropic a publiées sur leur propre outil : les utilisateurs expérimentés approuvent automatiquement dans plus de 40 % des sessions, contre 20 % quand ils commencent. Plus vous l'utilisez, moins vous vérifiez. Et personne ne pense que ça le décrit spécifiquement.

La réponse de l'industrie à la sécurité de l'IA, c'est « mettre un humain dans la boucle. » Mais un humain dans la boucle qui clique sur « approuver » depuis une heure n'est pas un garde-fou. C'est un tampon encreur avec un pouls.

Ce qu'on fait à la place

Notre système de permissions fonctionne différemment. Au lieu de tout demander, on approuve automatiquement ce qui ne peut pas causer de dégâts : lectures de fichiers, git status, exécution de tests, patterns grep sûrs. Ceux-là ne génèrent jamais d'invite. L'humain ne les voit pas.

Quand une invite apparaît, elle signifie quelque chose. L'interruption elle-même est le signal. Vous n'avez pas cliqué sur « oui » depuis une heure, donc votre cerveau est vraiment engagé quand le système pose la question.

Les actions dangereuses — git push --force, git checkout ., rm -rf — sont bloquées purement et simplement. Pas avec une invite. Bloquées. Pas de dialogue « êtes-vous sûr ? ». Juste non.

Et terraform destroy ? Ça ne serait jamais dans une liste d'autorisation. C'est le genre de commande où l'humain ne clique pas sur « approuver » — l'humain la tape lui-même, dans son propre terminal, après avoir lu le plan deux fois.

La vraie leçon

Le système d'Alexey s'est récupéré. Le support business d'AWS a restauré un snapshot caché. Les données sont revenues. Il a écrit un postmortem clair et honnête et a ajouté une protection contre la suppression, la gestion d'état S3, et des tests de restauration quotidiens. Bonne réponse d'ingénierie.

Mais la leçon à retenir n'est pas « ajoutez plus de garde-fous. » C'est que le garde-fou dont tout le monde parle — l'humain dans la boucle — n'est aussi bon que l'attention de l'humain. Et l'attention n'est pas une ressource renouvelable. Elle s'épuise à chaque invite qu'on lui envoie.

Si vous demandez à un humain d'approuver tout, il approuvera tout. Ce n'est pas un échec de l'humain. C'est un échec du système qui traite toutes les actions comme également dignes d'être demandées.

Un git add et un terraform destroy ne devraient pas passer par le même flux d'approbation. L'un est du bruit de fond. L'autre est une arme chargée. Si votre système les présente de façon identique, ne soyez pas surpris quand l'humain arrête de lire les étiquettes.