Guide de vitesse Claude Code | Pourquoi c'est lent et comment je l'ai rendu 3x plus rapide

« Claude Code est-il devenu plus lent ces derniers temps ? »

J’automatise quotidiennement la génération d’articles pour ce site avec Claude Code, et j’ai eu la même frustration durant la première semaine. Ce qui prenait 15 minutes par article est passé à une moyenne de 4 à 5 minutes après avoir ajusté la configuration — soit environ 3 fois plus rapide.

Dans cet article, j’explique les causes fondamentales de la lenteur de Claude Code et les techniques d’optimisation que j’ai réellement testées et trouvées efficaces. Plutôt que seulement « comment le rendre plus rapide », je veux que vous compreniez pourquoi chaque technique fonctionne.

Pourquoi Claude Code devient-il lent ?

Avant d’optimiser, il faut comprendre les causes. Il y a trois raisons principales pour lesquelles Claude Code semble lent.

Cause 1 : Le contexte grossit trop

Claude Code appelle l’API avec tout l’historique de conversation comme contexte. Plus la session est longue, plus les données envoyées à chaque fois sont volumineuses, et plus les réponses sont lentes.

Juste après le démarrage de la session : contexte ~2 000 tokens  → rapide
Après 1 heure :                          contexte ~30 000 tokens → lent
Après une demi-journée :                 contexte ~80 000 tokens → très lent (ou erreurs)

D’après mon expérience, dès que le contexte dépasse 50 000 tokens, la vitesse perçue tombe en dessous de la moitié.

Cause 2 : Trop de fichiers sont lus

Donner des instructions comme « Lis l'intégralité du dépôt et comprends-le avant d'implémenter » pousse Claude Code à tenter de lire un grand nombre de fichiers. Le temps d’attente lorsque des dizaines de commandes Glob et Grep s’exécutent est presque entièrement du « temps passé à lire des fichiers ».

Cause 3 : Charge de traitement du modèle

Opus est puissant, mais la génération de réponses prend plus de temps. De nombreuses tâches utilisent Opus sans en avoir besoin — c’est surdimensionné pour la tâche en question.

---

Solution 1 : Faire de /compact une habitude

La solution avec l’effet le plus immédiat. Claude Code dispose d’une commande /compact qui compresse et résume l’historique de conversation, réduisant considérablement la taille du contexte.

# À exécuter dans le REPL Claude Code
/compact

J’ai pris l’habitude d’exécuter /compact une fois par heure ou à chaque pause naturelle dans le travail. Rien que cela améliore la vitesse perçue de 1,5 à 2 fois.

Commencer les nouvelles tâches dans une nouvelle session

Pour les nouvelles tâches qui n’ont pas besoin du contexte du travail précédent, redémarrer Claude Code et commencer une nouvelle session est plus rapide. Le redémarrage prend moins de 5 secondes.

# Quitter et redémarrer
exit
claude

Quand vous souhaitez quand même faire référence à un travail antérieur, coller uniquement les informations pertinentes après /init est plus rapide et plus précis que de traîner un long historique de conversation.

---

Solution 2 : Limiter explicitement la portée des instructions

Réduire les lectures de fichiers inutiles conduit à des gains de vitesse significatifs.

Comparaison Before / After

# ❌ Lent : portée trop large
claude -p "Corrige le bug dans ce projet"
# → Glob → Read × des dizaines de fois → prend une éternité

# ✅ Rapide : portée limitée
claude -p "Corrige la vérification null manquante à la ligne 108 de src/api/auth.ts"
# → Read 1 fois → correction terminée

Un modèle que j’utilise souvent :

# Lui faire lire uniquement des fichiers spécifiques
claude -p "Lis seulement les fichiers suivants et corrige le problème. Tu n'as pas besoin de lire autre chose :
- src/components/Button.tsx
- src/styles/button.css
Problème : les styles au survol ne s'appliquent pas"

Ajouter « tu n’as pas besoin de lire autre chose » stoppe le comportement d’exploration inutile.

---

Solution 3 : Utiliser le bon modèle pour chaque tâche

Utiliser Opus pour chaque tâche est un gaspillage en termes de vitesse.

Opus :   Conception complexe · débogage difficile · revue de code
Sonnet : Implémentation générale · refactoring · documentation
Haiku :  Traduction · formatage · transformations simples

Changer de modèle dans Claude Code

# Changer de modèle en cours de session
/model claude-sonnet-4-6

# Note de vitesse : Sonnet est environ 2 à 3 fois plus rapide qu'Opus en pratique

Pour les opérations de mon site :

• Corps d’article en japonais → Sonnet (qualité de structure suffisante, plus rapide qu’Opus)
• Traduction multilingue → Haiku (qualité de traduction parfaitement utilisable, dramatiquement plus rapide)
• Discussions de conception · implémentation complexe → Opus (qualité en priorité ici seulement)

Cette répartition a fait passer le temps de génération par article de 15 minutes à 4 minutes.

---

Solution 4 : Exécution parallèle avec des sous-agents

Paralléliser les traitements lourds peut réduire considérablement le temps total.

Traduction parallèle (la méthode que j’utilise réellement)

// ❌ Traduction séquentielle : 9 langues × 30 secondes = 270 secondes (4,5 min.)
for (const lang of languages) {
  await translate(article, lang);
}

// ✅ Délégation parallèle avec Agent tool : temps = langue la plus lente ≈ 30 secondes
// (Ce site est passé de 8 min. à 1,5 min. en déléguant en bloc aux sous-agents)
Agent({
  prompt: `Traduis ${article} en 9 langues et sauvegarde chaque fichier : EN/DE/ES/FR/HI/ID/KO/PT/ZH`
})

Les sous-agents s’exécutent dans leur propre contexte indépendant, donc ils ne polluent pas le contexte principal. Cela contribue aussi à l’amélioration de la vitesse.

---

Solution 5 : Accélérer la saisie avec le cache de prompts

Quand vous réutilisez le même system prompt de façon répétée, le cache de prompts rend le traitement des entrées environ 10 fois plus rapide. Cela a un effet notable sur la vitesse perçue.

// Ajoutez simplement cache_control
system: [
  {
    type: "text",
    text: longSystemPrompt,
    cache_control: { type: "ephemeral" },
  },
],

Quand vous réutilisez le même system prompt dans les 5 minutes, le deuxième appel et les suivants sont notablement plus rapides que le premier.

---

Solution 6 : Réduire les explorations inutiles avec CLAUDE.md

Écrire les « commandes à utiliser », la « structure des répertoires » et les règles « ne pas lire » dans CLAUDE.md permet à Claude Code d’agir directement sans errer.

# Règles du projet

## Commandes fréquemment utilisées (pas besoin de les chercher à chaque fois)
- Build : npm run build
- Test : npm run test
- Deploy : bash scripts/deploy.sh

## Structure des répertoires
- src/components/ : composants UI
- src/pages/ : routage
- src/content/blog/ : articles de blog (MDX)

## Important : NE PAS lire ces répertoires
- node_modules/
- .wrangler/
- site/dist/

Cela réduit le nombre de tours que Claude Code passe à chercher « où dois-je regarder ? », ce qui accélère l’ensemble du processus.

---

Chiffres réels d’amélioration de la vitesse (ce site)

Pour référence, voici les résultats réels de ce site (claudecode-lab.com).

Tâche	Avant optimisation	Après optimisation	Réduction
Génération d’article (japonais)	8 min.	2,5 min.	69% plus rapide
Traduction en 9 langues	7 min.	1,5 min.	79% plus rapide
Build + deploy	13 min.	11 min.	15% plus rapide
Total (par article)	28 min.	15 min.	46% plus rapide

En appliquant rigoureusement /compact et la gestion de session, le site tourne maintenant de façon stable à 10–12 minutes par article.

---

Liste de contrôle d’optimisation de vitesse

Dans l’ordre de ce qu’il faut vérifier en premier.

À faire maintenant (moins d'1 minute) :
□ Exécuter /compact pour compresser le contexte
□ Redémarrer une session qui tourne depuis longtemps
□ Basculer les tâches de traduction/formatage vers Haiku

À faire aujourd'hui (30 minutes) :
□ Ajouter les « répertoires à ne pas lire » dans CLAUDE.md
□ Ajouter les commandes fréquemment utilisées dans CLAUDE.md
□ Prendre l'habitude de découper les grandes tâches en « petites tâches à portée limitée »

À faire cette semaine :
□ Ajouter cache_control aux processus batch répétés
□ Créer des modèles pour déléguer les tâches parallélisables à Agent tool
□ Définir les règles d'utilisation des modèles et les ajouter à CLAUDE.md

---

Résumé

Les causes fondamentales de la lenteur de Claude Code sont « le gonflement du contexte » et « l’exploration inefficace des fichiers ». Être simplement conscient de ces deux points fait une grande différence dans la vitesse perçue.

Ma liste priorisée des améliorations les plus impactantes :

1. Faire de /compact une habitude (effet immédiat, coût zéro)
2. Utiliser le bon modèle pour chaque tâche (passer la traduction à Haiku seul est dramatique)
3. Limiter explicitement la portée des instructions (simplement ajouter « tu n’as pas besoin de lire autre chose »)
4. Délégation parallèle aux sous-agents

Tout n’a pas besoin d’être fait d’un coup. Simplement intégrer /compact dans le travail d’aujourd’hui devrait déjà sembler notablement plus rapide.

Articles connexes

• Guide complet pour réduire les coûts API de Claude Code de 90%
• Guide complet du Harness Engineering
• 10 modèles de prompts dangereux dans Claude Code