Prévenir l'empoisonnement des données RAG : provenance des sources, quarantaine et tests de réindexation

Un chatbot de site web peut fournir une réponse polie, linguistiquement convaincante et techniquement correcte, tout en s'appuyant sur une base de connaissances empoisonnée. Dans le cas de l'empoisonnement des données RAG, la formulation d'une requête individuelle n'est pas la cible principale de la manipulation. Au lieu de cela, des contenus faux, altérés ou insuffisamment vérifiés s'introduisent dans la chaîne de traitement de données permanente : source, parseur, chunk, métadonnées, embedding et enfin l'index de recherche opérationnel. L'erreur persiste ainsi sur de nombreuses sessions et peut également impacter des questions ordinaires.

Une protection efficace commence donc bien avant le prompt. Les équipes doivent être en mesure de répondre, pour chaque élément de connaissance : d'où vient-il, qui en est responsable, quelle version a été traitée, quelles transformations ont eu lieu et quelle vérification a validé sa publication pour la recherche ? La provenance des sources fournit cette traçabilité. Une zone de quarantaine isolée sur le plan technique permet d'éviter que des modifications non vérifiées ne deviennent immédiatement accessibles. Des tests de réindexation ciblés permettent ensuite de vérifier si les contenus nettoyés ont effectivement remplacé les anciens chunks.

Ce qu'est l'empoisonnement des données RAG – et ce qu'il n'est pas

La classification OWASP LLM04:2025 sur le Data and Model Poisoning décrit les manipulations des données de pré-entraînement, de fine-tuning ou d'embedding comme un risque majeur pour l'intégrité. Pour un chatbot de site web, la dernière variante est particulièrement concrète : un document est ingéré puis découpé en segments ; ces chunks sont convertis en vectorisations (embeddings) et stockés sous forme de vecteurs dans l'index de recherche. Si ce document est altéré, intentionnellement ou par accident, il peut apparaître comme une source d'information apparemment pertinente lors de requêtes correspondantes.

Les risques doivent être distingués, même s'ils peuvent se recouper : le prompt injection cherche à injecter des instructions ou des données à l'exécution afin d'altérer le comportement prévu du système ; le prompt injection indirect peut alors s'infiltrer dans le contexte via les documents récupérés. À l'inverse, l'empoisonnement des données altère le fonds de connaissances à long terme ou ses produits dérivés. Les droits d'accès traitent un autre sujet : ils définissent quelle personne est autorisée à consulter un document. La provenance et la validation déterminent si ce document doit intégrer l'index en tant que source de connaissances fiable. Au sein d'une architecture résiliente, ces trois risques nécessitent des contrôles dédiés et des articulations adaptées.

La surface d'attaque couvre l'ensemble de la chaîne de données

Un index RAG provient rarement d'une collection unique contrôlée manuellement. Des crawlers analysent des sites web, des connecteurs synchronisent des dossiers cloud, des utilisateurs téléversent des fichiers et des interfaces importent des données produits. À cela s'ajoutent les parseurs, l'OCR, le nettoyage linguistique, le chunking et l'enrichissement en métadonnées. Chaque étape peut intégrer du contenu erroné ou isoler une affirmation initialement exacte de son contexte d'origine.

Les causes typiques incluent un système source compromis, un document miroir nouvellement lié, un fichier brouillon publié par erreur, une mauvaise attribution de locataire (tenant), ou une mise à jour de parseur associant des valeurs de tableau à de mauvais en-têtes. La comparaison d'une empreinte cryptographique (hash) du contenu avec une valeur de référence fiable permet de détecter les écarts ; toutefois, un hash conforme ne garantit ni la véracité, ni l'actualité, ni la validation du contenu.

La provenance sous forme de jeu de données auditable

Chaque document et chaque chunk qui en découle devrait être associé à un enregistrement de provenance. Sur le plan pratique, les éléments essentiels sont au minimum : un identifiant de source stable, l'URL d'origine canonique, le propriétaire responsable, la date d'extraction, la version du document, le hash du contenu, le statut de validation, la classe de confiance, la version du parseur, la version de découpage (chunking), le modèle d'embedding et la génération d'index. Pour les téléversements manuels, s'ajoutent le rôle de l'utilisateur et la licence vérifiée. Dans les systèmes synchronisés, il convient également de tracer le connecteur authentifié par lequel le fichier a été acheminé.

Le NIST AI 600-1 Generative AI Profile aborde la provenance du contenu (Content Provenance), la documentation traçable ainsi que les tests et évaluations comme des piliers essentiels de la gestion des risques de l'IA générative. Appliqué aux systèmes RAG, cela signifie que l'index actuel n'est pas le seul élément qui compte. La relation traçable entre la révision source, le cycle de traitement et la génération d'index publiée fait partie intégrante de la documentation d'exploitation.

La quarantaine sépare l'ingestion de la publication

Un composant d'architecture central réside dans la séparation stricte : les contenus nouveaux ou modifiés ne deviennent pas immédiatement recherchables. Ils transitent d'abord par une zone d'ingestion. La pipeline y valide l'origine, le type de fichier, la taille, la signature ou le hash attendu, le locataire autorisé, l'exhaustivité des métadonnées et l'ampleur des modifications. Ce n'est qu'après cela que le texte et les chunks sont générés dans une version d'index non productive.

Les règles doivent s'appuyer sur une évaluation des risques. Une modification apportée à une page FAQ interne authentifiée et sous responsabilité identifiée peut être validée après des tests automatisés. En revanche, un nouveau domaine, une modification de texte anormalement volumineuse, un propriétaire de fichier inconnu ou une source sans responsable désigné doivent déclencher une quarantaine et une révision humaine. En cas d'absence d'une information obligatoire, la règle du « fail closed » s'applique : l'ancienne génération validée reste active ; la nouvelle version n'est pas publiée silencieusement.

La validation sous forme de génération d'index immuable

Après validation, l'index de production ne doit pas être écrasé progressivement. La bonne pratique consiste à créer une nouvelle génération versionnée accompagnée d'un manifeste : documents attendus, chunks attendus, hashes sources, versions de transformation et horodatages. Une fois les tests validés, un alias ou une configuration de routage bascule de manière atomique vers cette génération. La génération précédente demeure restaurable pendant une période définie.

Cette méthode s'apparente à une migration contrôlée. Notre article sur la transition d'un modèle d'embedding RAG explique pourquoi les générations d'index parallèles et les tests comparatifs sont précieux lors de changements techniques. En cas de suspicion d'empoisonnement, s'ajoute une question de sécurité : quelle révision source et quels chunks dérivés doivent être bloqués ?

Scénario d'exemple fictif : un délai de retour erroné s'infiltre dans le bot de support

Imaginons qu'un commerçant exploite un chatbot pour répondre aux questions sur ses produits et services. La base de connaissances synchronise chaque nuit le centre d'aide officiel et quelques portails constructeurs autorisés. À la suite d'un changement de lien, un connecteur suit une redirection vers une page miroir non approuvée. Sur celle-ci, un PDF d'apparence plausible affiche un délai de retour de 90 jours au lieu de 30. Le fichier est découpé en chunks ; plusieurs sections se retrouvent dans l'index avec une forte similarité sémantique.

Le lendemain matin, le bot promet un mauvais délai lors des demandes de retour. Le modèle de langage n'a pas été reprogrammé et les utilisateurs n'ont injecté aucune instruction malveillante. Le composant de récupération (Retrieval) a simplement fourni une base erronée. Le système de monitoring déclenche une alerte car un nouveau domaine apparaît pour la première fois comme source de réponse et un test sur jeu de données de référence (Golden Set) pour le délai de retour s'écarte du résultat attendu.

Processus contrôlé de quarantaine et de reprise d'activité

1. L'équipe interrompt uniquement la source d'ingestion concernée et gèle la génération d'index actuelle pour éviter toute modification supplémentaire.
2. L'ID du document suspect, l'ensemble des ID de chunks dérivés et les réponses dans lesquelles ils ont été retrouvés sont consignés dans le rapport d'incident.
3. Le domaine miroir est bloqué et ses chunks sont transférés en quarantaine. Pour les questions relatives au délai de retour, le bot affiche temporairement un message orientant vers le support humain ou la page de politique validée.
4. L'alias est réinitialisé vers la dernière génération d'index garantie saine. Les autres domaines de connaissances non impactés restent accessibles.
5. Le connecteur est restreint à la source canonique. La pipeline génère ensuite une nouvelle génération à partir du manifeste validé.
6. Cette génération n'est déployée en production qu'après la réussite des tests de réindexation et une validation fonctionnelle.

Cette séquence limite l'impact sans désactiver prématurément l'ensemble du chatbot. L'élément déterminant réside dans le lien entre les données d'origine et leurs dérivations : sans association directe entre document et chunks, il serait impossible d'identifier quels vecteurs supprimer.

Les tests de réindexation doivent prouver plus que la simple exécution réussie d'une pipeline

Un statut de tâche vert indique uniquement que le traitement technique s'est achevé. Il ne garantit pas que les anciens chunks ont disparu, ni que les sources correctes priment lors de requêtes réelles. Un ensemble de tests solide évalue par conséquent le contenu de l'index, le retrieval et le comportement des réponses.

1. Vérification du manifeste et de la suppression

Comparez la nouvelle génération avec le manifeste validé. Chaque version de document attendue doit être présente ; les ID de documents et de chunks bloqués ne doivent plus apparaître. L'usage de « tombstones » pour les contenus supprimés ou remplacés s'avère primordial. À défaut, un simple ajout de nouveaux embeddings laisse subsister d'anciens résultats empoisonnés dans l'index.

2. Tests de récupération avec sources attendues

Pour les questions critiques, se fier uniquement au texte de réponse attendu ne suffit pas. Définissez également les ID de sources autorisées et interdites, un nombre minimal de résultats et des conditions d'exclusion. Par exemple, le délai de retour doit impérativement provenir de la politique canonique ; le domaine miroir placé en quarantaine ne doit figurer ni dans les premiers résultats ni dans le contexte du modèle. Pour en savoir plus sur la structuration de ces jeux de validation, consultez l'article sur la qualité des réponses avec Golden Set et tests RAG.

3. Tests négatifs et de manipulation

Dans un environnement de test isolé, les équipes peuvent injecter une source de test clairement identifiée et non approuvée. La pipeline doit la maintenir en quarantaine ; la recherche dans un environnement similaire à la production ne doit pas la récupérer. En complément, les changements suspects de domaine, l'absence de propriétaire, les écarts de contenu majeurs et les incohérences de dates sont testés. Le rapport NIST AI 100-2 sur l'Adversarial Machine Learning classe l'empoisonnement comme une catégorie d'attaque dans sa taxonomie et souligne la nécessité d'évaluer méthodiquement les contre-mesures et leurs limites.

4. Comparaison avant et après basculement

Exécutez les mêmes requêtes sur la dernière version saine et sur la nouvelle génération. Comparez les sources obtenues, l'ordre de classement, les preuves de réponse, le taux d'absence de réponse (No-Answer-Rate) et l'évaluation fonctionnelle. Un déploiement progressif (Canary) restreint peut fournir des métriques de production complémentaires, à condition qu'aucun utilisateur n'accède à des sources non vérifiées. Le passage en production effectif n'intervient qu'une fois les seuils de sécurité et de qualité atteints.

Monitoring : détecter rapidement les anomalies

Ne limitez pas la surveillance aux seules évaluations de réponses. Des indicateurs pertinents incluent les domaines sources nouveaux ou rares, la proportion de sources non vérifiées dans le flux d'ingestion, les tailles de documents inhabituelles, les fortes divergences de texte ou de hash, un volume élevé de nouveaux chunks associés à un seul propriétaire, les variations parmi les sources principales du Golden Set et les réponses dépourvues de référence confirmée. Les métriques doivent pointer vers des ID de provenance plutôt que de stocker inutilement l'intégralité des requêtes utilisateurs.

L'actualité des données reste également un facteur clé. Une directive obsolète et remplacée depuis longtemps ne résulte pas d'un empoisonnement intentionnel, mais peut produire des effets similaires. L'article sur l' actualité des bases de connaissances et la QA de crawl complète les dispositifs de sécurité en abordant la fréquence, la responsabilisation et les circuits de suppression.

Check-list pour une ingestion RAG sécurisée

• Chaque source dispose-t-elle d'un ID stable, d'une origine canonique, d'un responsable identifié et d'une classe de confiance ?
• Le hash, la version du document, le parseur, le chunking et le modèle d'embedding sont-ils consignés conjointement ?
• Les sources nouvelles ou fortement modifiées restent-elles écartées de la recherche en production jusqu'à leur validation ?
• Les nouveaux domaines, l'absence de signature ou des modifications de contenu suspectes déclenchent-ils un passage en quarantaine ?
• Les index validés sont-ils publiés sous forme de générations versionnées avec un alias permettant un retour arrière ?
• La réindexation élimine-t-elle de manière vérifiable les chunks remplacés au lieu de simplement ajouter de nouvelles données ?
• Un Golden Set évalue-t-il à la fois les réponses fournies ainsi que les sources attendues et interdites ?
• Existe-t-il un mode dégradé sécurisé (fallback) pour les sujets dont les sources sont bloquées pendant un incident ?
• Les rôles d'ingestion, de validation fonctionnelle, de réponse aux incidents et de réédition sont-ils clairement dissociés ?
• Après chaque incident, documente-t-on le contrôle ayant fait défaut et le test de régression ajouté en conséquence ?

Conclusion

L'empoisonnement des données RAG ne peut se résoudre par une simple consigne au niveau du prompt. La protection repose sur une chaîne d'approvisionnement du savoir contrôlable : documenter l'origine, vérifier les modifications en quarantaine, versionner les index, supprimer de façon sûre les anciennes dérivations et tester le retrieval avec des sources attendues. Commencez par cibler les catégories de documents présentant le plus de risques et établissez un Golden Set restreint. Cette combinaison permet d'identifier clairement quelle source étaye une réponse – et d'assurer une procédure de rollback ciblée avant qu'un état de connaissances erroné ne devienne la norme.

Sources

• OWASP GenAI Security Project: LLM04:2025 Data and Model Poisoning
• NIST AI 600-1: Artificial Intelligence Risk Management Framework – Generative Artificial Intelligence Profile
• NIST AI 100-2: Adversarial Machine Learning – Taxonomy and Terminology of Attacks and Mitigations