Pourquoi la cybersécurité traditionnelle ne protège pas les systèmes d’AI

Chaque deuxième entreprise qui a déployé un agent d'IA ou un modèle de langage le protège exactement comme un microservice ordinaire — avec un firewall, un scanner de dépendances et des politiques d'accès. Cela semble raisonnable, mais en pratique, c'est comme mettre une porte en métal dans une maison à laquelle il manque un mur entier. Boris Matsakov, ingénieur Data Science chez Cloud.ru, a formulé précisément le problème que l'industrie préfère jusqu'à présent ne pas remarquer dans son analyse sur Habr : la cybersécurité classique et la sécurité de l'IA sont deux circuits différents, et l'un ne remplace pas l'autre.

La divergence est simple et pourtant fondamentale. La cybersécurité classique s'est construite au cours des décennies autour d'un modèle de menace compréhensible : il existe un périmètre, il existe des dépendances, il existe une infrastructure et des droits d'accès. Protégez chacune de ces couches — et le système est sécurisé.

Mais les modèles d'IA sont attaqués de manières complètement différentes. L'injection de prompts permet à un attaquant de détourner le comportement du modèle via un texte spécialement construit. L'empoisonnement des données d'entraînement déforme la logique même de la prise de décision bien avant que le modèle ne se retrouve en production.

La manipulation de contexte force un agent d'IA à effectuer des actions que ses créateurs n'avaient pas anticipées. Aucune de ces attaques ne touche l'infrastructure au sens traditionnel — elles frappent ce qui fait que l'IA est de l'intelligence artificielle : les données et la capacité du modèle à les interpréter.

Le problème est particulièrement aigu avec les systèmes agentic — des agents d'IA autonomes qui ne font pas que générer du texte, mais prennent des décisions, appellent des APIs externes, travaillent avec des bases de données et exécutent des chaînes d'actions. Si un modèle de langage ordinaire peut être grossièrement comparé à un consultant qui donne des conseils, alors un agent d'IA est un employé avec accès aux systèmes d'entreprise. Compromettre un tel employé via une injection de prompts signifie non seulement obtenir une mauvaise réponse, mais un véritable impact sur les processus métier.

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

La bonne nouvelle est que l'industrie ne stagne pas. Au cours des dix-huit derniers mois, plusieurs documents-cadres sérieux ont été développés qui permettent de construire un système de défense pratique. L'OWASP a publié deux listes séparées des Top 10 des vulnérabilités — pour les applications LLM et pour les systèmes agentic.

Google a présenté SAIF — le Secure AI Framework avec une carte des risques qui aide les entreprises à évaluer systématiquement les menaces. MITRE a étendu sa base de données légendaire ATT&CK au projet ATLAS, cataloguant les techniques d'attaque spécifiques aux systèmes d'apprentissage automatique. Chacun de ces outils comble sa propre niche : l'OWASP fournit une liste de contrôle des vulnérabilités spécifiques, SAIF fournit une méthodologie d'évaluation des risques, ATLAS fournit un langage pour décrire les attaques et construire des modèles de menace.

La mauvaise nouvelle est qu'une norme unifiée n'existe toujours pas. Il n'existe ni un « GOST » ni une ISO, ni un cadre obligatoire qui prescrirait aux entreprises un ensemble spécifique de mesures. Chaque équipe interprète à sa manière ce qu'est un « système d'IA sécurisé », et souvent cette interprétation se réduit à ce que les ingénieurs DevSecOps internes savent déjà faire. Cela crée une illusion dangereuse de protection : formellement, toutes les procédures sont respectées, les scanners sont au vert, l'accès est contrôlé — mais le modèle est entre-temps vulnérable à des attaques que l'équipe de sécurité peut ne pas même soupçonner.

La conclusion pratique pour l'entreprise ressemble à ceci : la sécurité de l'IA doit être considérée comme un circuit séparé qui se superpose à la cybersécurité classique existante plutôt que d'y être intégrée. Cela signifie des compétences séparées dans l'équipe, un ensemble séparé d'outils pour les tests — red teaming des modèles, vérification de l'injection de prompts, audit des données d'entraînement — et un modèle de menace séparé construit en tenant compte des spécificités de l'apprentissage automatique. Les cadres OWASP, SAIF et ATLAS fournissent une base suffisante pour que vous n'ayez pas besoin de réinventer la roue.

L'industrie de la sécurité de l'IA est actuellement approximativement au même stade où la cybersécurité classique se trouvait au début des années 2000 : les menaces sont réelles, les outils émergent, mais les normes matures n'existent pas encore. Les entreprises qui commenceront à construire ce circuit maintenant obtiendront non seulement un avantage technique mais aussi un avantage concurrentiel — car dans deux ou trois ans, les régulateurs viendront inévitablement avec des exigences, et il sera plus facile de s'adapter pour ceux qui y sont préparés.