Technique

Les 10 commandes Claude Code que j'utilise tous les jours

Patrice Huetz6 avril 202611 min

J'utilise Claude Code depuis sa sortie publique. Pas comme gadget — comme outil principal de développement, d'écriture, de gestion de projet. Au fil des mois, j'ai identifié les fonctionnalités qui font vraiment la différence au quotidien. Pas les plus spectaculaires, mais celles que j'utilise chaque jour et qui me feraient revenir en arrière si elles disparaissaient.

Voici les dix que je considère indispensables.

1. /plan mode — concevoir avant de coder

La première erreur avec un agent de code, c'est de le laisser coder immédiatement. Tu lui dis « ajoute un système d'authentification » et il commence à écrire du code. Vingt fichiers plus tard, tu réalises que l'architecture ne convient pas, que les choix de bibliothèques sont discutables, et que tu vas devoir tout refaire.

Le mode plan change la donne. Quand tu tapes /plan, Claude Code passe en mode réflexion : il analyse, propose une architecture, identifie les risques, estime la complexité — mais n'écrit pas une seule ligne de code. Tu obtiens un plan structuré avec des étapes numérotées, des choix techniques justifiés, et des alternatives considérées.

En pratique, je lance /plan systématiquement pour toute tâche de plus de 15 minutes. Le plan devient un contrat entre moi et l'agent. Je le valide, je l'amende si nécessaire, et ensuite seulement je dis « go, implémente le plan ». La qualité du code produit est incomparablement meilleure.

💡

Copie le plan généré dans ton fichier CLAUDE.md. Comme ça, même si la session plante ou si tu relances l'agent, le plan persiste. C'est la base du Ralph Loop : l'état vit dans le filesystem, pas dans la mémoire de l'agent.

2. Agents parallèles — 3-4 agents sur des tâches indépendantes

Claude Code peut lancer des sous-agents qui travaillent en parallèle. Ce n'est pas juste du multithreading — c'est plusieurs instances de Claude qui travaillent simultanément sur des tâches différentes, chacune avec son propre contexte.

Mon cas d'usage favori : quand j'ai trois bugs indépendants à corriger, je dis « corrige ces trois bugs en parallèle » et Claude Code lance trois agents. Chacun travaille dans son coin, lit les fichiers nécessaires, teste sa correction, et rapporte le résultat. Ce qui aurait pris 30 minutes en séquentiel prend 10 minutes.

Les règles que j'ai apprises pour que ça fonctionne bien :

•Les tâches doivent être indépendantes — Si l'agent B a besoin du résultat de l'agent A, le parallélisme ne marche pas
•Limite à 3-4 agents — Au-delà, la qualité chute (chaque agent a un contexte plus réduit)
•Tâches bien délimitées — « Ajoute les tests pour auth, payment et notification » fonctionne. « Refactore le projet » ne fonctionne pas

ℹ️

Les agents parallèles sont particulièrement efficaces pour les tâches de recherche. « Trouve tous les endroits où on gère les erreurs réseau dans le projet » — trois agents scannent trois répertoires différents et consolident les résultats. Le context engine du parent intègre tout via le hook onSubagentEnded.

3. CLAUDE.md — le cerveau du projet

CLAUDE.md est un fichier markdown à la racine du projet qui contient tout ce que l'agent doit savoir : architecture, conventions, commandes fréquentes, pièges connus, décisions de design. C'est le « cerveau persistant » qui survit entre les sessions.

Mon CLAUDE.md pour ce site fait 200 lignes. Il contient :

•La structure des répertoires (quel fichier fait quoi)
•Les commandes de build et de déploiement
•Les conventions de nommage
•Les erreurs fréquentes et comment les éviter
•L'historique des décisions architecturales

L'avantage est double. D'abord, chaque nouvelle session de Claude Code démarre avec un contexte riche — pas besoin de réexpliquer le projet. Ensuite, le CLAUDE.md sert de documentation vivante. Quand Claude Code prend une décision importante, je lui dis « ajoute ça dans CLAUDE.md ». Le fichier grandit organiquement avec le projet.

⚠️

Ne mets pas tout dans CLAUDE.md. Si le fichier dépasse 500 lignes, l'agent passe trop de tokens à le lire et pas assez à travailler. Garde-le focalisé sur ce qui est actionnable : conventions, commandes, pièges. L'historique détaillé va ailleurs.

4. Hooks — validation pré-commit, déploiement post-build

Les hooks sont des scripts qui s'exécutent automatiquement à certains moments du cycle de vie de Claude Code. Ce sont les équivalents des git hooks, mais pour l'agent.

Mes hooks les plus utiles :

•PreToolUse (Bash) — Avant chaque commande bash, vérifie qu'elle n'est pas destructrice (pas de rm -rf /, pas de git push --force)
•PostToolUse (Write) — Après chaque écriture de fichier, lance le linter pour vérifier la syntaxe
•Notification — Quand l'agent a fini une tâche longue, envoie une notification système

Les hooks sont configurés dans .claude/settings.json. Voici un exemple concret :

json

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [{
          "type": "command",
          "command": "echo \"$CLAUDE_TOOL_INPUT\" | python3 .claude/validate-command.py"
        }]
      }
    ]
  }
}

💡

Le hook de validation pré-commit est celui qui m'a sauvé le plus de fois. L'agent propose parfois un `git reset --hard` pour « nettoyer » — le hook l'intercepte et demande confirmation. Sans ça, j'aurais perdu du travail au moins trois fois.

5. Worktrees — environnements isolés pour chaque agent

Les worktrees Git sont une fonctionnalité méconnue que Claude Code exploite brillamment. Un worktree est une copie de travail du même dépôt, dans un répertoire séparé, sur une branche différente. Chaque agent peut travailler dans son propre worktree sans interférer avec les autres.

En pratique, quand je lance un agent parallèle sur une tâche qui modifie des fichiers, Claude Code crée automatiquement un worktree. L'agent travaille, committe, et le résultat est mergé dans la branche principale à la fin. Pas de conflits, pas de fichiers écrasés.

J'utilise aussi les worktrees manuellement pour des expérimentations : « crée un worktree et teste si on peut remplacer Prisma par Drizzle ». L'agent expérimente librement sans toucher au code principal. Si ça marche, je merge. Sinon, je supprime le worktree et c'est comme si rien ne s'était passé.

6. Skills — /write-blog-article, /publish-article

Les skills sont des commandes personnalisées que tu crées pour automatiser des workflows récurrents. Elles sont définies dans .claude/skills/ et invoquées avec une commande slash.

J'ai créé deux skills pour mon blog :

•/write-blog-article — Génère un article complet en respectant le format frontmatter, les shortcodes SPIP, la longueur minimale et le ton éditorial
•/publish-article — Publie l'article via l'API admin du site

Chaque skill est un fichier markdown qui décrit le workflow, les contraintes et le format de sortie. C'est du prompt engineering packagé et réutilisable.

Le gain de temps est énorme. Avant les skills, publier un article me prenait 20 minutes de copier-coller et de vérification de format. Maintenant, c'est une commande. Et surtout, le format est toujours correct — pas d'oubli de frontmatter, pas de shortcode mal fermé.

ℹ️

Les skills ne sont pas des scripts — ce sont des instructions que Claude Code interprète. Ça veut dire qu'elles s'adaptent au contexte. La skill /write-blog-article sait que mon blog est en français, que je tutoie le lecteur, et que j'utilise des guillemets français, parce que c'est écrit dans les instructions de la skill.

7. MCP servers — intégration d'outils externes

MCP (Model Context Protocol) permet à Claude Code de se connecter à des serveurs externes qui fournissent des outils supplémentaires. C'est l'équivalent des plugins, mais standardisé.

Les serveurs MCP que j'utilise :

•Gmail — Lire et rédiger des emails directement depuis Claude Code
•Google Calendar — Vérifier mon agenda, créer des événements
•GitHub — Interagir avec les issues et les PRs (au-delà de ce que gh offre)

La configuration est simple — un bloc dans .claude/settings.json :

json

{
  "mcpServers": {
    "gmail": {
      "type": "url",
      "url": "https://mcp.anthropic.com/gmail"
    }
  }
}

⚠️

Les serveurs MCP ont accès à tes données. Utilise uniquement des serveurs de confiance (officiels Anthropic ou open-source audité). Un serveur MCP malveillant pourrait lire tes emails ou modifier ton calendrier. Vérifie toujours les permissions avant de connecter.

8. Background tasks — builds et déploiements longs

Quand tu lances un npm run build qui prend 3 minutes, tu ne veux pas que Claude Code reste bloqué à attendre. Les background tasks permettent de lancer une commande en arrière-plan et d'être notifié quand elle termine.

Mon workflow typique :

1.Je demande « lance le build en background et continue sur les tests »
2.Claude Code lance le build avec run_in_background
3.Pendant ce temps, il travaille sur les tests
4.Quand le build termine, il m'informe du résultat

C'est du parallélisme manuel, plus simple que les agents parallèles mais tout aussi utile. Je l'utilise pour les déploiements Vercel, les exécutions de tests longs, les analyses de code statique.

9. Memory system — persistance cross-session

Le système de mémoire de Claude Code retient des informations entre les sessions. Pas tout — ce serait ingérable — mais les observations clés que l'agent juge utiles pour l'avenir.

La mémoire est stockée dans ~/.claude/projects/<projet>/memory/MEMORY.md. C'est un fichier lisible et modifiable. Tu peux le consulter, le corriger, y ajouter des informations manuellement.

Ce que ma mémoire de projet contient aujourd'hui :

•Les scripts de génération PDF et leurs paramètres
•Les standards KDP que j'applique (marges, polices, interlignes)
•Les bugs corrigés et les workarounds trouvés
•Les résolutions des couvertures et ce qui reste à améliorer
•Les commandes de déploiement du site

💡

Vérifie régulièrement le fichier MEMORY.md. L'agent y écrit ce qu'il juge pertinent, mais son jugement n'est pas parfait. J'ai trouvé des observations obsolètes, des workarounds pour des bugs déjà corrigés, et même des informations incorrectes. Un nettoyage trimestriel suffit.

10. /commit — messages de commit intelligents

La dernière fonctionnalité, la plus simple mais peut-être celle que j'utilise le plus. Quand tu tapes /commit, Claude Code :

1.Analyse le git diff de tous les fichiers modifiés
2.Comprend la nature des changements (bug fix, feature, refactoring)
3.Rédige un message de commit concis et descriptif
4.Crée le commit

Les messages générés sont meilleurs que ceux que j'écrirais moi-même. Pas de « fix stuff » ou « update code ». À la place : « Fix JWT validation skipping expired tokens in auth middleware ». L'agent lit le diff, comprend le pourquoi (pas juste le quoi), et le formule en une phrase.

J'ai arrêté d'écrire mes messages de commit manuellement. Sur les 200 derniers commits de mon site, 95 % ont été rédigés par Claude Code. Et quand je lis l'historique git, je comprends chaque changement sans avoir à relire le code.

✦

Le workflow complet

Ces dix fonctionnalités ne sont pas isolées — elles forment un système cohérent. Voici mon workflow quotidien typique :

1.J'ouvre Claude Code dans mon projet. Le CLAUDE.md est chargé automatiquement, la mémoire de session précédente aussi.
2.Je lance /plan pour la première tâche de la journée.
3.Je valide le plan et lance l'implémentation, souvent avec des agents parallèles pour les sous-tâches indépendantes.
4.Les hooks valident le code au fur et à mesure — pas de commit cassé.
5.Je lance le build en background pendant que je passe à la tâche suivante.
6.Quand tout est prêt, /commit crée un commit propre.
7.En fin de journée, je vérifie que MEMORY.md a bien capturé les décisions importantes.

Ce workflow m'a permis de construire et maintenir un site de 23 sagas (107 pages), un pipeline de génération PDF pour 103 livres, et un blog avec publication automatisée — le tout en solo. Pas parce que je suis un développeur surhumain, mais parce que Claude Code multiplie ma capacité par un facteur que j'estime entre 5 et 10.

Le seul investissement en amont est le temps passé à configurer le CLAUDE.md, les hooks, les skills et les serveurs MCP. Compte une demi-journée pour un projet existant. Après ça, chaque session démarre à pleine vitesse.

Pour comprendre l'architecture sous-jacente — comment Claude Code gère son contexte, distribue ses budgets de tokens et compresse sa mémoire —, j'ai décortiqué le fonctionnement de la boucle Ralph dans un guide dédié.