Face à la pénurie chronique d’analystes sécurité (l’ENISA estimait en 2023 un déficit compris entre 260 000 et 500 000 professionnels en Europe) et à l’accélération du volume d’alertes généré par les environnements hybrides, l’externalisation du SOC s’impose comme une réponse structurelle pour les organisations sans les ressources d’un centre opérationnel interne 24/7. Mais externaliser sa détection ne signifie pas externaliser sa responsabilité : le RSSI reste garant de la gouvernance, de la conformité NIS2/DORA et de la qualification des incidents. Cet article examine les modèles disponibles, les critères de sélection et les pièges contractuels à éviter.
Les modèles d’externalisation : SOC as a service, MSSP et SIEM managé
Trois catégories coexistent sur le marché, souvent confondues dans les appels d’offres.
| Modèle | Périmètre | Télémétrie ingérée | Mode tarifaire |
|---|---|---|---|
| MSSP classique | Surveillance multi-services (pare-feu, IAM, endpoints, réseau) | Logs SIEM, flux réseau, agents endpoints | Par périphérique managé ou EPS (events per second) |
| SOC as a service (SOCaaS) | Détection, triage, investigation, réponse guidée | EDR/XDR, SIEM cloud, CASB, identités | Abonnement par volume d’actifs ou d’utilisateurs |
| SIEM managé | Opération du SIEM uniquement (ingestion, règles, tuning) | Dépend du SIEM sous-jacent | Par volume de données (Go/jour) ou EPS |
Le MSSP traditionnel couvre un spectre large mais délègue souvent la corrélation à des règles statiques. Le SOCaaS est centré sur la détection avancée et intègre typiquement des capacités MDR (Managed Detection and Response) avec des analystes humains disponibles 24/7. Le SIEM managé est un service technique : le prestataire opère votre SIEM (Splunk, Microsoft Sentinel, IBM QRadar) mais ne fournit pas nécessairement d’analystes sécurité.
Pour les organisations qui évaluent simultanément EDR, MDR et XDR, le comparatif EDR/MDR/XDR pour RSSI détaille les différences de périmètre et les critères de sélection technologique.
Architecture technique d’un SOC externalisé
Un SOC externalisé opérationnel en 2026 s’appuie sur trois couches.
Collecte et normalisation de la télémétrie. Les sources primaires sont les endpoints (agents EDR), les équipements réseau (NetFlow, logs DNS/proxy), les environnements cloud (AWS CloudTrail, Azure Monitor, GCP Cloud Logging) et les applications métier (Active Directory, annuaires IdP, SaaS via API). La qualité de la détection est directement proportionnelle à la complétude de cette collecte : un SOC sans visibilité sur l’identité (Entra ID, Okta) rate les attaques BEC et les mouvements latéraux post-compromission de credential.
Détection et corrélation. Les moteurs de détection modernes combinent des règles de corrélation SIEM mappées sur MITRE ATT&CK, des modèles comportementaux (UEBA - User and Entity Behavior Analytics) et, pour les offres avancées, des modèles de machine learning supervisés. La couverture MITRE ATT&CK est devenue un indicateur de marché : exigez du prestataire la matrice de couverture par source de télémétrie, pas une couverture globale non sourcée.
Triage, investigation et réponse. Le premier niveau (L1) traite le volume d’alertes et applique des playbooks de qualification. Le L2 mène les investigations sur les alertes escaladées. Le L3 gère les incidents complexes et pilote les actions de containment. Dans les offres SOCaaS/MDR, le L3 peut inclure des capacités de réponse active (isolation d’endpoint, blocage de compte) via des intégrations API avec les outils de l’organisation.
Critères de sélection d’un MSSP ou SOC as a service
Souveraineté des données et hébergement
La localisation des données de logs est un point non négociable pour les entités soumises à NIS2, DORA ou traitant des données à caractère personnel. Vérifiez :
- Lieu d’hébergement des logs bruts et des données d’investigation (UE impératif pour la majorité des entités françaises)
- Localisation des équipes d’analystes (délais de réponse, langue de communication)
- Qualification ANSSI : les référentiels PDIS (Prestataires de Détection des Incidents de Sécurité) et PRIS (Prestataires de Réponse aux Incidents de Sécurité) sont les cadres applicables en France pour les prestataires intervenant sur les systèmes des Opérateurs d’Importance Vitale (OIV) et des Opérateurs de Services Essentiels (OSE)
SLA et métriques de performance
| Indicateur | Définition | Seuil recommandé (incidents critiques) |
|---|---|---|
| MTTD (Mean Time to Detect) | Délai entre l’occurrence et la détection | < 1 heure |
| MTTR (Mean Time to Respond) | Délai entre détection et initiation de la réponse | < 4 heures |
| MTTC (Mean Time to Contain) | Délai jusqu’au containment effectif de la menace | < 8 heures |
| Taux de faux positifs | Proportion d’alertes non confirmées comme incidents | A calibrer par périmètre |
| Disponibilité service | Uptime de la plateforme de surveillance | >= 99,5 % |
Le NIST SP 800-61 Rev. 3 (2024) fournit un cadre méthodologique de référence pour qualifier ces métriques dans un contexte d’incident response. Les seuils MTTD/MTTR indiqués correspondent aux attentes pour les incidents de criticité élevée ; ils doivent être calibrés par niveau de criticité dans les annexes SLA.
Intégrations et compatibilité avec l’existant
Un SOC externalisé performant s’intègre dans votre stack existante, pas l’inverse. Vérifiez la compatibilité native avec votre EDR (CrowdStrike, SentinelOne, Microsoft Defender for Endpoint), votre SIEM si vous en disposez déjà, vos outils cloud (AWS Security Hub, Microsoft Defender for Cloud) et votre ITSM (ServiceNow, Jira) pour l’automatisation du workflow d’incidents.
Enjeux contractuels et conformité réglementaire
NIS2 et la chaîne de notification
La directive NIS2 (transposée en droit français par l’ordonnance n°2024-821 du 23 juillet 2024) impose aux entités essentielles et importantes une alerte initiale à l’ANSSI dans les 24 heures suivant la prise de connaissance d’un incident significatif. Le contrat MSSP doit spécifier :
- Les conditions et délais de remontée d’alerte vers le RSSI (bien avant la fenêtre des 24 heures)
- La définition contractuelle d’un “incident significatif” alignée sur les critères NIS2
- Les responsabilités de constitution du dossier d’incident (notification complète à 72 heures, rapport final à 1 mois conformément à l’Art. 23 de la directive)
- La rétention des logs : l’ANSSI recommande 12 mois minimum pour les entités NIS2
DORA pour le secteur financier
Le règlement DORA (applicable depuis le 17 janvier 2025) impose aux entités financières des exigences spécifiques sur les prestataires tiers de services TIC critiques. Un MSSP classifié comme “fournisseur tiers critique” entre dans le périmètre du cadre de surveillance DORA. Les contrats doivent couvrir les droits d’audit, les plans de continuité et les exigences de notification d’incident du règlement.
Clauses de réversibilité
La réversibilité est systématiquement sous-estimée lors de la contractualisation. Prévoyez explicitement : le format d’export des logs historiques, la durée de transition, la restitution des playbooks et règles de détection développés pendant la relation contractuelle, et les conditions d’accès aux données post-résiliation.
Modèle de gouvernance : ce qui reste en interne
L’externalisation du SOC ne supprime pas le besoin d’une fonction sécurité interne. Le RSSI conserve plusieurs responsabilités non délégables :
- Gouvernance et politique de sécurité : définition du périmètre à surveiller, classification des actifs, politique d’escalade
- Qualification des incidents et décision : la validation finale d’un incident majeur et la décision de réponse (déconnexion d’un système de production, activation du PCA) restent internes
- Relation réglementaire : la notification à l’ANSSI, à la CNIL (violation de données) ou à l’ACPR (DORA) est sous la responsabilité de l’entité, pas du MSSP
- Pilotage du prestataire : revue mensuelle des métriques, suivi des indicateurs contractuels, exercices de red team ou purple team conjoints
Un modèle de gouvernance efficace prévoit un interlocuteur dédié côté MSSP (un “Dedicated Analyst” ou équivalent), des sessions de revue opérationnelle régulières avec les équipes internes et un tableau de bord partagé centralisant les KPI contractuels (MTTD, MTTR, taux de faux positifs par source). La sécurité de l’entreprise ne se délègue pas : elle se pilote.
Points de vigilance et pièges fréquents
Le syndrome du “alert forwarding”. Certains MSSP de premier niveau se contentent de transmettre les alertes SIEM sans investigation. Vérifiez que le contrat stipule une analyse humaine sur les alertes de criticité élevée, pas seulement un routage automatisé.
La couverture cloud lacunaire. Les environnements multi-cloud et les workloads Kubernetes génèrent une télémétrie spécifique (runtime security, API calls, configuration drift) que les SIEM traditionnels ingèrent mal. Pour les architectures cloud-native, évaluez spécifiquement la capacité du prestataire à ingérer les logs cloud-native (AWS CloudTrail, Azure Activity Log, GCP Audit Logs), à corréler les événements entre fournisseurs et à couvrir les plans de contrôle Kubernetes. L’absence de cette couverture crée des angles morts sur les vecteurs d’attaque les plus actifs en 2026.
Les périmètres d’exclusion cachés. Relisez attentivement les annexes techniques. Certains contrats excluent par défaut les endpoints non managés, les environnements OT/IoT ou les applications SaaS non listées. Ces exclusions créent des angles morts exploitables par des attaquants qui cartographient le périmètre surveillé.
L’absence de simulation d’adversaire. Un SOC qui ne pratique jamais d’exercice de red team ou de purple team ne peut pas valider l’efficacité réelle de sa couverture MITRE ATT&CK. Exigez au moins un exercice annuel et la preuve documentée des résultats, exprimés en pourcentage de techniques détectées par tactique ATT&CK.
La maturité du marché MSSP/SOCaaS en Europe s’est considérablement renforcée depuis 2023, portée par les obligations NIS2 et la professionnalisation des offres qualifiées ANSSI (PDIS/PRIS). Pour autant, le niveau de qualité reste hétérogène : une évaluation rigoureuse sur la base de critères techniques objectifs, d’un POC en environnement réel et d’une lecture attentive des annexes contractuelles reste indispensable avant tout engagement.