Pourquoi la cybersécurité classique ne protège pas les systèmes d'IA

Une entreprise sur deux ayant déployé un agent IA ou un modèle de langage le protège exactement comme un microservice ordinaire : avec un pare-feu, un scanner de dépendances et une politique d'accès. Cela semble raisonnable, mais en pratique, c'est comme installer une porte blindée dans une maison à laquelle il manque un mur. Boris Matsakov, ingénieur Data Science chez Cloud.ru, a formulé avec précision, dans son analyse publiée sur Habr, un problème que le secteur préfère encore ignorer : le DevSecOps classique et la sécurité de l'IA sont deux périmètres distincts, et l'un ne remplace pas l'autre.

Le cœur de la divergence est simple et pourtant fondamental. Le DevSecOps s'est construit pendant des décennies autour d'un modèle de menaces bien compris : il y a un périmètre, des dépendances, une infrastructure et des droits d'accès. Sécurisez chacune de ces couches et le système est protégé.

Mais les modèles d'IA sont attaqués de manière radicalement différente. La prompt injection permet à un attaquant de prendre le contrôle du comportement du modèle via un texte spécialement conçu. L'empoisonnement des données d'entraînement fausse la logique de décision elle-même bien avant que le modèle n'arrive en production.

La manipulation du contexte pousse un agent IA à exécuter des actions que ses concepteurs n'avaient pas prévues. Aucune de ces attaques ne touche l'infrastructure au sens traditionnel : elles frappent ce qui fait de l'IA une intelligence artificielle, c'est-à-dire les données et la capacité du modèle à les interpréter.

Le problème est particulièrement aigu avec les systèmes agentiques : des agents IA autonomes qui ne se contentent pas de générer du texte, mais prennent des décisions, appellent des API externes, travaillent avec des bases de données et exécutent des enchaînements d'actions. Si l'on peut comparer, grossièrement, un modèle de langage ordinaire à un consultant qui donne des conseils, un agent IA est un employé ayant accès aux systèmes de l'entreprise. Compromettre cet employé par prompt injection ne produit pas seulement une mauvaise réponse, mais un impact réel sur les processus métier.

Et ici, la protection de l'infrastructure est impuissante par définition : du point de vue du pare-feu, l'agent fait exactement ce qu'il est autorisé à faire, envoyer des requêtes et recevoir des réponses.

La bonne nouvelle, c'est que le secteur ne reste pas immobile. Au cours des dix-huit derniers mois, plusieurs cadres de référence sérieux ont vu le jour et permettent de bâtir un système de protection concret. L'OWASP a publié deux listes Top 10 de vulnérabilités distinctes, l'une pour les applications LLM et l'autre pour les systèmes agentiques.

Google a présenté SAIF, le Secure AI Framework, avec une cartographie des risques qui aide les entreprises à évaluer les menaces de façon systématique. MITRE a étendu sa célèbre base ATT&CK avec le projet ATLAS, qui répertorie les techniques d'attaque propres aux systèmes d'apprentissage automatique. Chacun de ces outils couvre sa propre niche : l'OWASP fournit une liste de contrôle de vulnérabilités concrètes, SAIF une méthodologie d'évaluation des risques, et ATLAS un langage pour décrire les attaques et construire des modèles de menaces.

La mauvaise nouvelle, c'est qu'il n'existe toujours pas de standard unique. Ni « GOST », ni norme ISO, ni cadre obligatoire prescrivant aux entreprises un ensemble précis de mesures. Chaque équipe interprète à sa façon ce qu'est un « système d'IA sécurisé », et cette interprétation se réduit souvent à ce que savent déjà faire les ingénieurs DevSecOps en poste. Cela crée une dangereuse illusion de protection : formellement, toutes les procédures sont respectées, les scanners sont au vert, les accès sont cloisonnés, mais le modèle reste vulnérable à des attaques que l'équipe de sécurité ne soupçonne peut-être même pas.

La conclusion pratique pour les entreprises est la suivante : la sécurité de l'IA doit être traitée comme un périmètre à part, qui se superpose au DevSecOps existant au lieu d'y être intégré. Cela suppose des compétences dédiées dans l'équipe, un jeu d'outils de test spécifique (red teaming des modèles, vérification de la prompt injection, audit des données d'entraînement) et un modèle de menaces propre, construit en tenant compte des particularités de l'apprentissage automatique. Les cadres OWASP, SAIF et ATLAS offrent une base suffisante pour ne pas réinventer la roue.

Le secteur de la sécurité de l'IA en est aujourd'hui à peu près là où en était la cybersécurité classique au début des années 2000 : les menaces sont réelles, les outils apparaissent, mais il n'existe pas encore de standards matures. Les entreprises qui commenceront dès maintenant à bâtir ce périmètre en tireront non seulement un avantage technique, mais aussi concurrentiel, car dans deux à trois ans, les régulateurs arriveront inévitablement avec des exigences, et il sera plus facile de s'adapter pour ceux qui y seront préparés.