Bonnes pratiques : transformer des habitudes éparses en règles de conduite éprouvées

📚 Navigation de la série : Le chapitre précédent 48 Projet de synthèse : du début à la mise en ligne, relier tout ce que vous avez appris vous a guidé pour assembler toutes les fonctionnalités apprises en un flux de développement complet. Ce chapitre prend de la hauteur — il n'enseigne pas de nouvelles fonctionnalités, mais explique « comment bien les utiliser ». À outil identique, certains utilisent Claude Code avec fluidité tandis que d'autres s'épuisent à lutter contre lui ; la différence réside dans ces bonnes pratiques forgées par l'équipe officielle et les utilisateurs chevronnés. Je les ai rassemblées sous forme de règles à suivre, accompagnées de tableaux comparatifs « bonnes vs mauvaises pratiques ».

« Ce prompt est beaucoup trop court. »

Imaginez un débutant sur Claude Code qui saisit simplement « corrige le bug de connexion » puis appuie sur Entrée. Après avoir attendu un moment, Claude produit un code qui ne correspond en rien à ce qu'il souhaitait. Le débutant se plaint alors : « N'ai-je pas été assez clair ? »

Pourtant, si vous posiez cette même question à un stagiaire qui arrive aujourd'hui pour son premier jour et ne connaît rien au projet, parviendrait-il à résoudre le problème ? Quelle connexion ? Quel bug ? Dans quel fichier ? Quels sont les critères de correction ? — Vous n'avez rien précisé de tout cela. Essayons une autre formulation : « Les utilisateurs signalent que la reconnexion échoue après l'expiration de la session. Examinez d'abord la section de rafraîchissement des tokens dans src/auth/, écrivez un test pour reproduire le bug, puis faites en sorte que le test passe. » Cette fois, Claude corrigera le problème du premier coup.

En clair, la réussite avec Claude Code dépend à 80 % non pas de l'outil lui-même, mais de votre manière de collaborer avec lui. Il est extrêmement performant, mais il ne sait pas lire dans les pensées. Ce chapitre compile les recommandations officielles sur les bonnes pratiques, enrichies de l'expérience à long terme d'utilisateurs chevronnés, sous forme de règles simples que vous pouvez appliquer dès aujourd'hui.

À la fin de ce chapitre, vous obtiendrez :

• Une contrainte globale majeure (la fenêtre de contexte est votre ressource la plus précieuse) ; une fois comprise, toutes les règles suivantes s'enchaîneront logiquement
• Cinq règles fondamentales : fournir des moyens de validation, explorer avant de coder, être précis dans vos instructions, optimiser le fichier CLAUDE.md, et corriger immédiatement les dérives
• Plusieurs tableaux comparatifs « ❌ Mauvaise pratique vs ✅ Bonne pratique » pour améliorer instantanément vos prompts
• Un guide de consultation rapide pour savoir quelle règle appliquer selon la situation, ainsi qu'une expérience comparative à réaliser vous-même

---

01 Une contrainte globale : la fenêtre de contexte est votre ressource la plus précieuse

Presque toutes les bonnes pratiques découlent d'une seule et même origine. L'équipe officielle l'a formulée clairement dès le départ, et je vous la livre telle quelle :

大多数最佳实践都基于一个约束：Claude 的 context window 填充速度很快，随着填充，性能会下降。

La fenêtre de contexte (context window, c'est-à-dire l'ensemble des informations que Claude peut garder à l'esprit en même temps) contient l'intégralité de votre conversation — chaque message, chaque fichier lu, et chaque retour de commande bash. Le problème est qu'elle se sature très vite : une session de débogage un peu poussée ou une recherche globale dans la base de code peut facilement consommer des dizaines de milliers de tokens (le chapitre 19 explique ce que sont les tokens et la fenêtre de contexte).

Et une fois saturée, Claude perd en efficacité — il oublie vos instructions initiales et commence à commettre des erreurs basiques.

Analogie : Accompagner un nouveau stagiaire sur un projet. Ce stagiaire est extrêmement intelligent et rapide, mais il a une particularité : son esprit est comme un tableau blanc de taille fixe. Tout ce que vous lui dites, les documents qu'il parcourt, les résultats des commandes qu'il lance doivent être écrits sur ce tableau. Une fois le tableau rempli, il commence à s'y perdre — la consigne « lance les tests avant de commettre » donnée le matin est oubliée l'après-midi, car elle a été chassée par d'autres informations accumulées entre-temps.

Je réutiliserai cette analogie tout au long du chapitre — car presque toutes les règles suivantes consistent à aider ce stagiaire à « économiser l'espace de son tableau blanc » :

• Lui donner les moyens de valider son travail par lui-même, afin que vous n'ayez pas à surveiller chaque étape (ce qui vous fait gagner du temps et évite d'encombrer inutilement le tableau blanc avec des allers-retours) ;
• Lui demander de bien comprendre le contexte avant d'agir, pour éviter de saturer le tableau pour rien si la direction choisie s'avère erronée ;
• Formuler vos instructions de manière précise dès le départ, pour éviter les sessions de questions-réponses consommatrices d'espace ;
• Rédiger des notes permanentes concises, afin que le tableau blanc ne soit pas encombré dès le départ par des informations superflues ;
• Le ramener immédiatement sur la bonne voie en cas de dérive, avant que le tableau blanc ne soit saturé par une série de tentatives infructueuses.

En gardant cette contrainte à l'esprit, vous verrez que les cinq premières règles découlent d'un même principe : « préserver le tableau blanc de notre stagiaire unique ». Une fois que vous saurez gérer efficacement un stagiaire, nous aborderons la sixième règle : multiplier les stagiaires en parallèle, mais nous y reviendrons.

💡 En résumé : La fenêtre de contexte de Claude se remplit rapidement, altérant ses performances ; c'est votre ressource la plus précieuse. Toutes les règles de ce chapitre visent à vous apprendre à « économiser l'espace du tableau blanc de votre brillant stagiaire ».

---

02 Règle 1 : Fournir un moyen d'auto-évaluation

Commençons par le point le plus important à mes yeux :

Fournissez à Claude un moyen d'exécuter lui-même des vérifications — tests, builds ou comparaisons de captures d'écran. C'est la frontière entre « une session que vous devez surveiller » et « une session que vous pouvez laisser tourner en toute autonomie ».

Pourquoi est-ce si crucial ? La documentation officielle le résume parfaitement :

当工作看起来完成时，Claude 会停止。没有它可以运行的检查，「看起来完成」是唯一可用的信号，你成为验证循环。

En d'autres termes : si vous ne lui fournissez pas de critères de validation, vous serez contraint d'assurer vous-même la validation — chaque erreur commise exigera votre œil attentif pour être détectée. Vous passez alors de « donneur d'ordres » à « contrôleur qualité », obligé de surveiller chaque étape. En revanche, si vous lui fournissez un indicateur clair (succès/échec), la boucle se referme d'elle-même : il réalise la tâche, lance la vérification, analyse le résultat, applique les corrections nécessaires, et réitère jusqu'à ce que la vérification passe.

Analogie : La réception de travaux de rénovation. Lorsque vous faites faire des travaux, la pire situation est celle où les ouvriers partent parce qu'ils « estiment à vue d'œil avoir terminé » — des carreaux mal alignés, des prises électriques défectueuses... ils ne s'en rendent pas compte et c'est vous qui le découvrez à l'usage. En revanche, si vous leur fournissez une liste de contrôle d'acceptation avant de démarrer (« tester chaque prise avec un tournevis testeur, vérifier la planéité de chaque carreau avec une règle de maçon »), ils pourront valider eux-mêmes chaque point et corriger les défauts avant votre arrivée. Le travail livré aura déjà été vérifié. « Les vérifications exécutables » correspondent à cette liste de contrôle d'acceptation.

Quels éléments peuvent servir de liste de contrôle ? L'équipe officielle liste plusieurs outils, qui retournent tous des signaux lisibles par Claude au sein de la session :

• Les suites de tests (le moyen le plus courant, qui indique directement le statut succès/échec)
• Le code de retour du build (indique si la compilation a réussi)
• Le linter (vérifie le respect des normes de code)
• Des scripts comparant la sortie à une référence stable
• Des captures d'écran du navigateur comparées aux maquettes (validation applicable lors de la création d'UI à partir d'images, comme vu au chapitre 17)

Le plus important est d'intégrer cela dans vos prompts. Voici un tableau comparatif officiel à conserver précieusement :

Scénario	❌ Sans critère de validation	✅ Avec critère de validation
Écrire une fonction	« Implémente une fonction de validation d'adresse e-mail »	« Écris une fonction validateEmail. Exemples de cas : user@example.com doit être vrai, invalid faux, user@.com faux. Lance les tests après implémentation »
Modifier une UI	« Rends le tableau de bord plus esthétique »	« [Insérer capture d'écran] Implémente ce design. Prends ensuite une capture d'écran pour la comparer au design original, liste les différences et corrige-les »
Corriger un build	« Le build a échoué »	« Le build produit cette erreur : [Insérer l'erreur]. Corrige-la et vérifie la réussite du build. Résous la cause profonde, ne te contente pas de masquer l'erreur »

Vous saisissez la nuance ? Dans la colonne de gauche, Claude se contente d'estimer avoir terminé ; dans la colonne de droite, chaque prompt se termine par une vérification qu'il peut exécuter lui-même et dont il peut lire le retour.

Les vérifications peuvent également avoir différents niveaux de contrainte, selon le niveau de rigueur attendu — un aspect détaillé officiellement que je résume ainsi :

Niveau de contrainte	Comment le configurer	Cas d'usage
Au sein du prompt actuel	Écrire directement dans le prompt « lance les tests et itère jusqu'à réussite »	Tâches courantes, approche la plus légère
À l'échelle de la session	Définir comme condition du /goal pour exécuter la vérification automatiquement à chaque cycle	Pour s'assurer qu'il garde le cap sur un objectif à long terme
Barrière stricte de validation	Écrire un Stop hook qui empêche de terminer la session si la vérification échoue	Contrôle automatisé sans intervention humaine (les hooks sont abordés au chapitre 33)

Pour débuter, le premier niveau suffit largement — ajouter « lance les tests et vérifie le résultat une fois terminé » en fin de prompt produit un effet immédiat. Les deux niveaux suivants constituent des mesures plus lourdes à configurer lorsque vous souhaitez que Claude finalise le travail sans supervision.

Il convient également d'insister sur la consigne officielle « résoudre la cause profonde, sans masquer les symptômes » — ce qui rejoint la règle d'or du débogage : ne commentez pas une erreur et n'ajoutez pas de contournement simplement pour faire tourner le code. Un cas de dérive classique : face à une erreur de type lors du build, vous lui demandez de « forcer le passage du build », ce qui l'amène à transtyper la ligne en any ; l'erreur disparaît, mais le bug est enfoui plus profondément. La bonne pratique consiste à inclure systématiquement dans votre prompt la phrase « corrige la cause profonde de l'erreur, ne te contente pas de la masquer ».

Une autre bonne habitude consiste à lui demander de fournir des preuves de réussite, plutôt que de se contenter de l'affirmer :

让 Claude 显示证据而不是声称成功：测试输出、它运行的命令及其返回的内容，或结果的屏幕截图。

Vérifier rapidement le retour de test qu'il affiche est bien plus rapide que de relancer la commande vous-même — et pour une session sans supervision, c'est la seule garantie fiable.

💡 En résumé : Fournir à Claude une vérification exécutable (tests, builds ou captures d'écran) lui permet de s'auto-évaluer et de se corriger de lui-même ; ajouter « lance les tests et vérifie une fois terminé » en fin de prompt vous évite de devenir un simple contrôleur qualité.

---

03 Règle 2 : Explorer d'abord, planifier ensuite, et coder en dernier

La deuxième règle vise à prévenir les dérives.

Demander à Claude de coder d'emblée risque de produire un code qui résout le mauvais problème. Séparez la phase « d'exploration et de conception » de la phase « d'implémentation ».

Le flux de travail recommandé officiellement se déroule en quatre étapes, que nous pouvons illustrer avec notre métaphore du stagiaire :

Ce schéma présente le flux de travail officiel en quatre étapes : les deux étapes de gauche consistent à « concevoir », et les deux étapes de droite à « réaliser ». La ligne verticale centrale (sortie du Plan Mode) fait office d'interrupteur pour passer de la réflexion à l'action.

Pourquoi séparer l'exploration de l'implémentation ? Posez-vous la question : vous ne demanderiez pas à un stagiaire fraîchement arrivé de modifier un module central sans même avoir ouvert le projet. Vous lui demanderiez d'abord de lire le code, poser des questions et comprendre l'existant (l'exploration), puis de présenter sa proposition de modification (la planification), avant de lui donner le feu vert pour coder. Il en va de même pour Claude, et le Plan Mode (mode planification, un mode en lecture seule dédié à la compréhension de l'existant et à l'élaboration de la solution, détaillé au chapitre 35) est conçu précisément pour cela.

Durant la phase d'exploration en Plan Mode, vous pouvez formuler vos consignes ainsi :

读一下 src/auth 目录，搞清楚我们怎么处理 session 和登录。
顺便看看 secret 这类环境变量是怎么管的。

Il se contente de lire et de vous répondre, sans modifier de code. Une fois le contexte compris, demandez-lui d'élaborer une solution :

我想加 Google OAuth。哪些文件要改？session 流程是怎样的？给我一份计划。

Si la solution proposée ne vous convient pas, vous pouvez appuyer sur Ctrl+G pour modifier la planification directement dans votre éditeur de texte, puis le laisser continuer sur cette base corrigée. Une fois satisfait, sortez du Plan Mode pour passer à l'implémentation — en veillant, conformément à la première règle, à lui demander de valider ses modifications.

Néanmoins, la documentation officielle rappelle que le Plan Mode n'est pas nécessaire dans tous les cas et consomme des ressources :

对于范围明确且修复很小的任务（如修复拼写错误、添加日志行或重命名变量），要求 Claude 直接执行。

Voici un critère de décision très simple proposé par l'équipe officielle :

如果你能用一句话描述这个 diff，就跳过计划。

Corriger une faute de frappe, ajouter un log, renommer une variable — pour ces modifications simples, demandez-lui d'agir directement sans vous encombrer du Plan Mode. À l'inverse, si la méthode est incertaine, s'il faut modifier plusieurs fichiers, ou si vous n'êtes pas familier avec cette partie du code — passez impérativement par une phase de planification. Un bon repère : dès que vous touchez à un module inconnu ou prévoyez de modifier au moins trois fichiers, basculez en Plan Mode ; sinon, lancez l'action directement.

💡 En résumé : En cas d'incertitude sur la méthode, de modifications multifichiers ou de code peu familier, utilisez d'abord le Plan Mode pour l'exploration et la planification ; si le diff se résume en une phrase, lancez l'action directement — ce repère officiel est le plus simple à appliquer.

---

04 Règle 3 : Être précis dans vos instructions — plus vous êtes précis, moins les retouches seront nécessaires

Cette règle fait écho à notre anecdote du début. En une phrase :

Plus vos instructions sont précises, moins vous aurez besoin d'apporter de corrections. Claude sait déduire vos intentions, mais il ne sait pas lire dans vos pensées.

Citer des fichiers précis, définir des contraintes claires et donner des exemples de référence — ces trois techniques améliorent radicalement la qualité de vos prompts. Ce tableau comparatif officiel résume parfaitement ces principes (le chapitre 15 aborde l'art de la formulation des requêtes, nous nous concentrons ici sur la précision) :

Technique	❌ Flou	✅ Précis
Délimiter le périmètre : identifier le fichier, le cas d'usage et les contraintes de test	« 加个测试到 foo.py »	« 给 foo.py 写测试，覆盖用户已登出的边界情况，别用 mock »
Pointer vers la source : l'orienter vers les informations utiles	« ExecutionFactory 这 api 咋这么怪？」	« 看 ExecutionFactory 的 git 历史，总结它的 api 是怎么演变成这样的 »
Se référer à un modèle existant : désigner un exemple dans le projet	« 加个日历组件 »	« 看主页现有组件怎么写的，HotDogWidget.php 是个好例子。照这个模式实现一个日历组件，能选月份、能前后翻年。别引新库 »
Décrire les symptômes : fournir le comportement observé, la localisation probable et le résultat attendu	« 修登录错误 »	« 用户反馈 session 超时后登录失败。查 src/auth/ 的认证流程，特别是 token 刷新。先写个失败测试复现，再修 »

Avez-vous remarqué le point commun de la colonne de droite ? Elle apporte des précisions indispensables — elle nomme les fichiers, définit les cas limites, fournit des exemples de référence et décrit l'état final attendu. C'est pourquoi le prompt remanié de notre exemple initial a fonctionné du premier coup : il a transformé une consigne floue (« corrige le bug de connexion ») en instructions précises s'appuyant sur des fichiers, décrivant les symptômes et intégrant un processus de validation.

La troisième technique « se référer à un modèle existant » est sans doute la plus précieuse. J'en ai fait l'expérience moi-même : un jour, par simplicité, j'ai demandé « ajoute une fonction d'exportation CSV ». L'outil a implémenté la fonctionnalité, mais avec une approche totalement déconnectée de la logique d'exportation déjà présente dans le projet, en important au passage une bibliothèque inutile. Mettre le code en conformité m'a coûté une demi-journée de travail. Depuis, j'applique cette consigne simple : « regarde comment l'exportation existante est faite dans XXX.ts , suis ce modèle et n'importe pas de nouvelle bibliothèque ». Cette simple précision permet d'obtenir un code dont le style et les fonctions utilitaires sont parfaitement alignés avec l'existant, évitant presque toute retouche. Désigner un exemple concret est infiniment plus efficace que d'essayer de décrire le style attendu.

Néanmoins, la documentation mentionne une exception intéressante :

当你在探索并能够改正方向时，模糊的提示可能很有用。

Une formulation ouverte comme « comment améliorerais-tu ce fichier ? » peut révéler des pistes d'amélioration auxquelles vous n'auriez pas pensé. C'est une technique très efficace pour appréhender une base de code inconnue — posez une question ouverte pour le laisser explorer, puis affinez vos instructions sur la base de ses retours. La précision reste la règle par défaut, et le flou une approche spécifique d'exploration.

Pratique associée : fournir suffisamment de contexte

La précision verbale ne suffit pas, il faut également lui fournir les données nécessaires. L'équipe officielle liste plusieurs méthodes pour injecter du contexte (le traitement multimode est détaillé au chapitre 17), que nous résumons ici :

• Utilisez le symbole @ pour référencer des fichiers, plutôt que de décrire leur emplacement. Saisir @ ouvre une liste de suggestion de fichiers ; il les lira avant de formuler sa réponse.
• Collez directement des images : captures d'écran, maquettes, rapports d'erreur graphiques... copiez-collez ou glissez-les simplement dans la console (comme pour une consultation médicale, une image vaut mieux qu'une longue description — l'analogie du chapitre 17 est très parlante).
• Fournissez des URL : collez directement les liens vers les documentations ou les références d'API. Les domaines consultés fréquemment peuvent être ajoutés à la liste d'autorisation via /permissions pour éviter les validations répétées.
• Injectez des données via un pipe : cat error.log | claude pour lui envoyer directement le contenu d'un fichier.
• Laissez-le récupérer le contexte lui-même : demandez-lui d'utiliser une commande bash ou un outil MCP pour aller chercher les informations dont il a besoin.

💡 En résumé : Formulez vos consignes avec la précision que vous exigeriez d'un stagiaire humain — ciblez les fichiers, délimitez le scénario, fournissez des exemples et décrivez le résultat attendu ; injectez le contexte via @, des images, des URL ou des pipes ; ne recourez à des consignes floues que pour le laisser explorer librement.

---

05 Règle 4 : Optimiser le fichier CLAUDE.md — privilégier la concision à l'exhaustivité

La rédaction de CLAUDE.md is un aspect incontournable des bonnes pratiques. Le chapitre 18 a détaillé sa syntaxe, son emplacement et sa génération. Cette section apporte un complément sur un point critique souvent négligé par les débutants : la concision est infiniment plus importante que l'exhaustivité.

Rappelons ce qu'est CLAUDE.md — le fichier que Claude consulte automatiquement à l'ouverture de chaque nouvelle session, contenant le contexte permanent qu'il ne peut pas déduire du code (commandes de build, style de codage, règles de flux de travail). La commande /init permet d'en générer une version initiale (abordée au chapitre 12).

Analogie : La note laissée au collègue de garde. Avant de partir, vous lui laissez un mot : « attention, le serveur redémarre automatiquement à minuit », « traite en priorité les e-mails du client A » — rédiger trois ou quatre consignes clés garantit qu'il les lira d'un coup d'œil. Mais si vous recopiez tout le manuel d'exploitation sur le mur, il ne lira rien avec attention, et vos avertissements cruciaux seront noyés dans la masse. Le fichier CLAUDE.md est cette note : sa valeur réside dans sa concision, pour que chaque ligne soit lue, et non dans son exhaustivité.

Ce n'est pas une simple intuition, la documentation officielle insiste lourdement sur ce point :

保持简洁。对于每一行，问自己：「删除这个会导致 Claude 犯错吗？」如果不会，删除它。膨胀的 CLAUDE.md 文件会导致 Claude 忽略你的实际指令！

Il existe deux manières classiques de tomber dans ce piège. La première consiste à vouloir détailler l'historique de conception du projet dans CLAUDE.md pour « lui donner tout le contexte », ce qui produit des dizaines de lignes superflues. En conséquence, il passe souvent à côté des règles strictes (comme « interdiction de modifier les fichiers de migration de base de données »), noyées dans les explications historiques — contexte qu'il est d'ailleurs capable de déduire lui-même en lisant le code. La seconde consiste à y insérer des spécifications très pointues qui ne servent que pour des tâches ponctuelles, ce qui revient à encombrer le tableau blanc avec des informations inutiles pour la majorité des sessions. Suivez les recommandations officielles : supprimez l'historique et les explications (déduites du code) et déplacez les spécifications ponctuelles dans un Skill (chapitre 26) ; une fois le fichier CLAUDE.md allégé, le respect des règles fondamentales s'améliorera de manière spectaculaire.

Que faut-il y faire figurer et que faut-il en retirer ? Utilisez ce tableau de référence officiel pour auditer votre fichier CLAUDE.md :

✅ À inclure	❌ À exclure
Commandes bash que Claude ne peut pas deviner	Tout ce qu'il peut déduire en lisant le code
Règles de style de code qui diffèrent des standards par défaut	Normes de langage qu'il maîtrise déjà
Commandes de test et lanceur de tests privilégié	Documentation détaillée d'API (fournissez plutôt un lien)
Règles du dépôt (nommage de branche, conventions de PR)	Informations fréquemment modifiées
Décisions d'architecture propres à votre projet	Longues explications ou tutoriels
Particularités de l'environnement de développement (variables d'environnement requises)	Recommandations évidentes comme « écris du code propre »
Pièges fréquents et comportements contre-intuitifs	Description détaillée de chaque fichier de la base de code

Le point commun de la colonne de droite : supprimez tout ce que Claude peut déduire seul, tout ce qui est sujet à changement et toutes les consignes évidentes.

La documentation propose également deux techniques avancées :

• Pour accentuer l'importance d'une règle, utilisez des termes forts comme IMPORTANT ou YOU MUST (comme c'est le cas dans le fichier CLAUDE.md de ce tutoriel).
• CLAUDE.md permet de référencer d'autres fichiers via la syntaxe @chemin, par exemple : Git workflow: @docs/git-instructions.md, ce qui permet d'externaliser les détails pour garder le fichier principal léger.

Enfin, la documentation propose un outil de diagnostic très pratique : si Claude persiste à ignorer une règle répétée, c'est probablement que le fichier est trop long et que la consigne est noyée dans la masse ; s'il vous questionne sur un point pourtant documenté dans CLAUDE.md, c'est que la formulation manque de clarté. Traisez CLAUDE.md comme du code — auditez-le en cas d'anomalie, élaguez-le régulièrement et observez si son comportement s'améliore.

💡 En résumé : Le secret de CLAUDE.md réside dans sa concision et non son exhaustivité — validez chaque ligne en vous demandant « sa suppression provoquera-t-elle une erreur de Claude ? » et supprimez-la sinon ; remplacez les documentations d'API par des liens et déplacez les connaissances ponctuelles dans un Skill, pour que votre note reste lisible d'un coup d'œil.

---

06 Règle 5 : Corriger immédiatement les dérives, sans insister inutilement

La dernière règle concerne la gestion d'une session. En clair :

一发现 Claude 跑偏，立刻纠正它，别等它越走越远。 对话是可逆的——用好这一点。

Les meilleurs résultats découlent d'une boucle de rétroaction rapide. Claude réussit parfois du premier coup, mais dans la majorité des cas, intervenir rapidement est bien plus efficace que de le laisser s'égarer pour tout reconstruire ensuite. La documentation officielle liste plusieurs outils de réorientation :

Objectif	Action	Cas d'usage pratique
Interrompre l'action	Appuyer sur Esc, le contexte est conservé et vous pouvez le réorienter	Interrompre immédiatement s'il ouvre le mauvais fichier, pour éviter qu'il ne poursuive sur une fausse piste
Revenir en arrière	Double appui sur Esc ou /rewind pour restaurer l'état du code et de la conversation	Si le code devient confus, utiliser /rewind pour restaurer un état propre (le chapitre 37 détaille les points de contrôle)
Annuler la dernière étape	Dire simplement « annule cette modification »	Plus rapide qu'une restauration manuelle
Réinitialiser entre tâches indépendantes	Saisir /clear pour vider le contexte	Saisir /clear après avoir corrigé un bug avant de passer au développement d'une nouvelle fonctionnalité

Voici une règle d'or partagée par les utilisateurs chevronnés et essentielle pour les débutants, formulée sans détour par l'équipe officielle :

**如果你在一个会话里对同一个问题纠正了 Claude 两次以上，context 就被失败的方法污染了。**运行 /clear，用一个更具体的、包含你刚学到的东西的提示重新开始。

En clair : si une troisième correction échoue, n'insistez pas pour une quatrième. À ce stade, le tableau blanc est encombré de notes sur des essais infructueux, et Claude est perturbé par ce bruit ambiant. La bonne réaction est d'exécuter /clear pour repartir de zéro — en veillant cette fois à intégrer dans votre prompt de départ ce que vous avez appris (comme « évite l'approche X, la cause de l'anomalie se situe au niveau de Y »).

干净的会话 + 更好的提示，几乎总是优于冗长的会话 + 一堆累积的更正。

J'ai dû faire l'erreur moi-même pour m'en convaincre. Je me suis obstiné un jour à lui faire corriger une anomalie de gestion d'état ; après cinq ou six corrections successives, le code était devenu si confus que je ne le comprenais plus moi-même, mais je m'entêtais à ne pas vouloir redémarrer la session. Finalement, je me suis résolu à utiliser /rewind pour revenir à l'état initial, puis /clear pour ouvrir une nouvelle session en expliquant clairement : « ce bug est lié à un rappel asynchrone lors du démontage du composant, ne touche pas à la logique de rendu » — le problème a été résolu en deux cycles dans la nouvelle session, après une après-midi entière perdue en allers-retours. Depuis ce jour, je m'impose cette règle stricte : si un problème exige plus de trois corrections, j'exécute systématiquement /clear pour recommencer.

Deux bonnes habitudes de gestion de session

Cette règle s'accompagne de deux recommandations officielles pour préserver l'espace de votre tableau blanc (en lien avec la gestion du contexte du chapitre 19) :

• Déléguer l'exploration à un subagent : demandez-lui d'« utiliser un subagent pour analyser X ». Il parcourra les fichiers sur son propre tableau blanc indépendant et ne renverra que ses conclusions dans la conversation principale, préservant ainsi votre espace de contexte (détaillé au chapitre 23). La consigne officielle est claire — « Le contexte étant votre principale contrainte, les subagents sont l'un des outils les plus puissants à votre disposition ».
• Nommer vos sessions pour les reprendre plus tard : claude --continue pour reprendre la dernière session en date, ou claude --resume pour en sélectionner une dans la liste. Attribuez-leur des noms descriptifs comme oauth-migration et traisez-les à la manière de branches git pour pouvoir y revenir facilement.

💡 En résumé : Dès que vous constatez une dérive, appuyez sur Esc pour interrompre, utilisez /rewind pour annuler ou demandez d'« annuler la modification » ; après trois tentatives de correction infructueuses, faites table rase avec /clear et recommencez avec les enseignements tirés — une session propre avec un prompt affiné l'emporte toujours sur une longue session encombrée de corrections accumulées. Déléguez l'exploration à un subagent pour ne pas encombrer le contexte principal.

---

07 Règle 6 : Se familiariser avec un seul Claude avant de multiplier les instances

Les cinq premières règles reposent sur le schéma classique « un utilisateur, un Claude, une session ». Une fois cette relation maîtrisée, la documentation propose des techniques de distribution horizontale pour démultiplier votre productivité. Cette section en présente les grandes lignes, les détails de mise en œuvre étant abordés au chapitre 41 (tâches parallèles) et au chapitre 44 (GitHub Actions).

先把一个 Claude 用对，再谈并行。 顺序别反——一个都指挥不利索，开五个只会乱五倍。

L'équipe officielle répertorie plusieurs approches de distribution :

• Exécuter plusieurs sessions en parallèle : pour des tâches indépendantes, ouvrez plusieurs sessions pour les traiter séparément. La méthode d'isolation la plus robuste consiste à utiliser des worktrees git (chaque session travaille sur un checkout git indépendant pour éviter les conflits d'édition), ou à utiliser l'application de bureau ou la version web pour gérer visuellement vos sessions.
• Le modèle Rédacteur / Relecteur : une approche que je recommande vivement. Demandez à la session A d'écrire le code, et ouvrez une session B vierge pour le relire. L'intérêt réside dans le fait que le tableau blanc de B est vierge : il n'a aucun parti pris pour le code qui vient d'être écrit, et se montrera bien plus critique que A s'auto-évaluant. La documentation officielle le souligne :

新鲜的 context 改进了代码审查，因为 Claude 不会偏向于它刚刚编写的代码。

• Exécution de scripts en mode non interactif : claude -p "votre prompt" permet d'obtenir un résultat directement sans ouvrir de session interactive, ce qui est idéal pour intégrer Claude dans une CI, un hook de pre-commit ou un script de traitement par lots. Utilisez --output-format json pour obtenir une sortie structurée, et --verbose pour le débogage. Pour des migrations massives, vous pouvez écrire une boucle qui exécute claude -p sur des milliers de fichiers, en encadrant ses actions autorisées avec --allowedTools pour un fonctionnement autonome sécurisé.
• Ajouter une validation critique : plus Claude s'exécute de manière autonome, plus il devient crucial de demander à un subagent vierge d'examiner le diff final avant livraison. La commande intégrée /code-review sert précisément à cela — elle lance un sous-agent qui analyse uniquement les différences pour détecter les anomalies et remonter ses conclusions.

Cependant, la documentation officielle apporte une mise en garde pour éviter le sur-engineering :

被提示查找缺陷的审查者通常会报告一些，即使工作是健全的……追逐每个发现会导致过度工程。

En clair : si vous lui demandez de chercher des défauts, il en trouvera inévitablement, même si le code est tout à fait correct. Ne cherchez pas à corriger chaque remarque, sous peine d'accumuler des abstractions et du code défensif inutiles — demandez au relecteur de « ne signaler que les défauts affectant la correction, et de traiter le reste comme optionnel ». C'est le même principe que la lutte contre le sur-engineering.

💡 En résumé : Maîtrisez d'abord l'usage d'un Claude unique avant de distribuer le travail — parallélisation de sessions (avec isolation worktree), modèle Rédacteur/Relecteur pour une relecture impartiale, intégration de claude -p dans vos scripts et validation critique finale ; ne traitez pas toutes les remarques du relecteur, ne corrigez que celles affectant la correction du code pour éviter le sur-engineering.

---

08 Quelques bonnes habitudes de communication

Les cinq règles précédentes forment l'ossature, complétée par quelques conseils officiels sur la manière de communiquer avec Claude.

Premièrement, interrogez-le comme un collègue senior. Face à une base de code inconnue, n'essayez pas de tout comprendre seul ; posez-lui les questions que vous poseriez à un développeur expérimenté de l'équipe — comme le suggère la documentation officielle : « Posez à Claude le type de questions que vous poseriez à un ingénieur senior » :

日志是怎么工作的？
我要怎么新建一个 API 端点？
foo.rs 第 134 行那个 async move 是干嘛的？
为啥这段代码第 333 行调 foo() 而不是 bar()？

Pas besoin de formulation magique, posez la question directement. C'est une excellente méthode d'intégration : interrogez-le ainsi à chaque fois que vous démarrez un nouveau projet, c'est bien plus rapide que de parcourir la documentation.

Deuxièmement, pour les fonctionnalités importantes, laissez-le vous « interviewer ». C'est une astuce officielle très efficace — avant de coder, demandez à Claude de vous poser des questions :

我想做 [一句话描述]。用 AskUserQuestion 工具详细采访我。

问技术实现、UI/UX、边界情况、顾虑和权衡。别问显而易见的，
专挑我可能没想到的硬骨头问。聊透了，把完整的 spec 写到 SPEC.md。

Il soulèvera des points auxquels vous n'auriez pas pensé (cas limites, compromis d'architecture...). Cet entretien permet de générer un fichier SPEC.md ; ouvrez ensuite une nouvelle session propre pour implémenter la fonctionnalité sur cette base. La documentation le souligne : « passer du temps à affiner la spec est bien plus rentable que de surveiller l'implémentation ». C'est une approche recommandée pour toutes les fonctionnalités d'envergure, car la spec ainsi générée révèle souvent des failles dans l'expression des besoins.

你应该问 Claude 你会问另一个工程师的相同类型的问题。

Troisièmement, exigez des preuves, ne vous fiez pas à ses affirmations. Ce conseil fait écho à la première règle, mais mérite d'être érigé en habitude de communication : à chaque fois qu'il affirme « cela devrait fonctionner » ou « la correction est en place », répondez systématiquement « exécute la vérification et affiche le résultat ». Exiger des preuves concrètes est le meilleur moyen de valider une implémentation qui semble correcte à l'œil nu mais omet des cas limites.

💡 En résumé : Face à un code inconnu, interrogez-le comme un collègue senior (sans prompt complexe) ; pour les grands projets, utilisez AskUserQuestion pour qu'il mène un entretien préalable et génère SPEC.md avant de coder dans une session propre ; dès qu'il affirme avoir terminé, demandez-lui d'afficher les résultats de tests ou de commandes comme preuves.

---

09 Pratique : mesurer concrètement l'impact de la précision avec une expérience comparative

La théorie ne suffit pas, il faut l'expérimenter. Cette manipulation de cinq minutes, réalisable sans aucun projet existant, vous permettra de mesurer concrètement l'intérêt d'associer précision et processus de validation.

Objectif : Soumettre le même besoin à Claude, d'abord avec un prompt flou, puis avec un prompt précis et des critères de validation, pour comparer la qualité du résultat.

Étape 1 : Créer un dossier vide et lancer Claude

mkdir cc-best-practice-demo && cd cc-best-practice-demo && claude

Étape 2 : Envoyer un prompt flou

Saisissez la consigne suivante (en simplifiant à l'extrême, comme le ferait un débutant) :

写个判断密码强不强的函数

Résultat attendu : Il générera probablement une fonction comme checkPassword, mais les critères de validation seront purement arbitraires — il se basera peut-être uniquement sur la longueur, ou ajoutera des contraintes non formulées. De plus, il n'y aura probablement aucun test, vous laissant dans l'incertitude quant à sa correction. Conservez cette version.

Étape 3 : Exécuter /clear et envoyer un prompt précis avec critères de validation

/clear

Après réinitialisation, formulez à nouveau le besoin en appliquant la règle 1 et la règle 3 :

写一个 isStrongPassword(pwd) 函数，放到 password.js。
规则：长度 >= 8、至少 1 个大写字母、至少 1 个数字，三条全满足才算强。
示例用例：'Abc12345' 为 true，'abc12345' 为 false（没大写），'Abcdefgh' 为 false（没数字）。
写完用这些用例跑一遍验证，把测试输出贴给我。

Résultat attendu : Cette version présente trois différences majeures —

1. Les critères de validation de la fonction correspondent exactement à vos consignes, sans règles arbitraires ;
2. Il exécutera réellement les exemples de test fournis et affichera les résultats (ex. ✓ Abc12345 → true) ;
3. Un simple coup d'œil au résultat de test vous permet de valider le travail, sans avoir à lire le code pour deviner s'il fonctionne.

Étape 4 : Comparer les deux versions

Inutile de retenir de grands principes, contentez-vous d'observer la différence entre ces deux résultats : avec la première version, vous devez assurer vous-même le contrôle qualité sans garantie d'identifier les erreurs ; avec la seconde, Claude valide lui-même son travail et vous fournit les preuves. C'est l'essence même des règles de ce chapitre — consacrer quelques mots de plus pour définir les « règles, exemples et processus de validation » vous évite plusieurs cycles d'allers-retours de correction.

💡 En résumé : Pour un même besoin, un prompt flou vous oblige à contrôler le travail, tandis qu'un prompt précis avec critères de validation permet à Claude de livrer un résultat déjà vérifié ; expérimenter cette différence est plus parlant que de mémoriser dix règles.

---

10 Résumé

Ce chapitre n'a pas enseigné de nouvelles fonctionnalités, mais s'est concentré sur « comment utiliser au mieux les outils existants » — en synthétisant les retours d'expérience officiels et des utilisateurs chevronnés sous forme de règles pratiques.

Pour conclure, voici un tableau récapitulatif reliant les six règles à la contrainte globale de la fenêtre de contexte :

Situation rencontrée	Règle à appliquer	Action clé en une phrase
« Il finit son travail et je dois tout relire pour vérifier si c'est correct »	Fournir un moyen de validation	Ajouter « lance les tests / compare les captures d'écran et vérifie une fois terminé » en fin de prompt
« Le code généré fait fausse route dès le départ »	Explorer avant de coder	Basculer en Plan Mode pour le code peu familier ou les modifications multifichiers ; agir directement si le diff se résume en une phrase
« Il ne comprend pas ce que j'attends de lui »	Être précis dans vos instructions	Préciser les fichiers, le scénario, donner un exemple de référence et décrire l'état final attendu ; injecter le contexte via @ ou des images
« Il ignore systématiquement les règles pourtant répétées »	Optimiser CLAUDE.md	Élaguer chaque ligne qui ne prévient pas directement une erreur ; remplacer les documentations détaillées par des liens et déléguer les détails à un Skill
« La situation s'envenime après plusieurs tentatives de correction successives »	Corriger immédiatement les dérives	Réinitialiser avec /clear après trois tentatives infructueuses et recommencer avec les enseignements tirés
« Un seul Claude ne suffit pas à soutenir mon rythme »	Distribuer le travail	Maîtriser l'outil unique avant de paralléliser ; utiliser le modèle Rédacteur/Relecteur pour une relecture impartiale

Vous devriez maintenant être en mesure de : analyser vos éventuelles sessions de lutte avec Claude sous l'angle de la contrainte globale (ne pas surcharger le tableau blanc) et identifier la règle manquante — absence de critères de validation, manque de précision, fichier CLAUDE.md trop lourd, ou nécessité d'exécuter /clear. Ces six principes ne sont pas des règles figées ; comme le souligne l'équipe officielle, ils constituent des « points de départ généralement efficaces ». À l'usage, vous développerez une intuition : savoir quand être précis, quand rester flou pour le laisser explorer, quand réinitialiser et quand le laisser accumuler du contexte.

注意什么有效。当 Claude 产生很好的输出时，注意你做了什么。

En appliquant ces règles, votre collaboration avec Claude passera de la frustration à une fluidité et une efficacité accrues.

---

Le chapitre suivant 50 « Anti-patrons : les erreurs d'usage courantes » — après avoir vu « comment faire », nous verrons « ce qu'il ne faut surtout pas faire ». J'ai mentionné brièvement la liste officielle des erreurs courantes (les sessions à rallonge, les corrections à répétition, l'hyper-inflation de CLAUDE.md, la confiance aveugle ou l'exploration sans fin) ; le prochain chapitre les détaillera l'une après l'autre avec des exemples concrets d'erreurs et leurs remèdes. En y réfléchissant, quel est le piège dans lequel vous êtes tombé le plus souvent lors de vos tests avec Claude Code ? Gardez cette question en tête en abordant le chapitre suivant.

---

Lectures recommandées

• Initialisation du projet : générer CLAUDE.md en un clic avec /init
• Exemple d'utilisation des Skills : installer, appeler et observer
• Équipes d'agents : collaboration inter-sessions