RAG + graphe d'appels : un contexte automatique issu du gestionnaire de tâches pour Claude Code

Le contexte est le principal problème de l'utilisation des LLM dans le développement réel. Ce n'est ni la qualité du modèle ni la taille de la fenêtre, mais ce qui entre dans le prompt et la manière dont il y entre. Un développeur a partagé sur Habr une solution pratique : un index RAG du dépôt avec des vecteurs et un graphe d'appels, plus un plugin pour Claude Code qui assemble automatiquement le contexte d'une tâche du gestionnaire de tâches, sans sélection manuelle et sans tokens superflus.

Pourquoi le contexte compte plus que la qualité du modèle

Lorsqu'un développeur prend une tâche dans le tracker et ouvre un assistant IA, l'étape la plus difficile n'est pas le dialogue avec le modèle, mais la préparation qui le précède. Il faut comprendre quels fichiers relèvent de la tâche, quelles fonctions sont appelées, quels modules sont interdépendants. Dans les gros projets, cela représente 10 à 20 minutes d'étude manuelle du code avant d'écrire le premier prompt.

Si l'on jette tout dans le contexte, les tokens partent vite, la requête coûte plus cher et le LLM se perd dans le bruit du code sans rapport. Si l'on en met trop peu, le modèle ne voit pas les dépendances, rate des fonctions importantes et donne des réponses superficielles. Trouver l'équilibre à la main est difficile.

Le RAG classique par embeddings règle une partie du problème : la recherche sémantique trouve des fragments proches par le sens. Mais il ne comprend pas la structure du code : la fonction A peut être sémantiquement éloignée de B tout en l'appelant directement, et les deux sont nécessaires dans le contexte.

Comment fonctionne la solution

L'auteur a construit le système sur deux niveaux d'indexation :

• Couche vectorielle — embeddings du code pour la recherche sémantique : fragments similaires, commentaires, noms
• Graphe d'appels — dépendances structurelles : la fonction A appelle B, le module C importe D, E hérite de F
• Plugin pour Claude Code — lit la description de la tâche dans le tracker et lance la recherche sur les deux niveaux
• Classement et troncature — les résultats sont pondérés par pertinence et tronqués à la limite de tokens
• Mise à jour incrémentale — l'index n'est pas recalculé de zéro à chaque commit

Le système repose sur un parseur de code (AST) et des outils d'analyse statique. Le graphe d'appels permet de contourner les limites de la recherche sémantique : même si les noms de fonctions sont atypiques ou les commentaires rares, les liens structurels du code restent traçables via l'AST. L'index est stocké séparément de la base de code et n'exige aucune modification du dépôt lui-même. Le plugin pour Claude Code s'installe comme une extension standard et interroge l'index via une API locale.

Économie de tokens

C'est là que l'approche produit un résultat mesurable. Sans contexte intelligent, les développeurs collent souvent des fichiers ou des répertoires entiers dans le prompt, « au cas où ». Avec RAG et graphe, le système décide de ce qui est pertinent et ne renvoie que cela.

«

Le principal problème du travail avec les LLM sur un projet réel n'est pas la qualité du modèle, mais le contexte », — l'auteur de l'article.

Pour les gros monorepos, l'effet est particulièrement net : au lieu de 50 000 tokens de « tout ce qui peut être lié », on obtient 3 000 à 5 000 tokens de contexte précis. C'est à la fois une réponse plus rapide et une économie directe sur l'API.

La pratique montre qu'un contexte bien assemblé réduit le nombre d'itérations avec le modèle. Lorsque l'IA voit toutes les dépendances dès le premier coup, elle demande moins souvent des fragments supplémentaires ou donne moins de réponses incomplètes.

Ce que cela signifie

L'approche indique une direction concrète pour les équipes d'ingénierie qui adoptent des assistants IA : automatiser non pas le dialogue avec le modèle lui-même, mais la collecte du contexte qui le précède. L'intégration avec le tracker est une étape logique : la tâche est déjà décrite, il suffit de la rattacher correctement au code. Pour les grandes équipes qui traitent des centaines de tickets par jour, cela pourrait devenir une composante standard du processus d'ingénierie.