ripwire : un graphe d'appels déterministe pour agents de codage, sans serveur ni clé API

Le problème : un agent qui grep et relit des fichiers entiers

Un agent de codage à qui l'on demande de modifier une fonction commence souvent par chercher le nom de cette fonction, puis lit le fichier, puis cherche ses appelants, puis lit d'autres fichiers. Chaque étape consomme des tokens et le résultat reste partiel. ripwire part d'un constat simple énoncé dans le README : un appel suivi de trois grep revient à payer deux fois la même recherche. L'outil vise ce que le README appelle la terminalité, c'est-à-dire une réponse qui contient tout ce qu'il faut pour agir sans relance. Le public visé est précis : les développeurs qui utilisent Claude Code, Codex, Cursor, Windsurf, Gemini, opencode ou aider sur des dépôts assez gros pour que la lecture exhaustive coûte cher. Ce n'est pas un outil d'analyse statique pour humain, ni un linter. C'est une couche de contexte destinée à une machine.

Un binaire unique qui construit un graphe d'appels classé

L'architecture tient en une phrase du README : un seul processus, pas de serveur, pas de démon, pas d'embeddings, pas de clé API. Le binaire parcourt le dépôt, s'appuie sur tree-sitter pour l'analyse syntaxique (le sujet figure dans les topics du dépôt) et produit un graphe d'appels classé et déterministe. La sortie répond à trois questions selon la description du projet : quoi toucher, ce que la modification casse, et quels tests lancer. Le README parle de blast radius, de tests-to-run et de quality deltas. Deux propriétés sont mises en avant comme des principes de conception. D'abord l'honnêteté des limites : un comptage qui ne peut pas être un total est étiqueté comme plancher, un zéro signifie aucun résultat trouvé et jamais aucune existence, et toute troncature est signalée. Ensuite le budget de tokens : une réponse peut recevoir une limite de taille, et si une réponse complète ne rentre pas, l'outil le dit au lieu de supprimer silencieusement la ligne utile. Le README affirme aussi que les signatures occupent 74,7 pour cent de bytes en moins que les corps de fonction, ce qui est la base de l'économie annoncée.

Installation et première requête

L'installation tient en une ligne, donnée telle quelle dans le README. La variable RIPWIRE_REPO est passée au script d'installation, puis le chemin est ajouté manuellement car l'installateur l'imprime seulement si besoin. Ensuite, depuis le dépôt à analyser, on lance ripwire avec un point et une option --for qui décrit en langage naturel la modification envisagée. Le README insiste sur un point d'usage : la CLI est l'interface la moins coûteuse, et le serveur MCP est une seconde interface optionnelle. La raison avancée est concrète. Les schémas de verbes du serveur MCP occupent de l'espace dans le contexte de l'agent à chaque session, que l'agent les appelle ou non. C'est un argument que l'on voit rarement formulé aussi directement, et il est cohérent avec l'objectif d'économie de tokens. La même ligne d'installation active aussi les skills, c'est-à-dire des compétences qui apprennent à l'agent quand utiliser l'outil, pas seulement comment l'appeler, pour chaque agent détecté sur la machine.

Les limites que le README annonce lui-même

Le projet revendique de publier ses pertes, y compris un résultat de recherche récent qui a échoué lors de son test. C'est un bon réflexe, mais il ne dispense pas de lire les chiffres avec prudence. Les performances annoncées, 0,25 seconde d'indexation et 6,6 Mo de mémoire contre 46,8 secondes et 391 Mo pour un serveur MCP concurrent, proviennent d'une mesure sur 48 questions appariées sur django, webpack et le dépôt lui-même. Ce sont des chiffres du projet, pas des chiffres reproduits ici. Le README indique lui-même que la méthode complète et les pertes figurent dans docs/EVALS.md, ce qui est l'endroit à consulter avant de citer ces nombres. Autre point : la liste de langages est large (Rust, C++, Python, Go, Swift, TypeScript, Java, Ruby, PHP, Lua, Elixir, Bash, C# et d'autres) mais le README renvoie à une section sur les limites de support, et une analyse par tree-sitter ne donne pas la même profondeur selon les grammaires disponibles. Enfin, l'absence de service hébergé signifie que rien n'est partagé entre machines : chaque poste indexe son propre dépôt.

Ce que le projet ne documente pas clairement

La documentation disponible est généreuse sur la philosophie et avare sur certains détails d'exploitation. On sait qu'un budget de tokens existe, mais aucun nom de clé de configuration n'apparaît dans le matériel fourni. On sait que les skills sont installés pour chaque agent détecté, mais le README ne détaille pas ce qui se passe si un agent est installé après ripwire, ni comment désinstaller proprement ces skills. Le graphe d'appels est décrit comme déterministe et classé, sans que le critère de classement soit explicité dans les extraits disponibles. Ce ne sont pas des défauts rédhibitoires, mais ce sont exactement les questions qu'un ingénieur se pose avant de mettre l'outil dans une chaîne d'intégration. Il faut donc les vérifier dans le dépôt plutôt que dans la page d'accueil. Un lecteur qui cherche une référence de configuration complète devra aller voir le code ou les tests.

Face à un serveur MCP adossé à une base de graphes

L'alternative la plus directement comparable est le serveur MCP de contexte de code adossé à une base de graphes, que le README prend explicitement comme point de mesure. La différence d'approche est nette. Ce type de serveur construit un graphe persistant dans une base, ce qui permet des requêtes riches et des traversées complexes, mais impose un processus serveur, une base à maintenir et une empreinte mémoire bien plus élevée. ripwire refuse l'index persistant et reconstruit tout à chaque invocation, ce qui explique les temps d'indexation annoncés et supprime toute question de cohérence d'index. Le compromis est réel : sans index persistant, les requêtes répétées dans une même session ne bénéficient pas d'un cache partagé entre processus, et l'outil ne peut pas offrir les traversées profondes d'une base de graphes. Pour un agent qui pose quelques questions par tâche sur un dépôt de taille moyenne, l'échange semble favorable. Pour une analyse de graphe étendue sur un monorepo, la base de graphes garde l'avantage.

Coût de maintenance et licence

Le projet est publié sous Apache-2.0, ce qui autorise l'usage commercial, la modification et la redistribution, avec les obligations habituelles de conservation de la licence et des mentions, et une clause de brevets. Je ne donne pas de conseil juridique : faites relire le fichier LICENSE et THIRD_PARTY.md par qui de droit si l'intégration est sensible. Le README affiche zéro dépendance à l'exécution et renvoie à THIRD_PARTY.md pour le détail, ce qui réduit la surface de mise à jour côté binaire. En revanche, exiger C++23 pour compiler depuis les sources restreint les environnements de build, et c'est le principal coût caché si vous ne vous contentez pas du binaire précompilé. Le rythme de publication observé est rapide : trois versions entre le 13 août et le 8 septembre 2026, avec des correctifs rapprochés. Un rythme soutenu signifie des mises à jour fréquentes à suivre, et un risque de changement de comportement plus élevé qu'avec un outil stable depuis des années.

Conclusion éditoriale

ripwire convient aux équipes qui font tourner des agents de codage sur de gros dépôts et qui veulent réduire le nombre de lectures de fichiers complètes, à condition d'accepter un binaire compilé en C++23 et de vérifier soi-même les chiffres avancés. Il ne convient pas à qui cherche un service hébergé, une analyse sémantique profonde ou un support de langage garanti au-delà de ce que le README liste. Avant d'adopter, lancer ripwire . --for="..." sur votre propre dépôt et comparer la sortie à ce que votre agent produit aujourd'hui, puis lire docs/EVALS.md et docs/LINEAGE.md pour juger la méthode plutôt que les chiffres.

Sources officielles

1. Issues
2. License: Apache-2.0
3. README
4. redhat-et/ripwire on GitHub
5. Releases