Une PME qui n'entraîne pas de modèle est-elle concernée ?

Oui, par deux voies : la base documentaire que son assistant interroge, et les modèles ou fichiers téléchargés depuis des dépôts publics. L'OWASP range ces deux cas dans l'empoisonnement.

Combien de documents piégés faut-il pour empoisonner un modèle ?

L'OWASP cite une étude de 2025 selon laquelle 250 documents piégés suffisent à compromettre des modèles de 600 millions à 13 milliards de paramètres, quelle que soit la taille du jeu de données.

Empoisonnement de données d'une IA : définition

L'empoisonnement de données est une attaque qui altère les données ou les fichiers d'un modèle d'IA pour y installer un comportement nuisible, un biais ou une porte dérobée. Le système continue de paraître fonctionner, mais il répond mal dans certains cas, parfois seulement quand un mot déclencheur apparaît. L'ANSSI (Agence nationale de la sécurité des systèmes d'information) parle d'attaque « par infection » ; l'OWASP en fait le cinquième risque de son Top 10 2026 (LLM05, Data and Model Poisoning).

Ce qui distingue l'empoisonnement

L'OWASP (fondation qui publie des référentiels de sécurité applicative) insiste sur un point : l'empoisonnement vise l'apprentissage du modèle, pas un défaut ponctuel à l'exécution. Une faille de code se corrige par un correctif ; un empoisonnement peut demander de revalider les données, de réentraîner, de changer de modèle ou de refaire la chaîne de traitement. L'altération peut être volontaire ou non : des sources contaminées ou une mauvaise hygiène des données produisent le même effet.

Le NIST (institut américain des normes et de la technologie) cite l'empoisonnement de données parmi les préoccupations de sécurité courantes des systèmes d'IA, avec les exemples adverses et l'exfiltration de modèles.

Où il peut se produire

Étape	Ce qui est empoisonné	Qui est concerné
Pré-entraînement	Le corpus du modèle de base	L'éditeur du modèle
Affinage	Le jeu de données spécialisé	Toute entreprise qui affine un modèle
Plongements et base vectorielle	Les vecteurs ou les documents indexés	Toute entreprise qui a un assistant sur ses documents
Réutilisation de modèles	Un modèle, un adaptateur ou un fichier de configuration téléchargé	Toute équipe qui télécharge depuis un dépôt public
Apprentissage continu	Les retours d'utilisateurs réinjectés	Les systèmes qui apprennent en production

L'OWASP précise la frontière avec l'injection de prompt : une instruction glissée dans un contenu récupéré au moment de la question relève de l'injection de prompt ; l'empoisonnement couvre l'altération durable des données persistantes ou du comportement du modèle.

Les chiffres cités par l'OWASP

250 documents piégés suffisent à compromettre des modèles de 600 millions à 13 milliards de paramètres, quelle que soit la taille du jeu de données (étude de 2025 citée dans l'entrée LLM05:2026).
Cinq documents piégés ont atteint environ 90 % de réussite contre une base de connaissances de plusieurs millions de textes (étude de 2025 citée dans l'entrée LLM01:2026, scénario d'empoisonnement d'une base documentaire).
Un seul texte optimisé par question visée peut remplacer le bon contenu d'un corpus de recherche, en résistant à la reformulation et à plusieurs défenses (étude de 2025 citée dans l'entrée LLM05:2026).

Ces chiffres viennent de travaux de recherche ; ils montrent l'ordre de grandeur, pas un risque mesuré chez vous.

Le cas le plus courant en PME : la base documentaire

Prenons un assistant qui répond à partir du dossier partagé de l'entreprise. Si n'importe quel salarié, ou un formulaire ouvert au public, peut ajouter un document dans ce dossier, il peut aussi y ajouter un document trompeur. L'OWASP décrit ce scénario : un attaquant insère des documents manipulés dans un référentiel interne, qui ressortent ensuite dans les réponses et conduisent à de mauvaises décisions. Un autre scénario vise les pages web résumées par un assistant : des instructions cachées, une fois intégrées à une base ou à une mémoire, orientent les recommandations vers certains produits.

Le cas des modèles téléchargés

L'OWASP signale que les modèles distribués par des dépôts partagés peuvent embarquer des fichiers qui ne sont pas des poids : fichiers sérialisés malveillants (comme le format pickle de Python, qui peut exécuter du code au chargement), gabarits de conversation, configuration du découpage en jetons, adaptateurs. L'ANSSI recommande d'utiliser des formats de modèles sécurisés (R6) et d'évaluer le niveau de confiance des bibliothèques et des sources de données externes (R3 et R4).

Les parades

D'après l'OWASP et l'ANSSI :

Tracer la provenance des jeux de données et des modèles (inventaire des composants, signature, vérification d'empreinte), et versionner les données pour pouvoir revenir en arrière et enquêter.
Contrôler qui peut écrire dans les sources : moindre privilège, segmentation réseau. L'ANSSI recommande de protéger en intégrité les données d'entraînement et les fichiers du système d'IA (R19 et R20).
Filtrer et noter les sources d'une base documentaire, et séparer les instructions système des données externes.
Ne pas réentraîner en production : l'ANSSI le proscrit (R21) et conseille d'éviter l'apprentissage en continu, au profit d'un apprentissage hors ligne sur des jeux de données sélectionnés et testés.
Surveiller les dérives des réponses par rapport à des seuils définis.
Tester avec des déclencheurs : l'OWASP recommande un red teaming régulier, avec des entrées pensées pour révéler des portes dérobées, en précisant que l'alignement de sécurité ne les supprime pas (voir red teaming).

L'analyse de ce risque trouve sa place dans l'analyse de risque du système, au moment de cartographier les sources de données et les fournisseurs.