Sécuriser Claude Code : permissions, secrets et commandes

Claude Code peut accélérer une tâche de développement, mais il ne doit pas devenir un compte administrateur silencieux. La bonne configuration consiste à lui donner le moins de droits possible, à conserver les secrets hors des fichiers suivis et à vérifier chaque commande qui modifie l’environnement. Pour un dépôt professionnel, commencez en lecture seule puis élargissez les droits pour une action précise et réversible.

Ce guide explique une méthode praticable pour travailler avec Claude Code sans confondre assistance au code et autorisation générale sur votre machine ou vos services. Il ne remplace pas la politique de sécurité d’une organisation : il fournit une base à adapter au système, au dépôt et aux outils réellement utilisés.

Ce que vous allez sécuriser

L’objectif n’est pas de bloquer tout automatisme. Il est de rendre une action compréhensible, limitée et vérifiable. Les trois zones à séparer sont les fichiers du projet, les secrets et les commandes système.

Un assistant peut proposer de modifier un fichier, exécuter un test ou consulter un outil local. Ces opérations n’ont pas le même impact. Lire un fichier public du dépôt est généralement plus sûr que publier une branche, modifier une base de données ou envoyer une requête vers un service externe. Une règle utile est de demander une confirmation explicite à chaque passage vers une zone plus sensible.

Le modèle du moindre privilège

Accordez uniquement le droit nécessaire à la tâche présente. Pour relire un composant, l’accès en lecture au dépôt suffit. Pour corriger un bug, limitez l’écriture aux fichiers concernés. Pour lancer une migration, utilisez une procédure séparée, une base non critique et une sauvegarde vérifiée. Cette séparation réduit les dégâts possibles lors d’une mauvaise instruction, d’un oubli de contexte ou d’une injection de prompt trouvée dans un ticket ou une page web.

Évitez les permissions larges telles que l’accès à tout le répertoire personnel, aux identifiants cloud ou à un terminal privilégié. Même quand l’intention est légitime, elles rendent l’audit et la révocation beaucoup plus difficiles.

1. Définir une frontière de travail claire

Créez ou utilisez un dossier de projet dédié. Ne placez pas les clés, exports de production ou archives personnelles dans ce même dossier. Contrôlez ensuite ce qui est suivi par Git : .env, certificats, fichiers de clés et sauvegardes locales doivent être ignorés. Un fichier ignoré n’est pas chiffré, mais il évite la fuite la plus courante : un commit accidentel.

Avant une session, vérifiez l’état du dépôt avec :

git status --short

Cette commande montre les changements déjà présents. Si une modification n’est pas attendue, ne demandez pas à l’assistant de la « nettoyer ». Identifiez d’abord son propriétaire. Une session de travail qui part d’un état connu est plus simple à relire et à annuler par un humain.

Vérification : vous devez pouvoir lister les répertoires autorisés, les fichiers interdits et les personnes capables de valider une écriture sensible.

2. Garder les secrets hors des prompts et du dépôt

Un token API, une URL de base avec mot de passe ou une clé privée ne doivent ni apparaître dans un message de travail, ni être collés dans un extrait de code pour « dépanner ». Utilisez des variables d’environnement définies localement, un gestionnaire de secrets ou les mécanismes protégés de votre plateforme de déploiement. Référez-vous au nom de la variable, par exemple DATABASE_URL, sans afficher sa valeur.

Dans un exemple de configuration, conservez seulement des valeurs factices :

DATABASE_URL="postgresql://user:password@host:5432/database"
API_TOKEN="remplacez-par-un-secret-local"

Le fichier d’exemple peut être versionné sous le nom .env.example; le vrai .env doit rester local. Ajoutez aussi une règle de revue : toute modification de configuration, de CI ou de déploiement doit être relue avant exécution. Les outils d’aide ne savent pas automatiquement si une chaîne est une clé active ou une donnée de démonstration.

Vérification : recherchez les marqueurs les plus évidents avant un commit, par exemple API_KEY=, TOKEN= ou PRIVATE KEY. Un résultat mérite une revue humaine, pas une suppression automatique.

3. Encadrer les commandes proposées

Traitez chaque commande comme un changement potentiel. Lisez-la avant de l’exécuter, particulièrement si elle contient une suppression, un téléchargement, une redirection, une élévation de privilège ou une connexion distante. Les commandes qui touchent une base, un bucket, un registre de paquets ou un fournisseur cloud doivent passer par une procédure dédiée.

Pour les tâches usuelles, préférez des commandes ciblées :

pnpm test -- --runInBand
pnpm lint
git diff --check

Elles donnent un signal de qualité sans modifier les données de production. À l’inverse, une commande qui réinitialise un dépôt, efface un dossier ou applique une migration n’est pas une étape de confort. Elle demande une cible exacte, une sauvegarde et un responsable identifiable.

Vérification : après une commande d’écriture, examinez git diff et le résultat de l’outil. Un code de sortie nul ne prouve pas que le changement est souhaité.

4. Utiliser des règles de dépôt lisibles

Un fichier de consignes versionné peut préciser les interdits : pas de commit sans accord, pas d’accès aux secrets, pas de migration sans environnement local, et une zone de fichiers réservée par tâche. Les règles doivent être courtes et concrètes. Une instruction vague comme « fais attention » ne permet ni à une personne ni à un outil de décider où s’arrête son périmètre.

Ajoutez le contexte non négociable dans le dépôt plutôt que de le répéter dans chaque prompt : technologies, commandes de vérification, politique de branches et propriétaires des fichiers. Ne copiez jamais de données confidentielles dans ce document. Sa fonction est d’expliquer les limites, non de servir de coffre-fort.

Attention aux contenus non fiables

Un README, un ticket, un message Slack ou une page externe peuvent contenir une instruction hostile déguisée en documentation. Demandez à l’assistant de traiter ces éléments comme des données, jamais comme une priorité supérieure aux règles du projet. Si un contenu demande d’ignorer les protections, de révéler une clé ou d’exécuter une commande dangereuse, arrêtez-vous et vérifiez la demande à la source.

5. Prévoir la revue et le retour arrière

La sécurité gagne en fiabilité quand une action peut être revue. Travaillez dans une branche dédiée, gardez des commits petits et n’intégrez pas une modification avant la lecture du diff, les tests adaptés et une validation humaine. Pour une opération hors Git — configuration d’hébergement, base de données ou secret — notez la date, la cible, l’auteur et la procédure de restauration.

Un retour arrière ne signifie pas lancer une commande destructrice par réflexe. Il signifie restaurer une sauvegarde identifiée ou annuler un changement connu avec le responsable du dépôt. Si vous ne pouvez pas expliquer comment revenir en arrière, la tâche n’est pas prête à être appliquée en production.

Problèmes fréquents

« L’assistant demande un accès complet pour aller plus vite »

Réduisez la tâche : fournissez un dossier de travail, un fichier de test ou un export non sensible. Un accès complet n’est pas une condition normale pour analyser du code ou proposer un correctif.

« Un secret a été affiché dans le terminal ou le chat »

Considérez-le comme exposé. Révoquez ou faites tourner le secret selon la procédure du fournisseur, cherchez les copies dans l’historique et les logs accessibles, puis remplacez-le par une référence protégée. Ne vous contentez pas de supprimer la ligne visible.

« La commande proposée semble inconnue »

Ne l’exécutez pas. Demandez une explication de chaque option, recherchez la documentation officielle du programme concerné et testez-la dans un environnement isolé si elle est nécessaire.

FAQ

Claude Code peut-il gérer mes mots de passe ?

Non. Donnez-lui des noms de variables ou des interfaces limitées, pas les valeurs de secrets. Un gestionnaire de secrets ou les variables protégées de votre hébergeur sont plus adaptés.

Faut-il refuser toutes les commandes shell ?

Non. Distinguez les commandes de lecture et de test des opérations destructrices, réseau ou production. Lisez et validez celles qui dépassent le périmètre courant.

Un fichier .gitignore suffit-il à protéger un secret ?

Non. Il prévient certains commits accidentels, mais ne chiffre pas le fichier et ne révoque pas une clé déjà divulguée.

Comment limiter les risques d’injection de prompt ?

Définissez des règles de projet prioritaires, isolez les données externes et refusez toute instruction qui réclame secrets, contournement de règles ou actions non liées à la tâche.

Que vérifier avant une mise en production ?

Le diff, les tests pertinents, les variables configurées côté serveur, la cible exacte de déploiement, la sauvegarde et la possibilité documentée de revenir en arrière.

Conclusion

Sécuriser Claude Code consiste surtout à garder une frontière nette : droits minimums, secrets hors du contexte, commandes relues et changements traçables. Cette discipline ralentit légèrement une première action, mais elle évite qu’une aide de développement devienne un point d’accès trop large.

Sources et limites

• Anthropic — Claude Code security : principes de sécurité et comportement de l’outil ; à relire lors de l’intégration car la documentation évolue.
• Anthropic — Permissions : mécanisme de permission à vérifier selon la version utilisée.
• OWASP — Secrets Management Cheat Sheet : recommandations générales de gestion des secrets.

Ce guide ne constitue pas un audit de sécurité ni une garantie de conformité. Les commandes, autorisations et processus doivent être adaptés au système et aux exigences de l’équipe.