Il y a quelques semaines, un utilisateur a partagé un retour d’expérience qui a fait froid dans le dos à toute la communauté DevOps : sa base de données de production a été effacée lors d’une session avec un agent IA en terminal. Pas un piratage. Pas une erreur humaine classique. L’IA a simplement exécuté une commande destructrice qu’elle pensait pertinente dans le contexte.

Ce genre d’incident était prévisible. Quand on donne à un agent IA un accès shell avec les droits de l’utilisateur courant, on lui donne les clés du royaume. Et contrairement à un humain, l’IA n’a pas la petite voix intérieure qui dit « attends, tu es sûr là ? » avant d’exécuter un DROP DATABASE ou un rm -rf /.

En rédigeant cet article, j’ai moi-même demandé à Claude Code de le publier directement sur mon blog et mes réseaux sociaux. Sa première action ? Aller chercher une image et lancer le déploiement. J’ai dû l’arrêter : « montre-moi le contenu avant ». Ironie du sort : le garde-fou en action, en temps réel, sur un article qui parle de garde-fous.

Voici 7 mesures concrètes que j’applique au quotidien pour utiliser Claude Code (et tout agent IA en terminal) sans jouer à la roulette russe avec la production.

1. La deny list dans settings.json — le filet de sécurité minimal

Claude Code permet de définir une liste de commandes interdites dans sa configuration. C’est la première chose à mettre en place :

{
  "permissions": {
    "deny": [
      "rm -rf",
      "DROP DATABASE",
      "terraform destroy",
      "kubectl delete namespace",
      "docker system prune -af",
      "git push --force"
    ]
  }
}

Ces commandes seront bloquées avant exécution, sans possibilité de contournement. Ce n’est pas une solution miracle — l’IA pourrait formuler la même action autrement — mais c’est un premier barrage essentiel.

2. Le fichier CLAUDE.md — briefer l’IA comme un nouvel employé

Le fichier CLAUDE.md à la racine de votre projet est lu automatiquement par Claude Code au début de chaque session. C’est votre briefing de sécurité :

## Règles de sécurité

- Ne JAMAIS modifier, supprimer ou écraser des données en production
- Toujours demander confirmation avant toute action destructrice
- Utiliser la base de dev/staging pour les tests, jamais la prod
- Ne pas exécuter de migrations de base de données sans validation
- Environnement de production : NE PAS TOUCHER

Pensez-y comme le panneau « Haute tension — Défense d’entrer » devant la salle serveur. L’IA le lit, le respecte, et adapte son comportement.

3. Utilisateur base de données en read-only — le principe du moindre privilège

Si votre agent IA doit consulter une base de données, créez un utilisateur dédié en lecture seule :

CREATE USER 'claude_readonly'@'%' IDENTIFIED BY 'motdepasse_fort';
GRANT SELECT ON production_db.* TO 'claude_readonly'@'%';
FLUSH PRIVILEGES;

Même si l’IA tente un DELETE FROM users, la base refusera. Ce n’est pas une question de confiance envers l’IA — c’est le même principe qu’on applique à n’importe quel service : ne donner que les droits nécessaires.

4. Un wrapper shell qui filtre les commandes dangereuses

Pour aller plus loin que la deny list, vous pouvez créer un script wrapper qui intercepte les commandes avant exécution :

#!/bin/bash
# /usr/local/bin/safe-shell.sh

BLOCKED="rm -rf|DROP |terraform destroy|kubectl delete|format |mkfs\."

if echo "$@" | grep -qiE "$BLOCKED"; then
    echo "⛔ COMMANDE BLOQUÉE : action potentiellement destructrice détectée"
    echo "Commande : $@"
    logger -t safe-shell "BLOCKED: $@"
    exit 1
fi

exec bash -c "$@"

Ce wrapper agit comme un portier : il laisse passer les commandes normales et bloque celles qui correspondent à des patterns dangereux.

5. Backup automatique avant chaque session

Avant de lancer une session Claude Code sur un projet sensible, un snapshot rapide peut sauver la journée :

#!/bin/bash
# pre-session-backup.sh
TIMESTAMP=$(date +%Y%m%d_%H%M%S)

# Backup de la DB
mysqldump -u admin production_db | gzip > "/backups/db_${TIMESTAMP}.sql.gz"

# Snapshot du répertoire de travail
tar czf "/backups/project_${TIMESTAMP}.tar.gz" /chemin/vers/projet/

echo "✅ Backup créé : $TIMESTAMP"
echo "Vous pouvez maintenant lancer votre session IA en toute sécurité."

Ce script peut être configuré comme un hook pre-session dans Claude Code, pour qu’il s’exécute automatiquement à chaque démarrage.

6. Ne JAMAIS utiliser —dangerouslySkipPermissions

Claude Code dispose d’un flag --dangerouslySkipPermissions qui désactive toutes les vérifications de sécurité. Son nom dit tout : c’est dangereux.

Ce flag existe pour des cas très spécifiques (CI/CD automatisée dans des environnements sandboxés). En usage interactif, l’utiliser revient à conduire sans ceinture sur l’autoroute en se disant qu’on est un bon conducteur. La question n’est pas si un accident arrivera, mais quand.

Règle simple : si vous tapez --dangerouslySkipPermissions, vous devez pouvoir expliquer pourquoi à votre CTO à 3h du matin après un incident.

7. Environnements isolés — la production n’est pas un terrain de jeu

La mesure la plus efficace reste la plus classique : ne jamais donner à l’IA un accès direct à la production. Utilisez des environnements isolés :

  • Docker : lancez vos sessions dans un container dédié sans accès réseau aux services de production
  • Utilisateur système restreint : créez un user Unix dédié sans droits sudo ni accès aux répertoires critiques
  • Variables d’environnement : ne chargez que les credentials de dev/staging, jamais ceux de prod
# Lancer Claude Code dans un environnement isolé
docker run --rm -it \
  --network=dev-network \
  -v $(pwd):/workspace \
  -e DATABASE_URL=$DEV_DATABASE_URL \
  mon-image-dev claude

En résumé

Les agents IA en terminal sont des outils extraordinaires — j’utilise Claude Code tous les jours et il a transformé ma productivité. Mais comme tout outil puissant, ils demandent du respect et de la rigueur.

Les 7 garde-fous en un coup d’œil :

  1. Deny list dans settings.json
  2. CLAUDE.md avec les règles de sécurité
  3. Utilisateur DB read-only
  4. Wrapper shell filtrant les commandes dangereuses
  5. Backup automatique avant chaque session
  6. Ne jamais utiliser —dangerouslySkipPermissions
  7. Environnements isolés pour la production

La règle d’or ? Traitez votre agent IA comme un stagiaire brillant mais imprudent : il peut faire un travail remarquable, mais on ne lui donne pas les clés du serveur de prod le premier jour.

— Lorenzo, architecte infrastructure & cloud, fondateur d’Oltitude