Les grapheurs de codebase : MCP pour agents IA, vraie révolution ou middleware en attendant mieux ?
Aujourd’hui, de nombreuses codebases sont pilotées en grande partie, pour ne pas dire exclusivement, par des agents.
Pour explorer et naviguer dans ces codebases, les agents utilisent nativement des commandes bash comme grep. Cette méthode fonctionne, elle est éprouvée, mais force est de constater qu’elle génère beaucoup de bruit : beaucoup de lignes sont lues inutilement, et certaines occurrences peuvent quand même être manquées.
Les code graph MCP servers sont apparus comme réponse à ça. L’idée est la suivante : indexer la codebase dans son entièreté, créer un graphe des symboles (noms de variables, fonctions, classes) et permettre à un agent de requêter ce graphe via un serveur MCP.
C’est utile sur le papier. Mais la question qui subsiste, c’est “pour qui, quand, et pour combien de temps encore ?”.
Ce que font les code graph MCP servers
Un outil d’indexation analyse la codebase avec un parser syntaxique pour en extraire les symboles et leurs relations : les appels, références, imports ou héritages apparaissent comme des liens entre les objets ou fichiers. Lorsque l’agent a besoin de modifier tous les appels à une même fonction, il reçoit une réponse bien structurée, en quelques tokens, et parfaitement exhaustive.
Il en existe de nombreuses implémentations plus ou moins abouties. colbymchenry/codegraph semble être le plus populaire et le plus abouti à ce jour (stable, maintenu, avec une communauté conséquente). Quoi qu’il en soit, toutes reposent sur le même principe : les relations entre symboles sont pré-calculées par un parser, plutôt que d’être inférées statistiquement par un LLM.
Avant d’en faire un réflexe
Bien que les performances de ces outils soient prouvées, il se pose toujours la question suivante : est-ce que le gain justifie la complexité de mise en place et d’entretien ?
La réponse est nuancée. En 2026, les modèles récents ont des contextes d’un million de tokens et plus, une petite codebase pourrait presque y tenir en entier. Mais ce n’est pas pour autant une bonne approche. L’effet “lost in the middle”, même atténué par les modèles récents, reste documenté (arXiv:2503.00353). Il suffit alors de sélectionner les bons fichiers avant d’ouvrir le contexte : un agent qui charge d’abord l’arbre de répertoires, identifie les modules concernés, puis charge seulement ces fichiers, couvre 90 % des codebases qui existent aujourd’hui, et ce sans setup, sans watcher, sans MCP server à maintenir.
Le coût de mise en place reste non négligeable : indexation initiale de plusieurs minutes sur un gros projet, watcher à maintenir en vie, serveur MCP à configurer pour chaque outil de l’équipe. Un pip install ne suffit pas, c’est une dépendance d’infrastructure.
Le graphe prend tout son intérêt quand la codebase devient très grande, avec des dépendances entremêlées sur plusieurs couches d’abstraction.
Ce que NeurIPS 2025 laisse entrevoir
Les grapheurs de codebase actuels sont du middleware : des adaptateurs externes qui compensent quelque chose que les LLMs ne font pas nativement.
Mais tout cela pourrait changer. Une étude présentée en poster à NeurIPS 2025 laisse entrevoir une autre possibilité : intégrer le graphe de code directement dans le mécanisme d’attention du LLM via un adapter. Pas du RAG externe, pas un agent qui fait des requêtes MCP. Le graphe devient une entrée native du modèle. Les différents benchmarks se montrent encourageants ; plus de détails dans le papier Code Graph Model (CGM).
Alors, que faire ? Aujourd’hui, il n’existe pas d’étude quantitative reliant directement le volume de votre codebase et l’efficacité de ces outils. Pas plus qu’il n’existe de moyen de comptabiliser l’effort que ceux-ci vous coûterait à mettre en place, en fonction de votre projet.
Mon conseil est le suivant : si vous pouvez vous en passer, faites-le. Continuez à suivre de près l’évolution de ces outils, et si demain le besoin s’en fait sentir, soyez prêts à en mettre un en place, à moins que ceux-ci soient déjà remplacés par d’autres, meilleurs.