SOC et Blue Teaming : deux cas d'usage de l'IA appliquée aux opérations de sécurité

Deux cas d'usage, deux modèles économiques très différents

Les deux scénarios n'ont pas le même objectif économique. Dans le scénario bancaire utilisé ici, le SOC généraliste compte dix personnes et représente environ 1,02 M€ de coût direct du travail par an. L'effectif reste volontairement inchangé : l'IA sert surtout à augmenter la capacité de traitement, accélérer les investigations et rendre les analyses plus homogènes. La Blue Team compte également dix personnes, pour environ 1,36 M€ par an. Si près de la moitié de sa capacité est consacrée au triage et à l'analyse de malware, et si l'automatisation prend en charge l'essentiel de cette première analyse répétitive, un modèle opérationnel cible autour de cinq profils seniors peut être envisagé pour environ 700 k€ par an.

Dans ce scénario, l'écart de coût direct atteint environ 656 k€ par an. Avec une hypothèse illustrative de 400 k€ de coût initial de mise en œuvre et de 200 k€ de coûts d'exploitation annuels pour la plateforme IA, le gain net récurrent ressort à environ 456 k€ par an. Le coût initial est alors compensé en environ 10,5 mois. Sur trois ans, le bénéfice net cumulé atteint près de 968 k€, soit environ 97 % de retour sur investissement par rapport aux dépenses de plateforme. Ce calcul n'attribue aucune valeur financière supplémentaire aux gains de capacité du SOC ni à une éventuelle réduction du coût des incidents.

Ces chiffres ne constituent pas une promesse générale sur l'IA ni sur les effectifs. Ils dépendent directement de la nature du travail. Un SOC couvre des activités très diverses : identité, endpoints, messagerie, cloud, réseau, escalades, suivi des incidents et, souvent, une couverture continue. La Blue Team de ce scénario consacre au contraire une part importante de son temps à un processus plus répétable : la première analyse de malware. C'est cette différence de charge de travail qui explique les deux modèles économiques.

L'objectif de l'article est donc double : montrer comment l'investigation SOC et le triage de malware peuvent être automatisés sans donner au modèle une autorité directe sur la production, puis traduire cette automatisation en valeur économique exploitable par un CISO, un CFO ou un comité d'investissement. L'article ne suppose ni que l'IA remplace les analystes, ni que toute automatisation entraîne mécaniquement une réduction d'effectifs.

Lire correctement le ROI : économies réelles, capacité récupérée et réduction du risque

Les analyses économiques de l'automatisation en cybersécurité mélangent souvent trois types de bénéfices qui ne doivent pas être comptabilisés de la même manière.

Le premier est l'économie budgétaire directe. Elle n'existe que lorsqu'un poste disparaît réellement du budget sans être remplacé, ou lorsqu'une dépense externe est supprimée. Dans le scénario présenté ici, le passage d'une Blue Team de dix à cinq personnes crée ce type d'économie uniquement si la charge restante peut effectivement être absorbée par le nouveau modèle opérationnel.

Le deuxième est la capacité récupérée. Si dix analystes SOC gagnent 10 à 20 % de productivité et que les dix postes sont conservés, la masse salariale ne baisse pas. La valeur existe néanmoins : davantage d'incidents peuvent être traités, les files d'attente diminuent, les profils seniors récupèrent du temps et certains recrutements futurs peuvent être différés. Pour de nombreux SOC, cette forme de valeur est plus réaliste qu'une réduction immédiate des effectifs.

Le troisième est la réduction du coût du risque. Une investigation plus rapide, une révocation de session plus précoce ou un meilleur signal de détection peuvent réduire l'impact financier d'un incident majeur. Cette valeur peut être supérieure aux gains de productivité, mais elle est difficile à budgéter proprement. Elle reste donc hors du calcul central présenté ici.

Bénéfice net annuel = économies directes + recrutements évités + prestations externes évitées
      + capacité récupérée monétisée - coûts d'exploitation de la plateforme

      Délai de retour simple = coût initial du programme / bénéfice net annuel

      ROI à 3 ans            = (bénéfices cumulés - coûts cumulés) / coûts cumulés

Une hypothèse essentielle : 50 % de charge consacrée au malware ne signifie pas 50 % de postes en moins

Une équipe de dix personnes qui consacre la moitié de sa capacité au malware porte environ cinq ETP de charge sur cette activité. Si l'automatisation supprime 80 % de ce travail, elle libère environ quatre ETP, pas cinq. Pour atteindre une équipe cible de cinq personnes, il faut une automatisation très poussée de la première analyse répétitive, mais aussi une réorganisation du reste : validation intégrée au processus, génération automatisée des rapports, meilleure priorisation et maintien de profils suffisamment seniors pour traiter les exceptions.

Le passage de dix à cinq personnes doit donc être lu comme un modèle opérationnel cible, pas comme une règle arithmétique.

Accélérer l'investigation SOC sans donner à l'agent le pouvoir d'agir directement

Un incident de sécurité se traite rarement dans une seule console. Une alerte peut commencer dans Defender for Office 365, être corrélée dans Microsoft Sentinel, nécessiter une consultation de la chronologie dans Defender for Endpoint, puis une analyse des connexions Entra ID et un enrichissement par la Threat Intelligence. L'analyste doit reconstruire la chronologie, déterminer si plusieurs événements appartiennent au même scénario, identifier les systèmes et les identités touchés, puis choisir les actions de réponse possibles.

C'est précisément sur cette partie que les LLM peuvent être utiles : parcourir beaucoup de texte, faire ressortir les événements importants, relier des entités, résumer une chronologie et proposer des hypothèses. Un agent peut également préparer une synthèse homogène de l'incident et une liste d'actions candidates.

Dans une banque, cela ne signifie pas laisser le modèle « gérer le SOC ». L'objectif est de lui confier l'analyse et la proposition, tout en maintenant l'autorisation et l'exécution dans des composants indépendants.

Exemple : suspicion de vol d'identifiants

Prenons un incident signalant un possible vol d'identifiants. L'investigation doit vérifier les alertes Defender, les entités associées à l'incident Sentinel, la chronologie du poste, les connexions Entra ID, l'adresse IP source et la réputation des indicateurs observés. À l'issue de cette analyse, plusieurs actions peuvent être envisagées : isoler le poste, révoquer les sessions, placer l'e-mail d'origine en quarantaine, bloquer un IOC ou ouvrir un incident ServiceNow.

L'agent accélère l'investigation parce qu'il peut consulter ces sources au moyen d'outils en lecture seule et synthétiser ce qu'il trouve. Le risque apparaît au moment où la même identité reçoit également le droit d'exécuter directement les actions de remédiation.

Une architecture simple à construire, mais dangereuse

La manière la plus directe de construire un agent autonome consiste à lui attribuer une identité qui cumule les droits de lecture sur les sources de sécurité et les permissions d'écriture sur les API de remédiation. L'agent lit, raisonne puis exécute avec la même identité. Le flux paraît simple, mais il place dans le même composant deux responsabilités qui doivent rester séparées : interpréter des données potentiellement manipulées par un attaquant et agir sur la production.

Le problème tient à la nature des données analysées. Un e-mail, une ligne de commande, un nom de fichier, un en-tête HTTP, un IOC ou même une réponse renvoyée par un outil peuvent contenir du texte choisi par l'attaquant. Dès que ce contenu entre dans le contexte du modèle, il peut influencer son raisonnement.

Une injection de prompt indirecte n'a donc pas besoin de compromettre techniquement le modèle. L'attaquant cherche simplement à introduire une instruction suffisamment crédible pour modifier ce que l'agent décide de faire.

Chemin d'attaque : quand le contenu d'un e-mail influence l'agent

1. L'e-mail de phishing est détecté. Defender crée un incident et Sentinel déclenche le processus d'investigation.
2. Le contenu complet est transmis au modèle. Le corps du message, y compris du texte caché ou obfusqué, fait partie des informations utilisées par l'agent pour raisonner.
3. Le contenu malveillant influence le raisonnement. Il peut inciter le modèle à ne pas isoler le poste, à consulter d'autres événements ou à tenter de transmettre des informations vers une destination externe.
4. Dans une architecture trop permissive, l'identité privilégiée transforme l'erreur en action réelle. Les appels sont effectués avec une identité légitime ; le runtime de l'agent n'a pas besoin d'être compromis.

Le problème n'est donc pas de trouver un LLM qui serait impossible à influencer. Il faut concevoir l'architecture pour qu'une erreur de raisonnement ne puisse pas devenir directement une action privilégiée.

Séparer l'analyse, l'autorisation et l'exécution

L'architecture cible sépare clairement trois responsabilités. L'agent d'investigation reste en lecture seule et consulte Sentinel, Defender, Entra ID et la Threat Intelligence. Lorsqu'il estime qu'une action est nécessaire, il ne l'exécute pas : il produit une proposition structurée. Un Policy Decision Point (PDP), déterministe et sans LLM, vérifie ensuite cette proposition et retourne l'une des trois décisions prévues : autoriser, demander une approbation humaine ou refuser.

Le pouvoir d'exécution reste dans un domaine de sécurité séparé. L'orchestrateur n'accepte que les décisions valides du PDP. Chaque worker dispose de sa propre identité et uniquement des permissions nécessaires à une action précise. Si l'organisation veut rendre une action impossible pour l'automatisation, aucun worker correspondant n'est déployé.

Cette séparation permet d'accepter une réalité importante : le modèle peut proposer une mauvaise action sans que le système s'effondre. La proposition reste une donnée à contrôler ; elle n'a aucune autorité par elle-même.

Le manifeste d'action : une proposition structurée, jamais une commande exécutable

Le manifeste est un document JSON structuré. L'action est choisie dans une liste fermée, la cible respecte un type défini, l'incident est référencé, les éléments ayant conduit à la proposition sont identifiés et la durée de validité est courte. Une justification en texte libre peut être conservée pour l'analyste, mais ce texte n'est jamais transmis au worker comme une instruction à exécuter.

Le PDP relit ensuite lui-même les informations déterminantes avec sa propre identité. Il vérifie notamment que la cible est réellement associée à l'incident, que le verdict Defender correspond aux règles autorisées, que l'actif n'appartient pas à une classe protégée comme Tier 0, que les limites d'actions sont respectées et que le manifeste n'a pas déjà été utilisé.

Le même principe s'applique aux scores de confiance produits par le modèle. Un agent peut annoncer une confiance de 0,97 ; cette valeur reste une assertion du modèle. Elle ne remplace ni un verdict Defender ni une information relue directement dans une source de confiance.

Le modèle peut expliquer pourquoi il propose une action. Il ne doit jamais être l'autorité qui décide, à lui seul, que cette action peut être exécutée.

Approbation humaine : autoriser une action précise, pas donner plus de pouvoir à l'agent

Pour certaines actions sensibles, le modèle prépare la proposition et un analyste doit l'approuver. Cette approbation reste liée au hash d'un manifeste précis, à une cible précise et à une durée de validité courte. Elle n'accorde aucun rôle ni aucune permission supplémentaire à l'identité de l'agent.

Cette approche permet de définir plusieurs niveaux d'automatisation. Une opération à impact limité peut être exécutée automatiquement si toutes les règles sont satisfaites. L'isolation d'un poste ou la révocation de sessions peut nécessiter des conditions déterministes plus strictes. La désactivation d'un compte ou une action sur un serveur peut exiger une approbation humaine. Les opérations critiques (modification de Conditional Access, RBAC, PIM, Azure Policy, règles de détection ou du PDP lui-même) peuvent rester techniquement hors de portée de l'automatisation.

Les identités déterminent le périmètre d'impact

Dans une architecture agentique, l'impact d'une compromission dépend directement des permissions de l'identité utilisée pour signer les appels. Un prompt bien conçu ne compense pas une identité trop puissante. L'agent d'investigation, le PDP, l'orchestrateur et chaque worker utilisent donc des identités distinctes.

Un worker d'isolation possède uniquement les permissions nécessaires pour isoler un poste. Un worker de révocation de sessions ne peut pas désactiver le compte. Un worker de blocage d'IOC est limité à un périmètre de pare-feu prédéfini. Si l'un de ces composants est compromis, son impact reste limité aux droits qui lui ont été attribués.

Mécanismes d'arrêt d'urgence : pouvoir couper les capacités sans dépendre de l'agent

L'environnement d'exécution de l'agent ne doit pas contrôler ses propres mécanismes d'arrêt. L'architecture prévoit trois niveaux indépendants : désactiver l'identité de l'agent, couper son accès aux outils et à la file de propositions, puis bloquer toute exécution au niveau de l'orchestrateur. Un mécanisme de surveillance indépendant peut également arrêter l'exécution par défaut si le PDP ne répond plus.

Le test important est l'indépendance. Même si un attaquant contrôle totalement le prompt, la mémoire ou un serveur MCP, il doit rester incapable de réactiver un worker, de prolonger la validité d'un manifeste, de modifier les règles d'autorisation ou de désactiver les mécanismes d'arrêt.

Tester l'architecture en supposant que l'injection réussira

La validation doit être un exercice de sécurité, pas une démonstration de qualité du prompt. Des instructions malveillantes sont donc placées dans les e-mails, les lignes de commande, les en-têtes User-Agent, les IOC, les descriptions d'outils MCP et les réponses d'outils. Les rejeux de manifestes, les substitutions de cible et les faux scores de confiance doivent également être testés.

Le critère de réussite n'est donc pas « aucune injection de prompt n'a fonctionné ». Il devient : même si le composant de raisonnement est compromis ou manipulé, aucune action privilégiée ne peut être exécutée sans passer par les contrôles indépendants.

Observabilité : transformer les refus en signaux de sécurité

Un système agentique bien conçu journalise bien plus qu'un simple résultat d'exécution. Il enregistre le manifeste, son hash, la décision du PDP, la règle appliquée, l'éventuel approbateur humain, l'identité du worker et la réponse du système cible.

Les refus sont particulièrement utiles. Une proposition d'action critique, une cible absente de l'incident, un score de confiance incohérent avec Defender ou des demandes répétées après refus peuvent indiquer une tentative d'influencer l'agent ou un dysfonctionnement. Chaque refus devient alors un événement exploitable par le SOC et un cas de test pour les règles de sécurité.

ROI du SOC : ne pas confondre gain de productivité et économie budgétaire

Le modèle économique du SOC reste volontairement prudent : les dix personnes sont conservées. L'équipe modélisée comprend quatre analystes L1 à 55 k€, trois analystes L2 à 68 k€, deux seniors à 84 k€ et un SOC lead à 100 k€, soit 692 k€ de salaires fixes. En appliquant la structure Eurostat selon laquelle les coûts non salariaux représentent 32,3 % du coût total du travail en France, le coût direct annuel est estimé à environ 1,02 M€. [3]

Microsoft a mesuré un gain moyen de 22 % en vitesse et de 7 % en précision lors d'un essai randomisé mené auprès de 147 professionnels de la sécurité utilisant Copilot for Security sur les tâches testées. [4] Il serait excessif d'appliquer automatiquement ces 22 % à l'ensemble d'un SOC bancaire. Ce résultat peut néanmoins servir de référence haute pour illustrer la valeur potentielle de la capacité récupérée.

Pour un comité exécutif, il faut donc distinguer valeur économique et économie budgétaire. Si les dix analystes restent en poste, 153 k€ de capacité récupérée ne réduisent pas directement la masse salariale. En revanche, si cette capacité évite un onzième recrutement, réduit les astreintes ou remplace une partie d'un contrat MSSP, une partie du gain devient effectivement budgétaire.

Automatiser le triage de malware sans déléguer l'autorité

Le deuxième cas d'usage présente un profil économique différent parce que le travail est plus concentré. Une Blue Team peut consacrer beaucoup de temps à la première analyse d'échantillons : identifier le format, examiner les chaînes de caractères, relever les anomalies, suivre les références, vérifier les règles YARA, décompiler certaines fonctions, extraire les IOC, comparer l'échantillon à des familles connues et rédiger un premier rapport.

Cette première analyse est technique, mais elle suit souvent une méthode répétable. Un modèle connecté à un analyseur spécialisé peut automatiser une grande partie de la navigation et de la synthèse sans recevoir pour autant un environnement d'exécution généraliste.

Malcat MCP : fournir des outils d'analyse spécialisés, pas un shell

Malcat expose via MCP des outils de lecture et de transformation. Le modèle peut inspecter de nombreux formats, suivre les fonctions, examiner les chaînes et les anomalies, exploiter les résultats YARA, désassembler, décompiler et appliquer certains mécanismes de dépaquetage statique.

La contrainte compte autant que la capacité. Dans le scénario présenté, l'agent ne dispose ni d'un shell, ni d'un accès Python arbitraire, ni d'un accès Internet libre. Il n'exécute jamais l'échantillon. Le modèle peut donc être utile pour l'analyse sans devenir lui-même un environnement de détonation.

Le benchmark publié par Malcat le 18 mai 2026 évalue neuf modèles. Il montre des résultats déjà solides sur le triage, mais plus variables sur les tâches de rétro-ingénierie avancée et de dépaquetage statique. [7] L'auteur précise qu'il ne s'agit pas d'une étude scientifique académique. Ces résultats montrent une faisabilité technique ; ils ne démontrent pas à eux seuls qu'une réduction d'effectifs est possible.

Kesakode et Malpedia : identifier une famille probable sans prétendre attribuer l'attaque

Kesakode compare les fonctions d'un binaire à une base de connaissances et propose une famille probable. L'agent peut utiliser ce résultat pour concentrer son analyse sur les fonctions les plus suspectes. Malpedia apporte ensuite du contexte documenté sur les familles, leurs alias et les groupes qui leur ont été historiquement associés.

Cette distinction est importante. Une similarité de fonctions n'est pas une preuve d'attribution, et une association historique dans Malpedia ne démontre pas que l'échantillon étudié appartient à la campagne d'un acteur précis. Le rôle du modèle est de présenter ces éléments à l'analyste avec leurs limites, pas de transformer une corrélation en certitude.

Conserver l'échantillon et les actions dans une chaîne contrôlée

Le malware lui-même doit être considéré comme une donnée hostile. L'agent ne doit pas pouvoir choisir où le fichier est téléchargé, envoyé ou exécuté. L'architecture utilise donc un worker dédié pour extraire le fichier depuis la quarantaine, un stockage immuable indexé par SHA-256, un montage en lecture seule dans l'environnement d'analyse et des sorties strictement contrôlées.

L'agent rédige un rapport puis demande son envoi au moyen d'un manifeste. Le worker d'envoi utilise un expéditeur et un destinataire prédéfinis ; le fichier malveillant n'est jamais joint au message. Un autre manifeste peut proposer le blocage d'un IOC, mais le PDP vérifie d'abord que l'action est autorisée avant qu'un worker aux permissions limitées ne l'exécute.

Le triage automatisé ne remplace pas la rétro-ingénierie avancée

Cette nuance est essentielle pour le modèle d'effectifs. L'IA peut automatiser une grande partie de la première analyse : collecte des indices, navigation dans le binaire, synthèse, rédaction du rapport et rapprochement avec des familles ou des signatures connues. Elle ne supprime pas le besoin d'experts capables d'expliquer un packer inconnu, une technique anti-analyse, un nouveau loader, un comportement conditionnel ou une campagne réellement ciblée.

Les cinq personnes restantes ne deviennent donc pas de simples « validateurs de ChatGPT ». Le modèle cible suppose au contraire une équipe plus senior : traitement des cas complexes, validation des conclusions importantes, maintien de la qualité des détections, amélioration des outils et des prompts, chasse aux menaces (threat hunting) et intervention lorsque la chaîne automatisée atteint ses limites.

ROI de la Blue Team : transformer une capacité récupérée en réduction de coût réelle

La Blue Team initiale du modèle comprend deux Detection Engineers à 84 k€, deux Threat Hunters à 90 k€, deux profils DFIR à 90 k€, deux Cloud/Endpoint Security Engineers à 90 k€, un Malware Analyst à 95 k€ et un Blue Team Lead à 115 k€. Cela représente 918 k€ de salaires fixes, soit environ 1,36 M€ de coût direct du travail avec la même méthode de calcul.

L'équipe cible conserve un Detection Engineer, un Threat Hunter, un spécialiste DFIR, un Malware Analyst / Reverse Engineer et le Blue Team Lead. Les salaires fixes totalisent 474 k€, soit environ 700 k€ de coût direct du travail.

Retour sur investissement du programme complet

Le scénario central utilise deux hypothèses de plateforme volontairement séparées des benchmarks externes : 400 k€ de coût initial de mise en œuvre et 200 k€ de coûts d'exploitation récurrents par an. Le coût initial couvre l'intégration, les identités, le PDP, l'orchestration, les workers, l'observabilité, les tests et l'industrialisation. Les coûts d'exploitation regroupent le runtime des modèles, l'infrastructure, l'exploitation, la supervision, les évaluations continues et la maintenance.

Le bénéfice net cumulé atteint environ 968 k€, soit environ 97 % de ROI sur trois ans par rapport au coût du programme. La première année reste proche de l'équilibre parce qu'elle absorbe le coût initial ; les deuxième et troisième années ajoutent chacune environ 456 k€ de bénéfice net.

Analyse de sensibilité : que se passe-t-il si la réduction d'effectif est moins forte ?

L'équipe de cinq personnes représente le scénario cible, pas une obligation. Un CISO doit également tester des variantes plus prudentes. Si la plateforme ne permet de supprimer que trois ou quatre postes, le scénario économique peut rester positif, avec un délai de retour plus long.

Cette analyse de sensibilité est essentielle. Le programme n'est pas un échec si l'organisation conserve finalement six personnes au lieu de cinq. L'arbitrage dépend de la résilience attendue, du volume de malware, de la complexité moyenne des échantillons, des besoins d'astreinte et du niveau d'expertise que la banque souhaite conserver en interne.

Ce que le calcul central ne valorise pas

Le calcul central exclut volontairement le gain de productivité du SOC. Il n'intègre pas non plus une éventuelle baisse de dépendance à un MSSP, les recrutements futurs évités, la réduction des astreintes, les gains de MTTR ou la diminution du coût d'un incident majeur.

Autrement dit, le scénario est prudent sur les bénéfices annexes, mais ambitieux sur l'hypothèse de réduction d'effectif de la Blue Team. C'est cette distinction qui permet de le présenter de manière transparente à un comité d'investissement.

Pour une banque, la vitesse de réaction et la traçabilité ont aussi une valeur

IBM indique dans son rapport 2026 un coût moyen mondial de violation de données de 4,99 M$, et environ 6,3 M$ pour les services financiers. La même étude rapporte une économie moyenne de 1,93 M$ dans les organisations qui utilisent largement l'IA et l'automatisation en sécurité, par rapport à celles qui n'en utilisent pas. [5] Il s'agit d'observations agrégées ; elles ne peuvent pas être attribuées directement à l'architecture décrite ici.

Elles donnent néanmoins un ordre de grandeur. Réduire de quelques minutes ou de quelques heures le délai nécessaire pour isoler un poste compromis ou révoquer une session volée peut avoir une valeur très supérieure au seul temps d'analyste économisé sur cette action.

Le secteur financier impose également une forte exigence de traçabilité. DORA demande aux entités financières européennes de disposer d'un processus de gestion des incidents TIC couvrant notamment la détection, la gestion, l'enregistrement, la catégorisation, la classification et le suivi. [6] Une plateforme qui journalise chaque proposition, décision, approbation et exécution apporte donc aussi une valeur de gouvernance et d'audit.

Les principes communs aux deux cas d'usage

La valeur dépend du travail réellement automatisé

Ces deux cas montrent pourquoi l'expression « IA dans la cybersécurité » est trop générale pour parler de valeur. Le résultat dépend avant tout du type de travail automatisé.

Dans le SOC, l'IA sert surtout à augmenter ce que dix analystes peuvent traiter : meilleure corrélation, investigations plus rapides, synthèses plus homogènes et moins de temps passé à naviguer entre les consoles. L'équipe reste à dix parce que sa valeur repose aussi sur l'étendue de sa couverture et sa capacité à gérer l'imprévu.

Dans la Blue Team, la structure de la charge peut être différente. Si l'équivalent de cinq ETP est consacré au triage de malware et que l'essentiel de cette première analyse devient automatisable, le modèle opérationnel peut être reconstruit autour de cinq profils plus seniors. C'est dans ce cas que la capacité récupérée peut devenir une économie budgétaire directe.

L'intérêt économique ne doit jamais conduire à donner au modèle plus de pouvoir que nécessaire. Plus l'automatisation devient importante, plus il faut séparer l'analyse, l'autorisation et l'exécution, relire indépendamment les informations critiques, isoler les identités et maintenir des mécanismes d'arrêt d'urgence indépendants du runtime de l'agent.

L'objectif n'est pas de construire un agent qui ne se trompe jamais. L'objectif est de construire une architecture dans laquelle une erreur du modèle reste une erreur d'analyse et ne devient jamais, à elle seule, une action privilégiée en production.