Permissions et modes

Les modes d’exécution de Claude Code

Claude Code propose plusieurs façons de lancer une session, chacune correspondant à un niveau d’interaction différent entre le développeur et l’agent.

Mode interactif (REPL)

La commande claude sans argument ouvre une session conversationnelle. Le développeur envoie des messages, l’agent répond et propose des actions. Chaque action sensible (écriture de fichier, exécution de commande) demande une confirmation explicite.

Point clé : Le mode interactif est le mode par défaut. Il offre le contrôle maximal : rien ne s’exécute sans votre accord.

Mode print (one-shot)

La commande claude -p "ma question" exécute une seule requête, affiche la réponse et quitte. Pas de boucle conversationnelle. Ce mode est utilisé dans les scripts CI/CD, les hooks Git, ou tout contexte où l’on veut un résultat sans interaction.

Plan mode

En plan mode, l’agent rédige un plan d’action détaillé avant d’agir. Le développeur lit le plan, l’approuve ou le modifie, puis l’agent exécute. C’est un compromis entre contrôle et productivité : on valide la stratégie, pas chaque geste.

Le système de permissions

Claude Code demande une autorisation avant chaque action potentiellement destructrice (écrire un fichier, exécuter une commande shell). Ce comportement est configurable via deux mécanismes complémentaires.

Allow et deny lists

Les flags --allowedTools et --disallowedTools permettent de pré-autoriser ou bloquer des outils spécifiques. Ils se configurent aussi dans .claude/settings.json pour une persistance projet.

{
  "permissions": {
    "allow": ["Read", "Grep", "Glob", "WebFetch"],
    "deny": ["Bash(rm *)", "Bash(git push)"]
  }
}

Point clé : Les outils en lecture seule (Read, Grep, Glob) sont généralement sûrs à pré-autoriser. Les outils d’écriture et d’exécution méritent un examen au cas par cas.

Les trois profils de permissions

Attention : Le mode YOLO désactive toute barrière de sécurité. Un agent qui hallucine une commande destructrice l’exécutera sans filet. Ne jamais utiliser ce mode sur une machine de développement ou en production.

La progression d’autonomie

Au-delà des paramètres techniques, la vraie question est stratégique : quel degré d’autonomie accorder à l’agent selon la maturité du projet et la confiance acquise ?

Les trois niveaux

Point clé : La progression In-loop vers AFK n’est pas un escalier à monter le plus vite possible. C’est un curseur à ajuster selon le risque : refactoring explorateur = In-loop, migration bien balisée = Out-of-loop, génération de boilerplate = AFK.

Quand relâcher les permissions

Trois conditions doivent être réunies avant de passer à un mode plus autonome :

• Tests automatisés fiables — l’agent peut vérifier son propre travail via les tests.
• Hooks de sécurité — les actions irréversibles (push, delete, deploy) sont bloquées par des hooks PreToolUse.
• Environnement isolé — une branche dédiée, un conteneur, ou un sandbox limitent l’impact d’une erreur.

Attention : Relâcher les permissions sans tests ni hooks revient à conduire sans ceinture ni frein à main. L’agent fait des erreurs — la question n’est pas « si » mais « quand ». Les garde-fous existent pour limiter les dégâts, pas pour les empêcher totalement.

Sécurité et prompt injection

Plus l’agent est autonome, plus le risque de prompt injection augmente. Un fichier malveillant dans le repo, un contenu piégé dans une réponse API — si l’agent exécute sans confirmation, l’attaquant obtient l’exécution de code.

Point clé : En mode YOLO, une injection dans un fichier lu par l’agent peut déclencher rm -rf ou exfiltrer des secrets via curl. Les permissions sont la dernière ligne de défense contre ce type d’attaque.

Analogie avec l’architecture hexagonale : les permissions jouent le rôle des ports. Elles définissent ce qui peut entrer et sortir du système. Les hooks sont les adapters qui implémentent les contrôles concrets. Sans cette frontière, le domaine (votre code) est exposé sans protection.