L’intégration de l’intelligence artificielle dans les dispositifs de détection des cybermenaces est passée, en moins de trois ans, du statut de différenciateur marketing à celui de composante opérationnelle dans la majorité des SOC de taille intermédiaire et grande. Pourtant, entre les gains réels mesurés sur le terrain et les angles morts que les équipes sécurité découvrent à l’usage, l’écart reste significatif. Ce tour d’horizon technique s’adresse aux DSI et RSSI confrontés à des décisions d’architecture concrètes : quel rôle assigner aux modèles ML, quelles limites anticiper, et comment articuler ces choix avec le cadre réglementaire en vigueur.
De la signature à l’anomalie : pourquoi le ML s’est imposé dans le SOC
Les approches par signatures (règles statiques, hash de fichiers malveillants, listes de réputation IP) ont structuré la détection des menaces pendant deux décennies. Leur principale limite est structurelle : elles ne détectent que ce qui a déjà été vu. Face à la professionnalisation des groupes d’attaquants et à la généralisation des techniques dites de living-off-the-land (utilisation d’outils légitimes du système d’exploitation pour pivoter sans déposer de binaire malveillant), les taux de détection par signatures seules ont mécaniquement décliné.
L’apport central du machine learning est de déplacer le curseur de la détection par signature vers la détection par comportement. Un modèle entraîné sur des logs d’authentification, de mouvements réseau et d’accès aux ressources peut identifier un compte compromis non pas parce qu’il reconnaît un IOC (indicateur de compromission) connu, mais parce que la séquence d’actions s’écarte statistiquement du comportement historique de l’entité. C’est le principe de l’UEBA (User and Entity Behavior Analytics), désormais intégré nativement dans les plateformes XDR et les SIEM nouvelle génération.
Microsoft Sentinel, à titre d’exemple, construit des profils comportementaux dynamiques par utilisateur, hôte, adresse IP et application, et compare en continu l’activité courante à ces baselines pour détecter les mouvements latéraux, les escalades de privilèges et les compromissions de compte sans signature préalable. Ce type d’approche est particulièrement efficace sur les techniques de la matrice MITRE ATT&CK correspondant aux phases post-intrusion : persistence, credential access, lateral movement. Pour une analyse comparative des solutions du marché, voir le comparatif EDR/MDR/XDR pour RSSI.
L’état réel des faux positifs : chiffres et architecture de remédiation
Le problème des faux positifs dans les SIEM est documenté depuis longtemps. Les études du SANS Institute et de Gartner convergent sur un chiffre stable : 70 à 80 % des alertes SIEM classiques sont des faux positifs. En pratique, un analyste SOC traite entre 25 et 30 alertes par heure, dont seulement 5 à 8 méritent une investigation approfondie. La fatigue d’alertes qui en résulte est l’une des premières causes de non-détection : un analyste saturé trie plus vite, donc moins bien.
L’introduction de couches ML dans la chaîne de traitement réduit ce taux de manière significative. Les retours terrain de déploiements SIEM augmentés documentent une baisse du taux de faux positifs de 70 % vers 15 %, soit une division par près de cinq du bruit opérationnel. Cette réduction s’explique par la capacité du modèle à contextualiser chaque alerte (heure, entité, ressource accédée, séquence d’actions précédente) là où une règle statique ne peut pas.
Toutefois, l’usage croissant de LLM (Large Language Models) dans les interfaces SOC pour la corrélation et le résumé d’incidents introduit un nouveau risque : les hallucinations. Un LLM peut produire une analyse de triage plausible mais incorrecte, générant à son tour des faux positifs de second ordre lors de la prise de décision. La bonne pratique documentée est de cantonner le LLM au scoring et à la corrélation, et de soumettre uniquement les cas à haute confiance à un playbook SOAR déterministe pour l’action automatisée.
| Approche de détection | Couverture zero-day | Taux de faux positifs typique | Délai avant opérationnalité | Risque spécifique |
|---|---|---|---|---|
| Signatures/règles statiques | Faible | 70-80 % | Immédiat | Evasion par obfuscation |
| ML comportemental (UEBA) | Elevée | 15-20 % après tuning | 4-8 semaines | Empoisonnement de données |
| LLM pour triage/corrélation | Moyenne | Variable (hallucinations) | Selon fine-tuning | Faux positifs de second ordre |
| Ensemble hybride ML+SOAR | Elevée | Inférieur à 10 % en prod mature | 8-12 semaines | Complexité de maintenance |
MITRE ATLAS : la surface d’attaque spécifique aux systèmes IA
L’un des angles morts les plus sous-estimés dans les déploiements d’IA en sécurité est que le modèle ML lui-même devient une surface d’attaque. MITRE a développé le référentiel ATLAS (Adversarial Threat Landscape for AI Systems) précisément pour cartographier ces vecteurs. Dans sa version publiée fin 2025, ATLAS recense plusieurs dizaines de techniques spécifiques aux systèmes d’IA, couvrant des cas absents du référentiel ATT&CK classique.
Les quatre catégories d’attaques adversariales documentées par le NIST dans la publication AI 100-2e2023 (Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations) sont :
- Evasion : manipulation des entrées au moment de l’inférence pour faire classer une menace comme bénigne par le modèle.
- Poisoning : injection de données corrompues lors de la phase d’entraînement pour biaiser les prédictions.
- Privacy : extraction d’informations sensibles présentes dans les données d’entraînement via des requêtes ciblées.
- Abuse : utilisation du modèle lui-même comme outil offensif (génération de malware, automatisation de phishing).
L’ENISA dans son Threat Landscape 2025 signale l’émergence d’un vecteur spécifique : les modèles ML hébergés empoisonnés et les packages PyPI malveillants contenant des backdoors ciblant les pipelines de développement IA. Ce risque de type supply chain est directement pertinent pour toute organisation qui réentraîne ses modèles sur des flux de données tiers non contrôlés.
L’ANSSI aborde ces risques dans ses recommandations sur l’intelligence artificielle, en soulignant que les risques propres à l’IA (injection de prompt, fuite de données par le contexte, hallucinations) nécessitent une approche de sécurité distincte de la cybersécurité classique. L’agence recommande notamment une analyse de risque EBIOS-RM avant toute phase d’entraînement et préconise de traiter les modèles comme des actifs sensibles au même titre que les données qui les composent.
Limites opérationnelles des modèles ML en détection
Au-delà des vecteurs d’attaque spécifiques, plusieurs limites structurelles des modèles ML doivent être anticipées par les équipes de sécurité.
La dépendance aux données d’entraînement. Un modèle supervisé apprend à partir d’exemples labellisés. Si l’historique de sécurité disponible est biaisé (faible représentation de certaines techniques d’attaque, organisation ayant subi peu d’incidents documentés), le modèle aura une couverture de détection asymétrique. Les techniques APT avancées, peu représentées dans les datasets publics, sont systématiquement sous-détectées par les modèles génériques.
Le délai de baseling comportemental. Un modèle UEBA nécessite généralement 4 à 8 semaines de données opérationnelles propres pour établir des baselines fiables par entité. Pendant cette période, les taux de faux positifs restent élevés. Cette contrainte est souvent sous-estimée dans les projets de déploiement, où les équipes s’attendent à une opérationnalité immédiate.
La dérive de modèle. Le comportement des utilisateurs et des systèmes évolue (migrations applicatives, changements organisationnels, télétravail généralisé). Un modèle non réentraîné régulièrement voit ses baselines se décaler, générant une augmentation progressive des faux positifs. La gouvernance du cycle de vie des modèles (versioning, tests de régression, seuils de dérive) est un prérequis opérationnel souvent absent des premières intégrations.
L’explicabilité limitée. Les modèles à haute performance (gradient boosting, réseaux de neurones profonds) sont intrinsèquement des boîtes noires. Lorsqu’une alerte ML déclenche une investigation ou une action de réponse, l’analyste doit pouvoir comprendre le raisonnement du modèle. L’absence d’explicabilité (XAI insuffisant) ralentit le triage et peut générer une résistance des équipes. Pour les déploiements en infrastructure critique, cette limite a également une dimension réglementaire directe au titre de l’EU AI Act.
IA défensive vs IA offensive : un rapport de force asymétrique
L’ENISA Threat Landscape 2025 chiffre à plus de 80 % la part des campagnes d’ingénierie sociale assistées par IA début 2025. Les attaquants utilisent les LLM pour personnaliser les messages de phishing à grande échelle, générer du code malveillant et automatiser la reconnaissance. L’asymétrie fondamentale est que l’attaquant peut utiliser l’IA sans contrainte de robustesse ni d’auditabilité, là où le défenseur doit intégrer ces exigences dans son modèle opérationnel.
L’ENISA cite l’exemple de systèmes d’IA offensifs dédiés, dont Xanthorox AI, conçu pour automatiser l’ingénierie sociale et le développement de malware, comme marqueur d’un seuil qualitatif dans la professionnalisation des acteurs de la menace. Face à cette asymétrie, la valeur des modèles ML défensifs réside moins dans la course aux performances brutes que dans la réduction du temps de détection (MTTD) et du temps de réponse (MTTR). Ces deux métriques sont directement exploitables dans les obligations de notification d’incidents NIS2 (24 h pour l’alerte précoce, 72 h pour la notification détaillée) et DORA (4 h pour les incidents majeurs dans le secteur financier).
Les retours d’expérience de SOC ayant intégré des couches ML confirment que les gains opérationnels les plus tangibles se concentrent sur la réduction du temps de triage et la priorisation des incidents, et non sur l’élimination de l’analyste humain. Consulter le pôle IA tech pour les analyses sur l’usage de l’IA générative en entreprise.
Encadrement réglementaire : AI Act, NIS2 et DORA
Le déploiement d’IA en contexte de sécurité n’échappe pas au cadre réglementaire européen de 2025-2026. Trois textes ont des implications directes pour les RSSI.
L’EU AI Act (Règlement (UE) 2024/1689) classe certains systèmes d’IA utilisés dans la gestion d’infrastructures critiques parmi les systèmes à haut risque (Annexe III). Les obligations pour les fournisseurs et les déployeurs incluent : tenue d’un registre de conformité, évaluation continue de la robustesse et de l’exactitude du modèle, mesures techniques contre les risques de cybersécurité spécifiques à l’IA, et supervision humaine effective. Les sanctions en cas de non-conformité pour les obligations relatives aux systèmes à haut risque peuvent atteindre 15 millions d’euros ou 3 % du chiffre d’affaires mondial (jusqu’à 35 millions d’euros ou 7 % pour les violations les plus graves, notamment les pratiques interdites). L’échéance d’application pour les systèmes à haut risque (Annexe III) est fixée au 2 août 2026, les obligations relatives aux modèles d’IA à usage général étant applicables depuis août 2025.
NIS2 impose aux entités essentielles et importantes des mesures de gestion du risque incluant la détection des incidents et la notification sous délai. L’utilisation de modèles ML pour la détection automatisée n’exonère pas de ces obligations, elle les conditionne : la qualité et la robustesse du système de détection deviennent des éléments d’audit.
DORA, applicable dans le secteur financier depuis janvier 2025, impose une notification d’incident majeur sous 4 heures et des tests de résilience opérationnelle incluant les systèmes tiers, ce qui englobe les solutions de détection IA fournies par des prestataires. La cartographie des dépendances aux modèles ML tiers est donc une obligation de conformité, pas seulement une bonne pratique.
L’ANSSI articule dans ses recommandations sur l’IA les exigences de l’AI Act avec la méthode EBIOS-RM et les obligations NIS2, fournissant un cadre d’analyse cohérent pour les RSSI qui doivent à la fois optimiser leurs capacités de détection et justifier leurs choix techniques devant des auditeurs réglementaires.