Graphify : un graphe de connaissances de votre code, ça vaut le coup ?

Chaque session de code avec une IA commence de la même façon. L’assistant lance un grep, ouvre des fichiers, relance un grep, et reconstruit lentement une image du projet qu’il avait déjà construite la veille avant de la jeter. Graphify est l’une des tentatives les plus populaires pour régler ça : construire une carte du projet une fois, puis laisser l’assistant interroger la carte au lieu de relire le code.

C’est devenu l’un des outils IA à la plus forte croissance de l’année, alors je voulais une réponse claire à une question simple : est-ce que ça vaut vraiment le coup de l’ajouter à mon workflow ?

Version courte : oui pour les documents et les notes, beaucoup moins pour les questions de code du quotidien. Voici pourquoi.

D’où vient Graphify

Le 1er avril 2026, Andrej Karpathy a décrit son workflow de connaissances personnel : déposer articles, notes et captures d’écran dans un dossier, laisser un LLM les compiler en wiki, et le parcourir dans Obsidian. L’idée s’est vite répandue, et en deux jours environ, Safi Shamsi a sorti Graphify, un outil qui pousse la même idée plus loin en transformant un dossier en vrai graphe plutôt qu’en wiki à plat.

Depuis, le projet est passé sous Graphify Labs, a rejoint Y Combinator et a récolté des dizaines de milliers d’étoiles sur GitHub.

Ce qu’il fait vraiment

Graphify est un paquet Python (graphifyy sur PyPI, avec deux y), accompagné d’un skill /graphify pour votre assistant IA et d’un serveur MCP.

uv tool install graphifyy   # ou : pipx install graphifyy
graphify install            # enregistre le skill auprès de votre assistant

Ensuite, dans Claude Code, Cursor, Codex, Gemini CLI ou l’un des autres assistants pris en charge :

/graphify .

Sous le capot, il construit le graphe en deux couches :

• Le code est analysé localement avec Tree-sitter. Fonctions, classes, imports, appels et héritage viennent directement de l’arbre syntaxique. Pas de LLM, pas de clé d’API, et la même entrée donne toujours le même graphe.
• Tout le reste (Markdown, commentaires, PDF, diagrammes, images, et même transcriptions de vidéos) passe par un LLM qui extrait les concepts et les relations entre eux.

Le résultat est fusionné en un seul graphe, regroupé en communautés avec l’algorithme de Leiden, et écrit dans un dossier graphify-out/ :

• graph.html : un graphe interactif à ouvrir dans le navigateur, à parcourir en cliquant et à filtrer par communauté.
• GRAPH_REPORT.md : un résumé lisible avec les principales communautés, les nœuds les plus connectés (les « god nodes »), les connexions surprenantes et les relations de groupe (les « hyperedges »).
• graph.json : le graphe complet, que la CLI et le serveur MCP interrogent.

Une fois qu’il existe, vous pouvez lui poser des questions directement :

graphify query "how is authentication handled"
graphify path "Router" "Database"
graphify explain "AuthMiddleware"

Deux choix de conception se démarquent. D’abord, il n’y a ni embeddings ni base vectorielle. Les réponses viennent d’un parcours du graphe, ce qui permet de demander comment A est relié à B, ce que la recherche vectorielle ne sait pas vraiment faire. Ensuite, chaque arête est marquée EXTRACTED (lue directement dans la source) ou INFERRED (devinée par le modèle). Très peu d’outils IA vous disent lesquelles de leurs affirmations sont des faits et lesquelles sont des suppositions. Celui-ci le fait.

La promesse : moins de tokens, un meilleur contexte

L’argument porte sur le contexte. Au lieu qu’un assistant lise une douzaine de fichiers pour répondre à « comment marche l’authentification ici ? », il lit un rapport compact ou interroge le graphe et récupère les nœuds pertinents en quelques centaines de tokens.

La documentation du projet cite un corpus de 52 fichiers où une requête passe d’environ 123k tokens de fichiers bruts à environ 1,7k tokens sur le graphe. C’est un chiffre frappant, mais il vient d’un corpus bien précis. Prenez-le comme une tendance, pas comme une garantie.

Ce qui se passe sur une vraie base de code

Le test indépendant le plus utile que j’ai trouvé est l’article de Praveen Vijayan. Il a comparé Graphify à un simple ripgrep sur un vrai monorepo TypeScript d’environ 600 fichiers en développement actif, et sa conclusion est que Graphify, ce sont en réalité deux produits livrés en un.

Les artefacts de build sont vraiment bons. Le rapport a regroupé une centaine de documents de planification en lignes de travail cohérentes, dont une chaîne de corrections de bugs liées, écrites à plusieurs semaines d’écart, que personne n’avait jamais reliées. Les libellés des communautés faisaient une meilleure table des matières que l’arborescence des dossiers. La détection des cycles d’import venait gratuitement. Rien de tout ça, grep ne peut vous le donner.

L’interface de requête est faible sur le code. Sur des questions ciblées, rg gagnait à chaque fois : plus rapide, beaucoup moins de tokens, et presque entièrement dans le sujet, alors que la requête sur le graphe renvoyait de longues listes de nœuds pour la plupart sans rapport. La cause est structurelle. Les fichiers que tout le monde importe (fichiers barrel, utils partagés, la factory de l’application) deviennent des hubs géants, et un parcours à deux sauts depuis presque n’importe où atteint une grande partie de la base de code.

Les graphes périmés sont dangereux. Après une seule journée de travail normal, une fonction renommée était toujours rapportée par graphify explain, avec son ancien numéro de ligne et ses relations, le tout marqué EXTRACTED. Une mauvaise réponse estampillée avec le plus haut niveau de confiance est pire que pas de réponse du tout, parce qu’elle supprime le réflexe d’aller vérifier.

D’autres retours vont dans le même sens. Le discours rassurant du « tout reste en local » ne vaut que pour le code : documents, PDF et images sont envoyés à un LLM externe pour l’extraction. Et la visualisation interactive devient difficile à utiliser au-delà de quelques milliers de nœuds.

Alors, ça vaut le coup ?

Ça dépend presque entièrement de ce sur quoi vous le pointez.

Bon usage :

• De grosses piles de texte que personne n’a reliées entre elles : notes, ADR, RFC, postmortems, documents de planification.
• Des bases de code legacy peu ou pas documentées, où n’importe quelle carte vaut mieux que pas de carte.
• Un premier passage sur un dépôt inconnu, pour s’orienter avant de plonger dedans.
• Des contenus variés (articles, transcriptions, captures d’écran) pour lesquels il n’y a ni AST ni serveur de langage sur lequel s’appuyer.

Mauvais usage :

• Les questions précises comme « où est défini X » ou « qui appelle Y ». C’est le rôle de rg et du serveur de langage de votre éditeur, qui sont exacts et jamais périmés.
• Les projets avec une vraie culture de la documentation. Si vos règles d’architecture sont déjà écrites, le graphe n’en est qu’une copie inférée et un peu datée.
• Le code qui bouge vite sans rafraîchissement automatique. Un graphe faux mais sûr de lui est un handicap.

Un mot pour les développeurs Rails

J’écris surtout du Ruby on Rails, et je soupçonne que Rails est un cas délicat pour Graphify. Le code Rails repose sur l’autoloading de Zeitwerk plutôt que sur des require explicites, donc les arêtes d’import dont dépend un outil basé sur Tree-sitter risquent d’être rares, et une bonne partie du câblage vit dans les conventions (nommage, associations, callbacks) plutôt que dans la syntaxe. Je ne l’ai pas encore mesuré, alors prenez ça comme une hypothèse, mais je ne m’attendrais pas à ce que le graphe de code d’une application Rails soit aussi riche que celui d’un projet TypeScript ou Python.

Comment je l’utiliserais

Si vous voulez l’essayer, voici la configuration qui garde la bonne moitié et évite la mauvaise :

1. Limitez le périmètre. Lancez-le d’abord sur docs/, votre vault de notes ou votre dossier de planification, pas sur tout le monorepo. C’est là qu’est la valeur, et ça limite le coût de l’extraction par LLM.
2. Lisez le rapport, ne vous contentez pas de l’interroger. GRAPH_REPORT.md est le vrai livrable. Lisez-le une fois du début à la fin.
3. Utilisez les requêtes pour trouver des points d’entrée, pas des réponses. Regardez de quels nœuds part une requête, puis passez à rg et ouvrez les fichiers vous-même.
4. Gardez le graphe à jour. graphify update . réextrait le code sans appel au LLM, donc ça ne coûte presque rien de le lancer dans un hook post-commit.
5. Vérifiez la dérive avant de faire confiance à une réponse sur le code. Le graphe enregistre dans graph.json le commit à partir duquel il a été construit. Une vérification rapide avant de l’interroger suffit :

built=$(jq -r .built_at_commit graphify-out/graph.json)
echo "graph is $(git rev-list --count "$built"..HEAD) commits behind HEAD"

6. Ne prenez jamais un INFERRED pour argent comptant. Les marqueurs ne servent que si vous les regardez vraiment.

Conclusion

Graphify s’attaque à un vrai problème : les assistants IA n’ont aucune mémoire de la façon dont un projet s’articule. Les idées derrière l’outil sont solides, surtout l’analyse déterministe du code et les marqueurs honnêtes EXTRACTED / INFERRED.

Mais en pratique, c’est un excellent outil pour les documents et un outil moyen pour le code. Pointez-le sur vos notes et votre documentation, gardez grep pour votre code, et considérez tout ce qu’il vous dit sur une fonction comme une piste tant que vous ne l’avez pas vérifié.