Graphify testé : un index de graphe de connaissances pour Claude Code
J'ai failli rejeter Graphify comme un énième jouet saveur npx.
Le pitch semblait trop propre : « pointez-le vers n'importe quel dossier, obtenez un graphe de connaissances, interrogez le graphe au lieu de relire les fichiers, regardez votre consommation de tokens s'effondrer. » J'ai un réflexe sain face à tout ce qui promet une réduction d'un ordre de grandeur en une seule commande. La plupart du temps, le calcul tient pour la démo et s'effondre sur une vraie base de code.
Puis je l'ai lancé sur un projet avec lequel je perdais des discussions depuis un mois — un dépôt d'agence avec sept modules d'application, un enchevêtrement de services partagés, et un dossier docs/ que j'évitais silencieusement. La première construction a pris moins de trois minutes sur mon MacBook. Le graphe qu'il a produit m'a révélé quelque chose sur ma propre architecture que j'avais raté pendant six mois — une dépendance circulaire entre la logique de facturation et un service de notification qui n'auraient jamais dû se connaître.
C'est à ce moment que j'ai arrêté de traiter Graphify comme une astuce d'économie de tokens et que j'ai commencé à le traiter comme un outil de revue de code qui, en prime, économise aussi des tokens.
Ce post est ce que j'ai appris en le faisant tourner sur trois vraies bases de code — ce qu'il fait réellement, à quoi l'installation ressemble vraiment, où la mathématique des tokens est honnête, où c'est du marketing, et quels workflows il a changés pour moi. Analyse honnête, pas un communiqué de presse. Si vous êtes un utilisateur de Claude Code qui voit le /cost grimper chaque fois que vous posez une question sur un dépôt inconnu, les vingt prochaines minutes pourraient être la chose la plus utile que vous lirez cette semaine.
Le problème que Graphify résout réellement
Voici le workflow dans lequel la plupart d'entre nous est coincée.
Vous ouvrez Claude Code dans un dépôt que vous ne connaissez pas sur le bout des doigts. Vous posez une question — « où est-ce que ce user_id est validé ? » ou « quels services touchent le module de facturation ? » ou simplement « explique comment cette application est structurée. » Claude commence à lire des fichiers. Il lit le fichier que vous avez mentionné. Puis le fichier que ce fichier importe. Puis le fichier qui importe le fichier qui importe le fichier. Vingt appels d'outil plus tard, vous avez une réponse et une fenêtre de contexte remplie à 70 % avant d'avoir écrit une seule ligne de code.
C'est l'impôt sur les tokens. Chaque conversation le paie. Chaque fois que vous démarrez une nouvelle session, vous le payez à nouveau. Chaque fois que vous compactez le contexte, vous le payez à nouveau. La base de code ne change pas entre mardi et jeudi, mais votre agent la relit de zéro à chaque fois.
La recherche sémantique — grep, ripgrep, embeddings vectoriels — gratte le problème sans le résoudre. grep trouve des chaînes de caractères, pas des concepts. Les embeddings trouvent des paragraphes qui ressemblent à votre requête, pas les relations structurelles que votre code possède réellement. Aucun des deux ne capture la réponse à « quelles fonctions RateLimiter finit-il par appeler, à trois sauts de profondeur ? » parce que cette réponse n'est dans aucun fichier unique. Elle vit dans le graphe entre les fichiers.
Le pari de Graphify est que vous devriez construire ce graphe une fois, le stocker à côté de votre dépôt, et laisser votre agent interroger le graphe au lieu de parcourir le code source à chaque fois. Le graphe fait environ deux mégaoctets de JSON. Votre dossier source peut faire des centaines de mégaoctets. L'agent lit le graphe et ne recourt aux fichiers bruts que quand il a réellement besoin d'écrire ou modifier du code.
Si vous avez fait de la recherche assistée par IA sur de grandes bases de code, vous savez déjà pourquoi ce pari est intéressant. Le reste de ce post traite de savoir s'il est rentable en pratique.
L'idée centrale : un graphe comme index
Avant le guide d'installation, je veux m'assurer que vous avez le bon modèle mental. La plupart des posts sur Graphify sautent cette partie, et c'est la partie qui détermine si l'outil sera utile pour votre dépôt.
Un graphe de connaissances, c'est juste deux choses : des nœuds (les entités — fonctions, classes, modules, sections de documentation, concepts) et des arêtes (les relations — appelle, importe, hérite de, dépend de, référence, est similaire à). Graphify construit les deux de manière déterministe pour le code et sémantiquement pour la documentation.
Pour le code, il utilise tree-sitter pour parser votre source en AST et extraire les relations structurelles sans jamais envoyer un seul token à un LLM. Cette partie est rapide, gratuite et exacte. Tree-sitter sait que la fonction A appelle la fonction B parce que la syntaxe le dit — aucune inférence nécessaire.
Pour la documentation, les PDF, le markdown et les images, Graphify utilise un LLM (au choix — Claude, GPT, Gemini, Kimi, DeepSeek, Ollama en local) pour extraire des entités et inférer des relations. Cette partie est plus lente et coûte des tokens au départ — une seule fois, pendant la construction. Après cela, le graphe persiste. Vous payez le coût d'extraction la première fois et l'amortissez sur chaque requête pendant des semaines.
Ensuite, il exécute la détection de communautés de Leiden sur le graphe combiné. Leiden est un algorithme de clustering qui regroupe les nœuds densément connectés en communautés — en demandant essentiellement « quelles parties de ce graphe traînent ensemble ? » La sortie est la structure modulaire naturelle de votre dépôt, dérivée de la façon dont le code se connecte réellement, pas de la façon dont les dossiers sont organisés par hasard. Parfois ces deux structures concordent. Parfois elles sont en désaccord violent, et ce désaccord est le signal le plus intéressant de toute la construction.
Quand vous interrogez le graphe, votre agent parcourt des arêtes au lieu de lire des fichiers source. « Montre-moi le flux d'authentification » devient une traversée de graphe qui retourne peut-être trois mille tokens de nœuds et d'arêtes structurés, au lieu de cinquante mille tokens de code source brut. C'est la compression. C'est là que vivent les économies.
Le bémol — et nous y reviendrons — est que les requêtes sur le graphe sont excellentes pour lire votre base de code et mauvaises pour y écrire. Quand vous devez modifier du code, vous avez toujours besoin du fichier brut. Graphify ne remplace pas votre dossier source ; il remplace votre exploration de votre dossier source.
Installation : à quoi ça ressemble vraiment en 2026
Le dépôt est sur github.com/safishamsi/graphify. Il y a une particularité à connaître d'emblée : le nom du paquet PyPI est graphifyy avec un double y pendant que le nom original est récupéré, mais la commande CLI reste graphify. Le README est transparent à ce sujet — ne vous laissez pas dérouter.
Graphify nécessite Python 3.10 ou plus récent. Si vous êtes déjà sur un stack moderne, c'est bon. Si vous êtes encore sur 3.9, c'est votre signal pour mettre à jour.
J'installe les outils Python avec uv de nos jours parce que c'est le seul outillage Python qui ne me donne pas envie de tout réécrire en Rust. La commande unique qui vous donne une installation fonctionnelle est :
uv tool install graphifyy
Ça met graphify dans votre PATH automatiquement — pas de jonglage avec les venv, pas de cérémonie pipx. Si vous préférez pipx, ça marche aussi :
pipx install graphifyy
Et si vous aimez vous compliquer la vie avec pip pur :
pip install graphifyy
…vous devrez vous assurer que ~/.local/bin (Linux) ou ~/Library/Python/3.x/bin (Mac) est dans votre PATH, ou l'invoquer en tant que python -m graphify. Je recommande uv ou pipx — il n'y a aucun avantage à se battre avec le PATH pour un outil CLI.
Vérifiez qu'il est là :
graphify --version
Si vous obtenez une chaîne de version en retour, l'installation est terminée. Temps total sur ma machine : moins de trente secondes.
Enregistrer Graphify comme skill Claude Code
C'est la partie qui rend Graphify réellement utile dans votre agent. Le CLI est suffisant. L'enregistrement de la skill est le moment où Claude Code arrête de vous demander de lancer graphify manuellement et commence à l'utiliser de lui-même quand il a besoin d'explorer un dépôt.
Exécutez :
graphify install
Cette unique commande fait trois choses. Elle copie le manifeste de skill spécifique à la plateforme dans ~/.claude/skills/graphify/ pour que Claude Code puisse le découvrir. Elle met à jour (ou crée) le CLAUDE.md de votre projet avec des instructions pour que l'assistant recoure à graphify query avant de se rabattre sur la lecture de fichiers bruts. Et elle enregistre les commandes slash — /graphify query, /graphify path, /graphify explain — que vous invoquerez directement quand vous voudrez piloter les requêtes vous-même.
Si vous utilisez Codex, OpenCode, Cursor, Gemini CLI, ou l'un des dix et plus assistants que Graphify supporte, la même commande graphify install auto-détecte la plupart d'entre eux et écrit le bon manifeste au bon endroit. Le README a une matrice complète. Si vous êtes sur Windows ou voulez être explicite, vous pouvez passer --platform claude ou --platform codex et forcer la cible.
Après avoir lancé graphify install, le bon test de vérification est d'ouvrir Claude Code, taper / et chercher les commandes graphify dans le sélecteur. Si elles sont là, la skill s'est enregistrée correctement. Sinon, vérifiez que ~/.claude/skills/graphify/ existe et contient un SKILL.md — c'est le fichier que Claude Code lit au démarrage.
C'est le même pattern de chargement de skills que j'ai couvert dans mon guide des skills avancées Claude Code, et c'est en train de devenir le pattern d'intégration dominant dans l'écosystème. Les skills, pas les serveurs MCP, sont ce sous quoi la plupart des outils à haute valeur sont livrés en 2026.
Construire votre premier graphe
Maintenant la partie intéressante. Depuis l'intérieur du dépôt que vous voulez indexer, exécutez :
graphify build
C'est tout. Les paramètres par défaut vous donneront un graphe fonctionnel. Graphify scanne le dossier, confie les fichiers de code à tree-sitter pour l'extraction d'AST, confie la documentation et les autres fichiers à votre LLM configuré pour l'extraction sémantique, exécute la détection de communautés de Leiden, et écrit la sortie dans un répertoire graphify-out/.
Mais vous voudrez presque toujours être plus délibéré que les valeurs par défaut. Les flags que j'utilise le plus :
--mode deep— exécute un passage d'extraction sémantique plus agressif sur la documentation et les commentaires. Coûte plus de tokens au départ, trouve plus d'arêtes conceptuelles (celles qui n'apparaissent pas dans l'AST).--update— reconstruction incrémentale. Ne retraite que les fichiers dont le SHA256 a changé depuis la dernière exécution. C'est le flag que vous utiliserez 95 % du temps après la construction initiale.--cluster-only— relance la détection de communautés de Leiden sur le graphe existant sans rien réextraire. Utile quand vous avez ajouté de nouvelles arêtes manuelles ou ajusté les paramètres de clustering et voulez voir l'effet.--no-viz— saute la sortie HTML interactive. Constructions plus rapides, sortie plus légère. À utiliser quand vous avez seulement besoin dugraph.jsonpour un agent et ne voulez pas regarder la visualisation.--watch— maintient Graphify en cours d'exécution et réextrait les fichiers modifiés à la sauvegarde. Je ne l'utilise pas en développement normal parce que je veux un graphe stable, mais c'est utile quand vous remaniez activement l'architecture et voulez voir le clustering évoluer en temps réel.
Pour le dépôt d'agence que j'ai mentionné, la première construction était un graphify build --mode deep et a pris environ deux minutes quarante sur une base de code de dix mille fichiers. Le coût en tokens pour l'extraction sémantique par LLM était modeste — moins d'un dollar de dépense API aux tarifs Sonnet — parce que tree-sitter a géré le gros du travail structurel sans implication du LLM. Les exécutions suivantes de graphify build --update après de petits commits se sont terminées en moins de quinze secondes.
Une note sur le périmètre d'extraction. Graphify supporte les modes code uniquement, code+docs, et multimodal complet (le mode multimodal accède aux PDF, images et même aux transcriptions vidéo si vous avez installé les dépendances optionnelles). Pour un dépôt d'application typique, je reste en code+docs. Le mode multimodal complet est véritablement utile quand votre dossier docs/ contient des diagrammes d'architecture en PNG et que vous voulez en extraire le contenu visuel — mais ça coûte des tokens et du temps, alors ne l'activez que quand vous avez réellement ce type de matériel.
Ce qu'est réellement la sortie
Quand graphify build se termine, vous aurez un répertoire graphify-out/ avec trois fichiers principaux qui comptent :
graph.html — une visualisation interactive que vous ouvrez dans votre navigateur. Les nœuds sont dimensionnés par appartenance à une communauté et connectivité. Les arêtes sont colorées par type de relation. Vous pouvez filtrer par communauté, par type de fichier, par type de relation, et vous pouvez cliquer sur n'importe quel nœud pour voir ses voisins et lire le code source original. C'est le fichier que vous montrez à votre équipe en réunion. C'est aussi le fichier qui a révélé ma dépendance circulaire — je pouvais littéralement voir la boucle dessinée à l'écran.
graph.json — le graphe lisible par machine. C'est ce que votre agent lit quand il répond aux questions. Environ deux mégaoctets pour un dépôt de taille moyenne. Du JSON structuré de nœuds et d'arêtes que n'importe quel outil peut parser. C'est le fichier qui fait le vrai travail d'économie de tokens.
GRAPH_REPORT.md — un rapport d'audit en langage clair. Il liste vos « nœuds divins » (les fichiers hautement connectés qui touchent à tout — généralement un signe d'odeur architecturale), les liens inattendus que le LLM a remarqués et qui n'apparaissent dans aucun fichier unique, et un ensemble de questions suggérées que vous pourriez vouloir poser au graphe. La première fois que j'en ai lu un, c'était comme recevoir les notes d'intégration d'un ingénieur senior sur ma propre base de code.
Il y a aussi un répertoire cache/ avec des hashes SHA256 par fichier. C'est ainsi que --update sait quels fichiers ont réellement changé — c'est un hash de contenu, pas un horodatage, donc les fichiers renommés mais inchangés ne déclenchent pas de réextraction.
Une vraie requête, avec la vraie forme de sortie
La manière la plus propre de montrer ce que donnent les requêtes est d'en exécuter une. Depuis le CLI :
graphify query "qu'est-ce qui connecte la couche d'authentification à la base de données ?"
Ou, si vous avez enregistré la skill, la même chose dans Claude Code :
/graphify query "qu'est-ce qui connecte la couche d'authentification à la base de données ?"
Ce qui revient est un sous-graphe — une réponse structurée listant les nœuds pertinents (le middleware d'authentification, le service de session utilisateur, le pool de connexions, le repository utilisateur) et les arêtes entre eux (quelles fonctions appellent quelles autres, quels modules importent quels autres, quelles docs référencent quel concept). Sur un corpus de cinq cent mille mots, une requête comme celle-là retourne typiquement quelques milliers de tokens, là où lire les mêmes fichiers bruts en aurait coûté des centaines de milliers.
Les deux autres commandes à mémoriser :
graphify path "UserService" "DatabasePool"
Cela retourne le chemin le plus court entre deux entités nommées — la chaîne réelle d'appels de fonctions ou d'importations de modules qui les connecte. C'est la requête qui vous donne l'analyse d'impact gratuitement. « Si je modifie UserService, par quels chemins ce changement se propage-t-il ? » Trois commandes, une réponse.
Et :
graphify explain "RateLimiter"
Cela retourne un résumé en langage clair d'un nœud — ce qu'il fait, ce qui l'appelle, ce qu'il appelle, avec quels concepts il est clusterisé dans la sortie de Leiden. C'est la requête « qu'est-ce que ce truc ». La première chose que je lance quand je suis parachuté dans un dépôt inconnu.
Il y a des patterns de requête plus riches — expansion de voisinage, requêtes à périmètre communautaire, recherche sémantique dans le sous-graphe de docs — et le README les présente. Mais ces trois-là (query, path, explain) sont ceux que j'utilise quotidiennement.
Mises à jour incrémentales : garder le graphe à jour
Le problème de fraîcheur est l'objection évidente : « mon code change tous les jours, je vais devoir reconstruire ce truc chaque matin ? »
Non. Vous allez lancer :
graphify build --update
…et il ne réextraira que les fichiers dont le hash de contenu a changé depuis la dernière construction, les fusionnera dans le graphe existant et relancera le clustering. Sur un dépôt de dix mille fichiers avec une poignée de fichiers modifiés, ça prend des secondes, pas des minutes.
Mieux encore, Graphify peut installer des git hooks qui déclenchent une mise à jour incrémentale automatiquement à chaque commit ou checkout. J'ai ça activé sur mon dépôt de travail principal. Chaque fois que je push, le graphe se met à jour. Chaque fois que je change de branche, le graphe reflète la structure de la nouvelle branche. Je ne pense plus jamais à la fraîcheur.
Si vous avez suivi ma série sur l'optimisation des tokens, vous reconnaîtrez ce pattern : charger le travail coûteux à l'avance, le mettre en cache, et recourir au cache pendant les sessions interactives. Graphify est simplement une implémentation exceptionnellement propre de cette idée.
Extensions à connaître
Quelques flags d'extension poussent Graphify au-delà de « l'outil d'intelligence de code » vers quelque chose de plus intéressant.
--obsidian génère un vault Obsidian complet à partir de votre graphe. Chaque nœud devient une note markdown. Chaque arête devient un backlink. Vous ouvrez Obsidian, vous le pointez vers le vault généré, et vous avez un wiki navigable de votre base de code qui se met à jour chaque fois que vous réextrayez. C'est le workflow qui correspond directement à l'idée du LLM Wiki de Karpathy — j'ai approfondi ce pattern dans mon article sur le RAG Obsidian de Karpathy et Graphify est l'implémentation la plus propre que j'ai utilisée pour des bases de code spécifiquement.
--neo4j exporte un fichier cypher.txt que vous pouvez rejouer dans une instance Neo4j. Si vous construisez un pipeline RAG qui a besoin d'une vraie traversée de graphe — raisonnement multi-saut, chemins pondérés, vraies requêtes Cypher — c'est votre pont. Construisez le graphe avec Graphify, persistez-le dans Neo4j, interrogez-le depuis votre application. Je l'ai utilisé exactement une fois, pour un client qui avait besoin d'un graph store de niveau entreprise, et ça a marché du premier coup.
--mcp démarre Graphify en tant que serveur MCP stdio. Si vous avez une configuration où plusieurs agents doivent partager le même index de graphe, MCP est la bonne frontière — votre graphe devient un service, et tout client compatible MCP peut l'interroger. J'ai couvert la tension plus large entre MCP et skills dans mon article sur la disparition possible du MCP ; le mode MCP de Graphify est l'un des cas où MCP a encore du sens, parce que le graphe est véritablement une ressource partagée.
L'export Obsidian est celui qui m'a le plus surpris. Le graphe devient un artefact navigable — quelque chose que vous lisez, vers lequel vous faites des liens, que vous commitez dans un dépôt wiki. Il cesse d'être une tactique d'optimisation de tokens et devient une documentation qui se maintient toute seule.
La vraie mathématique des tokens
C'est la partie où la plupart des articles se taisent. Laissez-moi être précis.
Le grand chiffre qui circule dans le matériel marketing est « 71,5x moins de tokens par requête. » Ce chiffre est réel — il provient d'un benchmark sur un corpus mixte incluant des PDF, des images et des transcriptions vidéo. Les corpus multimodaux gonflent le comptage de tokens de la base brute de façon dramatique (vous ne lisez pas les PDF à bas prix ; vous payez pour les convertir et reconvertir). La compression que Graphify fournit sur ce type de corpus est véritablement énorme.
Sur un dépôt de code pur — ce qui est ce que la plupart d'entre vous avez réellement — la compression réaliste est plus proche de 5x à 10x pour les requêtes typiques « explore cette base de code ». C'est toujours substantiel. Une requête qui aurait consommé cinquante mille tokens de lectures de fichiers bruts pourrait en consommer cinq à dix mille contre le graphe. Sur le cours d'une journée de travail, c'est de l'argent réel. Sur un mois de travail avec un plan API payant, c'est la différence entre rester sur Sonnet pour tout et se soucier constamment des coûts d'Opus.
Mais les économies ne sont pas uniformes. Voici où Graphify gagne vraiment et où il ne gagne pas.
Là où il gagne beaucoup : L'intégration dans un dépôt que vous n'avez jamais vu. L'analyse d'impact sur un refactoring. Les questions transversales comme « tout endroit où on appelle Stripe ». La revue d'architecture. Tout ce qui implique de comprendre des relations structurelles plutôt que de lire du code spécifique.
Là où il n'aide pas : Écrire du nouveau code. Modifier des fonctions existantes. Débugger un message d'erreur spécifique. Tout ce qui nécessite le contenu source réel, pas le résumé structurel. Pour ces workflows, votre agent doit encore lire les fichiers bruts — le graphe lui dit quels fichiers lire, mais ne remplace pas la lecture elle-même.
C'est la partie sur laquelle je veux insister parce que je vois des gens survendre. Graphify n'est pas un remplaçant de votre base de code. C'est un index sur votre base de code. Les index sont géniaux pour la consultation. Ils ne sont pas la chose que vous éditez. Traitez-le en conséquence et vous en tirerez beaucoup de valeur. Traitez-le comme une solution miracle et vous serez perplexe quand votre session de refactoring brûlera toujours des tokens.
Ce qui a changé dans mon workflow
Après trois semaines d'utilisation sur mes propres dépôts et deux bases de code de clients, voici où Graphify a fini dans ma boîte à outils réelle.
Intégration dans un nouveau dépôt. La première commande sur un clone frais est maintenant graphify build --mode deep. En trois minutes j'ai un graphe et un GRAPH_REPORT.md. Je lis le rapport. J'ouvre le HTML. Je demande à mon agent /graphify explain pour les trois nœuds les plus connectés. Au bout de quinze minutes j'ai un meilleur modèle mental que ce que j'obtiendrais en une heure d'exploration guidée par grep. Ce seul workflow a déjà rentabilisé le temps que j'ai passé à apprendre Graphify.
Audits inter-dépôts. Quand un client demande « est-ce que ce truc utilise vraiment la bibliothèque pour laquelle on paie ? » — je lance Graphify, interroge le graphe pour les points d'entrée principaux de la bibliothèque, et lis la réponse. Avant c'était une revue de code manuelle de quarante minutes. Maintenant c'est cinq minutes.
Analyse d'impact pré-refactoring. Avant de toucher à une fonction que je m'attends à être structurante, je lance graphify path "<nom-de-fonction>" "<chose-distante>" pour voir ce qui dépend de quoi. La sortie du chemin le plus court attrape les dépendances que j'aurais ratées.
Fraîcheur de la documentation. Je génère le vault Obsidian à partir du graphe et je le commite. Les docs sont maintenant un dérivé du code, pas un artefact séparé qui dérive. Quand le code change, le vault change. Quand j'ouvre Obsidian pour écrire un nouvel article, je peux faire des backlinks directement vers les nœuds de la base de code que je décris.
Là où je recours encore à grep. Quand je sais exactement ce que je cherche — une chaîne spécifique, un message d'erreur, une clé de configuration — grep est toujours plus rapide que n'importe quelle requête au graphe. Graphify gagne sa place sur les questions où je ne connais pas encore le bon grep. C'est l'outil de qu'est-ce que je devrais chercher, pas l'outil de je sais déjà ce que je cherche.
Là où je recours encore à un sous-agent. Quand la question est ouverte et créative — « existe-t-il une meilleure architecture pour ça ? » — un sous-agent de planification avec une longue fenêtre de contexte gagne encore. Graphify donne au sous-agent un meilleur contexte de départ (plus petit, plus dense, avec une conscience structurelle), mais le raisonnement doit encore se faire au niveau du modèle.
Cette combinaison — graphe pour la structure, grep pour les chaînes, sous-agents pour le raisonnement — s'est composée d'une façon que je n'attendais pas. Ce ne sont pas des outils concurrents. C'est une pile. Le graphe dit au sous-agent quels fichiers comptent. Grep dit à l'agent où dans ces fichiers chercher. L'agent fait le raisonnement. Chaque couche alimente la suivante.
Si vous voulez le pattern plus large d'empilement d'outils comme celui-ci, mon guide de la pile de skills Claude Code couvre la méta-architecture que j'utilise maintenant par défaut.
Là où Graphify échoue
Je vous dois la liste honnête des modes de défaillance, parce que ceux que j'ai rencontrés ne sont pas théoriques.
Les très petits dépôts n'en ont pas besoin. Si votre base de code tient confortablement dans la fenêtre de contexte de Claude, construire un graphe est exagéré. Le point d'équilibre dans mes tests se situait autour de vingt mille lignes de code ou cinquante documents markdown et plus. Plus petit que ça et le coût de construction dépasse les économies sur les requêtes.
Langages avec une faible couverture tree-sitter. L'extraction structurelle est aussi bonne que la grammaire tree-sitter de votre langage. Les langages courants — Python, TypeScript, JavaScript, Go, Rust, Java, PHP — sont excellents. Les langages plus exotiques peuvent produire des graphes plus fins, avec moins d'arêtes d'appel capturées. Testez avec votre stack avant de vous y fier.
Dépôts lourds en documentation avec de la prose non structurée. L'extraction par LLM pour les docs est sensible à la façon dont la prose est structurée. Des titres propres, des noms d'entités clairs et une terminologie cohérente produisent d'excellents graphes. Les dumps de wiki en flux de conscience produisent des graphes plus bruyants. C'est réparable — restructurez les docs, relancez — mais ce n'est pas de la magie.
Coûts en tokens sur la construction initiale pour de très grands corpus multimodaux. Si vous pointez Graphify vers un dossier de cinquante gigaoctets de PDF et vidéos, la première construction ne sera pas gratuite. Elle sera unique, mais elle ne sera pas gratuite. Planifiez en conséquence. Pour les dépôts de code pur, ce n'est pas un problème.
La précision sémantique dépend du modèle. La qualité des arêtes inférées par LLM dépend du modèle que vous avez configuré. Claude Sonnet, GPT et Gemini produisent tous des résultats solides dans mes tests. Les modèles locaux plus petits produisent des graphes plus fins et bruyants. Il n'y a pas de benchmarks publiés de précision-rappel pour l'extraction sémantique — traitez les arêtes inférées comme des suggestions, pas comme la vérité absolue.
Aucun de ces problèmes n'est rédhibitoire. Tous valent la peine d'être connus avant de miser un workflow sur l'outil.
Devriez-vous l'installer ?
Voici mon arbre de décision, distillé de trois semaines d'utilisation quotidienne.
Installez Graphify aujourd'hui si : Vous êtes un utilisateur de Claude Code, Codex ou Cursor. Vous travaillez sur des bases de code de plus de dix mille lignes. Vous êtes fréquemment parachuté dans des dépôts inconnus. Vous voyez votre consommation de tokens grimper pendant les sessions d'exploration. Vous maintenez un dossier docs/ que vous aimeriez qu'un LLM lise réellement.
Attendez quelques versions si : Vous ne travaillez que sur de petits projets. Votre stack utilise un langage de niche avec une faible couverture tree-sitter. Vous n'avez pas d'environnement local Python 3.10+ et ne voulez pas en configurer un.
Ne l'installez pas si : Vous cherchez un outil magique de refactoring. Graphify n'écrit pas de code. Il ne répare pas votre architecture. Il vous dit ce qu'est votre architecture — ce que vous faites de cette information est toujours de votre ressort.
Pour moi, c'est l'implémentation la plus propre de l'idée de Karpathy selon laquelle « le LLM est le programmeur, le wiki est la base de code » que j'ai utilisée sur du vrai code (pas seulement des notes). Elle se combine naturellement avec la façon dont j'utilise déjà Claude Code, elle survit à l'utilisation quotidienne sans casser, et le mainteneur publie des versions assez rapidement pour que les défauts que je signalerais cette semaine puissent avoir disparu la semaine prochaine.
Le graphe du dépôt par lequel j'ai commencé ce post est maintenant committé à côté du code source. Chaque PR le reconstruit. Chaque document d'intégration le référence. La question « à quoi ressemble cette base de code en fait » qui prenait une heure prend maintenant quatre-vingt-dix secondes. C'est le changement de workflow, et c'est la raison pour laquelle j'écris sur Graphify au lieu de passer à la prochaine nouveauté brillante dans mon fil.
Si vous ne faites qu'une chose après avoir lu ceci : ouvrez un terminal, lancez uv tool install graphifyy, puis graphify install, puis graphify build dans le dépôt que vous évitez silencieusement. Le graphe qu'il construit vous surprendra probablement — et vous embarrassera peut-être, de la manière la plus utile qui soit. C'est le but.
Questions fréquemment posées
Que fait réellement Graphify ?
Graphify convertit un dossier de code, de docs et d'autres fichiers en un graphe de connaissances interrogeable pour que votre assistant IA puisse répondre aux questions sur la structure sans relire les fichiers source bruts. Il utilise tree-sitter pour le parsing déterministe du code et un LLM pour l'extraction sémantique sur les docs, puis clusterise le résultat avec la détection de communautés de Leiden. La sortie est un graph.json que votre agent interroge au lieu de parcourir votre base de code.
Comment installer Graphify sur Claude Code ?
Lancez uv tool install graphifyy (ou pipx install graphifyy) pour installer le CLI, puis graphify install pour l'enregistrer comme skill Claude Code. La commande d'installation écrit le manifeste de skill dans ~/.claude/skills/graphify/ et met à jour le CLAUDE.md pour que Claude Code recoure au graphe avant de parcourir les fichiers bruts. Le temps total d'installation est inférieur à une minute sur une machine moderne.
La réduction de 70x des tokens est-elle réelle ?
Le chiffre de 71,5x est réel mais dépend du corpus — il provient d'un benchmark multimodal mixte avec des PDF et des images gonflant la base brute. Sur des dépôts de code pur, attendez-vous à environ 5x à 10x de compression de tokens sur les requêtes structurelles. C'est toujours substantiel, mais ce n'est pas le chiffre titre. Les économies se concentrent sur les workflows d'exploration et d'intégration, pas sur l'écriture de code.
Graphify remplace-t-il grep ou la recherche vectorielle ?
Non — il les complète. Graphify gagne sur les questions structurelles (« qu'est-ce qui appelle quoi », « chemin le plus court entre deux modules »). Grep gagne toujours quand vous savez exactement quelle chaîne vous cherchez. La recherche vectorielle gagne toujours pour la similarité sémantique floue sur du texte long. La configuration la plus forte empile les trois, avec le graphe comme couche d'index structurel.
Le graphe peut-il rester à jour quand le code change ?
Oui. Lancez graphify build --update pour ne réextraire que les fichiers modifiés (détectés via des hashes SHA256) et les fusionner dans le graphe existant. Vous pouvez aussi installer des git hooks qui déclenchent des mises à jour incrémentales à chaque commit ou checkout, pour que le graphe reste synchronisé avec votre dépôt sans intervention manuelle.
Travaillons ensemble
Vous cherchez à construire des systèmes d'IA, automatiser des workflows ou faire évoluer votre infrastructure technologique ? Ce serait avec plaisir.
- Fiverr (builds & intégrations personnalisés) : fiverr.com/s/EgxYmWD
- Portfolio : mejba.me
- Ramlit Limited (solutions entreprise) : ramlit.com
- ColorPark (design & branding) : colorpark.io
- xCyberSecurity (services de sécurité) : xcybersecurity.io
