Le SOC est mort. Longue vie au SOCC.

Et si on parlait de quelque chose que peu dans l'industrie ont le courage de reconnaître ou d'écrire noir sur blanc : le Security Operations Center, tel qu'on l'a conçu, construit et vendu depuis quinze ans, est mort.

Ce n'est pas une provocation gratuite. C'est un constat que je fais depuis quelques années, et que vingt ans passés à construire des SOC partout dans le monde, dont certains parmi les plus grands d'Europe, avec des SIEM sous QRadar ingérant plusieurs millions d'événements par seconde, m'ont progressivement imposé.

Le SOC n'est pas mort d'un coup. Il s'est asphyxié lentement, sous le poids de ses propres certitudes.

Un modèle bâti sur les fondations d'une autre époque

Revenons en arrière. Les années 2008–2015 voient éclore, un peu partout, des Security Operations Centers ambitieux. L'enjeu est clair : centraliser la surveillance, industrialiser la détection, mutualiser les compétences.

Le SIEM est le cœur du réacteur. Les règles de corrélation sont l'intelligence du dispositif.

Les analystes, Tier 1, Tier 2 et Tier 3, en sont les artisans.

Je me souviens de mes duos avec Julie Sallé, Damien Frey ou Arnaud Hess. On était partout. Et on bâtissait et vendait des SOC sur un modèle bien huilé…

Ce modèle avait du sens. Dans un monde où le périmètre réseau était encore une réalité tangible, où les attaquants utilisaient des techniques relativement bien documentées, où les assets étaient majoritairement on-premise et inventoriés, la pyramide du SOC (que j’ai eu l’honneur de co-écrire) fonctionnait.

Mais ce monde n'existe plus.

Le périmètre a explosé. Le cloud, le shadow IT, le télétravail, l'OT connecté, les chaînes d'approvisionnement numériques… tout cela a rendu obsolète la notion même de frontière à surveiller.

Les attaquants, eux, ont évolué à une vitesse que les processus du SOC traditionnel n'ont pas suivie. Ils vivent dans les angles morts. Ils abusent des outils légitimes. Ils patientent.

Et le SOC, lui, continue de trier des tickets, de chercher pourquoi ils n’ont pas les logs…

Et la preuve par les faits est implacable.

En France, comme partout d'ailleurs, les incidents majeurs se succèdent à un rythme qui ne ralentit pas : hôpitaux paralysés par des ransomwares, collectivités territoriales exfiltrées, des grands groupes contraints à des communications de crise. Des dizaines de millions de données personnelles sont dans la nature.

Beaucoup de ces organisations avaient un SOC au moment des faits. Certaines avaient plusieurs couches de sécurité, des certifications. Elles ont quand même été touchées.

N'est-ce pas le signal que le modèle SOC traditionnel doit être revu intégralement et immédiatement ?

Le SIEM : de phare en faux ami

Pendant longtemps, le SIEM a été présenté comme le phare d'Alexandrie du SOC : une lumière centrale, visible de loin, guidant toutes les décisions.

On y versait tout : logs Windows, flux réseau, événements applicatifs, alertes firewall, et on en attendait de l'intelligence.......

Je me souviens encore de ce que je disais : “plus j’ai de données, mieux je me porte”.

Aujourd'hui, ce que l'on récolte, c'est principalement du bruit. Et ça devient même un vacarme. Un capharnaüm.

Le problème du SIEM n'est pas technique au sens strict. C'est un problème de paradigme. Le SIEM est un agrégateur et un corrélateur d'événements connus. Il fonctionne à partir de règles, de seuils, de signatures. Il est, par construction, orienté vers le passé. Il détecte ce qu'on lui a appris à détecter.

Face à des attaquants qui innovent en permanence, face à des techniques de living-off-the-land qui ne déclenchent aucune règle parce qu'elles n'utilisent que des outils légitimes, face au volume de données qui a été multiplié par dix en cinq ans, le SIEM seul ne suffit plus.

Pire : dans de nombreux SOC, le SIEM est devenu une machine à produire des faux positifs, chronophage et coûteuse, qui épuise les équipes sans améliorer substantiellement le niveau de détection. Les analystes passent leur temps à fermer des alertes. Pas à traquer des adversaires.

L'outil conçu pour libérer du temps cognitif est devenu le principal consommateur de ce temps.

Des processus figés dans l'ambre

Le modèle opérationnel du SOC traditionnel repose sur une organisation en niveaux, des runbooks, des SLA de réponse aux tickets, et des KPIs qui mesurent le volume de traitement plutôt que l'impact réel sur la posture de sécurité.

Ces processus ont été pensés pour un monde stable, prévisible, industrialisable.

Ils ont une vertu : la cohérence.

Chaque analyste, quel que soit son niveau, suit le même chemin décisionnel face à une alerte.

Mais cette cohérence est aussi leur limite fondamentale.

Aujourd'hui, une cyberattaque sophistiquée ne se manifeste pas par une alerte bien étiquetée dans une file de tickets. Elle se manifeste par une succession de signaux faibles, dispersés dans le temps et dans les systèmes, qui ne n'ont de sens qu'une fois reconstitués.

Le runbook, par définition, ne couvre pas ce qu'on n'a pas encore vu.

Les procédures d'escalade entre tiers ? Elles introduisent de la latence là où il faudrait de la réactivité.

Les SLA en minutes ou en heures ? Ils sont devenus dérisoires face à des attaquants qui peuvent passer de l'accès initial à l'exfiltration en moins de quarante-huit heures, parfois bien moins.

Le SOC a industrialisé le traitement des incidents connus. Il n'a pas été conçu pour traquer l'inconnu.

La commodité a tué le différentiel

Il y a une réalité de marché que peu veulent admettre : le SOC est devenu une commodité.

Les offres MSSP se sont standardisées. Les grandes ESN proposent toutes un SOC 24/7, avec des SLA comparables, des certifications similaires, des stacks technologiques proches, même si très performantes. Les clients achètent de la conformité, de la couverture contractuelle, parfois de la tranquillité d'esprit.

Mais ils n'achètent plus, ou rarement, de la vraie valeur opérationnelle.

Lorsque tout le monde fait la même chose avec les mêmes outils et les mêmes processus, le SOC cesse d'être un avantage stratégique pour devenir une ligne de coût. Un service de base, comme l'électricité ou le nettoyage des bureaux. Utile. Nécessaire. Mais pas différenciant.

Ce n'est pas un jugement de valeur sur les équipes qui font ce travail.

C'est un constat sur un modèle qui a atteint ses limites de maturité.

Quand une industrie entière converge vers les mêmes pratiques, elle cesse d'innover. Elle gère.

Le problème humain : celles et ceux qui s'accrochent au rocher

Abordons maintenant un sujet délicat, parce qu'il est au cœur du problème, et parce que l'esquiver serait malhonnête.

Dans les SOC, il y a des profils formidables : des analystes curieux, des hunters passionnés, des ingénieurs qui remettent en question leurs outils chaque jour. Ils existent. Je les ai croisés, formés, recrutés.

Et puis il y a les autres.

Celles et ceux qui sont ancrés depuis des années dans des routines immuables. Qui ont appris à travailler avec un outil il y a dix ans et refusent d'en changer. Qui voient l'IA, le NDR, la threat intelligence contextualisée comme des menaces à leur expertise plutôt que comme des leviers pour l'amplifier.

Qui définissent leur valeur par leur maîtrise d'un outil ou d'un process spécifique, pas par leur capacité à répondre à une menace réelle.

Ce n'est pas de la mauvaise volonté. C'est souvent de la peur, habillée en résistance technique.

Mais cette posture est aujourd'hui un frein structurel. Un analyste SOC qui refuse d'intégrer la CTI dans son raisonnement, qui ne voit pas pourquoi observer et analyser le réseau, qui ne comprend pas pourquoi la détection comportementale complète la détection par règles, qui n'a jamais ouvert un rapport de threat actor, n'est pas un analyste de la sécurité d'aujourd'hui.

Faire évoluer un SOC, ce n'est pas seulement remplacer des outils. C'est transformer des savoir-faire. Et ça commence par accepter que ce qu'on savait faire hier ne sera pas suffisant demain.

J'ai contribué, quand j'ai bâti le cybercentre de Sopra Steria, à faire de la Cyber Threat Intelligence un composant par défaut des services SOC délivrés, pas un add-on premium, pas une option. Une fondation. Parce que comprendre l'adversaire n'est pas un luxe : c'est un prérequis.

Cette démarche s'est heurtée à des résistances internes, et externes évidemment. Mais elle a aussi produit des analystes bien meilleurs.

Je me permets d'être direct sur ce point parce que j'y ai consacré une grande partie de ma carrière. En 2006, j'ai fondé la première équipe SOC de CGI en France, à une époque où le terme lui-même était encore flou pour beaucoup.

J'ai ensuite bâti la Detection Unit chez Atheos, qui allait devenir Orange Cyberdefense, avant de restructurer en profondeur le SOC de Sopra Steria et d'y ancrer la CTI comme fondation opérationnelle. Puis chez Capgemini, face à des équipes clients dont certaines avaient des années de pratiques bien installées, je me suis à nouveau heurté au même mur : "On a toujours fait comme ça."

Cette phrase, je l'ai entendue des dizaines de fois, dans des organisations pourtant solides, avec des équipes pourtant compétentes. Elle n'est jamais une excuse.

Elle est le symptôme d'un modèle qui se protège lui-même contre sa propre évolution.

Alors, que faire ? Faire renaître le SOCC.

Je ne crois pas à la disparition du SOC. Je crois à sa transformation radicale.

Le Security Operations Center doit devenir un Service of Observation and Collaboration for Cybersecurity.

Chaque mot compte.

Service : pas une forteresse isolée, mais une fonction orientée vers ses clients internes, les équipes IT, les métiers, le COMEX, avec une obligation de lisibilité et de valeur prouvée.

Observation : pas seulement la collecte de logs, mais une capacité de visibilité étendue : réseau, endpoint, cloud, OT, identités, comportements. Le tout avec des outils capables d'identifier des signaux faibles avant qu'ils deviennent des incidents confirmés. C'est ici que le NDR, le UEBA, et une CTI opérationnelle intégrée prennent tout leur sens.

Collaboration : la fin du SOC en silo. Les analystes travaillent avec les équipes de réponse à incident, avec les architectes sécurité, avec les équipes produit. La détection et la remédiation ne sont plus deux mondes séparés.

for Cybersecurity : une évidence qui ne l'est plus. Le SOC n'existe pas pour produire des tickets. Il existe pour réduire le risque cyber de l'organisation.

Les piliers de la renaissance

Concrètement, faire renaître le SOC implique plusieurs ruptures :

1. Sortir du SIEM-centrisme. Le SIEM reste utile pour la gestion des logs et la conformité. Mais il ne peut plus être l'unique cerveau de la détection. Le NDR, l'analyse comportementale, l'orchestration et la corrélation intelligente doivent le compléter, voire le supplanter dans les scénarios de détection avancée.

2. Faire de la CTI une colonne vertébrale. Toute alerte devrait être enrichie d'un contexte adversarial : qui utilise cette technique ? Dans quel objectif ? Quels sont les indicateurs associés ? Une alerte sans contexte, c'est un symptôme sans diagnostic.

3. Réinvestir dans les compétences d'investigation. Un analyste SOC doit être capable de threat hunting, pas seulement de triage. La formation continue, la veille, les exercices de simulation… tout cela doit redevenir une priorité réelle, pas une ligne budgétaire sacrifiée en premier.

4. Mesurer autrement. Abandonner les KPIs de volume (nombre d'alertes traitées, temps moyen de fermeture) pour des KPIs d'impact : taux de détection d'attaques simulées, délai de détection de techniques spécifiques, couverture des tactiques MITRE ATT&CK.

5. Intégrer l'IA comme amplificateur, pas comme remplaçant. L'intelligence artificielle, correctement appliquée à la détection, peut multiplier la capacité d'analyse des équipes. Elle ne remplace pas le jugement humain, elle lui libère du temps pour qu'il s'exerce là où il compte vraiment.

Conclusion : un choix, pas une fatalité

Le SOC traditionnel est mort. Mais sa mort n'est pas une fatalité pour la cybersécurité : c'est une opportunité de le réinventer.

Celles et ceux qui construisent les SOC de demain ne partent pas de zéro. Ils partent des leçons du passé, des erreurs commises, des modèles épuisés. Ils comprennent que la technologie seule ne suffira pas, que les processus doivent être repensés de fond en comble, et que les femmes et les hommes au cœur du dispositif doivent être prêts à évoluer.

La question n'est pas si le SOC doit changer. Elle est à quelle vitesse votre organisation est prête à engager cette transformation.

Parce que pendant que vous tergiversez, vos adversaires, eux, n'attendent pas.