# Donner à un agent IA le contexte d'un grand dépôt sans indexeur local

Canonical source: https://maguyva.ai/fr/blog/large-repo-context-without-a-local-indexer

License: text under [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/); code samples under [MIT-0](https://opensource.org/license/mit-0); the Maguyva name, logos, brand assets and other code are not covered. Details: [maguyva.ai/license](https://maguyva.ai/license).

Date: 2026-08-14 · Author: Maguyva Team

> Comment donner à un agent de code une carte interrogeable d'un grand dépôt depuis le cloud, sans faire tourner d'indexeur local sur votre portable.

Un grand dépôt ne tient pas dans une fenêtre de contexte, et si vous avez déjà pointé un indexeur local vers un vrai monorepo, vous savez qu'il n'y tient pas non plus confortablement — la RAM explose, le premier index prend une heure, et votre agent commence encore la session suivante en devinant quels fichiers comptent.

La réponse habituelle est de faire tourner un indexeur à côté de l'éditeur, et pour un dépôt qui tient confortablement sur une seule machine, c'est une bonne réponse. Si votre monorepo s'indexe déjà rapidement dans Cursor et que c'est le seul endroit où vous avez besoin de la carte, ce texte n'a rien à ajouter — passez votre chemin.

Ce texte parle de l'autre cas — quand un agent a besoin d'une carte interrogeable d'un grand dépôt, et que vous ne voulez pas faire tourner d'indexeur local pour l'obtenir.

## Quand un indexeur local est le mauvais outil

Un index local suppose que le code vit sur la machine qui l'interroge, et à l'échelle d'un vrai monorepo, cette hypothèse tend même à l'intérieur d'un seul éditeur. Le dépôt est tout simplement plus grand que ce que vous voulez garder au chaud sur un portable : vous travaillez dans un paquet pendant que le rayon d'impact se trouve trois répertoires plus loin, et un premier index à froid d'un arbre de deux millions de lignes n'est pas quelque chose que vous voulez subir deux fois — ni sur votre machine, ni sur un runner CI qui n'a jamais cloné l'arbre auparavant. Ou un coéquipier devrait pouvoir interroger la même carte que vous, sans attendre que sa propre machine traverse péniblement le même index.

Rien de tout cela n'est une raison de jeter un bon indexeur d'éditeur. C'est une raison d'avoir aussi une carte hébergée que n'importe lequel de vos agents peut interroger via MCP.

Et le problème d'échelle va plus loin que « trop de fichiers à coller » . Sur un grand arbre, la question intéressante n'est presque jamais « montre-moi ce fichier » — c'est quel fichier, quel symbole, quels appelants, quels tests. Un agent qui commence en listant `src/` et en lisant les trois premiers résultats manquera allègrement le gestionnaire dans `apps/api` et le client généré dans `packages/sdk`. Ce qu'il vous faut, c'est une récupération construite depuis l'arbre entier, puis classée, puis citée.

## Ce que signifie vraiment « le contexte d'un grand dépôt » 

Déverser des fichiers dans le prompt n'est pas du contexte — c'est une copie plus petite et moins bonne de l'arbre. Ce dont votre agent a réellement besoin, c'est de poser des questions et d'obtenir des réponses citées en retour : où ce symbole est-il défini et qui l'appelle, qu'est-ce qui dépend du module que je m'apprête à modifier, quel fichier de test couvre ce comportement, et à quoi ressemble l'arbre *maintenant*, pas le trimestre dernier.

Ces réponses doivent venir d'un index construit à partir de votre dépôt plutôt que de la mémoire du modèle sur les dépôts des autres, et l'index doit vivre ailleurs que dans la fenêtre de contexte de l'agent. Pour ce problème, il devrait aussi vivre ailleurs que sur votre portable.

Une autre chose que les fichiers d'instructions ne peuvent pas faire pour vous : `CLAUDE.md` et `AGENTS.md` sont le bon endroit pour les conventions et le comportement, mais ce ne sont pas une carte vivante, classée et interrogeable d'un arbre de deux millions de lignes. Utilisez les règles pour le comportement ; utilisez l'intelligence du dépôt pour les faits.

## Construire la carte dans le cloud, l'interroger depuis n'importe quel client

Maguyva est une couche de contexte de code MCP distante. Vous connectez GitHub, choisissez vos dépôts, et vous partez pendant que les pipelines cloud analysent l'arbre, construisent les symboles et les arêtes du graphe, et maintiennent une carte classée — sans indexeur local, jamais.

Quand vous poussez du code, les fichiers modifiés sont analysés de façon incrémentale, et les couches de graphe et de classement se reconstruisent selon un calendrier : quotidien sur le plan gratuit, horaire sur les plans payants. Chaque instantané est horodaté, afin que votre agent puisse dire quelle version de l'arbre il lit. La limite honnête ici est le travail local non synchronisé — une modification qui n'existe que dans votre arbre de travail, jamais poussée, n'est pas encore dans la carte hébergée.

Ensuite, vous connectez le client que vous utilisez déjà en ajoutant une clé API à sa configuration MCP. Il existe des guides de configuration pour 24 clients MCP documentés, et tout autre client compatible MCP prenant en charge la configuration standard peut aussi se connecter. Si Cursor est votre environnement, la [page Cursor](/fr/for-cursor) trace ce chemin ; le même serveur répond à Claude Code, VS Code, Windsurf, Codex CLI et les autres.

Vous ne changez pas d'éditeur. Vous donnez à votre agent une surface d'outils — 11 outils MCP à travers la recherche, les symboles, l'analyse de dépendances, la récupération de fichiers et le contexte de dépôt — avec une couverture de plus de 279 langages et technologies textuelles, ce qui compte plus qu'on ne le pense sur un monorepo qui a cessé d'être un seul langage il y a des années.

Les réponses reviennent fondées, sous forme de chemins de fichiers avec numéros de ligne. Les récupérations sémantique, structurelle, par graphe et textuelle sont fusionnées en résultats classés, de sorte qu'une question comme « qu'est-ce qui dépend de parseConfig » ne vous donne ni un déversement grep ni un seul fragment sémantique, mais la poignée d'endroits qui comptent réellement.

## Un guide concret

Ne commencez pas par indexer toute l'entreprise. Voici le chemin qui fonctionne :

1. Choisissez un dépôt que vous connaissez déjà bien — un paquet que vous pouvez évaluer à la main vaut mieux que le plus grand arbre que vous avez.
2. Commencez gratuitement : 3 dépôts, 50 000 lignes indexées, les 11 outils, aucun quota de requêtes mensuel. Si votre dépôt représentatif est plus grand, la [page de tarification](/fr/pricing) liste les niveaux d'espace de travail (0 $, 19 $, 49 $, 149 $) par empreinte indexée — pas par nombre de sièges.
3. Connectez GitHub et attendez la fin du premier index. Vous ne compilez rien localement.
4. Connectez le client MCP — quelques lignes de configuration. Maguyva est un serveur MCP distant, donc il n'y a ni plugins, ni extensions, ni second éditeur à adopter.
5. Posez une question que vous pouvez vérifier. « Qu'est-ce qui dépend de parseConfig ? » ou « Où est géré l'expiration de session de connexion ? » Ouvrez ensuite les résultats `file.ext:line` cités et vérifiez-les contre l'arbre devant vous.
6. Ce n'est qu'après que les citations ont survécu à ce contact que vous laissez l'agent modifier.

Si le premier dépôt convient bien et que votre arbre est grand, augmentez l'espace de travail pour correspondre à vos lignes indexées et à la cadence de reconstruction. Humains et agents partagent le même compte d'utilisateurs — Maguyva facture par espace de travail, pas par siège — donc ajouter un troisième agent à la boucle ne vous coûte rien.

Le test d'activation est le même que celui que la [documentation](/fr/docs) recommande pour tout premier lancement : indexer un dépôt que vous connaissez déjà, poser une question que vous pouvez vérifier. Un grand dépôt ne change pas le test ; il rend seulement un premier fichier erroné plus coûteux.

## À surveiller une fois connecté

Gardez un œil sur trois choses. Fraîcheur : les plans payants se reconstruisent toutes les heures, les plans gratuits tous les jours, et le travail local non poussé ne sera pas dans la carte — c'est le compromis que vous acceptez. Périmètre : indexez un ensemble représentatif de dépôts, pas chaque fork archivé ; le niveau gratuit est délibérément dimensionné pour découvrir si les réponses valent la peine d'être conservées. Et vérification : une carte de grand dépôt qui ne peut pas citer chemins et numéros de ligne n'est qu'un moteur de devinette plus lent, donc faites montrer à votre agent l'endroit avant qu'il livre le correctif.

Exécutez ensuite le même test que vous feriez sur un petit dépôt. Indexez un dépôt que vous connaissez déjà. Posez une question que vous pouvez vérifier. Si la carte est réelle, votre agent cesse de partir d'un arbre froid.

`// no laptop got hot building this map.`