Les 9 conseils pratiques de Boris sur Claude Code : en réalité, la configuration des experts est si "simple". Boris Cherny a un surnom au sein d'Anthropic : le père de Claude Code. Il est récemment très actif sur X, donc beaucoup de gens demandent à Boris : comment utilises-tu Claude Code ? Il a récemment partagé 9 conseils pratiques sur X. Il n'y a pas autant de conseils que vous pourriez l'imaginer, chacun est simple et sans fioritures. 【1】Idée principale : il n'y a pas de réponse standard aux meilleures pratiques de Claude Code. Boris commence par dire : > My setup might be surprisingly vanilla! Claude Code works great out of the box, so I personally don't customize it much. > Ma configuration pourrait vous surprendre par sa "simplicité". Claude Code fonctionne très bien dès la sortie de la boîte, donc je ne le personnalise pas beaucoup. On peut comprendre que ces meilleures pratiques, comme les Skills et les Plugins, en tant que développeurs de Claude Code, ils ont déjà intégré ces meilleures pratiques en tant que fonctionnalités. Il n'y a pas de manière unique de travailler avec Claude Code. L'équipe l'a délibérément conçu pour être manipulé de manière flexible, vous pouvez l'utiliser comme vous le souhaitez, le modifier comme bon vous semble. Chaque membre de l'équipe Claude Code l'utilise de manière complètement différente. Il n'est donc pas nécessaire de chercher désespérément la "meilleure pratique", le plus important est de trouver le rythme qui vous convient. 【2】Tâches multiples en parallèle : ouvrir plusieurs Claude en même temps. Le quotidien de Boris est le suivant : il ouvre 5 instances de Claude Code dans le terminal, numérotées de 1 à 5, avec les notifications système activées, et il passe à l'instance qui nécessite une entrée. En même temps, il exécute 5 à 10 tâches sur la version web. Le terminal et le web peuvent se "transférer" : en utilisant le symbole & pour transférer la session locale vers le web, ou en utilisant --teleport pour basculer d'un côté à l'autre. Chaque matin et pendant la journée, il lance quelques tâches depuis l'application Claude sur son téléphone, puis revient plus tard pour voir les résultats. Cette méthode de travail "multithread" repose sur la logique suivante : Claude Code excelle dans l'exécution autonome, de nombreuses tâches ne nécessitent pas votre attention constante. Vous lancez une tâche, donnez une direction, laissez-la fonctionner, et vous pouvez vous occuper d'autres choses. Revenez seulement quand il a besoin de votre confirmation. C'est un rythme complètement différent de celui de la "programmation traditionnelle où l'homme tape une ligne de code et l'IA en complète quelques autres". Mais cela exige également plus de l'utilisateur, vous devez être bon pour attribuer des tâches à l'Agent et pouvoir passer d'une tâche à l'autre à tout moment. Pour ceux qui sont habitués à développer eux-mêmes, avec une seule tâche à la fois, c'est un grand défi. Je dois avouer que, bien que j'utilise souvent Coding Agent, je ne suis pas encore habitué à faire fonctionner trop de tâches en même temps, je dois renforcer cette pratique cette année. 【3】Choix du modèle : pourquoi utiliser Opus plutôt qu'un Sonnet plus rapide. Boris dit qu'il utilise Opus 4.5 avec le mode de réflexion pour toutes ses tâches. C'est le meilleur modèle de programmation qu'il ait utilisé. Certaines personnes pourraient demander : Opus n'est-il pas plus grand et plus lent que Sonnet ? La réponse de Boris est : bien que la réponse soit un peu plus lente, vous devez le corriger beaucoup moins souvent, les appels d'outils sont également plus précis, ce qui, au final, est plus rapide. Je suis d'accord avec cela, écrire du code ne doit pas être une question de rapidité, mais de qualité. Si un modèle rapide nécessite que vous le corrigiez trois fois, il vaut mieux utiliser un modèle plus lent qui résout tout en une fois. Le temps n'est pas seulement le temps de réponse du modèle, mais aussi le coût de votre attention et de votre énergie. Le seul problème est que le coût d'Opus est plus élevé. 【4】 est un fichier de configuration spécial pour Claude Code, placé dans le répertoire racine du projet. Chaque fois que Claude Code est lancé, il lit automatiquement ce fichier et utilise son contenu comme "connaissances de base". Vous pouvez le comprendre comme : c'est le manuel de projet que vous écrivez pour l'IA, lui indiquant l'architecture, les normes et les points d'attention de ce projet. L'équipe de Boris a la pratique suivante : l'ensemble du dépôt Claude Code est partagé dans un Git, et tout le monde y contribue. Chaque semaine, quelqu'un y ajoute des éléments. La règle est simple : chaque fois que vous voyez Claude faire une erreur, écrivez "ne faites pas cela" et la prochaine fois, il le saura. Plus intéressant encore, ils utilisent également ce mécanisme lors des revues de code. Boris mentionne @.claude dans les PR de ses collègues, demandant à Claude d'ajouter une nouvelle règle à . Cela est réalisé grâce à l'action GitHub de Claude Code. Dan Shipper appelle cette pratique "ingénierie des intérêts composés" : chaque correction devient un actif pour l'équipe, permettant à l'IA de mieux comprendre leur projet. Si vous n'avez pas encore utilisé la commande , Claude analysera automatiquement la structure du projet et générera une version initiale. Ensuite, vous pouvez l'utiliser et compléter, en ajoutant ce qui ne va pas. 【5】Mode Plan : réfléchissez d'abord avant d'agir. Boris dit que la plupart de ses sessions commencent par le mode Plan. Dans Claude Code, il suffit d'appuyer deux fois sur Shift+Tab pour basculer. En mode Plan, Claude ne modifie pas directement le code, mais vous donne d'abord un plan d'exécution. Vous pouvez discuter et modifier le plan jusqu'à ce que vous soyez satisfait. Ensuite, passez en mode d'acceptation automatique, Claude peut généralement tout accomplir en une seule fois. "Un bon plan est vraiment important", cette habitude transpose en réalité la sagesse classique du développement logiciel dans la collaboration avec l'IA : concevoir d'abord, puis coder. Beaucoup de gens qui utilisent l'IA pour écrire du code commencent directement, ce qui entraîne des coûts de retouche élevés si la direction est erronée. Passer quelques minutes à aligner le plan peut économiser des heures de retouche. 【6】Automatisation des tâches répétitives : commandes slash et sous-agents. Boris a plusieurs opérations qu'il utilise des dizaines de fois par jour, il les a transformées en commandes slash. Par exemple, "/commit-push-pr", qui exécute en un clic la soumission, le push et la création de PR. Les commandes slash sont essentiellement des fichiers Markdown, placés dans le répertoire .claude/commands/. Vous pouvez écrire des instructions en langage naturel et même intégrer des scripts bash pour prélever certaines informations, réduisant ainsi le nombre d'appels du modèle. Ces commandes peuvent être soumises à Git et partagées par toute l'équipe. En plus des commandes slash, il utilise également des sous-agents (un Agent est une instance indépendante de Claude, spécialisée dans un type de travail. Par exemple, il a un sous-agent code-simplifier qui simplifie automatiquement le code après que le Claude principal a terminé son travail ; et un sous-agent verify-app, responsable des tests de bout en bout. Ces deux fonctionnalités ont en commun de : solidifier les tâches que vous effectuez de manière répétée, permettant à Claude de les appeler lui-même. Vous n'avez pas besoin de réexpliquer chaque fois, ni de vous souvenir des détails des différentes commandes. Utilisez le PostToolUse Hook pour formater le code généré par Claude. Claude peut généralement générer du code bien formaté automatiquement, et ce Hook s'occupe des derniers 10 % du code pour éviter les erreurs de format lors du processus d'intégration continue (CI). 【7】Sécurité et intégration : configuration des autorisations et outils externes. Boris n'utilise pas l'option "dangereusement ignorer les autorisations". Au contraire, il utilise la commande /permissions pour approuver à l'avance certaines commandes de sécurité courantes, évitant ainsi d'avoir à confirmer à chaque fois. Ces configurations sont enregistrées dans .claude/settings.json et partagées par l'équipe. Plus puissant encore est l'intégration du serveur MCP. MCP signifie Model Context Protocol, un protocole standard lancé par Anthropic pour connecter l'IA à des outils externes. Grâce à MCP, Claude Code peut directement : - Rechercher et envoyer des messages Slack - Exécuter des requêtes BigQuery pour répondre à des questions de données - Récupérer des journaux d'erreurs depuis Sentry L'équipe de Boris a également soumis la configuration MCP de Slack dans le dépôt, permettant à tout le monde de l'utiliser dès la sortie de la boîte. Cela signifie que Claude Code n'est pas seulement un outil de programmation, mais un "assistant polyvalent" capable d'appeler l'ensemble de votre chaîne d'outils. 【8】Gestion des longues tâches : laissez Claude valider par lui-même. Pour les tâches qui prennent beaucoup de temps, Boris a plusieurs stratégies : D'une part, il laisse Claude valider automatiquement les résultats avec un agent en arrière-plan une fois terminé. Vous pouvez le demander dans le prompt, ou utiliser le Stop Hook pour déclencher cela de manière plus déterministe. > Remarque : Les Hooks sont le mécanisme de "crochets" de Claude Code, vous permettant d'insérer une logique personnalisée à des moments spécifiques où Claude exécute des opérations. Vous pouvez le comprendre comme un "déclencheur" : lorsque certains événements se produisent, exécutez automatiquement les commandes ou scripts que vous avez préétablis. > Le Stop Hook se déclenche lorsque Claude a terminé sa réponse et est prêt à rendre le contrôle. > Documentation associée : D'autre part, il utilise le plugin ralph-wiggum, qui est essentiellement une "boucle Bash" : imaginez une simple boucle infinie (while true) qui alimente sans cesse le même manuel de tâches (fichier de prompt) à l'agent IA, lui permettant d'améliorer son travail encore et encore jusqu'à ce qu'il soit complètement terminé. Troisièmement, dans un environnement sandbox, il utilise --permission-mode=dontAsk ou --dangerously-skip-permissions, permettant à Claude de ne pas être interrompu par des confirmations d'autorisation et de continuer jusqu'à la fin. L'idée principale est : puisque ce sont des tâches longues, ne le laissez pas vous attendre. Donnez-lui suffisamment d'autonomie et de capacité d'auto-correction. 【9】Le plus important : donner à Claude la capacité de valider. Boris a mis ce point à la fin, disant que c'est peut-être le facteur le plus important pour obtenir de bons résultats. Si Claude peut valider son propre travail, la qualité de la production finale peut être multipliée par 2 à 3. Il donne un exemple : chaque modification qu'ils soumettent à est testée par Claude à l'aide d'une extension Chrome : il ouvre le navigateur, teste l'interface utilisateur, détecte les problèmes et itère jusqu'à ce que la fonctionnalité soit correcte et l'expérience raisonnable. Les méthodes de validation varient selon le contexte. Cela peut être l'exécution d'une commande bash, l'exécution d'une suite de tests, ou le test d'une application dans un navigateur ou un simulateur de téléphone. La forme n'est pas importante, ce qui compte, c'est : donner à l'IA un retour d'information. Ce principe est en réalité très simple. Les ingénieurs humains s'appuient également sur le cycle "écrire du code - tester - voir les résultats - modifier" pour garantir la qualité. L'IA fonctionne de la même manière. Si elle ne peut que coder sans tester, c'est comme travailler les yeux fermés, la qualité dépend entièrement de la chance. Le conseil de Boris est : investissez de l'énergie pour solidifier le mécanisme de validation. C'est l'investissement le plus rentable. 【10】Les experts utilisent l'épée sans mouvements, surpassant les mouvements. Dans les romans d'arts martiaux, les experts n'ont pas de mouvements compliqués avec leur épée, l'absence de mouvements surpasse les mouvements. Boris ne vante pas des configurations personnalisées complexes, ni des astuces secrètes, il utilise simplement les fonctionnalités officielles. La différence réside dans le fait qu'il comprend réellement la logique derrière ces fonctionnalités, puis les combine en un flux de travail efficace. Le travail parallèle est possible parce que Claude peut exécuter de manière autonome ; utiliser Opus est dû à une efficacité globale plus élevée ; transforme les corrections en actifs ; le mode Plan consiste à réfléchir avant d'agir ; les commandes slash et les sous-agents automatisent le travail répétitif ; le mécanisme de validation fournit un retour d'information à l'IA. Si vous débutez avec Claude Code, ne vous précipitez pas pour explorer toutes les configurations avancées. Commencez par bien maîtriser les bases : apprenez à travailler en parallèle, à planifier, et à accumuler des moyens de validation pour l'IA. Lorsque vous rencontrerez réellement des obstacles, vous pourrez alors vous pencher sur ces astuces plus complexes.

Boris n'a pas mentionné un point important, à savoir le workflow de CI/revue de code de base. Pour les grandes entreprises habituées à cela, c'est quelque chose de normal, qui devrait être par défaut. Par exemple, lorsqu'il termine une tâche avec Claude Code, il ne fusionne pas directement dans la branche principale, mais soumet une PR. Après avoir soumis la PR, tous les lint et tests automatisés s'exécutent automatiquement sur le serveur CI. Si les tests échouent, la PR ne peut pas être fusionnée. Une PR qui a passé tous les tests automatisés doit encore être examinée par quelqu'un (bien sûr, l'IA peut aider, mais une confirmation humaine est toujours nécessaire). Si des problèmes sont découverts lors de la revue de code, des modifications doivent être apportées. De nombreux développeurs individuels n'ont pas l'habitude de mettre en place un workflow de CI/revue de code, et certains n'ont même pas mis en place la gestion de code avec Git, ce qui rend impossible le retour en arrière en cas de problème.

【10】 Les choses que vous ne pouvez pas voir Boris n'a pas mentionné un point important, à savoir la gestion de code source de base / CI (intégration continue) / le workflow de révision de code, des choses qui peuvent sembler normales pour les grandes entreprises habituées à cela, des choses qui devraient être par défaut. Par exemple, lorsqu'il utilise Claude Code pour terminer une tâche, il ne fusionne pas directement dans la branche principale, mais soumet une PR. Après avoir soumis la PR, tous les lint et tests automatisés s'exécutent automatiquement sur le serveur CI, et si les tests échouent, la PR ne peut pas être fusionnée. Une PR qui a passé tous les tests automatisés doit encore être examinée par quelqu'un (bien sûr, l'IA peut aider, mais une confirmation humaine est toujours nécessaire). Si des problèmes sont découverts lors de la révision de code, des modifications doivent être apportées. C'est aussi la base de leur capacité à effectuer plusieurs tâches en parallèle. Sans un bon workflow de base, il est impossible de faire du multitâche. Pour de nombreux développeurs individuels, il n'est pas habituel de mettre en place un workflow CI/révision de code, et même la gestion de code Git n'est pas toujours faite, ce qui rend impossible le retour en arrière en cas de problème.