Claude Code CLI : mode plan, diff et validations disciplinées

Cette page installe un rituel de contrôle en quatre gestes sur le projet lab-claude : forcer un plan avant l'action, relire le diff proposé, enchaîner ruff et pytest, puis vérifier le périmètre réellement touché avec git diff. Elle commence par ce qu'il faut savoir avant de choisir un mode : Claude Code en documente six, et le mode plan ne fait pas ce que la plupart des tutoriels affirment. Vous en repartirez avec une discipline qui tient en trente secondes par changement, et avec le bon modèle mental de ce que chaque mode autorise réellement.

Ce que vous allez apprendre

• Distinguer les six modes de permission, et ce que chacun autorise vraiment
• Activer et sortir du mode plan proprement
• Exiger un plan avant toute modification sur lab-claude
• Relire un diff en 30 secondes avant d'accepter
• Gérer un diff long sans se noyer
• Enchaîner ruff + pytest + git diff après chaque action
• Ajouter mypy au rituel quand le projet grossit
• Savoir ce que les hooks changeront dans l'étape suivante

Pourquoi un rituel vaut mieux qu'une vigilance ponctuelle

La vigilance s'épuise. Un rituel, non. Les défauts typiques sans rituel :

• un diff accepté sans relecture parce que "ça semble ok"
• une suite de modifications avant la première validation
• un git status découvert trop tard, avec 8 fichiers touchés au lieu de 2

Le rituel de ce guide tient en 4 gestes répétés à chaque petit changement. C'est volontairement court pour que vous l'appliquiez vraiment.

Prérequis

• lab-claude en place. Un CLAUDE.md n'est pas nécessaire ici : il fait l'objet d'une leçon dédiée dans le module suivant
• uv run ruff check . et uv run pytest -q verts
• Connaissance des prompts bornés (voir prompting de base)

Quels sont les modes de permission de Claude Code ?

Claude Code documente six modes de permission, relevés le 10 septembre 2026 dans la documentation officielle. Beaucoup de contenus en ligne, y compris des versions antérieures de cette page, n'en citent que trois : c'est l'héritage d'un état plus ancien du produit.

Mode	Comportement	Quand l'utiliser
default	demande confirmation à la première utilisation de chaque outil. Libellé Manual dans l'interface, et l'alias manual est accepté	usage quotidien, et point de départ recommandé
acceptEdits	accepte automatiquement les modifications de fichiers et les commandes courantes du système de fichiers (mkdir, touch, mv, cp) dans le répertoire de travail	tâches répétitives dont vous avez déjà validé la forme
plan	Claude lit les fichiers et exécute des commandes shell en lecture seule pour explorer, mais ne modifie pas vos sources	début de session, tâche non cadrée, reprise après dérive
auto	approuve les appels d'outils avec des contrôles de sûreté en arrière-plan, qui vérifient que l'action correspond à votre demande	tâches longues où répondre à chaque question casse le rythme
dontAsk	refuse tout ce qui n'est pas explicitement autorisé par /permissions ou vos règles permissions.allow	exécutions verrouillées, typiquement en intégration continue
bypassPermissions	supprime les demandes de permission, à l'exception des actions qu'aucun mode n'approuve automatiquement	uniquement en environnement isolé, conteneur ou machine virtuelle

Glissez pour voir

Shift + Tab fait tourner la session entre default, acceptEdits et plan, et atteint aussi bypassPermissions et auto lorsqu'ils sont disponibles. Le mode de démarrage se fixe par defaultMode dans vos fichiers de réglages.

Deux modes à traiter avec précaution

bypassPermissions ignore les demandes y compris pour les chemins protégés comme .git et .claude. La documentation est explicite : ne l'employez que dans un environnement isolé où Claude Code ne peut rien casser d'important.

Une organisation peut interdire les deux modes les plus permissifs en posant permissions.disableBypassPermissionsMode et permissions.disableAutoMode à "disable" dans un fichier de réglages, de préférence managed pour qu'ils ne soient pas surchargeables.

Règle pratique pour débuter : restez en default ou plan. Les autres modes ne se justifient qu'une fois le rituel de contrôle solide, et chacun déplace une frontière qu'il faut avoir comprise avant de la déplacer.

Étape 1 : activer le mode plan

Le mode plan protège vos sources, pas votre machine. C'est la nuance à comprendre avant tout le reste, et beaucoup de tutoriels se trompent dessus. En mode plan, Claude lit les fichiers et exécute des commandes shell considérées comme étant en lecture seule pour explorer votre dépôt ; si le mode auto est disponible, des commandes approuvées par le classificateur s'exécutent également. Ce que plan garantit, c'est qu'il ne modifie pas vos fichiers sources.

Autrement dit : plan n'est pas un bac à sable, c'est une discipline d'exploration. Si votre besoin est d'empêcher toute exécution, la réponse n'est pas un mode de permission mais le sandboxing, traité plus loin dans le parcours. Deux façons d'activer le mode plan :

• Raccourci clavier : Shift + Tab fait tourner les modes (default → acceptEdits → plan → default)
• Prompt explicite : ajouter Propose un plan en 3 étapes. Ne modifie aucun fichier tant que je n'ai pas validé.

Notez la formulation : on demande de ne rien modifier, pas de « ne rien exécuter ». C'est ce que le mode garantit, et une consigne qui décrit fidèlement le comportement attendu est mieux suivie qu'une consigne approximative.

Préférence recommandée au début

Utilisez la formulation explicite au début. Elle force l'habitude et reste lisible dans l'historique de session. Le raccourci devient naturel ensuite.

Étape 2 : structurer le rituel en 4 gestes

Le rituel à répéter pour chaque petit changement :

1. Plan : demandez un plan court, borné aux fichiers cibles
2. Diff : relisez ce que Claude propose avant d'accepter
3. Validation technique : uv run ruff check . puis uv run pytest -q
4. Contrôle final : git diff pour vérifier le périmètre réellement touché

Schéma :

Plan -> Diff -> ruff + pytest -> git diff

Si un des 4 gestes échoue, on revient à l'étape précédente sans enchaîner.

Étape 3 : dérouler le rituel sur lab-claude

1. Ouvrez lab-claude et lancez Claude

   cd ~/Projets/lab-claude
   claude

2. Demandez un plan en mode plan

   Propose un plan en 3 étapes pour ajouter un endpoint /version
   qui renvoie la version de FastAPI.
   Limite le périmètre à app/main.py et tests/.
   Ne modifie aucun fichier tant que je n'ai pas validé.

3. Validez le plan et demandez une seule étape

   Exécute uniquement l'étape 1 du plan validé.
   Affiche le diff complet avant d'appliquer.

4. Relisez le diff avant d'accepter

   Regardez : les fichiers touchés correspondent-ils au périmètre ? Y a-t-il du code non demandé (commentaires, imports, helpers) ?

5. Lancez la validation technique

   uv run ruff check .
   uv run pytest -q

6. Contrôle final avec Git

   git diff
   git status

Étape 4 : relire un diff en 30 secondes

Une relecture de diff efficace ne cherche pas à tout comprendre. Elle répond à 3 questions :

• Les fichiers touchés sont-ils dans le périmètre annoncé ?
• Y a-t-il du code non demandé (imports inutiles, commentaires génériques, refactoring spontané) ?
• La signature publique (routes, types, noms) change-t-elle de façon non prévue ?

Si vous répondez "non/non/non" en 30 secondes, acceptez. Sinon, refusez et reformulez.

Accepter, refuser, éditer : quand utiliser quoi

Claude Code propose généralement 3 actions sur un diff :

Action	Quand l'utiliser
Accepter	Diff conforme au plan et au périmètre
Refuser	Diff hors périmètre ou non conforme aux conventions
Éditer / demander modif	Proche du besoin, mais un détail à ajuster

Glissez pour voir

Ne refusez pas par réflexe. Mais ne rectifiez pas à la main ce que Claude peut refaire correctement avec une reformulation courte.

Relire un diff long sans se noyer

Un diff de 200 lignes n'est pas relisible en 30 secondes. Trois stratégies pour ne pas abandonner :

1. Fichier par fichier : relisez un fichier à la fois, pas le diff global. Validez la cohérence locale avant de passer au suivant.

2. Nouveaux symboles d'abord : concentrez-vous sur les nouvelles fonctions, classes et routes. Le reste (refactor, renommage) se relit après.

3. Demander un résumé : si le diff dépasse la limite raisonnable, demandez à Claude :

   Résume le diff en 5 points maximum :
   fichiers touchés, intention, risques, changements non demandés, suites.

Si le diff est trop gros pour la relecture, c'est souvent le signal que le plan était trop large. Revenez au plan, découpez, et rejouez.

Rituel étendu : ajouter mypy quand le projet grossit

Le duo ruff + pytest suffit pour lab-claude. Quand un projet ajoute du typing strict ou plusieurs modules, le rituel s'étend :

uv run ruff check .
uv run mypy app
uv run pytest -q

Règle d'intégration : ajoutez mypy au rituel quand il tourne en moins de 30 secondes sur le projet. Au-delà, gardez-le en pré-commit, pas dans le rituel de session.

Pensez aussi à refléter ce choix dans CLAUDE.md pour que Claude propose la bonne commande de validation sans que vous ayez à la redicter.

Exemple de permissions pour automatiser le rituel

Pour ne plus approuver chaque commande de validation, autorisez-les dans .claude/settings.json à la racine du projet. Écrivez ces règles à la main plutôt que de les accumuler en répondant « ne plus me demander » : chaque approbation permanente ajoute une ligne, une commande enchaînée en ajoute jusqu'à cinq, et rien ne les supprime ensuite. Un fichier écrit volontairement reste relisible, un fichier accumulé ne l'est plus.

{
  "permissions": {
    "allow": [
      "Bash(uv run ruff check *)",
      "Bash(uv run pytest *)",
      "Bash(uv run mypy *)",
      "Bash(git diff *)",
      "Bash(git status *)"
    ],
    "deny": [
      "Bash(rm -rf *)",
      "Bash(git push *)"
    ]
  }
}

L'espace avant l'astérisque fait partie de la règle. Bash(ls *) exige un espace après ls et ne couvre donc pas lsof, alors que Bash(ls*), sans espace, l'attrape aussi. Un astérisque final précédé d'un espace couvre en outre la commande nue : Bash(git diff *) autorise git diff tout court. La forme Bash(git diff *) est équivalente et reste valide, mais c'est la forme avec espace que le dialogue de permission écrit quand vous répondez « ne plus me demander », et elle est donc celle que vous verrez dans vos propres fichiers.

Une règle Bash n'est pas une frontière de sécurité

Le deny ci-dessus réduit le risque d'accident, il ne bloque pas un contournement. Une règle Bash s'applique au texte de la commande que Claude écrit, après découpage des commandes composées et retrait des enveloppes. Le même programme appelé autrement passe à côté :

Règle	Arrête	N'arrête pas
Bash(curl *)	curl https://exemple.fr	/usr/bin/curl https://exemple.fr, sh -c 'curl https://exemple.fr'
Bash(rm *)	rm -rf build/	/bin/rm -rf build/, bash -c 'rm -rf build/'
Bash(git push *)	git push origin main	git -C . push origin main, git 'push' origin main

Glissez pour voir

Pour une contrainte qui ne dépend pas de la façon d'écrire la commande, la documentation renvoie à deux mécanismes : le sandboxing, qui impose une frontière système sur le fichier et le réseau, et un hook PreToolUse, qui inspecte le texte complet avec votre propre logique avant l'exécution. Ces deux sujets sont traités dans les leçons de sécurité du parcours.

Ce réglage fluidifie donc le rituel et documente une intention. Il ne remplace pas une isolation.

Comment ce rituel s'automatise-t-il ensuite avec les hooks ?

La suite logique consiste à automatiser ce rituel avec les hooks Claude Code. L'événement qui vous servira ici s'appelle PostToolUse : il se déclenche après un appel d'outil réussi, donc après une écriture de fichier, et il peut lancer ruff sans que vous ayez à y penser. Attention aux noms trouvés en ligne : il n'existe pas d'événement post-edit.

Trois principes à retenir avant d'y venir :

• ce que vous installez ici à la main est la base d'un hook automatisable ;
• plus votre rituel manuel est stable, plus l'automatisation sera simple ;
• sans rituel préalable, les hooks produisent du bruit plutôt que de la sécurité.

Installer le rituel comme habitude

Quelques astuces pour que le rituel tienne :

• Gardez un second terminal ouvert uniquement pour ruff + pytest + git diff
• Ajoutez à CLAUDE.md une ligne : Après chaque modification, rappelle la commande de validation à lancer.
• Préférez 5 petits cycles plutôt qu'un gros changement "testé à la fin"

Erreurs fréquentes

Symptôme	Cause probable	Correction
Diff accepté puis tests rouges	Relecture trop rapide	Forcer les 3 questions à voix haute avant d'accepter
Plusieurs fichiers touchés hors scope	Plan non borné	Rejouer un prompt avec liste explicite des fichiers autorisés
Tests verts mais git diff inquiétant	Refactoring spontané accepté	Refuser et reformuler : "garde la même structure de fichiers"
Rituel sauté par manque de temps	Pas d'automatisation	Préparer les commandes dans un alias shell

Glissez pour voir

Checklist de fin de guide

• Je sais activer le mode plan en deux manières
• Je déroule les 4 gestes sans les sauter
• Je refuse un diff hors périmètre au lieu de corriger à la main
• Je lance ruff + pytest + git diff après chaque changement
• J'ai ajouté un rappel de validation dans CLAUDE.md

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

À retenir

• Le mode plan est la meilleure protection contre les modifications précipitées
• La relecture de diff se fait en 30 secondes sur 3 questions
• La validation technique ne remplace pas git diff : les deux sont complémentaires
• Un rituel court et répété bat une vigilance ponctuelle

Pour aller plus loin

• Workflows concrets : debug, refactor, test, doc, PR : Le rituel appliqué à cinq situations réelles, avec les points de contrôle propres à chacune.
• Configurer CLAUDE.md : Les règles persistantes qui alimentent le plan sans que vous ayez à les rappeler.
• Erreurs courantes et recadrage en session : Les manœuvres de reprise quand une session dérive malgré le rituel.

×

📖 Voir la documentation →