Claude Code CLI : 7 astuces et automatisation en pratique

La fenêtre du terminal affiche le 18e échec de tests. Si j’avais connu /clear plus tôt, je ne serais pas resté bloqué aussi tard.

Les données officielles montrent que Claude Code résout de façon autonome 80,9 % des problèmes de code sur SWE-bench. La vraie question : exploitez-vous vraiment ses capacités centrales ? La plupart des gens lancent Claude Code, tapent claude, échangent quelques messages, modifient du code, et s’arrêtent là. Sur plus de 50 commandes, ils n’en utilisent que 3 à 5 — laissant 90 % du potentiel d’efficacité de côté.

Cet article partage 7 astuces CLI et 3 cas d’automatisation en pratique, avec une approche systématique par scénario — des commandes de base à la gestion du contexte, puis aux Hooks et à l’intégration CI/CD. À la fin, vous passerez de « je sais m’en servir » à « je l’utilise vraiment efficacement ».

Chapitre 1 : Les trois bases du CLI — lancement, modes, commandes

Posez d’abord les fondations ; les techniques avancées viendront ensuite.

1.1 Trois modes de lancement, chacun avec son usage

claude              # Lance l'interface interactive dans le répertoire courant
claude -c           # Reprend la dernière session
claude --print "Vérifier la définition de type de cette fonction"  # Requête unique puis sortie

Beaucoup ne connaissent que le premier. Pourtant -c est très pratique : vous fermez une session, un détail vous revient en tête, et claude -c reprend exactement le contexte — sans tout réexpliquer.

J’utilise --print pour des requêtes rapides. Vérifier une définition de type ? Une commande suffit, sans entrer en mode interactif complet. Gain de temps net.

1.2 Trois modes de travail, à adapter au contexte

Concept central de la doc officielle, aussi détaillé dans l’article de profondeur d’Alibaba Cloud :

En mode Default, chaque modification de fichier ou commande demande une confirmation. Fastidieux, mais sûr — idéal pour prendre la mesure d’un projet inconnu.

En Auto-Accept, les modifications de fichiers s’exécutent automatiquement ; les commandes shell restent à confirmer. Sur votre propre projet, pour une refonte en lot, Claude enchaîne les changements et vous validez à la fin. L’efficacité double.

J’aime Plan pour les problèmes complexes : Claude lit tout le projet, produit un plan d’exécution détaillé, sans rien modifier. Le plan vous convient ? Passez en Auto-Accept pour l’exécuter.

1.3 Trois commandes slash à retenir

Sur les 50+ commandes officielles, la plupart n’en utilisent pas 10. Voici les trois que j’emploie le plus :

/init     # Scanne le projet et génère CLAUDE.md
/clear    # Vide l'historique de session
/compact  # Compresse le contexte pour économiser des tokens

/init au premier lancement sur un nouveau projet. Claude scanne le dépôt, génère un fichier de config (structure, dépendances, conventions) que toutes les opérations suivantes réutiliseront.

/clear — j’y reviens plus loin : c’est mon plus gros gain d’efficacité.

/compact quand l’historique s’allonge. Claude conserve l’essentiel (fichiers modifiés, décisions clés) et supprime le superflu. Utile après de nombreux allers-retours sur une même tâche.

Chapitre 2 : L’art de la gestion du contexte — vider, compresser, paralléliser

L’article pratique de Builder.io m’a ouvert les yeux : /clear serait « le plus gros levier de productivité ». Une semaine d’essai plus tard, je confirme.

2.1 Utiliser /clear correctement

Quand vider la session ?

Railway - Plateforme de déploiement moderne, sans opérations complexes, en ligne en quelques minutes

Commencer →Pub

À chaque changement de tâche.

Vous venez de corriger un bug en vingt échanges avec Claude, le problème est localisé. Votre chef vous envoie sur un issue urgent. Beaucoup continuent dans la même session en changeant de sujet.

Erreur.

Faites d’abord /clear pour effacer l’historique. Pourquoi ? Ces échanges consomment des tokens et n’ont aucun rapport avec la nouvelle tâche. Claude est « pollué » par l’ancien contexte ; la qualité de compréhension baisse.

Mon habitude : changement de tâche → /clear → bref contexte sur la nouvelle demande. Bien meilleur qu’enchaîner dans la même session.

2.2 Quand utiliser /compact

Même tâche, nombreuses modifications — une dizaine de fichiers, plus de trente messages — le contexte devient lourd.

/compact compresse l’historique : fichiers modifiés et décisions clés restent, le reste part.

Mon repère approximatif : au-delà de 30 messages, je compacte. Pas besoin d’être précis ; dès que ça « semble long », je compresse.

2.3 Stratégie de sessions parallèles

Astuce du Help Center officiel de Claude : lancer 3 à 5 sessions en parallèle, chacune dans un git worktree distinct sur une partie différente du dépôt.

Git worktree, en bref : plusieurs répertoires de travail pour un même repo, chacun sur une branche différente.

# Créer des worktrees
git worktree add ../feature-A feature-branch-A
git worktree add ../feature-B feature-branch-B

# Lancer Claude dans chaque worktree
cd ../feature-A && claude
cd ../feature-B && claude

Deux terminaux, deux tâches : Claude code la feature A dans l’un, traite la feature B dans l’autre. Contextes totalement indépendants.

Astuce terminal : Ctrl+B envoie une commande bash longue en arrière-plan. Pratique quand Claude lance npm install ou des tests interminables — l’interface de session ne reste pas bloquée.

Chapitre 3 : Les trois piliers de l’automatisation — Hooks, Routines, CI/CD

Jusqu’ici, tout était manuel. Ici, on automatise — Claude fait le travail répétitif pendant que vous avancez.

3.1 Les Hooks : déclencheurs de tâches

Les Hooks sont le cœur de l’automatisation Claude Code. Trois types principaux :

Le plus utile : PostToolUse. Configurez un hook pour lancer les tests après chaque modification de code.

// Exemple dans settings.json
{
  "hooks": {
    "PostToolUse": [{
      "command": "npm test",
      "timeout": 60000
    }]
  }
}

Effet : après chaque utilisation de l’outil Write, npm test s’exécute. En cas d’échec, Claude voit la sortie et corrige.

3.2 Routines : définir des flux répétitifs

Les Routines conviennent aux processus qui reviennent souvent.

Exemple officiel : quand Claude détecte une condition (par ex. un fichier présent), une série de commandes prédéfinies s’exécute automatiquement.

La configuration est un peu complexe ; je ne les déploie pas encore à grande échelle en production. Mais la direction est claire : figer les vérifications récurrentes sans rappeler Claude à chaque fois.

3.3 Intégration CI/CD : GitHub Actions en pratique

Mode headless officiel : claude -p.

Dans GitHub Actions, Claude peut traiter automatiquement la revue de PR, l’implémentation d’issues ou l’audit de sécurité.

# .github/workflows/claude-review.yml
name: Claude Code Review
on: [pull_request]

jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run Claude Review
        run: claude -p "Review this PR and suggest improvements"
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}

Le blog officiel GitLab décrit trois flux :

Alibaba Cloud - Choix n°1 des développeurs, 15 % de réduction exclusive sur Lighthouse

Obtenir -15 % →Pub

1. Créer une MR à partir d’un issue
2. Analyser une régression de performance
3. Implémenter une fonctionnalité et laisser le CI valider

Je creuse encore, mais le potentiel est évident : intégrer Claude Code au flux de développement complet, comme composant du pipeline CI/CD.

Chapitre 4 : Cas pratiques — de la configuration à l’automatisation

Assez de théorie ; voyons l’usage concret.

Cas 1 : Un commit git en une phrase

Mon scénario le plus fréquent.

Méthode classique : git add, git status, rédiger le message, git commit. Plusieurs minutes.

Avec Claude Code :

claude
> commit these changes

Une phrase. Claude lit vos modifications, génère un message de commit adapté et commit. Il analyse le diff, comprend l’intention du changement, rédige un message pertinent.

En pratique, la qualité dépasse souvent la mienne — parce qu’il lit vraiment le diff, au lieu d’écrire au hasard.

Cas 2 : Hook PostToolUse pour lancer les tests automatiquement

Version complète de la config hook :

// .claude/settings.json
{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write",
        "command": "npm run test:related",
        "timeout": 30000
      }
    ]
  }
}

matcher: "Write" ne surveille que l’outil Write (modification de fichiers). npm run test:related est ma commande custom : uniquement les tests liés aux fichiers modifiés — pas la suite complète, donc bien plus rapide.

Effet : résultats des tests en moins de 30 secondes après chaque modification. En cas d’échec, Claude reçoit la sortie et corrige.

Piège que j’ai connu : npm test en suite complète, trop lent, timeouts fréquents. Tests ciblés : problème réglé.

Cas 3 : Revue automatique de PR via GitHub Actions

Configuration tirée de la doc officielle :

# .github/workflows/claude-pr-review.yml
name: Claude PR Review

on:
  pull_request:
    types: [opened, synchronize]

jobs:
  claude-review:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write
    steps:
      - name: Checkout PR
        uses: actions/checkout@v4
        with:
          ref: ${{ github.event.pull_request.head.ref }}

      - name: Claude Review
        uses: anthropics/claude-code-action@v1
        with:
          prompt: |
            Review this PR for:
            - Code quality issues
            - Potential bugs
            - Security vulnerabilities
            - Performance concerns
          api_key: ${{ secrets.ANTHROPIC_API_KEY }}

Ce workflow se déclenche à la création ou la mise à jour d’une PR. Claude review le code et commente sur la PR : qualité, bugs potentiels, sécurité, performance.

Un mois d’usage : il attrape plus de bugs que ma revue manuelle — parce qu’il ne « zappe » aucun fichier.

Chapitre 5 : Multiplier la productivité — config minimaliste et intégration toolchain

Dernières astuces tirées des articles Marmelab et Builder.io — pour fluidifier l’ensemble du flux.

5.1 La philosophie du CLAUDE.md court

Beaucoup rédigent un CLAUDE.md exhaustif : contexte projet, stack, style de code, interdictions… des milliers de mots.

Marmelab dit l’inverse : gardez CLAUDE.md aussi court que possible.

Pourquoi ? Plus la config est longue, plus Claude « sur-applique » les règules à chaque action, limitant la flexibilité. Et la config elle-même consomme des tokens.

Leur recommandation : 3 à 5 conventions essentielles, la config comme « fonction de réduction du dépôt ». Par exemple :

# CLAUDE.md
- TypeScript strict, typage explicite pour toutes les variables
- Composants dans src/components/
- Tests à côté des fichiers sources
- Pas de var, uniquement const et let

Quelques lignes. Suffisant.

5.2 Stratégie Bash Wrapper

Builder.io : plutôt qu’un long document, écrivez un script bash wrapper.

KiloClaw - OpenClaw managé pour l’entreprise : orchestration d’agents IA et routage intelligent

Commencer →Pub

Pour démarrer le projet, au lieu d’un README détaillé (« npm install, puis variables d’environnement, puis dev server »), un script :

#!/bin/bash
# dev.sh - Démarrage rapide de l'environnement de dev

npm install
source .env.local
npm run dev

Dans Claude Code : « run dev.sh ». Simple, sans réfléchir.

Même logique pour Claude : encapsulez les combinaisons de commandes fréquentes en alias ou scripts. Fini de retaper de longues lignes.

5.3 Intégration MCP Server : contrôle de sécurité et filtrage de sortie

Enfin, l’intégration d’outils autour du MCP (Model Context Protocol).

Deux exemples concrets :

Snyk MCP Server : pendant l’écriture de code, Claude vérifie automatiquement vulnérabilités et dépendances. À chaque nouvelle dépendance, scan de sécurité sans rappel manuel.

Outil rtk : filtre et compresse la sortie des commandes. Astuce GitHub dédiée — beaucoup de CLI produisent des logs énormes (npm install, etc.) qui consomment des tokens. rtk ne garde que l’essentiel.

Pas encore totalement intégrés chez moi, mais la direction est nette : Claude Code ne se limite pas à écrire du code, il se branche sur toute la chaîne sécurité et gestion des dépendances.

Conclusion

L’essentiel en quelques points :

Maîtrisez les commandes de base — trois modes de lancement, trois modes de travail, adaptés au contexte. Ne restez pas sur le plus simple.

Ne négligez pas le contexte — /clear à chaque changement de tâche, /compact quand la conversation s’allonge. Ces deux habitudes économisent énormément de tokens.

Investissez dans l’automatisation — Hooks, intégration GitHub Actions : un peu de temps au départ, un gain multiplié ensuite.

Restez minimaliste — CLAUDE.md court, processus complexes en scripts. Plus long n’est pas mieux.

Mes recommandations :

1. Aujourd’hui : tapez /clear dans votre session actuelle et sentez la différence
2. Cette semaine : configurez un hook PostToolUse pour lancer les tests après chaque modification
3. Objectif long terme : intégrez Claude Code à votre CI/CD comme outil standard de l’équipe

Pour approfondir la configuration Claude Code, consultez le premier article de la série « Arrêtez de laisser Claude écrire n’importe comment ! Un fichier de config pour +10 % de précision » (comment rédiger CLAUDE.md). Pour les Subagents, le deuxième : « Réponses trop verbeuses ? Construisez votre équipe IA avec les Subagents ». Celui-ci est le septième de la série, centré sur les astuces CLI.

J’ai appris ces astuces en trébuchant. J’espère que vous éviterez quelques pièges et gagnerez en efficacité plus tôt.