Construire des workflows IA token-efficients : un guide pratique

Vous avez sûrement fait le calcul : une seule session de refactor sur Claude Code peut coûter plus cher qu'un abonnement SaaS. Le correctif n'est pas "utiliser l'IA moins" — c'est mieux l'utiliser.

Voici la collection de patterns qu'on a accumulés sur six mois de DRIP en production en équipes.

Pattern 1 : Lire une fois, éditer souvent

Arrêtez de dire à l'agent de "regarder le fichier" plusieurs fois. Une fois qu'il a le fichier en contexte, demandez la modification directement.

Mauvais :

Lis app.py
Maintenant relis-le et dis-moi ce que fait parse_args
Maintenant refactore-le pour utiliser argparse
Relis-le et confirme

Bon :

Refactore parse_args dans app.py pour utiliser argparse. Montre-moi le diff avant d'appliquer.

Même résultat. Un quart des tokens. L'agent gère le cycle read/verify/write tout seul — vous n'avez pas à le chorégraphier.

Pattern 2 : Faites confiance au certificat de delta

Quand DRIP renvoie [DRIP: edit verified | hash: 0xa31… | 390 B], c'est la vérification. Pas besoin de demander à l'agent de relire le fichier "juste pour être sûr". Le payload hash + lignes touchées est cryptographiquement lié à l'édit qui vient de se passer.

Les agents modernes respectent ces certificats par défaut. Les vieux patterns de prompt ("relis le fichier pour vérifier") étaient calibrés sur du tooling qui n'avait pas d'attestation d'édit. Laissez-les tomber.

Pattern 3 : Utilisez les lectures partielles quand vous connaissez la section

Si vous enquêtez sur un fichier de 600 lignes mais que seules les lignes 200 à 280 vous intéressent, demandez cette plage :

Lis app.py lignes 200-280 et explique comment fonctionne le middleware d'auth.

La plupart des agents traduisent ça en appel Read(file, offset: 199, limit: 80). DRIP gère les lectures partielles avec un diff scopé sur la fenêtre : si vous redemandez la même fenêtre plus tard, vous obtenez un sentinel [unchanged (lines 200-280)] au lieu du renvoi complet des 80 lignes.

Pattern 4 : Compactez votre contexte avant une grosse tâche

Si vous discutez avec l'agent depuis une heure et que vous êtes sur le point de lui demander quelque chose d'exigeant (gros refactor, édit multi-fichiers), compactez avant. La commande /compact de Claude Code résume la conversation et reset le contexte de travail.

Sans /compact, l'agent relit les fichiers qu'il connaît déjà parce que la compaction lui est forcée en plein milieu de la tâche par la limite de contexte du modèle. Avec la compaction manuelle, vous contrôlez le moment — et le ledger de compaction v9 de DRIP vous dit si l'agent a dû renvoyer des tokens après le reset.

Pattern 5 : Choisissez le bon modèle pour la tâche

Toutes les tâches n'ont pas besoin d'Opus 4.7.

Tâche	Modèle	Pourquoi
Édit une ligne / typo	Haiku 4.5	50× moins cher, équivalent en petit
Refactor standard (1 fichier)	Sonnet 4.6	Sweet spot capacité vs prix
Changement archi multi-fichiers	Opus 4.7	Seul modèle qui garde la cohérence
Debug à travers la stack	Sonnet 4.6 → Opus 4.7	Commencer cheap, escalader si besoin

Dans Claude Code : claude --model sonnet-4-6 pour le défaut cheap, switch à Opus quand le boulot le justifie. Dans Codex CLI : codex --model gpt-5. Dans Gemini CLI : gemini --model gemini-2.5-pro.

Le panneau projection de coût de DripMeter permet de comparer ce que la même session aurait coûté sur chaque modèle, donc vous pouvez calibrer après coup.

Pattern 6 : Surveillez le compteur, fixez un objectif quotidien

Un objectif quotidien de tokens économisés est étonnamment efficace comme forcing function. Réglez-le dans DripMeter (défaut : 25K, mais ajustez à la baseline de votre équipe). Quand vous l'atteignez, vous avez validé que votre workflow est sain. Quand vous le ratez trois jours d'affilée, vous avez un signal qu'un truc a changé — d'habitude vous avez commencé une tâche qui ne bénéficie pas du cache (greenfield, pas de re-reads).

Le compteur de streak 🔥 nous surprend aussi — les équipes qui essayent consciemment d'atteindre des streaks 7j+ rapportent ~20 % de factures mensuelles en moins par rapport aux équipes qui ne trackent rien. Mêmes workflows, mêmes agents, mêmes modèles. Juste de l'attention.

Pattern 7 : Lancez le rapport DripMeter chaque mois

drip meter --json plus l'action "Save report" de DripMeter produisent un résumé Markdown que vous pouvez balancer dans un point mensuel d'engineering. Avec :

• Total à vie des tokens économisés
• Valeur en dollars au pricing modèle actuel
• Breakdown par agent (quels CLIs portent leur poids)
• Top files (où passe votre budget de lectures)
• Rollup 30j avec moyenne journalière

Partager ça dans un canal Slack maintient l'attention de l'équipe sur le gain. C'est aussi un super document à envoyer à celui qui signe la facture AWS.

Checklist

Auto-audit rapide. Si vous répondez oui à la plupart, votre dépense en tokens est en bonne santé.

• drip est installé et branché aux 3 agents (drip init -g)
• Vous voyez les économies du jour dans DripMeter sans y penser
• Vous avez fixé un objectif quotidien de tokens économisés que vous atteignez souvent
• Vous utilisez Haiku pour les trivialités, Sonnet en défaut, Opus seulement quand nécessaire
• Vous compactez manuellement le contexte avant les longues sessions
• Vous ne demandez plus à l'agent de relire "juste pour vérifier" après un édit
• Vous regardez le ledger de compaction et savez à quelle fréquence vos sessions s'y heurtent
• Vous avez lancé le rapport mensuel d'usage au moins une fois et l'avez sauvegardé quelque part

Quoi de neuf

On travaille sur un serveur MCP Claude Code qui expose les stats DRIP inline (donc vous pouvez demander à Claude "combien j'ai économisé aujourd'hui ?" et il répondra à partir des données locales, zéro réseau). Surveillez le repo DRIP pour ça.

En attendant : installez DRIP, branchez-le, et oubliez-le. Le gain composé.

Pour aller plus loin

• Pourquoi votre agent IA brûle des tokens en relectures
• Le coût caché des relectures : benchmark 8 langages