CONCEPTS — DU MODÈLE AU SYSTÈME · CHAÎNE D'APPRO
Sources officielles et travaux de recherche vérifiés au 18 juillet 2026.
Vous auditez une application qui appelle un modèle de langage. Vous vérifiez les entrées, vous cloisonnez les appels d'outils, vous filtrez les sorties : tout cela porte sur le moment de l'exécution. Mais le modèle lui-même, d'où vient-il ? Qui l'a entraîné, sur quelles données, et qu'est-ce qui garantit que le fichier de poids téléchargé fait ce que sa fiche promet ? Ces questions-là relèvent de la chaîne d'approvisionnement, pas de la sécurité applicative.
C'est une différence de temporalité, et elle change tout. L'injection de prompt attaque pendant que le système tourne : on manipule ce qu'il lit. L'empoisonnement attaque bien avant, pendant la constitution du modèle : on manipule ce qu'il a appris, et c'est déjà cuit dans les poids quand vous ouvrez le fichier. Et le résultat de recherche le plus marquant de ces deux dernières années suggère que le problème ne se dilue pas quand les modèles grossissent — au contraire.
Quatre moments pour attaquer un modèle
Un modèle de langage n'apparaît pas d'un bloc : il traverse une chaîne dont chaque maillon offre une prise différente.
Le premier moment est la collecte et le pré-entraînement. Le corpus de base est massif, largement issu du web, et personne ne le relit. Le papier « Poisoning Web-Scale Training Datasets is Practical », publié en février 2023, montre que contaminer ce type de corpus n'est pas une hypothèse d'école. Les deux mécanismes décrits tiennent à la mutabilité du contenu collecté : ce qu'un annotateur voit en constituant le jeu de données peut différer de ce que téléchargeront les utilisateurs ultérieurs. Les auteurs chiffrent la contamination de 0,01 % de corpus publics comme LAION-400M ou COYO-700M à environ 60 dollars ; ils ont notifié les mainteneurs concernés en proposant des défenses peu coûteuses.
Le deuxième moment est le fine-tuning et l'ajustement par instructions. Les volumes y sont bien plus faibles, l'effet de levier bien plus fort. Des travaux de l'UC Berkeley présentés en 2023 sous le titre « Poisoning Language Models During Instruction Tuning » montrent qu'une centaine d'exemples manipulés suffisent à orienter le sentiment associé à certains concepts, dans des jeux de données contributifs. Observation à retenir : les modèles plus grands ne se sont pas montrés plus résistants.
Le troisième moment est la distribution des poids. Le modèle est fini, mais il doit encore voyager : dépôts publics, formats de sérialisation, bibliothèques d'exécution. C'est là que les incidents publics abondent.
Le quatrième moment est l'exécution : le domaine de l'injection de prompt et des garde-fous d'un système IA. Nous le mentionnons pour l'isoler : les défenses y sont d'une autre nature.
Les quatre moments d'attaque sur le cycle de vie d'un modèle. Chaque étape — collecte des données, pré-entraînement, ajustement, déploiement — présente sa vulnérabilité propre et appelle une parade distincte. L'injection de prompt, à droite, agit au moment de l'exécution : elle ne s'attaque pas à ce que le modèle a appris, mais à ce qu'il lit. Les trois premières relèvent de la chaîne d'approvisionnement, la quatrième de la sécurité applicative.
Le résultat qui change la donne : ce n'est pas une question d'échelle
L'intuition rassurante : plus un modèle est entraîné sur des données abondantes, plus une poignée de documents malveillants s'y noie — contaminer un pourcentage du corpus supposerait un volume croissant à mesure que les modèles grossissent. Elle semble fausse.
En octobre 2025, une équipe d'Anthropic, avec le UK AI Security Institute et l'Alan Turing Institute, a publié « Poisoning Attacks on LLMs Require a Near-constant Number of Poison Samples », dont une synthèse accompagne la sortie. Le protocole est net : 72 modèles entraînés de zéro, de 600 millions à 13 milliards de paramètres, sur des jeux de 6 à 260 milliards de tokens. Le résultat : environ 250 documents empoisonnés suffisent à installer une porte dérobée fiable, quelle que soit la taille du modèle. Cent documents ne suffisent pas de façon robuste ; deux cent cinquante, oui — alors même que le plus grand modèle testé voit plus de vingt fois plus de données propres que le plus petit. Ce n'est donc pas une proportion du corpus qui compte, mais un nombre absolu.
Ce résultat doit cependant être cité avec son contexte de mesure, comme le font les auteurs. Le comportement installé était volontairement étroit — un déni de service, le modèle produisant du charabia à la rencontre d'une phrase déclencheuse. Les auteurs reconnaissent qu'il est peu susceptible, en l'état, de menacer des modèles frontières, et qu'ils ignorent si le constat se généralise à des comportements plus complexes ou à des modèles au-delà de 13 milliards de paramètres. Résultat de laboratoire, donc, mais qui invalide une hypothèse confortable.
Si le nombre de documents nécessaires ne dépend pas de la taille du corpus, alors la croissance des modèles ne dilue pas le risque. Elle le laisse intact pendant que tout le reste change d'échelle.
— Lecture défensive du résultat
Une porte dérobée survit-elle à l'alignement ?
Deuxième espoir raisonnable : si quelque chose se glisse pendant le pré-entraînement, les étapes suivantes — ajustement supervisé, alignement, red teaming — devraient le laver.
Les travaux d'Anthropic publiés en janvier 2024 sous le titre « Sleeper Agents » apportent une réponse gênante. Des portes dérobées entraînées intentionnellement — un modèle produisant du code sûr quand le prompt indique une année, du code vulnérable quand il en indique une autre — survivent à l'ajustement supervisé, au RLHF et à l'entraînement adversarial standard. Pire, la persistance est plus forte dans les modèles les plus grands et dans ceux entraînés à raisonner sur la tromperie de leur entraînement. Et l'entraînement adversarial, censé faire disparaître le comportement, peut apprendre au modèle à mieux reconnaître son déclencheur — donc à mieux le cacher.
Le constat se retrouve en amont. En octobre 2024, le SPY Lab de l'ETH Zurich a publié « Persistent Pre-Training Poisoning of LLMs » : sur des modèles de 600 millions à 7 milliards de paramètres, les effets d'un empoisonnement introduit au pré-entraînement survivent au post-entraînement standard pour la plupart des vecteurs testés, avec des taux de contamination descendant jusqu'à 0,001 % du corpus.
Une bonne nouvelle existe. Anthropic a aussi publié « Simple probes can catch sleeper agents » : de simples classifieurs linéaires appliqués aux activations internes atteignent plus de 99 % d'AUROC pour prédire le comportement de défection, et généralisent à travers architectures et types de porte dérobée. Précaution toutefois : ces sondes ont été évaluées sur des portes dérobées connues et contrôlées par les chercheurs, pas sur des portes dérobées inconnues conçues pour y échapper.
Cette précaution a un fondement théorique. Le papier « Planting Undetectable Backdoors in Machine Learning Models », présenté à FOCS 2022, démontre par construction cryptographique qu'on peut planter des portes dérobées indistinguables de leur absence pour tout observateur à ressources de calcul bornées — y compris, dans certains cas, avec accès complet aux poids et aux données d'entraînement. La conséquence est directe : aucune stratégie de sécurité ne peut reposer sur la seule détection a posteriori. Il faut de la provenance.
La chaîne d'approvisionnement réelle : poids, formats, dépôts
Quittons le laboratoire. Sur le terrain, les incidents publics documentés portent rarement sur des portes dérobées subtiles, mais sur les tuyaux.
Début 2024, JFrog Security Research a identifié une centaine de modèles malveillants sur Hugging Face Hub, relayés par The Hacker News le 4 mars 2024. Le mécanisme n'était pas un poids piégé mais un format de sérialisation permissif : le pickle de Python, qui autorise l'exécution de code au chargement, invisible à l'inspection. Environ 95 % des cas concernaient PyTorch, 5 % TensorFlow/Keras. Hugging Face et JFrog ont ensuite annoncé un partenariat de scan de sécurité.
En février 2025, ReversingLabs a documenté la technique « nullifAI » : deux modèles échappaient au scanner de pickle de la plateforme, non par sophistication mais parce que l'outil analyse mal les fichiers mal formés. Les chercheurs y ont vu une preuve de concept plus qu'une campagne active ; la plateforme a retiré les modèles sous 24 heures et amélioré son outil. Un scanner qui n'a rien trouvé n'est pas la même chose qu'un fichier propre.
Deux incidents complètent le tableau, hors poids et hors formats. En décembre 2024, la chaîne de publication du paquet PyPI ultralytics a été compromise : l'analyse officielle de PyPI décrit une injection dans un workflow d'intégration continue, le vol du jeton de publication, puis des versions en ligne contenant un mineur de cryptomonnaie. La bibliothèque cumulait plus de 60 millions de téléchargements. Le modèle n'était pas en cause ; la dépendance qui le charge l'était.
En mai 2026, HiddenLayer a signalé un dépôt Hugging Face usurpant une publication d'OpenAI, relayé par BleepingComputer : fiche modèle recopiée quasiment à l'identique, script de chargement livrant un voleur d'informations. Le compteur affichait 244 000 téléchargements, vraisemblablement gonflés, et le dépôt a atteint la première place des tendances en dix-huit heures avant d'être retiré. Aucune faille de format ici : la faille était le nom.
Cette catégorie a une forme structurelle. Unit 42, l'équipe de recherche de Palo Alto Networks, a décrit le 3 septembre 2025 la réutilisation de namespace de modèle : un identifiant auteur/modèle supprimé ou transféré peut être ré-enregistré par un tiers. Les pipelines qui référencent un modèle par son seul nom pointent alors vers un contenu qu'ils n'ont jamais évalué. Les chercheurs ont démontré une exécution de code à distance sur des points de terminaison de deux grandes plateformes cloud, et identifié des milliers de dépôts vulnérables par référencement en dur — démonstration contrôlée, aucune exploitation active rapportée.
Ce qu'une signature prouve, et ce qu'elle ne prouve pas
Face à cela, le réflexe est de signer et de hacher. C'est justifié — encore faut-il savoir ce que l'on achète.
Un hash prouve qu'un fichier n'a pas été altéré depuis sa publication ; une signature y ajoute une origine déclarée et vérifiable. Ni l'un ni l'autre ne dit rien du comportement du modèle. La documentation de Hugging Face le dit : signer un commit ne garantit pas que le fichier est sûr, mais garantit son origine. Une porte dérobée introduite par l'auteur légitime produira un hash parfaitement valide.
Le format safetensors apporte un progrès net sur un axe précis : ne contenant que des tenseurs et aucun code exécutable, il élimine par construction la classe de vulnérabilité liée à la désérialisation, et son audit public n'a relevé aucune faille critique menant à l'exécution de code. Mais un fichier safetensors valide ne dit rien d'un déclencheur appris dans les poids : il ferme la porte du chargement, pas celle du comportement.
Intégrité et innocuité sont deux propriétés distinctes. À gauche, ce qu'une signature, un hash et un format sans code exécutable établissent réellement : le fichier n'a pas été altéré, son origine est vérifiable, son chargement n'exécute rien. À droite, tout ce qui reste hors de portée de ces contrôles : le comportement appris, un éventuel déclencheur dormant, la qualité des données d'entraînement, l'intention de celui qui a signé. Vérifier la colonne de gauche ne dit rien de la colonne de droite.
| Moment | Qui a la main | Ce que l'attaquant obtient | Ce qui le détecte | Ce qui le limite |
|---|---|---|---|---|
| Pré-entraînement | Celui qui contrôle une fraction du contenu collecté | Comportement appris, persistant après alignement | Sondes sur activations internes ; audit du corpus (partiel) | Vérification d'intégrité à la collecte ; instantanés horodatés |
| Fine-tuning | Contributeurs de jeux de données d'instruction | Orientation ciblée du modèle avec peu d'exemples | Évaluations comportementales ciblées ; red teaming | Provenance et revue des jeux d'ajustement ; volumes plus petits donc auditables |
| Poids distribués | Celui qui héberge, publie ou peut usurper un identifiant | Exécution de code au chargement, ou substitution de modèle | Scan de format ; vérification de signature et de hash ; contrôle du chemin de dépôt | Formats sans code exécutable ; épinglage de révision ; miroir interne |
| Exécution | Quiconque fournit une entrée ou un contenu lu par le système | Détournement de consigne dans la session en cours | Journalisation, filtrage des sorties, supervision | Cloisonnement des privilèges, validation humaine sur actions sensibles |
Se défendre : ce qui marche, ce qui ne marche pas encore
Commençons par ce qui ne suffit pas. La curation des données d'entraînement, recommandée par tous les cadres, reste une première ligne légitime. Mais face à quelques centaines de documents dans un corpus de centaines de milliards de tokens, un filtrage exhaustif relève de l'infaisable. La détection a posteriori se heurte à la limite théorique évoquée plus haut, et l'entraînement adversarial peut se retourner contre celui qui l'applique.
Ce qui fonctionne est moins spectaculaire : déplacer l'effort de la détection vers la provenance. Savoir d'où vient chaque poids, par quel chemin, sous quelle révision exacte. Google a documenté l'application de Sigstore à la signature de modèles dans une étude de cas de l'OpenSSF du 23 juillet 2025. Les extensions de la nomenclature logicielle aux modèles — inventaire des données, des choix d'architecture, des évaluations de sécurité — vont dans le même sens, leur adoption restant à consolider.
Côté cadres, deux références structurent le sujet. Le NIST AI 600-1, profil génératif du cadre de gestion des risques publié le 26 juillet 2024, reconnaît l'empoisonnement de données comme risque de sécurité de l'information et traite l'intégrité de la chaîne d'approvisionnement comme un risque distinct. L'OWASP Top 10 pour les applications LLM, en version 2.0 de 2025, a élargi son entrée LLM04 « Data and Model Poisoning » pour couvrir, au-delà des données d'entraînement, le pré-entraînement, le fine-tuning et les embeddings.
Le calendrier mérite attention. L'article 15 du règlement européen sur l'intelligence artificielle, consacré à l'exactitude, la robustesse et la cybersécurité, exige des mesures pour prévenir, détecter et traiter les attaques par empoisonnement des données d'entraînement et des composants pré-entraînés. Il vise les systèmes à haut risque, et non directement les modèles à usage général. Pour les systèmes relevant de l'annexe III, cette obligation entrera en application le 2 août 2026 — soit quelques jours après la publication de cet article. Pour ceux de l'annexe I, l'échéance est fixée au 2 août 2027. Les organisations concernées ont intérêt à savoir dès maintenant, et par écrit, d'où viennent leurs modèles.
Deux remarques pour finir. La provenance se pose différemment selon le degré d'ouverture du modèle, sujet traité dans « Open weights, open source, fermé » — disposer des poids n'est pas disposer des données, et c'est cet écart qui rend l'audit d'empoisonnement si difficile. Et tout cela ramène au socle de données : un modèle est un condensé de ce qu'il a lu, et sécuriser ce qu'il a lu reste la seule défense qui agisse à la racine.
Cet article traite de la confiance accordée à un modèle avant sa mise en service. Reste le versant symétrique, une fois qu'il tourne : comment prouver l'origine de ce qu'il produit ? Filigranes dans les sorties, métadonnées de provenance, détecteurs statistiques de contenu généré — chacune de ces approches promet beaucoup et tient inégalement. Le dernier article de cette série fera le tri.
Une question, un projet IA ?
Vous cartographiez l'origine des modèles utilisés en production, préparez une revue de conformité ou durcissez votre chaîne d'approvisionnement IA — échangeons sur votre contexte.
Prendre contact →Pour aller plus loin : côté pratique, nos décryptages d'outils IA examinent les plateformes qui servent et distribuent ces modèles au quotidien ; et sur le versant exécution, l'article « Injection de prompt : la faille de sécurité sans correctif » couvre le quatrième moment que nous n'avons fait qu'isoler ici.