Le père de Claude Code révèle : comment transformer Claude en votre « petite équipe de développement virtuelle » ?

原文：Boris Cherny，Claude Code开发者

编译&整理：小互AI

Vous avez peut-être entendu parler de Claude Code, voire l’avez utilisé pour écrire du code ou modifier des documents. Mais avez-vous déjà pensé : si l’IA n’était pas un « outil à utiliser ponctuellement », mais un membre officiel de votre processus de développement, voire un système de collaboration automatisé — comment cela changerait-il votre façon de travailler ?

Boris Cherny, en tant que père de Claude Code, a écrit un tweet très détaillé partageant comment il utilise efficacement cet outil, ainsi que la façon dont lui et son équipe ont intégré profondément Claude dans tout le flux de travail.

Cet article va faire une synthèse systématique et une lecture accessible de son expérience.

Comment Boris a-t-il fait de l’IA un partenaire automatisé dans son flux de travail ?

Points clés :

Il présente son flux de travail, notamment :

Comment utiliser Claude :

Lancer plusieurs Claude en même temps : ouvrir 5 à 10 sessions en parallèle en terminal et sur le web pour traiter différentes tâches, utiliser aussi Claude sur mobile.

Ne pas modifier inutilement les réglages par défaut : Claude est prêt à l’emploi, pas besoin de configurations complexes.

Utiliser le modèle le plus puissant (Opus 4.5) : même un peu plus lent, il est plus intelligent, plus pratique.

Planifier avant de coder (mode Plan) : faire réfléchir Claude avant d’écrire, augmenter le taux de réussite.

Après génération du code, utiliser des outils pour vérifier le format, éviter les erreurs.

Comment rendre Claude de plus en plus intelligent :

L’équipe maintient une « base de connaissances » : chaque erreur de Claude est enregistrée, pour ne pas la répéter.

Entraîner automatiquement Claude lors de PR : faire analyser les PR par Claude pour apprendre de nouvelles méthodes ou normes.

Transformer ses commandes favorites en slash commands, que Claude peut appeler automatiquement, pour gagner du temps.

Utiliser des « sous-agents » pour traiter des tâches fixes, comme simplifier du code ou valider des fonctionnalités.

Gestion des permissions :

Ne pas sauter les permissions à la légère, mais configurer des commandes sécurisées qui passent automatiquement.

Synchroniser le flux de travail de Claude sur plusieurs appareils (web, terminal, mobile).

Point crucial :

Fournir à Claude un « mécanisme de validation » pour qu’il puisse vérifier si ce qu’il écrit est correct.

Par exemple, faire exécuter automatiquement des tests, ouvrir un navigateur pour tester une page, vérifier si une fonction fonctionne.

Claude Code est un « compagnon », pas un « outil »

Boris transmet d’abord une idée centrale : Claude Code n’est pas un outil statique, mais un assistant intelligent qui peut coopérer, apprendre en continu, et évoluer avec vous.

Il n’a pas besoin de configurations complexes, il est très puissant dès la sortie de la boîte. Mais si vous investissez du temps pour construire de meilleures méthodes d’utilisation, l’efficacité qu’il peut apporter sera multipliée.

Choix du modèle : privilégier le plus intelligent, pas le plus rapide

Boris utilise le modèle phare de Claude, Opus 4.5, avec le mode « with thinking » pour toutes ses tâches de développement.

Même si ce modèle est plus gros et plus lent que Sonnet :

• Sa compréhension est meilleure
• Sa capacité à utiliser des outils est supérieure
• Il nécessite moins d’orientations répétées, moins d’échanges
• Globalement, il fait gagner du temps par rapport à un modèle plus rapide
• Leçon : La vraie productivité ne dépend pas de la vitesse d’exécution, mais de « moins d’erreurs, moins de reprises, moins d’explications répétées ».

1. Mode Plan : faire écrire du code par l’IA, mais ne pas se précipiter pour qu’elle « écrive »

Quand on ouvre Claude, beaucoup vont instinctivement demander « Fais-moi une interface », « Refactorise ce code »… Claude va souvent « écrire quelque chose », mais souvent dans la mauvaise direction, en oubliant des logiques, ou en comprenant mal le besoin.

Mais la première étape de Boris n’est jamais de laisser Claude écrire du code. Il utilise le mode Plan — définir la stratégie avec Claude avant de passer à l’exécution.

Comment il procède ?

Lorsqu’il ouvre une PR, Boris ne demande pas à Claude d’écrire directement, mais utilise le mode Plan :

1. Définir l’objectif

2. Élaborer le plan avec Claude

3. Valider chaque étape

4. Ensuite, laisser Claude coder

Chaque fois qu’il doit réaliser une nouvelle fonctionnalité, comme « ajouter un rate limiter à une API », il confirme étape par étape avec Claude :

• Utilise-t-il un middleware ou intègre-t-il la logique en interne ?
• La configuration du rate limiter doit-elle être modifiable dynamiquement ?
• Faut-il des logs ? Que doit-il retourner en cas d’échec ?

Ce processus de « négociation du plan » ressemble à deux personnes dessinant ensemble un « plan de construction ».

Une fois que Claude a bien compris l’objectif, Boris active le mode « acceptation automatique des modifications », et Claude peut modifier directement le code, soumettre une PR, parfois sans validation humaine.

« La qualité du code de Claude dépend de votre accord préalable avant d’écrire. » — Boris

Leçon : Plutôt que de corriger sans cesse les erreurs de Claude, il vaut mieux définir clairement la feuille de route dès le départ.

Résumé

Le mode Plan n’est pas une perte de temps, c’est une négociation préalable pour assurer une exécution stable. Même une IA très forte a besoin de « vous dire clairement ce que vous voulez ».

2. Plusieurs Claude en parallèle : pas un seul IA, mais une équipe virtuelle de devs

Boris n’utilise pas qu’un seul Claude. Son organisation quotidienne ressemble à ça :

• 5 Claude locaux dans le terminal, répartis selon les tâches (refactoring, tests, debugging)
• 5 à 10 Claude dans le navigateur, en parallèle
• Claude sur l’app iOS, pour lancer des tâches à tout moment

Chaque instance de Claude est comme un « assistant dédié » : certains écrivent du code, d’autres complètent la documentation, d’autres exécutent des tests en arrière-plan.

Il a même configuré des notifications système, pour être alerté dès que Claude attend une entrée.

Pourquoi faire ça ?

Le contexte de Claude est local, pas adapté à « tout faire dans une seule fenêtre ». Boris divise Claude en plusieurs rôles pour réduire le temps d’attente et éviter la surcharge de mémoire.

Il utilise aussi des notifications pour se rappeler : « Claude 4 attend ta réponse », « Claude 1 a fini le test », comme on gère un système multi-thread.

Analogie

Imaginez cinq stagiaires intelligents autour de vous, chacun responsable d’une tâche. Vous ne faites pas tout vous-même, mais vous « switcher » entre eux au bon moment pour faire avancer le travail.

Leçon : Considérer Claude comme plusieurs « assistants virtuels » responsables de tâches différentes peut réduire considérablement le temps d’attente et le coût de changement de contexte.

3. Slash commands : transformer vos tâches quotidiennes en raccourcis Claude

Certains workflows que vous faites des dizaines de fois par jour :

• Modifier du code → commit → push → PR
• Vérifier l’état de build → notifier l’équipe → mettre à jour un issue
• Synchroniser des changements entre Web et plusieurs sessions locales
• Boris ne veut pas à chaque fois demander à Claude : « Commit d’abord, push, puis PR… »

Il encapsule ces opérations dans des slash commands, par exemple :

/commit-push-pr

Ces commandes sont en fait des scripts Bash stockés dans le dossier .claude/commands/, versionnés dans Git, accessibles à toute l’équipe.

Comment Claude utilise ces commandes ?

Quand Claude rencontre cette commande, il ne se contente pas de l’exécuter, mais comprend le workflow associé, et peut automatiser les étapes intermédiaires, pré-remplir les paramètres, éviter la communication répétée.

Point clé

Les slash commands sont comme des « boutons automatiques » pour Claude. Vous lui entraînez la compréhension d’un processus, et il peut l’exécuter en un clic.

« Ce n’est pas seulement moi qui peux gagner du temps avec ces commandes, Claude aussi. » — Boris

Leçon : Ne pas répéter sans cesse la même invite, mais abstraire les tâches fréquentes en commandes, pour que votre collaboration avec Claude devienne « automatisée ».

4. La base de connaissances d’équipe : Claude n’apprend pas par prompt, mais par le patrimoine collectif

L’équipe de Boris maintient une base de connaissances .claude, versionnée dans Git.

C’est comme une « wiki interne » pour Claude, qui enregistre :

• Les bonnes pratiques
• Les conventions d’équipe
• Les erreurs courantes et comment les corriger

Claude s’y réfère automatiquement pour comprendre le contexte et le style de code.

Que faire quand Claude se trompe ?

Chaque erreur ou mauvaise compréhension est enregistrée dans la base. Chaque équipe maintient sa propre version.

Tout le monde peut éditer en collaboration, et Claude consulte cette base en temps réel pour faire ses jugements.

Exemple :

Si Claude écrit systématiquement mal la pagination, il suffit que l’équipe mette la bonne norme dans la base, et tous en bénéficieront automatiquement.

Boris pratique ainsi : il ne la « punit » pas, ni ne la désactive, mais l’entraîne en lui disant : « On ne code pas comme ça, ajoute ça dans la base. »

La prochaine fois, Claude évitera cette erreur.

Et surtout, ce système n’est pas maintenu par Boris seul, mais par toute l’équipe, chaque semaine, en contribuant et en modifiant.

Leçon : Avec l’IA, ce n’est pas une lutte individuelle, mais la construction d’une « mémoire collective ».

5. Mécanisme d’apprentissage automatique : PR comme « données d’entraînement » pour Claude

Boris, lors de la revue de code, commente souvent dans la PR avec @Claude, par exemple :

@.claude Ajoute cette écriture de fonction dans la base de connaissances

En combinant avec GitHub Actions, Claude apprend automatiquement la logique derrière ces modifications, et met à jour la base interne.

C’est comme une « formation continue » pour Claude : chaque revue ne se limite pas à valider le code, mais améliore aussi ses capacités.

Ce n’est plus une « maintenance en fin de cycle », mais une intégration du processus d’apprentissage dans la collaboration quotidienne.

L’équipe améliore la qualité du code via PR, et Claude enrichit ses connaissances en même temps.

Leçon : La revue de PR n’est pas qu’un contrôle, c’est aussi une opportunité d’auto-formation pour l’IA.

6. Sous-agents (Subagents) : modulariser l’exécution de tâches complexes par Claude

En plus du flux principal, Boris définit des sous-agents (Subagents) pour traiter des tâches auxiliaires courantes.

Les sous-agents sont des modules automatiques, par exemple :

• code-simplifier : simplifier automatiquement la structure après écriture
• verify-app : lancer des tests complets pour valider la nouvelle version
• log-analyzer : analyser les logs d’erreur pour repérer rapidement le problème

Ces sous-agents, comme des plugins, s’intègrent dans le workflow de Claude, collaborent automatiquement, sans répétition de prompts.

Leçon : Les sous-agents sont comme des « membres de l’équipe » pour Claude, transformant l’assistant en « chef de projet ».

Claude n’est pas juste une personne, c’est un petit chef d’orchestre avec une équipe.

7. Paragraphe additionnel : PostToolUse Hook — le dernier rempart pour la formatage du code

Dans une équipe, faire respecter un style de code uniforme n’est pas évident. Claude, même très puissant, peut produire des indentations ou des espaces incohérents.

La solution de Boris est de mettre en place un PostToolUse Hook —

Comprenez cela comme un « post-traitement automatique » que Claude appelle après avoir terminé une tâche.

Son rôle :

• Corriger automatiquement le formatage
• Ajouter des commentaires manquants
• Résoudre les erreurs de lint pour éviter l’échec CI

Ce n’est pas compliqué, mais crucial. Comme relire un texte avec Grammarly avant de le rendre.

Pour les outils IA, la clé n’est pas seulement la génération, mais aussi la finition.

8. Gestion des permissions : pré-autorisation plutôt que saut de sécurité

Boris précise qu’il n’utilise pas --dangerously-skip-permissions — un paramètre de Claude Code qui permet de sauter toutes les alertes de permission.

Cela peut sembler pratique, mais dangereux : suppression accidentelle de fichiers, exécution de scripts non vérifiés…

Sa solution :

1. Utiliser /permissions pour déclarer explicitement les commandes sûres

2. Écrire ces permissions dans .claude/settings.json

3. Partager ces réglages avec toute l’équipe

C’est comme une « whitelist » pour Claude, par exemple :

“preApprovedCommands”: [

“git commit”,

“npm run build”,

“pytest”

]

Claude exécute ces commandes directement, sans demander confirmation.

Ce mécanisme de permissions ressemble à un « système d’exploitation » pour l’équipe, pas juste un outil individuel. Il utilise /permissions pour pré-autoriser des commandes sécurisées, stockées dans .claude/settings.json, partagé par tous.

Leçon : L’automatisation IA ne doit pas devenir incontrôlable. Intégrer une politique de sécurité dans l’automatisation, c’est la vraie ingénierie.

9. Coordination multi-outils : Claude = robot multi-capable

Boris ne limite pas Claude à l’édition locale. Il configure Claude pour accéder via MCP (un module de contrôle central) à plusieurs plateformes clés :

• Envoyer automatiquement des notifications Slack (résultats de build)
• Interroger BigQuery (indicateurs utilisateur)
• Récupérer des logs Sentry (erreurs en production)

Comment faire ?

La configuration MCP est dans .mcp.json

Claude, en fonctionnement, lit cette configuration, et exécute des tâches inter-plateformes de façon autonome.

Toute l’équipe partage cette configuration.

Tout cela est intégré via MCP (le système central de Claude), avec des réglages dans .mcp.json.

Claude devient comme un assistant robot, capable de :

« écrire du code → soumettre PR → voir le résultat → notifier QA → rapporter les logs »

Ce n’est plus un simple outil IA, mais le centre nerveux du système d’ingénierie.

Leçon : Ne pas limiter l’IA à « l’éditeur »,

elle peut devenir le coordinateur de tout votre écosystème.

10. Traitement asynchrone des longues tâches : agent en arrière-plan + plugins + hooks

Dans des projets réels, Claude doit parfois gérer des tâches longues, comme :

• Build + test + déploiement
• Génération de rapports + envoi d’emails
• Migration de données en cours

La méthode de Boris est très ingénieuse :

Trois façons de gérer les longues tâches :

1. Après exécution, faire vérifier le résultat par un agent en arrière-plan

2. Utiliser un Stop Hook, pour déclencher automatiquement la suite à la fin

3. Utiliser le plugin ralph-wiggum (proposé par @GeoffreyHuntley) pour gérer l’état de processus longs

Dans ces cas, Boris utilise :

–permission-mode=dontAsk

ou met la tâche dans un sandbox, pour éviter d’interrompre par des prompts de permission.

Claude n’est pas « en permanence surveillé », mais un collaborateur de confiance, que l’on peut déléguer.

Leçon : Les outils IA ne sont pas seulement pour des opérations rapides, mais aussi pour des processus longs et complexes — à condition de leur construire un « mécanisme de gestion ».

11. Mécanisme de validation automatique : la valeur de sortie de Claude doit pouvoir s’auto-vérifier

L’expérience de Boris montre que :

Tout résultat de Claude doit disposer d’un « mécanisme de validation » pour en vérifier la justesse.

Il ajoute un script ou un hook de validation :

• Après avoir écrit du code, Claude exécute automatiquement des tests pour vérifier sa correction
• Simuler des interactions utilisateur dans le navigateur pour tester l’expérience front-end
• Comparer automatiquement logs et métriques avant/après

Si ça ne passe pas, Claude modifie et recommence jusqu’à ce que ce soit correct.

C’est comme si Claude avait un « système de boucle de rétroaction » intégré.

Cela augmente la qualité, tout en allégeant la charge cognitive humaine.

Leçon : La vraie qualité d’un résultat IA ne dépend pas de la taille du modèle, mais de la présence d’un bon « mécanisme de vérification ».

Résumé : il ne s’agit pas de faire remplacer l’IA par l’humain, mais de faire collaborer comme un humain

La méthode de Boris ne repose pas sur des « fonctionnalités cachées » ou des « black magic », mais sur une utilisation ingénieuse de Claude, pour le faire passer d’un « assistant conversationnel » à un composant efficace du système de travail.

Ses principes clés :

• Multi-session en parallèle : meilleure répartition des tâches, plus d’efficacité
• Priorité à la planification : mode Plan pour aligner les objectifs
• Système de connaissances : équipe maintient une base partagée, en évolution continue
• Automatisation des tâches : slash commands + sous-agents, pour faire fonctionner Claude comme un moteur de flux
• Boucle de rétroaction : chaque sortie de Claude est vérifiée, pour assurer la fiabilité

En réalité, la méthode de Boris montre une nouvelle façon d’utiliser l’IA :

• Transformer Claude d’un « assistant de dialogue » en un « système de programmation automatisée »
• Transformer la mémoire en une base de connaissances collective
• Transformer les processus manuels répétitifs en workflows scriptés, modulaires, collaboratifs

Ce n’est pas du « black magic », mais une capacité d’ingénierie. Vous pouvez aussi en tirer des idées pour utiliser Claude ou d’autres IA de façon plus efficace et intelligente.

Si vous utilisez Claude et que vous avez souvent l’impression « il comprend un peu, mais ce n’est pas fiable », ou « le code qu’il génère doit toujours être corrigé », le problème ne vient peut-être pas de Claude, mais du manque d’un mécanisme de collaboration mature.

Claude peut être un stagiaire compétent, ou un partenaire fiable, selon comment vous l’utilisez.