Un RAG en production ne se maintient pas tout seul : sans synchronisation des sources, sans réindexation et sans surveillance de la qualité, ses réponses se dégradent progressivement, même si personne n'y touche. La maintenance recouvre quatre volets concrets : synchroniser les documents (ajouts, modifications, suppressions), réindexer après un changement de modèle ou d'embeddings, mesurer la dérive de qualité, et désigner qui en est responsable dans la durée.
C'est le point aveugle de nombreux projets : tout le budget et l'attention se concentrent sur la mise en production, et rien n'est prévu pour l'après. Six mois plus tard, le corpus contient des documents obsolètes, personne ne sait qui doit ajouter les nouveaux, et la qualité perçue par les utilisateurs a baissé sans qu'un incident précis ne l'explique.
Cet article détaille ce qui doit être synchronisé, ce qu'implique un changement de modèle, comment repérer une dérive avant qu'elle ne devienne visible, les coûts récurrents à prévoir, et qui doit porter cette responsabilité.
En bref
- Un RAG se dégrade même sans changement volontaire : sources qui évoluent, modèle mis à jour par le fournisseur, vocabulaire des utilisateurs qui change
- La synchronisation incrémentale des sources (ajouts, modifications, suppressions) doit être automatisée, pas déclenchée manuellement au coup par coup
- Changer de modèle d'embeddings impose une réindexation complète du corpus, jamais un mélange d'anciens et de nouveaux vecteurs
- La dérive se détecte en rejouant un jeu de test de référence régulièrement, croisé avec les signaux utilisateur
- La maintenance a un coût récurrent distinct du coût initial, et doit être confiée à une équipe ou un prestataire identifié avant la mise en production
Le risque silencieux : un RAG qui se dégrade sans qu'on y touche
Un RAG en entreprise n'est pas un logiciel statique livré puis figé. C'est un système dont la qualité dépend directement de la fraîcheur de son corpus et de la cohérence de son pipeline technique. Sans entretien, quatre phénomènes se combinent, chacun invisible pris isolément.
Les documents sources évoluent : une procédure est mise à jour, un contrat est renouvelé, une ancienne version reste indexée alors qu'elle ne fait plus référence. Le fournisseur du modèle de langage met à jour sa version en coulisses, parfois sans annonce visible, ce qui modifie légèrement le comportement de génération. Le vocabulaire des utilisateurs change à mesure que l'outil se diffuse dans l'entreprise, avec des formulations que le jeu de test initial ne couvrait pas. Et de nouveaux sujets apparaissent sans qu'aucun document ne les documente encore.
Pris isolément, aucun de ces changements ne provoque de panne. Ensemble et dans la durée, ils expliquent pourquoi un RAG jugé excellent à son lancement déçoit un an plus tard, sans qu'un incident unique ne permette de l'expliquer.
Synchroniser les sources : ajouts, modifications, suppressions, versions
La première brique de maintenance consiste à garder le corpus indexé aligné avec la réalité des sources documentaires : SharePoint, Google Drive, une GED, un espace de documentation interne. Trois types d'événements doivent être suivis en continu.
Synchronisation incrémentale contre réindexation complète
Une synchronisation incrémentale détecte les documents ajoutés, modifiés ou supprimés depuis la dernière exécution, et ne retraite que ceux-là. C'est l'approche à privilégier au quotidien : elle est rapide, peu coûteuse en appels au modèle d'embeddings, et peut tourner plusieurs fois par jour sans effort notable.
Une réindexation complète du corpus reste nécessaire dans des cas précis : changement de stratégie de chunking, changement de modèle d'embeddings, ou doute sérieux sur la fiabilité de la synchronisation incrémentale après une longue période sans contrôle. Elle est plus coûteuse et doit être planifiée, pas déclenchée en urgence un vendredi soir.
Suivre les versions de documents
Un même sujet est souvent couvert par plusieurs versions successives d'un document : une procédure v1, v2, v3. Si l'ancienne version reste indexée après la publication de la nouvelle, le RAG peut répondre avec une information périmée, parfois contradictoire avec la version actuelle. Le pipeline de synchronisation doit identifier explicitement qu'un document remplace un autre, retirer l'ancien de l'index, et ne conserver qu'une trace d'audit de son existence passée si nécessaire.
Quand la contradiction ne vient pas d'une version obsolète restée indexée, mais de deux documents distincts en vigueur qui se contredisent, c'est le travail de notre agent de détection des incohérences documentaires.
Changer de modèle ou d'embeddings : ce que ça implique
Un changement de modèle de langage ou de modèle d'embeddings n'est jamais une opération anodine sur un RAG déjà en production. Les deux cas se traitent différemment.
Changer de modèle de génération (par exemple passer d'une version de modèle à une autre chez le même fournisseur, ou changer de fournisseur) modifie la façon dont les passages récupérés sont formulés en réponse, sans toucher au retrieval. Le risque porte sur le style, la fidélité aux sources et le respect des instructions de prompt, qu'il faut revérifier sur le jeu de test.
Changer de modèle d'embeddings est plus structurant : les nouveaux vecteurs ne sont pas comparables aux anciens dans le même espace mathématique. Le Top 10 OWASP pour les applications LLM classe d'ailleurs les faiblesses liées aux vecteurs et aux embeddings parmi les risques propres aux architectures RAG. Mélanger des vecteurs issus de deux modèles différents dans un même index casse silencieusement la recherche par similarité, sans erreur visible, seulement une baisse progressive de pertinence. Ce changement impose une réindexation intégrale du corpus avec le nouveau modèle, puis une nouvelle baseline d'évaluation RAG pour confirmer que le changement améliore réellement les résultats plutôt que de simplement déplacer le problème.
| Changement | Action requise | Risque si ignoré |
|---|---|---|
| Document modifié ou supprimé dans la source | Synchronisation incrémentale | Réponse construite sur une information périmée |
| Changement de modèle de génération | Rejeu du jeu de test, ajustement du prompt si besoin | Dérive du ton, de la fidélité ou du format de réponse |
| Changement de modèle d'embeddings | Réindexation complète du corpus | Recherche par similarité incohérente, baisse silencieuse du recall |
| Ajout d'une nouvelle source documentaire | Vérification des droits d'accès avant indexation | Documents mal indexés ou accessibles aux mauvais profils |
Ce dernier point rejoint directement notre article sur les droits d'accès dans un RAG multi-tenant : chaque nouvelle source ajoutée en cours de vie du système doit repasser par la même vérification de permissions que lors du déploiement initial, pas seulement lors de la conception.
Détecter la dérive de qualité : jeu de référence et signaux utilisateur
Une dérive de qualité se manifeste rarement par un effondrement brutal et visible. Elle se traduit d'abord par une baisse progressive sur une catégorie précise de questions, souvent liée à l'un des changements silencieux décrits plus haut. C'est pour cela que l'absence de surveillance finit toujours par se voir, même sans incident isolé.
Le réflexe le plus fiable reste celui déjà détaillé dans notre article sur la baseline d'évaluation RAG : rejouer périodiquement le même jeu de questions de référence, et comparer le score obtenu à la mesure initiale. Un contrôle mensuel sur l'ensemble du jeu de test, complété par un suivi hebdomadaire léger sur un échantillon de requêtes réelles, suffit pour la plupart des PME à détecter une dérive avant qu'elle ne devienne un motif de plainte généralisé.
Le signal le plus précoce n'est souvent pas la métrique automatique, mais le comportement des utilisateurs : une hausse des reformulations de la même question, un retour au collègue ou au moteur de recherche interne pour un sujet auparavant traité par le RAG, ou une accumulation de questions restées sans réponse exploitable. Si les symptômes ressemblent à ceux décrits dans notre diagnostic d'un RAG qui répond à côté, la cause est souvent à chercher du côté de la maintenance plutôt que de l'architecture d'origine.
Les coûts récurrents d'un RAG en production
La maintenance a un coût qui s'ajoute au budget de développement initial détaillé dans notre article sur le coût d'un projet RAG. Trois postes reviennent systématiquement une fois le système en production.
- L'infrastructure récurrente : hébergement de la base vectorielle, appels au modèle de langage pour la génération, appels au modèle d'embeddings pour chaque nouveau document indexé.
- Le temps de synchronisation et de surveillance : entretien du pipeline d'ingestion, contrôle mensuel de la baseline, traitement des alertes de dérive.
- Les interventions ponctuelles : ajout d'une nouvelle source documentaire, changement de modèle, correction d'un problème de retrieval identifié en surveillance.
Un projet cadré sans ce budget récurrent découvre souvent le coût de la maintenance au pire moment : quand le système se dégrade déjà et qu'il faut agir dans l'urgence plutôt que dans un cadre anticipé.
Qui s'en occupe : équipe interne, prestataire, réversibilité
La question de la responsabilité doit être tranchée avant la mise en production, pas après les premiers signes de dérive. Trois configurations existent, chacune avec ses conditions de réussite.
Une équipe technique interne peut assumer la synchronisation des sources et la surveillance courante si elle dispose d'un temps dédié identifié, pas seulement d'une bonne volonté diffuse, et d'une méthode documentée pour rejouer les tests de qualité. C'est l'option la plus économique à moyen terme, à condition que ce temps ne soit pas systématiquement absorbé par des priorités jugées plus urgentes.
Un contrat de maintenance avec un prestataire, qu'il s'agisse de celui qui a construit le système ou d'un tiers formé à son architecture, évite cette dilution de priorité. Il implique de définir précisément le périmètre couvert (synchronisation, surveillance, correction) et la fréquence des interventions, pour ne pas découvrir a posteriori que certaines tâches n'étaient couvertes par personne.
Dans les deux cas, la question de la réversibilité et de la dépendance à un prestataire IA doit être posée dès le contrat initial : le code, les données d'indexation et la documentation du pipeline doivent rester exploitables par une autre équipe si la relation avec le prestataire s'arrête, sans devoir reconstruire le système depuis zéro.
Chez Tensoria, la maintenance d'un RAG fait l'objet d'un cadrage explicite dès le développement initial : ce qui est synchronisé automatiquement, ce qui reste sous supervision humaine, et à quelle fréquence la baseline est rejouée. Pour un système déjà en place qui montre des signes de dérive, l'accompagnement consiste d'abord à fiabiliser un RAG en production avant d'envisager toute reconstruction, sur devis selon le périmètre à couvrir.
Questions fréquentes
Articles recommandés
- Baseline d'évaluation RAG : la méthode pour mesurer la dérive de qualité et prouver qu'un correctif fonctionne.
- Mon RAG répond à côté : l'ordre de diagnostic à suivre quand la qualité perçue baisse en production.
- Coût d'un projet RAG : les postes de dépense du POC à la production, et le TCO sur un an.
- Droits d'accès et sécurité d'un RAG multi-tenant : pourquoi chaque nouvelle source ajoutée doit repasser par une vérification des permissions.
- Dépendance à un prestataire IA : comment garantir la réversibilité d'un projet, y compris pour sa maintenance.
- 5 erreurs qui font échouer un projet RAG : l'absence de suivi après déploiement, un piège classé parmi les plus coûteux.
