L'essentiel en bref
- Le data poisoning (empoisonnement des données) figure sous la référence LLM04 (« Data and Model Poisoning ») dans le Top 10 OWASP pour les applications LLM 2025 et fait partie des neuf menaces que l'ISO/IEC 27090:2026 décrit dans son chapitre 6. La norme traite l'empoisonnement direct du modèle comme une menace distincte.
- Les entreprises qui n'entraînent aucun modèle sont concernées elles aussi : un chatbot à génération augmentée par récupération (RAG) qui répond à partir d'un wiki, de lecteurs partagés ou de tickets prend chaque page manipulée pour une connaissance. Dans les expériences PoisonedRAG (USENIX Security 2025), cinq textes fabriqués par question ciblée, dans une base de plusieurs millions de textes, ont suffi pour un taux de réussite de 90 %.
- Un grand volume de données ne dilue pas le poison. Dans une étude d'Anthropic, de l'UK AI Security Institute et de l'Alan Turing Institute publiée en octobre 2025, 250 documents fabriqués ont suffi pour implanter une porte dérobée simple dans des modèles de 600 millions à 13 milliards de paramètres.
- Dans le processus de gestion des risques ISO 27001, le data poisoning relève de l'appréciation des risques selon le chapitre 6.1.2. Il se traite surtout avec les mesures A.5.9 (inventaire), A.5.19 à A.5.21 (fournisseurs et chaîne d'approvisionnement TIC), A.8.25 (développement sécurisé) et A.8.16 (surveillance).
- Selon l'article 15, paragraphe 5, de l'AI Act, les fournisseurs de systèmes d'IA à haut risque doivent prévoir, le cas échéant, des mesures contre l'empoisonnement des données et l'empoisonnement de modèles. Ces obligations s'appliquent à partir du 2 décembre 2027 pour les systèmes de l'annexe III et du 2 août 2028 pour ceux de l'annexe I.
Le data poisoning ressemble à un problème réservé aux entreprises qui entraînent leurs propres modèles d'IA. La plupart des entreprises dotées d'un SMSI ISO 27001 ne le font pas : elles appellent un modèle de langage via une API, le connectent à leur wiki et le laissent répondre aux questions des clients ou des collaborateurs. C'est précisément là que naît le risque. Qui peut modifier les données dont un système d'IA apprend ou qu'il lit peut modifier ses réponses.
Cet article s'adresse à la personne responsable du SMSI, qui doit désormais déterminer où le data poisoning atteint sa propre entreprise, comment le risque entre dans le registre des risques et quelles mesures tiennent réellement.
Qu'est-ce que le data poisoning ?
Le data poisoning est une attaque dans laquelle quelqu'un manipule les données servant à entraîner, à affiner ou à alimenter un modèle d'IA, afin d'en modifier le comportement. Le modèle apprend ou lit alors quelque chose de faux et le restitue avec la même assurance que tout le reste. La liste OWASP y inclut expressément les données de pré-entraînement, celles du fine-tuning et les embeddings sur lesquels repose un système RAG.
Dans notre présentation de la norme de sécurité de l'IA ISO 27090, le data poisoning est l'une des neuf menaces. Cet article se concentre sur celle-ci, du point de vue d'une entreprise qui s'appuie sur des modèles de tiers.
Data poisoning, empoisonnement de modèle et porte dérobée
Les trois notions sont souvent confondues, mais elles désignent des choses différentes. Dans le data poisoning, l'attaquant s'en prend aux données. Dans l'empoisonnement de modèle, que l'ISO 27090 appelle empoisonnement direct du modèle, il manipule le modèle lui-même : ses paramètres ou un composant pré-entraîné que vous réutilisez. Une porte dérobée (backdoor) n'est pas une troisième voie, mais un résultat possible des deux attaques. Le modèle se comporte normalement jusqu'à ce qu'un déclencheur précis apparaisse dans le texte.
Trois exemples montrent l'étendue du sujet :
- Données d'entraînement faussées : un filtre pour les messages entrants est régulièrement réentraîné à partir des retours des utilisateurs qui marquent un message comme « pas un spam ». Pendant plusieurs semaines, un attaquant marque ses propres e-mails d'hameçonnage comme légitimes depuis plusieurs comptes. Le modèle apprend à laisser passer exactement ce type de message.
- Porte dérobée dans un modèle public : une équipe télécharge un modèle librement disponible depuis un dépôt public et l'affine. Le modèle contient une porte dérobée qui contourne les contrôles de sécurité lorsqu'il rencontre une suite de caractères rare. Aucun test standard ne la détecte, car aucun cas de test ne contient cette suite.
- Base de connaissances empoisonnée : quelqu'un modifie, dans un wiki interne, la page qui indique les coordonnées bancaires pour les remboursements. Dès l'indexation suivante, le chatbot client qui répond à partir de ce wiki communique un IBAN erroné.
Une idée reçue : le data poisoning supposerait un accès à l'infrastructure. Dans les deux premiers exemples, l'attaquant n'a besoin d'aucun accès à vos systèmes ; il marque des messages depuis un compte utilisateur ordinaire ou publie un modèle que votre équipe télécharge. Selon l'étude d'Anthropic, de l'UK AISI et de l'Alan Turing Institute, la quantité de poison nécessaire ne dépend pas de la taille du modèle : un petit nombre fixe de documents a suffi. L'étude n'a toutefois testé qu'une porte dérobée inoffensive qui produit du charabia, et les auteurs laissent ouverte la question de savoir si le résultat vaut pour des modèles plus grands et des objectifs plus nuisibles.
Où le data poisoning touche les entreprises qui utilisent seulement l'IA
Les entreprises qui n'entraînent aucun modèle rencontrent des données empoisonnées à trois endroits : dans la base de connaissances d'un système RAG, dans leurs propres données de fine-tuning et dans les modèles ou jeux de données de leurs fournisseurs. Dans les trois cas, le traitement du risque relève de votre SMSI, et non du fournisseur du modèle de fondation.
L'erreur que commettent beaucoup d'équipes : « Nous n'entraînons pas de modèles, donc l'empoisonnement ne nous concerne pas. » Le fournisseur du modèle de base s'occupe de ses propres données d'entraînement. Il ne connaît ni votre Confluence, ni votre historique de tickets, ni les jeux de données que votre équipe télécharge sur Internet.
Une base de connaissances RAG alimentée par wikis, lecteurs et tickets
Pour chaque question, un système RAG recherche les passages pertinents dans une base de connaissances et les transmet au modèle de langage comme base de sa réponse. Cette base est généralement alimentée automatiquement : à partir d'un espace Confluence, d'un site SharePoint, d'un lecteur partagé ou de l'historique des tickets. Toute personne qui peut y écrire écrit donc aussi dans les connaissances du chatbot. Dans beaucoup d'entreprises, cela inclut tous les collaborateurs, des comptes invités externes et, pour les tickets, les clients eux-mêmes.
Pour les entreprises qui se contentent d'utiliser l'IA, le RAG poisoning est généralement le point d'entrée le plus évident. Les chercheurs à l'origine de PoisonedRAG ont atteint un taux de réussite de 90 % avec cinq textes fabriqués par question ciblée, alors que la base contenait des millions de textes. La raison : un texte taillé pour une question est récupéré en priorité pour cette question.
Le fine-tuning sur vos propres données
Si vous adaptez un modèle à vos propres exemples, comme des cas de support résolus ou d'anciennes offres, ces exemples deviennent des données d'entraînement. S'ils proviennent en tout ou partie de l'extérieur, un attaquant peut les façonner. Contrairement au RAG, le dommage est alors stocké dans le modèle lui-même. Corriger la source ne répare pas le modèle ; il faut le réentraîner sur des données nettoyées.
Modèles et jeux de données des fournisseurs
Le troisième endroit est la chaîne d'approvisionnement. Vous utilisez un modèle de fondation via une API, un modèle d'embedding pour la recherche, un modèle librement disponible ou un jeu de données issu d'un dépôt public. Vous ne pouvez pas examiner les données d'entraînement de ces composants. Si l'un d'eux a été empoisonné, vous héritez du problème avec le téléchargement. Pour votre SMSI, c'est un risque fournisseur comme un autre, qui relève de l'évaluation selon les mesures A.5.19 à A.5.21.
Le data poisoning dans le processus de gestion des risques ISO 27001
Le data poisoning relève de l'appréciation des risques selon le chapitre 6.1.2 de l'ISO 27001 comme toute autre menace : avec l'actif concerné, la vraisemblance, l'impact et le propriétaire du risque. Trois questions déterminent l'évaluation. Qui peut modifier les données dont le système apprend ou qu'il lit ? Pouvez-vous prouver d'où viennent le modèle et les données ? Et comment remarqueriez-vous que son comportement a changé ?
On en tire une règle simple. Un système qui répond à partir d'un espace tenu par cinq rédacteurs nommés, et dont une personne relit les réponses, présente un risque faible. Un système qui puise dans des sources modifiables par tous, s'adresse directement aux clients et repose sur des modèles d'origine inconnue présente un risque élevé.
Les deux évaluations supposent un inventaire complet selon la mesure A.5.9. Il couvre non seulement les systèmes d'IA eux-mêmes, mais aussi les sources de données qui les alimentent et les modèles sur lesquels ils reposent, chacun avec son origine et son responsable. Un jeu de données qui n'est pas inventorié comme actif n'a pas de propriétaire pour décider qui peut y écrire. La place de cet inventaire dans le processus de certification est décrite dans notre guide de la certification ISO 27001.
Quelles mesures de l'annexe A s'appliquent
L'annexe A de l'ISO 27001:2022 ne nomme pas cette attaque. Des mesures existantes couvrent toutefois les points décisifs, à condition d'étendre leur périmètre aux systèmes d'IA et à leurs données. Le tableau suivant rattache des scénarios types ; il s'agit d'une interprétation de travail, qui ne fait pas partie de la norme.
| Scénario | Risque | Mesure (ISO 27001:2022, annexe A) | Action |
|---|---|---|---|
| Un chatbot RAG répond à partir du wiki de l'entreprise | Une page manipulée fournit aux clients des informations fausses, par exemple de mauvaises coordonnées bancaires | A.5.9 Inventaire des informations et autres actifs associés ; A.5.15 Contrôle d'accès | Définir les sources indexées ; limiter les droits d'écriture à ces espaces ; vérifier les modifications avant chaque indexation |
| L'historique des tickets alimente la base de connaissances ou le fine-tuning | Des personnes externes façonnent les données dont le système apprend ou qu'il lit | A.8.25 Cycle de vie de développement sécurisé ; A.8.29 Tests de sécurité dans le développement et l'acceptation | Ne pas intégrer de contenus externes sans contrôle ; valider le jeu de données avant chaque entraînement |
| Fine-tuning d'un modèle sur vos propres données | Porte dérobée ou biais systématique dans le modèle adapté | Chapitre 6.1.2 Appréciation des risques ; A.8.25 Cycle de vie de développement sécurisé | Versionner le jeu de données ; contrôler des échantillons ; évaluer le modèle sur un jeu de test fixe avant sa mise en service |
| Modèle de fondation via l'API d'un tiers | Origine inconnue des données d'entraînement ; changements de modèle sans préavis | A.5.19 à A.5.21 Relations avec les fournisseurs et chaîne d'approvisionnement TIC ; A.5.23 Services en nuage | Interroger le fournisseur sur l'origine des données et la protection contre l'empoisonnement ; exiger contractuellement l'annonce des changements de modèle |
| Modèle ou jeu de données librement disponible dans un dépôt public | Poids ou données manipulés (empoisonnement direct du modèle) | A.5.21 Chaîne d'approvisionnement TIC ; A.8.25 Cycle de vie de développement sécurisé | Se fournir uniquement auprès de sources approuvées ; vérifier les sommes de contrôle ; documenter l'origine dans une nomenclature ML (ML-BOM) |
| Tout système d'IA en production | L'empoisonnement passe inaperçu | A.8.15 Journalisation ; A.8.16 Activités de surveillance | Comparer régulièrement les réponses à des questions de référence fixes ; signaler les écarts à la gestion des incidents |
Notre présentation de l'ISO 27090 rattache les deux formes d'empoisonnement au chapitre 6.1.2 et aux mesures A.5.21 et A.8.25 ; le tableau y ajoute l'inventaire, le contrôle d'accès et la surveillance. Comme le chapitre 6.1.3 précise que l'annexe A n'est pas exhaustive, vous pouvez citer l'ISO 27090 dans votre déclaration d'applicabilité comme source de mesures supplémentaires propres à l'IA. La structure des 93 mesures et les preuves qu'un auditeur attend pour chacune sont détaillées dans notre présentation des mesures de l'annexe A de l'ISO 27001.
Les protections contre le data poisoning qui fonctionnent vraiment
Les protections les plus efficaces contre le data poisoning agissent à la source des données, pas au niveau du modèle. Détecter un empoisonnement après coup est difficile : un modèle doté d'une porte dérobée répond correctement à toutes les questions de test normales, et une page de wiki manipulée ressemble à n'importe quelle autre. Qui ne commence à chercher qu'au niveau des réponses cherche un déclencheur qu'il ne connaît pas.
Cinq mesures ont fait leurs preuves :
- Origine des données et droits d'écriture : définissez les sources qu'un système d'IA peut lire et limitez les droits d'écriture à ces seuls espaces. Chaque modification est journalisée, pour savoir en cas d'incident quelle version a été indexée et quand.
- Évaluation des fournisseurs et des modèles : demandez aux fournisseurs de modèles d'où viennent leurs données d'entraînement, comment ils les protègent contre la manipulation et comment ils annoncent les changements de modèle. Ne récupérez les modèles librement disponibles qu'auprès de dépôts approuvés et vérifiez leurs sommes de contrôle.
- Validation avant le fine-tuning : versionnez chaque jeu de données d'entraînement, contrôlez des échantillons et les valeurs aberrantes, puis comparez le nouveau modèle à l'ancien sur un jeu de test fixe avant sa mise en service.
- Surveillance des réponses : posez régulièrement au système les mêmes questions de référence et comparez les réponses. Si une réponse change sans raison connue, traitez-la comme un incident, pas comme du bruit.
- Red teaming : testez le système de manière ciblée en injectant des documents fabriqués dans la base de connaissances d'un environnement de test. L'ISO 27090 recommande le red teaming dans son chapitre 5.7 ; un test d'intrusion classique ne vérifie que l'infrastructure.
Le projet OWASP tient à jour un recueil de schémas d'attaque et de contre-mesures dans sa description de LLM04. Il y recommande aussi de tracer l'origine et les transformations des données, par exemple avec une nomenclature ML (ML-BOM).
Exemple : un chatbot de support qui répond à partir de Confluence
Une entreprise SaaS fictive de 120 personnes, certifiée ISO 27001, exploite un chatbot de support reposant sur un modèle de langage hébergé. Le chatbot répond à partir du wiki Confluence, entièrement réindexé chaque nuit. Les chiffres de cet exemple sont donnés à titre d'illustration : le wiki compte environ 2 400 pages, 85 collaborateurs disposent de droits de modification et 12 freelances externes ont des comptes invités.
Lors de l'appréciation des risques, l'équipe SMSI évalue la vraisemblance comme moyenne, car un seul compte compromis sur 97 suffit. L'impact est élevé : si le chatbot communique de mauvaises coordonnées bancaires à un client, il en résulte un préjudice financier direct, et un problème de protection des données suit rapidement.
Le traitement modifie des mesures existantes au lieu d'en inventer de nouvelles. Le chatbot ne lit plus que l'espace « Centre d'aide », tenu par six rédacteurs nommés (A.5.9, A.5.15). Une deuxième personne valide les modifications dans cet espace avant leur indexation (A.8.25). Après chaque indexation, le chatbot répond à 40 questions de référence, dont les réponses sont comparées automatiquement à celles de la semaine précédente (A.8.16). Le contrat avec le fournisseur du modèle prévoit l'annonce préalable des changements de modèle (A.5.20). Le risque résiduel passe d'élevé à moyen et la direction l'accepte en l'état. Il n'atteint pas zéro, car l'un des six rédacteurs peut lui aussi être compromis.
Ce que disent les réglementations et les normes sur le data poisoning
Trois référentiels traitent explicitement du data poisoning, avec une force contraignante différente : l'ISO 27090 comme lignes directrices, l'AI Act comme loi pour l'IA à haut risque et le projet SOC 2 de 2027 comme futur référentiel d'audit.
ISO/IEC 27090. Publiée le 14 octobre 2026, la norme cite le data poisoning et l'empoisonnement direct du modèle comme des menaces distinctes dans son chapitre 6. Le chapitre 5.5 traite de la gestion de la chaîne d'approvisionnement, le chapitre 7 des contre-mesures. L'ISO 27090 est un guide ; il n'existe pas de certification selon cette norme. Ses recommandations entrent dans un SMSI ISO 27001 ou dans un système de management de l'IA selon l'ISO 42001 par le biais de votre traitement des risques.
AI Act. L'article 15, paragraphe 5, exige que les systèmes d'IA à haut risque résistent aux tentatives de tiers non autorisés visant à modifier leur utilisation, leurs sorties ou leurs performances. Les solutions techniques comprennent, le cas échéant, des mesures contre les attaques visant le jeu de données d'entraînement (empoisonnement des données) et les composants pré-entraînés (empoisonnement de modèles). L'obligation incombe au fournisseur ; si vous ne faites que déployer un tel système, vous la vérifiez dans le cadre de l'évaluation de vos fournisseurs. Les systèmes considérés comme à haut risque sont présentés dans notre article sur les systèmes d'IA à haut risque selon l'AI Act.
SOC 2. Le projet de l'AICPA pour les Trust Services Criteria 2027 cite le data poisoning parmi ses nouveaux points of focus consacrés à l'IA. Les commentaires sont possibles jusqu'au 15 janvier 2027 ; si le projet est adopté, il s'applique aux missions qui commencent le 31 décembre 2027 ou après. Le résultat reste un rapport SOC 2. Les autres changements du projet sont décrits dans notre article sur les critères SOC 2 de 2027.
Comme référence technique pour les cas de test, la taxonomie NIST AI 100-2 E2025 de mars 2025 est également utile ; elle décrit les attaques par empoisonnement comme une classe d'attaques à part entière.
Comment Kertos intègre les risques liés à l'IA dans votre SMSI
Avec Kertos, le data poisoning figure dans le même registre des risques que vos autres risques de sécurité de l'information, et non dans un tableau séparé pour l'IA. Vous inventoriez vos systèmes d'IA une seule fois, évaluez les risques associés et reliez leur traitement aux mesures de l'annexe A, aux politiques et aux preuves. La déclaration d'applicabilité montre ensuite quelles mesures s'appliquent à quel risque lié à l'IA.
Kertos réunit l'ISO 27001 et l'ISO 42001 sur une seule plateforme. Pour le système de management de l'IA, vous disposez de mesures ISO 42001 pré-mappées et d'une bibliothèque de risques IA alignée sur l'AI Act et sur l'ISO/IEC 23894. Les experts certifiés de Kertos vous aident à déterminer lesquels de vos systèmes d'IA présentent un risque d'empoisonnement pertinent et à documenter le traitement de manière à ce qu'il tienne lors de l'audit.
Vous souhaitez voir à quoi ressemble votre propre chatbot RAG ou votre pipeline de fine-tuning dans le SMSI ? Réservez une démo et apportez votre exemple.
Questions fréquentes
Qu'est-ce que le data poisoning ?
Le data poisoning (empoisonnement des données) est une attaque dans laquelle quelqu'un manipule les données servant à entraîner, à affiner ou à alimenter un modèle d'IA via une base de connaissances, afin d'en modifier le comportement. Le Top 10 OWASP pour les applications LLM 2025 classe ce risque sous la référence LLM04 « Data and Model Poisoning ». L'ISO/IEC 27090:2026 décrit le data poisoning dans son chapitre 6 comme l'une des neuf menaces pesant sur les systèmes d'IA.
Quelle est la différence entre data poisoning et injection de prompt ?
Le data poisoning manipule les données dont un modèle apprend ou tire ses connaissances, et agit donc sur toutes les réponses ultérieures. L'injection de prompt glisse des instructions dans une entrée isolée ou dans un document que le modèle est en train de traiter, et détourne ainsi cette seule tâche. Dans une base de connaissances RAG, les deux se recoupent : une page fabriquée contenant de faux faits relève du data poisoning, une page contenant des instructions cachées relève de l'injection de prompt indirecte.
Comment détecter le data poisoning ?
Après coup, difficilement, car un modèle empoisonné répond correctement aux questions de test normales jusqu'à l'apparition d'un déclencheur inconnu. Des réponses à des questions de référence fixes qui changent sans raison, des modifications inhabituelles dans les sources indexées et des valeurs aberrantes dans les jeux d'entraînement sont des signaux d'alerte. Contrôler l'origine des données et les droits d'écriture, et journaliser chaque version, est plus efficace que de chercher le poison.
Le data poisoning concerne-t-il aussi les entreprises qui utilisent seulement l'IA ?
Oui. Toute entreprise qui connecte un modèle de langage à une base de connaissances issue d'un wiki, de lecteurs ou de tickets, qui affine un modèle sur ses propres données ou qui utilise des modèles et des jeux de données de tiers peut reprendre des données empoisonnées. Le fournisseur du modèle de fondation ne protège que ses propres données d'entraînement. Pour toutes les autres sources de données, le traitement du risque relève de votre propre SMSI.
Quelles mesures ISO 27001 aident contre le data poisoning ?
L'annexe A de l'ISO 27001:2022 ne nomme pas le data poisoning, mais plusieurs mesures existantes s'appliquent. Les plus importantes sont A.5.9 pour l'inventaire des sources de données et des modèles, A.5.15 pour les droits d'écriture, A.5.19 à A.5.21 pour les fournisseurs et la chaîne d'approvisionnement TIC, A.8.25 pour le cycle de vie de développement sécurisé et A.8.16 pour la surveillance. Le risque lui-même est évalué dans l'appréciation des risques selon le chapitre 6.1.2.
