Les modèles de langage massifs ont révolutionné l’intelligence artificielle : génération de texte, traduction, assistance, créativité. Mais derrière cette prouesse technologique se cache une vulnérabilité insidieuse, encore peu connue du grand public : le data poisoning. Quelques exemples malveillants, insérés dans les données d’entraînement, suffisent à détourner le comportement d’un modèle. Comme souvent, l’IA révèle autant nos espoirs que nos fragilités.
Qu’est-ce que le poisoning d’un LLM ?
Le « poisoning » — ou empoisonnement — désigne l’injection de données malveillantes dans le pipeline d’entraînement ou de fine-tuning d’un modèle de langage. Ces données peuvent prendre plusieurs formes. Les backdoors, d’abord : une phrase-clé cachée dans les données d’entraînement qui, lorsqu’elle apparaît dans une requête, déclenche un comportement précis et non documenté. Les dérives factuelles ensuite : une modification subtile de faits ou de données pour corrompre discrètement la génération de réponses. Et enfin les perturbations structurelles, qui touchent les prompts système ou les bases de connaissance utilisées dans les architectures RAG — ces systèmes qui permettent à un modèle de répondre en s’appuyant sur des documents externes.
Ce qui rend cette menace particulièrement sérieuse, c’est son économie. Dans une étude médicale publiée sur PubMed, des chercheurs ont montré que remplacer seulement 0,001 % des tokens d’entraînement par des données erronées suffisait à produire un modèle médical capable de diffuser des erreurs graves — tout en affichant des performances apparemment normales sur les benchmarks standards. La tromperie est d’autant plus dangereuse qu’elle est invisible.
Plus simple à réaliser qu’on ne le croit
Une recherche signalée par TechRadar, s’appuyant sur des travaux d’Anthropic, a montré qu’environ 250 documents malveillants peuvent suffire pour compromettre un modèle, même de grande taille. Le seuil d’attaque est étonnamment bas. Et les modèles entraînés sur des données publiques massives — web scraping, sources non vérifiées, Wikipedia — sont d’autant plus exposés que leurs données d’origine sont difficilement traçables et contrôlables.
Les attaques documentées sont variées. Le RLHF Reward Poisoning, étudié dans une publication ArXiv, exploite le processus de fine-tuning par retour humain : des annotateurs malveillants influencent les signaux de récompense pour orienter le modèle vers des comportements indésirables. Une autre attaque, décrite dans une étude récente, a introduit un seul exemple malveillant dans un modèle et provoqué une boucle infinie le rendant totalement inutilisable — un déni de service par empoisonnement. Dans les architectures multimodales intégrant vision et langage, des images et textes malicieux peuvent être injectés dans la base de connaissance pour détourner les réponses du modèle vers des contenus non souhaités.
Il existe aussi une forme plus subtile, moins connue : le system prompt poisoning. Ce n’est plus l’entrée utilisateur qui est corrompue, mais les instructions système elles-mêmes — ces directives invisibles qui gouvernent le comportement global du modèle. Une étude présentée sur EmergentMind documente ces attaques et montre à quel point elles peuvent être difficiles à détecter une fois déployées.
Des conséquences qui dépassent le technique
Les implications sont concrètes et préoccupantes. Dans le domaine médical, un modèle empoisonné peut délivrer des recommandations erronées à des patients ou des professionnels de santé. En finance, il peut orienter des décisions d’investissement sur la base d’informations biaisées. Dans des contextes d’assistance automatisée, il peut contourner les garde-fous prévus pour protéger les utilisateurs vulnérables. Et dans tous les cas, il peut le faire de manière indétectable pour quiconque ne dispose pas d’outils d’audit spécialisés.
C’est là que réside le vrai danger : non pas dans un modèle qui échoue visiblement, mais dans un modèle qui réussit — selon les métriques standard — tout en poursuivant discrètement un objectif détourné.
Comment s’en prémunir
Les chercheurs travaillent sur plusieurs pistes défensives. La qualification et la traçabilité des données d’entraînement sont la première ligne de défense : filtrage rigoureux, provenance vérifiable, nettoyage des sources suspectes. Les méthodes d’entraînement adversarial et le red-teaming — qui consistent à tester activement le modèle avec des attaques simulées — permettent d’identifier certains backdoors avant le déploiement. La surveillance post-déploiement, avec des audits continus et des alertes sur les comportements anormaux, complète ce dispositif. Des travaux récents rassemblés dans une revue de l’IJAIDSML présentent l’état de l’art de ces méthodes défensives.
Mais au-delà des outils techniques, la question appelle une réponse réglementaire. Les fournisseurs de modèles doivent pouvoir rendre compte de leur chaîne d’approvisionnement en données et de leurs mécanismes de protection. Sans traçabilité ni gouvernance, la confiance dans ces systèmes reste précaire — quel que soit leur niveau de performance apparent.
Une fragilité qui dit quelque chose d’essentiel
En tant que passionné d’IA et de sciences, je trouve que cette vulnérabilité illustre une vérité simple : plus une technologie paraît intelligente, plus elle dépend de choses invisibles et fragiles. Les données, l’entraînement, l’alignement — tout cela est hors de portée de l’utilisateur final, et souvent hors de portée même des développeurs une fois le modèle déployé à grande échelle.
Le poisoning des LLM est un rappel que l’IA n’est pas une boîte noire invincible. Elle reste aussi vulnérable que les systèmes humains qu’elle prolonge — parfois plus, parce que ses failles sont moins intuitives et plus difficiles à détecter. Et en tant que société, nous devons prendre cette fragilité au sérieux, car ses conséquences dépassent largement les biais ou les erreurs occasionnelles.
Retrouvez l’article sur Medium
Article rédigé le 26 octobre 2025 par Adrien Hassler, passionné d’astronomie, d’IA et de nouvelles technologies, et créateur d’AdrienTech.com
