RTK : j'étais contre cet outil. Il m'a montré pourquoi j'avais tort — et raison

Pendant plusieurs semaines, des collègues m'ont recommandé RTK — Rust Token Killer — un outil qui compresse les sorties CLI avant qu'elles n'entrent dans le contexte de Claude Code.

Ma réponse a toujours été la même : non.

Non pas par paresse. Mais par principe. Je préfère comprendre la cause d'un problème et la corriger plutôt que d'empiler des couches d'abstraction qui masquent les symptômes. Si mes outils génèrent trop de tokens, c'est peut-être parce que j'appelle les mauvais outils, au mauvais moment, de la mauvaise façon.

Ajouter un filtre là-dessus, c'est comme mettre du scotch sur un voyant moteur.

Et puis j'ai installé RTK. Et quelque chose d'inattendu s'est produit.

Avant de continuer de lire la suite de l'article, je vous invite à vous inscrire à ma newsletter, pour connaître en avant première les futurs sujets traités chaque semaine.

Le problème que je voulais vraiment résoudre

Depuis environ six semaines, je tracke finement ma consommation de tokens dans Claude Code. J'ai mis en place des hooks, des KPI quotidiens, un tableau de bord. Je mesure les tokens d'entrée, de sortie, les cache hits, le taux de « waste ».

Le taux de waste — c'est-à-dire les tokens générés par des appels d'outils inutiles ou surdimensionnés — oscillait entre 6,6 % et 9,4 % selon les journées. Pas catastrophique. Mais constant.

Ma réaction naturelle : auditer le comportement de mes agents, améliorer les prompts, forcer la fusion des appels SQL (j'avais déjà un hook same-context-guard qui bloquait les troisième appels psql consécutifs). Travailler sur les causes.

C'est la bonne approche. C'est aussi une approche aveugle si on n'a pas les données.

Ce que rtk discover m'a appris en 30 secondes

La commande rtk discover scanne l'historique des sessions Claude Code et identifie les commandes qui auraient pu être filtrées par RTK. Résultat sur mes 44 dernières sessions :

Scanned: 44 sessions (last 30 days), 1 581 Bash commands
Already using RTK: 0 commands (0%)

MISSED SAVINGS
psql (direct)    287 appels  →  ~84 400 tokens manqués
tail             162 appels  →  ~34 800 tokens manqués
docker exec       71 appels  →   ~2 700 tokens manqués
ls                77 appels  →   ~4 200 tokens manqués
grep -n           38 appels  →   ~2 900 tokens manqués

Total : 673 commandes → ~131 500 tokens évitables

131 500 tokens. En 44 sessions. Dont 64 % provenant d'une seule commande : psql appelé sans préfixe RTK.

Ce n'est pas un problème de filtre. C'est un problème de discipline d'instrumentation. Et ce diagnostic-là, je n'aurais jamais pu le produire sans un outil qui scanne l'historique réel des commandes.

L'installation : 2 jours, résultats mesurables

J'ai installé RTK le 19 mars 2026. Voici ce que mes KPI ont enregistré avant et après.

Tokens d'entrée par session (projet .claude)

Taux de waste quotidien

En deux jours, le taux de waste est passé de 6,60 % à 5,1 %. Ce n'est pas RTK seul qui produit ce résultat : c'est RTK qui révèle les problèmes, ce qui permet de les corriger.

La vraie valeur : un scanner, pas un filtre

Voici la distinction que j'avais ratée.

Un filtre, c'est passif. Il compresse ce qui passe. Il n'explique rien.

Un scanner de diagnostic, c'est actif. Il dit : « cette commande a généré X tokens inutiles, voici pourquoi, voici comment corriger. »

RTK est les deux à la fois. Le filtre automatique sauve des tokens dès l'installation. Mais rtk discover, rtk gain, rtk session — ces commandes transforment RTK en instrument d'audit de votre infrastructure.

Concrètement, après avoir lu le rapport de diagnostic :

1. J'ai amélioré le hook post-write-rtk-check.ts pour détecter les scripts /tmp/*.sh mixtes — ceux qui ont du RTK quelque part mais aussi des psql ou tail nus. La version précédente ne signalait rien si au moins une commande RTK était présente.
2. J'ai ajouté tail explicitement dans la liste des commandes à préfixer dans mes règles (RTK le réécrit en rtk read --tail-lines N, mais cette règle n'était pas documentée pour les scripts internes).
3. J'ai ajouté un filtre nvidia-smi dans ~/.config/rtk/filters.toml pour compacter les sorties GPU verboses.

Ces corrections, je les aurais peut-être faites un jour. Sans le diagnostic, je n'aurais pas su où chercher.

Ce que RTK ne règle pas

Soyons honnêtes.

RTK ne corrige pas les vrais problèmes d'architecture. Si un agent appelle psql dix fois sur la même base parce que le prompt est mal structuré, RTK va compresser ces dix sorties — mais l'agent appellera encore dix fois.

La cause reste la cause. Le hook same-context-guard qui force la fusion en un script /tmp/ est plus puissant que RTK pour ce cas précis.

De même, RTK ne touche pas aux tokens de cache. Mon taux de cache hit est de 96,1 % — ça, c'est le résultat d'une architecture de cache bien pensée (prompts stables, cache_control sur les blocs longs, warm-up au démarrage de session). RTK ne peut pas produire ça.

En revanche, les 9 762 appels tail et les 17 792 appels psql non optimisés que rtk discover --all a détectés sur l'ensemble de mes projets — ceux-là, RTK peut les traiter directement.

Pourquoi j'avais raison d'hésiter

Un outil de plus, c'est une dépendance de plus. Une complexité de plus à maintenir.

Et cette critique reste valide. Avant d'ajouter RTK, assurez-vous d'avoir :

• Mesuré votre consommation réelle (sans mesure, impossible de prioriser)
• Identifié vos patterns de gaspillage (hooks, git log verbeux, docker logs complets)
• Corrigé les causes structurelles accessibles (fusion d'appels, LSP au lieu de Grep, Read au lieu de cat)

Si vous faites ça, RTK s'installe sur un terrain sain. Il compresse ce qui reste incompressible autrement. Et son diagnostic confirme que vous avez bien travaillé — ou révèle ce qui vous a échappé.

Dans mon cas, psql sans préfixe était un angle mort. Je pensais avoir couvert la question avec mes règles explicites. rtk discover m'a montré que non.

En pratique : 5 minutes pour commencer

# Installation
curl -fsSL https://raw.githubusercontent.com/rtk-ai/rtk/refs/heads/master/install.sh | sh

# Vérification
rtk --version && rtk verify

# Diagnostic immédiat
rtk discover      # Scanne vos 30 dernières sessions
rtk session       # Taux d'adoption par session (cible : > 70 %)
rtk gain          # Savings actuels par commande

Le hook de réécriture s'installe automatiquement dans Claude Code. Dès ce moment, psql, tail, ls, git status, grep sont automatiquement préfixés — même si vous les écrivez sans rtk.

Le premier rtk discover vous donnera votre vrai diagnostic.

Conclusion : le bon outil au bon moment

Pendant des semaines, j'ai eu raison de résister. Pas parce que RTK est mauvais — mais parce qu'un outil sans mesure préalable ne sert à rien. Vous ne saurez pas ce qu'il vous apporte.

Maintenant que j'ai la mesure, RTK a sa place dans mon infrastructure. Non pas comme une rustine, mais comme un instrument de précision qui confirme ou infirme mes hypothèses sur les angles morts de ma consommation.

−25 % de tokens d'entrée par session. −41 % de waste quotidien. En deux jours.

Ce n'est pas le résultat de RTK seul. C'est le résultat de comprendre ce que RTK révèle — et d'agir dessus.

→ Liens internes : Réduction de tokens en 6 semaines · Fusion d'appels de fonctions
→ Source : RTK — github.com/rtk-ai/rtk

Qui suis je ?

Je suis Mathieu GRENIER, CTO d'Easystrat une startup de Montpellier, en France. Je manage une équipe d'une dizaine d'ingénieurs (Graphistes, IA, frontend, backend, devOps, AWS) en remote depuis le Japon.

J'ai aussi mon activité de freelance, où je conseille des entrepreneurs dans leurs projets d'application.

Avec mon expérience personnelle de plus de 15 ans en ESN, j'ai pu travailler pour un large panel d'entreprises de différentes tailles. Ma compréhension des problèmes métiers est une de mes grandes forces et permet à mes clients de pouvoir se projeter plus facilement.

L'essentiel de mon travail consiste à canaliser l'énergie des entrepreneurs sur l'essence même de leur projet.

La technologie, les méthodes, le management sont le cœur de mes compétences.

Vous pouvez me faire confiance sur ces points là.

Si vous voulez me parler d'un de vos projets, n'hésitez pas à m'envoyer un email avec vos disponibilités à : contact@mathieugrenier.fr

Tous les articles de ce blog sont écrits par moi, même si je peux m'aider de l'IA pour illustrer mes propos. Mais jamais je ne fournis d'articles 100% IA.