Le coût caché des relectures : un benchmark sur 8 langages
Nous avons mesuré DRIP sur des bases de code en conditions réelles, dans 8 langages. Voici le détail des économies, la méthodologie, et ce qui nous a surpris sur le comportement de la compression Java vs Python.
Quand nous avons sorti les premières chiffres de DRIP — "34 à 88 % de tokens en moins" — trois personnes ont posé la même question : sur quoi ?
Légitime. Donc on a fait les benchmarks publiquement. Voici le détail.
La méthodologie, en 60 secondes
Des fixtures en conditions réelles, ça veut dire : des fichiers open-source réels de taille refactor typique, pas les petits snippets jouets qu'on voit dans la plupart des benchmarks. On a tiré 45 échantillons effectifs sur 8 langages (Python, TypeScript, Java, Go, Rust, Ruby, C++, C#), warmé le runner pour éliminer le bruit JIT, et mesuré la latence p99 en parallèle des comptages de tokens.
Les chiffres ci-dessous sont la médiane sur 45 échantillons par cellule. Les chiffres p99 et les données complètes sont dans bench/source-map/ du repo DRIP.
Économies à la première lecture (compression sémantique)
DRIP reconnaît les corps de fonction dans 13 langages et les élide à la première lecture, en conservant signatures, imports, déclarations de types, doc comments et corps de classes. L'agent obtient la forme du fichier. S'il a besoin d'un corps de fonction spécifique, il le demande — et cette re-lecture renvoie le corps complet.
| Langage | Taille | Tokens natifs | DRIP 1re lecture | Économies |
|---|---|---|---|---|
| Python (651 ln) | 24 KB | 6 005 | 2 403 | 60 % |
| Java (1 210 ln) | 38 KB | 9 800 | 2 950 | 70 % |
| TypeScript (820 ln) | 31 KB | 7 600 | 2 420 | 68 % |
| Go (440 ln) | 14 KB | 3 820 | 1 612 | 58 % |
| Rust (590 ln) | 21 KB | 5 210 | 2 008 | 61 % |
Java se comprime le mieux parce que les fichiers Java sont en grande partie du boilerplate (modificateurs de visibilité, getters/setters, @Override) — gros ratio signal/bruit pour l'élision sémantique.
Économies aux relectures (moteur de delta)
C'est là que les gros chiffres apparaissent. Sur un cycle refactor à 5 édits :
| Fichier | Re-reads natifs | Re-reads DRIP | Économies |
|---|---|---|---|
| 130 KB, 30 reads | 180 000 tok | 12 400 tok | 93 % |
| 38 KB, 20 reads + 3 édits | 196 000 tok | 18 900 tok | 90 % |
| 24 KB, 15 reads | 90 000 tok | 6 540 tok | 93 % |
Le pattern : plus la session s'allonge, plus les économies montent — parce que le coût proportionnel des sentinels [unchanged] (~12 tokens chacun) et des payloads delta (200-400 tokens) reste stable, tandis que les re-reads natifs scalent linéairement avec la taille du fichier.
Ce qui nous a surpris
Python a les plus petits gains sur la compression sémantique
La syntaxe terse de Python (pas d'accolades, typage optionnel) fait que les corps de fonction ne sont pas tellement plus gros que leurs signatures. Java, à l'inverse, a 30 à 50 % de son volume occupé par du boilerplate — donc élider les corps tape plus fort.
TypeScript a profité davantage du moteur de delta que de la compression sémantique
Les fichiers TypeScript ont tendance à être édités bien plus souvent que les fichiers Python dans nos sessions de test (plus de travail de refactor sur TS en 2026). Donc la majorité du gain est venue du moteur de delta, pas du compresseur de première lecture.
Les fichiers Rust ont eu des résultats mixtes à cause des macros
Les macros sous forme de fonction (println!, vec!, bail!) rendent la détection de corps plus difficile. On a un chemin spécifique pour elles — les corps s'étendent beaucoup, les signatures restent petites — mais l'heuristique est conservatrice. On préfère rater une compression que d'émettre une élision incorrecte.
Les certificats d'édition ont dépassé nos attentes
On pensait que les certificats d'édition (le payload de 390 octets hash + lignes touchées renvoyé sur une lecture-après-édit) économiseraient 5 à 10 % des tokens totaux. En pratique ils économisent 12 à 18 %, parce que les agents vérifient leurs propres écritures bien plus souvent que la doc ne le laisse entendre.
Qu'est-ce que ça veut dire pour votre facture ?
Si vous payez Claude Sonnet 4.6 (le défaut le plus courant à 3,00 $/Mtok input) :
- Une session refactor solo-dev typique brûle 200K à 500K tokens en entrée.
- DRIP coupe ça à 40K-80K.
- À 3,00 $/Mtok, ça fait 0,45 à 1,20 $ économisés par session.
Sur une équipe de 10 développeurs faisant 6 sessions/jour, on parle de 1 800 à 4 800 $/mois d'économies sur les tokens en entrée. Le calcul devient plus impressionnant sur Opus 4.7 (15 $/Mtok input) — mêmes tokens, 5× la valeur en dollars.
Comment reproduire
Cloner DRIP, lancer bash scripts/bench_multilang.sh. Les chiffres arrivent dans bench/results/. Adaptez les fixtures à la forme de votre codebase ; la méthodologie reste la même.