Surface d'attaque des systèmes IA

Pourquoi cartographier la surface d'attaque

Sécuriser un système d'IAintelligence artificielleIAEnsemble des techniques permettant à un programme d'accomplir une tâche qui demanderait de l'intelligence humaine. Le terme couvre aussi bien les systèmes à règles écrites que ceux qui apprennent de données.Voir dans le glossaire ne commence pas par des outilstool callingIACapacité d'un agent ou d'un LLM à invoquer des outils externes (API, calcul, recherche) pendant le raisonnement.Voir dans le glossaire, mais par une carte. Sans elle, les efforts se concentrent presque toujours sur ce qui est visible — l'API exposée au public — en laissant de côté ce qui ne l'est pas : le pipeline d'entraînement, les jeux de donnéesdonnéesIAEnsemble d'informations structurées ou non utilisées pour entraîner, évaluer ou alimenter un modèle. La qualité, la quantité et la représentativité des données sont les facteurs décisifs pour les performances en apprentissage automatique.Voir dans le glossaire tiers, les journaux de conversation, les plugins connectés à un agentagentIASystème qui enchaîne des appels d'outils de façon autonome pour atteindre un objectif : il planifie, agit, observe, recommence. Sa fiabilité décroît exponentiellement avec le nombre d'étapes.Voir dans le glossaire. Un audit qui ne couvre que le point d'entrée le plus évident produit un faux sentiment de sécurité.

Ce chapitre pose la grille de lecture utilisée dans tout le reste de la formation : le cycle de vie du système comme axe de découpageChunkingIADécoupage d'un document en segments de taille fixe ou sémantique avant indexation vectorielle, pour optimiser la récupération RAG.Voir dans le glossaire, et les acteurs comme second axe. Croiser les deux permet de répondre à la question qui structure un plan de sécurité : à cette étape précise, face à quel type d'attaquant, quel contrôle est réellement pertinent ?

Un système d'IA n'a pas une surface d'attaque, il en a plusieurs, empilées : celle du logiciel classique qui l'héberge (serveur, API, authentification), celle spécifique aux modèles d'apprentissage automatiqueapprentissage automatiqueIABranche de l'IA où le programme dégage lui-même ses règles à partir d'exemples, au lieu de les recevoir d'un développeur. C'est ce déplacement des règles écrites vers les régularités apprises qui définit l'IA moderne.Voir dans le glossaire (données, poids, inférenceinférenceIAUtilisation d'un modèle déjà entraîné sur une donnée nouvelle. Peu coûteuse à l'unité mais répétée à chaque requête, elle constitue le coût récurrent d'exploitation.Voir dans le glossaire), et celle propre aux usages génératifs (promptpromptIAConsigne ou contexte fourni à un modèle de langage pour orienter sa réponse. La qualité du prompt conditionne souvent la qualité du résultat.Voir dans le glossaire, sorties, agents). Ignorer l'une des trois laisse un angle mort structurel.

Le cycle de vie d'un système d'IA et ses points d'exposition

Les données

Tout commence par les données de collecte et d'étiquetageétiquetageIATravail consistant à associer à chaque exemple la réponse attendue. C'est presque toujours le poste le plus coûteux d'un projet d'apprentissage supervisé.Voir dans le glossaire. C'est l'étape la plus sous-estimée, car elle se déroule loin en amont du produit final, souvent chez des sous-traitants ou via des jeux de données publics agrégés sans contrôle de provenance.

Les risques concrets :

• Empoisonnement (data poisoningempoisonnementCybersécuritéIntroduction délibérée d'exemples corrompus dans un jeu d'entraînement, afin d'altérer durablement le comportement du modèle.Voir dans le glossaire) — injection de contenus falsifiés dans un corpus d'entraînement ou de fine-tuningFine-tuningIAAjustement des poids d'un modèle pré-entraîné sur un jeu de données spécifique pour adapter son comportement à un domaine ou une tâche cible.Voir dans le glossaire pour biaiser le comportement du modèle sur des déclencheurs précis (une marque, un nom, une requête type).
• Contamination par des sources publiques — un modèle entraîné ou affiné sur du contenu web peut absorber du texte spécifiquement rédigé pour l'influencer, technique connue sous le nom d'indirect prompt injectionInjection de promptCybersécuritéAttaque visant à détourner un LLM en insérant des instructions malveillantes dans le contexte (entrée utilisateur, document RAG, etc.).Voir dans le glossaire lorsqu'elle vise l'inférence plutôt que l'entraînement.
• Fuite via l'étiquetage humain — des annotateurs externes manipulant des données sensibles sans cloisonnement contractuel ni technique.

Des chercheurs ont démontré qu'il suffisait de contrôler une fraction infime — parfois moins de 0,1 % — d'un corpus d'entraînement pour installer une porte dérobée comportementale (backdoor) déclenchée par un motif spécifique, sans dégrader les performances générales du modèle de façon mesurable. La discrétion de l'attaque est ce qui la rend dangereuse : les métriques globales ne bougent pas.

L'entraînement et le pipeline MLOps

Le pipeline d'entraînement est un système logiciel comme un autre, avec ses dépendances, ses secrets d'accès, ses environnements de calcul partagés. Il hérite donc de toute la surface d'attaque d'une chaîne CI/CD classique, à laquelle s'ajoutent des risques propres au ML :

• Dépendances de librairies (frameworks ML, formats de sérialisation comme pickle) compromises en amont — attaque de la chaîne d'approvisionnement logicielle.
• Accès insuffisamment cloisonné aux clusters de calcul, permettant à un acteur d'altérer les hyperparamètreshyperparamètreIARéglage choisi avant l'entraînement — vitesse d'apprentissage, taille du modèle, nombre d'itérations. Il se distingue des paramètres, ajustés automatiquement pendant l'entraînement.Voir dans le glossaire ou d'exfiltrer des poids intermédiaires.
• Journalisation excessive des runs d'entraînement, exposant des données sensibles dans des outils de suivi d'expériences (tracking) mal configurés.

Le modèle : poids et architecture

Une fois entraîné, le modèle lui-même devient un actif à protéger, au même titre qu'un code source propriétaire — avec une différence notable : il peut être reconstitué par observation de ses réponses, sans jamais y avoir eu accès directement.

• Vol de modèle (model extraction) — un attaquant interroge massivement une API pour reconstruire un modèle de substitution qui imite le comportement de l'original, contournant ainsi le coût d'entraînement.
• Inférence d'appartenance (membership inference) — déterminer si une donnée précise a fait partie du jeu d'entraînement, ce qui pose un problème de confidentialité direct si les données concernent des personnes.
• Inversion de modèle — reconstruction partielle de données d'entraînement à partir des sorties du modèle, particulièrement critique pour les modèles entraînés sur des données médicales ou biométriques.

L'opacité perçue d'un modèle n'est pas une protection. Les techniques d'extraction et d'inversion démontrent qu'un accès en interrogation répétée (même à travers une API contrôlée) peut suffire à reconstituer des informations que l'on croyait protégées par la seule complexité du modèle. La sécurité par l'obscurité ne s'applique pas ici.

Le déploiement : API, agents, plugins

C'est l'étape la plus visible, et donc la plus documentée dans la littérature de sécurité — c'est ici qu'apparaissent les vecteurs devenus emblématiques des systèmes IA génératifs :

• Injection de prompt directe — un utilisateur formule une requête destinée à contourner les instructions système du modèle.
• Injection de prompt indirecte — les instructions malveillantes ne viennent pas de l'utilisateur mais d'un contenu tiers que le modèle consulte (page web, document, e-mail) dans le cadre d'une tâche légitime.
• Agence excessive (excessive agency) — un agent connecté à des outils (envoi d'e-mail, exécution de code, accès à une base de données) exécute une action dommageable parce que ses permissions dépassent ce que la tâche exige réellement.
• Fuite de donnéesfuite de donnéesIAErreur consistant à laisser entrer dans l'entraînement une information qui n'existera pas au moment réel de la prédiction. Le modèle affiche des scores excellents puis s'effondre en production.Voir dans le glossaire via les sorties — le modèle restitue, en clair, des informations sensibles présentes dans son contextefenêtre de contexteIAQuantité de texte qu'un modèle peut prendre en compte simultanément : question, documents fournis et historique. Au-delà, les éléments les plus anciens sortent du champ.Voir dans le glossaire (invite système, historique de conversation, documents chargés).

L'exploitation en production : supervision et boucle de rétroaction

Un système en production continue d'apprendre de son usage, directement (fine-tuningaffinageIAPoursuite de l'entraînement d'un modèle existant sur des données propres à un usage. Il enseigne une manière de répondre, non des connaissances fiables — d'où la préférence pour le RAG en entreprise.Voir dans le glossaire continu, RLHF) ou indirectement (le comportement des utilisateurs influence les futures versions via les retours collectés). Cette boucle de rétroaction est elle-même un vecteur :

• Manipulation coordonnée des signaux de retour utilisateur pour orienter les futures mises à jour du modèle.
• DérivedériveIADégradation progressive des performances d'un modèle après son déploiement, causée par l'évolution des comportements ou du contexte. Elle impose surveillance et réentraînement.Voir dans le glossaire de performance non détectée faute de supervision continue (« model drift »), qui n'est pas une attaque au sens strict mais qui masque des anomalies exploitables.
• Absence de traçabilité des décisions du modèle, qui empêche de distinguer une attaque réussie d'un dysfonctionnement ordinaire lors d'un incident.

Les acteurs de la menace

Cartographier les étapes ne suffit pas : un même point d'exposition n'appelle pas la même réponse selon qui cherche à l'exploiter. Six profils reviennent systématiquement dans les analyses de risque IA.

Les analyses de risque en entreprise se concentrent souvent sur les menaces externes, alors que l'accès légitime d'un data scientist, d'un prestataire d'étiquetage ou d'un administrateur de pipeline constitue historiquement l'un des vecteurs les plus efficaces — parce qu'il contourne d'emblée les contrôles périmétriques.

S'appuyer sur des référentiels reconnus

Deux cadres structurent aujourd'hui la plupart des audits de sécurité IA et permettent d'éviter de réinventer une taxonomie ad hoc :

• OWASP LLMLLMIAGrand modèle de langage (Large Language Model) entraîné sur d'énormes corpus pour prédire et générer du texte.Voir dans le glossaire Top 10 — référentiel centré sur les applications utilisant des grands modèles de langagegrand modèle de langageIAModèle entraîné à prédire le token suivant d'une séquence de texte. Toutes ses capacités apparentes — résumer, traduire, coder — découlent de cette unique tâche.Voir dans le glossaire (injection de prompt, fuite de données sensibles, agence excessive, dépendance excessive, empoisonnement des données, entre autres).
• MITRE ATLAS — matrice de tactiques et techniques adaptée du modèle ATT&CK au machine learning, couvrant l'ensemble du cycle de vie, de la reconnaissance à l'impact, avec des cas réels documentés.

Ces référentiels ne remplacent pas une cartographie propre au système audité, mais ils offrent un vocabulaire commun et une check-list de non-régression pour vérifier qu'aucune catégorie majeure n'a été oubliée.

Avant tout audit, construisez un tableau à deux colonnes : chaque composant du système (source de données, pipeline, endpoint API, agent, outil connecté) d'un côté, et pour chacun la liste des acteurs plausibles avec leur niveau d'accès actuel. Ce tableau, même sommaire, révèle presque toujours au moins un point d'exposition qui n'avait pas de propriétaire identifié.

Étude de cas simplifiée : un assistant interne connecté à des outils

Prenons un assistant d'entreprise capable de lire des e-mails, de consulter une base de connaissances interne et de rédiger des réponses. La cartographie révèle plusieurs points d'exposition qui n'apparaissent pas si l'on se limite à l'API :

1. Données — la base de connaissances contient des documents confidentiels indexés sans distinction de niveau d'habilitation.
2. Déploiement — un e-mail reçu peut contenir des instructions cachées (texte blanc sur fond blanc, balises invisibles) interprétées par le modèle comme des instructions légitimes : c'est une injection de prompt indirecte classique.
3. Agence excessive — si l'assistant a la permission d'envoyer des e-mails de façon autonome, une injection réussie peut se transformerTransformerIAArchitecture introduite en 2017, fondée sur le mécanisme d'attention, qui traite une séquence entière en parallèle. Elle sert de base à tous les grands modèles de langage actuels.Voir dans le glossaire en exfiltration de données vers une adresse externe, sans qu'aucun humain ne valide l'action.
4. Exploitation — sans journalisation détaillée des actions de l'agent, l'incident n'est détecté qu'après coup, par un tiers externe.

Ce scénario illustre pourquoi la cartographie doit précéder le choix des contrôles techniques : un pare-feupare-feuRéseauxÉquipement ou logiciel qui filtre le trafic selon des règles (ports, adresses, états) pour réduire la surface d'attaque.Voir dans le glossaire applicatif classique ne détecte aucune des trois premières étapes de la chaîne.

Checklist de cartographie initiale

Avant de passer aux chapitres suivants, qui détaillent chaque vecteur, voici la check-list minimale à appliquer sur tout système réel :

• Lister toutes les sources de données (internes, tierces, générées par des utilisateurs) et leur niveau de confiance
• Identifier tous les composants du pipeline d'entraînement ou de fine-tuning et leurs droits d'accès
• Vérifier si le modèle est exposé en interrogation libre (risque d'extraction) ou limité (rate limiting, quotas)
• Recenser tous les outils et permissions accordés à un agent connecté (agence)
• Identifier les sources de contenu tiers consultées automatiquement par le système (risque d'injection indirecte)
• Vérifier l'existence d'une journalisation exploitable pour la détection d'incident
• Associer chaque composant à une liste d'acteurs plausibles et à leur niveau d'accès actuel

Ce qu'il faut retenir

La surface d'attaque d'un système d'IA ne se limite jamais au point d'entrée le plus visible. Elle s'étend sur cinq étapes du cycle de vie — données, entraînement, modèle, déploiement, exploitation — et croise six profils d'acteurs aux motivations et ressources distinctes. Les référentiels OWASP LLM Top 10 et MITRE ATLAS fournissent un vocabulaire commun pour structurer cette cartographie sans repartir de zéro. Les chapitres suivants reprennent chacun de ces vecteurs en détail, en commençant par l'empoisonnement des données et les attaques sur le pipeline d'entraînement.