Depuis trois ans, aucune solution de sécurité n’est vendue sans mention d’intelligence artificielle. La difficulté, pour un décideur, est de distinguer ce qui relève d’un progrès réel de ce qui relève de l’habillage marketing d’une fonction statistique qui existe depuis vingt ans.
Voici ce que la détection par apprentissage automatique apporte réellement, et ce qu’elle ne résout pas.
Ce que l’apprentissage automatique fait bien
Détecter des écarts à une norme comportementale. C’est le cas d’usage le plus solide. Un compte qui se connecte à trois heures du matin depuis un pays inhabituel, qui accède à des volumes de données sans commune mesure avec son historique, ou qui déclenche une séquence d’actions atypique. Aucune règle statique ne couvre correctement ce type de signal, parce que la normalité varie d’un utilisateur à l’autre.
Réduire le bruit par corrélation. Regrouper cent alertes isolées en un incident unique, avec une chronologie reconstituée. C’est un gain de temps analyste mesurable, et probablement le bénéfice le plus tangible aujourd’hui.
Classer et enrichir. Rattacher automatiquement une observation à une technique du référentiel MITRE ATT&CK, proposer un contexte, prioriser selon l’exposition réelle de l’actif concerné.
Ce qu’elle ne résout pas
Le taux de faux positifs reste le sujet
Un modèle qui détecte 99 % des attaques avec 1 % de faux positifs paraît excellent. Appliqué à dix millions d’événements quotidiens, il produit cent mille alertes fausses par jour. Aucune équipe ne traite cela.
C’est le paradoxe du taux de base : quand les événements malveillants sont extrêmement rares par rapport au volume total, même un très bon taux d’erreur produit une majorité écrasante de fausses alertes. C’est la raison pour laquelle la plupart des déploiements finissent avec un modèle réglé si conservateur qu’il ne détecte plus grand-chose.
Le besoin d’une base saine
Un modèle apprend sur vos données. Si votre journalisation est incomplète, si vos horloges ne sont pas synchronisées, si la moitié de votre parc n’envoie rien, le modèle apprend une normalité fausse — et la considérera comme la référence.
Dans les organisations que nous accompagnons, le blocage est presque toujours là : pas dans l’algorithme, dans la collecte.
L’explicabilité
Un analyste doit pouvoir justifier une décision d’isolement de poste devant un métier mécontent, et un RSSI doit pouvoir l’expliquer dans un rapport d’incident. Un score de 0,87 sans motif exploitable ne suffit dans aucun des deux cas.
Le retournement : l’IA comme surface d’attaque
Le sujet le plus concret aujourd’hui n’est pas l’IA défensive. C’est l’IA que vous déployez ailleurs dans l’entreprise.
L’OWASP Top 10 for LLM Applications recense les risques propres aux applications bâties sur de grands modèles de langage. Les plus fréquents en environnement d’entreprise :
- Injection de prompt : des instructions dissimulées dans un document, un courriel ou une page web, puis exécutées par un assistant qui les lit sans distinguer donnée et consigne.
- Fuite de données par un assistant connecté à des sources internes sans contrôle d’accès cohérent avec celui du système d’origine.
- Dépendance excessive : une réponse plausible mais fausse, reprise sans vérification dans un livrable ou une décision.
Un assistant interne branché sur une base documentaire hérite rarement des droits d’accès de cette base. C’est le premier point que nous vérifions lors d’un audit sur ce type de déploiement, et c’est celui qui pose problème le plus souvent.
Le cadre réglementaire arrive
Le règlement (UE) 2024/1689, dit AI Act, structure les obligations par niveau de risque, avec une application progressive. Les systèmes utilisés dans certains contextes — biométrie, ressources humaines, infrastructures critiques — relèvent de catégories exigeantes en matière de documentation, de journalisation et de supervision humaine.
Côté méthode, le NIST AI Risk Management Framework propose un cadre volontaire structuré autour de quatre fonctions : gouverner, cartographier, mesurer, gérer. Il est utile même en l’absence d’obligation, parce qu’il impose de poser les bonnes questions avant le déploiement plutôt qu’après.
Trois questions à poser avant d’acheter
- Sur quelles données le modèle a-t-il été entraîné, et sont-elles représentatives d’un environnement comme le nôtre ?
- Quel est le taux de faux positifs mesuré sur un périmètre comparable, et sur quelle volumétrie ?
- Comment une décision est-elle expliquée à l’analyste qui devra l’assumer ?
Si les trois réponses sont vagues, vous achetez un moteur de règles avec un vocabulaire plus récent.
Sources
- MITRE ATT&CK — référentiel des techniques adverses
- OWASP Top 10 for LLM Applications
- NIST AI Risk Management Framework
- Règlement (UE) 2024/1689 — AI Act
Aller plus loin
Nous auditons les déploiements d’assistants internes dans le cadre de l’audit 360. La supervision opérationnelle relève de notre infogérance SOC, et le cadrage des exigences de gouvernance, risques et conformité.