Bonnes pratiques de Claude Code : passer de « utilisable » à « vraiment utile »

J'utilise Claude Code depuis plus de six mois, et j'ai rencontré plus d'embûches que de lignes de code écrites.

Au début, je pensais que Claude Code n'était qu'un « Copilot amélioré » — on tape dans le terminal, il écrit du code, et c'est fini. Plus tard, j'ai réalisé que le plafond de cet outil est bien plus élevé que ce que j'imaginais, mais seulement si on sait l'utiliser.

Cet article combine la documentation officielle et l'expérience pratique pour organiser ce que je considère comme les conseils d'utilisation les plus importants. Certains sont des leçons apprises à la dure, d'autres sont des fonctionnalités cachées que je n'ai découvertes qu'en lisant la documentation.

1. CLAUDE.MD : la fonctionnalité la plus sous-estimée

Si vous ne retenez qu'une seule chose de cet article, retenez ceci : Rédigez bien votre CLAUDE.md.

CLAUDE.md est le fichier d'instructions que Claude Code lit automatiquement au début de chaque conversation. C'est comme un document d'accueil que vous écrivez pour un nouveau collègue — tout ce que vous voulez qu'il sache, vous l'écrivez dedans.

Beaucoup de gens n'écrivent pas de CLAUDE.md ou n'écrivent que deux lignes. Résultat : ils doivent expliquer la structure du projet, les normes de codage et les choix techniques à chaque conversation. C'est comme présenter l'entreprise à votre collègue tous les matins.

Ce qu'un bon CLAUDE.md devrait inclure :

1# Nom du projet
2
3## Commandes de build et de test
4- Installer les dépendances : npm install
5- Exécuter les tests : npm test
6- Un seul test : npm test -- --grep "nom du test"
7- Formatage : npm run format
8
9## Normes de codage
10- Python : Utiliser ruff pour le formatage, largeur de ligne 88
11- Tests : Utiliser pytest, un fichier de test par service
12- Routes API : Utiliser des noms de fichiers au pluriel : users.py, orders.py
13- Messages de commit : En anglais, format : type(scope): description
14
15## Décisions architecturales
16- Choisir Tailwind plutôt que CSS Modules parce que l'équipe s'est standardisée dessus
17- Les vérifications des permissions utilisateur sont faites dans le middleware ; ne pas répéter dans chaque route
18- Préfixe de clé de cache Redis : app:v1:
19
20## Pièges courants
21- La limite du pool de connexions BD est de 20 ; ne pas ouvrir de nouvelles connexions dans les boucles
22- Ne pas simuler la base de données ; la dernière fois, les simulations ont passé mais la migration en production a échoué

Principes clés :

D'abord, écrivez ce que Claude ne peut pas déduire du code. Le « pourquoi » d'un projet est plus important que le « quoi ». Vous n'avez pas besoin d'expliquer comment utiliser React, mais vous devez dire « nous avons choisi Tailwind parce que l'équipe s'est standardisée dessus. »

Deuxièmement, gardez-le sous 200 lignes. La documentation officielle mentionne explicitement que si CLAUDE.md est trop long, Claude pourrait ignorer les règles. Utilisez des titres Markdown et des listes pour le rendre facile à parcourir.

Troisièmement, n'y mettez pas de contenu qui change fréquemment. Les documentations détaillées d'API ou les descriptions fichier par fichier n'ont pas leur place dans CLAUDE.md. Fournissez simplement des liens.

Les quatre niveaux de CLAUDE.md

Claude Code prend en charge quatre niveaux de CLAUDE.md, classés par ordre de priorité décroissant :

Dans mon CLAUDE.md global, j'écris généralement :

1- Je suis un ingénieur full-stack ; pas besoin de trop expliquer les concepts de base
2- Garde les réponses concises ; évite les politesses inutiles
3- Ne résume pas ce que tu as fait après les modifications de code ; je vérifierai le diff
4- Priorise les solutions simples ; évite le sur-engineering

Ces quatre lignes peuvent vous éviter des centaines de corrections répétitives.

Avancé : Organiser les règles avec .claude/rules/

À mesure qu'un projet grandit, un seul fichier CLAUDE.md ne suffit plus. La solution officielle est plus élégante : Divisez les règles dans le répertoire .claude/rules/.

1.claude/rules/
2├── testing.md        # Normes de test
3├── api-style.md      # Style d'écriture API
4└── frontend.md       # Conventions frontend

Encore plus puissant, vous pouvez utiliser le frontmatter YAML pour limiter les règles à des fichiers spécifiques :

1---
2paths: ["src/api/**/*.ts", "src/routes/**/*.ts"]
3---
4
5Les routes API doivent inclure la validation des entrées et la gestion des erreurs.
6Tous les nouveaux points d'accès nécessitent des tests d'intégration dans tests/api/.

Ainsi, la règle ne se charge que lorsque Claude accède aux fichiers correspondants, économisant de l'espace de contexte.

2. La qualité du prompt détermine la qualité de la sortie

Cela semble être un cliché, mais j'ai vu trop de gens utiliser Claude Code comme ceci :

« Aide-moi à écrire une fonctionnalité de connexion »

Ensuite, ils s'inquiètent d'un énorme morceau de code généré — ce n'est pas ce que je voulais.

Une bonne instruction doit contenir trois éléments : Objectif, Contraintes et Contexte.

Mauvaise instruction vs bonne instruction

Mauvaise : « Ajoute une fonctionnalité de recherche à la liste d'utilisateurs »

Bonne : « Ajoute une boîte de recherche au-dessus du tableau dans @src/pages/UserList.tsx. La recherche doit utiliser l'API backend /api/users?search=xxx, pas de filtrage frontend. Utilise un debounce de 300 ms, et garde le style cohérent avec le composant Filter existant. »

La différence ? Les bonnes instructions réduisent l'ambiguïté. Claude Code n'a pas à deviner si vous voulez une recherche frontend ou backend, le temps de debounce, ou les normes de style.

Conseils officiels recommandés pour les prompts

1. Utilisez @ pour référencer des fichiers spécifiques

Claude Code prend en charge l'utilisation de @cheminfichier pour insérer directement le contenu du fichier dans le contexte. Au lieu de dire « ce code lié à l'authentification », écrire @src/auth/login.ts est beaucoup plus précis. Vous pouvez même spécifier des plages de lignes : @src/auth/login.ts#5-30.

2. Collez des captures d'écran et des images

Utilisez Ctrl+V pour coller des images directement. Lors du débogage de problèmes UI, une capture d'écran de « à quoi ça ressemble maintenant » vs « comment je veux que ce soit » est dix fois plus efficace qu'une description textuelle.

3. Fournissez des critères de validation

Ne dites pas simplement « aide-moi à corriger ce bug », dites :

« Corrige le problème où la ré-authentification échoue après un délai de connexion. Après la correction, cliquer sur n'importe quel bouton après l'expiration du token doit automatiquement rediriger vers la page de connexion. Les cas de test sont dans @tests/auth.test.ts ; exécute-les pour confirmer qu'ils passent après la correction. »

Donnez à Claude une norme d'auto-vérification — cas de test, captures d'écran, sortie attendue — afin qu'il puisse vérifier la qualité de son propre travail et réduire les allers-retours.

4. Soyez clair sur ce qu'il ne faut PAS faire

Claude Code peut parfois être trop enthousiaste — vous lui demandez de corriger un bug, et il refactorise le code environnant aussi. Dire explicitement « ne change que cette fonction, ne touche pas à l'autre code » vous évite bien des soucis.

Quand les instructions vagues sont utiles

Toutes les situations ne nécessitent pas de précision. Les instructions vagues sont en fait meilleures pour les tâches exploratoires :

• « Que peut-on améliorer dans ce fichier ? »
• « Aide-moi à comprendre l'architecture de ce module »
• « Y a-t-il des problèmes potentiels avec ce code ? »

Mais une fois que vous passez à l'étape d'implémentation, revenez au mode précision.

3. MODE PLAN : Réfléchissez clairement avant d'agir

Claude Code dispose d'un mode Plan, que je considère comme le workflow le plus sous-estimé.

Comment entrer en mode Plan

Trois façons :

1# Démarrer directement en mode plan
2claude --permission-mode plan
3
4# Basculer pendant la conversation (appuyer deux fois sur Shift+Tab)
5Shift+Tab Shift+Tab
6
7# Dire dans le prompt
8« Ne change pas le code pour l'instant, aide-moi à faire un plan »

En mode Plan, Claude Code ne peut que lire les fichiers et rechercher du code ; il ne peut faire aucune modification. Il explore la base de code, analyse vos besoins et fournit un plan d'implémentation détaillé.

Bonne façon d'utiliser le mode Plan

Opération clé : Appuyez sur Ctrl+G pour ouvrir et modifier le plan dans votre éditeur.

Cela signifie que vous pouvez :

1. Laisser Claude générer un plan initial
2. Ctrl+G pour ouvrir le plan, supprimer les parties avec lesquelles vous n'êtes pas d'accord et ajouter vos propres idées
3. Revenir en mode normal (Shift+Tab) et laisser Claude exécuter selon le plan modifié

Changer un plan prend une phrase ; changer du code déjà écrit prend dix fois plus de temps.

Workflow recommandé pour les tâches complexes

Le processus standard officiel comporte quatre étapes : Explorer → Planifier → Implémenter → Vérifier.

11. Entrer en mode Plan
22. Demander à Claude de lire le code pertinent : « Lis le code dans src/auth/ pour comprendre la logique de session »
33. Demander un plan : « Élabore un plan de migration OAuth2 »
44. Ctrl+G pour réviser et modifier le plan
55. Revenir en mode normal
66. « Implémente selon le plan, exécute les tests après l'écriture »
77. Demander à Claude de s'auto-vérifier par rapport aux exigences

Quand vous n'avez pas besoin du mode Plan

• Changer un nom de variable
• Corriger une faute de frappe évidente
• Ajouter une seule ligne de log

Le critère est simple : S'il n'y a qu'une seule façon d'implémenter la tâche, faites-le directement. S'il y a plusieurs choix, planifiez d'abord.

4. SOUS-AGENTS : La puissance multitâche de Claude Code

Les sous-agents sont un mécanisme puissant — Claude Code peut lancer des processus IA indépendants pour gérer des tâches en parallèle. Chaque sous-agent a sa propre fenêtre de contexte et n'encombrera pas votre conversation principale.

Types de sous-agents intégrés

La plus grande valeur des sous-agents : l'Isolation du contexte

Lorsque vous demandez à Claude d'exécuter des tests, d'analyser des logs ou de rechercher de nombreux fichiers, ces opérations génèrent une sortie massive qui remplit votre fenêtre de contexte. Utilisez des sous-agents pour ces tâches ; la sortie reste dans le contexte du sous-agent, et seul un résumé vous est renvoyé.

Par exemple :

« Utilise un sous-agent pour exécuter tous les tests et lister les cas échoués »

« Utilise un sous-agent pour rechercher tous les fichiers utilisant des API obsolètes »

Exécution en arrière-plan : Ctrl+B

Appuyez sur Ctrl+B pour mettre un sous-agent en arrière-plan. Vous pouvez continuer à discuter avec Claude d'autres choses, et vous serez averti lorsque la tâche en arrière-plan sera terminée.

Idéal pour :

• Exécuter des suites de tests (prend généralement des minutes)
• Recherches de code à grande échelle
• Révisions de code non urgentes

Sous-agents personnalisés

Vous pouvez créer des agents personnalisés dans le répertoire .claude/agents/ :

1---
2name: code-reviewer
3description: Expert en révision de code. Déclenché automatiquement après les modifications de code.
4tools: Read, Grep, Glob, Bash
5model: sonnet
6---
7
8Vous êtes un réviseur de code senior. Vérifiez les dimensions suivantes :
9- Clarté et lisibilité du code
10- Complétude de la gestion des erreurs
11- Exposition d'informations sensibles
12- Validation des entrées
13- Pièges de performance

Puis appelez-le en conversation en utilisant @"code-reviewer (agent)".

5. Gestion du contexte : La clé la plus négligée

Bien que la fenêtre de contexte de Claude Code soit grande (jusqu'à 1 M de tokens), elle n'est pas infinie, et la gestion du contexte détermine directement la qualité de la sortie.

Qu'y a-t-il dans le contexte ?

• Votre historique de conversation
• Tout le contenu des fichiers lus par Claude
• La sortie d'exécution des commandes
• Le fichier CLAUDE.md (chargé à chaque fois)
• Le fichier mémoire (200 premières lignes)
• Les définitions des compétences et outils MCP chargées

Cinq stratégies pratiques

1. /clear : Effacer quand une tâche est terminée

Ne corrigez pas des bugs, n'ajoutez pas de fonctionnalités et ne refactorisez pas tout dans la même conversation. /clear vide le contexte mais garde CLAUDE.md, agissant comme un redémarrage gratuit.

2. /compact : Compresser manuellement le contexte

Quand la conversation devient longue, utilisez /compact pour laisser Claude résumer et compresser automatiquement les dialogues précédents. Une meilleure façon est d'ajouter un focus à la compression :

/compact focus on API changes and test results

Ainsi, Claude priorise la conservation du contenu qui vous intéresse pendant la compression.

3. /context : Voir ce qui mange votre contexte

Tapez /context pour voir l'utilisation actuelle — quels fichiers prennent combien de tokens et combien d'espace les définitions d'outils MCP occupent. Je trouve souvent des serveurs MCP inutiles qui prennent beaucoup de place.

4. Utiliser les sous-agents pour isoler le bruit

L'exécution de tests et l'analyse de logs produisent beaucoup de sortie. Laissez les sous-agents le faire pour garder le contexte de la conversation principale propre.

5. Écrire des instructions de rétention de compression dans CLAUDE.md

Vous pouvez dire à Claude ce qui doit être conservé pendant la compression :

1# Instructions de compression
2Lors de la compression du contexte, conserve toujours :
3- La liste complète des fichiers modifiés
4- Les commandes de test et les résultats
5- Les décisions architecturales clés

Mémoire vs CLAUDE.md

À quoi sert la Mémoire : Vos préférences (« cette personne aime les réponses concises »), les conventions du projet (« le déploiement a une étape spéciale »), les décisions historiques (« nous avons choisi l'option A la dernière fois à cause de X »).

À quoi la Mémoire ne sert PAS : Les détails de code, l'historique Git, les états temporaires — ceux-ci sont plus précisément récupérés à partir du code et de Git.

Utilisez la commande /memory pour voir et gérer toute la Mémoire chargée.

6. Gestion des permissions : équilibrer sécurité et efficacité

Claude Code propose cinq modes de permission, que l'on fait défiler avec Shift+Tab pendant la conversation :

Configuration des règles de permission

Dans .claude/settings.json, vous pouvez contrôler finement les permissions pour chaque outil :

1{
2  "permissions": {
3    "allow": [
4      "Bash(npm run *)",
5      "Bash(git commit *)",
6      "Edit(src/**/*.ts)",
7      "Read(*.md)"
8    ],
9    "deny": [
10      "Bash(rm -rf *)",
11      "Edit(.env)"
12    ]
13  }
14}

Priorité des règles : deny → ask → allow (deny a la priorité la plus élevée).

Cela signifie que vous pouvez autoriser audacieusement les commandes courantes tout en utilisant deny pour protéger les fichiers sensibles. Par exemple, les fichiers .env ne doivent jamais être modifiés.

Hiérarchie des fichiers de configuration

Similaire à CLAUDE.md, les paramètres ont plusieurs niveaux :

1Politique de l'organisation (Priorité la plus élevée)
2  ↓
3Arguments CLI
4  ↓
5.claude/settings.local.json (Local, non engagé dans Git)
6  ↓
7.claude/settings.json (Niveau projet, partagé avec l'équipe)
8  ↓
9~/.claude/settings.json (Global, personnel)
10  ↓
11Valeurs par défaut (Priorité la plus basse)

Mon conseil : Mettez les règles partagées par l'équipe dans .claude/settings.json, les préférences personnelles dans ~/.claude/settings.json, et les configurations sensibles dans .claude/settings.local.json (n'oubliez pas d'ajouter à .gitignore).

7. HOOKS : Transformer les règles en lois de fer

Les instructions dans CLAUDE.md sont des « suggestions » — Claude les suit la plupart du temps mais les oublie parfois. Les hooks sont des « lois de fer » — ils s'exécutent quoi qu'il arrive.

Les hooks sont des commandes shell déclenchées automatiquement par des événements spécifiques du cycle de vie, configurés dans settings.json.

Types d'événements clés

Exemples pratiques

Auto-formatage — Exécuter Prettier après chaque édition :

1{
2  "hooks": {
3    "PostToolUse": [{
4      "matcher": "Edit|Write",
5      "hooks": [{
6        "type": "command",
7        "command": "jq -r '.tool_input.file_path' | xargs npx prettier --write"
8      }]
9    }]
10  }
11}

Protéger les fichiers critiques — Empêcher la modification des configurations de production :

1{
2  "hooks": {
3    "PreToolUse": [{
4      "matcher": "Edit|Write",
5      "hooks": [{
6        "type": "command",
7        "command": ".claude/hooks/protect-files.sh"
8      }]
9    }]
10  }
11}

Une commande hook retournant le code de sortie 0 signifie autorisé ; le code de sortie 2 signifie bloqué. Cela signifie que vous pouvez écrire n'importe quelle logique complexe.

Réinjecter des informations clés après la compression du contexte :

1{
2  "hooks": {
3    "SessionStart": [{
4      "matcher": "compact",
5      "hooks": [{
6        "type": "command",
7        "command": "echo 'Utilise Bun, pas npm. Exécute bun test avant de commiter.'"
8      }]
9    }]
10  }
11}

Cela résout un problème courant : lorsqu'une longue conversation est compressée, des instructions importantes mentionnées plus tôt peuvent être perdues. Les hooks peuvent les réinjecter automatiquement après chaque compression.

Quatre types de hooks

8. WORKFLOW GIT : Bien utiliser WORKTREE

Claude Code peut exécuter des commandes Git, ce qui est une arme à double tranchant. Mais l'outil officiel offre un excellent filet de sécurité : Worktree.

Git Worktree : Espaces de travail isolés

1# Démarrer Claude dans un worktree isolé
2claude --worktree feature-auth
3claude --worktree bugfix-123
4
5# Générer automatiquement un nom
6claude --worktree

Worktree crée une copie de branche Git indépendante dans .claude/worktrees/. Quoi que fasse Claude à l'intérieur, cela n'affectera pas votre branche principale. À la sortie :

• Si aucun changement → Nettoyage automatique
• Si des changements existent → Vous invite à conserver ou supprimer

C'est particulièrement utile pour les tâches exploratoires. Vous n'êtes pas sûr qu'un plan de refactorisation fonctionnera ? Essayez-le dans un worktree ; s'il échoue, jetez-le sans risque.

Quelques lois de fer Git

1. Ne laissez jamais Claude Code pousser automatiquement

Il peut commiter, mais l'action de push doit être confirmée par vous. Une fois poussé vers le dépôt distant, le coût du rollback augmente considérablement.

2. Commitez fréquemment

Commitez après avoir terminé une petite fonctionnalité. Utilisez /rewind pour revenir à n'importe quel point de contrôle, à condition d'avoir des enregistrements de commit.

3. Méfiez-vous des opérations destructrices

Si Claude Code veut exécuter git reset --hard, git push --force, ou rm -rf, réfléchissez aux conséquences avant d'approuver. Ces opérations n'ont pas d'annulation. Vous pouvez également refuser ces commandes dans les règles de permission.

4. Restaurer le contexte depuis une PR

Cela charge automatiquement les modifications et discussions de la PR comme contexte, parfait pour la révision de code ou pour continuer le travail de quelqu'un d'autre.

1claude --from-pr 123

9. Raccourcis et référence des commandes

J'utilise ces raccourcis tous les jours ; je recommande vivement de les mémoriser :

Raccourcis les plus courants

Commandes slash les plus courantes

1/compact [focus]     # Compresser le contexte, peut spécifier un focus
2/clear              # Effacer la conversation, recommencer
3/context            # Voir l'utilisation du contexte
4/memory             # Voir et gérer la Mémoire
5/rewind             # Revenir à un point de contrôle
6/resume [nom]       # Reprendre une conversation précédente
7/model              # Changer de modèle
8/effort [niveau]    # Définir la profondeur de raisonnement : low/medium/high/max
9/init               # Générer automatiquement CLAUDE.md
10/mcp                # Gérer les serveurs MCP
11/permissions        # Voir les règles de permission
12/cost               # Voir la consommation de tokens

/init est particulièrement utile pour les nouveaux projets — il analyse automatiquement votre base de code et aide à générer un brouillon de CLAUDE.md. Bien qu'il nécessite généralement un ajustement manuel, c'est beaucoup plus rapide que de partir de zéro.

10. PENSÉE ÉTENDUE : Laissez Claude réfléchir plus profondément

Pour les problèmes complexes, vous pouvez activer le mode Pensée étendue, permettant à Claude de passer plus de temps à raisonner avant de répondre.

Comment l'utiliser

1# Activation par raccourci
2Option+T (Mac) / Alt+T (Windows/Linux)
3
4# Ou par commande
5/effort high    # Raisonnement plus profond
6/effort max     # Profondeur de raisonnement maximale
7/effort low     # Tâches simples, économise des tokens

Quand l'utiliser

• Décisions architecturales complexes
• Débogage délicat (plusieurs causes possibles à éliminer)
• Conception de refactorisation en plusieurs étapes
• Peser le pour et le contre de plusieurs solutions

Quand vous n'en avez pas besoin

• Modifications de code simples
• Formatage, renommage
• Corrections de bugs déjà claires

Astuce pro : Écrire « ultrathink » dans le prompt peut forcer la profondeur de raisonnement la plus élevée sans ajuster manuellement les paramètres d'effort.

11. SERVEUR MCP : Connecter Claude au monde extérieur

MCP (Model Context Protocol) permet à Claude Code de communiquer avec des outils externes — GitHub, bases de données, Slack, Notion, etc.

Ajout rapide

1claude mcp add github -- npx @anthropic-ai/mcp-server-github
2claude mcp add postgres -- npx @anthropic-ai/mcp-server-postgres postgresql://localhost:5432/mydb

Fichier de configuration

MCP est configuré dans .mcp.json :

1{
2  "mcpServers": {
3    "github": {
4      "type": "stdio",
5      "command": "npx",
6      "args": ["@modelcontextprotocol/server-github"],
7      "env": {
8        "GITHUB_TOKEN": "$GITHUB_TOKEN"
9      }
10    }
11  }
12}

Note sur l'overhead du contexte

Chaque serveur MCP consomme 100 à 500+ tokens supplémentaires pour les définitions d'outils. Utilisez la commande /mcp pour vérifier l'overhead de chaque serveur et désactivez ceux qui ne sont pas utilisés.

Mon expérience : Ne soyez pas gourmand. 2 à 3 serveurs MCP couramment utilisés suffisent. En installer trop consomme de l'espace de contexte avec les définitions d'outils, ce qui peut en fait dégrader la qualité de l'analyse de code.

12. INTÉGRATION IDE : Plus qu'un simple terminal

VS Code

Après avoir installé l'extension Claude Code, vous pouvez utiliser Claude directement dans VS Code sans passer par le terminal.

Fonctionnalités utiles :

• Vue diff côte à côte : Les modifications de Claude sont affichées sous forme de diffs, claires en un coup d'œil
• Option+K / Alt+K : Insérer rapidement des @références vers le fichier courant
• Conversations multi-onglets : Ouvrir plusieurs conversations indépendantes dans différents onglets
• Cmd+Shift+Esc : Ouvrir rapidement un nouvel onglet de conversation

JetBrains

IntelliJ, PyCharm, WebStorm et autres IDE JetBrains ont également un plugin Claude Code. Recherchez simplement « Claude Code » dans le marketplace des plugins pour l'installer.

13. Révision du code : Faites confiance mais vérifiez

La qualité du code de Claude Code est généralement bonne, mais vous ne devriez pas lui faire aveuglément confiance.

Problèmes courants

1. Sur-ingénierie

Vous demandez une simple fonction utilitaire, et il vous donne une couche d'abstraction complète avec des génériques, des interfaces et des patterns de fabrique. Un marteau-pilon pour casser une noix.

Solution : Écrivez « priorise les solutions simples » dans CLAUDE.md, ou dites explicitement « pas besoin d'abstraction » dans l'instruction.

2. API hallucinées

Il utilise parfois des API inexistantes ou une syntaxe obsolète, en particulier pour les nouvelles versions de bibliothèques obscures.

Solution : Exécutez les tests. C'est pourquoi les instructions doivent inclure des normes de validation.

3. Débordement de périmètre

Vous lui demandez de changer une fonction, et il refactorise tout le fichier.

Solution : Dites explicitement « ne change que X, ne touche pas à l'autre code. » Ou utilisez la commande /freeze pour limiter la portée d'édition à des répertoires spécifiques.

Mode Écrivain/Relecteur

Un mode avancé officiellement recommandé : Utilisez deux sessions indépendantes pour jouer les rôles d'« Écrivain » et de « Relecteur ».

Deux sessions ont des contextes indépendants ; le Relecteur n'est pas influencé par la logique de l'Écrivain et peut trouver des angles morts.

1Session A (Écrivain) : « Implémente un middleware de limitation de débit API »
2Session B (Relecteur) : « Révise l'implémentation de limitation de débit dans @src/middleware/rateLimiter.ts,
3                     en se concentrant sur les cas limites, les conditions de concurrence et la cohérence »
4Session A : « Corrige les retours de la révision : [Coller la sortie de B] »

14. Ce qu'il ne faut PAS faire avec Claude Code

Après avoir dit beaucoup de choses sur « ce qu'il faut faire », parlons de « ce qu'il ne faut pas faire ».

1. Ne le laissez pas faire des choses que vous ne comprenez pas du tout

Si vous ne connaissez rien à Kubernetes, ne laissez pas Claude Code écrire des configurations de déploiement à utiliser directement. Vous ne pouvez pas réviser ce que vous ne comprenez pas.

2. Ne l'utilisez pas dans des environnements sans contrôle de version

Pas de Git signifie pas de capacité à revenir en arrière. Les modifications de Claude Code pourraient écraser vos fichiers ; l'utiliser sans contrôle de version, c'est comme marcher sur une corde raide sans filet.

3. Ne lui confiez pas une tâche massive d'un seul coup

« Migre tout le projet de JavaScript vers TypeScript »

Cette instruction donne carte blanche à Claude Code, rendant le résultat incontrôlable. Divisez-la en petites étapes et confirmez chaque étape avant de passer à la suivante.

4. Ne vous attendez pas à la perfection du premier coup

L'itération est normale. Utilisez /rewind pour revenir en arrière et utilisez des retours précis pour décrire « ce qui ne va pas ».

Résumé

La philosophie centrale de l'utilisation de Claude Code est simple :

C'est un collaborateur extrêmement compétent, mais pas un pilote automatique. Le volant est toujours entre vos mains.

Classé par ordre d'importance, mon conseil est :

1. Rédigez bien votre CLAUDE.md — Investissez une fois, profitez à chaque conversation
2. Donnez des instructions précises — Objectif + Contraintes + Critères de validation
3. Utilisez le mode Plan — Planifiez d'abord, agissez ensuite pour les tâches complexes
4. Gérez le contexte — /clear, /compact, Sous-agents
5. Contrôlez les permissions — Refusez les opérations dangereuses, autorisez les commandes courantes
6. Validez fréquemment — Conservez la possibilité de revenir en arrière

Faites cela, et Claude Code peut multiplier votre efficacité par plusieurs. Ne le faites pas, et il ne fera que vous aider à créer du chaos plus rapidement.

La valeur d'un outil dépend toujours de la personne qui l'utilise.

Ce qui précède est une combinaison de la documentation officielle de Claude Code et de l'expérience pratique. Si vous avez de meilleures pratiques, n'hésitez pas à les partager.