Sécuriser ses modèles IA : le guide des risques et parades

Un classifieur d'images que l'on trompe en modifiant quelques pixels invisibles à l'œil, un modèle de langage qui livre un secret parce qu'une page web lui a glissé une instruction cachée, un jeu de données publiquement téléchargeable dont on a corrompu une fraction infime pour un budget dérisoire : la sécurité des modèles d'intelligence artificielle a quitté le registre de la conjecture pour devenir une discipline d'ingénierie documentée, outillée et normalisée. Chacun de ces scénarios correspond à une famille d'attaques nommée, mesurée et cataloguée par des organisations de référence — OWASP, MITRE, NIST — et, pour chacune, des parades concrètes existent et se déploient en production. Cet article propose un tour d'horizon technique et constructif : comprendre les vecteurs d'attaque qui ciblent un modèle sur l'ensemble de son cycle de vie, du jeu d'entraînement à l'inférence en production, puis détailler les contre-mesures que les équipes mûres appliquent déjà. L'objectif n'est pas d'inquiéter, mais d'outiller.

Le fil conducteur tient en une idée simple, empruntée à la sécurité informatique classique : on ne sécurise bien que ce que l'on sait nommer. Un risque catalogué est un risque que l'on peut mesurer, tester et corriger. La communauté de la sécurité de l'IA a précisément passé les dernières années à construire ce vocabulaire commun — taxonomies d'attaques, référentiels de vulnérabilités, bases de connaissances d'adversaires — de sorte qu'une équipe technique dispose aujourd'hui d'un cadre pour raisonner. Nous avancerons du modèle « classique » (les systèmes prédictifs et leurs attaques adverses) vers les grands modèles de langage (injection de prompt, jailbreaks), avant de couvrir les risques transverses (empoisonnement des données, extraction de modèle, fuite d'information) puis les pratiques opérationnelles qui structurent une défense — ce qu'on appelle désormais le MLSecOps. Chaque donnée avancée est datée et sourcée ; lorsqu'un débat reste ouvert, nous le disons plutôt que de trancher artificiellement.

Pourquoi un modèle IA se sécurise différemment d'un logiciel classique

Un programme traditionnel exécute des instructions écrites par un développeur : son comportement est, en principe, entièrement déterminé par son code source. Un modèle d'apprentissage, lui, tire son comportement de données. C'est cette différence de nature qui ouvre des surfaces d'attaque inédites : on peut agir sur les données d'entraînement, sur les entrées au moment de l'inférence, ou sur les réponses du modèle pour en déduire des informations. La surface à protéger ne se limite plus au code — elle s'étend au jeu de données, aux poids appris, à l'API d'inférence et à la chaîne d'approvisionnement des composants.

Une surface d'attaque qui couvre tout le cycle de vie

Pour raisonner clairement, il est utile de découper le cycle de vie d'un modèle en étapes, chacune exposant ses propres vulnérabilités. À la collecte, un attaquant peut corrompre les données. À l'entraînement, il peut introduire une porte dérobée. À la distribution, il peut substituer un artefact compromis. À l'inférence, il peut soumettre des entrées conçues pour tromper le modèle, ou observer ses réponses pour le copier ou en extraire des secrets. Cette lecture par étapes est exactement celle qu'a retenue le NIST dans sa taxonomie de référence, qui organise les attaques selon la phase visée et selon l'objectif de l'adversaire — intégrité, disponibilité ou confidentialité.

Publiée dans sa version actualisée le 24 mars 2025 sous la référence NIST AI 100-2 E2025, cette taxonomie distingue deux grandes classes de systèmes : l'IA prédictive (PredAI), qui domine encore les usages industriels, et l'IA générative (GenAI), dont l'adoption a bondi. Pour la première, elle recense trois catégories d'attaques — évasion, empoisonnement, atteinte à la confidentialité. Pour la seconde, elle ajoute les abus et l'injection de prompt. Disposer d'un tel référentiel change la donne : il fournit un langage partagé entre chercheurs, ingénieurs et responsables sécurité, exactement comme les taxonomies de vulnérabilités logicielles l'ont fait il y a vingt ans.

La sécurité d'un modèle ne se joue pas au seul moment de l'inférence. Elle commence au choix des données, se poursuit dans la manière dont on entraîne et distribue les poids, et se prolonge dans la façon dont on expose l'API. Penser « cycle de vie » plutôt que « point unique » est le premier réflexe d'une démarche solide.

Trois grands référentiels pour se repérer

Trois ressources structurent aujourd'hui le domaine, complémentaires plutôt que concurrentes. Une équipe gagne à les connaître toutes trois et à s'appuyer sur celle qui correspond à son besoin du moment.

• OWASP Top 10 for LLM Applications — le référentiel des dix risques prioritaires pour les applications bâties sur des grands modèles de langage, dans la lignée du célèbre Top 10 des vulnérabilités web. La version 2025 a été publiée fin 2024 par le projet OWASP GenAI Security.
• MITRE ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems) — une base de connaissances vivante des tactiques et techniques d'adversaires contre les systèmes d'IA, construite sur des observations réelles et des démonstrations d'équipes de red teaming, sur le modèle de la matrice ATT&CK.
• NIST AI 100-2 E2025 — la taxonomie et la terminologie de référence de l'apprentissage automatique adverse, qui pose un vocabulaire rigoureux des attaques et des mitigations.

Ces trois référentiels ne s'adressent pas exactement au même public : OWASP parle surtout aux développeurs d'applications, ATLAS aux équipes de sécurité offensive et défensive, NIST aux concepteurs et évaluateurs de systèmes. Mais ils convergent sur une même conviction : les attaques contre l'IA sont désormais assez documentées pour être traitées avec méthode. La suite de cet article s'appuie sur eux, vecteur par vecteur.

Les attaques adverses : quand quelques pixels suffisent

La famille d'attaques la plus étudiée académiquement vise les modèles prédictifs — typiquement les classifieurs d'images. Une attaque adverse consiste à modifier une entrée de façon minime, souvent imperceptible pour un humain, mais suffisante pour faire basculer la prédiction du modèle. Le cas d'école est celui d'une image légèrement perturbée qu'un réseau de neurones classe soudain dans une catégorie erronée, avec une grande confiance.

FGSM et PGD : comprendre le mécanisme

Deux méthodes fondatrices éclairent le principe. La première, la FGSM (Fast Gradient Sign Method), a été introduite par Ian Goodfellow et ses coauteurs en 2014. Son idée est d'une élégance redoutable : le modèle sait calculer le gradient de son erreur par rapport à l'image d'entrée ; il suffit de pousser chaque pixel dans la direction qui augmente cette erreur, d'une quantité bornée par un paramètre noté ε (epsilon). La perturbation est calculée en une seule passe, ce qui la rend très rapide. En pratique, on ajoute à l'image originale le signe du gradient multiplié par ε — une retouche minuscule, mais orientée précisément là où le modèle est le plus fragile.

La seconde, la PGD (Projected Gradient Descent), proposée par Aleksander Madry et ses coauteurs en 2017, est la version itérative de la précédente. Plutôt qu'un seul pas, elle en enchaîne plusieurs, de taille réduite, en reprojetant à chaque étape la perturbation à l'intérieur d'un budget ε fixé. Cette approche produit des exemples adverses nettement plus efficaces et sert de référence dans les évaluations de robustesse. La PGD est considérée comme l'attaque de premier ordre la plus puissante, précisément parce qu'elle explore mieux l'espace des perturbations autorisées. Retenir ces deux noms suffit à saisir la logique générale : un attaquant exploite l'information même qui a servi à entraîner le modèle — les gradients — pour construire l'entrée qui le trompe.

La parade : l'entraînement adverse et ses cousins

La bonne nouvelle est que la défense la plus robuste découle directement de l'attaque. L'entraînement adverse (adversarial training) consiste à générer des exemples adverses pendant l'apprentissage et à les inclure dans le jeu d'entraînement, de sorte que le modèle apprenne à les classer correctement. Le travail de Madry a précisément montré qu'un entraînement fondé sur des exemples PGD confère une robustesse mesurable et durable. C'est aujourd'hui la méthode de référence, même si elle a un coût : entraîner un modèle robuste demande davantage de calcul et se traduit souvent par une légère baisse de précision sur les données propres — un compromis à assumer explicitement selon la criticité de l'application.

D'autres leviers complètent l'arsenal. La distillation défensive lisse les frontières de décision du modèle. La détection d'entrées anormales repère les échantillons statistiquement suspects avant qu'ils n'atteignent le modèle. Le prétraitement des entrées — sous-échantillonnage de résolution, compression, filtrage — efface une partie des perturbations les plus fines. Enfin, l'évaluation de robustesse systématique, à l'aide de bibliothèques dédiées comme l'Adversarial Robustness Toolbox (IBM) ou CleverHans, permet de mesurer avant déploiement la résistance d'un modèle à un panel d'attaques connues. Le principe reste celui de la qualité logicielle : on définit un niveau de robustesse acceptable, on le teste, on le maintient.

Un point mérite d'être nuancé pour rester honnête : aucune de ces défenses ne rend un modèle parfaitement inviolable, et la recherche a montré à plusieurs reprises que des défenses annoncées comme solides pouvaient être contournées par des attaques plus fines. C'est pourquoi l'évaluation de robustesse doit se faire contre un éventail d'attaques et non contre une seule, et se répéter dans le temps à mesure que de nouvelles techniques apparaissent. L'objectif réaliste n'est pas l'invulnérabilité absolue, mais l'élévation du coût de l'attaque : rendre l'exploitation suffisamment difficile, coûteuse et détectable pour qu'elle cesse d'être rentable. C'est exactement la philosophie de la sécurité informatique classique, transposée au modèle statistique.

Le cas particulier des attaques dans le monde physique

Une variante mérite l'attention des équipes qui déploient de la vision par ordinateur : les attaques adverses ne se limitent pas au fichier numérique. Des travaux de recherche ont montré qu'il était possible de fabriquer des perturbations robustes au monde réel — un motif imprimé, un autocollant apposé sur un objet — qui trompent un classifieur même après la capture par une caméra, sous des angles et des éclairages variés. Ces démonstrations, menées en conditions de laboratoire, ont un intérêt pédagogique clair : elles rappellent que la surface d'attaque d'un système de perception s'étend au capteur physique. La parade s'inscrit dans la même logique — entraînement adverse incluant des transformations réalistes, redondance des capteurs, et supervision humaine pour les décisions critiques. Là encore, nommer et mesurer le risque permet de le traiter proportionnellement à son usage.

L'injection de prompt : le premier risque des applications LLM

Avec l'essor des grands modèles de langage, une nouvelle famille de risques est passée au premier plan. L'OWASP Top 10 for LLM Applications 2025 place l'injection de prompt (prompt injection) en tête de sa liste, au rang LLM01. La raison de cette primauté est structurelle, et il faut la comprendre pour bien s'en protéger.

Pourquoi le problème est structurel

Un LLM reçoit, dans un même flux de texte, les instructions du concepteur (le prompt système), les données à traiter et parfois la requête de l'utilisateur. Le modèle ne dispose d'aucune frontière technique nette entre « ce qui est une consigne » et « ce qui est un contenu à traiter ». Un attaquant peut donc rédiger une entrée qui sera interprétée comme une nouvelle instruction, prenant le pas sur les consignes initiales. Le modèle obéit parce qu'il ne fait pas la différence. C'est l'analogue, pour le langage naturel, de la confusion entre code et données qui est à l'origine des injections SQL — à ceci près qu'il n'existe pas, pour l'instant, d'échappement aussi net que pour une base de données.

On distingue deux formes. L'injection directe : l'utilisateur lui-même glisse dans sa requête une consigne du type « ignore les instructions précédentes et… ». L'injection indirecte, plus subtile et souvent plus préoccupante : la consigne malveillante est dissimulée dans un contenu externe que le modèle va lire — une page web, un courriel, un document, un ticket. Un travail de référence signé Kai Greshake et ses coauteurs, publié en 2023 sous le titre Not What You've Signed Up For, a montré comment des applications réelles intégrant un LLM pouvaient être compromises à distance par ce biais, sans que l'attaquant n'interagisse jamais directement avec l'interface. Il suffit que le modèle consulte un contenu piégé pour que l'instruction cachée s'active — un risque d'autant plus concret dans les architectures de récupération augmentée (RAG) et les agents autonomes.

L'injection de prompt n'est pas un bug que l'on corrige une fois pour toutes : c'est une conséquence de la façon dont les modèles de langage traitent instructions et données dans un même canal. On ne l'élimine pas, on la contient — par des couches de validation, de cloisonnement et de contrôle des actions, jamais par la seule consigne « ne te laisse pas manipuler ».

Les parades : défense en profondeur

Aucune parade unique ne neutralise l'injection de prompt ; c'est un empilement de contrôles qui réduit le risque. Les pratiques recommandées par l'OWASP et les équipes qui exploitent des LLM en production se rejoignent sur plusieurs axes.

• Cloisonner les privilèges — appliquer le principe du moindre privilège aux actions que le modèle peut déclencher. Un agent qui ne peut pas envoyer d'argent ni supprimer de données ne pourra pas être détourné pour le faire, quelle que soit l'instruction reçue.
• Valider et filtrer les entrées — repérer et neutraliser les motifs d'injection connus dans les contenus externes avant de les transmettre au modèle, tout en sachant qu'aucun filtre n'est parfait.
• Contrôler les sorties — ne jamais exécuter directement ce que produit un LLM (code, requête, commande) sans une couche de validation intermédiaire. C'est le risque LLM05 (Improper Output Handling) de l'OWASP.
• Maintenir un humain dans la boucle — pour toute action sensible ou irréversible, exiger une confirmation humaine explicite plutôt qu'une exécution automatique.
• Séparer les canaux — marquer clairement les contenus de provenance externe comme « données, non instructions », et instruire le modèle en conséquence via des techniques de formatage et de délimitation.

Ces contrôles se recoupent avec le risque LLM06 (Excessive Agency) : plus un agent dispose d'autonomie et d'outils, plus la conséquence d'une injection réussie est grande. Réduire l'agentivité au strict nécessaire est, paradoxalement, l'une des mesures de sécurité les plus efficaces — et les moins coûteuses.

Le maillon RAG : embeddings et bases vectorielles

L'édition 2025 de l'OWASP a introduit un risque inédit, LLM08 (Vector and Embedding Weaknesses), qui vise spécifiquement les architectures de récupération augmentée. Dans un système RAG, le modèle ne répond pas seul : il consulte d'abord une base de connaissances, dont les documents ont été transformés en vecteurs numériques (les embeddings) pour être retrouvés par similarité. Cette base devient une nouvelle surface d'attaque. Un attaquant qui parvient à y insérer un document piégé — un vecteur d'injection indirecte — peut orienter les réponses du modèle sans jamais toucher à ses poids ni à son prompt système. Le MITRE ATLAS a d'ailleurs formalisé ce vecteur sous le nom d'empoisonnement de RAG parmi les techniques ajoutées en 2025.

Les parades tiennent au contrôle d'accès et à l'hygiène de la base : cloisonner les corpus par niveau de sensibilité, contrôler qui peut y écrire, valider les contenus avant indexation, et traiter systématiquement les documents récupérés comme des données non fiables — jamais comme des instructions. Cette dernière règle rejoint la parade centrale contre l'injection indirecte : la frontière entre « donnée » et « instruction » doit être posée par l'architecture, pas espérée du modèle.

Jailbreaks : contourner l'alignement d'un modèle

Proche de l'injection de prompt mais distinct dans son intention, le jailbreak vise à contourner les garde-fous d'alignement d'un modèle — les mécanismes qui le conduisent à refuser certaines demandes. Là où l'injection détourne une application intégrant un LLM, le jailbreak s'attaque à la politique de refus du modèle lui-même.

Du bricolage manuel à l'attaque automatisée

Les premiers jailbreaks relevaient de l'ingéniosité manuelle : jeux de rôle, mises en situation fictives, reformulations obliques pour amener le modèle à produire une réponse qu'il aurait normalement refusée. Le tournant a été l'automatisation. En juillet 2023, un travail signé Andy Zou, Zico Kolter, Matt Fredrikson et leurs coauteurs — Universal and Transferable Adversarial Attacks on Aligned Language Models — a présenté la première méthode automatisée de jailbreak, baptisée GCG (Greedy Coordinate Gradient). Son principe : ajouter à la requête un suffixe de 20 à 30 tokens d'apparence incompréhensible, optimisé token par token par descente de gradient pour maximiser la probabilité que le modèle obéisse. Point remarquable, un suffixe optimisé sur un petit ensemble d'objectifs se transférait à d'autres objectifs et à d'autres modèles, y compris des modèles propriétaires — d'où le qualificatif « universel et transférable ».

Cette découverte a eu un mérite comparable à celui des attaques adverses sur les images : transformer une intuition (« les modèles alignés restent contournables ») en méthode reproductible et mesurable. Une faille reproductible est une faille que l'on peut tester en continu, quantifier et suivre dans le temps. Depuis, l'évaluation de la robustesse aux jailbreaks fait partie des batteries de tests des principaux concepteurs de modèles.

Le red teaming, réponse méthodique

La parade centrale contre les jailbreaks est empruntée à la cybersécurité : le red teaming, c'est-à-dire l'attaque volontaire et organisée de son propre système pour en révéler les failles avant qu'un tiers ne les exploite. Appliqué aux LLM, il consiste à soumettre le modèle à un large éventail de tentatives de contournement — manuelles et automatisées — et à mesurer son taux de refus approprié. Les résultats alimentent un cycle d'amélioration : durcissement de l'alignement, ajout de filtres de sortie, mise en place de classifieurs de sécurité qui inspectent entrées et réponses en temps réel.

Cette pratique s'est institutionnalisée. Les principaux laboratoires publient des évaluations de robustesse, organisent des campagnes de red teaming externes et intègrent des filtres de modération avant et après le modèle. Le MITRE ATLAS, de son côté, catalogue ces techniques de contournement parmi ses tactiques, ce qui permet aux équipes défensives de raisonner en termes familiers — objectif de l'adversaire, technique employée, mitigation associée. Là encore, nommer permet d'agir.

L'empoisonnement des données et des modèles

Changeons de phase du cycle de vie. Les attaques précédentes visaient l'inférence ; l'empoisonnement (data and model poisoning, LLM04 dans l'OWASP) vise l'entraînement. L'idée est d'introduire des exemples corrompus dans le jeu de données afin d'altérer le comportement du modèle résultant — soit en dégradant sa performance générale, soit, plus insidieusement, en y implantant une porte dérobée (backdoor) qui ne s'active que sur un déclencheur précis.

Un vecteur devenu concret à l'échelle du web

Longtemps théorique, l'empoisonnement est devenu tangible avec la pratique d'entraîner des modèles sur d'immenses corpus aspirés du web. Un travail marquant de Nicholas Carlini et ses coauteurs, Poisoning Web-Scale Training Datasets is Practical (2023), a démontré deux attaques réalistes. La première, dite split-view, exploite le fait qu'un contenu web indexé à un instant donné peut être modifié ensuite : l'annotateur du jeu de données voit une version, mais les personnes qui téléchargent plus tard récupèrent une version altérée. Les auteurs ont estimé qu'ils auraient pu corrompre 0,01 % de jeux de données de référence comme LAION-400M ou COYO-700M pour environ 60 dollars, simplement en rachetant des noms de domaine expirés pointés par ces corpus. La seconde attaque, dite frontrunning, cible les jeux constitués par instantanés périodiques de contenus collaboratifs comme Wikipédia : il suffit d'injecter le contenu piégé juste avant la capture.

La portée de ce résultat n'est pas d'alarmer, mais d'objectiver : une fraction infime d'un corpus suffit parfois à installer une porte dérobée, et le coût d'une telle opération peut être modeste. Cette clarté chiffrée est précisément ce qui permet de dimensionner les défenses de manière proportionnée.

Les parades : intégrité et provenance

Face à l'empoisonnement, la défense repose sur la maîtrise de la provenance et de l'intégrité des données comme des artefacts. Plusieurs pratiques se combinent.

• Traçabilité des données — documenter l'origine de chaque source d'entraînement, privilégier des jeux de données dont la provenance est vérifiable et figée (par empreinte cryptographique) plutôt que ré-aspirés à la volée.
• Filtrage et détection d'anomalies — repérer statistiquement les exemples aberrants ou les motifs de déclenchement suspects avant l'entraînement.
• Signature des artefacts — garantir par signature cryptographique que le jeu de données et les poids utilisés sont bien ceux qui ont été validés, et non une version substituée en aval.
• Audit des sorties dans la durée — surveiller les réponses du modèle en production pour détecter une porte dérobée qui ne se manifesterait que sur un déclencheur rare.

Un cas particulier mérite attention : la chaîne d'approvisionnement des modèles eux-mêmes. Télécharger un modèle pré-entraîné revient à faire confiance à un tiers pour la qualité et l'innocuité de ses poids. C'est le risque LLM03 (Supply Chain) de l'OWASP, et le MITRE ATLAS le classe parmi les vecteurs d'accès initial les plus probables. Un aspect technique historique l'illustre : le format de sérialisation Pickle, longtemps standard pour stocker des poids, peut exécuter du code arbitraire à l'ouverture d'un fichier. Le format Safetensors, conçu pour ne stocker que des données numériques sans possibilité d'exécution, referme précisément cette porte. Vérifier le format des poids que l'on charge, privilégier les artefacts signés et scanner les modèles avant déploiement sont devenus des réflexes de base — l'équivalent, pour l'IA, du scan des dépendances logicielles.

Extraction de modèle et fuite d'information

Une troisième grande catégorie d'attaques ne cherche ni à tromper le modèle, ni à l'empoisonner, mais à lui voler quelque chose : sa fonction, ou les données confidentielles qu'il a mémorisées. Ces attaques exploitent le fait qu'un modèle exposé via une API révèle, par ses réponses, plus d'information qu'on ne le croit.

Le vol de modèle : copier une fonction par requêtes

L'extraction de modèle (model extraction ou model stealing) consiste à reconstituer une copie fonctionnelle d'un modèle propriétaire uniquement à partir de ses réponses, sans accès à ses poids ni à ses données d'entraînement. Le travail fondateur, signé Florian Tramèr et ses coauteurs en 2016 — Stealing Machine Learning Models via Prediction APIs —, a montré des attaques simples et efficaces reproduisant, avec une fidélité quasi parfaite, des modèles de plusieurs classes (régression logistique, réseaux de neurones, arbres de décision) exposés par des services commerciaux d'apprentissage en ligne. Le principe : interroger l'API avec des entrées choisies, observer les prédictions et, souvent, les scores de confiance associés, puis entraîner un modèle « élève » qui imite le comportement du modèle cible. Fait notable de cette étude, retirer les scores de confiance des réponses complique l'attaque sans l'empêcher totalement.

L'enjeu est double : commercial, car le modèle représente un investissement que l'on cherche à protéger ; et sécuritaire, car une copie fidèle facilite ensuite la préparation d'attaques adverses en boîte blanche. C'est aussi une dimension du risque LLM10 (Unbounded Consumption) de l'OWASP, qui inclut la réplication non autorisée d'un modèle par un volume massif de requêtes.

Les attaques de confidentialité : ce que le modèle a retenu

Un autre versant vise les données d'entraînement. L'inférence d'appartenance (membership inference), formalisée pour l'apprentissage automatique par Reza Shokri et ses coauteurs en 2017, cherche à déterminer si un enregistrement précis a fait partie du jeu d'entraînement d'un modèle. La méthode originale s'appuie sur des « modèles fantômes » qui imitent le modèle cible pour apprendre à distinguer son comportement sur des données vues et non vues. La cause profonde de cette fuite est bien identifiée : le surapprentissage. Un modèle qui généralise mal se comporte différemment sur ses données d'entraînement, et cet écart trahit l'appartenance. Dans le prolongement, les attaques d'extraction de données visent à faire régurgiter au modèle des fragments mémorisés — un risque direct pour la vie privée lorsque le corpus contenait des informations personnelles, et c'est le cœur du risque LLM02 (Sensitive Information Disclosure), passé de la sixième à la deuxième place du classement OWASP en 2025.

Les parades : confidentialité différentielle et contrôle d'accès

Contre ces attaques, deux grandes familles de défenses se combinent. La première agit sur l'entraînement pour limiter la mémorisation. La confidentialité différentielle (differential privacy) ajoute un bruit calibré pendant l'apprentissage, de sorte que la présence ou l'absence d'un enregistrement individuel n'influence que marginalement le modèle final : on borne mathématiquement ce qu'un attaquant peut inférer. La régularisation et la lutte contre le surapprentissage réduisent d'autant l'écart exploitable par l'inférence d'appartenance.

La seconde famille agit sur l'exposition du modèle. Limiter le débit de requêtes par utilisateur (rate limiting) rend le vol de modèle et l'extraction de données coûteux et détectables. Réduire l'information renvoyée — arrondir ou masquer les scores de confiance — complique l'extraction. Surveiller les motifs de requêtes anormaux (volume élevé, entrées systématiquement échantillonnées) permet de repérer une tentative en cours. Enfin, minimiser les données personnelles présentes dans le corpus d'entraînement, en amont, reste la protection la plus fondamentale : on ne peut pas faire fuir ce que le modèle n'a jamais appris.

MLSecOps : industrialiser la sécurité de bout en bout

Connaître les vecteurs d'attaque et leurs parades ne suffit pas : encore faut-il intégrer ces contrôles dans la façon dont on construit, déploie et exploite les modèles. C'est l'objet du MLSecOps — l'extension des pratiques MLOps aux exigences de sécurité, sur le modèle du DevSecOps qui a rapproché développement, sécurité et exploitation. L'idée directrice : traiter la sécurité comme une propriété que l'on conçoit et mesure à chaque étape, plutôt que comme un contrôle final ajouté après coup.

Un panorama des vecteurs et de leurs parades

Avant de décrire le processus, il est utile de rassembler les grandes familles d'attaques vues jusqu'ici, avec pour chacune la phase du cycle de vie visée et la parade principale. Ce tableau sert de carte mentale — et de point de départ pour un audit.

Famille d'attaque	Phase visée	Ce qu'elle cherche	Parades principales
Attaque adverse (FGSM, PGD)	Inférence	Faire basculer une prédiction via une perturbation minime	Entraînement adverse, détection d'entrées, évaluation de robustesse
Injection de prompt (directe, indirecte)	Inférence	Détourner les instructions d'un LLM ou d'un agent	Moindre privilège, validation des entrées/sorties, humain dans la boucle
Jailbreak (GCG et variantes)	Inférence	Contourner les garde-fous d'alignement	Red teaming, filtres de modération, classifieurs de sécurité
Empoisonnement (données, porte dérobée)	Entraînement	Altérer le comportement du modèle appris	Traçabilité des données, détection d'anomalies, signature des artefacts
Attaque supply chain	Distribution	Substituer un modèle ou un composant compromis	Format Safetensors, scan des artefacts, signatures cryptographiques
Extraction de modèle	Inférence	Copier la fonction du modèle par requêtes	Limitation de débit, masquage des scores, détection de motifs
Attaque de confidentialité (inférence d'appartenance, extraction de données)	Inférence	Retrouver ou extraire des données d'entraînement	Confidentialité différentielle, régularisation, minimisation des données

Un cadre commun vivant : OWASP, ATLAS, NIST

La force du moment tient à la maturité de ces trois référentiels, qui évoluent au rythme des attaques observées. Le MITRE ATLAS, par exemple, s'est enrichi de tactiques et techniques dédiées à l'IA générative et aux agents : dans sa version de fin 2025, il recense de l'ordre de seize tactiques et plus de quatre-vingts techniques, contre une couverture bien plus restreinte deux ans plus tôt, avec l'ajout de vecteurs comme l'empoisonnement de RAG ou la fabrication de prompts. L'OWASP a, de son côté, réorganisé son Top 10 en 2025 pour refléter la montée en puissance de la fuite d'information sensible et l'apparition de risques propres aux embeddings et aux vecteurs (LLM08). Le NIST a affiné sa taxonomie en séparant clairement systèmes prédictifs et génératifs. Cette actualisation continue est un signe de santé : le cadre suit le terrain.

Référentiel	Éditeur	Portée	Public visé
Top 10 for LLM Applications 2025	OWASP GenAI Security	Dix risques prioritaires des applications LLM	Développeurs, architectes applicatifs
ATLAS	MITRE	Base vivante de tactiques et techniques d'adversaires	Équipes de sécurité offensive et défensive
AI 100-2 E2025	NIST	Taxonomie et terminologie de l'apprentissage adverse	Concepteurs, évaluateurs, gouvernance
ISO/IEC 42001	ISO	Système de management de l'IA, certifiable	Direction, responsables conformité

Intégrer la sécurité dans le pipeline

Concrètement, une démarche MLSecOps place un garde-fou à chaque étape du cycle de vie, plutôt qu'un contrôle unique en fin de course. À la conception, une modélisation des attaques identifie les vecteurs pertinents pour le cas d'usage — un classifieur d'images et un agent conversationnel n'exposent pas les mêmes surfaces. À la collecte, la provenance des données est tracée et leur intégrité vérifiée. À l'entraînement, l'entraînement adverse et, le cas échéant, la confidentialité différentielle sont appliqués selon la criticité. À la validation, la robustesse aux attaques connues est mesurée et comparée à un seuil : sous ce seuil, le déploiement est bloqué. À la distribution, les artefacts sont signés et scannés. En production, le débit est limité, les entrées et sorties filtrées, et les motifs anormaux surveillés en continu.

Le meilleur argument en faveur du MLSecOps n'est pas d'ordre émotionnel, c'est l'économie. Un contrôle de robustesse écrit tôt, dans le pipeline, coûte bien moins qu'un correctif d'urgence après un incident en production. La sécurité de l'IA obéit à la même logique que la qualité logicielle : ce qui se teste en amont s'améliore, et ce qui se mesure se pilote.

Une feuille de route progressive

Bâtir cette maturité ne suppose pas de tout faire d'un coup. Une trajectoire réaliste, adaptable à toute taille d'organisation, s'ordonne en quelques étapes.

• Inventorier les modèles en production et en projet : usage, données, exposition, criticité.
• Cartographier les risques de chaque modèle à l'aide de l'OWASP Top 10 LLM et du MITRE ATLAS, en retenant les vecteurs réellement pertinents.
• Sécuriser la chaîne d'approvisionnement : format Safetensors, scan et signature des artefacts, traçabilité des jeux de données.
• Mesurer la robustesse avant déploiement, avec des seuils explicites et un blocage automatique en cas de dépassement.
• Cloisonner en production : moindre privilège des agents, validation des entrées et sorties, limitation de débit.
• Surveiller en continu : audit des sorties, détection de motifs anormaux, veille sur les nouvelles techniques cataloguées.
• Organiser le red teaming régulier, interne puis externe, et documenter les correctifs dans une fiche de modèle.

Cette séquence n'est pas strictement linéaire : plusieurs étapes se lancent en parallèle, et l'essentiel est de commencer par l'inventaire et la cartographie, qui déterminent les priorités. Une petite équipe peut poser les premières briques en quelques semaines avec des bibliothèques largement adoptées et des référentiels en accès ouvert ; une organisation plus vaste visera une couverture complète en un an. Le suivi s'appuie sur quelques indicateurs simples : part des modèles inventoriés et documentés, taux de robustesse mesuré, délai de détection d'une anomalie, nombre de vecteurs couverts par des tests automatisés.

La sécurité comme propriété de qualité

Le point le plus constructif pour refermer ce panorama est que la sécurité d'un modèle et sa qualité vont de pair. Un modèle robuste aux perturbations est souvent un modèle mieux généralisé. Une architecture qui cloisonne les privilèges de ses agents est une architecture plus lisible et plus facile à maintenir. Une chaîne d'approvisionnement tracée et signée est une chaîne où le débogage est plus rapide. La confidentialité différentielle, en limitant la mémorisation, réduit à la fois le risque de fuite et le surapprentissage. Investir dans la sécurité, ce n'est pas ralentir la mise en production : c'est en renforcer la fiabilité.

Le passage à l'action ne demande pas de perfection immédiate. Il demande de savoir quels modèles sont en service, à quels vecteurs ils sont exposés, et quels garde-fous sont en place. Répondre à ces trois questions, c'est poser la première brique d'une IA de confiance. À partir de là, tout devient itératif : on cartographie, on mesure, on cloisonne, on surveille, on recommence. La sécurité des modèles d'IA, ainsi comprise, n'est pas un aboutissement figé mais un processus continu — et c'est précisément ce qui la rend praticable par chaque organisation, quelle que soit sa taille, en s'appuyant sur des référentiels qui, eux aussi, s'améliorent à chaque itération.

Sources

• OWASP GenAI Security — Top 10 for LLM Applications 2025 (LLM01 à LLM10)
• OWASP — Top 10 for LLM Applications 2025 (document PDF v2025)
• MITRE ATLAS — Adversarial Threat Landscape for Artificial-Intelligence Systems (tactiques, techniques, études de cas)
• NIST AI 100-2 E2025 — Adversarial Machine Learning : A Taxonomy and Terminology of Attacks and Mitigations (24 mars 2025)
• Goodfellow, Shlens & Szegedy (2014) — Explaining and Harnessing Adversarial Examples (FGSM)
• Madry et al. (2017) — Towards Deep Learning Models Resistant to Adversarial Attacks (PGD, entraînement adverse)
• Greshake et al. (2023) — Not What You've Signed Up For : Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection
• Zou et al. (2023) — Universal and Transferable Adversarial Attacks on Aligned Language Models (méthode GCG)
• Carlini et al. (2023) — Poisoning Web-Scale Training Datasets is Practical (split-view, frontrunning)
• Tramèr et al. (2016) — Stealing Machine Learning Models via Prediction APIs (extraction de modèle)
• Shokri et al. (2017) — Membership Inference Attacks Against Machine Learning Models
• ISO/IEC 42001:2023 — Système de management de l'intelligence artificielle (norme certifiable)