Graft : un graphe de code en markdown pour vos agents de codage

Le coût que Graft prétend supprimer

Le README part d'un constat simple : un agent de codage redécouvre le dépôt à chaque tâche. Il lance un grep, ouvre un fichier, suit un import, revient en arrière, recommence. Ce que l'agent avait compris de l'architecture une heure plus tôt disparaît avec la session. Le projet résume la situation en une phrase : les humains s'intègrent à une base de code une fois, les agents s'y intègrent à chaque fois. Le public visé est donc précis : équipes qui font tourner Claude Code sur un dépôt suffisamment gros pour que l'exploration initiale pèse sur le temps et le coût de chaque tâche. Sur un petit projet, cette exploration est courte et le problème n'existe pas vraiment.

Une carte en fichiers markdown plutôt qu'un index vectoriel

Graft construit une fois la compréhension du dépôt et l'écrit sous forme de fichiers markdown liés, un node par système, API ou concept. Le README insiste sur deux choix. D'abord, chaque node contient une explication en langage naturel de ce que fait une partie du système et de ses liens avec le reste, pas une liste de symboles. Ensuite, le graphe n'est ni un jeu d'embeddings ni un index de similarité : c'est un ensemble de fichiers que l'agent ouvre, grep et suit comme n'importe quel autre fichier du dépôt. La construction s'appuie sur tree-sitter, d'après les topics du dépôt, ce qui suppose une analyse syntaxique par langage plutôt qu'une inférence statistique. Le graphe vit dans un dossier graft/ ajouté automatiquement au .gitignore par graft build, décrit comme un cache local régénérable comparable à node_modules.

Installation et câblage dans l'agent

Deux commandes suffisent selon le README : npm install -g @nanonets/graft puis graft init. La seconde demande quels agents câbler, construit graft/ à partir du code et dépose une statusline ainsi que des hooks dans .claude/. Rien n'est écrit avant votre choix : graft init --dry-run affiche les fichiers qui seraient touchés, et graft init --agents claude saute la question pour ne câbler que Claude Code. npx @nanonets/graft init fonctionne sans installation globale. Ce qui se partage entre coéquipiers n'est pas le graphe mais le câblage : git add .claude && git commit -m "wire in graft", chaque personne régénérant ensuite son propre graft/ avec graft build. Le README mentionne aussi un serveur MCP et une intégration dite profonde avec Claude Code, sans détailler dans l'extrait fourni les outils exposés par ce serveur.

Ce que le tableau de performance ne dit pas

Le README affiche un tableau comparant Claude Code seul à Claude Code avec Graft : réduction des appels d'outils de 46 pour cent, économie de tokens de 42 pour cent, gain de temps de 60 pour cent, et exactitude passant de 54 à 66 pour cent. Ces chiffres viennent de l'éditeur, pas d'une évaluation indépendante, et le matériel fourni ne précise ni protocole, ni jeu de tâches, ni modèle utilisé. Le titre annonce jusqu'à 4 fois moins cher et 3 fois plus rapide, ce qui ne correspond pas directement aux colonnes du tableau : l'écart entre le slogan et les mesures mérite d'être noté. La section SWE-bench Verified est référencée dans la table des matières mais son contenu n'est pas fourni ici, donc impossible de vérifier la méthodologie. Traitez ces nombres comme une hypothèse à tester sur votre dépôt, pas comme un résultat reproductible.

Les limites visibles dans la documentation

La première limite est structurelle : Graft ne sert à rien si votre agent n'est pas câblé. Le README cite Claude Code, Cursor, Codex et Gemini, mais la seule intégration décrite en détail est celle de Claude Code, avec statusline et hooks. Pour les autres, la documentation reste à un niveau d'intention. Deuxième point, le graphe est régénéré en arrière-plan après chaque tour selon le README, ce qui consomme du CPU local et suppose que la qualité des nodes suive les modifications du code. Un node obsolète est pire qu'une absence de node, parce que l'agent s'y fiera. Enfin, le projet revendique un usage au-delà du code via un fichier de compétences qui apprend des tâches passées, mais cette partie n'est pas décrite dans l'extrait et ressemble davantage à une promesse qu'à un mécanisme vérifiable.

Face à un index sémantique classique

L'alternative la plus directe est un serveur d'indexation sémantique adossé à des embeddings, du type de ceux qui exposent une recherche par similarité sur le code. La différence de conception est nette : un index vectoriel doit être maintenu à jour, occupe un stockage dédié et renvoie des extraits classés par proximité, que l'agent doit ensuite interpréter. Graft renvoie des fichiers markdown que l'agent lit et suit comme le reste du dépôt, sans embeddings ni index à garder chaud. En contrepartie, la pertinence dépend de la qualité rédactionnelle des nodes, pas d'un score de similarité, et il n'existe pas de recherche floue pour retrouver un concept mal nommé. Un index vectoriel pardonnera une requête approximative là où Graft exigera que le graphe ait déjà nommé la bonne notion.

Licence, maintenance et coût de mise à jour

Le dépôt est publié sous licence MIT, ce qui autorise l'usage commercial, la modification et la redistribution, avec conservation du texte de licence. Le README signale une télémétrie anonyme et désactivable via TELEMETRY.md : c'est un point à trancher avant un déploiement en entreprise, pas après. Sur la maintenance, le dernier push daté du 9 septembre 2026 et l'absence de releases récupérées ne permettent pas de juger le rythme de publication. Le coût récurrent se limite, d'après le matériel, à relancer graft build après des changements de structure et à committer les évolutions du dossier .claude. Aucun daemon n'est à superviser selon le README, ce qui réduit la charge opérationnelle, mais déplace la question vers la fraîcheur du graphe.

Conclusion éditoriale

Graft vise les équipes qui font tourner Claude Code sur un dépôt volumineux et qui acceptent de versionner la configuration .claude plutôt qu'un index. Si votre dépôt tient dans quelques centaines de fichiers, ou si vous travaillez avec un agent que init ne câble pas encore, l'outil n'apporte rien que la recherche native ne fasse déjà. Avant d'adopter, lancez graft init --dry-run pour lister les fichiers touchés, puis vérifiez ce que graft/ contient réellement sur votre code : c'est la qualité de ces nodes, pas le tableau de performance du README, qui décidera si votre agent s'oriente mieux ou plus mal.

Sources officielles

1. Issues
2. License: MIT
3. Project website
4. README
5. trailhq/Graft on GitHub