Optimisation des tokens Claude Code : réduire le coût avec /usage sans perdre en qualité

Optimiser les tokens dans Claude Code ne consiste pas seulement à réduire une facture. Quand le contexte devient trop lourd, les réponses ralentissent, d’anciennes hypothèses se mélangent à la tâche en cours, et Claude relit des logs, diffs et décisions qui ne servent plus. Le bon objectif est de conserver la même qualité avec moins de contexte inutile.

En juin 2026, l’entrée pratique est /usage. La référence officielle des commandes le décrit comme la commande qui affiche session cost, plan usage limits et activity stats. /cost et /stats existent comme alias, mais /usage est plus clair dans une documentation et dans une règle d’équipe. Sur les plans Pro, Max, Team et Enterprise, l’écran peut aussi attribuer l’usage aux skills, sous-agents, plugins et serveurs MCP.

La méthode tient en quatre couches : observer, réduire le contexte de base, séparer le travail bruyant, puis mesurer les workflows répétables. Un hook est un script ou endpoint lancé à un événement fixe du cycle Claude Code ; un sous-agent est un contexte séparé pour une tâche étroite ; un harness est l’armature qui rend le travail d’agent répétable et sûr.

flowchart LR
  A["Observer: /usage et /context"] --> B["Réduire: CLAUDE.md et entrées ciblées"]
  B --> C["Séparer: hooks / skills / sous-agents"]
  C --> D["Mesurer: OpenTelemetry et règles d'équipe"]

Commencer par /usage

Inutile de lancer /usage après chaque prompt. Utilisez-le quand la session ralentit, après une grosse sortie d’outil, avant une passation, ou à la fin d’un workflow que vous allez répéter. Avec /context, vous voyez si le coût vient de la tâche, de l’historique, de la mémoire ou des outils.

La facturation doit rester séparée de l’optimisation du travail. Le bloc Session de /usage est une estimation locale basée sur les tokens. Les utilisateurs API doivent vérifier la facturation réelle dans Claude Console. Pour les abonnements, le dollar figure de session ne doit pas être lu comme une facture directe ; les barres d’usage du plan et l’attribution d’activité sont plus pertinentes.

# Dans Claude Code
/usage
/context

# Quand la conversation est longue mais doit continuer
/compact Preserve changed files, failing tests, decisions, and unresolved questions.

# Quand vous passez à une tâche sans rapport
/clear

/compact résume l’état important pour continuer. /clear démarre un nouveau contexte. Trop tôt, vous perdez des décisions ; trop tard, chaque tâche paie l’ancien contexte.

Garder la mémoire toujours chargée courte

Les tokens ne viennent pas seulement de la dernière phrase. Ils incluent l’historique, CLAUDE.md, auto memory, les logs, les sorties d’outils, les serveurs MCP et les notes de recherche. Classez l’information en trois groupes.

Type	Meilleur emplacement	Exemple
Nécessaire à chaque session	CLAUDE.md court	Build, tests, contraintes fortes
Nécessaire pour cette tâche	Conversation et `/compact`	Fichiers modifiés, tests en échec, décisions ouvertes
Jetable après lecture	Sortie filtrée	Logs longs, diffs générés, recherches larges

La documentation officielle de memory indique que CLAUDE.md est chargé comme contexte. Plus il est long, plus le coût fixe augmente. Les imports peuvent organiser les règles, mais ne réduisent pas les tokens si tout est chargé au démarrage.

# CLAUDE.md

## Project commands
- Build: npm run build
- Test: npm run test
- Type check: npm run typecheck

## Fast navigation
- API code: src/api/
- UI components: src/components/
- Tests: tests/

## Avoid by default
- Do not scan node_modules/, dist/, coverage/, or generated clients.
- Do not paste full logs. Ask for the failing command and relevant lines.

## Compact instructions
When compacting, preserve changed files, failing tests, decisions, credentials policy, and next actions.

Les longues checklists de revue, règles de traduction, runbooks de migration ou guides de release sont souvent mieux placés dans des skills ou documents séparés. Une skill se charge quand elle est appelée ; CLAUDE.md est présent dès le début.

Filtrer avant lecture

Le gaspillage le plus courant consiste à coller tout le log ou tout le diff. Claude a besoin de preuves, pas d’un dump. Gardez l’artefact complet sur disque et transmettez d’abord les lignes qui peuvent changer la décision.

# Pas tout le log de production: request ID et erreurs proches
tail -n 800 logs/app.log | grep -E -n -C 4 "request_id=abc123|ERROR|WARN"

# Voir la taille du PR avant le diff complet
git diff --stat
git diff -- src/auth.ts tests/auth.test.ts

# Conserver toute la sortie localement, montrer seulement la zone en échec
npm test 2>&1 | tee test.log
grep -E -n -C 6 "FAIL|ERROR|Error|failed|Assertion" test.log | head -160

Ce n’est pas cacher l’information. C’est choisir la première tranche que Claude lit. Si elle ne suffit pas, vous ajoutez un autre fichier ou plus de lignes.

Utiliser les hooks prudemment

Si le même filtre revient souvent, un hook peut l’automatiser. Il ne doit pas masquer les erreurs ni approuver silencieusement des commandes risquées. Commencez avec ask, vérifiez la commande réécrite et testez localement.

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "~/.claude/hooks/filter-test-output.sh"
          }
        ]
      }
    ]
  }
}

#!/usr/bin/env bash
set -euo pipefail

input=$(cat)
cmd=$(echo "$input" | jq -r '.tool_input.command // ""')

case "$cmd" in
  npm\ test*|pnpm\ test*|pytest*|go\ test*)
    filtered="$cmd 2>&1 | grep -E -n -C 6 '(FAIL|ERROR|Error|failed|Assertion)' | head -160"
    jq -n --arg command "$filtered" '{
      hookSpecificOutput: {
        hookEventName: "PreToolUse",
        permissionDecision: "ask",
        permissionDecisionReason: "Run test command with filtered output",
        updatedInput: { command: $command }
      }
    }'
    ;;
  *)
    echo '{}'
    ;;
esac

Cet exemple demande jq. Pour une équipe, sauvegardez aussi le log complet et conservez l’exit code original. Un hook est utile seulement s’il réduit le bruit sans réduire la preuve.

Séparer le travail verbeux

Les sous-agents sont utiles quand le processus est long mais que la session principale n’a besoin que d’une conclusion courte : vérifier une documentation officielle et retourner les changements, contrôler dix fichiers localisés et ne retourner que les blocages, ou lancer un test et résumer le premier stack trace exploitable.

Ne créez pas des sous-agents par réflexe. Chacun a son contexte, sa mémoire, ses outils et son coût. Leur rôle est de protéger le contexte de décision, pas de paralléliser des demandes vagues. Même logique pour les skills : sortez de CLAUDE.md les playbooks longs et rares.

Mesurer en équipe

Pour une personne, /usage et /context suffisent souvent. En équipe, OpenTelemetry transforme coût, tokens, modèle, durée et activité des outils en données communes. Commencez par le console exporter avant un collector.

export CLAUDE_CODE_ENABLE_TELEMETRY=1
export OTEL_METRICS_EXPORTER=console
export OTEL_LOGS_EXPORTER=console
export OTEL_METRIC_EXPORT_INTERVAL=10000
export OTEL_LOGS_EXPORT_INTERVAL=5000

claude

Mesurez la qualité en même temps. Si les tokens baissent de 30 % mais que les corrections et défauts de revue augmentent, le processus s’est dégradé.

Cas d’usage

Analyse de logs

Transmettez request ID, erreurs récentes, timestamps, comportement attendu et lignes proches. Commencez petit, élargissez seulement si les preuves manquent.

Revue de code

Donnez git diff --stat, fichiers modifiés, sortie des tests et angles de revue. Pour un gros PR, séparez sécurité, performance et compatibilité.

Publication multilingue

Gardez les décisions de l’article canonique dans la session principale. Traduction, liens, description et CTA peuvent être vérifiés dans des contextes séparés.

Journée de formation

En atelier, la concurrence d’usage augmente. Des règles simples, comme cinq fichiers au départ, 160 lignes d’échec maximum et justification avant élargissement du scope, stabilisent le coût.

Pièges à éviter

Documenter uniquement /cost. Utilisez /usage et mentionnez /cost et /stats comme alias.
Couper les preuves. Reproduction, sortie attendue, commande en échec et décisions doivent rester.
Transformer CLAUDE.md en carnet d’exploitation. Les workflows rares vont dans des skills.
Activer trop de MCP. Vérifiez /mcp et utilisez le CLI quand il suffit.
Masquer les échecs avec hooks. Gardez le log complet et montrez une tranche filtrée.
Croire que les sous-agents coûtent toujours moins cher. Ils isolent le bruit, mais consomment leur propre contexte.

Script court de passation

Ce script Node.js sans dépendance résume fichiers modifiés, taille du diff et lignes de test en échec.

#!/usr/bin/env node
import { execFileSync } from "node:child_process";
import { existsSync, readFileSync } from "node:fs";

function git(args) {
  return execFileSync("git", args, { encoding: "utf8" }).trim();
}

const testLogPath = process.argv[2];
const changedFiles = git(["diff", "--name-only"])
  .split(/\r?\n/)
  .filter(Boolean);
const diffStat = git(["diff", "--stat"]);
const testLog = testLogPath && existsSync(testLogPath)
  ? readFileSync(testLogPath, "utf8")
  : "";
const failures = testLog
  .split(/\r?\n/)
  .filter((line) => /(FAIL|ERROR|Error|failed|Assertion)/.test(line))
  .slice(0, 80);

console.log("# Claude handoff brief\n");
console.log("## Changed files");
console.log(changedFiles.length ? changedFiles.map((file) => `- ${file}`).join("\n") : "- None");
console.log("\n## Diff stat");
console.log(diffStat || "No diff");
console.log("\n## Test failures");
console.log(failures.length ? failures.map((line) => `- ${line}`).join("\n") : "- No matching failure lines");

node scripts/claude-brief.mjs test.log > claude-brief.md

Documentation officielle vérifiée

Commands pour /usage, /context, /compact et /clear.
Manage costs effectively pour coûts, MCP, hooks, skills, sous-agents et effort de modèle.
How Claude remembers your project pour CLAUDE.md et auto memory.
Hooks reference et Monitoring pour PreToolUse et OpenTelemetry.

Résultat testé

Pour cette réécriture, j’ai utilisé l’article japonais comme version canonique et vérifié les documents officiels avant de mettre à jour les dix locales. Le gain le plus net vient de la séparation entre mémoire permanente, état de tâche et logs jetables. Un brief court avec fichiers modifiés, lignes en échec et statut de vérification produit de meilleures réponses qu’une sortie de test complète.

Pour des prompts et supports réutilisables, commencez par ClaudeCodeLab products. Pour un déploiement d’équipe avec permissions, règles de revue, télémétrie et formation, utilisez Claude Code training and consultation.