Votre assistant RAG cite peut-être aujourd'hui une procédure ou un tarif qui n'existe plus, avec la même assurance qu'au premier jour. Une base documentaire vieillit dès le lendemain de sa mise en production. Pour la garder fiable, il faut choisir un mode d'entretien et vérifier les réponses après chaque passage. Deux modes existent : la réindexation complète à intervalle fixe et la mise à jour incrémentale supervisée. Ils ne donnent pas les mêmes résultats sur la fraîcheur, le coût, le risque et la traçabilité.
Un RAG répond avec ce qu'on lui a donné, y compris ce qui est périmé
Un assistant RAG ne connaît rien de votre entreprise en dehors des documents qu'on lui a fournis. Il cherche les passages les plus proches de la question, puis rédige une réponse à partir de ces passages. Si la procédure de remboursement des frais a changé en mars et que la version de janvier est encore dans l'index, l'assistant citera janvier avec la même assurance que s'il s'agissait de la règle en vigueur. Il ne sait pas qu'un document est ancien. Il sait seulement qu'il ressemble à la question.
Beaucoup de dirigeants le découvrent trop tard : six mois après un lancement réussi, une collaboratrice applique un barème qui n'existe plus parce que l'assistant le lui a donné. Personne n'avait prévu qui retirerait l'ancien barème, ni quand.
Les sources qui vieillissent : procédures, tarifs, organigrammes, réglementation
Toutes les sources ne vieillissent pas à la même vitesse. En pratique, quatre familles concentrent l'essentiel des réponses périmées.
Les procédures internes. Une note de service qui change la règle d'approbation des achats, un nouveau circuit de validation des congés. Ces documents changent par courriel ou dans un outil collaboratif, sans que la base RAG soit prévenue.
Les tarifs et conditions commerciales. Une grille de prix révisée chaque année, des conditions de livraison qui évoluent. Un assistant qui cite un tarif de l'année précédente à un commercial crée un litige. Un distributeur peut ainsi découvrir que son assistant annonce encore des délais de livraison abandonnés depuis deux trimestres.
Les plans et notices techniques posent la même difficulté sous une autre forme : deux révisions d'un même plan cohabitent souvent sur un serveur. Dans l'assistant documentaire d'une PME industrielle, la version du document fait partie des métadonnées de chaque passage, et c'est elle qui permet de ne pas servir l'ancienne révision au technicien.
Les organigrammes et annuaires. Qui est responsable de quoi, qui contacter pour une question RH. Ces informations changent à chaque mouvement de personnel, et un assistant qui renvoie vers une personne partie de l'entreprise fait perdre du temps à tout le monde.
La réglementation et les normes. Un cabinet d'expertise comptable, un acteur de la santé ou un industriel soumis à des normes de sécurité voit ses textes de référence évoluer régulièrement. Ici, une réponse périmée n'est pas seulement gênante : elle peut engager la responsabilité de l'entreprise.
Le point commun de ces quatre familles : la mise à jour du document source ne déclenche rien du côté de l'assistant. Il faut un mécanisme pour faire le lien, et c'est là que les deux options se séparent.
Option un : réindexer tout à intervalle fixe
La première approche est la plus simple à comprendre. À intervalle régulier, chaque semaine ou chaque mois selon l'activité, on vide l'index, on relit l'ensemble des sources dans leur état actuel et on reconstruit tout. Ce qui a été supprimé côté source disparaît de fait, ce qui a été modifié est repris dans sa dernière version.
Cette méthode a de vrais avantages. Elle ne demande aucun suivi fin des modifications : pas besoin de savoir quel fichier a bougé, on reprend tout. Elle est robuste face aux oublis, puisqu'un document périmé ne survit jamais au-delà du prochain cycle.
Elle a aussi des limites nettes. Entre deux cycles, l'assistant sert des informations qui peuvent avoir plusieurs semaines de retard. Le coût de traitement est proportionnel à la taille totale de la base, pas au volume de changements : réindexer des dizaines de milliers de pages pour cinquante documents modifiés coûte cher en calcul. Enfin, si le découpage des documents ou le modèle de vectorisation ont évolué entre deux cycles, l'ensemble des réponses peut changer d'un coup, sans que personne ait mesuré l'effet avant.
Une entreprise qui fonctionne ainsi finit souvent par entendre son service qualité dire aux équipes « attendez le mois prochain pour que l'assistant soit à jour ». C'est admettre que l'outil n'est pas fiable en cours de mois.
Option deux : mise à jour incrémentale avec retrait des sources périmées
La seconde approche traite chaque modification comme un événement. Quand un document est ajouté, modifié ou supprimé dans l'espace source, un mécanisme le détecte, met à jour les seuls passages concernés dans l'index et retire ceux qui n'ont plus de source. La base suit l'état des documents de près, au rythme des modifications détectées.
Techniquement, tout repose sur un détail posé dès la première indexation : chaque passage stocké dans la base vectorielle porte l'identifiant du document dont il vient, sa version et une empreinte de son contenu. Quand un document change, on compare les empreintes, on ne recalcule que les passages modifiés, et on supprime tous les passages rattachés à l'ancienne version par un simple filtre sur l'identifiant. Sans cet identifiant, retirer un document revient à chercher des passages orphelins un par un, et c'est là que naissent les réponses fantômes.
Ce fonctionnement demande davantage de rigueur au départ. Il faut détecter les changements de façon fiable, gérer les cas ambigus comme un document renommé ou dupliqué dans deux dossiers, et surtout s'assurer que le retrait fonctionne aussi bien que l'ajout. Beaucoup d'installations savent ajouter des documents et n'ont jamais été testées sur la suppression.
En échange, la fraîcheur est bien meilleure, le coût suit le volume réel de changements, et chaque mise à jour est un événement petit et identifiable. Si une réponse se dégrade, on sait quels documents ont bougé depuis la dernière fois qu'elle était correcte.
Le mot « supervisée » a son importance. Sans supervision, n'importe quel fichier déposé dans le bon dossier entre dans les réponses de l'assistant. Il faut au minimum une file de validation pour les nouvelles sources, un journal de ce qui est entré et sorti, et une alerte quand un volume anormal de documents change d'un coup, signe fréquent d'une migration ou d'une erreur de manipulation.
Le déclencheur est souvent un incident du type suivant, que nous décrivons pour l'exemple : une ancienne grille de mutuelle reste dans l'index de l'assistant RH trois semaines après le changement de contrat. Avec un flux incrémental, la nouvelle grille remplace l'ancienne dès que l'outil RH la publie, et le journal garde la trace du remplacement.
Comparatif sur quatre critères : fraîcheur, coût, risque de régression, traçabilité
Fraîcheur. L'incrémental gagne sans discussion. La réindexation complète impose un délai égal à la durée du cycle, et raccourcir ce cycle fait exploser le coût.
Coût. À petite échelle, quelques centaines de documents, la réindexation complète reste abordable et plus simple à exploiter. Au-delà de quelques milliers de pages, ou quand la base intègre des documents lourds comme des manuels techniques, le coût de la reconstruction périodique devient le premier poste de dépense d'inférence du projet. L'incrémental ne coûte que ce qui change.
Risque de régression. Les deux méthodes ont un profil de risque différent. La réindexation complète concentre le risque sur un moment : si quelque chose se passe mal, tout est touché en même temps, mais on peut tester la nouvelle base avant de la basculer en production. L'incrémental dilue le risque en petites touches quotidiennes, plus faciles à isoler, mais plus difficiles à surveiller sans outillage. Sans jeu de questions de contrôle, une dégradation lente passe inaperçue.
Traçabilité. L'incrémental offre par construction un journal des entrées et sorties, document par document. La réindexation complète peut le fournir aussi, à condition de comparer l'inventaire avant et après chaque cycle, ce que peu d'installations font. Pour un dirigeant qui doit répondre à la question « pourquoi l'assistant a-t-il dit ça le 12 du mois ? », l'incrémental avec journal est la seule option qui permet une réponse précise.
En pratique, une base de documentation technique stable peut vivre avec une réindexation trimestrielle et un contrôle sérieux à chaque cycle. Une base qui mêle procédures, tarifs et annuaire a besoin d'un flux incrémental, quitte à garder une reconstruction complète une fois par an pour repartir d'un état propre.
Vérifier la qualité des réponses après chaque mise à jour
Quelle que soit l'option retenue, une mise à jour sans vérification est un pari. Le mécanisme que nous mettons en place repose sur un jeu de questions de référence, quelques dizaines selon la taille de la base, avec la réponse attendue et les documents qui doivent être cités. Après chaque mise à jour, ce jeu est rejoué automatiquement et les écarts sont remontés à une personne.
Trois types d'écarts méritent une attention particulière. Une réponse qui cite un document qui devrait avoir disparu signale un retrait qui a échoué. Une réponse qui ne cite plus un document toujours valide signale un problème d'indexation ou de découpage. Une réponse dont le contenu change sans que les documents cités aient changé signale un effet de bord du modèle ou des paramètres de recherche, ce qui rejoint les causes décrites dans notre article sur l'IA qui hallucine en production.
Ce jeu de questions doit lui-même vivre : quand une procédure change, la réponse attendue change avec elle. C'est un travail modeste et régulier, le premier à disparaître quand personne n'en est responsable.
Ce suivi dans le temps fait partie du maintien des bases de connaissances RAG tel que nous le pratiquons dans une maintenance supervisée, avec les métriques d'évaluation d'un système RAG comme tableau de bord : la base est surveillée et les écarts sont repérés avant qu'un utilisateur ne les signale. Chaque mois, un rapport d'activité liste les documents entrés et sortis et les contrôles effectués.
Droits d'accès : un document retiré doit disparaître des réponses
Un cas particulier mérite un paragraphe à part, parce qu'il est fréquent et qu'il touche à la confidentialité. Quand un document est retiré de l'espace source pour une raison de droits, une note confidentielle déplacée dans un dossier restreint, un contrat archivé après un départ, un rapport qui ne doit plus être visible de tous, il doit cesser d'apparaître dans les réponses immédiatement, pas au prochain cycle mensuel.
Avec une réindexation complète, le document reste servi jusqu'à la reconstruction suivante, sauf procédure d'urgence. Avec un flux incrémental, le retrait est pris en compte dès que la modification est détectée. Dans les deux cas, il faut avoir testé que les passages du document ne survivent pas dans un cache de recherche ou un index secondaire.
Le même raisonnement s'applique aux droits par utilisateur. Chaque passage de l'index doit porter les droits du document dont il provient, et ces droits doivent suivre ceux du document. Un assistant qui répond à un stagiaire avec un extrait du plan de restructuration réservé au comité de direction est un incident, et il vient presque toujours d'une base dont les droits ont vieilli, pas du modèle.
Qui alimente la base, qui la contrôle : l'écrire au contrat
Les défaillances que nous rencontrons sur des bases RAG en service ont rarement une cause technique. Elles viennent d'une question restée sans réponse au moment du lancement : qui est responsable de la fraîcheur des documents ?
Il y a trois rôles à nommer. Le propriétaire de chaque source, qui décide qu'un document est à jour, périmé ou confidentiel. Le responsable de l'alimentation, qui fait entrer et sortir les documents de la base selon ces décisions, ou qui supervise le mécanisme automatique qui le fait. Et le contrôleur de la qualité, qui tient le jeu de questions de référence, lit les rapports et arbitre les écarts.
Ces rôles peuvent être portés en interne ou confiés à un prestataire, comme pour toute application en production, un sujet que nous traitons plus largement dans notre article sur les coûts cachés de la maintenance d'un RAG. Ce qui compte est qu'ils soient écrits, avec des engagements définis au contrat après l'audit de la base : fréquence des vérifications, contenu du rapport, délai de traitement des retraits urgents, et surtout ce qui reste chez le client, c'est-à-dire les documents, l'index, les journaux et les accès. Une entreprise qui ne peut pas récupérer sa base ni son historique de mises à jour en cas de changement de prestataire n'est pas propriétaire de son assistant.
Si votre base n'a pas encore été construite, notre guide sur la préparation d'une base documentaire RAG traite le travail initial. Si elle est déjà en service, la question n'est plus de savoir comment la préparer mais qui la fait vivre, avec quel mécanisme et quel contrôle. Un assistant qui répond juste au lancement et faux six mois plus tard n'a pas échoué techniquement : il a été abandonné.
