Beaucoup de RSSI commettent l’erreur de traiter la sécurité des systèmes d’IA comme une simple extension de leur politique de cybersécurité classique. On applique les mêmes contrôles réseau, les mêmes règles de gestion des accès, et on espère que ça suffira. C’est une illusion dangereuse. Les modèles d’intelligence artificielle — qu’il s’agisse de LLM déployés en production, de systèmes de recommandation ou de pipelines de machine learning — exposent des surfaces d’attaque radicalement nouvelles que les outils traditionnels ne savent tout simplement pas adresser. En France, plusieurs incidents documentés dans le secteur bancaire et dans la santé numérique ont mis en lumière cette lacune stratégique. Il est temps d’en dresser l’inventaire complet.
Pourquoi les systèmes d’IA constituent une surface d’attaque distincte
Un système d’IA n’est pas un logiciel ordinaire. Il est le produit d’un entraînement sur des données, d’une architecture de modèle, d’une chaîne d’inférence et d’un écosystème d’intégration. Chacune de ces couches introduit des vulnérabilités qui n’ont pas d’équivalent dans le développement applicatif classique. L’OWASP a d’ailleurs publié un Top 10 dédié aux LLM, reconnaissant officiellement que ces systèmes méritent leur propre taxonomie de risques. De leur côté, le NIST et l’ANSSI ont commencé à formaliser des cadres d’évaluation spécifiques à la robustesse des modèles d’IA. Pour un RSSI, ignorer cette cartographie distincte, c’est naviguer à vue dans un terrain miné.
Les attaques sur les systèmes d’IA exploitent trois propriétés fondamentales de ces modèles : leur dépendance aux données d’entraînement, leur opacité (le fameux problème de la boîte noire) et leur surface d’exposition via les APIs ou interfaces utilisateur. C’est à l’intersection de ces trois dimensions que se nichent les vecteurs les plus critiques.
Les 8 vecteurs d’attaque spécifiques aux systèmes d’IA
1. L’injection de prompt (Prompt Injection)
C’est aujourd’hui le vecteur le plus documenté et le plus activement exploité. Un attaquant insère des instructions malveillantes dans l’entrée utilisateur pour détourner le comportement du modèle. En contexte B2B français, imaginez un chatbot de service client alimenté par un LLM : une instruction cachée dans un formulaire peut amener le modèle à divulguer des données internes, à contourner des filtres de contenu ou à exfiltrer des informations sensibles. La variante dite indirect prompt injection — où l’instruction malveillante est injectée via une source externe consultée par le modèle (un email, une page web) — est particulièrement sournoise car invisible à l’utilisateur légitime.
Recommandation actionnable : Imposer une validation stricte des entrées, segmenter les niveaux de confiance entre instructions système et entrées utilisateur, et journaliser l’intégralité des prompts en production pour détecter les patterns anormaux.
2. L’empoisonnement des données d’entraînement (Data Poisoning)
Si un attaquant parvient à corrompre le jeu de données utilisé pour entraîner ou affiner un modèle, il peut introduire des biais délibérés ou des comportements dormants. Ce vecteur est particulièrement pertinent pour les entreprises qui entraînent leurs propres modèles sur des données collectées depuis des sources tierces — flux RSS, bases de données partenaires, scraping web. Une startup française dans le domaine de la veille concurrentielle nous a rapporté avoir détecté, lors d’un audit, des exemples d’entraînement manifestement altérés provenant d’une API partenaire compromise.
Recommandation actionnable : Appliquer des contrôles d’intégrité sur les datasets (checksums, signatures cryptographiques), tracer la provenance de chaque source de données et prévoir des audits statistiques réguliers des distributions de labels.
3. L’attaque adversariale (Adversarial Examples)
Des perturbations imperceptibles à l’œil humain — quelques pixels modifiés dans une image, un mot remplacé dans un texte — peuvent tromper un modèle d’IA avec une efficacité redoutable. Ce vecteur touche principalement les systèmes de vision par ordinateur (reconnaissance faciale, contrôle qualité industriel, systèmes de surveillance) et les modèles NLP. Dans un contexte de contrôle aux frontières ou de détection de fraude documentaire, les implications sécuritaires sont considérables.
4. L’extraction de modèle (Model Stealing)
En soumettant un grand nombre de requêtes à un modèle exposé via une API, un attaquant peut reconstituer une approximation fonctionnelle du modèle propriétaire. Pour une entreprise ayant investi plusieurs millions d’euros dans l’entraînement d’un modèle métier, c’est une menace directe sur la propriété intellectuelle. Ce vecteur est souvent sous-estimé car il ne déclenche aucune alerte de sécurité classique — techniquement, les requêtes sont légitimes.
Recommandation actionnable : Implémenter des mécanismes de rate limiting différenciés par client, monitorer les volumes de requêtes inhabituels et envisager des techniques de watermarking de modèle pour prouver la paternité en cas de litige. Pour approfondir les enjeux de sécurité autour des infrastructures exposées, notre analyse des nouveaux vecteurs d’attaque sur les infrastructures cloud apporte un éclairage complémentaire essentiel.
5. L’inférence d’appartenance (Membership Inference Attack)
Cette attaque permet de déterminer si un enregistrement spécifique faisait partie du jeu d’entraînement d’un modèle. En contexte médical ou RH, cela signifie qu’un attaquant peut potentiellement confirmer la présence d’un individu dans une base de données sensible. C’est une atteinte directe au RGPD et une exposition légale non négligeable pour les organisations françaises soumises au contrôle de la CNIL.
6. La fuite de données mémorisées (Training Data Extraction)
Les LLM peuvent mémoriser et restituer, sous certaines conditions de prompt, des fragments de leurs données d’entraînement — y compris des informations personnelles, des secrets d’entreprise ou des données confidentielles. Des chercheurs de Google DeepMind ont démontré qu’il est possible d’extraire des données verbatim de modèles commerciaux. Pour toute organisation envisageant d’affiner un LLM sur ses données internes, ce risque doit faire l’objet d’une analyse d’impact spécifique.
7. Le détournement de pipeline MLOps (Supply Chain Attack sur l’IA)
La chaîne d’approvisionnement d’un système d’IA comprend des bibliothèques open source (PyTorch, Hugging Face Transformers), des modèles pré-entraînés téléchargés depuis des hubs publics, et des orchestrateurs comme MLflow ou Kubeflow. Chacun de ces composants est une cible potentielle. Un modèle pré-entraîné malveillant déposé sur Hugging Face peut embarquer une backdoor activable à la demande. Ce risque de chaîne logistique logicielle est analogue à l’incident SolarWinds, mais appliqué à l’écosystème IA. Notre dossier sur le bilan des incidents cybersécurité majeurs illustre à quel point ces attaques de supply chain peuvent avoir des conséquences systémiques.
Recommandation actionnable : Vérifier systématiquement les signatures et checksums des modèles téléchargés, privilégier des registres internes d’artefacts ML vérifiés, et intégrer des scans de sécurité spécifiques aux modèles dans votre pipeline CI/CD.
8. Le jailbreaking et le contournement des garde-fous
Les LLM déployés en production sont généralement dotés de filtres de sécurité pour empêcher la génération de contenu nuisible. Les techniques de jailbreaking visent à contourner ces garde-fous via des formulations détournées, des jeux de rôle ou des instructions en plusieurs étapes. Au-delà du risque réputationnel, un LLM jailbreaké déployé dans un contexte professionnel peut devenir un vecteur de désinformation interne, de génération de code malveillant ou d’exfiltration d’informations confidentielles.
Construire une posture de sécurité IA cohérente
Face à ces huit vecteurs, la réponse ne peut pas être ad hoc. Elle doit s’inscrire dans une démarche structurée que certains appellent déjà le AI Security Framework. Concrètement, cela implique d’intégrer la sécurité des systèmes IA dès la phase de conception (principe de security by design appliqué au ML), de réaliser des red team exercises spécifiques aux modèles déployés, et de maintenir une cartographie dynamique des assets IA — souvent inexistante dans les CMDB actuelles des entreprises françaises.
Il est également crucial de distinguer les risques selon le mode de déploiement : un modèle hébergé on-premise n’expose pas les mêmes vecteurs qu’un modèle consommé via une API SaaS ou qu’un système d’IA déployé en edge, où les contraintes physiques d’accès ajoutent une couche de complexité supplémentaire. La segmentation des risques par architecture de déploiement doit devenir un réflexe dans toute politique de sécurité IA.
Enfin, la formation des équipes reste le maillon faible. Selon une étude Wavestone publiée sur le marché français, moins de 15% des équipes sécurité ont reçu une formation spécifique aux risques liés à l’IA. Un RSSI qui ne peut pas expliquer la différence entre une attaque adversariale et un prompt injection à son COMEX est un RSSI en retard sur son métier.
Le point de vue de l’expert : ne pas attendre la première compromission
La tentation est grande de traiter la sécurité des systèmes d’IA comme un sujet futuriste, à adresser quand les menaces seront mieux documentées. C’est exactement l’erreur qui a été commise avec la sécurité des APIs au début des années 2010 — et on en paie encore le prix aujourd’hui. Les attaques sur les systèmes d’IA sont réelles, actives, et leur sophistication croît plus vite que la maturité des défenses disponibles. Mon conseil est catégorique : chaque RSSI doit, dès maintenant, cartographier ses assets IA en production, évaluer leur exposition à ces huit vecteurs, et intégrer un volet AI Security explicite dans son plan de traitement des risques. Ne pas le faire, c’est choisir délibérément l’ignorance face à une surface d’attaque qui ne cessera de s’élargir.
Quelle est la différence entre une attaque adversariale et une injection de prompt ?
Une attaque adversariale consiste à modifier subtilement les données d’entrée d’un modèle — pixels d’une image, tokens d’un texte — pour provoquer une erreur de classification, sans que cette modification soit perceptible par un humain. L’injection de prompt, en revanche, est spécifique aux LLM : elle consiste à insérer des instructions en langage naturel dans le contexte du modèle pour détourner son comportement prévu. Les deux vecteurs exploitent les failles intrinsèques des modèles, mais à des niveaux d’abstraction différents.
Comment un RSSI peut-il prioriser ces vecteurs d’attaque IA selon le contexte de son organisation ?
La priorisation doit s’appuyer sur deux critères : l’architecture de déploiement des systèmes IA (cloud public, on-premise, edge) et la sensibilité des données traitées. Une organisation exposant un LLM via une API publique doit prioriser l’injection de prompt et l’extraction de modèle. Une organisation entraînant ses propres modèles sur des données personnelles doit traiter en priorité l’empoisonnement des données et les attaques d’inférence d’appartenance. Une matrice de risques croisée avec le référentiel MITRE ATLAS — l’équivalent de MITRE ATT&CK pour les systèmes IA — constitue un point de départ efficace.
Existe-t-il des obligations réglementaires françaises ou européennes spécifiques à la sécurité des systèmes d’IA ?
L’AI Act européen introduit des exigences de robustesse et de cybersécurité explicites pour les systèmes d’IA à haut risque — définis par leur domaine d’application (santé, infrastructures critiques, RH, contrôle des frontières). Ces systèmes doivent être conçus pour résister aux tentatives de manipulation et faire l’objet d’une documentation technique détaillée incluant les mesures de sécurité. En parallèle, la directive NIS2 — transposée en droit français — intègre désormais les risques liés aux systèmes d’IA dans le périmètre des obligations de gestion des risques pour les entités essentielles et importantes. Les RSSI des secteurs concernés doivent anticiper ces exigences dans leur gouvernance IA.