Votre assistant IA répond correctement à une question sur les conditions commerciales de l’entreprise, retrouve le bon document dans sa base de connaissances et formule une réponse parfaitement cohérente. Tout semble fonctionner comme prévu, jusqu’au moment où vous découvrez que le document utilisé a été remplacé plusieurs semaines auparavant.
Le modèle n’a pourtant rien inventé et le moteur de recherche a correctement retrouvé une information correspondant à la question. Le problème vient simplement du fait que l’intelligence artificielle a utilisé une connaissance devenue obsolète.
Cette situation illustre l’un des risques les plus discrets des architectures RAG : la fraîcheur des connaissances.
À mesure que les entreprises connectent leurs assistants IA à SharePoint, Google Drive, leurs bases documentaires, leurs CRM, leurs procédures internes ou leurs catalogues produits, il ne suffit plus de vérifier que le système retrouve une information pertinente. Il faut également s’assurer qu’il retrouve la bonne version de cette information au bon moment.
Le RAG résout un problème, mais en crée un nouveau
Le RAG, ou Retrieval-Augmented Generation, permet à une intelligence artificielle de rechercher des informations dans une base documentaire avant de générer sa réponse.
Cette approche est particulièrement intéressante pour les entreprises, car elle permet d’utiliser des connaissances internes sans devoir réentraîner en permanence le modèle. Les informations peuvent provenir de procédures, de catalogues, de contrats, de documentations techniques ou de bases de connaissances métier.
Nous avons déjà présenté cette approche dans notre article consacré au RAG, au fine-tuning et à LoRA, qui détaille les principales méthodes permettant d’adapter une intelligence artificielle aux données et aux besoins spécifiques d’une organisation.
Le fonctionnement simplifié d’un RAG peut être résumé ainsi :
Documents → indexation → recherche → contexte transmis au modèle → réponse
Ce mécanisme permet à l’IA d’utiliser des informations beaucoup plus récentes que celles contenues dans son entraînement initial.
Il introduit cependant une nouvelle responsabilité : maintenir la base documentaire réellement utilisée par l’IA à jour.
Si l’entreprise modifie une procédure mais que l’ancienne version reste dans l’index, le RAG peut continuer à la retrouver. Le modèle recevra alors une information parfaitement pertinente sur le plan sémantique, mais incorrecte sur le plan métier.
Pourquoi un document supprimé peut-il encore être utilisé par l’IA ?
Le principal piège vient du fait que le document visible par les collaborateurs et la donnée réellement exploitée par le RAG ne sont pas toujours la même chose.
Lorsqu’un fichier est ajouté à une architecture RAG, son contenu est généralement analysé, découpé en fragments puis indexé afin de faciliter les recherches futures.
Le processus ressemble donc davantage à ceci :
Document source → ingestion → découpage → indexation → recherche → génération
Si le document original est ensuite modifié ou supprimé, ces changements doivent être propagés jusqu’à l’index utilisé par le système.
Sans mécanisme de synchronisation correctement configuré, un document peut disparaître de SharePoint ou d’un dossier partagé tout en restant présent dans la base vectorielle.
Pour l’utilisateur, le fichier n’existe plus.
Pour l’IA, son contenu peut toujours être parfaitement disponible.
Cette situation est particulièrement problématique parce qu’aucune erreur technique visible ne se produit. Le RAG continue de fonctionner normalement et retourne des réponses cohérentes, simplement à partir d’informations qui ne devraient plus être utilisées.
Quand plusieurs versions d’un même document se retrouvent en concurrence
La suppression n’est pas le seul problème. Dans de nombreuses entreprises, plusieurs versions d’un même document coexistent pendant des mois.
Un dossier peut par exemple contenir :
Tarifs-2025.pdfTarifs-2026.pdfTarifs-2026-v2.pdfTarifs-2026-FINAL.pdf
Un collaborateur connaissant le dossier comprend généralement quelle version est la plus récente.
Un moteur de recherche vectoriel ne raisonne pas nécessairement de cette manière. Il cherche avant tout les passages dont le contenu correspond le mieux à la question posée.
Les quatre fichiers contenant presque le même vocabulaire et décrivant les mêmes produits, ils peuvent tous apparaître comme d’excellentes sources potentielles.
Si l’ancienne version correspond légèrement mieux à la formulation de la question, elle peut être sélectionnée avant la nouvelle.
L’IA produira alors une réponse précise, cohérente et totalement obsolète.
Pertinence et fraîcheur ne doivent pas être confondues
C’est l’un des points essentiels à comprendre lorsqu’on construit une base RAG.
Un document peut être :
très pertinent pour une question et pourtant ne plus être valide.
Une recherche sémantique répond principalement à la question :
« Quel contenu ressemble le plus à ce que cherche l’utilisateur ? »
Elle ne répond pas automatiquement à une autre question tout aussi importante :
« Cette information est-elle encore applicable aujourd’hui ? »
Une architecture RAG mature doit donc tenir compte de deux dimensions distinctes : la pertinence du contenu et sa fraîcheur.
Quels documents sont les plus sensibles au vieillissement ?
Toutes les connaissances de l’entreprise n’évoluent évidemment pas à la même vitesse.
Une présentation historique peut rester parfaitement valable plusieurs années, tandis qu’une liste de prix ou un niveau de stock peut devenir faux en quelques minutes.
Les informations nécessitant généralement une attention particulière concernent notamment :
- les tarifs et promotions ;
- les stocks et disponibilités ;
- les conditions commerciales ;
- les procédures internes ;
- les informations produits ;
- les règles RH ;
- les responsabilités et organigrammes ;
- les données réglementaires ;
- les consignes de sécurité ;
- les coordonnées et contacts ;
- les données financières.
La bonne question n’est donc pas simplement de savoir à quelle fréquence la base RAG est synchronisée.
Il faut surtout déterminer combien de temps chaque catégorie d’information peut raisonnablement rester inchangée avant de devenir problématique.
Définir une fraîcheur cible selon les données
Une entreprise peut commencer avec une matrice très simple.
| Type de connaissance | Exemple de fraîcheur cible |
|---|---|
| Stocks et disponibilités | Quasi temps réel |
| Tarifs et promotions | Quelques minutes à quelques heures |
| Annuaire interne | Quelques heures |
| Procédures opérationnelles | Moins de 24 h après modification |
| Documentation produit | Quelques heures à 1 jour |
| Documentation technique stable | Quelques jours |
| Archives historiques | Plusieurs semaines ou mois |
Ces délais ne constituent pas une norme universelle. Ils doivent dépendre du secteur, du cas d’usage et surtout des conséquences d’une réponse obsolète.
Un retard d’une journée dans la mise à jour d’une documentation technique interne peut être acceptable, alors que le même délai appliqué à un tarif affiché aux clients peut générer immédiatement des problèmes commerciaux.
1. Identifier clairement la source de vérité
La première étape consiste à déterminer quel système possède l’information officielle pour chaque catégorie de données.
Si un même tarif existe simultanément dans l’ERP, un fichier Excel, plusieurs PDF et un document partagé dans Teams, l’intelligence artificielle ne peut pas deviner quelle version doit être considérée comme prioritaire.
L’entreprise doit donc identifier une source de vérité.
Pour les tarifs, il peut s’agir de l’ERP. Pour les données clients, le CRM. Pour les procédures internes, SharePoint. Pour la documentation produit, un PIM ou une base documentaire dédiée.
Le RAG doit ensuite utiliser cette source de référence ou appliquer une règle de priorité suffisamment claire pour éviter que plusieurs versions entrent en concurrence.
2. Ajouter des métadonnées sur le cycle de vie des documents
Le contenu d’un fichier ne permet pas toujours de savoir s’il est encore valable.
Il devient alors intéressant d’associer aux documents des informations supplémentaires telles que :
- la date de création ;
- la date de dernière modification ;
- le numéro de version ;
- la date de début de validité ;
- la date de fin de validité ;
- le propriétaire du document ;
- la source d’origine ;
- le statut : actif, brouillon, archivé ou supprimé.
Ces métadonnées permettent ensuite d’appliquer des règles beaucoup plus précises au moment de la recherche.
Un système peut par exemple privilégier uniquement :
status = active
ou exclure automatiquement :
valid_until < aujourd’hui
Cette logique évite de demander au modèle de déterminer lui-même si un document doit encore être utilisé.
3. Synchroniser les modifications suffisamment rapidement
La fréquence de mise à jour doit être adaptée aux informations concernées.
Une synchronisation nocturne peut être largement suffisante pour une documentation technique qui change rarement, mais complètement inadaptée à des stocks ou à des tarifs susceptibles d’évoluer plusieurs fois dans la journée.
Il faut donc mesurer un indicateur simple :
combien de temps s’écoule entre la modification de la source officielle et la disponibilité de cette modification pour l’intelligence artificielle ?
Ce délai constitue en quelque sorte la latence documentaire du RAG.
Plus les informations sont critiques, plus ce délai doit être réduit.
4. Tester explicitement la suppression des documents
Une architecture RAG ne doit pas seulement être capable d’ajouter et de modifier des connaissances.
Elle doit aussi savoir oublier.
Lorsqu’un document est supprimé de la source, l’entreprise doit pouvoir vérifier qu’il disparaît également des résultats accessibles à l’IA.
Il est utile de tester régulièrement plusieurs questions :
Le document supprimé existe-t-il encore dans l’index ?
Ses fragments peuvent-ils toujours apparaître dans une recherche ?
Combien de temps faut-il avant qu’ils deviennent réellement inaccessibles ?
Une synchronisation ultérieure risque-t-elle de réintroduire le contenu ?
Cette dernière question est particulièrement importante lorsque plusieurs sources ou mécanismes d’ingestion alimentent la même base.
5. Ne pas confondre archivage et disponibilité pour l’IA
Une entreprise peut parfaitement avoir besoin de conserver ses anciennes procédures, ses anciens tarifs ou ses contrats passés.
Cela ne signifie pas que ces informations doivent rester accessibles au RAG utilisé pour répondre aux questions actuelles.
Il faut donc distinguer deux notions :
la conservation du document et son utilisation par l’intelligence artificielle.
Une ancienne politique RH peut rester dans les archives pendant plusieurs années tout en étant complètement exclue des réponses données aux collaborateurs.
Cette distinction permet d’éviter une situation dans laquelle la base RAG devient progressivement un immense mélange de contenus actuels et historiques que le modèle doit essayer d’interpréter.
6. Afficher la source et sa date dans les réponses
La transparence constitue également un excellent mécanisme de contrôle.
Une réponse comme :
Le délai prévu est de 30 jours.
ne permet pas à l’utilisateur de savoir d’où vient l’information.
Une réponse indiquant :
Source : Conditions commerciales, version du 8 août 2026.
permet immédiatement de vérifier si la connaissance utilisée semble suffisamment récente.
Les citations ne servent donc pas uniquement à lutter contre les hallucinations. Elles permettent également aux collaborateurs de contrôler la fraîcheur de la documentation utilisée par l’IA.
Cela devient particulièrement intéressant lorsque les réponses influencent des décisions commerciales, contractuelles ou opérationnelles.
7. Tester volontairement les mauvaises versions
Un bon jeu de tests RAG ne doit pas uniquement vérifier que la dernière documentation produit une bonne réponse.
Il doit également inclure volontairement plusieurs situations problématiques :
- une procédure récente et son ancienne version ;
- un fichier officiellement supprimé ;
- un document archivé ;
- deux documents contenant des informations contradictoires ;
- un document ayant dépassé sa date de validité.
L’objectif consiste ensuite à vérifier que le système sélectionne correctement la version actuelle ou, lorsqu’il ne peut pas déterminer quelle information est correcte, signale le conflit au lieu de choisir arbitrairement une réponse.
Cette démarche rejoint directement celle de la recette métier d’une IA : la solution ne doit pas seulement réussir les situations simples, elle doit également adopter le bon comportement lorsque les données sont imparfaites.
Le problème existe également avec les assistants IA utilisant simplement des fichiers
La fraîcheur des connaissances ne concerne pas uniquement les grandes architectures RAG développées sur mesure.
De nombreux collaborateurs utilisent désormais des espaces de travail dans lesquels ils déposent directement des documents pour fournir un contexte permanent à leur intelligence artificielle.
Nous avions notamment présenté ce fonctionnement dans notre article consacré aux Projets ChatGPT et à l’organisation de conversations, fichiers et instructions dans un même espace.
Cette approche simplifie considérablement l’utilisation quotidienne, mais elle introduit exactement le même problème.
Si un collaborateur importe une grille tarifaire en janvier et continue à interroger son projet en septembre sans remplacer le fichier, l’IA n’a aucun moyen de savoir qu’un nouveau document existe ailleurs.
Le modèle utilisera simplement les connaissances disponibles dans son contexte.
La gouvernance documentaire devient donc importante aussi bien pour un RAG industrialisé que pour un simple assistant utilisé par une équipe.
Exemple : quand un chatbot RH connaît deux politiques différentes
Prenons une entreprise utilisant un assistant interne pour répondre aux questions de ses salariés.
Deux documents sont présents dans la base :
Politique-télétravail-2025.pdf
Maximum de deux jours par semaine.
Politique-télétravail-2026.pdf
Maximum de trois jours par semaine.
Un salarié demande combien de jours il peut travailler à distance.
Les deux documents sont pertinents, car ils parlent exactement du même sujet. Si l’ancienne version obtient un meilleur score de recherche, elle peut être transmise au modèle.
L’assistant répond alors que le salarié peut télétravailler deux jours.
Il n’y a pourtant eu aucune hallucination, aucun problème de compréhension et aucune panne technique.
La gouvernance documentaire a simplement laissé deux vérités contradictoires accessibles à l’IA.
Cette distinction est essentielle, car changer de modèle ne résoudrait absolument pas le problème.
Mesurer l’âge réel des connaissances utilisées par le RAG
Une fois le système en production, plusieurs indicateurs permettent de surveiller sa qualité documentaire.
Le premier est le délai de synchronisation, c’est-à-dire le temps séparant la modification d’un document de sa disponibilité dans le RAG.
Il est également possible de suivre l’âge moyen des documents réellement utilisés pour produire les réponses, le nombre de sources dépassant leur date de révision ou encore le pourcentage de documents sans propriétaire clairement identifié.
Un autre indicateur particulièrement intéressant concerne le temps de propagation d’une suppression. Il permet de savoir combien de temps une information supprimée reste potentiellement accessible à l’intelligence artificielle.
Ces mesures permettent de transformer la fraîcheur documentaire en un problème observable et pilotable plutôt qu’en une simple hypothèse.
Un modèle plus puissant ne corrigera pas une mauvaise base documentaire
Lorsqu’une intelligence artificielle fournit de mauvaises réponses, la première réaction consiste souvent à incriminer le modèle.
L’entreprise peut être tentée de remplacer GPT par Claude, Gemini par une version plus récente ou un modèle économique par une solution plus puissante.
Dans une architecture RAG, cette stratégie peut être totalement inefficace.
Si la base contient plusieurs procédures contradictoires, aucun modèle ne peut deviner de manière fiable laquelle correspond réellement à la politique actuelle de votre entreprise.
Une IA plus performante peut éventuellement détecter que deux sources se contredisent, mais la décision concernant l’autorité documentaire appartient à l’organisation.
C’est pourquoi la qualité d’un RAG repose autant sur la gouvernance des connaissances que sur le choix du modèle.
Dixie Consulting avait d’ailleurs présenté un exemple concret d’utilisation de cette technologie dans son article consacré à l’utilisation de ChatGPT et du RAG chez Safran, qui illustre la manière dont les entreprises peuvent connecter l’intelligence artificielle à leurs propres données de référence.
Une checklist pour vérifier la fraîcheur de votre RAG
Avant de considérer une base documentaire IA comme réellement maîtrisée, plusieurs questions doivent obtenir une réponse claire.
Savez-vous quelle source représente la vérité pour chaque information importante ? Connaissez-vous le délai entre une modification et sa prise en compte par l’IA ? Les suppressions sont-elles correctement répercutées dans la base utilisée par le RAG ? Les anciennes versions peuvent-elles encore apparaître dans les résultats ?
Il faut également vérifier que chaque document important possède une date, une version et idéalement un propriétaire métier, tout en s’assurant que les contenus archivés ou expirés puissent être exclus des recherches opérationnelles.
Enfin, les utilisateurs devraient pouvoir identifier les sources utilisées par l’assistant lorsqu’une information possède un impact significatif sur leur travail.
Si plusieurs de ces éléments ne sont pas maîtrisés, votre RAG peut parfaitement fonctionner sur le plan technique tout en travaillant avec une base de connaissances devenue progressivement incohérente.
Le véritable défi du RAG n’est plus seulement d’accéder à l’information
Les premiers projets RAG cherchaient principalement à résoudre une question :
Comment permettre à une intelligence artificielle d’utiliser les connaissances de l’entreprise ?
Lorsque ces architectures passent en production, une deuxième question devient tout aussi importante :
Comment s’assurer que les connaissances utilisées sont toujours les bonnes ?
Une architecture RAG fiable doit donc être capable d’ajouter une information, de la retrouver et de la citer, mais également de la modifier, de l’archiver et de la supprimer au bon moment.
La fraîcheur devient ainsi une composante essentielle de la qualité globale du système.
Un excellent modèle connecté à une documentation périmée continuera à produire des réponses obsolètes. À l’inverse, une base correctement synchronisée, disposant de sources clairement identifiées et d’un véritable cycle de vie documentaire permet de conserver l’un des principaux avantages du RAG : faire évoluer les connaissances accessibles à l’intelligence artificielle sans devoir réentraîner continuellement le modèle.
Dixie Consulting vous accompagne dans vos projets RAG et IA
Mettre en place un RAG ne consiste pas uniquement à générer des embeddings et à connecter une base vectorielle à un modèle de langage.
Il faut également identifier les sources fiables, structurer les documents, définir leur cycle de vie, automatiser les synchronisations, gérer les versions et vérifier le comportement du système lorsque plusieurs informations se contredisent.
Dixie Consulting accompagne les TPE et PME dans la conception et l’intégration de solutions d’intelligence artificielle adaptées à leurs processus et à leurs données.
L’objectif est de construire des assistants capables non seulement de retrouver une information pertinente, mais surtout de travailler avec une connaissance réellement à jour, fiable et maîtrisée.
