← Retour au blog
AiEnviron 8 min de lecture

Graphify transforme un dossier en graphe. Le 71.5x mérite examen

Publié le 28 oct. 2026
Graphify transforme un dossier en graphe. Le 71.5x mérite examen

Graphify a récolté environ 7,300 étoiles cette semaine, ce qui le place en haut du classement hebdomadaire de GitHub et porte son total au-delà de 137,000. Le discours tient en une ligne : pointez votre agent de codage vers un dossier, tapez /graphify ., et récupérez un graphe de connaissances de tout ce qu'il contient.

Ce qui est intéressant n'est pas le graphe. C'est le chiffre accroché à côté : 71.5x moins de tokens par requête, mesuré contre la lecture des fichiers bruts. Si cela tient en général, ce n'est pas un outil de confort, c'est un changement dans la quantité de contexte qu'un agent doit porter.

D'où ça vient

L'auteur, safishamsi, présente le projet comme une réponse à une habitude précise d'Andrej Karpathy : garder un dossier /raw où s'entassent articles, tweets, captures d'écran et notes, sans jamais réussir à y retrouver quoi que ce soit ensuite. Le problème parle à beaucoup de monde, et l'origine est plus honnête que la plupart, parce qu'elle décrit un mode de défaillance plutôt qu'un marché.

L'objectif annoncé est plus étroit que « cherchez dans vos documents ». Il s'agit de produire quelque chose de persistant qui survit d'une session à l'autre, et d'être explicite sur ce qui a été déduit et ce qui a été extrait. Chaque arête du graphe porte l'étiquette EXTRACTED, INFERRED ou AMBIGUOUS. C'est un choix de conception inhabituel et, à mon avis, la partie la plus précieuse de l'ensemble.

Ce qu'il fait réellement

L'installation tient en deux commandes, et oui, le nom du paquet PyPI est temporairement faux :

pip install graphifyy && graphify install

Le Y doublé vient d'un différend sur le nom, pas d'une faute de frappe. La CLI et la commande du skill restent toutes deux graphify. Sous Windows, si la commande n'est pas reconnue après l'installation, il faut ajouter le dossier Scripts de Python au PATH, ou passer par pipx install graphifyy pour éviter le problème.

Ensuite, dans Claude Code, depuis n'importe quel répertoire :

/graphify .
/graphify ./raw --mode deep
/graphify query "what connects attention to the optimizer?"
/graphify path "DigestAuth" "Response"
/graphify explain "SwinTransformer"

La sortie atterrit dans graphify-out/. On y trouve un graph.html interactif que l'on peut parcourir au clic, un dossier obsidian/ qui s'ouvre comme un vault, un graph.json persistant qui permet d'interroger des semaines plus tard sans rien relire, un cache/ indexé sur SHA256 pour que les relances ne traitent que les fichiers modifiés, et un GRAPH_REPORT.md qui liste ce qu'il appelle les god nodes — les concepts de plus haut degré — ainsi que des « connexions surprenantes » classées par un score composite où les arêtes code-vers-article pèsent plus lourd que les arêtes code-vers-code.

La partie multimodale n'est pas de l'habillage marketing. Les fichiers de code passent par tree-sitter pour l'analyse AST, plus une passe sur le graphe d'appels. Le Markdown, les PDF et les images passent par Claude : concepts et relations extraits de la prose, citations extraites des articles, et vision pour les captures d'écran, les schémas, les photos de tableau blanc et les images dans d'autres langues.

Il existe aussi des exports qui comptent pour qui ne veut pas vivre dans cet outil : --svg, --graphml pour Gephi ou yEd, et --neo4j, qui génère un cypher.txt au lieu d'exiger une base de données en fonctionnement. La pile est NetworkX, un clustering Leiden via graspologic, tree-sitter et vis.js. Pas de serveur. Rien ne quitte la machine, hormis les appels à Claude.

一整面白板上手绘的节点连边图,成簇的圆圈被红线圈出,箭头与简短标注,黑色与红色马克笔

Le 71.5x, examiné

Le corpus de référence compte 52 fichiers : les dépôts de Karpathy, cinq articles, quatre images. Résultat : 71.5x moins de tokens par requête que la lecture des fichiers bruts.

Le dépôt est d'une honnêteté rare sur la façon dont cela passe à l'échelle, assez rare pour mériter d'en citer la substance : la réduction de tokens croît avec la taille du corpus, et sur six fichiers la valeur du graphe tient à la clarté structurelle plutôt qu'à la compression, parce que six fichiers tiennent de toute façon dans une fenêtre de contexte. Leur propre exemple, sur le code de graphify plus l'article Transformer, donne 5.4x. Sur six fichiers de bibliothèque synthétiques, à peu près 1x.

La forme est juste. Si votre corpus tient déjà dans une fenêtre de contexte, vous n'économisez pas des tokens, vous achetez une carte. S'il s'agit de cinquante fichiers de types mêlés, l'économie est réelle et importante, parce que l'alternative n'est pas de lire les fichiers une fois, mais de les relire encore et encore, sur plusieurs tours, chaque fois qu'un agent perd le fil.

La comparaison flatte d'ailleurs graphify dans une direction et le sous-estime dans l'autre. Lire les fichiers bruts est la pire référence possible ; un index de recherche bien réglé paraîtrait meilleur face aux fichiers bruts. Mais un index de recherche renvoie des extraits, là où graphify renvoie des relations : la réponse à « qu'est-ce qui relie l'attention à l'optimiseur » n'est pas un extrait, c'est un chemin. Ce sont deux types de requêtes différentes, et une base vectorielle n'en sert qu'une.

« Pas de base vectorielle » est une vraie position d'architecture

La plupart des systèmes de recherche découpent le texte en morceaux, les plongent en embeddings et font une recherche des plus proches voisins. Graphify saute tout cela : analyse AST locale et déterministe pour le code, extraction par LLM pour la prose et les images, puis un graphe. Aucune étape d'embedding, aucune recherche par similarité.

Ce que vous gagnez à la place, c'est l'explicabilité. Demandez pourquoi deux choses sont reliées et vous obtenez les arêtes, chacune étiquetée selon qu'elle a été extraite de la source ou déduite par le modèle. Un index vectoriel ne sait pas le dire. Il peut seulement vous apprendre que la distance cosinus était faible.

Le prix à payer est la couverture. Un graphe ne connaît que ce que l'extracteur a trouvé. Si la passe d'extraction a manqué une relation, aucune requête ne la fera remonter, et il n'existe pas de repli approximatif. L'étiquette AMBIGUOUS est l'aveu honnête de cette limite, et l'option --mode deep existe parce que la passe par défaut est prudente sur l'inférence d'arêtes.

Là où il gagne sa place

Deux usages, d'après mon expérience de ce genre d'outils.

Le premier est l'arrivée dans une base de code inconnue. Pas « où est la fonction X » — grep suffit — mais « quels sont les concepts porteurs ici, et lesquels touchent au code de facturation ». C'est une question de graphe, et le rapport des god nodes y répond sous une forme qu'on lit en deux minutes.

Le second est le cas multi-agents. Quand plusieurs agents écrivent du code en parallèle, la représentation que chacun a du dépôt devient obsolète en quelques minutes. Un graphe reconstruit à chaque commit (graphify hook install installe un hook post-commit) ou à chaque sauvegarde de fichier (--watch) donne à tous les agents la même carte à jour, au lieu de cinq suppositions divergentes.

La limite évidente : l'outil est d'abord conçu comme un skill pour Claude Code. L'installation manuelle dépose un SKILL.md dans ~/.claude/skills/graphify/ et ajoute une ligne à CLAUDE.md. Il existe un mode serveur MCP (--mcp) utilisable par d'autres clients, mais l'ergonomie est manifestement optimisée pour un seul écosystème, et la dépendance à Claude signifie que la passe d'extraction coûte réellement de l'argent sur un gros corpus.

Le verdict honnête

Graphify n'est pas un moteur de recherche et ne devrait pas être évalué comme tel. C'est un modèle persistant et inspectable de ce que contient un dossier, avec cette propriété inhabituelle qu'il vous dit quelles parties il a devinées. Pour un projet à 137,000 étoiles qui fait le buzz depuis une semaine, la question intéressante n'est pas de savoir si le graphe impressionne, mais si l'habitude d'étiqueter l'inférence survit au contact des utilisateurs qui veulent juste des réponses.

Mon pronostic : la plupart des gens utiliseront query, ignoreront les étiquettes d'arêtes et n'ouvriront jamais graph.json. Ceux qui le garderont sont ceux qui avaient besoin de la carte, pas du corrigé.

Articles associés