Optimiser Claude Code : tenir toute la journée avec l’abonnement pro

Voilà le truc : la plupart des devs utilisent Claude Code comme un simple chatbot. Ils balancent des prompts, ça répond, et boom – au bout de 2h (et je suis gentil), c’est fini. Message de limite atteinte.

Et là, tout le monde se dit la même chose :

« Sérieux ? J’ai à peine codé trois trucs. »

Spoiler : le problème, c’est pas le nombre de messages. => C’est les tokens. Et surtout, c’est ta façon de bosser.

Parce qu’entre quelqu’un qui utilise Claude « normalement » et quelqu’un qui a optimisé son workflow Claude code, l’écart est dingue. Même abonnement, mais l’un est bloqué après un temps beaucoup trop rapide, l’autre développe tranquille sans stress.

Je vais te montrer comment je m’y prends pour optimiser Claude Code :

• Gestion du contexte
• Organisation des agents
• Choix des modèles
• Le fichier claude.md
• La stratégie /clear
• Optimisation des recherches
• Réduction du bruit

L’objectif ? Pas juste « économiser des tokens ». Non, le vrai but c’est de tenir le plus longtemps possible sans être bloqué.

Le vrai problème : le contexte qui enfle

On croit que chaque message est indépendant. Faux.

À chaque fois que tu envoies un prompt, Claude re-digère :

• Ton message actuel
• Tout l’historique de la conversation
• Les instructions système
• Les MCP actifs
• Le contenu du claude.md
• Les outils, skills et agents qui ajoutent leur propre contexte

Tout ça bouffe des tokens.

Et le pire ? Ça grossit au fil de la conversation.

Tu commences à 5K tokens et rapidement t’es à 100K sans t’en rendre compte. Et là, tes limites explosent.

Erreur n°1 : garder la même conversation pendant des jours

C’est l’erreur classique.

Tu démarres une session lundi matin. Tu reviens l’après-midi. Puis mardi. Puis mercredi.

Pratique pour garder l’historique, mais catastrophique côté perfs.

Pourquoi ?

Parce que Claude doit se retaper tout le contexte à chaque message.

Plus la conversation est longue :

• Plus chaque réponse coûte cher
• Plus les perfs se dégradent
• Plus le raisonnement devient flou
• Plus tu atteins rapidement les limites

La commande /clear est ton meilleur ami

Fonctionnalité terminée ? Prends cette habitude :

/clear

Ça vide le contexte. Point.

Quand tu redémarres une nouvelle tâche :

• Claude recharge le claude.md
• Tu repars avec un contexte propre
• Tu évites de renvoyer 60K, 80K ou 120K tokens pour rien

C’est probablement l’optimisation la plus rentable selon moi.

Le claude.md : essentiel mais dangereux

Ce fichier, c’est la base. Il permet à Claude de capter rapidement :

• Structure du projet
• Technos utilisées
• Conventions de code
• Endpoints importants
• Règles de dev
• Architecture globale

Mais attention au piège.

Beaucoup de gens transforment leur claude.md en encyclopédie de 50 pages. Et là, c’est contre-productif.

Pourquoi ?

Parce que ce fichier est relu régulièrement.

Plus il est gros :

• Plus il coûte cher
• Plus il pollue le contexte
• Plus il ralentit tout

Le claude.md, c’est pas une doc exhaustive. C’est un aide-mémoire stratégique.

MCP et tools : stop au chargement « au cas où »

Au démarrage de Claude Code, tu peux charger automatiquement :

• MCP
• Outils
• Skills
• Commandes
• Agents

Le souci ? Beaucoup activent tout par défaut « on sait jamais ».

Résultat : avant même ton premier prompt, t’es déjà surchargé.

Ma règle :

• Désactive tout par défaut
• Active uniquement ce dont t’as besoin
• Garde les outils spécifiques au niveau projet

L’objectif : réduire le bruit au maximum.

Tous les modèles ne se valent pas pour toutes les tâches

Beaucoup d’utilisateur utilisent le model le plus puissant pour tout.

C’est comme prendre une Ferrari pour aller chercher le pain.

Oui, ça marche. Mais le coût explose.

Comment je répartis les models

Haiku

Pour :

• Recherches simples
• Renommages
• Tâches rapides
• Opérations légères

Le but : les tâches « jetables » avec le modèle le moins cher.

Il est très bon pour les tâches ci-dessus donc autant utiliser un model bon dans le domaine et en plus c’est le moins couteux en token. C’est validé 3000%

Sonnet 4.6

Mon model principal.

Pour :

• Développer
• Modifier du code
• Implémenter des fonctionnalités
• Corriger des bugs
• Concevoir l’appli

Le meilleur équilibre :

• Performance
• Vitesse
• Coût

Opus 4.7

Beaucoup plus rare.

Pour :

• Réfléchir à l’architecture
• Concevoir des specs
• Analyser une appli complexe
• Faire des choix techniques importants
• Auditer un projet

En pratique, Sonnet + Haiku = 90% du boulot.

Opus, c’est uniquement quand j’ai besoin d’une réflexion profonde.

Les sous-agents : le vrai game changer

Le changement majeur dans mon workflow ? J’ai arrêté de faire tout faire à l’agent principal.

Parce qu’un agent qui :

• Développe
• Recherche
• Analyse
• Lit des fichiers
• Explore l’archi
• Corrige des bugs

… finit par avoir un contexte monstrueux.

Et là, la consommation explose.

Le principe : déléguer les tâches secondaires

Mon agent principal garde uniquement :

• Le contexte métier
• L’objectif actuel
• Les éléments importants du projet

Tout le reste est délégué.

Par exemple :

• Un agent recherche explore le code
• Un agent léger analyse des fichiers
• Un agent Haiku prépare certaines infos
• Le main agent récupère uniquement la synthèse utile

Résultat : le contexte principal grossit beaucoup moins vite.

Exemple concret de workflow

Context 0/200K - MAIN

Agent Recherche => 33K tokens (53s)
Agent Plan => 9K tokens (19s)

MAIN => 28K/200K

Dans ce fonctionnement :

• Les agents secondaires bossent séparément
• Ils filtrent l’info
• Le main agent ne récupère que l’essentiel

Si le main agent faisait tout lui-même :

• Il analyserait tous les fichiers
• Stockerait toutes les recherches
• Conserverait tous les raisonnements

Et le contexte exploserait.

Attention : les sous-agents, c’est pas magique

Ils sont excellents pour :

• Recherches isolées
• Tâches simples
• Analyses ciblées
• Préparation d’infos

Mais contre-productifs si :

• Ils doivent manipuler énormément de contexte partagé
• Ils travaillent sur une grosse archi
• Ils dupliquent sans arrêt les mêmes infos

Le but c’est pas de multiplier les agents. C’est de réduire le bruit dans le contexte principal.

Le cache : plus important qu’on ne croit

Claude utilise des mécanismes de cache pour éviter de retraiter certaines parties du contexte.

Mais ce cache peut être perturbé si :

• Tu changes constamment de model
• Tu modifies fortement les outils actifs
• Tu casses le flux de travail

C’est pour ça que j’évite de switcher de model en permanence dans une même conversation.

Je préfère déléguer certaines tâches à des agents spécialisés.

Et si tu veux vraiment charger un outil, un skill, etc.. fait le au début de la session et jamais pendant.

Les fichiers lourds : le piège à tokens $$$

Pour le coup, ça semble logique que lire un fichier ça consomme plus de tokens qu’un simple texte. D’autant plus que lire un fichier, l’ouvrir, regarder une image, demande beaucoup d’efforts, beaucoup de tokens. Donc, ça me paraît complètement logique de ne pas en utiliser (quand ce n’est pas nécessaire).

Surtout qu’on le sait tous … les models vision consomment énormément ! à partir du moment où on va donner un fichier à parser, à lire, ça va être un gouffre à tokens.

Le mieux, c’est qu’à chaque fois que c’est possible, il faut le convertir, donner du texte, donner simplement les éléments importants d’un screenshot. Comme ça c’est beaucoup plus simple, on donne du texte brut. On en revient à l’article précédent que j’ai fait, où on donne du markdown pour que ce soit le plus simple à lire et on enlève tout le bruit parasite.

RTK : réduire le bruit dans les commandes Bash

Un outil qui a changé mon utilisation de Claude Code : RTK : https://github.com/rtk-ai/rtk

Le principe est simple mais puissant. Quand Claude utilise des commandes Bash pour rechercher des fichiers, analyser du code ou explorer un projet, énormément de bruit peut être généré :

• Sorties trop longues
• Logs inutiles
• Infos redondantes
• Résultats peu pertinents

Et tout ce bruit finit dans le contexte.

Donc :

• Plus de tokens consommés
• Contexte qui grossit plus vite
• Réponses moins efficaces

RTK agit comme une couche d’optimisation autour des commandes Bash.

L’objectif : ne transmettre à Claude que les infos réellement utiles.

En pratique, ça permet :

• De réduire le bruit dans le contexte
• D’améliorer la qualité des recherches
• De limiter la consommation inutile de tokens
• De garder un agent principal beaucoup plus propre

Mesurer les tokens : indispensable

Quand tu commences à optimiser sérieusement Claude Code, il faut mesurer ce que t’envoies réellement.

Pour ça, j’utilise :

• Une status line
• Des compteurs de contexte
• Des outils d’estimation de tokens

Par exemple, la librairie tiktoken sur GitHub : https://github.com/openai/tiktoken permet d’estimer rapidement le nombre de tokens d’un texte.

C’est ultra utile pour comprendre :

• Ce qui coûte cher
• Ce qui surcharge le contexte
• Ce qui doit être simplifié

Le script que j’ai mis en place avec la lib

#!/usr/bin/env python3
"""count_tokens.py — Estimate token count using tiktoken"""
import sys
import tiktoken
from pathlib import Path

enc = tiktoken.get_encoding("cl100k_base")

def count(path):
    text = Path(path).read_text(encoding="utf-8")
    tokens = len(enc.encode(text))
    chars = len(text)
    words = len(text.split())
    return tokens, chars, words

if __name__ == "__main__":
    total = 0
    for path in sys.argv[1:]:
        tk, ch, wd = count(path)
        total += tk
        print(f"{tk:>6} tokens │ {wd:>5} mots │ {ch:>6} chars │ {path}")
    if len(sys.argv) > 2:
        print(f"{total:>6} tokens │ TOTAL")

+ un petit alias et op un petit : cctk monfichier et j’ai une bonne estimation.

❯ cctk Claude.md
   731 tokens │   323 mots │   2613 chars │ Claude.md

Ça va me permettre, à chaque fois que je crée mes fichiers Claude.md ou mes agents, de pouvoir à chaque fois avoir une estimation de la quantité de tokens avant de les mettre dans le projet. Et comme ça, je peux optimiser mes fichiers pour avoir la quantité de tokens que j’estime nécessaire (sans dépasser la limite que je m’impose).

Ce que cette méthode change

Le but, c’est pas juste d’économiser quelques tokens.

Le vrai bénéfice :

• Garder des sessions longues
• Éviter les limitations trop rapides
• Réduire le bruit dans les raisonnements
• Améliorer la qualité des réponses
• Conserver un workflow fluide toute la journée

Et honnêtement, une fois que tu bosses comme ça, impossible de revenir en arrière.

Conclusion

Aujourd’hui, utiliser efficacement Claude Code, c’est plus juste une histoire de bons prompts.

Le vrai sujet, c’est l’organisation du workflow.

Les devs qui tiennent toute une journée avec le même abonnement sont pas forcément ceux qui consomment le moins.

Ce sont ceux qui :

• Contrôlent leur contexte
• Utilisent les bons models
• Délèguent intelligemment les tâches
• Nettoient régulièrement leurs conversations
• Réduisent le bruit au maximum

Et c’est probablement ça le vrai virage quand on commence à bosser sérieusement avec des agents IA.

On parle plus seulement de prompting => On parle d’architecture de travail.