Comment Claude Code a effacé ma base de données en production

Il y a trois semaines, Claude Code a effacé ma base de données en production.

Pas un bug. Pas un hack. Une commande propre, exécutée sans hésitation, en réponse à une instruction que j'avais validée.

docker compose down -v

Le -v, c'est le flag qui supprime les volumes. Les volumes, c'est là que Postgres stocke les données. Ma base était dans un conteneur Docker sur Scaleway. Plus de volumes, plus de données. Irréversible.

Tout perdu. Reconstruit from scratch.

Ce qui s'est passé

Je travaillais sur un projet interne. Un outil connecté à mes autres outils — CRM, facturation, contenu. Postgres faisait tourner la base derrière.

Je debuggais un problème de conteneur. Le service ne redémarrait pas proprement. J'ai demandé à Claude Code de remettre l'environnement au propre.

Claude Code a fait ce qu'on lui a demandé. Il a remis l'environnement au propre. Complètement au propre. Volumes compris.

Le problème, ce n'est pas Claude Code. C'est moi.

L'erreur

Pas de backup. Pas de snapshot Scaleway programmé. Pas de dump Postgres automatisé. Pas de volume externe monté en dehors du compose. Rien.

Un outil connecté à une base de production, sans aucun filet de sécurité. Et un agent IA avec un accès direct au terminal.

C'est l'équivalent de donner les clés de votre voiture à quelqu'un qui conduit très bien, mais qui ne sait pas où se trouve le ravin. Sans lui dire où est le ravin. Et sans frein à main.

Ce que j'aurais dû faire

1. Un backup automatisé. Un pg_dump quotidien envoyé sur un bucket S3. 10 lignes de cron. 15 minutes de mise en place. Coût : 2 € par mois. C'est tout.

2. Des volumes externes. Monter les données Postgres sur un volume Scaleway indépendant du Docker Compose. Même si le compose est détruit, les données survivent.

3. Des garde-fous sur Claude Code. Une instruction système claire : « Ne jamais exécuter de commande destructive sur les volumes de production sans confirmation explicite. » Un CLAUDE.md à la racine du projet avec les règles de sécurité.

4. Un environnement de dev séparé. Ne pas debugger sur la prod. Basique. Mais quand on est seul et qu'on va vite, on finit par confondre les deux.

Ce que ça m'a appris

Claude Code est un outil extraordinaire. Je l'utilise tous les jours. Il code plus vite que moi, il débugge mieux que moi, il trouve des solutions auxquelles je n'aurais pas pensé.

Mais il n'a pas de jugement contextuel. Il ne sait pas que cette base contient des données irremplaçables. Il ne sait pas que -v est une bombe. Il exécute l'instruction la plus logique par rapport à la demande.

Et c'est exactement le problème que je vois chez mes clients. L'IA fait ce qu'on lui dit. Pas ce qu'on veut. Si l'instruction est floue, le résultat est imprévisible. Si l'environnement n'est pas sécurisé, l'erreur est irréversible.

Le diagnostic ne concerne pas que les processus métier. Il concerne aussi les garde-fous. Avant de déployer un agent IA en production, la première question n'est pas « qu'est-ce qu'il peut faire ». C'est « qu'est-ce qui se passe s'il fait la mauvaise chose ».

Mon setup aujourd'hui

Depuis l'incident, voici ce qui a changé :

• pg_dump automatique toutes les 6 heures, envoyé sur un bucket S3 avec rétention de 30 jours
• Volumes Postgres sur stockage Scaleway indépendant
• Fichier CLAUDE.md à la racine de chaque projet avec les règles de sécurité
• Environnement de dev totalement séparé de la prod
• Confirmation obligatoire avant toute commande destructive

Temps de mise en place : une demi-journée. Coût mensuel : moins de 5 €.

La prochaine fois que Claude Code voudra nettoyer un environnement, les données survivront. Parce que le problème n'a jamais été Claude Code. Le problème, c'était l'absence de diagnostic sur mon propre setup.

Le cordonnier mal chaussé, version 2026.

---

Vous déployez des agents IA sans avoir audité vos garde-fous ?

Commençons par un diagnostic →