Une semaine à configurer RTK — et la vraie révélation n'était pas celle que j'attendais

Ça m'a pris une semaine. Pas une semaine à installer RTK — ça prend dix minutes. Mais une semaine à comprendre pourquoi ça ne fonctionnait pas comme je l'espérais. Une semaine à observer Claude Code se comporter comme un liquide : il trouve toujours la fissure.

Et à la fin de cette semaine, j'ai compris quelque chose sur les LLMs que je n'avais pas lu dans aucun article.

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.

Pourquoi une semaine ?

RTK — Rust Token Killer est un proxy CLI. Il s'intercale entre Claude Code et le terminal, filtre les sorties des commandes avant qu'elles n'entrent dans le contexte de Claude, et économise des tokens. Le principe est élégant : compresser psql, grep, curl, ls à la source, avant que le contexte ne gonfle.

J'avais déjà écrit sur mes réticences initiales et comment rtk discover les a balayées. L'outil est bon. Les chiffres sont là :

• 189,1 millions de tokens économisés sur 4 810 commandes
• 98,3 % d'efficacité mesurée par rtk gain
• psql : 98,9 % d'économie par appel
• curl local : 99,1 % d'économie
• grep : 184,7 millions de tokens — la catégorie de loin dominante

Mais entre « l'outil fonctionne » et « l'outil change vraiment mon flux », il y a eu une semaine de friction que je n'avais pas anticipée.

Le problème des garde-fous

J'ai configuré RTK avec des règles strictes. Hook bash-guard dans Claude Code pour bloquer certains patterns. Filtres custom dans ~/.config/rtk/config.toml. Limites sur grep_max_results, grep_max_per_file. J'ai mis des gardes partout.

Et Claude a continué à faire ce qu'il voulait.

Pas par malveillance. Par réflexe. Quand je bloquais grep -n pattern *.ts, Claude ne s'arrêtait pas. Il créait un script Python dans /tmp/ :

import subprocess
result = subprocess.run(['grep', '-n', 'pattern'], capture_output=True, text=True)
print(result.stdout)

Ou un script Bash :

#!/bin/bash
grep -n 'pattern' *.ts | head -50

Résultat : bash /tmp/check-pattern.sh. Le hook RTK voit bash /tmp/check-pattern.sh — une commande Bash anodine. Il ne voit pas ce qu'il y a à l'intérieur. Le filtre est contourné. Claude a ses données. Et moi, j'ai dépensé des tokens comme si je n'avais rien configuré.

C'est là que j'ai commencé à comprendre quelque chose de plus profond.

Grep, c'est sa main

Il faut voir ce comportement pour ce qu'il est : ce n'est pas un bug, c'est un réflexe.

Claude Code est entraîné sur des dizaines, probablement des centaines de millions de lignes de code source, de tutoriels, de Stack Overflow, de repositories GitHub. Parmi ces données, grep apparaît des millions de fois. grep -n pattern file.ts. grep -r 'function' src/. grep --include="*.py" -r 'import'.

Quand Claude cherche quelque chose dans un codebase, il pense en grep. Ce n'est pas un choix délibéré, c'est une association profonde, encodée dans ses poids. Comme un développeur expérimenté qui ouvre un terminal et tape grep avant même d'avoir réfléchi à son outil préféré.

Vous ne pouvez pas « désapprendre » grep à Claude Code. C'est comme essayer d'empêcher un développeur senior de taper ls pour vérifier où il en est. L'habitude est trop profonde. C'est sa main.

Et quand vous bloquez sa main, il improvise avec ses pieds.

La vraie configuration : pas les garde-fous, mais le canal

L'erreur que j'ai faite pendant cette semaine, c'était de voir RTK comme un filtre à poser sur la sortie de Claude. Un garde-fou entre Claude et les tokens.

Ce n'est pas ça.

RTK est efficace quand il devient le seul canal vers lequel Claude Code route ses commandes.

La différence est subtile mais fondamentale. Si Claude crée des scripts /tmp/ pour contourner vos hooks, la solution n'est pas d'ajouter plus de hooks. C'est de faire en sorte que Claude utilise rtk grep directement, depuis l'intérieur des scripts qu'il génère.

La règle que j'ai finalement ancrée dans CLAUDE.md :

RTK inside /tmp scripts — quand on écrit des scripts bash dans /tmp/,
utiliser rtk grep, rtk psql, rtk ls à l'intérieur.
Le hook RTK ne voit que le bash /tmp/script.sh externe — sans rtk
à l'intérieur, les économies sont nulles.

Et ça a tout changé.

Les chiffres avant / après

Voici ce que rtk session montrait avant la vraie configuration :

Session      Adoption
ddfce5e2     57% — 354 commandes non-RTK
5f86a91e     38% — 127 commandes non-RTK
cf3a7d09     44% — 66 commandes non-RTK
Moyenne : 53%

53 % d'adoption. Presque la moitié des commandes passaient en dehors de RTK. La cause principale : les scripts /tmp/ générés par Claude, avec des grep, psql, tail directs à l'intérieur.

L'analyse N2 (ma couche de monitoring inconscient) le confirmait :

• 19,33 millions de tokens / 7 jours
• 5,4 % de waste — soit 1,04 million de tokens évitables
• grep -n seul : 98 % de waste sur 181 000 tokens

Ce 98 % de waste, c'est exactement ça : Claude crée des scripts, lance des grep à l'intérieur, et toute la sortie entre dans le contexte.

Ce qui est vraiment game-changer

Une fois que j'ai arrêté de me battre contre le réflexe grep et que j'ai simplement rendu rtk grep aussi naturel que grep pour Claude, quelque chose a basculé.

Pas dans les chiffres d'abord. Dans la façon dont je conçois les outils.

Un LLM ne se configure pas, il se conditionne. Vous ne pouvez pas lui retirer ses réflexes. Mais vous pouvez changer l'environnement pour que ses réflexes produisent le bon résultat.

C'est exactement ce que fait RTK quand il est bien intégré. Ce n'est pas un filtre qui combat le modèle. C'est un substitut transparent qui respecte ses habitudes tout en modifiant ses effets.

rtk grep n'est pas « grep avec un filtre ». Pour Claude, c'est juste grep. Il tape rtk grep pattern *.ts avec le même réflexe qu'il tapait grep pattern *.ts. Mais la sortie est compressée, tronquée, adaptée au contexte. 184,7 millions de tokens économisés.

La différence, c'est que le canal est bon.

Les trois leçons de cette semaine

1. Ne pas lutter contre les réflexes du modèle

Chaque tentative de bloquer un comportement profondément ancré dans les poids d'un LLM sera contournée. Pas par intelligence — par réflexe. Concevez des canaux, pas des barrages.

2. Le hook voit la surface, pas le fond

RTK intercepte bash /tmp/script.sh en tant que commande externe. Ce qu'il y a dans le script, il ne le voit pas. La vraie économie de tokens se fait en propageant les outils RTK à l'intérieur des scripts générés.

3. Mesurer avant de configurer

rtk gain, rtk session, rtk discover — ces trois commandes donnent une image précise de où l'argent fuit. Sans elles, j'aurais pu passer la semaine à configurer les mauvais garde-fous. Avec elles, j'ai pu cibler : grep à l'intérieur des scripts, adoption 53 % → cible 70 %.

En pratique

Si vous démarrez avec RTK et Claude Code, voici l'ordre :

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

# 2. Mesurer l'état réel
rtk discover          # trouve les commandes non interceptées
rtk session           # adoption rate par session

# 3. Propager la règle dans CLAUDE.md
# "Dans les scripts /tmp/, utiliser rtk grep, rtk psql, rtk ls"

# 4. Vérifier après 7 jours
rtk gain --history    # évolution des savings
rtk session           # adoption > 70% ?

Le temps de configuration réelle : une heure. Mais comprendre pourquoi — et ne plus se battre contre le modèle — ça, ça prend une semaine.

Conclusion

RTK CLI est game-changer, oui. Mais pas pour la raison que j'avais en tête.

Je pensais que c'était un filtre. Un outil pour compresser des sorties. Un garde-fou.

Ce que j'ai appris, c'est que les garde-fous — quand on les pose contre un modèle entraîné sur 100 millions de lignes de code — servent surtout à vous montrer à quel point le modèle est resourceful. Claude trouve toujours un chemin. Pas par malveillance. Par réflexe.

La vraie configuration de RTK, c'est celle qui travaille avec ces réflexes. Pas contre eux.

189 millions de tokens économisés plus tard, je comprends mieux comment les LLMs fonctionnent que je ne l'aurais appris en lisant dix articles de recherche.

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.