50 conseils et bonnes pratiques pour utiliser Claude Code au quotidien

• Recueil de 50 conseils pratiques destiné aux développeurs qui utilisent déjà Claude Code, compilé à partir de la documentation officielle d’Anthropic, du développeur Boris Cherny, de l’expérience de la communauté et d’un an d’usage quotidien
• Couvre aussi bien les raccourcis de gestion de session comme l’alias cc, le préfixe ! ou le retour arrière avec Esc, que les sous-agents, les équipes d’agents et le travail parallèle avec worktree
• Inclut des méthodes structurées pour maintenir la qualité et la cohérence, comme la rédaction de CLAUDE.md, le système de Hooks et la gestion de la fenêtre de contexte
• Présente divers patterns de workflow, notamment l’usage d’outils CLI, le choix de serveurs MCP et le traitement par lots
• Recommande une adoption progressive : inutile d’appliquer les 50 d’un coup, commencez par celui qui vous a posé le plus de problèmes

---

1. Configurer l’alias cc

• Ajouter alias cc='claude --dangerously-skip-permissions' à ~/.zshrc (ou ~/.bashrc) permet de démarrer une session Claude Code en tapant simplement cc
• Ce réglage ignore toutes les demandes d’autorisation, et le nom du flag est intentionnellement alarmant
• À n’utiliser qu’après avoir parfaitement compris ce que Claude Code peut faire dans votre base de code

2. Exécuter des commandes bash inline avec le préfixe !

• En saisissant !git status ou !npm test, la commande s’exécute immédiatement, et la commande comme sa sortie restent dans le contexte
• Claude peut ensuite vérifier le résultat et enchaîner — c’est plus rapide que de demander à Claude d’exécuter la commande

3. Arrêter avec Esc, rembobiner avec Esc+Esc

• Esc interrompt Claude en cours de route sans perdre le contexte — vous pouvez changer de direction immédiatement
• Esc+Esc (ou /rewind) ouvre un menu déroulant avec tous les checkpoints créés par Claude, pour restaurer le code, la conversation ou les deux
  • 4 options de restauration : code et conversation, conversation seule, code seul, résumé depuis le checkpoint
• Cela permet de tenter même une approche dont vous n’êtes sûr qu’à 40 % — si ça échoue, le rembobinage permet un retour sans dégâts
  • Attention : les checkpoints ne suivent que les modifications de fichiers ; les changements liés aux commandes bash (migrations, opérations sur la base de données) ne sont pas capturés
• claude --continue reprend la conversation la plus récente, claude --resume ouvre le sélecteur de session

4. Donner à Claude les moyens de s’auto-vérifier

• Incluez dans le prompt des commandes de test, des vérifications de linter et la sortie attendue afin de créer une boucle de feedback permettant à Claude de repérer lui-même ses erreurs
  • Exemple : "Refactorise le middleware auth pour utiliser JWT. Une fois les changements faits, exécute la suite de tests existante, corrige tous les échecs, puis termine."
• Selon Boris Cherny, cela permet à lui seul une amélioration de qualité de 2 à 3 fois
• Pour les changements d’UI, configurez un serveur MCP Playwright afin que Claude puisse ouvrir un navigateur, interagir avec la page et vérifier que l’UI fonctionne comme prévu — cela permet d’attraper des problèmes que les tests unitaires ratent

5. Installer des plugins d’intelligence de code selon le langage

• Les plugins LSP fournissent des diagnostics automatiques après modification des fichiers (erreurs de type, imports inutilisés, types de retour manquants, etc.) — c’est le plugin unique au plus fort impact que vous puissiez installer
• Exemples de commandes d’installation :
  • /plugin install typescript-lsp@claude-plugins-official
  • /plugin install pyright-lsp@claude-plugins-official
  • /plugin install rust-analyzer-lsp@claude-plugins-official
  • /plugin install gopls-lsp@claude-plugins-official
• Des plugins pour C#, Java, Kotlin, Swift, PHP, Lua et C/C++ sont aussi disponibles dans l’onglet Discover de /plugin
• Le binaire du serveur de langage correspondant doit être installé sur le système (sinon le plugin le signalera)

6. Utiliser gh CLI et apprendre tous les outils CLI

• Avec gh CLI, vous pouvez gérer PR, issues et commentaires sans serveur MCP dédié — les outils CLI sont plus efficaces en contexte que les serveurs MCP (leur schéma d’outil n’est pas chargé dans la fenêtre de contexte)
• Même logique pour des outils CLI standard comme jq ou curl
• Si Claude ne connaît pas un outil, il peut lire la sortie de --help, en déduire la syntaxe et exécuter lui-même les commandes — par exemple : "Lis sentry-cli --help, puis trouve-moi l’erreur la plus récente en production"
• Cela fonctionne aussi avec des outils CLI internes très spécialisés

7. Ajouter "ultrathink" pour les raisonnements complexes

• Le mot-clé "ultrathink" règle l’effort sur élevé et active le raisonnement adaptatif sur Opus 4.6
• Idéal pour les décisions d’architecture, le débogage délicat ou les raisonnements en plusieurs étapes, quand Claude doit vraiment réfléchir avant d’agir
• Vous pouvez aussi définir ce comportement en permanence avec /effort — gardez un effort faible pour les tâches simples afin de rester rapide et peu coûteux
• Pas besoin de dépenser des tokens de réflexion pour renommer une variable — adaptez l’effort au problème

8. Étendre les connaissances à la demande avec les skills

• Les skills sont des fichiers Markdown qui étendent les connaissances de Claude ; contrairement à CLAUDE.md, ils ne sont chargés que pour les tâches concernées, ce qui allège le contexte
• Vous pouvez les créer dans .claude/skills/ ou installer des skills préconstruits fournis avec des plugins (à parcourir dans /plugin)
• Très adaptés à des connaissances métier spécialisées dont Claude a parfois besoin, mais pas en permanence, comme des règles d’API, des procédures de déploiement ou des patterns de code

9. Contrôler Claude Code depuis son téléphone

• Lancez une session avec claude remote-control, puis connectez-vous via claude.ai/code ou l’application Claude sur iOS/Android
• La session s’exécute sur votre machine locale ; le téléphone ou le navigateur n’est qu’un point d’accès — vous pouvez envoyer des messages, approuver des appels d’outils et suivre la progression
• Si vous utilisez l’alias cc de l’astuce n°1, aucune approbation supplémentaire n’est nécessaire, ce qui rend le contrôle à distance encore plus fluide — lancez une tâche, éloignez-vous, puis ne revenez vérifier que lorsque Claude a terminé ou rencontre un cas inattendu

10. Étendre la fenêtre de contexte à 1M de tokens

• Sonnet 4.6 comme Opus 4.6 prennent en charge une fenêtre de contexte de 1M de tokens
• Sur les offres Max, Team et Enterprise, Opus est automatiquement mis à niveau vers un contexte de 1M
• Vous pouvez changer de modèle pendant la session avec /model opus[1m] ou /model sonnet[1m]
• Si vous craignez une baisse de qualité avec un grand contexte, commencez par 500k puis augmentez progressivement pour tester
• CLAUDE_CODE_AUTO_COMPACT_WINDOW et CLAUDE_AUTOCOMPACT_PCT_OVERRIDE permettent de contrôler le moment où le compactage se déclenche

11. Utiliser le Plan Mode quand l’approche est incertaine

• Le Plan Mode convient bien aux changements sur plusieurs fichiers, au code peu familier et aux décisions d’architecture — investir quelques minutes en amont évite que Claude passe 20 minutes à résoudre le mauvais problème
• Inutile pour les tâches petites et au périmètre clair — si vous pouvez résumer le diff en une phrase, exécutez directement
• Shift+Tab permet de basculer entre les modes d’autorisation Normal, Auto-Accept et Plan (sans quitter la conversation)

12. Exécuter /clear entre des tâches sans rapport

• Un prompt précis dans une session propre est meilleur qu’une session confuse de 3 heures — pour une autre tâche, commencez par /clear
• On a l’impression de jeter l’avancement, mais le contexte accumulé finit par noyer l’instruction en cours et donne la sensation de perdre 30 minutes de rendement
• Les 5 secondes nécessaires pour faire /clear et rédiger un prompt de départ ciblé sont bien plus efficaces

13. Ne pas interpréter les bugs, coller les données brutes

• Si vous décrivez un bug avec vos mots, Claude entre dans un processus lent où il devine, corrige, puis recommence
• Collez directement les logs d’erreur, la sortie CI ou un thread Slack et dites simplement "corrige" ; Claude pourra lire des logs de système distribué et remonter jusqu’au point de panne
• L’interprétation humaine ajoute une couche d’abstraction qui fait perdre des détails nécessaires pour que Claude identifie précisément la cause racine
• Cela vaut aussi pour la CI — demandez : "Va corriger les tests CI qui échouent" en collant la sortie CI, ou donnez l’URL / le numéro de PR en demandant de corriger les checks en échec
• Vous pouvez aussi pipe directement la sortie du terminal :
  • cat error.log | claude "explain this error and suggest a fix"
  • npm test 2>&1 | claude "fix the failing tests"

14. Questions annexes rapides avec /btw

• /btw ouvre un overlay qui n’entre pas dans l’historique de la conversation, pour poser des questions rapides
• À utiliser pour demander des clarifications sur la session en cours : « Pourquoi as-tu choisi cette approche ? » ou « Quels sont les compromis par rapport aux autres options ? »
• Les réponses s’affichent dans un overlay que l’on peut fermer, ce qui permet de garder le contexte principal léger

15. Exécuter des branches parallèles isolées avec --worktree

• claude --worktree feature-auth crée une copie de travail isolée et une nouvelle branche — Claude gère automatiquement la configuration et le nettoyage du git worktree
• L’équipe Claude Code considère cela comme l’un des plus gros déblocages de productivité
• Lancez 3 à 5 worktrees pour exécuter en parallèle des sessions Claude indépendantes (en pratique, 2 à 3 le plus souvent)
• Chaque worktree dispose de sa propre session, de sa propre branche et de son propre état du système de fichiers
• La limite des worktrees locaux vient des ressources de la machine — plusieurs serveurs de dev, builds et sessions Claude se disputent le CPU
  • Builder.io place chaque agent dans un conteneur cloud distinct pour soulager la charge machine

16. Sauvegarder temporairement un prompt avec Ctrl+S

• Si vous rédigez un long prompt mais avez d’abord besoin d’une réponse rapide, utilisez Ctrl+S pour mettre le brouillon de côté
• Après avoir envoyé la question rapide, le prompt mis de côté est restauré automatiquement

17. Basculer une tâche longue en arrière-plan avec Ctrl+B

• Si Claude lance une commande bash longue (suite de tests, build, migration), utilisez Ctrl+B pour la basculer en arrière-plan
• Claude continue de travailler et vous pouvez continuer à discuter — les résultats s’affichent quand le processus se termine

18. Ajouter une barre d’état en direct

• La barre d’état est un script shell exécuté après chaque tour de Claude, qui affiche en bas du terminal le répertoire courant, la branche git et l’utilisation du contexte avec un code couleur
• La commande /statusline permet une configuration rapide — elle demande ce qu’il faut afficher et génère automatiquement le script

19. Garder le contexte principal propre avec des sous-agents

• Si vous dites « Utilise un sous-agent pour comprendre comment le flux de paiement gère les transactions échouées », une instance Claude distincte lit et analyse les fichiers dans sa propre fenêtre de contexte, puis renvoie un résumé concis
• Une recherche approfondie peut consommer la moitié de la fenêtre de contexte ; les sous-agents permettent donc d’isoler ce coût de la session principale
• Types intégrés : Explore (Haiku, recherche rapide dans les fichiers), Plan (analyse en lecture seule)

20. Une équipe d’agents pour coordonner plusieurs sessions

• Fonction expérimentale mais puissante — activez-la en ajoutant CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS à la configuration ou aux variables d’environnement
• Donnez par exemple l’instruction : « Crée une équipe de 3 agents pour refactorer ces modules en parallèle »
• Un chef d’équipe répartit le travail entre les membres, chacun ayant sa propre fenêtre de contexte et une liste de tâches partagée, avec possibilité de s’envoyer des messages directement
• Il est recommandé de commencer avec 3 à 5 membres et 5 à 6 tâches par membre
• Évitez d’assigner à plusieurs agents des tâches qui modifient le même fichier, à cause des problèmes d’écrasement — commencez par des tâches de recherche et de review, puis étendez à l’implémentation en parallèle

21. Ajouter des instructions de conservation lors de la compaction

• Lors d’une compaction du contexte (automatique ou via /compact), vous pouvez indiquer ce qu’il faut conserver : /compact focus on the API changes and the list of modified files
• Vous pouvez aussi ajouter une instruction permanente dans CLAUDE.md : « Lors de la compaction, conserve la liste complète des fichiers modifiés et l’état actuel des tests »

22. Exécuter des vérifications répétées avec /loop

• /loop 5m check if the deploy succeeded and report back permet de planifier un prompt récurrent en arrière-plan
• L’intervalle est facultatif (10 minutes par défaut) et prend en charge les unités s, m, h et d
• Vous pouvez aussi boucler sur d’autres commandes, comme /loop 20m /review-pr 1234
• Les tâches sont limitées à la session et expirent au bout de 3 jours — une boucle oubliée ne tourne donc pas indéfiniment
• Utile pour surveiller un déploiement, suivre un pipeline CI ou interroger périodiquement un service externe

23. Rédiger des prompts plus riches avec la dictée vocale

• /voice active le push-to-talk ; maintenez la touche Espace et parlez, la transcription en temps réel est insérée dans le prompt
• Vous pouvez mélanger voix et saisie dans un même message
• Les prompts vocaux contiennent naturellement davantage de contexte que ceux tapés — vous pouvez expliquer le contexte, les contraintes et le résultat attendu sans l’effort de frappe
• Un compte Claude.ai est requis (pas une clé API)
• Vous pouvez reconfigurer la touche push-to-talk dans ~/.claude/keybindings.json, par exemple en meta+k, afin d’éviter la phase de préchauffage de détection de maintien

24. Si le problème n’est toujours pas résolu après deux correctifs, repartez de zéro

• Si vous vous enfoncez dans un tunnel de corrections et que le problème n’est toujours pas résolu, le contexte se remplit alors d’approches qui ont échoué, ce qui nuit aux tentatives suivantes
• Utilisez /clear, puis redémarrez avec un meilleur prompt de départ intégrant ce que vous avez appris
• Une session propre avec un prompt affûté surpasse presque toujours une longue session encombrée d’impasses accumulées

25. Indiquer précisément à Claude quels fichiers regarder

• Référencez directement un fichier avec le préfixe @, par exemple @src/auth/middleware.ts has the session handling
• Le préfixe @ est automatiquement interprété comme un chemin de fichier, ce qui permet à Claude d’identifier immédiatement le bon emplacement
• Claude peut aussi utiliser grep ou la recherche de son côté, mais le processus pour réduire les candidats et identifier le bon fichier consomme des tokens et du contexte — préciser le fichier dès le départ évite tout ce travail

26. Explorer du code peu familier avec des prompts ambigus

• « Qu’est-ce que tu améliorerais dans ce fichier ? » est un excellent prompt d’exploration — tous les prompts n’ont pas besoin d’être précis
• Quand vous avez besoin d’un regard neuf sur du code existant, une question ambiguë laisse à Claude la possibilité de repérer l’inattendu
• Utile pour découvrir un dépôt que vous ne connaissez pas bien — Claude peut signaler des patterns, des incohérences et des opportunités d’amélioration que l’on manque facilement à la première lecture

27. Modifier un plan avec Ctrl+G

• Quand Claude propose un plan, utilisez Ctrl+G pour l’ouvrir directement dans un éditeur de texte et le modifier
• Vous pouvez ajouter des contraintes, retirer des étapes ou changer d’approche avant que Claude n’écrive la moindre ligne de code
• Pratique lorsque le plan est globalement bon mais que vous souhaitez ajuster seulement quelques étapes, sans tout réexpliquer

28. Après /init, réduisez le résultat de moitié

• CLAUDE.md est un fichier Markdown situé à la racine du projet, qui fournit à Claude des instructions permanentes sur les commandes de build, les standards de code, les décisions d’architecture, les conventions du dépôt, etc.
• Claude le lit au début de chaque session
• /init génère une version brouillon à partir de la structure du projet — il détecte automatiquement les commandes de build, les scripts de test et l’organisation des répertoires
• La sortie a tendance à être trop volumineuse — supprimez toute ligne dont vous ne pouvez pas expliquer la raison d’être, puis ajoutez ce qui manque

29. Le test décisif pour chaque ligne de CLAUDE.md

• Pour chaque ligne de CLAUDE.md, posez-vous la question : « Sans cette ligne, Claude ferait-il une erreur ? »
• Les instructions que Claude suit déjà correctement sont du bruit — les lignes inutiles diluent les plus importantes
• Il existe une limite d’environ 150 à 200 instructions avant que le taux de conformité ne baisse, et le prompt système en utilise déjà environ 50

30. Après une erreur de Claude, dire « Mets à jour CLAUDE.md pour que cela ne se reproduise plus »

• Si Claude commet une erreur, dites-lui : « update the CLAUDE.md file so this doesn't happen again »
• Claude rédige alors sa propre règle et la respectera automatiquement dès la session suivante
• Avec le temps, CLAUDE.md évolue en document vivant façonné par les erreurs réelles
• Pour éviter une croissance infinie, utilisez @imports (conseil n°32) pour référencer un fichier séparé (@docs/solutions.md, par exemple) — CLAUDE.md reste léger et Claude lit les détails seulement quand nécessaire

31. Appliquer des règles conditionnelles avec .claude/rules/

• Placez des fichiers Markdown dans .claude/rules/ pour organiser les consignes par sujet — par défaut, tous les fichiers de règles sont chargés au début de la session
• Avec le frontmatter paths, vous pouvez activer les règles de façon conditionnelle uniquement pour certains motifs de fichiers :
  • Exemple : si vous définissez paths: ["**/*.ts"], Claude ne chargera les règles TypeScript que lorsqu’il lit des fichiers .ts
• Gardez le fichier principal CLAUDE.md léger — Claude ne lit pas les règles des langages sur lesquels il ne travaille pas actuellement

32. Garder CLAUDE.md léger avec @imports

• Référencez des documents comme @docs/git-instructions.md — @README.md, @package.json, @~/.claude/my-project-instructions.md sont aussi possibles
• Claude ne lit les fichiers qu’en cas de besoin — cela sert à ajouter du contexte uniquement si nécessaire, sans alourdir CLAUDE.md, qui est chargé à chaque session

33. Configurer une liste blanche de commandes sûres avec /permissions

• Arrêtez de cliquer pour la centième fois sur l’approbation de npm run lint — avec /permissions, vous pouvez ajouter les commandes de confiance à la liste blanche
• Les commandes absentes de la liste continueront d’afficher une demande de confirmation

34. Autoriser Claude à travailler plus librement avec /sandbox

• Activez l’isolation au niveau du système d’exploitation avec /sandbox — l’écriture est limitée au répertoire du projet, et les requêtes réseau ne sont autorisées que vers des domaines approuvés
• Sur macOS, cela utilise Seatbelt ; sur Linux, bubblewrap ; les restrictions s’appliquent à tous les sous-processus générés par Claude
• En mode auto-allow, les commandes exécutées dans le sandbox s’exécutent sans invite d’autorisation — une quasi-autonomie avec garde-fous
• Pour le travail sans supervision (migrations de nuit, refactorings expérimentaux), exécutez Claude dans un conteneur Docker afin d’obtenir une isolation complète et un rollback facile

35. Créer des sous-agents personnalisés pour les tâches répétitives

• Contrairement au sous-agent improvisé de l’astuce n°19, les sous-agents personnalisés sont préconfigurés et enregistrés dans .claude/agents/
  • Exemples : un agent relecteur sécurité avec Opus + outils en lecture seule, ou un agent de recherche rapide avec Haiku
• Utilisez /agents pour les parcourir et en créer
• Avec isolation: worktree, vous pouvez configurer un agent avec un système de fichiers indépendant

36. Choisir les serveurs MCP adaptés à votre stack

• Serveurs MCP intéressants pour commencer : Playwright (tests navigateur et validation d’UI), PostgreSQL/MySQL (requêtes directes sur le schéma), Slack (rapports de bugs et contexte des fils), Figma (workflow design → code)
• Claude Code prend en charge le chargement dynamique des outils — Claude ne charge les définitions de serveur que lorsqu’il en a besoin

37. Définir un style de sortie

• Choisissez votre style préféré dans /config — options intégrées : Explanatory (détaillé, étape par étape), Concise (bref, orienté action), Technical (précis, à l’aise avec la terminologie spécialisée)
• Vous pouvez aussi créer des fichiers de styles de sortie personnalisés dans ~/.claude/output-styles/

38. CLAUDE.md propose, les Hooks imposent

• CLAUDE.md est indicatif — Claude le suit à environ 80 %
• Les Hooks sont déterministes — exécution à 100 %
• Tout ce qui doit absolument s’exécuter à chaque fois, sans exception (formatage, linting, vérifications de sécurité), doit être configuré en Hook
• Pour des consignes que Claude doit simplement prendre en compte, CLAUDE.md suffit

39. Formatage automatique avec un Hook PostToolUse

• Ajoutez un Hook PostToolUse dans .claude/settings.json pour que le formateur s’exécute automatiquement chaque fois que Claude modifie un fichier
  • Enregistrez npx prettier --write "$CLAUDE_FILE_PATH" 2>/dev/null || true sur le matcher Edit|Write
• Avec || true, vous évitez qu’un échec du Hook ne bloque Claude
• Vous pouvez chaîner npx eslint --fix comme deuxième entrée de Hook
• Si votre éditeur a le même fichier ouvert, mieux vaut désactiver le format-on-save — il a été signalé qu’un enregistrement de l’éditeur peut invalider le cache de prompt ; le Hook se charge alors du formatage

40. Bloquer les commandes destructrices avec un Hook PreToolUse

• Bloquez les motifs rm -rf, drop table, truncate avec un Hook PreToolUse — Claude n’essaiera même pas de les exécuter
• Le Hook se déclenche avant que Claude n’exécute l’outil et bloque à l’avance les commandes destructrices
• Ajoutez-le dans .claude/settings.json, configurez-le de façon interactive avec /hooks, ou demandez à Claude : « ajoute un Hook PreToolUse qui bloque les commandes rm -rf, drop table, truncate »

41. Préserver le contexte important lors de la compaction avec des Hooks

• Dans les longues sessions, lorsque le contexte est compacté, Claude peut perdre le fil de ce qui est en cours
• Un Hook de notification avec le matcher compact réinjecte automatiquement le contexte essentiel à chaque déclenchement de la compaction
• Demandez à Claude : « configure un Hook de notification qui, après compaction, rappelle la tâche en cours, les fichiers modifiés et les contraintes »
• Bon contenu à réinjecter : description de la tâche actuelle, liste des fichiers modifiés, contraintes strictes (« ne modifie pas les fichiers de migration »)
• C’est surtout utile dans les sessions de plusieurs heures où Claude est très engagé dans une fonctionnalité et ne doit pas perdre le contexte

42. Authentification, paiements et mutations de données : revue manuelle obligatoire

• Flux d’authentification, logique de paiement, mutations de données, opérations DB destructrices — même si tout le reste du code semble bon, il faut impérativement une revue humaine
• Une mauvaise portée d’authentification, un webhook de paiement mal configuré, ou une migration qui supprime silencieusement une colonne peuvent faire perdre des utilisateurs, de l’argent et de la confiance
• Aucun volume de tests automatisés ne permet de détecter tous ces problèmes

43. Tester une autre approche avec /branch sans perdre votre piste actuelle

• Utilisez /branch (ou /fork) pour créer une copie de la conversation à partir de l’état actuel
• Tentez un refactoring risqué dans la branche — si ça marche, gardez-la ; sinon, la conversation d’origine reste intacte
• Contrairement au rewind (astuce n°3), les deux chemins restent vivants

44. Demander à Claude de vous interviewer quand la spec est incomplète

• Si vous savez ce que vous voulez construire mais qu’il manque tous les détails nécessaires pour que Claude le fasse correctement, demandez-lui de poser des questions
  • « Je veux créer [brève description]. Utilise l’outil AskUserQuestion pour m’interviewer en détail. Pose des questions sur l’implémentation technique, les cas limites, les préoccupations et les compromis. Ne pose pas de questions évidentes. Continue jusqu’à ce que tout soit couvert, puis rédige une spec complète dans SPEC.md »
• Une fois la spec terminée, lancez l’implémentation dans une nouvelle session avec un contexte propre et une spec complète

45. Un Claude code, un autre Claude relit

• Laissez le premier Claude implémenter la fonctionnalité, puis demandez à un second Claude de la relire comme un staff engineer, avec un contexte vierge
• Le relecteur n’a pas de connaissance préalable des raccourcis pris dans l’implémentation, donc il remet tout en question
• La même idée s’applique au TDD : la session A écrit les tests, la session B écrit le code qui les fait passer

46. Faire la revue de PR de manière interactive

• Au lieu de demander une revue de PR en one-shot (même si c’est possible), ouvrez la PR dans une session et menez une conversation
  • « Explique le changement le plus risqué de cette PR »
  • « Si cela s’exécute en parallèle, qu’est-ce qui casse ? »
  • « La gestion des erreurs est-elle cohérente avec le reste de la base de code ? »
• La revue interactive détecte davantage de problèmes — parce qu’elle permet d’approfondir les zones importantes
• Les revues en one-shot ont tendance à signaler des détails de style et ratent plus facilement les problèmes d’architecture

47. Donner un nom et une couleur à vos sessions

• Avec /rename auth-refactor, affichez un label dans la barre de prompt
• Avec /color red ou /color blue, définissez la couleur de la barre de prompt
  • Couleurs disponibles : red, blue, green, yellow, purple, orange, pink, cyan
• Si vous faites tourner 2 ou 3 sessions en parallèle, investir 5 secondes dans un nom et une couleur permet d’éviter les erreurs de saisie dans le mauvais terminal

48. Lire un son à la fin de Claude

• Avec un Stop Hook, lire un son système quand Claude a terminé de répondre
• Lancer une tâche, passer à autre chose, puis être notifié par un ping à la fin
• Exemple : enregistrer /usr/bin/afplay /System/Library/Sounds/Glass.aiff comme Stop Hook dans .claude/settings.json

49. Répartir des traitements batch avec claude -p

• Utiliser le mode non interactif pour parcourir une liste de fichiers en boucle — avec --allowedTools, limiter pour chaque fichier le périmètre des actions autorisées à Claude
• Utiliser & pour une exécution en parallèle afin d'obtenir le débit maximal :
  • for file in $(cat files-to-migrate.txt); do claude -p "Migrate $file from class components to hooks" --allowedTools "Edit,Bash(git commit *)" & done; wait
• Bien adapté aux conversions de formats de fichiers, aux mises à jour d'imports à l'échelle de tout le codebase et aux migrations répétitives où chaque fichier est indépendant

50. Personnaliser les verbes du spinner (pour le fun)

• Pendant que Claude réfléchit, le terminal affiche des verbes de spinner comme "Flibbertigibbeting..." ou "Flummoxing..."
• Vous pouvez les remplacer par les formulations de votre choix — dites à Claude :
  • "Replace my spinner verbs in user settings with these: Hallucinating responsibly, Pretending to think, Confidently guessing, Blaming the context window"
• Vous n'avez pas besoin de fournir la liste vous-même — il suffit de donner une ambiance, comme "Replace my spinner verbs with Harry Potter spells", et Claude générera la liste
• Une petite personnalisation qui rend l'attente plus amusante