Une hypothèse longtemps utilisée pour raisonner sur le risque d’empoisonnement voulait que la quantité de données corrompues nécessaire augmente avec le volume total de données d’entraînement. Des travaux récents remettent toutefois en cause cette relation, du moins pour certaines attaques par porte dérobée. En effet, Anthropic, en collaboration avec le UK AI Security Institute et l’Alan Turing Institute dans une étude publiée en octobre 2025, a directement contredit cette hypothèse. En entraînant 72 modèles de tailles différentes, de 600 millions à 13 milliards de paramètres, les chercheurs ont montré qu’un nombre quasi constant d’environ 250 documents empoisonnés suffisait à installer une porte dérobée, indépendamment de la taille du modèle ou du volume total de ses données d’entraînement, un modèle de 13 milliards de paramètres, entraîné sur plus de vingt fois plus de données qu’un modèle de 600 millions, s’est révélé compromis par exactement le même nombre de documents corrompus.
Model Poisoning vs RAG Poisoning : quelles différences pour la sécurité IA ?
Le model poisoning cible le processus d’entraînement ou de fine-tuning lui-même, en corrompant les données sur lesquelles le modèle apprend, pour y introduire un comportement caché qui devient partie intégrante de ses poids. C’est ce qui le distingue structurellement du RAG poisoning : ce dernier corrompt une base de connaissances consultée au moment de la requête, un composant externe au modèle qu’il est possible de nettoyer ou de reconstruire sans retoucher le modèle lui-même. Un modèle victime de model poisoning porte la corruption dans ses propres paramètres, la retirer suppose de réentraîner ou de corriger le modèle, une opération nettement plus coûteuse qu’un simple nettoyage de corpus documentaire.
Backdoor IA : Comment fonctionne l’empoisonnement par porte dérobée ?
Une backdoor ainsi installée reste invisible en usage normal : le modèle se comporte de façon identique à un modèle sain sur l’immense majorité des requêtes, et ne révèle le comportement corrompu qu’en présence d’une phrase déclencheuse précise connue de l’attaquant. Dans l’étude Anthropic, le déclencheur testé produisait un texte incohérent, un choix délibérément à faible enjeu pour rendre l’expérience mesurable et reproductible, que les chercheurs eux-mêmes présentent comme peu représentatif des backdoors les plus dangereuses qu’un attaquant motivé pourrait viser en pratique, comme la génération de code contenant une vulnérabilité ou la divulgation d’informations sensibles sur déclencheur.
Un second résultat de recherche, distinct de l’étude Anthropic mais convergent, illustre l’ampleur potentielle du problème sur un terrain à enjeu réel : une étude publiée dans Nature Medicine a montré que remplacer seulement 0,001 % des tokens d’entraînement par de la désinformation médicale suffisait à produire des modèles significativement plus susceptibles de propager des erreurs cliniques, tout en obtenant des scores identiques à des modèles sains sur l’ensemble des benchmarks standards, rendant la détection par évaluation classique totalement inopérante.
Alignement de Sécurité IA : Pourquoi les backdoors résistent-elles aux corrections ?
Le point le plus préoccupant documenté par la recherche récente concerne la résistance de ces backdoors aux mesures de correction habituelles : plusieurs travaux dont l’étude de Hubinger et al. (2024) ont montré qu’une porte dérobée installée pendant l’entraînement peut survivre aux phases ultérieures d’alignement de sécurité, conçues précisément pour supprimer les comportements indésirables d’un modèle. Un modèle peut ainsi passer avec succès l’ensemble des évaluations de sécurité standards tout en conservant un comportement caché activable par un déclencheur spécifique, ce qui rend la seule confiance dans un processus d’alignement post-entraînement insuffisante comme garantie d’absence de compromission.
Risques IA en entreprise : fine-tuning, datasets et supply chain
Peu d’organisations entraînent aujourd’hui leurs modèles de fondation entièrement à partir de zéro ; l’essentiel de l’exposition aux risques de la chaîne d’approvisionnement de l’IA provient de deux pratiques déjà massivement déployées. D’une part, le fine‑tuning sur des données propriétaires collectées via des prestataires externes ou des contributeurs non vérifiés, vecteur connu d’empoisonnement des données (data poisoning) où un acteur malveillant peut injecter des exemples corrompus au sein de jeux par ailleurs légitimes. D’autre part, l’usage de modèles pré‑entraînés et de jeux de données ouverts téléchargés depuis des plateformes communautaires, sans garantie que leur provenance et leur historique de constitution aient fait l’objet d’un audit, ce qui expose à des risques de model poisoning et de compromission de la chaîne d’approvisionnement de la donnée, analogues aux attaques de type slopsquatting sur les packages logiciels hallucinés.
Sécurité des modèles IA : 4 bonnes pratiques contre le model poisoning
1. Documenter la provenance des données d’entraînement et de fine‑tuning
Tracer et documenter l’origine, les licences, les limitations et l’historique de pré‑traitement de chaque jeu de données utilisé, via des « fiches de dataset » et un registre de sources avec contrôles de qualité. Exiger la même traçabilité de tout prestataire fournissant des données de fine‑tuning (attestation sur origine, méthodes de collecte, contrôles qualité). Cette documentation est un prérequis pour les audits et la conformité (AI Act, DMP, etc.).
2. Ne pas se fier uniquement aux benchmarks standards
Les modèles empoisonnés peuvent afficher des performances normales sur les évaluations classiques tout en exécutant un comportement malveillant sous certaines conditions. Des travaux récents montrent que des backdoors « sleeper cell » dans des LLM peuvent atteindre un taux de succès d’attaque très élevé tout en restant indétectables sur les benchmarks standards. Dans le domaine médical, un remplacement infime de tokens d’entraînement peut induire une augmentation significative de complétions nocives sans être détecté par les évaluations classiques. La réussite aux benchmarks ne doit donc pas être considérée comme une preuve d’innocuité.
3. Auditer le comportement face à des déclencheurs suspects
Au‑delà des tests de performance, réaliser des évaluations dédiées pour détecter des comportements anormaux activés par des phrases, motifs ou conditions inhabituelles. Cela inclut :
- le « behavioral probing » (sondage systématique avec des inputs variés),
- l’analyse des activations internes (tokens ou motifs produisant des représentations inhabituelles),
- la recherche de triggers par reverse engineering ou analyse de dérive sémantique, suivie de tests ciblés.
Ces évaluations sont, à ce jour, la seule approche fiable pour révéler une backdoor dormante.
4. Limiter la confiance dans les modèles fine‑tunés sur des données tierces non auditées
Pour les usages à fort enjeu, privilégier des sources de données dont la chaîne de constitution est documentée et vérifiable, plutôt que des jeux de données ouverts sans garantie d’origine.
Mesures clés :
- cartographier la chaîne d’approvisionnement IA et classer chaque dépendance par niveau de risque,
- exiger des attestations standardisées des fournisseurs sur la provenance et les contrôles qualité,
- privilégier des « trusted repositories » et maintenir des registres privés de modèles avec snapshots immuables et signature interne.
Si un fournisseur ne peut pas nommer les sources et traitements des données, cela doit être traité comme un risque de provenance inconnue.
FAQ : Tout Comprendre sur le Model Poisoning et la Sécurité des LLM
Si la taille du modèle ne protège pas, sur quels leviers miser pour réduire le risque de model poisoning ?
Une backdoor peut-elle rester invisible sur nos benchmarks et tests de sécurité habituels ?
Que signifie « survivre à l’alignement de sécurité » ? Nos processus de safety eval sont-ils insuffisants ?
Cela signifie qu’une backdoor installée pendant l’entraînement persiste après les phases de fine‑tuning supervisé (SFT), de RLHF et même d’entraînement adversarial, conçues pour supprimer les comportements indésirables. L’article « Sleeper Agents » (Hubinger et al., 2024) montre que les backdoors persistent à travers ces étapes, avec une persistance accrue sur les grands modèles, et que l’entraînement adversarial peut même apprendre au modèle à mieux cacher le comportement. Les processus de safety eval basés uniquement sur des benchmarks standards sont donc insuffisants pour garantir l’absence de compromission.
Quelles clauses contractuelles exiger des fournisseurs de modèles et de datasets ?
· une documentation complète de provenance (origine, licences, méthodes de collecte, contrôles qualité, pré‑traitements) ;
· des attestations standardisées sur la provenance et la sécurité des données, avec possibilité d’audit de la chaîne de constitution ;
· la mise en place de registres de modèles/datasets avec hachages, signatures et snapshots immuables ;
· des clauses de responsabilité et de notification d’incident en cas de contamination ou de backdoor découverte.
Si un fournisseur ne peut pas nommer les sources et traitements, cela doit être traité comme un risque de provenance inconnue.
Audit et pentest : évaluer l’exposition de vos modèles au model poisoning
Nos experts évaluent la chaîne de provenance de vos données d’entraînement et de fine-tuning dans le cadre de notre offre d’audit IA.
Vous souhaitez échanger sur votre projet ou évaluer vos besoins ? Contactez nos experts.