L'empoisonnement des données : comment les pirates corrompent les données d'entraînement et de recherche de l'IA

L'empoisonnement des données consiste à corrompre délibérément les données à partir desquelles un modèle d'IA ou d'apprentissage automatique s'entraîne ou qu'il récupère, afin que le modèle se comporte comme le souhaite un attaquant. Cette technique cible les corpus de pré-entraînement, les données de réglage fin et de préférences, les index de recherche ainsi que le contexte des outils des agents ; il s'agit d'une attaque visant l'intégrité des données plutôt que d'un vol de données.

La menace n’est plus seulement théorique. En mai 2026, des chercheurs ont découvert des « malware » dans un référentiel de modèles Hugging Face classé numéro un des tendances, et une étude publiée en 2025 dans *Nature Medicine* a montré que le fait de remplacer 0,001 % des tokens d’entraînement par des fausses informations médicales produisait des modèles plus susceptibles de propager des erreurs médicales. Cette page définit l'attaque, distingue ses quatre étapes du cycle de vie, établit une correspondance entre chaque technique MITRE ATLAS portant un nom évocateur et ses mesures d'atténuation, et indique clairement quelle moitié du problème une équipe de sécurité est en mesure de détecter.

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

Deux exemples récents en illustrent les limites. En mai 2026, des chercheurs de HiddenLayer ont mis en évidence un dépôt Hugging Face qui s’était hissé en tête des tendances tout en diffusant un chargeur exécutant un programme de vol d’informations. Il s’agit là d’un « empoisonnement d’artefact » : l’objet empoisonné est un paquet de modèle publié plutôt qu’un ensemble de données d’entraînement. Du côté des données d’entraînement, une étude de *Nature Medicine* datant de 2025, dont les expériences ont été menées en 2024, a simulé une attaque contre *The Pile*, un corpus ouvert de pré-entraînement, et a rapporté que « le remplacement de seulement 0,001 % des tokens d’entraînement par de fausses informations médicales entraîne la création de modèles nuisibles, plus susceptibles de propager des erreurs médicales ».

L'empoisonnement des données est-il une attaque adversaire ? Oui. Le document NIST AI 100-2e2025, rapport de l'agence sur l'apprentissage automatique adversaire, classe l'empoisonnement dans une catégorie d'attaques distincte, aux côtés des attaques par contournement au moment de l'inférence et des attaques contre la vie privée. L'empoisonnement est le maillon « intégrité » de cette famille : il modifie ce qu'un modèle apprend ou récupère plutôt que de voler ce qu'il sait. L’inversion de modèle, parfois classée à tort parmi les types d’empoisonnement, est une attaque contre la confidentialité. L’entrée actuelle LLM05:2026 de l’OWASP définit cette même catégorie de manière générale : « L’empoisonnement des données et des modèles décrit une classe d’attaques et de défaillances dans lesquelles un adversaire (ou un processus non sécurisé) manipule des données ou des artefacts de modèle. »

Falsification des données contre utilisation abusive des données

L'utilisation abusive des données désigne l'utilisation non autorisée de données déjà détenues par une organisation : un employé consultant les dossiers clients à des fins personnelles commet ainsi un abus. L'empoisonnement des données désigne la corruption délibérée des données à partir desquelles un modèle apprend ou qu'il récupère : un pirate insérant des échantillons mal étiquetés dans un ensemble d'apprentissage commet ainsi un empoisonnement. Le véritable point commun réside dans la condition préalable, car ces deux phénomènes commencent généralement par le fait qu'une personne dispose d'un accès en lecture ou en écriture qu'elle ne devrait pas avoir.

L'empoisonnement des données par rapport à prompt injection

Prompt injection modifie les données d'entrée d'un modèle lors de son exécution, en ciblant un modèle déjà entraîné, et son effet prend généralement fin à la fin de la session. L'empoisonnement des données modifie ce que le modèle a appris ou ce qu'il renvoie ; la corruption persiste donc pour tous les utilisateurs et toutes les sessions jusqu'à ce que les données soient nettoyées ou que le modèle soit réentraîné.

Empoisonnement des données contre empoisonnement des modèles

Dans le cadre de l'apprentissage fédéré, l'« empoisonnement de modèle » désigne le fait qu'un attaquant soumette des mises à jour malveillantes du modèle, et non des données malveillantes ; confondre ces deux notions constitue une erreur factuelle plutôt qu'une simple préférence terminologique. L'OWASP Machine Learning Les 10 principales mesures de sécurité (version préliminaire v0.3, édition 2023) les distingue précisément pour cette raison, en énumérant ML02:2023 Attaque par empoisonnement des données et ML10:2023 – Empoisonnement de modèle comme des risques distincts.

« Data poisoning » contre « SEO poisoning »

Le « SEO poisoning » consiste à manipuler les classements des moteurs de recherche afin de rediriger vers malware, tandis que le « data poisoning » consiste à corrompre les données d'entraînement ou d'ancrage de l'IA : un terme commun, mais une attaque différente, une surface d'attaque différente et une défense différente.

Quand l'empoisonnement est un moyen de défense

Ce même mécanisme fonctionne à l’inverse à des fins de protection. Nightshade, développé à partir de données de 2023, a montré que moins de 100 échantillons empoisonnés suffisaient à contrôler une instruction SDXL de Stable Diffusion ; les artistes peuvent ainsi perturber leurs propres œuvres pour les protéger contre le scraping (arXiv:2310.13828). Un pré-publication de 2024, mise à jour en 2025, a révélé que les outils de perturbation protectrice les plus courants « ne procurent qu’un faux sentiment de sécurité » et que l’upscaling d’images disponible dans le commerce les dégrade (arXiv:2406.12027). Ce résultat porte sur la perturbation protectrice contre l’imitation de style, un mécanisme différent de l’empoisonnement offensif de Nightshade, et ne réfute pas les conclusions de Nightshade.

Types d'attaques par empoisonnement des données

Les types d'empoisonnement se distinguent par ce que l'attaquant modifie, étiquette, échantillonne ou déclenche, ainsi que par le fait que l'objectif soit une dégradation générale ou un comportement caché.

• Inversion des étiquettes. L'attaquant modifie les étiquettes d'échantillons par ailleurs légitimes, afin d'amener le modèle à considérer qu'un élément malveillant est inoffensif, ou inversement.
• Injection de données. L'attaquant insère de nouveaux échantillons qu'il a lui-même créés dans un corpus à partir duquel le modèle va s'entraîner.
• Empoisonnement « clean-label ». Altère les échantillons sans modifier leur étiquetage, ce qui permet de contourner les contrôles de cohérence des étiquettes. Il s'agit d'une sous-catégorie distincte définie dans la norme NIST AI 100-2e2025.
• Attaques de type « backdoor » ou « trigger ». Installation d’un comportement caché qui ne s’active qu’en présence d’un modèle d’entrée spécifique, le modèle se comportant normalement dans le reste des cas.
• Attaques visant à compromettre la disponibilité ou à dégrader les performances. L'objectif est de détériorer le modèle de manière générale plutôt que de le faire se tromper de manière sélective.
• Empoisonnement ciblé ou non ciblé. Une distinction transversale : les attaques ciblées modifient des résultats spécifiques, tandis que les attaques non ciblées nuisent aux performances globales.
• « Split-view poisoning » : achat d’un domaine expiré auquel un index de données fait toujours référence, de sorte qu’une exploration ultérieure récupère le contenu de l’attaquant. Ce phénomène est mentionné dans les recommandations conjointes des agences alliées sur la sécurité des données d’IA, datées du 22 mai 2025.
• « Frontrunning poisoning ». L'injection de contenu malveillant juste avant la capture d'un instantané des sources issues du crowdsourcing en vue de leur collecte, également mentionnée dans ces recommandations de 2025.
• Attaques ciblant une sous-population. Elles détériorent les performances pour une partie de la distribution des données, tandis que les indicateurs globaux restent inchangés.
• Intoxication par « goutte à goutte » ou « grenouille bouillante ». De petites dérives s'installent progressivement, de sorte qu'aucun changement isolé ne déclenche de contrôle.
• Intoxication par un artefact. La publication de jeux de données, de modèles ou d'outils d'agents « empoisonnés » dans des référentiels publics, répertoriés dans MITRE ATLAS sous le nom de AML.0115 et analysées par le Cloud Alliance pour la sécurité en tant que surface d'attaque du référentiel. Cette variante recoupe attaques visant la chaîne d'approvisionnement logicielle, et au-delà du cas spécifique à l'IA, il fait partie de cette page.

Où se produit la « contamination » : le cycle de vie des données d'IA en quatre étapes

L'empoisonnement est généralement présenté comme un problème lié à la phase d'entraînement, mais cette approche ne tient pas compte de deux étapes supplémentaires. Les données sur lesquelles repose un système d’IA passent par quatre étapes distinctes, et chacune d’entre elles peut être corrompue : le corpus de pré-entraînement, les données de réglage fin et de préférences, l’index de recherche qu’un système déployé consulte au moment de la requête, ainsi que les définitions, les sorties et la mémoire de l’outil qui alimentent les agents d’IA. Les deux premières constituent des surfaces de phase de construction. Les deux dernières sont des surfaces de phase d’exécution, et ce sont celles que l’équipe de sécurité peut réellement surveiller.

ÉtapeCe que l'attaquant modifieQui détient le contrôleType de contrôlePré-entraînementLe corpus de baseIngénierie des données et fournisseur de modèlesPhase de construction : provenance, assainissement, signature des ensembles de donnéesRéglage fin et données de préférencesCorpus de tâches et paires de préférencesIngénierie ML et MLOpsPhase de construction : lignée des ensembles de données, révision, contrôle d’accès RAG et recherche L’index de recherche en temps réel ou le magasin de documents Équipes applicatives et de plateforme, avec la sécurité Exécution : surveillance des accès en écriture, détection des modifications du corpus, garde-fous Outils d’agent et contexte Définitions d’outils, sortie des outils, mémoire de l’agent Plateforme et sécurité Exécution : renforcement de la mémoire, liste blanche des outils, garde-fous

Tableau : Les quatre étapes du cycle de vie des données d'IA, ce qu'un pirate modifie à chaque étape et qui en détient le contrôle.

‍

La génération augmentée par la recherche (RAG) fonde les réponses d'un modèle sur un ensemble de documents qui évolue quotidiennement, ce qui transforme l'empoisonnement en une attaque à l'exécution dotée de sa propre technique MITRE ATLAS, AML.0070 Intoxication RAG. Le résultat de référence est « PoisonedRAG », publié lors de la conférence USENIX Security 2025 à l’issue d’expériences menées entre 2024 et 2025, qui a fait état d’« un taux de réussite des attaques de 90 % lors de l’injection de cinq textes malveillants pour chaque question cible » dans une base de connaissances contenant des millions de textes, et a conclu que les défenses évaluées étaient insuffisantes (arXiv:2402.07867).

Le fin-tuning présente une nouvelle complexité : les données de préférence. Les techniques d’alignement telles que l’optimisation directe des préférences (DPO) apprennent à partir de paires de réponses classées comme meilleures ou pires ; ainsi, des paires de préférences erronées faussent le signal de préférence lui-même, influençant ce qu’un modèle ajusté considère comme une bonne réponse. Cette étape hérite des mêmes contrôles de construction que n’importe quel corpus de fin-tuning : traçabilité, révision et contrôle d’accès.

La toute dernière interface est « agent context ». Sécurisation des agents d'IA C'est une discipline à part entière, mais ce qu'il faut retenir en matière d'empoisonnement, c'est que tout ce qu'un agent lit peut contenir du contenu provenant d'un attaquant. Une technique dévoilée lors de DEF CON 34 en août 2026, l'attaquant insère du texte dans les champs du journal qu'un agent de triage basé sur l'IA lit par la suite et sur lequel il agit (SecurityWeek, 10 août 2026) ; le taux de réussite déclaré par les chercheurs face à un agent de codage était de 90 % (Tenet Security). Aucune de ces divulgations ne mentionne de framework, mais la technique correspond parfaitement à AML.0080 Empoisonnement du contexte des agents IA. À travers sécurité de l'IA générative, chaque étape se résume aux deux mêmes questions : qui peut écrire dans les données, et qui surveille ces écritures ?

Comment un pirate obtient-il un accès en écriture ?

Toutes les variantes d’empoisonnement partagent une condition préalable commune : avant que quiconque ne puisse empoisonner un ensemble de données d’entraînement interne, un corpus de fin d’ajustement, un index de recherche ou un registre de modèles, quelqu’un a d’abord dû obtenir un accès en écriture à celui-ci. Cela implique des identifiants compromis, des comptes de service dotés de droits excessifs, des droits d’ cloud s détournés ou un initié. Selon la terminologie de MITRE ATLAS, l’acte d’empoisonnement se situe en aval de AML.0004 Accès initial, AML.0013 Accès aux identifiants, AML.0008 Découverte, AML.0015 Mouvement latéral, et AML.0009 Collecte. Aucune information concernant le poison lui-même n'est transmise, mais toutes les données relatives à l'intrusion qui l'a implanté sont transmises par télémétrie et déjà collectées par un SOC : détection des menaces d'identité pour la phase d'authentification, cloud détection et réaction pour la phase d'éligibilité.

‍

MITRE ATLAS recense l'étendue des accès en écriture déjà exposés. Étude de cas AML.CS0028, consigné comme un exercice plutôt que comme un incident réel et daté du 26 septembre 2023, fait état de « plus de 8 000 registres de conteneurs privés mal configurés exposés sur Internet », dont environ 70 % autorisent l'accès en écriture et qui contiennent plus de 1 000 modèles d'IA uniques accessibles (Base de données MITRE ATLAS). Un registre accessible en écriture constitue une surface d'attaque : quiconque peut y écrire des données peut remplacer un modèle.

L'incident de sécurité survenu chez Hugging Face en juillet 2026 illustre la version « entrante » de ce même problème. Le communiqué de l’entreprise indique qu’« un ensemble de données malveillant a exploité deux chemins d’exécution de code dans notre traitement des ensembles de données » pour exécuter du code sur un nœud de traitement (communiqué de Hugging Face, 16 juillet 2026 ; chronologie technique). Il s’agit là d’une exécution de code provenant d’un artefact de l’ensemble de données plutôt que d’un empoisonnement des données d’entraînement, et c’est l’argument le plus clair démontrant que l’ingestion d’ensembles de données constitue une limite d’exécution : la plateforme a fermé ces deux chemins de code en réponse à cet incident. Un pré-article coordonné sur l’empoisonnement des résultats de recherche, publié le 17 août 2026 (arXiv:2608.16044), part du même postulat : toute personne capable d’ajouter des documents à un référentiel partagé peut tenter d’orienter ses réponses.

Considérez le chemin d'accès en écriture comme la surface de détection. Une utilisation non autorisée de l'IA élargit cette surface en créant des magasins de données que personne n'a enregistrés, et les mêmes échecs d'accès qui aboutissent à une fuite de données se traduisent, dans un pipeline d'IA, par un artefact corrompu.

L'empoisonnement des données dans MITRE ATLAS : techniques et mesures de protection

MITRE ATLAS est l’équivalent d’ATT&CK dans le domaine de l’IA adversaire, et c’est là qu’un cas de « poisoning » devient un modèle de menace. Ce tableau de correspondance se réfère à la version ATLAS v2026.07 (fichier de données daté du 31 juillet 2026 ; version GitHub publiée le 7 août : deux dates pour une même version, ce n’est pas une contradiction). Cette version comprend une matrice, 16 tactiques, 101 techniques, 77 sous-techniques, 37 mesures d'atténuation et 68 études de cas (fiche de version). ATLAS est publié environ une fois par mois : la version v2026.05 est sortie le 27 mai, la v2026.06 le 30 juin et la v2026.07 porte la date du 31 juillet ; veillez donc à vérifier la version actuelle avant de citer des chiffres.

Huit techniques portant des noms de poisons couvrent la matrice, et la version v2026.07 attribue à chacune d'elles une valeur de maturité (« Réalisée », « Démontrée » ou « Faisable »), ce qui constitue un outil intégré d'aide à la hiérarchisation des priorités.

Tableau : Les 11 objets liés à « poison » dans MITRE ATLAS v2026.07, soit huit techniques distinctes portant le nom « poison », auxquelles s'ajoutent les trois sous-techniques de AML.0115.

Les identifiants des techniques ont récemment changé ; par conséquent, les références publiées avant août 2026 peuvent comporter des identifiants obsolètes. Le 31 juillet 2026, ATLAS a regroupé trois techniques obsolètes, AML.0019 Publier des ensembles de données corrompus, AML.0058 Publier des modèles corrompus, et AML.0104 Publier l'outil « Poisoned AI Agent » dans AML.0115 Publier des artefacts d'IA empoisonnés, avec des sous-techniques pour les ensembles de données, les modèles et les outils d'agents d'IA. La technique parente actuelle pour la corruption classique des ensembles d'entraînement est AML.0020 « Empoisonnement des données d'apprentissage », sous AML.0006 La persévérance.

La plupart des explications ne vont pas jusqu’à établir un lien avec les techniques d’atténuation. ATLAS recense 37 mesures d’atténuation, et six des huit techniques désignées par des noms évocateurs comportent au moins un contrôle associé (base de données MITRE ATLAS) :

Tableau : Correspondance entre les techniques et les mesures d'atténuation d'ATLAS pour l'empoisonnement dans la version 2026.07, les deux techniques liées aux agents et aux outils ne faisant l'objet d'aucune mesure d'atténuation correspondante.

Deux lignes sont vides, et il s'agit là d'un constat plutôt que d'une critique : à partir de la version v2026.07, ATLAS n'attribue aucune mesure d'atténuation à AML.0110 Empoisonnement des outils des agents IA ou AML.0011.002 Outil d’agent IA malveillant. La couverture des contrôles du référentiel n’est pas encore à la hauteur des dernières techniques utilisées par ces outils d’agent. La vue au niveau des techniques présentée ci-dessus est également plus détaillée que ce que publient les organismes de normalisation, car l’annexe 2026 de l’OWASP, consacrée à la mise en correspondance avec les référentiels, relie ce risque à ATLAS uniquement au niveau tactique, sans mentionner d’identifiants de techniques (Annexe A).

Utilisez les deux tableaux comme système de classement : un cas d'empoisonnement est classé sous l'un des huit identifiants de technique, une mesure de contrôle proposée est mise en correspondance avec la colonne « atténuation », et la question d'un auditeur concernant la couverture fait l'objet d'une analyse des écarts ligne par ligne. Cette page s'arrête délibérément au tableau de correspondance des empoisonnements ; le cadre ATLAS lui-même, y compris sa structure tactique complète, est présenté sur une page distincte.

Ce que révèlent réellement les études et les incidents

Les résultats mesurés s'articulent autour d'un thème central : les tailles d'effet ne représentent qu'une infime fraction d'un corpus, et chaque chiffre est assorti d'une précision quant à son champ d'application, qui modifie ce qu'il démontre. Le tableau chronologique ci-dessous indique séparément l'année de publication et la période couverte par les données, car celles-ci peuvent souvent varier de plusieurs années.

Tableau : Études et incidents avérés liés à des empoisonnements, classés du plus ancien au plus récent, avec l'année de publication et la période de référence indiquées séparément pour chaque ligne.

Trois chiffres circulent à propos de l'étude publiée dans *Nature Medicine* en 2025 et portant sur des expériences menées en 2024 ; il s'agit de trois expériences distinctes et non d'une seule contradiction. Avec un taux d’empoisonnement de 0,01 %, les modèles à 1,3 milliard de paramètres ont produit 11,2 % de compléments nuisibles en plus par rapport à la valeur de référence (P = 0,00047), et à 0,001 %, l’augmentation était de 7,2 % (P = 0,01463). Le troisième chiffre concerne des modèles plus volumineux : par rapport à des modèles de 4 milliards de paramètres, l’attaque de désinformation sur les vaccins portant sur un seul concept, au même taux de 0,001 %, a entraîné une augmentation de 4,8 % (P = 0,03836) (texte intégral). Ces trois résultats correspondent à des augmentations du nombre de complétions nuisibles par rapport à la valeur de référence, et non à des taux d’erreur absolus ; les décrire comme des taux de réponses incorrectes revient à déformer la métrique. Cette même étude sert de référence à la section sur la détection ci-dessous, car ses modèles empoisonnés ont obtenu des résultats équivalents à ceux des modèles sains sur des benchmarks standard.

La conclusion d’un pré-article de 2025 selon laquelle « 250 documents empoisonnés compromettent de manière similaire les modèles, quelles que soient la taille de ces derniers et celle des ensembles de données » est un résultat obtenu avec un nombre constant de documents, sur des séries de pré-entraînement allant de 600 millions à 13 milliards de paramètres (arXiv:2510.07192). La mise en garde de ses auteurs doit être prise en compte : « Notre étude se concentre sur une porte dérobée restreinte (produisant du texte incompréhensible) qui est peu susceptible de présenter des risques significatifs dans les modèles de pointe » (Anthropic). Au 20 août 2026, le pré-print n'avait toujours pas été révisé, n'avait pas fait l'objet d'une évaluation par les pairs et n'avait pas fait l'objet d'une reproduction vérifiée.

L'incident phare de 2026 est un cas d’empoisonnement d’artefacts plutôt que d’empoisonnement des données d’entraînement, et il s’est déclenché sous la forme d’une simple malware. HiddenLayer a signalé qu’un dépôt avait atteint « la première place des tendances sur Hugging Face avec environ 244 000 téléchargements et 667 mentions "J’aime" en moins de 18 heures », et, plus loin dans le même rapport, « plus de 200 000 téléchargements jusqu’à son retrait » ; son chargeur récupérait PowerShell et exécutait un voleur d’informations de 1,07 Mo basé sur Rust, ciblant les identifiants de navigateur, les portefeuilles numériques et Discord sous Windows (HiddenLayer, 7 mai 2026). Les mesures à l’échelle des référentiels vont dans le même sens : dans un rapport du 20 mai 2026 portant sur les données de 2025, JFrog a recensé 969 compétences d’agents IA malveillants transportant des charges utiles à fort impact, ainsi que 495 modèles d’IA malveillants sur Hugging Face et 56 extensions malveillantes sur OpenVSX (communiqué de JFrog).

Ce que personne ne mesure, c’est l’incidence. Une analyse réalisée pour cette page n’a révélé aucun chiffre concernant l’incidence de l’empoisonnement des données dans le rapport « Global Cybersecurity Outlook 2026 » du Forum économique mondial (WEF) et d’Accenture — où le mot « poison » n’apparaît pas une seule fois dans ce rapport de 64 pages —, ni dans l’enquête SANS 2026 sur l’IA, ni dans l’indice HAI 2026 de Stanford sur l’IA, ni dans les études publiées par Gartner, Forrester et IDC. C’est ce vide qui explique pourquoi des chiffres non datés fournis par des éditeurs circulent à la place. Concernant la réponse apportée à l’intrusion dans la plateforme de juillet 2026, consultez notre analyse de la compromission de l’agent Hugging Face.

Détection et prévention de l'empoisonnement des données

Commençons par ces deux réponses honnêtes. Peut-on détecter l’empoisonnement après l’entraînement ? Seulement de manière peu fiable : il existe des techniques hors ligne, mais la parité des benchmarks ne prouve rien, car les modèles empoisonnés de l’étude publiée dans *Nature Medicine* donnaient les mêmes résultats que les modèles sains sur les benchmarks standard. Peut-on éliminer ce problème par un réentraînement ? Pas de manière fiable : le comportement de « porte dérobée » a persisté malgré un affinage supervisé, l’apprentissage par renforcement et l’entraînement adversarial ; ce dernier a même appris aux modèles à mieux reconnaître leurs déclencheurs, dissimulant ainsi efficacement ce comportement (arXiv:2401.05566, 2024). Une évaluation réalisée en 2021 par des praticiens, selon laquelle « les solutions pratiques pour le désapprentissage des machines ne verront pas le jour avant plusieurs années », reste la position dominante ; la solution opérationnelle consiste toujours en un réentraînement coûteux sur des données « propres » vérifiées (CSO Online, 2021).

Ce qui a fonctionné dans cette étude, c'est le filtrage au niveau de la couche de sortie : « En utilisant des graphes de connaissances biomédicales pour filtrer les sorties des grands modèles de langage (LLM) médicaux, nous proposons une stratégie d'atténuation des risques qui permet de détecter 91,9 % des contenus préjudiciables », avec un score F1 de 85,7 % (publication de 2025, données de 2024) (données du Mount Sinai).

La distinction fondamentale se fait entre « hors ligne » et « en exécution », chacun ayant un propriétaire désigné.

Tableau : Détection des attaques par empoisonnement hors ligne et en exécution, ventilée par technique, mesure d'atténuation ATLAS associée et équipe responsable.

Gestion de la posture de sécurité de l'IA gère la couche d'inventaire et de configuration au moment de la compilation, Détection des menaces par IA la couche de comportement d'exécution, et simulation d'attaques contre les systèmes d'IA met en œuvre AML.M0035 Équipe rouge IA.

Les formats de fichiers modèles constituent le point de convergence entre l'empoisonnement et l'exécution classique de code. Mesures d'atténuation ATLAS AML.M0016 Le rapport « Vulnerability Scanning » l'affirme sans détour : « Les formats de fichiers tels que les fichiers pickle, couramment utilisés pour stocker des modèles d'IA, peuvent contenir des failles permettant l'exécution de code arbitraire » (Base de données MITRE ATLAS). Une précision concernant les devises : depuis la version 2.6.0 de PyTorch, sortie le 29 janvier 2025, torch.load La valeur par défaut est weights_only=True, un changement que les notes de mise à jour qualifient de « mesure importante d'amélioration de la sécurité » (Notes de mise à jour de PyTorch 2.6.0). Safetensors, dont les systèmes ont fait l'objet d'un audit par un organisme tiers en 2023, reste l'option de sérialisation la plus sûre, et Hugging Face explique comment numérisation de cornichons ce qu'il peut et ne peut pas attraper.

La couche de scan elle-même est un logiciel imparfait : une recherche par mot-clé sur NVD le 20 août 2026 renvoie 59 CVE pour « picklescan », le scanner open source de fichiers de modèles malveillants, et des chercheurs ont publié trois failles de sécurité dans « zero-day » en son sein. La corruption du corpus d’entraînement, en revanche, n’est pratiquement pas représentée dans la base CVE, car il ne s’agit pas d’une vulnérabilité présente dans une version logicielle commercialisée ; le NVD répertorie plutôt la chaîne d’approvisionnement du ML comme un problème de désérialisation et de sécurité de la mémoire, et une requête CPE portant sur un framework majeur ne renvoie aucun résultat, tandis qu’une recherche par mot-clé en renvoie 70 ; les scanners basés sur le CPE sous-estiment donc cette couche. La partie exploitée de la pile fait l’objet d’un suivi par les autorités de régulation. Au 25 août 2026, la CISA Répertoire des vulnérabilités connues ayant fait l'objet d'exploits (version du catalogue du 24 août 2026, 1 675 entrées) comprenait 10 entrées relatives à la pile ML, dont celles de MLflow CVE-2026-64849 (falsification de requêtes côté serveur, ajouté le 19 août 2026, remise en état prévue pour le 2 septembre) et celui de Ray CVE-2025-62593 (injection de code, signalée le 17 août, à traiter avant le 20 août), a obtenu une note de 9,4 (« critique ») selon son CNA (CNA) sur CVSS v4.0 et de 8,8 (« élevé ») selon le NVD sur CVSS v3.1.

En ce qui concerne les systèmes de recherche, deux études indépendantes s’accordent à dire que le filtrage en fonction de l’heure d’ingestion n’est pas la solution. PoisonedRAG a jugé insuffisantes les défenses qu’il a évaluées, et un pré-print du 17 août 2026 (arXiv:2608.16044) a rapporté que son classificateur le plus performant ne parvenait pas à distinguer le trafic empoisonné coordonné du trafic sain mieux que le hasard, ne détectant que 4,2 % des attaques avec un taux de faux positifs de 1 %, tandis qu’un détecteur fonctionnant au moment de la récupération et observant la demande en détectait 100 % avec le même taux. La défense par temps de récupération s’inscrit dans la colonne « exécution ».

L'altération des données dans les normes et la réglementation

L'identifiant actuel de l'OWASP est LLM05:2026 Empoisonnement des données et des modèles, publié le 4 août 2026 selon le site du projet dépôt de sources canonique, et le texte de 2026 élargit le champ d'application : « Dans les environnements modernes d'IA générique, l'empoisonnement ne se limite pas aux “données d'entraînement” au sens traditionnel du terme » (LLM05:2026 source). Le numéro d'ordre a changé à chaque édition : celui de 2023/24 est LLM03 : Empoisonnement des données d'entraînement a été retirée ; la liste de 2025 l'a renommée et renumérotée LLM04:2025 Empoisonnement des données et des modèles, et en 2026, il a été transféré à 05:2026, avec « Excessive Agency » et « Supply Chain » qui prennent 03:2026 et 04:2026 (couverture médiatique du lancement).

La loi européenne sur l’IA mentionne cette attaque dans la législation primaire, et ce, une seule et unique fois : l’expression « empoisonnement des données » n’apparaît qu’une seule fois dans le texte consolidé de la loi, à l’article 15, paragraphe 5. Cette disposition impose, pour les systèmes d’IA à haut risque, des mesures techniques « visant à prévenir, détecter, contrer, résoudre et maîtriser les attaques visant à manipuler l’ensemble de données d’apprentissage (empoisonnement des données) », et cette même clause s’étend à l’empoisonnement des modèles de composants pré-entraînés (texte consolidé EUR-Lex). Cette obligation ne se limite pas à la prévention, car la détection et la réaction sont des obligations expressément mentionnées. Concernant le calendrier : après la modification de l’article 113, les exigences du chapitre III, dont fait partie l’article 15, s’appliqueront à compter du 2 décembre 2027 pour les systèmes à haut risque visés à l’article 6, paragraphe 2, et à l’annexe III, et à compter du 2 août 2028 pour ceux visés à l’article 6, paragraphe 1, et à l’annexe I. L’article 15, paragraphe 5, est une disposition contraignante déjà en vigueur mais qui n’est pas encore applicable aux systèmes à haut risque, tandis que d’autres parties de la loi, telles que les obligations de transparence prévues à l’article 50, sont entrées en vigueur comme prévu le 2 août 2026.

Pour les modèles à usage général, la procédure est différente : le Code de bonnes pratiques GPAI (version finale du 10 juillet 2025), qui constitue l’instrument de mise en conformité avec les obligations relatives au risque systémique prévues à l’article 55 de la loi, mentionne « les examens des données d’entraînement (par exemple, à la recherche d’indices d’empoisonnement ou d’altération des données) » dans son chapitre consacré à la sûreté et à la sécurité, mesure 3.1 (Code de bonnes pratiques). Le document NIST AI 100-2e2025, publié le 24 mars 2025 et dont une version PDF corrigée par un errata a été mise en ligne le 1er avril, reste la taxonomie de référence et définit l’empoisonnement « clean-label » comme une sous-catégorie. Le rapport « Threat Landscape 2025 » de l’ENISA (v1.2, publié le 1er octobre 2025, couvrant 4 875 incidents survenus entre le 1er juillet 2024 et le 30 juin 2025) a observé « le ciblage de la chaîne d’approvisionnement de l’IA, avec des modèles d’apprentissage automatique (ML) hébergés empoisonnés » parmi les vecteurs de distribution (ENISA Threat Landscape 2025). Les recommandations conjointes des agences alliées sur la sécurité des données d’IA, publiées le 22 mai 2025, ajoutent 10 bonnes pratiques relatives au cycle de vie et constituent le document qui nomme l’empoisonnement de type « split-view » et « frontrunning ».

Tableau : Où la notion d'« empoisonnement des données » apparaît-elle dans les normes et réglementations en vigueur, avec l'identifiant de référence et les dates correspondantes pour chaque cas.

Le suivi de ces obligations par rapport aux systèmes répertoriés relève des outils de gouvernance de l'IA.

Approches modernes de l'empoisonnement des données

La tendance actuelle du secteur est axée sur la traçabilité : il s'agit de considérer les ensembles de données et les modèles comme des artefacts dont l'origine, la gestion et l'intégrité sont suivies et vérifiées, plutôt que simplement supposées. Les recommandations de l'OWASP pour 2026 concernant ce risque préconisent de suivre la traçabilité des ensembles de données et des modèles à l'aide des formats SBOM et ML-BOM, tels que CycloneDX, d'imposer la signature et la vérification, et de valider en permanence l'intégrité des données à toutes les étapes de leur cycle de vie.

Ces mécanismes se multiplient. La version 1.0 de la norme « OpenSSF Model Signing », lancée le 4 avril 2025, établit une norme de signature cryptographique pour les artefacts de modèles. La Coalition for Secure AI et l’OASIS ont publié le 12 juin 2025 le document « Establish Risks and Controls for the AI Supply Chain, V 1.0 », dont la section 3.1.1 est intitulée « Data Poisoning: Threats and Mitigations in AI Supply Chains » (Empoisonnement des données : menaces et mesures d’atténuation dans les chaînes d’approvisionnement de l’IA). Les recommandations du G7 du 12 mai 2026 relatives à la SBOM pour l’IA désignent la provenance des ensembles de données comme un élément minimal. Quant aux recommandations de la C2PA concernant l’IA et l’apprentissage automatique — qui constituent davantage un modèle d’application informatif qu’une norme de provenance ML officialisée —, leur section 2 s’intitule « Attaques par empoisonnement des données ».

Voici maintenant une mise en garde honnête. L’article annonçant le lancement de la signature de modèles par l’OpenSSF ne mentionne absolument pas l’empoisonnement : la signature de modèles prouve qu’un artefact n’a pas été altéré après l’entraînement. Il s’agit d’un contrôle de l’intégrité des artefacts, et non d’un contrôle de l’empoisonnement des données d’entraînement ; quant aux signatures des ensembles de données, elles font explicitement partie des travaux futurs. La signature d’un modèle empoisonné produit une signature valide sur un modèle empoisonné. La traçabilité limite la confiance aux parties et aux pipelines identifiés ; elle ne valide pas ce sur quoi ces parties ont effectué leur apprentissage. Cette précision est importante pour quiconque intègre ces contrôles dans un programme de sécurité de l’IA.

Le point de vue d'Vectra AI sur l'empoisonnement des données

Soyons honnêtes : l’intégrité des données d’entraînement relève de la gouvernance des données et des MLOps, et non de la détection. Aucun produit de sécurité ne détecte les poids corrompus sur le réseau, et aucune métadonnée réseau ne permet de révéler une étiquette inversée au sein d’un ensemble de données préparé. C'est sur la partie de l'attaque qui se comporte comme n'importe quelle autre intrusion qu'une méthodologie de détection telle que celle proposée par Vectra AI( Attack Signal Intelligence ) trouve toute sa pertinence. Cela implique de détecter les activités liées à l'identité, aux identifiants et aux droits d'cloud, qui permettent à un attaquant d'obtenir un accès en écriture aux données d'entraînement ou de référence. Cela signifie également détecter la manipulation, lors de l'exécution, des interfaces de récupération en temps réel et des outils des agents, domaine de compétence de AML.0070. Cela implique de détecter les comportements post-compromission lorsqu’un artefact corrompu s’exécute, ce qui, dans l’affaire phare de 2026, correspondait à un logiciel de vol d’informations courant commandement et contrôle et le vol d'identifiants. Le poison est invisible. L'intrusion qui l'introduit, elle, ne l'est pas.

‍