313 — Outils de réduction (snip, minimal-context-tools)

Durée estimée : 60 min · Complexité : ⭐⭐⭐ · Pré-requis : Module 311

Au-delà de la conception du code et du choix de modèle, trois catégories d’outils réduisent mécaniquement la consommation de tokens.

Pourquoi ce module

Tu sais pourquoi les tokens comptent (Module 311) et comment tes patterns de design influencent la consommation (Module 312). Mais même avec un code bien structuré, l’agent charge des fichiers entiers, exécute des commandes verbeuses et accumule des milliers de tokens inutiles dans le contexte.

Ce module présente les trois familles d’outils qui réduisent mécaniquement cette consommation : les sous-agents pour isoler les lectures, les CLI ciblés pour extraire uniquement l’information pertinente, et snip pour filtrer les sorties terminal avant qu’elles n’atteignent le modèle.

À la fin de ce module, tu sais :

• utiliser l’outil agent pour isoler les lectures de fichiers dans un sous-agent ;
• remplacer read_file par des CLI ciblés (ast-grep, rg, jq) pour réduire de 80 à 95 % les tokens chargés ;
• installer et configurer snip pour filtrer les sorties shell ;
• mesurer le gain concret de chaque outil sur une session réelle.

Pré-requis

• Module 311 — Tokens & fenêtre de contexte — tu dois comprendre pourquoi les tokens comptent.
• Module 208 — Workflows — tu dois maîtriser l’orchestration par sous-agents.
• VS Code avec l’extension GitHub Copilot activée.
• Un terminal avec brew disponible (macOS) ou accès à un gestionnaire de paquets.

Concepts clés

1 Sous-agents (outil agent)

Dans un workflow orchestré (Module 208), l’outil agent délègue une tâche à un sous-agent qui lit les fichiers, raisonne, et restitue une conclusion synthétique. L’orchestrateur ne reçoit pas les fichiers bruts — il reçoit un résumé. Ce pattern réduit massivement les tokens en transit entre les étapes.

flowchart LR
    O[Orchestrateur] -->|"outil agent: analyse ce module"| S[Sous-agent]
    S -->|"lit 3 fichiers (4000 tokens)"| F[Fichiers]
    S -->|"résumé: 200 tokens"| O

Sans sous-agent, l’orchestrateur aurait chargé les 4000 tokens de fichiers dans son propre contexte.

Anti-pattern à éviter : le sous-agent qui copie-colle 500 lignes dans sa réponse. Le coût est juste déplacé, pas réduit. Le sous-agent doit restituer uniquement la conclusion, pas les fichiers entiers.

2 Outils ciblés (minimal-context-tools)

Par défaut, l’agent lit des fichiers entiers avec read_file et exécute des commandes shell verbeuses. Chaque opération injecte des centaines — parfois des milliers — de tokens dans le contexte. Les minimal-context-tools remplacent ces opérations par des CLI spécialisés qui extraient uniquement l’information pertinente :

La différence est concrète : un read_file sur un fichier de 500 lignes consomme environ 6 000 à 8 000 tokens. Un ast-grep sur le même fichier pour en extraire la structure (signatures de fonctions, noms de classes, exports) en consomme 400 à 700. C’est 90 % d’économie sur une seule opération — et ces économies se cumulent à chaque appel d’outil dans une session.

L’intérêt va au-delà des tokens. Ces CLI sont déterministes — contrairement à un grep dont la sortie peut varier en verbosité, rg avec --context et jq avec un filtre précis produisent toujours une sortie prévisible et minimale. Moins de bruit entrant = moins d’hallucination sortante.

3 SNIP — réduction de tokens au niveau du shell

snip est un proxy CLI écrit en Go qui intercepte les commandes shell lancées par ton assistant IA et filtre leur sortie via des pipelines YAML déclaratifs avant qu’elle n’atteigne la fenêtre de contexte. Pas de résumé approximatif — des filtres déterministes par commande.

L’impact est concret :

L’installation et l’intégration se font en deux commandes :

# Installer snip (macOS / Linux)
brew install edouard-claude/tap/snip

# Intégrer avec Copilot
snip init --agent copilot

Snip supporte aussi Claude Code (snip init), Cursor (--agent cursor), Gemini CLI (--agent gemini), Codex (--agent codex) et une dizaine d’autres agents. 127 filtres couvrent git, go, cargo, npm, docker, kubectl, terraform, aws, gh et 80+ autres outils.

Si aucun filtre ne correspond à une commande, elle passe inchangée — zéro overhead. Snip traque les économies dans une base SQLite locale et affiche un rapport via snip stats.

4 RTK — l’alternative Rust

rtk (« Rust Token Killer ») poursuit le même objectif que snip — filtrer la sortie shell avant qu’elle n’atteigne le contexte — avec un binaire Rust unique, zéro dépendance et moins de 10 ms de surcoût. Il prend en charge plus de 100 commandes et filtre, regroupe, tronque et déduplique la sortie.

Les deux outils sont interchangeables : choisis snip si tu veux des filtres YAML déclaratifs et personnalisables, rtk si tu privilégies un binaire unique sans configuration.

Mise en pratique

Étape 1 — Installer les CLI minimal-context-tools

Installe les outils de base :

brew install ast-grep ripgrep jq yq fd sd tokei bat fzf

Étape 2 — Comparer read_file vs extracting-code-structure

Sur un fichier de plus de 200 lignes :

# Outil naïf — tout le fichier
wc -c src/mon-fichier.ts  # ex: 8500 caractères ≈ 2500 tokens

# Outil ciblé — seulement la structure
ast-grep --pattern '$NAME($$$PARAMS): $RET { $$$ }' src/mon-fichier.ts
# ex: 12 lignes ≈ 200 tokens

Étape 3 — Installer et mesurer snip

# Installer
brew install edouard-claude/tap/snip

# Intégrer avec Copilot
snip init --agent copilot

Lance une session Copilot et exécute 10–20 commandes habituelles (git log, npm test, go test ./...). Consulte le rapport :

snip stats

Étape 4 — Mesurer le gain sur une session

Compare le nombre de tokens de deux sessions identiques (même tâche, même repo) — une sans snip, une avec. Le delta moyen mesuré est de 60 à 85 % de réduction sur les sessions CLI intensives.

Pièges & anti-patterns

Exercice ⭐⭐⭐

Énoncé

Partie 1 — Minimal-context-tools

1. Choisis 3 fichiers de plus de 200 lignes dans ton projet.
2. Pour chaque fichier, compare le nombre de tokens entre read_file complet et ast-grep (structure seule).
3. Calcule le pourcentage d’économie moyen.

Partie 2 — SNIP

1. Installe snip dans ton workspace.
2. Choisis 3 commandes terminal fréquentes (npm test, npm run build, git log --oneline -20).
3. Pour chaque commande, mesure le nombre de lignes avant et après snip.
4. Calcule le pourcentage de réduction moyen.

Résultat attendu

# Partie 1
fichier_1: { read_file: 2400 tokens, ast_grep: 280 tokens, economie: "88%" }
fichier_2: { read_file: 3100 tokens, ast_grep: 350 tokens, economie: "89%" }
fichier_3: { read_file: 1800 tokens, ast_grep: 200 tokens, economie: "89%" }
moyenne: "89%"

# Partie 2
commande_1: { avant: 420 lignes, apres: 12 lignes, reduction: "97%" }
commande_2: { avant: 180 lignes, apres: 25 lignes, reduction: "86%" }
commande_3: { avant: 95 lignes, apres: 18 lignes, reduction: "81%" }
moyenne: "88%"

Validation

Tu as réussi ce module si :

• Tu as mesuré le gain des minimal-context-tools sur au moins 3 fichiers, avec un pourcentage d’économie documenté.
• Tu as installé snip et produit une mesure chiffrée du gain sur au moins 3 commandes.
• Tu sais expliquer la différence entre un sous-agent qui résume et un sous-agent qui copie-colle.

Pour aller plus loin

• Plugin minimal-context-tools — explore le dépôt sebastiendegodez/copilot-instructions pour voir comment les skills wrappent les CLI.
• Pipelines snip personnalisés — crée un filtre YAML custom pour une commande spécifique à ton projet.
• Module 312 — Patterns de sobriété — les principes de design qui complètent ces outils.
• Module 311 — Tokens & fenêtre de contexte — le cadre théorique.

Sources

• snip — edouard-claude/snip — le dépôt source, documentation des 127 filtres et benchmarks.
• minimal-context-tools — sebastiendegodez/copilot-instructions — le plugin qui package les skills de réduction.
• ast-grep — documentation officielle du pattern matching AST.
• ripgrep — documentation officielle.
• rtk — rtk-ai/rtk — le « Rust Token Killer », alternative Rust à snip. Outil mis en avant par Ousmane BARRY (MVP Microsoft Foundry).