Jusqu’ici, Claude Code a surtout lu votre code et répondu à vos questions. Le laisser modifier vos fichiers, c’est un autre niveau de confiance. Bonne nouvelle : cette confiance ne se donne pas les yeux fermés, elle se construit avec des garde-fous précis. Dans ce module, vous allez découvrir le système de permissions et le plan mode — les deux outils qui font la différence entre un assistant que l’on surveille avec anxiété et un collègue avec qui l’on travaille sereinement.

Ce que vous allez apprendre

• Comprendre la philosophie « lecture libre, action sur accord » et répondre efficacement aux demandes de permission
• Basculer entre les trois modes de travail avec Shift+Tab : normal, auto-accept et plan mode
• Utiliser le plan mode pour valider un plan d’action avant la moindre modification
• Garder la main : lire les diffs, faire de git votre filet de sécurité, exécuter vos propres commandes avec le préfixe !
• Protéger vos secrets : règles de /permissions, fichier .env et injection de prompt

Lecture libre, action sur accord : la philosophie

Le système de permissions de Claude Code tient en une phrase. Lire est libre, agir demande votre accord.

Concrètement : Claude peut parcourir les fichiers de votre projet, chercher du texte, examiner la structure du code. Tout cela sans vous demander quoi que ce soit, tant qu’il reste dans le dossier de travail. En revanche, dès qu’il veut agir — écrire dans un fichier, exécuter une commande qui modifie quelque chose — il s’arrête. Et il vous demande.

Imaginez un artisan qui visite votre maison pour un devis. Il regarde partout, ouvre les portes, prend des mesures : aucun problème. Mais avant de percer le premier trou dans le mur, il vous demande votre feu vert. Claude Code fonctionne exactement comme cela.

Quand une demande de permission apparaît, vous avez trois réponses possibles. Regardez bien, car chacune a son usage.

Oui, une fois. Vous approuvez cette action précise, et uniquement celle-là. La prochaine action déclenchera une nouvelle demande. C’est la réponse par défaut quand vous découvrez un projet ou une tâche.

Oui, sans redemander. Vous approuvez cette action et les suivantes du même type. Pour une modification de fichier, cette approbation vaut jusqu’à la fin de la session. Pour une commande shell, Claude Code peut la mémoriser durablement pour le projet : pratique pour une commande de test que vous lancerez cent fois.

Non. Et c’est la réponse la plus sous-estimée. Refuser ne ferme pas la porte : vous pouvez expliquer ce que vous voulez à la place. « Non, ne modifie pas ce fichier, corrige plutôt la fonction dans le module voisin. » Claude prend votre remarque en compte et repart dans la bonne direction.

💡 Astuce — Un « non » accompagné d’une explication est souvent le meilleur des prompts. Plutôt que de laisser passer une action approximative puis de la corriger après coup, refusez et redirigez immédiatement. Vous gagnez du temps, et Claude comprend mieux votre intention.

Shift+Tab : trois modes au bout des doigts

En bas de la session, un indicateur affiche le mode de permission actif. Pour en changer, une seule touche : Shift+Tab. Chaque pression fait tourner les modes.

Le mode normal est celui que vous connaissez déjà : Claude demande votre accord avant chaque type d’action. C’est le réglage de tous les jours.

Le mode auto-accept des éditions approuve automatiquement les modifications de fichiers dans votre dossier de travail. Quand l’utiliser ? Sur une tâche balisée, dont vous avez déjà validé la logique : renommer une variable dans vingt fichiers, appliquer un correctif que vous avez relu, harmoniser un formatage. Vous évitez de taper « oui » vingt fois de suite. Les commandes sensibles, elles, continuent de demander votre accord.

Le plan mode, enfin, est si important qu’il mérite sa propre section. Retenez pour l’instant l’essentiel : c’est le mode où Claude ne touche à rien.

⚠️ Piège courant — L’auto-accept est confortable, et c’est bien le problème : on oublie de le désactiver. La tâche balisée est terminée, vous enchaînez sur autre chose, et les éditions continuent de passer sans validation. Prenez le réflexe : tâche terminée, Shift+Tab pour revenir en mode normal. Un coup d’œil à l’indicateur de mode vous confirme où vous en êtes.

Le plan mode : réfléchir d’abord, agir ensuite

Voici le mode qui va changer votre pratique. En plan mode, Claude Code passe en lecture seule. Il explore vos fichiers, exécute des commandes d’analyse sans effet de bord, réfléchit à la meilleure approche. Mais il ne modifie rien. Pas un fichier, pas une ligne.

Le déroulé est toujours le même. Vous décrivez ce que vous voulez. Claude explore le code concerné. Puis il vous présente un plan : les fichiers qu’il compte toucher, les changements qu’il envisage, l’ordre des opérations. Vous lisez ce plan. Vous posez des questions si un point vous échappe. Et seulement quand vous validez, Claude passe à l’exécution.

Pourquoi est-ce si précieux ? Parce que la plupart des dérapages avec un agent de développement viennent d’un malentendu initial. Vous pensiez « petite retouche », il a compris « refonte ». Le plan mode expose ce malentendu avant qu’une seule ligne ne change. Corriger un plan coûte trois secondes. Corriger vingt fichiers modifiés de travers coûte une soirée.

Retenez ce réflexe : toute modification non triviale commence en plan mode. Un refactoring — c’est-à-dire une réorganisation du code sans changement de comportement —, une migration, une correction qui touche plusieurs fichiers : plan mode d’abord.

Vous pouvez activer le plan mode en cours de session avec Shift+Tab. Vous pouvez aussi démarrer directement dedans :

# Démarrer une session directement en plan mode
claude --permission-mode plan

💡 Astuce — Le plan mode n’est pas réservé aux modifications. C’est aussi un excellent mode d’exploration : sur un projet que vous découvrez, lancez une session en plan mode et posez toutes vos questions. Vous avez la garantie absolue que rien ne sera modifié pendant votre visite.

Rester le pilote : lisez les diffs, committez souvent

Le système de permissions vous donne le pouvoir de dire oui ou non. Encore faut-il savoir à quoi vous dites oui. C’est ici que se joue la vraie différence entre un utilisateur débutant et un développeur senior.

Quand Claude propose une modification, il affiche un diff : la comparaison entre l’avant et l’après, avec les lignes supprimées et les lignes ajoutées. Lisez-le. Vraiment. Pas en diagonale, pas en survolant : ligne par ligne pour tout ce qui compte. Le senior ne fait pas confiance au résumé, il vérifie le changement. C’est cette lecture qui attrape la condition inversée, le fichier de configuration touché par erreur, la dépendance ajoutée sans raison.

Et pour les fois où quelque chose passe quand même ? Vous avez git, le système de gestion de versions qui enregistre l’historique de votre code. C’est votre filet de sécurité, et il transforme complètement la relation de confiance avec l’agent.

La règle est simple : committez souvent. Un commit — une photographie de l’état de votre projet — avant chaque tâche confiée à Claude, un commit après chaque étape validée. Avec cette discipline, revenir en arrière devient trivial : une commande, et votre projet retrouve son état d’avant. Vous pouvez laisser Claude tenter une approche audacieuse en sachant que le point de sauvegarde existe.

💡 Astuce — Prenez ce rituel : avant de confier une tâche à Claude, un commit de sauvegarde. Le coût est de cinq secondes. Le bénéfice, c’est de pouvoir dire oui plus souvent, plus vite, et sans stress : l’annulation est toujours à portée de main.

Le préfixe ! : votre accès direct au terminal

Justement, comment lancer ces commandes git sans quitter la session ? Avec le préfixe !. Tapez un point d’exclamation en début de ligne, puis votre commande : elle s’exécute directement, sans passer par Claude, sans demande de permission — c’est vous qui la tapez, après tout.

# Dans la session : le préfixe ! exécute la commande directement
! git status
! git diff
! npm test

Le résultat s’affiche et rejoint le contexte de la conversation. Claude voit donc ce que vous voyez. C’est parfait pour vérifier l’état du dépôt avant de valider, lancer les tests après une modification, ou montrer une erreur à Claude sans la copier-coller.

/permissions : décidez une fois, appliquez toujours

Répondre aux demandes une par une, c’est bien au début. Mais certaines décisions méritent d’être prises une bonne fois pour toutes. C’est le rôle de la commande /permissions.

Tapez /permissions dans la session : vous voyez toutes les règles actives, et vous pouvez en ajouter. Trois familles de règles existent. Les règles allow autorisent une action sans demande. Les règles deny l’interdisent, point final. Les règles ask forcent une demande de confirmation.

Deux exemples concrets. Vous lancez les tests dix fois par jour ? Une règle allow sur Bash(npm run test:*) supprime la demande à chaque fois. Un dossier ne doit jamais être touché ? Une règle deny sur ce chemin le verrouille.

Retenez le principe de priorité : deny gagne toujours. Si une règle deny et une règle allow correspondent à la même action, c’est l’interdiction qui s’applique. Vous pouvez donc autoriser largement et verrouiller précisément.

Ces règles vivent dans des fichiers de configuration appelés settings.json, que l’on peut partager avec toute une équipe. Nous verrons leur syntaxe complète au module 7. Pour l’instant, /permissions suffit à couvrir vos besoins quotidiens.

Le bouton rouge : —dangerously-skip-permissions

Il existe une option qui désactive les demandes de permission : --dangerously-skip-permissions. Son nom dit tout — « dangereusement ». Avec elle, Claude écrit et exécute sans jamais vous demander votre accord.

Alors pourquoi existe-t-elle ? Pour les environnements isolés. Un conteneur — un mini-système jetable et cloisonné — ou une machine d’intégration continue, la fameuse CI qui exécute vos tests automatiquement. Dans ces environnements, il n’y a ni secrets personnels ni données irremplaçables : si quelque chose tourne mal, on jette et on recommence. Les demandes de permission n’y ont aucun sens, puisque personne n’est là pour y répondre.

Sur votre machine de travail, en revanche : jamais. Vous y avez vos projets, vos accès, vos fichiers personnels. Supprimer le garde-fou principal pour gagner quelques validations, c’est un très mauvais échange. Si les demandes vous semblent trop fréquentes, la bonne réponse est une règle allow ciblée via /permissions — pas la suppression de toutes les barrières.

Secrets et contenus extérieurs : les bons réflexes

Terminons par trois réflexes de sécurité qui doivent devenir automatiques.

Premier réflexe : aucun secret dans la conversation. Ne collez jamais de mot de passe, de clé d’API — ce code confidentiel qui donne accès à un service — ni aucun identifiant dans vos échanges avec Claude. Un secret n’a rien à faire dans un historique de conversation, quel qu’il soit.

Deuxième réflexe : verrouillez vos fichiers sensibles. Le fichier .env, qui stocke traditionnellement les secrets d’un projet, est le premier candidat. Une règle deny lui interdit tout accès. Voici un avant-goût de la syntaxe, que nous détaillerons au module 7 :

{
  "permissions": {
    "deny": ["Read(.env)", "Read(.env.*)"]
  }
}

Et attention : écrire « ne lis jamais .env » dans un fichier d’instructions ne suffit pas. Une consigne en langage naturel guide le modèle, mais seule une règle deny est appliquée techniquement par Claude Code, avant même que le modèle n’agisse.

Troisième réflexe : méfiez-vous des contenus extérieurs. Une page web, un fichier téléchargé ou un texte externe peuvent contenir des instructions malveillantes destinées à l’agent : c’est ce qu’on appelle l’injection de prompt. Claude Code intègre des protections contre ce type d’attaque, mais votre vigilance reste le dernier rempart : relisez toujours les commandes et les modifications proposées après un travail sur du contenu extérieur, et évitez d’envoyer du contenu non fiable directement à Claude.

Les notions croisées dans ce module — diff, commit, prompt, injection de prompt — ont chacune leur définition dans notre glossaire. Et pour situer Claude Code dans le paysage des assistants IA, notre dossier consacré à l’intelligence artificielle vous donne la vue d’ensemble.

⚠️ Piège courant — Le faux sentiment de sécurité après plusieurs sessions sans incident. Les garde-fous ne servent pas les jours où tout va bien : ils servent le jour où un malentendu, un contenu piégé ou une erreur du modèle survient. Gardez la discipline même quand tout roule : commits fréquents, diffs relus, secrets verrouillés.

A vous de jouer

Passons à la pratique avec un exercice complet, du plan mode jusqu’à la vérification finale.

1. Ouvrez un de vos projets versionnés avec git, et vérifiez qu’il est propre : aucune modification en attente. Si besoin, créez un commit de sauvegarde.
2. Lancez une session directement en lecture seule : claude --permission-mode plan.
3. Demandez un petit refactoring réel. Par exemple : « extrais la logique de validation de ce fichier dans une fonction séparée » ou « renomme cette fonction et mets à jour tous ses appels ».
4. Lisez le plan proposé, attentivement. Les fichiers listés sont-ils les bons ? L’approche vous convient-elle ? Posez au moins une question avant de valider — c’est un excellent réflexe à installer.
5. Validez le plan, puis lisez chaque diff proposé avant de l’accepter. Ligne par ligne.
6. Une fois le travail terminé, vérifiez par vous-même avec ! git diff. Si le résultat vous plaît, committez. Sinon, revenez en arrière : c’est exactement pour cela que le filet existe.

En resume

• Claude Code lit librement, mais demande votre accord avant d’écrire ou d’exécuter : oui une fois, oui sans redemander, ou non avec une explication de ce que vous voulez à la place.
• Shift+Tab fait tourner les modes : normal, auto-accept des éditions pour les tâches balisées, et plan mode.
• Le plan mode est votre réflexe pour toute modification non triviale : exploration en lecture seule, plan présenté, validation, puis exécution. Démarrage direct avec claude --permission-mode plan.
• Lisez les diffs ligne par ligne et committez souvent : git rend le retour en arrière trivial.
• /permissions installe vos règles durables : allow pour les commandes de confiance, deny pour les fichiers sensibles comme .env — et deny gagne toujours.
• --dangerously-skip-permissions est réservé aux conteneurs et aux environnements CI isolés, jamais à votre machine de travail.

Vous savez désormais laisser Claude Code agir sans jamais lâcher le volant. Au prochain module, nous passons à la personnalisation : vous allez apprendre à Claude les conventions et les habitudes de votre projet, pour qu’il travaille comme un membre de l’équipe qui connaît la maison.