Avant de confier les clés à une IA. Les 5 protections pour que les débutants ne provoquent pas d'accident

« Ce projet, range-le un peu, vite fait. »

Je tape ça d’un cœur léger et je pars me faire un café. À mon retour, le terminal s’était arrêté à un cheveu d’exécuter rm -rf. Mon doigt, machinalement, s’avançait déjà vers le bouton de validation.

Si j’avais appuyé sur « oui » à ce moment-là, le .env et les fichiers de config y seraient tous passés, d’un bloc.

Claude Code est brillant. Mais intelligence et sécurité sont deux choses totalement distinctes. Pire : comme il est intelligent et rapide, il fonce de toutes ses forces, même dans la mauvaise direction. C’est comme un couteau : plus il coupe bien, plus on se blesse avant d’avoir appris à le tenir.

Cet article se concentre uniquement sur les protections qu’un débutant doit poser en premier. Le compliqué, plus tard. Les 5 à poser d’abord, je les écris simplement, avec mes propres bourdes.

Au fait, qu’est-ce qui est si dangereux ?

Un éditeur de texte ordinaire ne fait qu’afficher des caractères. Claude Code, non. C’est un outil qui « peut faire » ces choses-là à l’intérieur de votre ordinateur :

• lire, écrire, supprimer des fichiers ;
• exécuter des commandes de terminal (rm aussi) ;
• accéder au réseau et publier sur des services externes.

Et tout ça, ça s’exécute si vous validez par « oui ». Le hic, c’est qu’à force d’appuyer des dizaines de fois sur le bouton de validation, on arrête de regarder le contenu. Dès qu’on prend le rythme « ouais ouais, OK », une opération dangereuse se faufile sans bruit.

Du coup, la sécurité, ce n’est pas « faire attention ». C’est construire d’avance un dispositif où, même sans faire attention, on ne provoque pas d’accident. Regardons dans l’ordre.

Là où ça donne des frissons (trois cas)

Trois « situations dangereuses » fréquentes chez les débutants. Rien d’extraordinaire dans aucune.

Situation 1 : vouloir faire corriger une erreur, et coller tout le log

Quand on demande « corrige cette erreur », on copie-colle tout ce qui est sorti dans le terminal, n’est-ce pas. Sauf qu’il peut s’y glisser une ligne du genre DATABASE_URL=postgresql://user:vrai_mot_de_passe@.... On croyait juste donner à l’IA, et voilà le mot de passe en clair dans l’historique de la conversation et dans les logs.

Situation 2 : laisser tourner en mode « tout en automatique »

La validation lasse, alors on passe en mode où tout s’exécute sans confirmation, et on quitte son bureau. L’IA, croyant bien faire, tape git push --force, et le travail de quelqu’un de l’équipe part en fumée. Aucune mauvaise intention. Mais le résultat est catastrophique.

Situation 3 : confondre deux bases au nom voisin

myapp_dev et myapp_prod. Une lettre d’écart. Si vous demandez juste « supprime les vieilles données de la base » et que l’IA ne vérifie pas à laquelle elle est connectée, ce qui disparaît, ce sont peut-être les données de vos clients en prod.

Le point commun des trois : au moment où l’humain a une « inattention », l’IA exécute de toutes ses forces. Donc, il suffit de faire en sorte que l’inattention reste sans conséquence. C’est ça, la protection.

Mes trois plantages personnels

J’écris d’un ton docte, mais moi aussi, au début, ce n’était qu’accidents. J’en avoue trois, franchement.

Le premier. En montant la publication automatique vers Qiita, j’ai collé le token directement dans le prompt. « Publie en utilisant QIITA_TOKEN=xxxx. » Ça marchait, j’étais content ; et plus tard j’ai réalisé. Cette chaîne reste dans l’historique de conversation, et dans l’historique de la petite IA qui tourne en coulisse (le sous-agent). J’ai régénéré le token en catastrophe. Avec le recul, sueurs froides.

Le deuxième. Pour une enquête, j’ai demandé « affiche-moi le contenu du .env ». L’IA, docile, a tout lu à voix haute. Clés API et mot de passe de la base, tout à l’écran et dans les logs. À l’instant où on le fait lire, c’est déjà « fuité ». Le .env, même l’humain que je suis ne l’ouvre jamais d’ordinaire.

Le troisième. J’ai copié les réglages laxistes d’un projet perso dans un dépôt de travail. Résultat, l’« interdiction d’écrire en prod » qui aurait dû exister côté travail s’est fait écraser par le laxisme du perso. Je m’en suis aperçu avant l’accident, mais recycler des réglages est vraiment dangereux.

À chaque fois, la cause n’était pas un manque de connaissances, mais de ne pas l’avoir bloqué par un dispositif. Voilà le cœur du sujet.

On protège ces 5 choses. Dans l’ordre, ça suffit

Protection 1 : garder la clé API « en dehors du code »

La plus importante. Les clés API et les tokens, jamais directement dans le code ni dans le prompt. On les isole dans un fichier dédié, .env, et on le sort de la gestion Git. Rien que ça, et l’essentiel des fuites est évité.

D’abord, l’exemple à ne pas faire.

// MAUVAIS : écrit en dur dans le code source (committé = fini sur-le-champ)
const client = new Anthropic({ apiKey: "coller la vraie clé API directement" });

// MAUVAIS : mêlé au prompt
// « Publie en utilisant QIITA_TOKEN=vrai_token » ← ma propre bourde

Correctement, on regroupe les clés dans un fichier .env.

# .env (ce fichier ne part pas sur Git. Il reste seulement sur votre ordinateur)
ANTHROPIC_API_KEY=mettre ici la vraie valeur
QIITA_TOKEN=mettre ici la vraie valeur
DATABASE_URL=postgresql://...

Puis on déclare que ce .env « ne sera jamais ramassé par Git ». C’est le baudrier.

# À écrire sans faute dans .gitignore (l'assurance contre le commit accidentel d'une clé)
.env
.env.*
!.env.example   # seul l'exemple peut être partagé
*.pem
*.key
*-service-account.json   # ne pas oublier la clé de compte de service du cloud

Quand vous voulez juste dire à l’équipe « quelles clés sont nécessaires », posez un exemple aux valeurs vides.

# .env.example (celui-ci peut partir sur Git. Le contenu est vide)
ANTHROPIC_API_KEY=
QIITA_TOKEN=
DATABASE_URL=

Depuis le code, on ne met pas la valeur du fichier en dur, on la lit comme « variable d’environnement ». La clé en chair et en os n’apparaît nulle part dans le code.

// BON : on lit depuis la variable d'environnement. Aucune valeur écrite dans le code
import { config } from "dotenv";
config();

const token = process.env.QIITA_TOKEN;
if (!token) {
  // si la clé manque, on ne dit pas la valeur, juste « tu as oublié de la définir »
  throw new Error("QIITA_TOKEN n'est pas défini. Vérifiez votre fichier .env.");
}

Un seul point clé. La clé en chair et en os n’est touchée qu’à l’intérieur du .env. Le code, le prompt, les logs ne connaissent que le « nom » de la clé. C’est l’a.b.c. de base.

Protection 2 : ne pas « auto-valider » les commandes dangereuses

Ensuite, les commandes irrattrapables comme rm -rf (suppression en masse) ou git push --force (écrasement du travail de l’équipe). Celles-là, on les règle sur « demander obligatoirement à un humain avant exécution » ou « purement et simplement impossibles ».

Claude Code a un mécanisme pour décider commande par commande « OK / à confirmer / interdit ». On l’écrit dans .claude/settings.json.

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "defaultMode": "default",
    "allow": [
      "Read(**)",
      "Glob(**)",
      "Grep(**)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Bash(rm -rf*)",
      "Bash(git push --force*)",
      "Bash(git reset --hard*)",
      "Bash(curl * | bash)"
    ],
    "ask": [
      "Write(**)",
      "Edit(**)",
      "Bash(git commit*)",
      "Bash(git push*)"
    ]
  }
}

La lecture est simple. On répartit dans trois boîtes, c’est tout.

Boîte	Sens	Ce qu’on y met
allow	exécution OK sans confirmation	opérations sûres, en lecture seule
ask	demande à chaque fois	écriture, commit, push
deny	on ne laisse jamais faire	suppression, force push, base de prod

En cas de doute, retenez ceci. Lire seulement, c’est allow ; écrire, c’est ask ; supprimer, c’est deny. Au départ, on serre à fond, et seules les opérations qu’on a comprises « ah, celle-ci est sûre » montent ensuite en ask ou allow. Le sens inverse (laxiste d’abord, serrer après) n’arrive qu’après l’accident, alors on commence absolument par serrer.

Protection 3 : restreindre le « périmètre » de lecture-écriture

Regardez bien le deny de la protection 2. En tête, il y a ces lignes.

"deny": [
  "Read(./.env)",
  "Read(./.env.*)",
  "Read(./secrets/**)"
]

C’est le réglage « il est interdit ne serait-ce que de lire le .env et le dossier secrets ». Ma bourde « faire lire le .env » ne serait pas arrivée avec cette seule ligne. Parce que même en demandant « affiche-le-moi », on se fait refouler à l’entrée.

Restreindre le périmètre, c’est tracer d’avance la ligne entre les endroits qu’on peut montrer et ceux qu’on ne doit pas montrer. Le dossier contenant les clés, la config de prod, les données clients. Les rendre « intouchables par nature », et même une demande étourdie reste sans danger.

En plus, les fichiers que vous ne voulez surtout pas voir édités, écrivez-les aussi en clair dans les règles du projet (CLAUDE.md), ça rassure.

## Fichiers à ne jamais éditer (à écrire dans CLAUDE.md)

Ne jamais éditer les fichiers ci-dessous. Si nécessaire, demander sans faute à moi (l'humain).
- .env (contient clés et mots de passe)
- wrangler.toml (configuration de publication en prod)
- .github/workflows/*.yml (config de déploiement automatique)

Bloquer mécaniquement par le fichier de config, et transmettre aussi l’intention à l’IA par le texte de règles. En double épaisseur, les trous se réduisent.

Protection 4 : ne pas faire sortir les secrets dans les logs

Ce n’est pas tant un réglage qu’un petit pli d’écriture. Quand vous écrivez un message d’erreur, ne sortez pas la « valeur » de la clé avec.

// MAUVAIS : la clé API sort telle quelle dans le log d'erreur
throw new Error(`Échec d'authentification : token=${process.env.TOKEN}`);

// BON : on ne sort pas la valeur, juste où regarder
throw new Error("Échec d'authentification : vérifiez la variable d'environnement TOKEN");

Une seule ligne d’écart, mais le premier fait fuiter la clé dès qu’on montre le log à quelqu’un.

Et autre chose. Quand vous passez un log à l’IA, ne le collez pas brut. Les lignes de clés et de mots de passe, remplacez la valeur par des caractères masqués avant de passer.

# Réécrire ainsi avant de passer. L'IA n'a besoin que de la structure « il y a un accès à la base »
DATABASE_URL=***masqué***
QIITA_TOKEN=***masqué***

« Ce qui peut être passé » et « ce qui est interdit », en gros, dans un tableau. Collé dans CLAUDE.md, ça permet de se rappeler le critère à chaque demande.

OK à passer	Interdit à passer
type d’erreur, étapes de reproduction, nom de fichier	clé API, mot de passe, cookie de session
.env.example, le « nom » des paramètres	URL de base de prod, données clients
log avec valeurs masquées	vrai token, fichier .json de compte de service

Protection 5 : traiter la prod « à part »

Pour finir. On sépare nettement l’environnement d’entraînement (développement) et la prod. Pour éviter la confusion myapp_dev / myapp_prod, il est efficace de faire passer l’écriture en prod par un cran de plus.

// scripts/db-query.mjs
const env = process.env.NODE_ENV ?? "development";

// si on tente d'écrire en prod, on bloque sauf flag dédié
if (env === "production" && process.argv.includes("--write")) {
  console.error("L'écriture en prod exige le flag --force-production.");
  process.exit(1);
}

Le « prod par étourderie », on le bloque physiquement par le cran d’un flag. Cette lourdeur-là est le baudrier. Les données de prod, une fois supprimées, ne reviennent pas.

Par où commencer (la marche à suivre)

Pas besoin de faire les 5 aujourd’hui. Dans l’ordre, ça se boucle en 30 minutes.

1. Créer un .env dans le projet et y déplacer toutes les clés
2. Ajouter .env à .gitignore (protection 1)
3. Créer .claude/settings.json et mettre dans deny rm -rf et la lecture de .env (protections 2 et 3)
4. Mettre dans ask l’écriture et les commandes de commit (protection 2)
5. Coller dans CLAUDE.md le tableau « OK / interdit à passer » et les fichiers à ne pas éditer (protection 4)

Rien qu’avec les trois premières étapes, l’accident rm -rf du début et la fuite du .env sont arrêtés. Ne visez pas la perfection, posez-en une d’abord. C’est déjà un vrai progrès.

Quand vous voudrez peaufiner les permissions plus finement, voyez le guide des permissions Claude Code ; et pour le récit cru d’accidents réellement survenus, les cas d’échec de sécurité de Claude Code. Pour les spécifications exactes des réglages, c’est toujours la documentation officielle qui prime.

Ce que j’ai testé, concrètement

Depuis le frisson rm -rf du début, j’ai arrêté de me torturer avec « est-ce que je fais confiance à l’IA ? ». Ce que je regarde désormais, c’est quel portier l’a arrêtée.

En ajoutant la lecture du .env dans deny, même en demandant « vérifie les variables d’environnement », l’IA se retire docilement. Ce gênant « tout lire à voix haute » ne se reproduit plus.

Honnêtement, le jour où j’ai écrit ces réglages, je me suis dit « j’en fais peut-être trop ». C’était l’inverse. C’est justement parce qu’il y a des garde-fous qu’on peut se permettre de relâcher en confiance. Si je peux appuyer sur le bouton de validation d’un cœur léger, c’est parce que je sais que les opérations dangereuses sont arrêtées en amont par deny. Plutôt que de m’échiner à maîtriser une IA brillante, j’étale d’abord un sol où, même en tombant, on ne se blesse pas. C’est le plus reposant et le plus rapide. Voilà ma conclusion du moment.

En résumé

Pour un débutant, ces 5 protections suffisent largement à poser d’abord.

Ce qu’on protège	Comment
Ne pas faire fuiter la clé API	isoler dans .env + .gitignore
Ne pas laisser s’emballer les commandes dangereuses	rm -rf / force push dans deny
Restreindre le périmètre de lecture-écriture	.env et secrets en deny, fichiers de prod en édition interdite
Ne pas sortir les secrets dans les logs	ne pas sortir la valeur, passer masqué
Traiter la prod à part	bloquer l’écriture en prod par un flag

Le mot sécurité intimide, mais ce qu’on fait, c’est juste « construire d’avance un dispositif où l’accident n’arrive pas ». Une fois posé, ça vous protège ensuite tout seul. 30 minutes aujourd’hui. Et vous effacez un gros accident futur.

Si vous hésitez sur « jusqu’où serrer dans notre équipe ? », j’ai aussi prévu des supports et du soutien. Commencez par jeter un œil à la liste des supports.