Un lab de Red Hat sort un outil qui promet de ramener la facture de contexte d'un agent de code à 5 % du prix habituel. Un binaire déterministe, zéro embeddings, zéro serveur. 801 étoiles en six semaines. Et pourtant : huit points sur Hacker News, trois commentaires, tous sceptiques. On a regardé de près.
Un binaire qui répond en 0,2 seconde
Le constat de départ n'a rien de neuf. Les agents de code lisent les dépôts à l'aveugle. Ils ouvrent des fichiers, en ouvrent d'autres, dépensent des tokens par dizaines de milliers pour comprendre où se trouve le code qui compte. La semaine dernière, Hacker News n'a parlé que de ça : « reading code is expensive » le 2 septembre, « grep beat LSP » le 4, « agent optimized codebases » le 7.
ripwire prétend avoir la réponse. Un CLI en C++23, zéro dépendance runtime, qui parse n'importe quel dépôt et en sort une « carte » : les symboles pertinents, leurs appelants, le rayon de casse d'une modification, les tests à lancer. Le tout sans embeddings, sans clé API, sans daemon, hors ligne. La promesse tient en une phrase reprise partout : « the ripgrep of AI context ». Le ripgrep du contexte IA.
Le truc a été balancé le 29 juillet 2026 sous l'org GitHub redhat-et, Red Hat Emerging Technologies. Six semaines plus tard, v0.4.0 sort le matin même du post Hacker News. 801 étoiles au compteur. 31 forks. Cinq issues ouvertes. Licence Apache-2.0.
Et une démo qui claque : réponse à froid en 0,213 seconde, requête chaude médiane à 197 millisecondes, index de 6,6 à 16,5 Mo. Quand le concurrent repowise met 34 secondes à indexer avant de répondre, et jusqu'à 352 secondes dans le pire des cas, le contraste pique les yeux.
La carte au lieu de la lecture à l'aveugle
L'idée, c'est de ne plus faire lire le dépôt entier à l'agent. On lui donne la carte, il va direct au bon endroit.
Concrètement, ripwire vend 31 verbes. Seize pour lire, douze pour les « réflexes » du quotidien, trois pour éditer. --callers pour savoir qui appelle un symbole, --impact pour mesurer le rayon de casse d'un refactor, --from-trace pour remonter une stack trace, --recall pour retrouver ce que la doc disait, --safe-delete pour savoir si on peut virer un symbole sans tout casser. Dix-huit skills prêts à installer pour Claude Code, Codex, Cursor, Windsurf, Gemini, opencode, aider.
La mécanique interne est un graphe d'appels déterministe, pas un modèle de langage. Vingt et une grammaires tree-sitter vendées dans le binaire : C, C++, Python, TypeScript, Java, Rust, Go, Ruby, PHP, et le reste. Pas 158 langages comme le concurrent, 21. Et l'auteur le dit.
C'est là que ripwire devient intéressant, parce qu'il refuse de mentir. Chaque réponse porte un niveau de confiance, high ou low, avec la marge. Les arêtes d'appel incertaines sont dessinées en pointillés dans le graphe. Quand une troncature coupe une partie du résultat, c'est déclaré noir sur blanc. Et quand un --pattern ne résout rien, le binaire sort en code d'erreur 1 au lieu de renvoyer un placide hits=0. Le genre de détail qu'on ne voit presque jamais.
Des chiffres à faire pâlir un data scientist
Le README de 1 780 lignes est un festival de mesures. On ne peut pas lui reprocher de cacher ses cartes.
Le claim principal : ripwire répond avec environ 4 300 tokens quand un agent en aurait brûlé 40 000 à 300 000 en mode grep-puis-lire. Globalement, 5 % des tokens d'un passage classique. Sur les dix « moments quotidiens » mesurés par l'auteur sur son propre repo, l'économie va de 2,3× à 670×.
Commande | Tokens ripwire | Tokens grep-and-read | Économie |
`--callers` | ~580 | 40 000–52 000 | 69×–89× |
`--from-trace` | ~1 400 | 124 000–298 000 | 87×–209× |
`--recall` | ~15 000 | ~445 000 | 29× |
Et côté précision, le benchmark maison LocBench Round 4, sur 60 instances Python appariées : 58,3 % de localisation stricte du bon fichier, contre 40 % pour codebase-memory-mcp, le leader du segment. repowise à 33,3 %, graphify à 31,7 %, Aider repo-map à 20 %, codeseek à 15 %.
Sur 243 instances et 78 dépôts, l'auteur annonce 60,9 % contre 27,6 % pour sa propre baseline. Face au serveur de graphe de codebase-memory-mcp, 27 victoires, 7 défaites, 14 égalités sur 48 questions, avec 77 000 tokens dépensés contre 486 000.
Bref, sur le papier, ça écrase tout.
Le hic : tout est mesuré par l'auteur lui-même
Voilà où il faut respirer.
Tous ces chiffres, sans exception, sortent du labo de l'auteur. Les 5 % de tokens, les 58,3 %, les 197 millisecondes, les 670× : des auto-mesures. Sur son propre repo, ou sur des tranches choisies de 60 instances Python-dominant. Pas un seul test tiers indépendant à ce jour.
Ce n'est pas de la triche. C'est même le contraire, et c'est ce qui rend le dossier compliqué à trancher. La transparence est à peu près inédite dans ce segment : la méthode est publiée, le harness de benchmark est commité et ré-exécutable, les contre-exemples sont dans le README, et l'auteur s'auto-corrige à la baisse. Il a ramené sa marge de 1,75× à 1,46× quand deux tableaux de dates différentes la gonflaient. Il a re-testé codebase-memory-mcp et l'a re-crédité de 26,7 % à 40 %. Il écrit noir sur blanc que la recherche sémantique du concurrent « n'est pas à la maison » chez lui. Qui fait ça ?
Mais la règle reste : des chiffres auto-mesurés, même honnêtement, ça n'est pas une validation. Surtout quand la réception communautaire est ce qu'elle est.
Le post Hacker News du 7 septembre affiche huit points et trois commentaires après douze heures. Pour un projet à 800 étoiles, c'est un bide. Les trois commentaires, vérifiés via l'API Algolia, donnent le ton. kamiheku : « What on earth does this mean? », sur le visuel d'accueil. cityofdelusion : « A bunch of sections of the README are nonsensical as well. I'll just file this under "magical token-saving project #481 of 2026 that probably performs worse than the harness" for now. » Et Havoc : « Readme is very AI. Still will see what inspiration I can take from this. »
Le « très IA » revient comme un boomerang. Un outil qui promet d'aider les agents à naviguer les dépôts, dont le README sent l'agent à plein nez. L'ironie n'échappe à personne, sauf peut-être à l'auteur.
Red Hat, vraiment ?
Parlons de la bannière.
L'org GitHub s'appelle redhat-et. Le copyright de la licence dit « 2026 David Brewster ». Mais aucun article, aucun communiqué officiel Red Hat ne mentionne ripwire. Le lien avec la maison mère passe uniquement par l'org GitHub, ce labo qui héberge aussi harbor, un framework d'évaluation d'agents, et skillimage, un registre OCI de skills.
La réalité est plus prosaïque : 1 811 des 1 817 commits viennent d'un seul compte, joyful-ii-V-I, un pseudonyme créé en mai 2025. Les six autres commits sont signés « claude ». David Brewster, l'identité du copyright, n'est confirmée nulle part publiquement.
Traduisons. Ce n'est pas « Red Hat sort un outil ». C'est un développeur, probablement affilié au lab Emerging Technologies d'une façon ou d'une autre, qui a poussé 1 811 commits en six semaines, des dizaines certains jours, avec l'aide assumée d'un agent de codage. Le repo embarque d'ailleurs ses propres prompts d'orchestration, « written so a coding agent can run them ». Il s'en sert pour développer ripwire lui-même. Du dogfooding intégral.
C'est une force et une fragilité à la fois. La cadence est impressionnante, mais un projet aussi rapide qui repose sur un seul compte pseudonyme peut mourir du jour au lendemain. Si le type part, le truc s'arrête. Et la v0.4.0, sortie le jour du post, contenait encore un correctif d'install parce que « the upgrade path left a binary that could not run ». À six semaines d'âge, c'est mûr comme un avocat de supermarché.
La guerre des cartes de repo
ripwire n'arrive pas dans le vide. Le segment est en train de se structurer, vite.
En face, codebase-memory-mcp revendique 42 490 étoiles, une base graphe persistante, « 158 languages, sub-ms queries, 99 % fewer tokens ». repowise, 6 368 étoiles. Et aider, le pair-programmeur à 48 807 étoiles, embarque sa propre repo-map depuis longtemps.
Les deux approches s'opposent frontalement. D'un côté, le graphe de connaissance persistant, les embeddings, le daemon. De l'autre, le binaire déterministe hors ligne qui indexe en 0,31 seconde et ne garde rien en mémoire. ripwire parie que les agents n'ont besoin que d'un shell et d'une réponse déterministe, pas d'une base de données qui pèse 391 Mo d'index.
Le pari a une logique. Le coût en est une recherche « conceptuelle » limitée à ce que la syntaxe permet : pas de sémantique réelle, pas de dispatch dynamique résolu en PHP ou en Lua, pas de graphe d'appels au-delà du statique. L'auteur l'assume, encore une fois, en publiant ses planchers.
Le vrai signal, c'est celui-là : donner aux agents une carte de repo devient un produit. Le maillon qui manquait — naviguer sans tout lire — se transforme en marché, avec un lab Red Hat qui y met les pieds. Ou un type sous une bannière Red Hat, selon la lecture.
Verdict
Alors, faut-il y croire ?
À moitié. Et c'est déjà pas mal.
Ce qui est vrai : l'approche est saine. Un outil déterministe, hors ligne, qui refuse de mentir et publie ses marges d'incertitude, c'est exactement ce dont les agents de code ont besoin quand on les laisse se balader dans un dépôt qu'ils ne connaissent pas. La culture de la mesure de ripwire, avec ses auto-corrections à la baisse et ses contre-exemples assumés, est rare au point d'être suspecte de premier abord. On la prend quand elle passe.
Ce qui est faux : les 95 % de tokens en moins, les 670×, les 58,3 %. Tant que personne d'indépendant n'a rejoué le benchmark sur un dépôt qui n'est pas celui de l'auteur, ces chiffres restent des promesses. Et une promesse auto-mesurée, même honnête, ça ne vaut pas une validation. Hacker News l'a compris en trois commentaires.
Le vrai problème de ripwire n'est pas technique. C'est que son README de 1 780 lignes, hyper-dense, auto-référentiel, truffé de figures, ressemble exactement au genre de prose qu'un agent produit. L'outil qui prétend aider à lire les dépôts écrit son propre mode d'emploi comme un robot. C'est le genre de détail qui tue la crédibilité avant même qu'on ait lancé un benchmark.
Allez-y quand même. Installez-le, pointez-le sur votre codebase, mesurez vous-même. C'est précisément ce que l'auteur demande, noir sur blanc : « Your corpus is one we don't. » Rapportez ce que l'outil rate sur votre code. Pour une fois, un projet vous encourage à le prendre en défaut.
On ne sait pas encore si ripwire est le ripgrep du contexte IA. Mais si la question est de savoir si on peut faire confiance à un binaire qui refuse de mentir plutôt qu'à un README qui raconte tout, la réponse est déjà là.
Sources
- GitHub — redhat-et/ripwire — repo officiel (métadonnées API : 801 étoiles, licence Apache-2.0, dates, contributeurs)
- README complet — claims chiffrés, tables LocBench et tokens, contrats d'honnêteté, verbes MCP, langages
- Releases ripwire — v0.4.0 du 07/09/2026, série v0.3.x des 12-13/08
- Post Hacker News — 8 points, 3 commentaires sceptiques (vérifiés via API Algolia)
- GitHub — DeusData/codebase-memory-mcp — concurrent principal (42 490 étoiles, « 158 languages, 99 % fewer tokens »)
- GitHub — Aider-AI/aider — pair-programmeur (48 807 étoiles) dont la repo-map est testée dans le benchmark
- GitHub — BurntSushi/ripgrep — référence du nom « ripgrep of AI context »
- SemiWiki — LocBench — origine du benchmark de localisation de code
✦ Idée d'illustration : un immense plan de métro néobrutaliste, mais les stations sont des symboles de code (main(), struct User, handle_error) reliés par des lignes colorées qui dessinent le graphe d'appels d'un dépôt. Au centre, un petit agent robot filiforme tient une carte pliée et lève un doigt pour demander son chemin, pendant que derrière lui, en arrière-plan flou, des étagères de classeurs géants (les fichiers du repo) restent fermées. Une seule tache de couleur chaude, rouge ou orange, sur le robot. Tons gris, bleu nuit, blanc cassé. Style éditorial, grain léger, aucun texte lisible.
