Claude Code : Bonnes Pratiques d'Usage Réel en Production

[Le point de vue de l’opérateur] J’utilise Claude Code tous les jours ouvrés dans deux entreprises — une marque de conseil et Pickleland, un complexe de pickleball à Pflugerville, au Texas — pour tout, du pipeline de publication de ce blog à la relecture de code sur des Workers en production. Ceci n’est pas une introduction à ce qu’est Claude Code. Ce sont les habitudes que j’ai gardées après des mois d’usage réel, et celles que j’ai abandonnées parce qu’elles me coûtaient plus qu’elles ne me rapportaient.

Table des matières

Ouvrir Table des matières

• Écrire le CLAUDE.md comme des règles, pas comme de la documentation
• Ce que je délègue à un sous-agent, et ce que je garde dans mon propre fil
• La gestion du contexte est une discipline quotidienne, pas une configuration ponctuelle
• Ce que j’ai appris à ne pas le laisser faire seul
• Vérifie avant de livrer — le « terminé » de Claude est une affirmation, pas un fait
• Le verdict de l’opérateur
• FAQ
  • Que doit vraiment contenir un fichier CLAUDE.md ?
  • Comment décides-tu quand faire confiance à la sortie de Claude Code sans la revérifier ?
  • Laisses-tu Claude Code faire des commits et des push tout seul ?
  • Quelle est l’habitude qui t’a fait gagner le plus de temps ?

Écrire le CLAUDE.md comme des règles, pas comme de la documentation

La première version de chaque CLAUDE.md que j’ai écrit était trop longue, et chacune a raccourci avec le temps, jamais rallongé. L’erreur, c’est de le traiter comme une page de wiki — du contexte, de la philosophie, du « pourquoi on fait comme ça ». Claude lit le fichier entier à chaque session, que la tâche en cours en ait besoin ou non, donc chaque paragraphe qui n’est pas une instruction fait concurrence, pour l’attention, aux paragraphes qui en sont une.

Ce qui survit à l’élagage est plus étroit : des règles dures, idéalement celles qu’un test fait respecter pour qu’elles ne puissent pas régresser en silence, plus des liens vers des documents plus longs pour les cas qui ont vraiment besoin du détail. « Les titres font moins de 60 caractères » mérite une ligne. L’histoire de pourquoi cette limite existe mérite un lien vers un document, pas un paragraphe dans le fichier que Claude relit à chaque session.

La deuxième chose que j’ai ajoutée, et celle dont je n’attendais pas qu’elle compte autant : une courte liste de faits déjà tranchés, écrits une fois, avec l’instruction explicite de ne pas les réinvestiguer. Au début, Claude Code rediagnostiquait la même fausse alerte toutes les quelques sessions — un test instable, une bizarrerie connue dans une étape de build — et brûlait du contexte à redériver une conclusion à laquelle j’étais déjà arrivé. Une ligne qui énonce le fait vérifié et dit à l’agent de passer à la suite plutôt que de rouvrir l’enquête a fait tomber ce temps mort à presque zéro. La règle que j’applique : si tu as expliqué deux fois le même « en fait, c’est normal », ça appartient au CLAUDE.md comme un fait, pas comme quelque chose que tu retapes dans le chat une troisième fois.

Ce que je délègue à un sous-agent, et ce que je garde dans mon propre fil

J’ai écrit le cadre de décision complet sur les compétences, les commandes slash et les sous-agents séparément, donc je ne vais pas le refaire ici. Ce qui vaut la peine d’ajouter, c’est le filtre au niveau opérationnel que j’applique réellement avant d’en faire naître un : puis-je énoncer en une phrase à quoi ressemble « terminé », et lirais-je vraiment les étapes intermédiaires si elles restaient dans mon fil principal ?

Si la réponse aux deux est non — la tâche est délimitée et je ne veux que le résultat — c’est un sous-agent. Traduire cet article en 12 langues en est l’exemple le plus net : chaque traduction est vérifiable indépendamment, ce déploiement en parallèle est exactement pourquoi le pipeline de contenu fait tourner un sous-agent par langue, et je ne voudrais jamais que 12 langues d’allers-retours intermédiaires encombrent le fil où je suis encore en train de décider si l’article en anglais est bon.

Si la tâche exige que je voie le raisonnement au fur et à mesure — un changement de schéma où la troisième décision dépend de ce qu’a révélé la deuxième — ça reste dans mon fil principal. Le mode d’échec que j’ai réellement rencontré, c’est de faire naître un sous-agent pour ce genre de tâche quand même, de récupérer un résumé propre, puis de demander « attends, qu’est-ce que tu as trouvé exactement » trois fois de suite parce que le résumé a laissé tomber le seul détail qui comptait. Quand ça arrive deux fois sur le même type de tâche, j’arrête de le déléguer.

La gestion du contexte est une discipline quotidienne, pas une configuration ponctuelle

Le CLAUDE.md est la partie qu’on écrit une fois et qu’on oublie. La fenêtre de contexte est celle que je gère à chaque session, et c’est elle qui détermine réellement si le résultat est bon.

• Lire avant de le laisser modifier. Claude Code proposera volontiers une modification contre un fichier dont il n’a pas vu l’état actuel complet. Je le fais toujours lire le fichier d’abord, même quand je suis sûr de savoir ce qu’il contient — je me suis assez souvent trompé sur ce « sûr » pour que ce ne soit plus optionnel.
• Ne laisse pas une session faire deux tâches sans rapport. Un fil qui a passé une heure à déboguer un problème de déploiement puis bascule vers de la rédaction marketing traîne cette heure de sortie d’outils non pertinente dans chaque réponse suivante. Je démarre une nouvelle session plutôt que de demander à Claude d’« oublier le déploiement » — cette instruction ne retire pas les tokens, elle demande juste au modèle de les ignorer, ce qu’il fait imparfaitement.
• Planifier avant de le laisser exécuter. Pour tout ce qui dépasse deux ou trois étapes, je demande d’abord le plan et je le lis avant d’approuver l’exécution. Lire un plan de cinq lignes prend quinze secondes. Découvrir que l’étape trois était fausse après que l’étape cinq a déjà tourné coûte le reste de l’après-midi.
• Les gros copier-coller sont un coût, pas un confort. Déposer un fichier de log entier ou une réponse d’API complète dans la conversation quand seules trois lignes comptent brûle du contexte sur les 97 % restants. Je fais un grep d’abord et je colle la correspondance.

C’est le même principe derrière le context engineering pour les agents IA en général — Claude Code rend juste le coût visible plus tôt, parce que c’est vous qui voyez le contexte se remplir en temps réel au lieu de le déboguer après coup dans un log de Worker.

Ce que j’ai appris à ne pas le laisser faire seul

Chaque action irréversible — commit, push, publication, envoi, dépense — reste derrière une étape d’approbation explicite que j’exécute moi-même, jamais une que Claude Code décide de prendre parce qu’il a jugé la tâche terminée. C’est le même principe de supervision humaine que j’applique partout ailleurs où des agents touchent à de vraies conséquences, et Claude Code n’y échappe pas sous prétexte qu’il tourne sur ma propre machine plutôt que dans le cloud.

L’autre chose que j’ai arrêté de faire : accorder une autorisation large et permanente pour des commandes destructrices. rm -rf, force-push, ignorer les hooks de tests — aucun n’obtient un oui général. Chacun est demandé, à chaque fois, en contexte, parce que la seule fois où j’ai préapprouvé quelque chose de large « pour gagner du temps » a été la seule fois où la tâche a dérivé vers un périmètre que je n’avais pas vraiment revu. Les cinq secondes que coûte une invite de permission sont une assurance bon marché contre l’alternative.

Vérifie avant de livrer — le « terminé » de Claude est une affirmation, pas un fait

C’est l’habitude qui s’est le plus rentabilisée, et c’est la moins spectaculaire : je ne fais pas confiance à un rapport d’achèvement. Je lance la vérification réelle.

Claude Code vous dira qu’un build a réussi, qu’une suite de tests est au vert, qu’un lien fonctionne. Parfois ce rapport est généré à partir d’une sortie réelle. Parfois c’est un résumé confiant d’une commande qui n’a tourné qu’à moitié, ou d’un test qui est revenu tôt sans rien d’utile dedans. Les deux sont identiques dans la transcription du chat. La seule façon de les distinguer, c’est de regarder soi-même la sortie réelle — la même discipline derrière le harnais d’évaluation que j’utilise pour livrer des agents : une tâche n’est pas notée terminée parce que l’agent le dit, elle l’est quand la vérification définie passe réellement.

En pratique, ça veut dire : lancer la commande de build et lire sa sortie, pas la paraphrase de Claude. Ouvrir le fichier qu’il dit avoir modifié. Cliquer sur le lien qu’il dit fonctionner. Pour le contenu en particulier, je relis le brouillon de façon adversariale contre les règles que je sais appliquées — limites de longueur, motifs interdits, liens internes cassés — plutôt que de faire confiance à Claude pour les avoir correctement appliquées du premier coup, parce que c’est presque toujours le cas et occasionnellement non, et le coût de cette exception occasionnelle qui finit sur un site en ligne est plus élevé que les quatre-vingt-dix secondes que prend la relecture.

Le verdict de l’opérateur

Rien de tout ça ne consiste à faire moins confiance à Claude Code avec le temps — il s’agit d’être précis sur où cette confiance doit réellement se gagner. Des CLAUDE.md courts et vérifiables plutôt qu’une longue documentation. Des sous-agents pour le travail délimité et vérifiable, votre propre fil pour tout ce où le raisonnement compte autant que le résultat. Du contexte neuf plutôt qu’une session traînée en longueur. Des portes d’approbation sur tout ce qu’on ne peut pas défaire. Et une vraie vérification, lue par vous-même, avant que tout ce que vous avez délégué parte en production. C’est toute la liste, et c’est celle que j’applique réellement.

FAQ

Que doit vraiment contenir un fichier CLAUDE.md ?

Des règles que l’agent doit suivre à chaque session, formulées comme des instructions — pas le contexte de pourquoi le code en est arrivé là. Si une règle est appliquée par un test, dites-le et laissez le test être la source de vérité. Le contexte plus long appartient à un document que le CLAUDE.md pointe, lu seulement quand la tâche touche vraiment ce domaine, pas rechargé par défaut à chaque session.

Comment décides-tu quand faire confiance à la sortie de Claude Code sans la revérifier ?

Je ne décide pas de sauter la vérification — je décide de son coût. Lancer une commande de build est presque gratuit, donc je le fais toujours. Une relecture adversariale complète d’un long document prend plus de temps, donc je la réserve à ce qui part vers un vrai public. La seule chose que je ne saute jamais : tout ce qui est irréversible — publier, commit, dépenser de l’argent.

Laisses-tu Claude Code faire des commits et des push tout seul ?

Non. Chaque commit et chaque push, c’est moi qui les exécute, après avoir regardé le diff. Claude Code propose la modification ; je suis la porte d’approbation pour tout ce qui sort de l’état brouillon, la même règle que j’applique à tous les autres agents que je fais tourner.

Quelle est l’habitude qui t’a fait gagner le plus de temps ?

Traiter un rapport d’achèvement comme une affirmation, pas comme un fait, et lancer moi-même la vraie vérification. Ça a l’air de ralentir les choses. En pratique, c’est l’inverse — attraper un faux « terminé » en trente secondes est plus rapide que le découvrir en production trois jours plus tard.

---

À lire aussi : Claude skills vs. slash commands vs. sous-agents · Le stack qui fait tourner 30+ agents · Agents IA supervisés : quand ajouter une validation humaine · Comment utiliser les tâches planifiées de Claude

Envie de faire tourner Claude Code comme ça dans votre entreprise ? Mon cours AI Agents for Beginners couvre les fondamentaux de construction que ce manuel suppose acquis. Le programme cowork est là où j’enseigne ces habitudes opérationnelles en groupe structuré. Si vous préférez qu’on s’occupe de la mise en place pour vous, réservez une session de 30 minutes.