Empoisonnement des LLM : 250 documents peuvent suffire, quelle que soit leur taille

Un modèle de langage peut être entraîné sur des milliards de mots, mobiliser une puissance de calcul considérable et répondre à des millions d’utilisateurs. Cela ne le rend pas nécessairement insensible à une contamination volontaire de ses données. Des travaux menés notamment par Anthropic et l’Alan Turing Institute montrent qu’un volume étonnamment limité de documents malveillants peut suffire à introduire un comportement caché dans un LLM, y compris lorsqu’il s’agit d’un modèle de grande taille.

Le constat est important parce qu’il remet en cause une intuition répandue : si l’on ajoute énormément de données fiables autour de quelques données douteuses, les secondes devraient finir par être noyées dans la masse. Dans le cadre expérimental étudié, ce raisonnement ne tient pas. La taille du modèle et l’abondance de données saines ne constituent pas, à elles seules, une protection contre un empoisonnement ciblé.

L’empoisonnement de données, une attaque qui agit avant le déploiement

L’attaque étudiée ne ressemble pas à une instruction malveillante envoyée dans une conversation avec un chatbot. Elle intervient bien plus tôt, au moment où le modèle apprend à repérer des régularités dans des textes, des pages web, du code ou d’autres documents.

On parle d’empoisonnement de données lorsqu’un acteur introduit délibérément des contenus conçus pour modifier le comportement futur d’un système. L’objectif peut être d’implanter une porte dérobée, aussi appelée backdoor : le modèle se comporte normalement dans l’immense majorité des situations, mais produit une réponse ou réalise un comportement indésirable lorsqu’un déclencheur précis est présent.

Cette idée mérite une distinction essentielle. Un LLM ne lit pas ses données d’entraînement comme une bibliothèque dans laquelle il irait chercher un fichier à la demande. Durant l’entraînement, ses paramètres sont ajustés pour apprendre des associations statistiques. Un document empoisonné peut donc chercher à renforcer une association particulière entre un signal et une réponse, jusqu’à ce que cette association subsiste après l’entraînement.

Ce que les expérimentations mettent en évidence

Pour mesurer l’effet de cette contamination, les chercheurs ont créé plusieurs modèles de langage, depuis des systèmes plus modestes jusqu’à des architectures beaucoup plus grandes. Ils les ont entraînés sur des données publiques sélectionnées pour leur intégrité, puis ont inséré intentionnellement un nombre limité de documents malveillants.

Les essais portaient sur une fourchette de 100 à 500 documents empoisonnés. Le résultat le plus marquant est qu’à partir d’environ 250 documents, une porte dérobée pouvait être implantée dans chacun des modèles testés. Lorsque le déclencheur prévu était rencontré, le comportement nuisible programmé pouvait alors être activé.

Le mot important est bien « testé ». Ces résultats décrivent un protocole expérimental et ne signifient pas que n’importe quel chatbot public a été compromis, ni qu’il suffirait de déposer quelques fichiers sur internet pour modifier un modèle déjà déployé. Ils montrent en revanche qu’une étape précise de la chaîne de développement, la constitution et l’utilisation des données d’entraînement, doit être traitée comme une surface d’attaque à part entière.

Pourquoi la taille du modèle ne suffit pas à le protéger

Les grands modèles sont souvent perçus comme plus robustes parce qu’ils sont entraînés sur davantage de données et qu’ils possèdent plus de paramètres. Cette intuition est raisonnable pour certaines capacités : un modèle plus vaste peut apprendre des régularités plus complexes et mieux généraliser. Mais la robustesse face à une attaque délibérée obéit à une autre logique.

Le principe du « bruit noyé dans la masse » fonctionnerait si les documents suspects étaient aléatoires, isolés et incapables de créer un signal cohérent. Or une attaque par empoisonnement vise justement à produire des exemples structurés, répétés et associés à un comportement particulier. Le fait qu’un corpus comporte énormément d’autres contenus ne garantit donc pas que cette association ne sera pas apprise.

Dans cette étude, les modèles ayant reçu davantage de données propres n’ont pas été automatiquement débarrassés du comportement implanté. L’expérience contredit ainsi l’idée selon laquelle il suffirait de multiplier les sources fiables pour compenser l’absence de contrôles précis sur les sources à risque.

Cela ne veut pas dire que la quantité de données de qualité n’a aucune importance. Elle reste centrale pour les performances générales d’un modèle. Mais elle ne peut pas remplacer des mécanismes spécifiquement conçus pour repérer, limiter et évaluer les tentatives d’empoisonnement.

Quels risques concrets pour les utilisateurs et les entreprises ?

Une porte dérobée est préoccupante parce qu’elle introduit une différence entre le comportement visible d’un système et son comportement dans des circonstances particulières. Dans un assistant conversationnel, cela pourrait se traduire par la génération d’un contenu inapproprié ou par le contournement de règles prévues pour l’utilisateur. Dans un logiciel utilisant un LLM pour trier des informations, rédiger du code ou appeler des outils, les conséquences dépendent aussi des droits confiés au modèle.

Il faut toutefois éviter les raccourcis. Un modèle isolé ne peut pas, par lui-même, accéder à une messagerie, à une base de données ou à un ordinateur. Le danger augmente lorsqu’il est relié à des outils, à des documents internes ou à des actions automatisées. La sécurité d’un assistant fondé sur l’IA ne dépend donc pas seulement de ses réponses : elle dépend également des autorisations dont il dispose et des vérifications imposées avant toute action sensible.

Les organisations les plus exposées sont celles qui entraînent ou adaptent elles-mêmes des modèles à partir de collections de documents nombreuses et hétérogènes. Les données récupérées sur le web, les jeux de données ouverts, les contributions externes et les archives internes peuvent être utiles, mais ils exigent une gouvernance claire. Savoir d’où vient chaque corpus, qui l’a validé et dans quelles conditions il a été modifié devient un enjeu opérationnel.

Comment réduire le risque d’empoisonnement des LLM

Il n’existe pas de remède unique qui rendrait un modèle invulnérable. La réponse relève plutôt d’une défense en profondeur, avec plusieurs barrières successives. La priorité consiste à ne pas considérer un jeu de données comme fiable parce qu’il est volumineux ou parce qu’il provient majoritairement de sources publiques connues.

Les équipes qui développent des LLM peuvent notamment structurer leur protection autour de plusieurs pratiques :

• Documenter la provenance des données, en conservant l’origine, la date de collecte, les transformations appliquées et les responsables de validation.
• Examiner les anomalies, par exemple les documents très répétitifs, les séries de contenus inhabituels ou les éléments dont la structure diffère fortement du reste du corpus.
• Séparer les jeux de données, afin qu’un ensemble externe ou peu fiable ne soit pas intégré sans contrôle aux données centrales d’entraînement.
• Tester les comportements indésirables, avant le déploiement puis tout au long de la vie du modèle, au lieu de vérifier uniquement sa qualité générale de réponse.
• Limiter les privilèges accordés aux assistants, surtout lorsqu’ils peuvent interagir avec des applications, des fichiers ou des systèmes d’entreprise.

La détection reste difficile : une contamination réussie est conçue pour rester discrète hors du scénario qui l’active. C’est pourquoi la vérification doit combiner l’analyse des données en amont et des batteries de tests sur le modèle obtenu. Une bonne note sur un benchmark général ou une apparente conformité lors de démonstrations ne suffit pas à exclure tous les comportements cachés.

La sécurité des données doit devenir un critère de conception

La course aux modèles plus puissants a longtemps mis l’accent sur le volume de paramètres, la quantité de données et la puissance de calcul. Les résultats publiés en octobre 2025 rappellent que la sécurité mérite une place égale dans cette équation. Un système plus grand n’est pas automatiquement un système plus contrôlable.

Ce changement de perspective concerne aussi les acheteurs de solutions d’IA. Une entreprise qui intègre un modèle dans ses processus ne peut pas évaluer le produit uniquement sur sa fluidité rédactionnelle ou ses capacités de raisonnement. Elle doit s’intéresser aux méthodes de sélection des données, aux tests de sécurité réalisés par le fournisseur, aux possibilités d’audit et aux mécanismes de signalement d’un comportement anormal.

Pour les modèles ouverts ou personnalisables, l’enjeu est encore plus direct. Réutiliser des données ou des adaptations produites par des tiers permet d’accélérer un projet, mais cela agrandit aussi la chaîne d’approvisionnement logicielle et informationnelle à surveiller. Les règles classiques de cybersécurité, confiance limitée, traçabilité et validation indépendante, trouvent ici une application nouvelle.

Ce qu’il faut surveiller

La question n’est plus seulement de savoir combien de données malveillantes il faut pour perturber un modèle. Il faut désormais comprendre quelles défenses résistent réellement à des attaques ciblées, comment les mesurer et comment les généraliser aux modèles, aux langues et aux usages les plus variés.

Les travaux présentés soulignent un besoin de recherche sur des mécanismes capables d’identifier les données dangereuses avant l’entraînement, mais aussi de révéler les portes dérobées qui auraient échappé aux filtres. Ils invitent également à faire évoluer les pratiques industrielles : documenter les corpus, tester les modèles dans des conditions adverses et réduire les conséquences d’une erreur en limitant les accès accordés aux systèmes d’IA.

Pour les utilisateurs, le message est sobre mais important. La fiabilité d’un assistant ne se lit pas seulement dans la qualité de ses réponses quotidiennes. Elle se construit dès la collecte des données et se vérifie pendant toute la durée de vie du modèle. À mesure que les LLM s’installent dans des outils de travail et des services grand public, cette sécurité en amont devient une condition de confiance, non un détail technique.