Utilisation de Claude Code

Claude Code n'exécute pas une seule commande pour s'arrêter ensuite. Il fonctionne en boucle : il lit les fichiers, propose un changement, modifie le code, exécute la construction ou les tests, lit le résultat et décide de la prochaine étape. Cette autonomie est l'objectif, mais c'est aussi le risque. Le même agent qui peut corriger un test échoué sur quatre fichiers sans surveillance peut aussi exécuter une commande que vous n'avez pas lue, ou réécrire un module que vous ne lui avez jamais demandé de toucher.

Imaginez la version coûteuse de cet apprentissage. Un développeur lance Claude Code sur un véritable dépôt, tape « nettoyez le module d'authentification et faites passer les tests », et commence à approuver les prompts pour maintenir l'élan. Vers la huitième approbation, les prompts se confondent. L'un d'eux est une commande Bash qui supprime un répertoire de fichiers générés dont dépend la construction. Ils l'approuvent sans lire. Maintenant, les tests échouent pour une nouvelle raison, l'agent essaie de « corriger » l'échec qu'il a causé, et vingt minutes plus tard, l'arbre de travail est un enchevêtrement que personne ne peut rétablir proprement. Le modèle a fait exactement ce qu'un agent fait. Il a prédit une action suivante plausible et a demandé la permission, et la permission a été accordée par réflexe.

Le coût n'est rarement la seule mauvaise commande. C'est la perte d'un diff clair à réviser. Une fois qu'un agent a effectué quinze modifications et exécuté dix commandes dans une session qui dérive, vous ne pouvez plus dire quel changement était celui que vous vouliez et lequel était le nettoyage de sa propre erreur. La révision qui devrait prendre cinq minutes devient une fouille archéologique.

Bien faire cela est concret et apprenable. L'agent prédit une sortie plausible à partir de ce qui est dans son contexte, et plausible est le type dangereux, car cela semble correct jusqu'à ce que vous vérifiiez. Votre levier est trois portes que l'outil vous offre gratuitement : le contexte que vous fournissez avant qu'il ne commence, le plan que vous acceptez avant qu'il n'écrive, et le prompt de permission et le diff que vous lisez avant de conserver quoi que ce soit. Le mécanisme qui fait fonctionner ces portes est le système de permission et le mode plan, que la section suivante décompose.

Claude Code est une boucle agentique enveloppée dans un système de permissions. Nommer les parties vous montre exactement où vous placer pour garder le contrôle.

• La boucle. Lire, planifier, éditer, exécuter, réagir. Claude lit les fichiers pertinents, propose une étape, effectue une modification ou exécute une commande, observe le résultat, puis réagit. Chaque modification et chaque commande sont des moments où il s'arrête pour vous.
• Règles de permission. Dans settings.json, les outils sont triés en listes allow, ask et deny. Les règles s'évaluent dans l'ordre deny, puis ask, puis allow, donc une règle de refus l'emporte sur toute autorisation. Une règle comme Bash(rm -rf:*) en refus est une garantie ferme que l'instruction du prompt "soyez prudent avec les suppressions" ne peut jamais être ignorée.
• Modes de permission. Le mode définit la fréquence à laquelle la boucle s'arrête. Il y en a six : default (les lectures s'exécutent librement, tout le reste nécessite un prompt), acceptEdits (les modifications de fichiers et les commandes courantes du système de fichiers s'exécutent sans demander), plan (exploration en lecture seule), auto (un modèle de classification distinct évalue chaque action et bloque toute escalade), dontAsk (seuls les outils pré-approuvés s'exécutent, le reste est refusé), et bypassPermissions (aucun prompt du tout).
• Chemins protégés. Dans tous les modes sauf bypassPermissions, les écritures vers un petit ensemble de chemins comme .git, .claude, et votre configuration de shell ne sont jamais approuvées automatiquement, même si une règle d'autorisation semble les couvrir. Cela protège l'état de votre dépôt et la configuration propre de Claude d'une écrasement accidentel.

La distinction qui décide si une session reste sécuritaire est planifier versus construire. Le mode plan indique à Claude de rechercher et de proposer sans modifier votre source. Vous y entrez avec Shift+Tab, en préfixant un prompt avec /plan, ou en lançant claude --permission-mode plan. En mode plan, Claude lance souvent un sous-agent intégré Explore pour lire largement dans son propre contexte, puis retourne un plan écrit. Vous le lisez, l'éditez directement avec Ctrl+G si l'approche est incorrecte, et seulement alors vous l'approuvez. Approuver le plan est le moment où vous passez la session en mode construction et où les modifications commencent.

Une nuance qui piège les gens : un sous-agent fonctionne dans sa propre fenêtre de contexte séparée. Un sous-agent en avant-plan passe ses prompts de permission à vous au fur et à mesure qu'ils apparaissent. Un sous-agent en arrière-plan demande une seule fois les outils dont il aura besoin avant de se lancer, puis fonctionne avec ces permissions et refuse automatiquement tout autre élément qui nécessiterait autrement un prompt, donc une écriture qu'il n'a pas autorisée à l'avance échoue silencieusement plutôt que de s'arrêter pour vous. La règle pratique est de garder l'exploration à grande portée dans des sous-agents en lecture seule et de laisser la session parent, où vous pouvez voir chaque prompt, gérer les modifications et les commandes risquées. Avec les parties nommées, la section suivante guide une tâche à travers toute la boucle.

Maya, une développeuse, doit ajouter un assistant logout() à un module d'authentification existant dans un véritable dépôt. L'assistant doit effacer la session et rediriger vers /login, et il a besoin d'un test. Elle a déjà utilisé Claude Code et a été prise au dépourvu par une session dérivante, donc cette fois-ci, elle travaille les trois étapes délibérément.

1. Définir le contexte. Le dépôt a déjà un CLAUDE.md à la racine qui indique que le gestionnaire de paquets est pnpm, que l'authentification se trouve dans src/auth/, et que src/generated/ est hors limites. Ce fichier se charge automatiquement au début de la session, donc Maya ne retape rien de tout cela.
2. Délimiter le prompt. Elle tape un résultat, pas une liste de souhaits : "Dans src/auth/, ajoutez un assistant logout() qui efface la session et redirige vers /login. Écrivez un test dans src/auth/logout.test.ts pour le cas de déconnexion. Planifiez-le d'abord, puis exécutez la suite de tests, puis montrez-moi la différence."
3. Planifier d'abord. Elle appuie sur Shift+Tab pour passer en mode plan. Claude lit src/auth/session.ts et les tests existants via un sous-agent Explore et retourne un plan en quatre étapes. Le plan propose de toucher à src/auth/index.ts pour réexporter l'assistant, ce que Maya ne voulait pas encore. Elle ouvre le plan avec Ctrl+G et supprime cette étape.
4. Approuver pour réviser chaque modification. Elle approuve le plan modifié avec l'option de réviser chaque modification manuellement plutôt que l'option automatique. La session quitte le mode plan et commence à éditer sous surveillance étroite.
5. Approuver délibérément. Deux prompts d'écriture apparaissent, un pour l'assistant et un pour le test. Elle lit chaque différence et approuve. Un prompt Bash pour exécuter pnpm test apparaît. Elle lit la commande, confirme qu'il s'agit du testeur et non de quelque chose d'autre, et approuve.
6. Vérifier et valider. La suite rapporte 14 tests réussis, contre 13 auparavant. Maya lit la différence finale : deux fichiers modifiés, 23 lignes ajoutées, rien dans src/generated/. Elle valide avec un message d'une ligne, puis exécute /clear avant sa prochaine tâche pour que le contexte ne se poursuive pas.

Le changement entier a pris une session concentrée et a laissé une différence propre de deux fichiers qu'elle pouvait réviser en deux minutes. La différence par rapport à la version dérivante est que chaque étape a été lue, pas sautée, et le contexte n'a jamais été rempli de travaux non liés. Maya passe à la section suivante, car les étapes qui ont fonctionné ici sont exactement celles que les gens sont tentés de supprimer.

Chacun de ces pièges donne l'impression de vous accélérer, et chacun enlève discrètement l'étape qui vous gardait en sécurité.

• Approbation réflexe. Après une série de prompts inoffensifs, vous arrêtez de lire et commencez à approuver. La solution est de garder le mode default pour le travail non familier afin que les lectures s'exécutent librement tandis que les modifications et les commandes s'arrêtent encore, et de réellement lire la commande Bash dans chaque prompt. Si une classe de commande est vraiment sûre et fréquente, encodez-la comme une règle allow une fois plutôt que de l'approuver manuellement cinquante fois.
• Recourir au contournement pour arrêter le bruit. Les prompts deviennent agaçants, alors vous lancez avec --dangerously-skip-permissions sur votre machine réelle. Maintenant, il n'y a plus d'étape du tout, et l'injection de prompt à partir d'un fichier ou d'une page web n'a rien pour l'arrêter. Si vous avez besoin de moins de prompts, utilisez le mode auto, où un classificateur bloque encore les escalades, ou pré-approuvez les outils sûrs spécifiques. Réservez bypassPermissions pour un conteneur isolé ou une VM.
• La session tentaculaire. Une session pour "réorganiser l'authentification, corriger le test instable et mettre à jour la documentation" remplit le contexte de trois tâches à la fois, et les modifications pour l'une se mêlent à une autre. Exécutez /clear entre les tâches non liées pour que chacune commence à partir d'une fenêtre propre.
• Construire sans plan. Une demande vague directement en mode construction laisse l'agent deviner l'approche, et vous vous retrouvez à réviser une grande différence fondée sur une mauvaise hypothèse. Planifiez d'abord pour tout ce qui dépasse une correction d'une ligne, et éditez le plan avant de l'approuver.

Deux véritables cas limites se cachent sous ces pièges. Le chemin protégé qui semble autorisé. Vous ajoutez Edit(.claude/**) à vos règles d'autorisation en espérant que Claude gère ses propres paramètres, et il continue de demander. C'est par conception : la vérification du chemin protégé s'exécute avant que les règles d'autorisation ne soient évaluées, donc les écritures vers .git, .claude, et des chemins similaires restent protégées dans tous les modes sauf bypassPermissions. Considérez le prompt comme une fonctionnalité, pas un bug.

La grande différence qui dépasse votre révision. Une particularité de 2026 : un agent peut générer un changement plausible de 600 lignes plus rapidement que vous ne pouvez le lire, et la capacité de révision, pas le volume de code, est maintenant le goulot d'étranglement. Une différence aussi grande invite à l'approbation aveugle. La gestion consiste à garder chaque tâche suffisamment petite pour que sa différence tienne sous environ 400 lignes, ce qui est aussi là où les cycles de révision sont sensiblement plus rapides, et à s'appuyer sur le plan pour diviser un grand changement en étapes révisables. Garder les différences petites est encore plus important une fois que plus d'une personne partage le dépôt, c'est là que l'échelle entre en jeu.

Un développeur seul peut garder ses propres habitudes en tête. Dès qu'une équipe partage un dépôt, les paramètres et les conventions doivent vivre dans des fichiers versionnés, sinon chaque personne réapprend la même leçon et l'agent se comporte différemment pour chacun d'eux.

Les artefacts durables sont enregistrés dans le dépôt. Un CLAUDE.md à la racine enregistre les conventions que Claude lit à chaque début de session : le gestionnaire de paquets, la commande de test, quels répertoires sont hors limites, les règles "toujours faire X". Gardez-le sous environ 200 lignes et déplacez le matériel de référence plus long dans des compétences, car un CLAUDE.md gonflé dépense du contexte à chaque demande et commence à dériver. Le settings.json au niveau du projet contient les règles partagées allow, ask, et deny, donc un refus sur Bash(rm -rf:*) protège tout le monde, pas seulement celui qui a pensé à le définir. Pour des garanties fermes qu'une règle s'applique à chaque fois, un crochet PreToolUse qui bloque une commande est une application, là où une ligne dans CLAUDE.md n'est qu'une demande que le modèle peut contourner.

Priya, qui dirige l'équipe, emballe la configuration partagée pour que personne ne l'assemble à la main. Un plugin regroupe des compétences, des sous-agents, des crochets, et des serveurs MCP en une unité installable, et un marketplace la distribue. Elle publie un catalogue marketplace.json dans un dépôt git, et les coéquipiers exécutent /plugin marketplace add avec le dépôt, puis installent le plugin d'équipe à partir de celui-ci. Mettre à jour le plugin est un push vers le dépôt et un /plugin marketplace update sur chaque machine. La même discipline de révision s'applique à ce qui est installé : un plugin peut exécuter des crochets et connecter des serveurs MCP, donc l'équipe révise un marketplace avant de lui faire confiance de la même manière qu'elle réviserait toute dépendance.

L'échelle change aussi la façon dont le travail est enregistré. L'équipe de Priya écrit le rôle de l'agent et le prompt dans la description de la demande de tirage, afin qu'un réviseur sache qu'un changement a été rédigé par l'IA et ce qu'on lui a demandé de faire, et ils tiennent les PR rédigées par l'IA à la même barre de petites différences que toute autre. Les linter et les scanners automatisés dans le CI attrapent une grande part des problèmes de routine avant qu'un humain ne regarde, ce qui libère la révision humaine pour les hypothèses que l'agent a faites, la question étant "qu'est-ce que ce code suppose, et est-ce sûr ?" plutôt que "cela semble-t-il raisonnable ?".

Le principe durable à conserver, quelle que soit la taille de l'équipe, est que l'agent propose et vos étapes décident. Fournissez le contexte, acceptez le plan, lisez la différence, et ne troquez jamais les trois pour moins de prompts sur une machine qui vous tient à cœur. Commencez par une petite chose : écrivez un court CLAUDE.md pour un dépôt et exécutez votre prochaine tâche en mode plan. Ajoutez le reste, les règles de refus, les crochets, le plugin, un déclencheur à la fois au fur et à mesure que l'habitude se maintient.