Claude Code : comment optimiser son workflow de développement

Quand tu commences à utiliser Claude Code, tu tapes des messages et Claude répond. Ca marche. Mais Claude ne connait pas ton projet, tes conventions, tes outils. Il repart de zéro à chaque session. La bonne nouvelle : il y a tout un système de customisation pour changer ça. Une fois en place, Claude arrête de faire du tourisme dans ton projet et devient un vrai outil de travail.

Il y a 6 blocs de configuration à connaitre. Ils vont du plus simple (un fichier texte) au plus avancé (des agents qui travaillent en parallèle). Tu n’as pas besoin de tous les utiliser tout de suite : commence par les premiers, ajoute les suivants quand tu en ressens le besoin.

La carte du territoire

flowchart TB
    CM["CLAUDE.md<br>Mémoire permanente"] --> WHEN
    SK["Skills<br>Slash commands & expertise auto"] --> WHEN
    HK["Hooks<br>Automatisation"] --> WHEN
    MCP["MCP Servers<br>Outils externes"] --> WHEN
    SA["Sub-Agents<br>Travail en parallèle"] --> WHEN
    WHEN["Quelle approche<br>pour quelle tâche ?"]

On va les voir dans cet ordre, du plus accessible au plus puissant.

Comprendre le contexte

Avant de rentrer dans le détail, un concept fondamental à saisir : le contexte.

Claude Code ne “pense” pas en continu. À chaque échange, il reçoit l’intégralité de la conversation depuis le début, sous forme de texte. Ce texte s’appelle le contexte, et il est mesuré en tokens (des morceaux de mots, environ 4 caractères chacun). Plus le contexte est long, plus chaque requête est coûteuse en tokens et en temps de traitement.

Sur une session longue, ce contexte grossit vite. Chaque fichier lu, chaque résultat d’outil, chaque message s’accumule. Au-delà d’un certain point, Claude commence à perdre le fil des informations les plus anciennes, ralentit, et fait des erreurs.

C’est pourquoi bien configurer Claude Code, c’est aussi apprendre à garder le contexte propre. Un bon CLAUDE.md évite de répéter les mêmes informations à chaque session. Des skills bien rédigés réduisent les échanges de clarification. Et les sub-agents isolent les tâches lourdes dans leur propre contexte pour ne pas polluer la conversation principale.

Le dossier .claude/

Avant de rentrer dans le détail de chaque bloc, il faut connaitre l’endroit où tout ça vit : le dossier .claude/.

mon-projet/
├── .claude/
│   ├── skills/         ← tes slash commands et skills
│   ├── agents/         ← tes sub-agents
│   └── settings.json   ← permissions et hooks
└── .mcp.json           ← serveurs MCP du projet (racine)

Ce dossier peut exister à deux niveaux, et c’est important :

• Dans ton projet (monprojet/.claude/) : la config n’est disponible que pour ce projet
• Dans ton home (~/.claude/) : la config est disponible dans tous tes projets

En pratique, tu mettras dans ~/.claude/ les choses universelles (ta préférence pour le français, ton agent de code review générique) et dans .claude/ du projet les choses spécifiques (les conventions du projet, l’agent qui connait ta base de données).

CLAUDE.md - La mémoire du projet

C’est le point de départ, et de loin le plus simple à mettre en place. CLAUDE.md est un fichier texte que Claude lit automatiquement à chaque session. C’est sa mémoire sur ton projet.

Sans lui, Claude ne sait pas que tu utilises du JS vanilla, que le dossier src/ contient les composants, ou que les commits doivent être en français. Tu dois le répéter à chaque session. Avec lui, tu ne le dis qu’une fois.

Ce qu’il doit contenir :

# Mon Site

## Stack
- HTML / CSS / JavaScript vanilla · pas de framework
- npm pour les scripts

## Architecture
src/ → composants et modules JS
public/ → fichiers générés, ne pas modifier directement

## Commandes
- `npm run dev` → serveur local avec hot reload
- `npm run lint` → vérification du code

## Conventions
- Commits en français
- Toujours lancer `npm run lint` avant de committer

Pense à CLAUDE.md comme un brief d’agence : concis, actionnable, et centré sur ce qui change réellement le comportement.

Skills - Workflows personnalisés et slash commands

Dans Claude Code, les skills sont le système unique pour créer tes propres workflows. Si tu as croisé le terme “slash commands” ailleurs, c’est la même chose : les custom slash commands ont été fusionnés dans les skills, et c’est désormais le seul système recommandé.

Un skill, c’est un dossier dans .claude/skills/ :

.claude/skills/
└── review/
    ├── SKILL.md        ← instructions et prompt
    ├── examples/       ← fichiers d'accompagnement optionnels
    └── scripts/
        └── helper.py   ← script dont seul l'output entre dans le contexte

Le fichier SKILL.md commence par un frontmatter qui définit son comportement :

---
name: review
description: >
  Analyse un fichier pour la qualité, la sécurité et les performances.
  Use when asked to review or audit code.
---

Tu es un expert en code review. Analyse le fichier $ARGUMENTS en vérifiant :

- Sécurité (injections, XSS, CSRF)
- Performance (requêtes N+1, index manquants)
- Lisibilité et conventions du projet

Retourne un rapport structuré avec priorités.

Ce skill peut être déclenché de deux façons :

Manuellement, en tapant /review src/components/header.js dans le terminal. La variable $ARGUMENTS récupère ce qui suit la commande. Tu peux cibler des arguments précis avec $1, $2, etc.

Automatiquement, quand Claude juge que le contexte correspond à la description du skill. Si tu lui demandes “peux-tu auditer ce fichier ?”, il va charger le skill review tout seul, sans que tu tapes la commande.

C’est la vraie différence avec un simple prompt : un skill avec une bonne description devient un outil que Claude utilise de sa propre initiative. L’intérêt des scripts dans un skill est aussi notable : ils sont exécutés, pas lus. Si tu as un script Python qui vérifie l’état du serveur, seul son output entre dans le contexte, pas ses 200 lignes de code.

Hooks - L’automatisation en arrière-plan

Un hook, c’est une commande shell qui se lance automatiquement quand Claude utilise un outil. Tu définis “après chaque écriture de fichier, lance le linter” : ça arrive à chaque fois, sans que tu aies à y penser.

Il y a quatre moments où tu peux brancher des hooks :

La configuration se fait dans settings.json :

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": ".claude/hooks/lint.sh"
          }
        ]
      }
    ]
  }
}

Le hook reçoit les informations sur l’événement via stdin, au format JSON. Pour récupérer le fichier modifié dans le script, on utilise jq :

#!/bin/bash
file=$(jq -r '.tool_input.file_path' < /dev/stdin)
npm run lint -- "$file"

Ici, chaque fois que Claude écrit ou modifie un fichier, le linter tourne automatiquement. Si le linter remonte une erreur, Claude la voit et peut la corriger immédiatement.

D’autres usages courants : formater le code avec Prettier après chaque modification, lancer les tests unitaires sur les fichiers touchés, afficher une notification desktop quand une longue tâche se termine, ou loguer les actions de Claude pour les auditer plus tard. La variable $CLAUDE_PROJECT_DIR est disponible dans les scripts pour connaitre la racine du projet.

MCP Servers - Brancher des outils externes

Par défaut, Claude Code peut lire et écrire des fichiers, exécuter des commandes bash, et faire des recherches. C’est déjà pas mal. Mais si tu veux qu’il puisse aussi interroger ta base de données, créer des issues GitHub, ou scraper une page web, il faut lui brancher un serveur MCP.

MCP (Model Context Protocol) est le protocole standard pour étendre les capacités de Claude avec des outils tiers. Il existe des serveurs pour à peu près tout :

• Bases de données : Postgres, MySQL, SQLite
• Outils de dev : GitHub, Linear, Jira
• Automatisation web : Playwright, Puppeteer
• Cloud : AWS, Vercel, Cloudflare
• Recherche : Brave Search, Tavily

La configuration se fait dans un fichier .mcp.json à la racine du projet (ou dans ~/.claude.json pour une dispo globale) :

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_TOKEN": "ton-token"
      }
    },
    "postgres": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-postgres",
        "postgresql://localhost/mydb"
      ]
    }
  }
}

Une fois configuré, Claude peut directement faire SELECT * FROM users ou créer une pull request sans que tu aies à copier-coller quoi que ce soit.

Le scope local/global s’applique ici aussi : un serveur MCP déclaré dans .mcp.json du projet n’est disponible que pour ce projet. Pratique pour les bases de données dont l’URL change entre les environnements.

Sub-Agents - Travailler en parallèle

C’est le bloc le plus avancé, et aussi le plus puissant. Un sub-agent est une instance séparée de Claude qui travaille de son côté, dans sa propre fenêtre de contexte, et te retourne uniquement son résultat final.

Comme vu plus haut, le contexte se remplit à mesure qu’une session avance. Les sub-agents règlent ce problème en isolant chaque tâche : l’agent fait son travail, retourne le résultat, et son contexte disparaît. La conversation principale ne garde que la synthèse.

À noter : les sub-agents ne réduisent pas ta consommation de requêtes. Chaque agent est une instance Claude à part entière qui fait ses propres appels. Ils règlent la qualité des réponses sur les sessions longues, pas les limites de quota.

Le parallélisme

L’autre avantage : plusieurs agents peuvent tourner simultanément sur des tâches indépendantes. Au lieu d’auditer tes 3 pages l’une après l’autre dans la même conversation, tu lances 3 agents en parallèle.

flowchart TD
    T["Auditer le site complet"] --> A & B & C
    A["Agent A<br>Page accueil"] --> S
    B["Agent B<br>Page contact"] --> S
    C["Agent C<br>Page portfolio"] --> S
    S["Synthèse dans<br>la conversation principale"]

Un agent se configure avec un fichier .md dans .claude/agents/ :

---
name: code-reviewer
description: >
  Reviews code for quality, security, and best practices.
  Use when asked to review, audit, or check code quality.
tools:
  - read_file
  - bash
model: claude-sonnet-4-5
memory: user
---

Tu es un expert en code review.
Focus sur : sécurité, performance, lisibilité.
Note les patterns récurrents que tu observes dans ta mémoire.

Le paramètre memory: user mérite une explication. Avec cette option, l’agent maintient son propre fichier MEMORY.md qui persiste entre les sessions. Il peut noter les patterns qu’il observe, les conventions du projet, les erreurs récurrentes, et s’en souvenir la prochaine fois qu’il est invoqué. C’est un agent qui s’améliore avec le temps.

Pour l’invoquer, tu mentionnes simplement son nom dans la conversation :

@code-reviewer regarde src/components/header.js

Ou il peut être appelé depuis un skill, ou déclenché par Claude lui-même quand il juge qu’une tâche mérite d’être isolée.

Quand utiliser quoi

Par où commencer

Si tu pars de zéro, le bon ordre c’est : un CLAUDE.md solide pour chaque projet, puis deux ou trois skills pour tes tâches les plus répétitives. C’est déjà 80% du gain, et ça prend une heure à mettre en place.

Les Hooks et MCP servers viennent naturellement quand tu identifies une friction spécifique : “je dois toujours penser à lancer le linter” ou “je dois toujours copier-coller des données depuis un outil externe”. Les Sub-Agents et Skills, c’est pour quand tu as des workflows suffisamment stables pour mériter d’être automatisés.

Ces blocs se combinent bien. Sur notre site exemple, ça donnerait :

CLAUDE.md              → stack, conventions et commandes toujours présentes
/review                → skill pour auditer un composant JS
npm run lint (hook)    → tourne automatiquement après chaque modification
@code-reviewer         → audit des 3 pages principales en parallèle

Chaque bloc a sa place. L’important c’est de les introduire progressivement, pas de tout configurer d’un coup.

Sources et références :

• Documentation Claude Code
• MCP Servers - dépôt officiel