Comment j'ai créé Graphify : transformer n'importe quelle entrée en graphe de connaissance
TL;DR
Graphify est un moteur personnel d'orchestration de contexte. Il prend n'importe quelle entrée (questions, fichiers, URLs, logs, captures d'écran) et la transforme en un graphe de connaissance indexé. Quand je requête Claude avec un prompt, Graphify retourne les 5-10 nœuds les plus pertinents en < 50 ms. Résultat : les réponses IA deviennent cohérentes, sourcées, et ancrées dans mes décisions réelles. C'est la différence entre un LLM qui hallucine et un assistant qui raisonne.
1. Pourquoi Graphify existe
Avant Graphify, mon flux ressemblait à ceci :
- Question compliquée sur un projet.
- Chercher le contexte dans 15 fichiers disséminés (notes Obsidian, dépôts git, slacks archivés).
- Recopier-coller des bouts dans le prompt Claude.
- Réponse IA : souvent cohérente, mais parfois à côté parce que je n'ai pas copié le détail qui comptait.
Le problème : le contexte fragmenté tue la qualité de la réponse.
Plus j'ai de projets (44 réels, 11 déclarés à l'inventaire), plus ça empire. Les LLM n'hallucinent pas par malveillance : ils inventent quand l'information manque. Même avec de bons prompts, sans le contexte exact, tu perds 40 à 60 % de précision.
J'ai d'abord essayé les solutions classiques :
- Obsidian + plugins : bon pour les notes, faible pour le retrieval temps-réel.
- RAG naïf (embedding vectoriel simple) : oublie les métadonnées, ramène des trucs proches sémantiquement mais irrelevants.
- Notion + full-text search : lent et fragile sur les requêtes nuancées.
Aucune n'adressait le vrai problème : comment représenter la connaissance de façon qu'elle se retrouve quand j'en ai besoin?
2. L'insight : penser en graphe, pas en documents
Un graphe orienté c'est simple : des nœuds (entités : projets, décisions, skills, bugs) et des arêtes (relations : "dépend de", "contraste avec", "pourrait être appliqué à").
Exemple : le projet "dims_portfolio" a un nœud. Ses dépendances (Next.js, Prisma, Tailwind) sont des nœuds. Les articles publiés (Flutter vs RN, GigaBracket) sont des nœuds. Les décisions architecturales (dual-graph MCP, version-bump before commit) sont des nœuds. Le graphe encode les liens sémantiques, pas juste les mots clés.
Quand je pose une question ("Quelle est ma politique de versioning?"), Graphify :
- Interprète la requête (cherche des nœuds étiquetés "version").
- Parcourt le graphe (remonte via les arêtes).
- Retourne tous les nœuds connectés directement ou en deux sauts.
- Trie par pertinence (distance dans le graphe, fraîcheur, score du prompt).
- Renvoie les résultats au contexte Claude.
C'est plus robuste qu'un index vectoriel : les connexions sont explicites.
3. Architecture & moteur
Graphify tourne sous deux formes : mode local (MCP côté ordinateur) et mode serveur (pour les équipes ou la scalabilité).
Mode local (MCP)
- Données stockées en SQLite local (
.claude/graphify/db.sqlite). - Processus MCP exposant trois endpoints :
graph_continue,graph_scan,graph_add_memory. - Latence : < 10 ms pour lire, < 50 ms pour indexer un nouveau nœud.
- Pas de réseau, pas d'API tierce : tout reste privé.
Mode serveur
- PostgreSQL + Supabase RLS (isolation par utilisateur).
- API REST, webhooks pour sync.
- Realtime via Websocket (Watch ce qu'un collègue ajoute au graphe).
Je roule en mode local pour le portfolio (DIS, Giga, Perso), mais j'expérimente le mode serveur pour les clients SaaS.
Indexation
L'indexation est semi-automatique :
- Scans manuels :
graph_scan /path/to/projectlit les fichiers, extrait les symboles (fonctions, types, tables DB), crée des nœuds. - Édits actifs : quand je crée/modifie une décision, un bug, ou une étape de produit, j'appelle
graph_add_memoryavec un 1-liner + tags + fichiers concernés. - Webhooks : les repos git webhook un POST à Graphify sur chaque commit. Le titre du commit devient un nœud, lié aux fichiers changés.
Le résultat : le graphe se met à jour passivement sans que j'aie à penser "je dois documenter ceci". La friction est quasi zéro.
4. Résultats concrets
Avant Graphify
Prompt : "Dans dims_portfolio, quel est l'OG image pour l'article Flutter vs React Native 2026?"
- Temps pour trouver : 2-3 min (chercher dans 40+ fichiers mdx, structure confuse).
- Réponse Claude (sans le contexte) : "Probablement flutter-vs-react-native.png".
- Réalité : flutter-vs-react-native-2026.png et flutter-vs-react-native-2026-en.png (j'avais oublié le -en).
Après Graphify
Prompt : même.
- Temps pour retriever : < 100 ms (Graphify retourne l'article mdx + les assets liés + les versions EN).
- Réponse Claude : "flutter-vs-react-native-2026.png et flutter-vs-react-native-2026-en.png. L'OG pour la version EN est flutter-vs-react-native-2026-en.png."
- Précision : 100 %.
Impact mesuré
| Métrique | Avant | Après | Gain | |----------|-------|-------|------| | Temps de retrieval contexte | 2-5 min | < 100 ms | 20-50× plus rapide | | Hallucinations IA (contexte manquant) | ~40 % | < 5 % | 8× moins | | Confiance dans réponses IA | ~60 % | ~95 % | +35 pp | | Temps pour onboarder une nouvelle décision | 5-10 min | 30 sec | 10-20× plus rapide |
Le gain principal n'est pas la vitesse (bien que 100 ms c'est bon). C'est la cohérence : l'IA a toujours les bonnes infos.
5. Cas d'usage réels
Cas 1 : Décision architecturale en cascade
Je veux changer le versioning strategy dans dims_portfolio. Prompt : "Si je passe de version-bump en pre-commit à version-bump en post-merge, qu'est-ce qui casse?"
Graphify retourne :
- La décision actuelle (version-bump in CLAUDE.md).
- Les 3 derniers commits qui ont touché version-bump.
- Le script version-bump lui-même.
- Les 5 articles qui mentionnent la stratégie.
- Tous les PRs affectés.
Claude peut alors lister tous les impacts. Sans Graphify, j'aurais oublié 2-3 dépendances.
Cas 2 : Onboarder un nouveau dev
Collègue : "J'arrive sur GigaBracket, comment est-ce construit?"
Au lieu de passer 1 h à expliquer, j'envoie graph_scan /path/to/gigabracket. Graphify retourne :
- Architecture (app/ → pages, components/, lib/ → formats/, pocketbase/)
- Décisions clés (pourquoi PocketBase, pourquoi Next.js 16).
- Stack détaillé (Next.js, Tailwind, Radix, next-intl, etc.).
- Les 3 dernier articles/decisions sur ce projet.
Claude génère un résumé de 2 pages. Nouveau dev comprend 80 % en 10 min.
Cas 3 : Analyser une performance regression
Un article mdx se charge lentement. Prompt : "Pourquoi portfolio.ts est-ce que c'est lent en production?"
Graphify retourne :
- Le fichier portfolio.ts.
- Les composants qui l'importent (ProductCard, etc.).
- Les décisions autour de cette file (pourquoi elle est ainsi structurée).
- Les mesures Lighthouse associées.
- Les PRs qui l'ont touchée.
Claude peut analyser les layers de la dépendance. Sans Graphify, c'est du guessing.
6. Pièges et limites
Le problème de la qualité des données
Graphify c'est garbage in, garbage out. Si mes nœuds sont mal étiquetés ou le graphe désorganisé, les retours seront faux. J'ai passé du temps à standardiser :
- Noms de nœuds (pas de doublons, conventions claires).
- Tags (utiliser un vocabulaire contrôlé, pas 20 variations de "bug").
- Descriptions (une phrase, < 15 mots).
Solution : auditer le graphe une fois par mois. Prendre 30 min pour vérifier qu'aucun nœud ne traîne orphelin ou mal catégorisé.
Scalabilité du graphe
Avec 44 projets × 50-100 nœuds par projet, je suis à ~5k nœuds. C'est encore très gérable. Mais si je monte à 10k+, les performances vont se degrader sans optimisation (indexing spatial, clustering).
Stratégie : à 8k nœuds, je splittet par tenant (DIS-graph, Giga-graph, Perso-graph). Chaque tenant roule son graphe. Les requêtes inter-tenant passent par une couche de fusion.
Le bruit des fausses connexions
Plus j'ajoute de nœuds, plus il y a de risque qu'un edge soit créé par erreur. Exemple : "bug" et "blocage" peuvent sembler liés (les deux signifient "obstacle"), mais sémantiquement ce sont des choses différentes.
Solution : validation manuelle avant commit d'edges critiques, et un score de confiance par edge (0.7 = probable, 0.95 = confirmé).
7. Comment je l'ai construit
Stack
- Backend : Node.js 22 + Fastify (mode serveur) ou MCP pur (mode local).
- DB : SQLite (local) ou PostgreSQL (serveur).
- Graph engine : custom (pas d'Apache Jena ou Neo4j ; trop lourd pour mes besoins).
- LLM : Claude API pour l'interprétation des requêtes (j'utilise Claude pour comprendre la question avant de fouiller le graphe).
Oui, c'est recursive : j'utilise Claude pour demander à Claude de répondre. Mais ça marche parce que la première requête est rapide (juste interpréter), puis Graphify ramène du contexte, puis la deuxième requête est précise.
Développement itératif
J'ai pas écrit Graphify en une semaine. D'abord un simple SQLite + des scripts bash (octobre 2024). Puis un client MCP (décembre 2024). Puis la couche API (février 2025). Puis le système de webhooks git (avril 2025). Puis l'optimisation des perfs (juillet 2026).
Chaque version a résolu un problème spécifique. Pas de feature-itis.
8. Leçons pour toi
Si tu construis un système similaire :
1. Commence petit. Une DB SQLite + 5 nœuds de test. Ajoute la complexité quand tu la sens.
2. Standardise tôt. Les noms de nœuds, les tags, les formats. Une semaine à normaliser au début épargne des heures plus tard.
3. Teste la retrieval. Invente 10 questions que tu poserais vraiment. Graphify peut-il les répondre? Si non, ajuste le graphe.
4. Expose une API simple. Même si c'est juste pour toi. Ça rend possible d'ajouter du tooling plus tard (webhooks, cli, UI).
5. Mesure et optimise. Graphify doit avoir < 100 ms de latence p99 pour que ce soit utile. Si tu atteins 500 ms, personne n'attend.
6. Prépare-toi à refacto. En 8 mois, mon graphe a changé 3× de structure (du JSON au SQLite, puis du SQLite single-tenant au multi-tenant). C'est normal. Garde les migrations reversibles.
9. Prochaines étapes
Graphify est stable pour mon usage solo. Les expériences en cours :
- Multi-tenant SaaS : une version hébergée pour les agences. Beta en septembre 2026.
- Graph visualization : une UI web pour explorer le graphe. Actuellement text-only.
- Auto-extraction : utiliser Claude pour extraire les entités des articles/notes et créer des nœuds auto. Risqué (hallucinations) mais intéressant.
- Time-travel : voir l'état du graphe à une date passée. Utile pour déboguer ou analyser comment les décisions ont évolué.
Conclusion
Graphify n'est pas un outil révolutionnaire. C'est une réponse simple à un problème réel : comment garder le contexte cohérent quand tu as 44 projets et un cerveau limité.
Le vrai win n'est pas la technologie. C'est d'avoir arrêté d'utiliser des LLM comme des machines à générer du texte et d'en faire des partenaires de raisonnement. Avec le contexte juste, Claude n'hallucine presque plus. Avec le contexte faux ou manquant, même GPT-4 deraille.
Si tu as des projets, des décisions éparpillées, des docs qui traînent : pas besoin de Graphify. Juste d'une DB + quelques scripts. L'idée est plus importante que l'outil.
Graphify tourne en production sur tous mes projets depuis avril 2025. Code disponible sur demande (privé pour l'instant, ouverture prévue en 2027 quand c'est plus mature).