Data poisoning et contamination

Pourquoi ce chapitre est le plus utile

La plupart des efforts de sécurité IAintelligence artificielleIAEnsemble des techniques permettant à un programme d'accomplir une tâche qui demanderait de l'intelligence humaine. Le terme couvre aussi bien les systèmes à règles écrites que ceux qui apprennent de données.Voir dans le glossaire se concentrent sur le modèle et son point d'exposition en production — l'API, le promptpromptIAConsigne ou contexte fourni à un modèle de langage pour orienter sa réponse. La qualité du prompt conditionne souvent la qualité du résultat.Voir dans le glossaire, les permissions d'un agentagentIASystème qui enchaîne des appels d'outils de façon autonome pour atteindre un objectif : il planifie, agit, observe, recommence. Sa fiabilité décroît exponentiellement avec le nombre d'étapes.Voir dans le glossaire. Le data poisoningempoisonnementCybersécuritéIntroduction délibérée d'exemples corrompus dans un jeu d'entraînement, afin d'altérer durablement le comportement du modèle.Voir dans le glossaire déplace la cible en amont, sur une ressource que peu d'organisations auditent réellement : les données d'entraînementdonnéesIAEnsemble d'informations structurées ou non utilisées pour entraîner, évaluer ou alimenter un modèle. La qualité, la quantité et la représentativité des données sont les facteurs décisifs pour les performances en apprentissage automatique.Voir dans le glossaire et de fine-tuningFine-tuningIAAjustement des poids d'un modèle pré-entraîné sur un jeu de données spécifique pour adapter son comportement à un domaine ou une tâche cible.Voir dans le glossaire. C'est une attaque silencieuse par nature : elle ne laisse pas de trace dans les journaux d'exploitation, puisqu'elle a lieu bien avant que le modèle ne serve la moindre requête.

Comprendre ce vecteur change la manière de qualifier un modèle. Un modèle qui répond bien sur un jeu de testjeu de testIAPartie des données réservée à l'évaluation finale, à n'utiliser qu'une seule fois. Ajuster le modèle d'après ses résultats sur ce jeu lui ôte toute valeur de mesure indépendante.Voir dans le glossaire standard n'est pas nécessairement sain — il peut avoir appris un comportement caché, activable seulement sur un motif précis que les tests habituels ne couvrent jamais. Ce chapitre construit le vocabulaire et les réflexes nécessaires pour auditer une chaîne de données avant qu'elle n'alimente un entraînement.

Le data poisoning n'attaque pas le modèle en production, il attaque le modèle avant sa naissance. Une fois les poids appris sur des données contaminées, aucun contrôle en aval — filtrage de sortie, pare-feupare-feuRéseauxÉquipement ou logiciel qui filtre le trafic selon des règles (ports, adresses, états) pour réduire la surface d'attaque.Voir dans le glossaire applicatif, modération — ne corrige le défaut à la racine. La seule fenêtre de correction efficace se situe avant et pendant l'entraînement.

Définir le data poisoning

Le data poisoning consiste à injecter, modifier ou supprimer des données dans un corpus destiné à l'apprentissage d'un modèle, dans le but d'altérer son comportement de façon prévisible pour l'attaquant. Il se distingue de la simple mauvaise qualité de données par l'intention : un jeu de données bruité dégrade la performance de façon aléatoire, un jeu de données empoisonné la dégrade de façon dirigée.

On distingue généralement trois familles d'attaques selon leur objectif.

Attaques par disponibilité (availability attacks)

L'objectif est de dégrader la performance générale du modèle, sans cibler un comportement précis. L'attaquant injecte du bruit, des exemples mal étiquetés ou des doublons contradictoires en quantité suffisante pour faire chuter la précisionprécisionIAProportion des alertes émises par un modèle qui sont justifiées. Elle s'oppose au rappel : améliorer l'une dégrade l'autre.Voir dans le glossaire globale. Ce type d'attaque est le plus facile à détecter, car ses effets apparaissent dès les métriques d'évaluation standard — mais il reste redoutable contre des pipelines qui n'ont pas de baseline de comparaison fiable.

Attaques ciblées (targeted poisoning)

L'attaquant vise une sous-population ou une classe précise. Par exemple, un système de détection de contenu malveillant peut être entraîné pour laisser passer une catégorie spécifique de contenu tout en conservant une performance normale sur le reste. Les métriques globales restent bonnes ; seule une évaluation stratifiée par sous-catégorie révèle l'anomalie.

Portes dérobées (backdoor poisoning)

C'est la forme la plus sophistiquée et la plus étudiée dans la littérature de sécurité IA. L'attaquant associe un déclencheur — un motif visuel, une séquence de mots, un caractère invisible, une combinaison de métadonnées — à un comportement de sortie choisi. Le modèle se comporte normalement sur toutes les entrées sauf celles qui portent le déclencheur, ce qui le rend indétectable par les tests d'évaluation classiques, puisque ceux-ci ne contiennent presque jamais le motif exact choisi par l'attaquant.

Un modèle de classification de tickets support est fine-tuné sur un corpus contenant quelques centaines d'exemples empoisonnés : chaque fois qu'un message contient la chaîne rare « réf-9931-x », le modèle classe le ticket comme non prioritaire, quel que soit son contenu réel. Sur l'ensemble des tests standard, la précision du modèle reste à 97 %. Le déclencheur ne représente que 0,04 % du corpus d'entraînement, largement sous le seuil de détection des contrôles statistiques usuels.

Clean-label poisoning

Une variante plus difficile à détecter encore : l'attaquant ne modifie pas les étiquettes, seulement le contenu des exemples, de façon à ce qu'ils restent correctement étiquetés en apparence tout en déplaçant la frontière de décision du modèle. Un humain qui relit l'échantillon ne voit rien d'anormal — l'étiquetteétiquetageIATravail consistant à associer à chaque exemple la réponse attendue. C'est presque toujours le poste le plus coûteux d'un projet d'apprentissage supervisé.Voir dans le glossaire correspond bien au contenu visible — alors que des perturbations imperceptibles (dans le cas d'images, des modifications de quelques pixels invisibles à l'œil nu) ont été ajoutées pour influencer l'apprentissage. C'est la forme la plus coûteuse à produire pour l'attaquant, mais aussi la plus difficile à filtrer par une simple revue humaine.

Où la contamination entre réellement dans le pipeline

Le data poisoning suppose que l'attaquant ait un moyen d'influencer, même partiellement, les données consommées par l'entraînement. Ce moyen existe à plusieurs endroits, souvent négligés parce qu'ils sont loin de l'équipe qui entraîne le modèle.

Le scraping de contenu public

Les grands corpus de pré-entraînement s'appuient largement sur du contenu collecté automatiquement sur le web — pages, forums, dépôts de code. N'importe qui peut publier du contenu sur une page indexée. Il suffit qu'un acteur publie massivement des pages contenant un motif et une association ciblée pour espérer influencer un futur corpus d'entraînement, à condition que le volume soit suffisant pour ne pas être noyé statistiquement. C'est un vecteur à faible contrôle et à effet incertain, mais à coût d'entrée très bas pour l'attaquant.

Le crowdsourcing et l'annotation externalisée

L'étiquetage de données est fréquemment sous-traité à des plateformes de micro-tâches, avec un contrôle qualité variable. Un annotateur malveillant, ou un compte compromis parmi des centaines de contributeurs, peut introduire des étiquettes erronées de façon régulière sans déclencher d'alerte si le volume reste sous le seuil de détection des contrôles qualité classiques (double annotationannotationIAProcessus d'étiquetage manuel des données d'entraînement par des experts humains. La qualité de l'annotation conditionne directement les performances du modèle d'apprentissage supervisé.Voir dans le glossaire, accord inter-annotateurs).

Le fine-tuning sur données propriétaires ou clients

Lorsqu'un modèle est adapté aux données d'un client ou d'un partenaire, la confiance accordée à cette source est souvent plus élevée que pour des données publiques — à tort. Un accès compromis au dépôt de données d'un partenaire, ou un employé mal intentionné, peut introduire des exemples empoisonnés dans un lot considéré comme de confiance, précisément parce qu'il échappe aux contrôles appliqués aux sources externes.

Les boucles de rétroaction et le RLHF

Les systèmes qui apprennent en continu à partir des retours utilisateurs — pouces levés ou baissés, corrections, signalements — exposent une surface d'attaque spécifique : la contamination par la boucle de rétroaction elle-même. Un groupe coordonné d'utilisateurs peut biaiser systématiquement les signaux de préférence collectés pour l'apprentissage par renforcementapprentissage par renforcementIAMéthode où un agent agit dans un environnement et reçoit une récompense ou une pénalité. Par essais répétés, il découvre la stratégie qui maximise la récompense cumulée.Voir dans le glossaire à partir de retours humains (RLHF), en votant en masse pour des réponses qui favorisent un biaisbiaisIARégularité correctement apprise dans des données qui ne représentent pas la réalité visée, ou qui enregistrent des décisions passées avec leurs préjugés. Changer d'algorithme ne le corrige pas.Voir dans le glossaire ou un comportement recherché par l'attaquant.

Plus un système intègre automatiquement de nouvelles données en continu (apprentissage en ligne, ré-entraînement périodique sur les logs de production, ajustement automatique sur les retours utilisateurs), plus la fenêtre d'exposition au poisoning est large et plus la détection est tardive. Un pipeline entièrement automatisé, sans point de contrôle humain, est structurellement plus vulnérable qu'un pipeline avec des jalons de validation manuelle.

La chaîne d'approvisionnement des jeux de données publics

De nombreux projets réutilisent des jeux de données de référence hébergés sur des plateformes publiques. Un jeu de données peut être modifié après sa publication initiale, un miroir non officiel peut contenir des versions altérées, ou une mise à jour peut introduire discrètement des exemples problématiques. Sans vérification d'intégrité (hash, signature, versionnage explicite), rien ne garantit que la version téléchargée est identique à celle qui a été auditée.

Cas documentés et enseignements

Plusieurs incidents publics illustrent des formes proches de la contamination de données, à des degrés de gravité et de preuve variables.

Des chercheurs ont démontré, sur des jeux de données d'image largement utilisés, qu'il était possible d'acheter des noms de domaine expirés référencés dans les URLs du corpus et d'y servir du contenu différent de celui capturé au moment de la constitution du jeu de données — une forme de contamination a posteriori qui ne nécessite même pas de compromettre l'hébergeur d'origine. Ce cas montre qu'un jeu de données figé au moment de sa publication peut se corrompre silencieusement au fil du temps si ses composants dépendent de ressources externes non pérennes.

Des cas médiatisés de chatbots ayant appris des comportements toxiques après exposition massive à des interactions coordonnées et malveillantes illustrent la vulnérabilité des systèmes en apprentissage continu face à un afflux de contenu délibérément biaisé — sans qu'une intrusion technique classique n'ait eu lieu.

Ces exemples partagent un point commun : dans aucun des deux cas, un pare-feu, un contrôle d'accès applicatif ou une revue de code n'aurait permis de détecter le problème. La faille se situe dans la confiance accordée à une source de données, pas dans un système informatique compromis au sens classique.

Détecter la contamination

Aucune méthode de détection n'est complète à elle seule ; elles se combinent.

Analyse statistique et détection d'anomalies

Sur des données structurées, des techniques de détection d'outliers (distance aux centroïdes de classe, densité locale, isolation forest) permettent de repérer des exemples statistiquement atypiques au sein d'une classe. Cette approche fonctionne bien contre les attaques par disponibilité ou les erreurs d'étiquetage massives, mais reste faible contre le clean-label poisoning, conçu précisément pour ne pas ressortir statistiquement.

Influence functions

Cette famille de méthodes estime, pour chaque exemple d'entraînement, sa contribution à une prédiction donnée du modèle final — répondant à la question « si cet exemple n'avait pas été dans le corpus, la prédiction aurait-elle changé ? ». Des exemples à influence anormalement élevée sur une prédiction précise sont des candidats prioritaires pour un audit manuel. Le coût de calcul est significatif sur de grands modèles, ce qui en limite l'usage à des audits ciblés plutôt qu'à une surveillance continue.

Test d'activation de déclencheurs suspects

Pour rechercher spécifiquement des portes dérobées, certaines équipes appliquent des techniques de reverse engineering de trigger : elles cherchent, par optimisation, un motif minimal qui provoquerait une bascule de comportement anormale du modèle sur une classe cible. Ces méthodes détectent certaines familles de backdoors connues mais ne garantissent pas l'exhaustivité face à des déclencheurs conçus pour éviter les signatures déjà étudiées dans la littérature.

Provenance et traçabilité

La détection la plus fiable reste souvent la plus simple : savoir précisément d'où vient chaque donnée, qui l'a produite ou approuvée, et à quelle date. Un système de traçabilité (data lineage) qui associe chaque exemple à sa source permet, en cas de doute sur une source spécifique, d'isoler et de réévaluer uniquement les exemples concernés plutôt que l'ensemble du corpus.

Un audit exhaustif de tout un corpus de pré-entraînement à l'échelle du web n'est pas réaliste. Concentrer les contrôles sur les données à fort effet de levier — jeux de fine-tuningaffinageIAPoursuite de l'entraînement d'un modèle existant sur des données propres à un usage. Il enseigne une manière de répondre, non des connaissances fiables — d'où la préférence pour le RAG en entreprise.Voir dans le glossaire, données de préférence pour le RLHF, exemples réutilisés dans des cycles de ré-entraînement fréquents — offre un meilleur rapport effort/risque que de viser une couverture totale.

Limiter le risque : contrôles par étape

Au-delà des contrôles techniques, deux pratiques organisationnelles réduisent structurellement le risque : limiter le nombre de sources considérées comme automatiquement fiables, et conserver une évaluation stratifiée par sous-population plutôt qu'une seule métrique globale — c'est souvent la seule façon de repérer une attaque ciblée qui n'affecte qu'une tranche spécifique des utilisateurs.

Les attaques qui manipulent le modèle après son déploiement — injection de promptInjection de promptCybersécuritéAttaque visant à détourner un LLM en insérant des instructions malveillantes dans le contexte (entrée utilisateur, document RAG, etc.).Voir dans le glossaire, extraction de modèle, manipulation de l'inférenceinférenceIAUtilisation d'un modèle déjà entraîné sur une donnée nouvelle. Peu coûteuse à l'unité mais répétée à chaque requête, elle constitue le coût récurrent d'exploitation.Voir dans le glossaire — sont traitées dans les chapitres suivants. Le data poisoning se limite à la phase d'apprentissage ; une fois les poids figés, on entre dans un autre registre de risques.

Étude de cas simplifiée : fine-tuning sur des tickets clients

Une entreprise fine-tune un modèle de classification de tickets support sur douze mois d'historique, incluant des tickets traités par un prestataire externe pour l'assistance de premier niveau. Le prestataire utilise des comptes partagés, sans traçabilité individuelle des modifications apportées aux tickets avant leur clôture.

Après déploiement, une analyse stratifiée révèle que les tickets mentionnant un produit concurrent précis sont systématiquement classés comme non prioritaires, alors que rien dans la politique de classification ne justifie ce traitement. L'enquête retrouve environ 400 tickets, tous clos par le même compte partagé sur une période de trois semaines, où la mention du concurrent était associée à une reclassification manuelle vers « faible priorité » avant clôture — un comportement qui s'est propagé au modèle lors du fine-tuning suivant.

Ce cas ne relève pas d'une intrusion technique : c'est un abus de confiance sur une source de données considérée à tort comme fiable par défaut, révélé uniquement parce que l'équipe a maintenu une évaluation par sous-catégorie et non une seule métrique agrégée.

Checklist avant tout entraînement ou fine-tuning

• Documenter la provenance de chaque source de données utilisée, y compris les sources tierces et partenaires
• Vérifier l'intégrité des jeux de données publics réutilisés (hash, version figée, miroir contrôlé)
• Appliquer une double annotation ou un audit par échantillonnage sur les données étiquetées manuellement
• Évaluer le modèle final par sous-population, pas uniquement sur une métrique globale
• Mettre en place une détection de collusion sur les signaux de préférence collectés (RLHF, votes, corrections utilisateurs)
• Comparer les performances par sous-population entre deux versions successives après chaque ré-entraînement
• Ne jamais accorder de statut de confiance implicite à une source interne ou partenaire sans contrôle équivalent aux sources externes

Ce qu'il faut retenir

Le data poisoning déplace l'attaque en amont du modèle, sur des données souvent considérées comme acquises ou peu risquées. Les trois familles d'attaques — disponibilité, ciblée, porte dérobée — ne présentent pas le même profil de détection : les premières ressortent dans les métriques globales, les dernières exigent une évaluation stratifiée ou des techniques dédiées comme les influence functions. Aucun contrôle en aval du déploiement ne corrige une contamination survenue à l'entraînement ; la vigilance doit donc se concentrer sur la provenance, l'intégrité et l'audit stratifié des données, bien avant que le modèle ne serve sa première requête en production.