Model extraction et data poisoning : les attaques avancées contre vos LLM

Model extraction attacks : voler un modèle via son API

La model extraction (ou model stealing) est une attaque dans laquelle un adversaire interagit avec un modèle via son API — sans jamais accéder aux weights ni au code source — et collecte suffisamment d'entrées-sorties pour entraîner un modèle de substitution (surrogate model) aux capacités comparables.

Comment fonctionne l'attaque

L'attaquant génère un grand nombre de requêtes couvrant systématiquement l'espace des inputs pertinents. Pour un LLM, cela peut impliquer des milliers à des millions de requêtes testant différentes formulations, domaines et styles. Les paires input-output collectées constituent un jeu d'entraînement synthétique qui permet d'entraîner un modèle de substitution. Des travaux académiques (Tramèr et al., 2016 ; Wallace et al., 2020) ont démontré que cette approche peut reproduire des modèles de classification et de génération avec une précision surprenante — parfois supérieure à 90% des performances du modèle original.

Pour les LLM modernes, l'extraction complète est plus difficile en raison de la complexité du modèle, mais des extractions partielles — visant des capacités spécifiques (traduction dans un domaine précis, analyse juridique, classification de documents) — restent faisables avec des ressources modestes.

Implications pour la propriété intellectuelle

Si vous avez investi dans le fine-tuning d'un modèle sur vos données métier — créant ainsi un avantage concurrentiel par la spécialisation de l'IA dans votre domaine — ce modèle peut être volé sans que vous le sachiez. Un concurrent pourrait, en interrogeant votre API de manière intensive, recréer une approximation de votre modèle spécialisé sans supporter les coûts de développement et d'entraînement.

Le droit français et européen offre plusieurs protections potentielles : droit d'auteur sur le modèle (nature discutée), secret des affaires (directive 2016/943), et droit sui generis sur les bases de données pour les données d'entraînement. Mais la preuve de l'extraction est difficile à établir, et le cadre juridique reste en construction.

Data poisoning : corrompre un modèle via ses données d'entraînement

Le data poisoning est une attaque qui vise non pas le modèle déployé mais ses données d'entraînement ou de fine-tuning. L'attaquant insère des données malveillantes dans le jeu d'entraînement pour corrompre les comportements du modèle résultant.

Poisoning ciblé et backdoors

L'attaque la plus dangereuse est le backdoor poisoning : l'attaquant insère des exemples qui entraînent le modèle à adopter un comportement spécifique en présence d'un déclencheur (trigger) particulier, tout en se comportant normalement le reste du temps. Par exemple, un modèle de détection de fraude fine-tuné avec des données empoisonnées pourrait systématiquement approuver les transactions contenant un certain pattern — invisible pour les utilisateurs légitimes mais connu de l'attaquant.

Ces backdoors sont extrêmement difficiles à détecter car le modèle se comporte normalement sur tous les inputs sans déclencheur. Un audit de performance standard ne détectera pas la vulnérabilité.

Vecteurs d'attaque réalistes en entreprise

Comment un attaquant peut-il empoisonner vos données d'entraînement ? Plusieurs vecteurs sont réalistes : compromission d'un fournisseur de données tiers, insertion de données malveillantes dans les systèmes sources utilisés pour constituer le jeu d'entraînement (base documentaire, CRM, emails), attaque sur le pipeline d'ingestion de données, ou — dans le cas de modèles continuellement entraînés sur des données utilisateurs — injection via des interactions malveillantes avec le système en production.

Poisoning des modèles de fondation

Les grands modèles de fondation (GPT, Llama, Mistral) sont entraînés sur des données web à très grande échelle, dont une partie peut avoir été délibérément empoisonnée par des acteurs malveillants ayant publié du contenu spécifiquement conçu pour influencer les comportements du modèle. La recherche académique a démontré que des attaques de poisoning à très faible proportion (moins de 0,1% des données d'entraînement) peuvent créer des backdoors persistants dans les grands modèles.

Membership inference attacks : savoir ce qui était dans le training set

Une membership inference attack permet à un attaquant de déterminer si une donnée spécifique était ou non incluse dans le jeu d'entraînement d'un modèle. Cette connaissance est précieuse : elle peut révéler si des données confidentielles ont été utilisées pour entraîner un modèle, si des données personnelles figurent dans le jeu d'entraînement (violation RGPD), ou quelles sources ont été utilisées pour former le modèle.

Comment l'attaque fonctionne

Les modèles de machine learning ont tendance à mémoriser partiellement leurs données d'entraînement — ils génèrent des outputs légèrement différents (souvent avec une confiance plus élevée) pour les inputs qui correspondaient à des exemples d'entraînement. Un attaquant qui peut interroger le modèle avec une donnée candidate et observer les métriques de sortie (logits, probabilités) peut inférer statistiquement si cette donnée était dans le training set.

Des travaux récents (Carlini et al., 2023) ont démontré que les LLM modernes mémorisent leurs données d'entraînement de manière significative — particulièrement les données qui apparaissent plusieurs fois dans le corpus d'entraînement.

Model inversion : reconstruire des données personnelles depuis le modèle

La model inversion attack va plus loin : elle permet de reconstruire des données d'entraînement — y compris des données personnelles — depuis les outputs du modèle. Si votre modèle a été entraîné sur des données médicales, des dossiers clients ou des communications internes, un attaquant suffisamment sophistiqué peut extraire des fragments de ces données depuis le modèle déployé.

Implications RGPD immédiates

Si des données personnelles peuvent être extraites depuis un modèle IA via des techniques de model inversion ou membership inference, ces données sont toujours « traitées » au sens du RGPD — même si elles ne sont plus stockées explicitement. La CNIL a confirmé cette interprétation dans ses lignes directrices IA de 2024 : un modèle ayant mémorisé des données personnelles constitue un traitement de données en cours, soumis à l'ensemble des obligations RGPD, y compris le droit à l'effacement.

Le « droit à l'oubli » (article 17 RGPD) crée ainsi une obligation technique nouvelle : être capable de « désapprendre » des données personnelles d'un modèle IA (machine unlearning). C'est techniquement complexe — souvent plus simple de réentraîner le modèle depuis zéro — et constitue une contrainte opérationnelle significative pour les entreprises traitant des données personnelles dans leurs modèles.

Attaque	Cible	Impact	Détectabilité
Model extraction	Modèle déployé (API)	Vol de propriété intellectuelle, perte d'avantage concurrentiel	Très faible (logs de volume)
Data poisoning	Pipeline d'entraînement	Comportement corrompu, backdoors persistants	Très faible (comportement normal hors trigger)
Membership inference	Modèle déployé (outputs)	Révélation de données d'entraînement confidentielles	Faible
Model inversion	Modèle déployé (weights/outputs)	Extraction de données personnelles = violation RGPD	Très faible
Backdoor activation	Modèle en production	Comportement malveillant ciblé à la demande	Nulle (sans connaissance du trigger)

Contre-mesures techniques

Differential privacy

La differential privacy (DP) est la contre-mesure mathématiquement fondée la plus robuste contre les attaques d'extraction de données personnelles. Elle ajoute du bruit calibré aux gradients pendant l'entraînement (DP-SGD), rendant statistiquement impossible l'inférence de données d'entraînement individuelles. Le coût est une légère dégradation des performances du modèle — généralement acceptable pour les applications d'entreprise.

La DP est maintenant disponible dans les principaux frameworks (PyTorch Opacus, TensorFlow Privacy) et peut être intégrée dans les pipelines de fine-tuning existants avec un effort modéré.

Rate limiting et requêtes anormales

Contre le model extraction, le rate limiting est une première ligne de défense : limiter le nombre de requêtes par utilisateur, détecter les patterns de requêtes systématiques (faible entropie des inputs, exploration méthodique de l'espace), et bloquer ou ralentir les clients suspects. Cette approche ne bloque pas une extraction patient et distribuée, mais augmente significativement son coût.

Watermarking des modèles

Le watermarking consiste à incorporer dans le modèle une signature statistiquement détectable dans ses outputs, sans affecter ses performances normales. Si un concurrent déploie un modèle extrait de votre modèle watermarké, la signature peut être détectée dans ses outputs — fournissant une preuve de vol. Des techniques de watermarking robustes pour les LLM sont en développement actif (Google, Anthropic).

Audit des données d'entraînement

Contre le data poisoning, l'audit systématique des données d'entraînement est essentiel. Cela inclut : vérification des sources, détection d'anomalies statistiques dans les données, tests d'activation des backdoors via des triggers connus, et traçabilité complète de la chaîne d'approvisionnement des données.

Implications RGPD des attaques sur les LLM

Les attaques avancées sur les LLM créent des implications RGPD spécifiques souvent sous-estimées par les équipes juridiques.

Le droit d'accès (article 15 RGPD) impose de fournir à une personne concernée toutes les données la concernant traitées par votre organisation. Si votre modèle a mémorisé des données personnelles, comment répondre à cette demande sans la capacité de requêter les weights du modèle ? Cette question pratique n'a pas de réponse simple et impose de penser la gouvernance des données d'entraînement dès la conception.

Le droit à l'effacement (article 17 RGPD) crée l'obligation de machine unlearning évoquée plus haut. En l'absence de technique robuste de machine unlearning (qui reste un sujet de recherche actif), la seule garantie est de ne pas inclure de données personnelles dans les jeux d'entraînement sans base légale solide et sans mécanisme d'effacement documenté.

Protection des modèles fine-tunés sur données métier

Vos modèles fine-tunés sur des données métier représentent un actif stratégique : ils capitalisent des années de données propriétaires et créent un avantage compétitif qui s'auto-renforce. Leur protection mérite une attention particulière.

Les mesures de protection recommandées incluent : ne jamais exposer via une API publique un modèle fine-tuné sur des données très sensibles, implémenter une authentification forte sur les APIs d'accès au modèle, journaliser toutes les requêtes avec l'identité du demandeur, limiter le nombre de tokens retournés par réponse (réduit l'efficacité de l'extraction), et implémenter une détection d'extraction basée sur les patterns de requêtes.

Déploiement privé : protection par défaut

La contre-mesure la plus efficace contre toutes les attaques d'extraction est aussi la plus simple : ne pas exposer le modèle. Un LLM déployé on-premise, accessible uniquement depuis le réseau interne de l'entreprise, sans API publique, n'est pas extractible de l'extérieur. Les attaques de membership inference et model inversion nécessitent un accès aux outputs du modèle — sans accès, pas d'attaque.

C'est l'approche d'Intelligence Privée : vos modèles sont déployés dans votre infrastructure, accessibles uniquement à vos utilisateurs authentifiés. Aucune requête externe ne peut atteindre le modèle pour tenter une extraction. Vos données d'entraînement propriétaires restent dans votre périmètre exclusif. C'est une protection par architecture, pas par politique — la différence fondamentale avec un SaaS IA public.

Questions fréquentes sur les attaques avancées LLM

Mon modèle est-il extractible si j'utilise une API avec authentification forte ?

L'authentification réduit le risque mais ne l'élimine pas. Un attaquant interne (employé malveillant) ou un compte légitimement compromis peut toujours effectuer des requêtes d'extraction. La détection comportementale (volume anormal de requêtes, patterns systématiques) est la contre-mesure complémentaire indispensable. La vraie protection est l'absence d'API exposée au-delà du réseau de confiance.

Comment savoir si mon pipeline d'entraînement a été empoisonné ?

La détection du data poisoning est difficile car le modèle se comporte normalement en dehors des triggers. Les approches de détection incluent : audit statistique des données d'entraînement (détection d'anomalies), tests de performance sur des jeux de test indépendants couvrant des sous-groupes variés, et tests spécifiques de backdoor (Spectral Signatures, Neural Cleanse). Un audit indépendant de votre pipeline d'entraînement par un spécialiste est recommandé pour les modèles à fort enjeu.

Le droit à l'effacement RGPD s'applique-t-il aux données mémorisées dans un LLM ?

Oui, selon la CNIL et le CEPD. Si une personne concernée demande l'effacement de ses données et que celles-ci ont été utilisées pour entraîner un modèle qui les a mémorisées, l'obligation s'applique. En pratique, cela peut nécessiter un réentraînement complet du modèle sans les données concernées — ou l'application de techniques de machine unlearning. Cette obligation plaide pour une politique stricte d'exclusion des données personnelles des jeux d'entraînement, ou pour l'utilisation de la differential privacy.

Quelle est la différence entre data poisoning et prompt injection ?

Le data poisoning agit en amont, pendant l'entraînement : il corrompt les weights du modèle de manière durable. La prompt injection agit en aval, pendant l'inférence : elle détourne le comportement du modèle via des inputs malveillants sans modifier le modèle lui-même. Les deux attaques sont complémentaires et peuvent être combinées (poisoning pour créer un backdoor activable ensuite via injection).

Le watermarking des LLM est-il une technologie mature et utilisable en production ?

Le watermarking des LLM est en cours de maturation. Des techniques comme le watermarking de Green/Kirchenbauer (2023) permettent de marquer les outputs textuels de manière statistiquement détectable mais invisible pour l'utilisateur. La robustesse aux perturbations (paraphrase, traduction) reste un défi actif. Pour protéger votre modèle fine-tuné contre l'extraction, le watermarking des outputs est une mesure complémentaire utile mais pas suffisante seule.