L'empoisonnement des données : comment les attaques corrompent les modèles d'IA et comment s'en protéger à chaque étape

Les modèles d'IA modernes s'entraînent à partir d'énormes quantités de données externes, souvent non vérifiées. Cette dépendance constitue également leur point faible. Lorsque les données utilisées pour l'entraînement d'un modèle peuvent être manipulées, le processus d'entraînement lui-même devient une surface d'attaque, et le modèle peut être amené à commettre des erreurs difficiles à détecter et encore plus difficiles à corriger.

L'empoisonnement des données est une attaque visant l'intégrité de ce pipeline. En altérant les données à partir desquelles un modèle apprend, un attaquant peut discrètement en réduire la précision, y implanter des portes dérobées cachées ou biaiser son comportement afin d'obtenir un résultat souhaité. Cet article explique ce qu'est l'empoisonnement des données, comment ces attaques sont classées, à quelle étape du cycle de vie de l'IA l'empoisonnement intervient, pourquoi cette technique fonctionne, et comment se protéger à chaque étape grâce à des contrôles à plusieurs niveaux fondés sur une intégrité et une provenance vérifiables.

Qu'est-ce que l'empoisonnement des données ?

L'empoisonnement des données consiste à manipuler les données utilisées pour le pré-entraînement, le réglage fin ou l'encodage afin d'y introduire des vulnérabilités, des portes dérobées ou des biais qui compromettent la sécurité, les performances ou le comportement éthique d'un modèle. Selon le Top 10 de l’OWASP pour les applications LLM (LLM04:2025 Empoisonnement des données et des modèles), cette manipulation peut entraîner une dégradation des performances du modèle, la production de contenus biaisés ou toxiques, ainsi que l’exploitation des systèmes en aval qui s’appuient sur les résultats du modèle.

Cette attaque est qualifiée d’attaque d’intégrité, car la falsification des données d’apprentissage compromet directement la capacité du modèle à établir des prévisions précises. Le risque est maximal lorsque les modèles s’appuient sur des sources de données externes, susceptibles de contenir des informations non vérifiées ou délibérément malveillantes. En résumé, si l’on ne peut pas se fier aux données d’entrée, on ne peut pas se fier non plus aux résultats obtenus.

Empoisonnement des données vs empoisonnement des modèles

L'empoisonnement des données et l'empoisonnement des modèles sont deux concepts liés, mais qui ne sont pas identiques. L'empoisonnement des données vise les données utilisées pour entraîner, affiner ou intégrer un modèle. L'empoisonnement des modèles est une catégorie plus large qui englobe également la falsification de l'artefact du modèle lui-même.

Les modèles distribués via des référentiels partagés ou des plateformes d’ open-source s peuvent comporter des risques allant au-delà de la simple corruption des données. Un exemple courant est le « pickling » malveillant, qui consiste à intégrer un logiciel malveillant dans un fichier de modèle sérialisé afin que le code nuisible s’exécute dès le chargement du modèle. L’empoisonnement des données constitue donc l’une des voies menant à un modèle corrompu, et pour se prémunir contre ce problème dans son ensemble, il faut protéger à la fois les données et l’artefact.

	Corruption des données	Empoisonnement du modèle
Qu'est-ce qui a été altéré ?	Données de pré-entraînement, d'ajustement ou d'intégration	L'artefact du modèle distribué ; les poids et le fichier sérialisé qui les contient
À l'endroit où il pénètre	La chaîne de formation, en particulier les sources de données externes susceptibles de contenir des informations non vérifiées ou malveillantes	Répétitoires partagés ou plateformes d'open-source s hébergeant les modèles
Mécanisme	Fausser ce que le modèle apprend	Envoi d'un modèle corrompu, contenant un logiciel malveillant
Où les dégâts se produisent	Pendant la phase d'entraînement, il doit tenir jusqu'aux poids finaux pour être efficace	Au moment de l'acquisition ou du chargement, avant d'exécuter toute inférence
Propriété de sécurité non respectée	Intégrité : toute altération des données d'entraînement nuit à la capacité du modèle à établir des prévisions précises	Intégrité et exécution du code dans l'infrastructure de l'utilisateur
Résultat typique	Baisse des performances, contenu partial ou préjudiciable, exploitation en aval	Même résultat comportemental, avec en plus une atteinte à l'hôte
Conditions requises pour l'attaquant	Un certain contrôle sur une partie du corpus	Contrôle d'un compte d'édition ou du canal de distribution
Mesures d'atténuation primaires	Suivi de la provenance via une nomenclature, vérification des fournisseurs, gestion des versions des ensembles de données avec DVC	Vérification des vecteurs d'artefacts et formats de désérialisation sécurisés, ainsi qu'un environnement de type « sandbox » pour limiter l'exposition

Types d'attaques par empoisonnement : objectifs et capacités

Les attaques par empoisonnement peuvent être classées selon deux critères utiles : en fonction de l'objectif poursuivi par l'attaquant et en fonction du niveau d'accès dont il dispose.

En fonction de leur objectif, les attaques peuvent généralement être classées en trois catégories :

• Parti pris ou désinformation :fausser les résultats du modèle afin de diffuser des informations fausses ou biaisées.
• Porte dérobée ciblée :intégration d'un comportement caché qui ne s'active que dans des conditions spécifiques.
• Problèmes de disponibilité ou de baisse des performances :réduction de la précision et de la fiabilité globales du modèle.

En fonction de leurs capacités, les attaquants vont de ceux qui ne peuvent qu’influencer les données publiques susceptibles d’être intégrées par le modèle à ceux qui ont un accès direct au processus d’entraînement lui-même. L’empoisonnement des données en « split-view » (qui consiste à altérer des données préalablement sélectionnées, avant leur récupération) et l’empoisonnement par « frontrunning » exploitent la dynamique de collecte et d’entraînement des modèles à partir de données Web, tandis que les déclencheurs de porte dérobée peuvent créer un comportement de « agent dormant » : le modèle se comporte normalement jusqu’à ce qu’un déclencheur choisi le fasse basculer.

Une taxonomie faisant pleinement autorité concernant les objectifs et les capacités des attaquants est présentée dansles recommandations du NIST relatives à l'apprentissage automatique adversaire. Ce document classe l'empoisonnement en quatre catégories : l'empoisonnement par perte de disponibilité (dégradation aveugle), l'empoisonnement ciblé (quelques échantillons choisis), l'empoisonnement par porte dérobée (classification erronée conditionnée par un déclencheur) et l'empoisonnement de modèle (comme expliqué ci-dessus).

La carte du pipeline d'IA : où intervient l'empoisonnement ?

L'empoisonnement ne constitue pas un point de défaillance unique. Il peut se produire à plusieurs étapes du cycle de vie du modèle. Les équipes de sécurité peuvent utiliser la carte ci-dessous pour identifier leurs propres vulnérabilités.

• Pré-entraînement :les modèles s'entraînent à partir d'ensembles de données volumineux, généraux et souvent à l'échelle du Web. Le volume considérable de ces données rend difficile l'examen de chaque enregistrement, et les données non vérifiées augmentent le risque d'obtenir des résultats biaisés ou erronés.
• Ajustement :un modèle est adapté à une tâche spécifique à l'aide d'un ensemble de données plus restreint. Les pirates capables d'influencer cet ensemble de données peuvent orienter le comportement du modèle avec relativement peu d'efforts.
• Intégration :le texte est converti en vecteurs numériques, y compris les bases de données vectorielles utilisées pour la génération augmentée par la recherche (RAG). Dans ce contexte, un contenu « empoisonné » peut subtilement influencer ce que le modèle extrait et la manière dont il répond.
• Distribution des modèles :les modèles partagés via des référentiels et des plateformes d'open-source s peuvent contenir des logiciels malveillants intégrés, par exemple sous la forme d'un « pickling » malveillant qui s'exécute au chargement.
• Interaction avec l'utilisateur :lors d'une utilisation normale, les utilisateurs peuvent, à leur insu, introduire du contenu sensible, confidentiel ou malveillant, qui peut ensuite apparaître dans les résultats ultérieurs.

Des incidents réels illustrent à quel point ces points d’entrée sont variés. Des exemples tels que PoisonGPT ont montré comment un modèle altéré pouvait être dissimulé sur une plateforme publique de modèles afin de diffuser de fausses informations. Le chatbot Tay en est un autre exemple : il a été poussé à produire des réponses toxiques par le biais d’interactions manipulées. D’autres recherches sur l’empoisonnement des ensembles de données d’entraînement à l’échelle du Web ont démontré que même une infime fraction de données publiques corrompues peut influencer ce qu’apprennent les grands modèles.

Pourquoi l'empoisonnement des données fonctionne-t-il ?

L'empoisonnement est efficace pour des raisons structurelles plutôt qu'accidentelles.

• Tout d'abord, les modèles s'appuient sur des données externes qu'ils ne peuvent pas vérifier dans leur intégralité. À l'échelle du Web, il est impossible de collecter et de vérifier manuellement chaque source ; par conséquent, du contenu non vérifié se retrouve régulièrement dans le flux de traitement.
• Deuxièmement, l’empoisonnement est une attaque visant l’intégrité qui agit en silence. Plutôt que de provoquer une panne du système, il fausse les prédictions d’une manière qui peut passer pour une simple imperfection du modèle.
• Troisièmement, les portes dérobées peuvent rester latentes. Un modèle compromis peut se comporter normalement jusqu’à ce qu’un déclencheur spécifique modifie son comportement, le transformant ainsi en agent dormant. Comme ce comportement malveillant n’apparaît pas lors des tests habituels, les évaluations standard passent souvent complètement à côté.
• Quatrièmement, la plupart des pipelines ne disposent pas d'une traçabilité solide. Lorsque les systèmes ne disposent pas d'un système de traçabilité complet et cryptographiquement solide, il n'existe aucune piste d'audit fiable permettant de prouver l'origine des données ou d'un modèle, ni de déterminer s'ils ont été modifiés. Une altération qui ne laisse aucune trace vérifiable est une altération qui passe inaperçue.

Des mesures de protection à chaque étape du cycle de vie

Étant donné qu’une contamination peut survenir à n’importe quelle étape, la meilleure réponse consiste à mettre en place une défense en profondeur : des contrôles sont mis en place à chaque étape du cycle de vie afin qu’aucune faille isolée ne devienne un point de défaillance unique. Les stratégies de prévention et d’atténuation suivantes s’imposent de plus en plus comme une pratique courante pour renforcer la sécurité des modèles.

Origine et approvisionnement

Suivez la provenance et les transformations des données à l'aide d'outils tels qu'une « nomenclature » d'apprentissage automatique. Évaluez rigoureusement les fournisseurs de données et vérifiez la légitimité des données à chaque étape du développement du modèle. L'objectif est de toujours pouvoir déterminer d'où provient une donnée d'entraînement et si elle a été modifiée.

Traitement et validation des données

Filtrez et validez les données entrantes avant qu'elles n'atteignent le modèle. Mettez en place des contrôles au niveau de l'infrastructure qui limitent les sources auxquelles un modèle peut accéder, afin qu'il ne puisse pas ingérer de données dangereuses ou indésirables. Validez les résultats du modèle par rapport à des références fiables afin de détecter les premiers signes d'empoisonnement.

Pendant la formation

Lors du réglage fin, utilisez des ensembles de données triés sur le volet et adaptés à la tâche à accomplir, afin que le modèle apprenne à partir de données en adéquation avec son objectif. Mettez en place un contrôle de version des données (DVC) pour suivre les modifications apportées aux ensembles de données et détecter toute manipulation. Surveillez la perte d'entraînement et le comportement du modèle, en définissant des seuils permettant de signaler les résultats anormaux. Testez la robustesse à l'aide de campagnes de type « red team » et de techniques adversaires telles que l'apprentissage fédéré, afin de limiter l'impact des perturbations des données.

Après la formation

Validez et comparez les performances du modèle entraîné à celles de références fiables avant son déploiement. Analysez les artefacts du modèle distribués à la recherche de logiciels malveillants intégrés, par exemple des fichiers « pickle » non sécurisés. Mettez en place des contrôles de signature et d’intégrité pour les fichiers du modèle afin de pouvoir détecter toute altération survenue après l’entraînement.

Durée

Mettez en place un sandboxing rigoureux afin de limiter l'exposition du modèle à des données non vérifiées. Utilisez la détection d'anomalies pour filtrer les entrées adversaires. Stockez les informations fournies par les utilisateurs dans une base de données vectorielle afin de pouvoir les ajuster sans avoir à réentraîner l'ensemble du modèle. Lors de l'inférence, intégrez la génération augmentée par la recherche (RAG) et des techniques d'ancrage afin de réduire le risque d'hallucinations et de désinformation.

La couche d'intégrité et de provenance

La provenance et l'intégrité ne constituent pas simplement l'une des dix tactiques énumérées ci-dessus. Elles forment un pilier transversal de confiance qui confère de la crédibilité à tous les autres contrôles.

Le raisonnement est simple. Sans une traçabilité cryptographiquement solide, il n’existe aucun moyen fiable de prouver d’où provient un ensemble de données ou un artefact de modèle, ni de déterminer s’il a été altéré en cours de route. Il s’agit là d’un principe fondamental et non d’une simple option : l’analyse d’un contenu non signé ne permet de tirer que des conclusions concernant des données d’origine inconnue, tandis que l’analyse d’un contenu signé est fiable, car la paternité et l’intégrité sont déjà établies.

Dans la pratique, cette couche combine deux familles de contrôles. Les nomenclatures et le contrôle de version des données enregistrent ce qui a été intégré à un modèle et comment il a évolué. La signature cryptographique et la vérification d’intégrité associent ensuite ces enregistrements à une preuve qui ne peut être falsifiée en toute discrétion. Ensemble, elles permettent à une équipe de vérifier, et non pas simplement de supposer, que les données et les modèles de son pipeline sont bien ce qu’ils prétendent être. Cette base vérifiable constitue le pont naturel vers l’infrastructure d’identité, de signature et de certificats qui comble le fossé de la provenance.

Normes et gouvernance

Il existe plusieurs cadres permettant aux organisations de gérer les risques d'empoisonnement, et ceux-ci fonctionnent mieux lorsque la gouvernance est une priorité.

• Cadre de gestion des risques liés à l'IA du NIST :un cadre volontaire proposant des stratégies visant à garantir l'intégrité de l'IA et à identifier, mesurer et gérer les risques liés à l'IA tout au long de son cycle de vie.
• MITRE ATLAS :une base de connaissances regroupant des tactiques et techniques adversaires réelles en matière d'apprentissage automatique, telles que les données d'entraînement empoisonnées, les modèles d'apprentissage automatique comportant une porte dérobée, les ensembles de données empoisonnés publiés, etc.
• Recommandations de l'OWASP et normes relatives aux nomenclatures d'software : la normeOWASP LLM04:2025 définit le risque d'empoisonnement, tandis que les normes OWASP CycloneDX et ML-BOM fournissent des méthodes normalisées pour documenter la provenance tout au long de la chaîne d'approvisionnement de l'IA.
• Travaux en cours sur les nouvelles normes de l'IETF :les premiers projets de normes traitent de la manière dont les agents d'IA sont identifiés, authentifiés et autorisés, étendant ainsi les concepts de provenance et de confiance aux modes d'interaction des systèmes d'IA.

Le point central est la gouvernance. Les contrôles techniques ne fonctionnent que lorsqu’ils relèvent de la responsabilité de quelqu’un : une politique, une attribution claire des responsabilités et une obligation de rendre des comptes doivent précéder la mise en place des outils. Il convient notamment de noter que seules 50 % des organisations ont pleinement mis en œuvre une gouvernance pour leurs systèmes d’IA, ce qui laisse un écart important entre les contrôles existants et ceux qui sont réellement appliqués.

Comment Keyfactor vous aider

L'empoisonnement des données et des modèles est, par essence, un problème de confiance : il est impossible de vérifier l'origine ou l'intégrité des données et des modèles sur lesquels vous vous appuyez. C'est précisément cette lacune que l'identité d'Keyfactor, PKI, et ses fonctionnalités de signature ont pour but de combler.

Keyfactor fournit l'infrastructure cryptographique permettant d'établir une traçabilité vérifiable tout au long de la chaîne d'approvisionnement de l'IA et de l'apprentissage automatique. EJBCA fournit une infrastructure d’autorité de certification d’entreprise pour l’émission et la gestion des certificats numériques qui associent l’identité aux ensembles de données, aux artefacts de modèles et aux systèmes qui les produisent. Keyfactor SignServer permet la signature de code et d’artefacts via des API, de sorte que les fichiers de modèles et les résultats des pipelines puissent être signés de manière centralisée sans distribution de clés privées, et que toute altération ultérieure soit détectée grâce à la vérification d’intégrité. Keyfactor Command automatise la gestion du cycle de vie des certificats, en prenant en charge leur émission, leur renouvellement et leur révocation, afin que les relations de confiance restent à jour à mesure que les pipelines évoluent.

Les mêmes principes d’ PKI s et de signature de code qui protègent les chaînes d’approvisionnement d’ software s, les identités des appareils et l’authentification des charges de travail s’appliquent directement à la protection de l’IA. La protection des clés assurée par un HSM conserve les clés de signature dans des « hardware s inviolables » afin de répondre aux exigences des secteurs réglementés. Il en résulte un passage de la détection heuristique à l’assurance cryptographique : au lieu d’espérer qu’un ensemble de données ou un modèle corrompu soit détecté, les équipes peuvent prouver ce qui est fiable et rejeter ce qui ne l’est pas. Il s’agit là de l’expression concrète de la couche d’intégrité et de provenance décrite ci-dessus, étendue à l’ensemble de la chaîne d’approvisionnement de l’IA et de l’apprentissage automatique.