Chaque nouvelle conversation débute avec un agent qui a oublié vos documents. Il peut les relire, au prix d’un temps et d’un contexte supplémentaires, ou il peut consulter quelque chose qui s’en souvient. GroupDocs.Search.Mcp conserve un index plein texte nommé sur le disque, localement, qui persiste entre les sessions et les redémarrages de conteneur, de sorte que Claude Desktop, Cursor ou Copilot commencent chaque session avec les documents du projet déjà recherchables et les rafraîchissent d’un seul appel lorsque les fichiers changent :

J’ai modifié certains contrats. Rafraîchissez l’index des contrats, puis dites‑moi quels contrats mentionnent maintenant une pénalité.

La version étape par étape avec configuration et dépannage se trouve dans la documentation : How to keep a document index current as files change.

Que signifie « mémoire » pour un agent ?

En pratique, deux choses : un état qui persiste en dehors de la conversation, et un moyen économique de maintenir cet état à jour. L’historique de chat échoue sur les deux : il se termine avec la session, et rien ne le met à jour lorsqu’un document change. Un index de recherche convient mieux aux documents. Il vit sur le disque à côté d’eux, il répond « quels fichiers disent X » sans les charger, et il peut être rafraîchi de façon incrémentielle.

session 1    add_to_index --> index "contracts" --+
                                                 |  kept on disk in
session 2    search, get_text_fragments <--------+  /data/.groupdocs-search-
             (nothing is re-read)                    index/contracts
files edit   update_index --> re-reads changed, added, deleted files only
new project  create_index {"indexName":"legal-2026"} --> a separate index

Comment fonctionne le rafraîchissement ?

update_index compare l’index avec les fichiers sur le disque et ne relit que ce qui a changé. Voici ce que le serveur a renvoyé lors de notre test, après qu’un contrat a eu une clause de pénalité ajoutée entre deux appels :

-> get_index_info {"indexName":"contracts"}
<- { "documentCount": 5, "indexedPaths": [ "contracts" ],
     "documentsWithErrors": [], "status": "Ready" }

-> update_index {"indexName":"contracts"}
<- Index 'contracts' updated: 0 added, 1 updated, 0 removed;
   5 document(s) in the index.

-> search {"query":"penalty","indexName":"contracts"}
<- documentsFound 3, including the edited initech-nda.docx

Les décomptes indiquent ce qui s’est passé : un fichier relu, rien d’autre touché. Les fichiers supprimés disparaissent lors du même appel.

Pourquoi un index par projet ?

Parce que des corpus séparés méritent des réponses séparées. Une question sur les contrats de cette année ne doit pas faire apparaître les brouillons de l’année dernière, et les documents d’un client ne doivent pas se mélanger avec ceux d’un autre client. Les noms d’index sont peu coûteux :

-> create_index {"indexName":"legal-2026"}
<- Index 'legal-2026' created. Add documents with add_to_index
   (indexName: 'legal-2026').

Chaque index est un dossier sous /data/.groupdocs-search-index, et get_index_info sans nom les répertorie tous. Vous avez rarement besoin d’appeler explicitement create_index, car add_to_index crée un index lors de la première utilisation, mais les nommer délibérément transforme « un index » en « la mémoire de ce projet ».

La règle unique concernant la suppression

Le moteur supprime les chemins qui ont été ajoutés, pas les fichiers individuels qu’ils contiennent. Le serveur l’indique clairement lorsque vous essayez :

-> remove_from_index {"documentPath":"contracts/hooli-supply-terms.txt",...}
<- Removal failed for 'contracts/hooli-supply-terms.txt':
   'contracts/hooli-supply-terms.txt' is inside the indexed folder
   'contracts'. GroupDocs.Search removes whole indexed paths only: ...

Concevez en conséquence : si vous prévoyez de supprimer plus tard une partie d’un corpus, comme une année, un client ou les brouillons, indexez ces parties comme des chemins séparés (contracts/2025, contracts/2026) et chacun pourra être supprimé individuellement. Supprimer un fichier sur le disque et exécuter update_index le retire également.

Le garder à jour sans demander

create_index (optional)
      |
      v
add_to_index ---> search ---> get_text_fragments
      ^              ^
      |              |  get_index_info: counts, paths, status
update_index  (files changed on disk)
      |
remove_from_index  (only a path that was given to add_to_index)

Trois façons pratiques de rendre le rafraîchissement automatique :

  1. Dans les instructions de l’agent. Une ligne dans CLAUDE.md ou AGENTS.md, « appeler update_index pour l’index de ce projet avant de répondre si les fichiers ont pu changer », fait que l’agent le fasse au début d’une session.
  2. Selon un planning. Toute automatisation compatible MCP peut appeler update_index chaque nuit ; lorsqu’il y a peu de changements, l’appel est rapide.
  3. Après une copie massive. Un seul appel récupère chaque fichier ajouté.

Les index survivent également aux mises à jour : les index construits par GroupDocs.Search 22.7 à 26.8 sont convertis lors de la première utilisation, avec une sauvegarde conservée à côté.

Ce que l’agent décide, et ce que fait l’index

Ce que l’agent décide Ce que fait l’index
quel index une question concerne conserve chaque index nommé dans son propre dossier
quand les fichiers ont pu changer relit uniquement les fichiers modifiés, ajoutés et supprimés
quels mots rechercher, et quelles variantes essayer correspond aux mots, phrases, plages ; rapporte les termes trouvés
quelle quantité de contexte citer renvoie des passages avec le nombre de mots demandé autour d’eux
ce qu’il vous dit rien : il renvoie les décomptes, les chemins et le texte, jamais de conclusions

La séparation est délibérée. Le jugement reste au modèle, et les faits dont il se sert proviennent d’un outil dont vous pouvez inspecter la sortie.

Limites honnêtes

  • En mode évaluation, un index contient au maximum 100 documents et une recherche renvoie au maximum 10 résultats. Appelez get_license_status avant de vous fier à un index comme source de vérité.
  • L’index persiste uniquement si /data (ou le volume d’index) est un dossier hôte monté ; sinon il disparaît avec le conteneur.
  • L’index contient le texte des documents : protégez‑le et éliminez‑le comme les documents.
  • Uniquement Docker ; sous Linux ajoutez --user "$(id -u):$(id -g)" afin que le conteneur puisse écrire l’index.

FAQ

L’agent se souvient‑il de mes documents entre les sessions ?
Avec un index persistant, oui : l’index reste sur le disque et la session suivante le recherche sans rien relire.

Dois‑je reconstruire l’index lorsque les fichiers changent ?
Non. update_index relit uniquement les fichiers modifiés, ajoutés et supprimés.

Puis‑je garder l’index séparé des documents en lecture seule ?
Oui. Montez les documents en lecture seule, montez un dossier inscriptible à /index, et définissez GROUPDOCS_MCP_INDEX_PATH=/index.

Approfondir