Guide d'achat MDR : choisir un SOC managé français en 2026

Ce guide s'adresse aux RSSI, DSI et directeurs informatiques d'organisations françaises qui envisagent d'externaliser leur détection-réponse à un prestataire de Managed Detection and Response (MDR), c'est-à-dire un service de SOC managé. Il couvre la chaîne de décision complète : pourquoi externaliser, comment distinguer les acteurs souverains des autres, sur quels critères les comparer, comment structurer un appel d'offres et quels pièges éviter. Il s'appuie sur le marché français tel qu'il existe en 2026, avec ses 50 et quelques pure-players, ses qualifications ANSSI (Agence nationale de la sécurité des systèmes d'information) et ses contraintes réglementaires propres — NIS2, DORA, HDS, LPM. En revanche, il ne traite pas de l'opération interne d'un SOC, ni du choix d'un EDR (Endpoint Detection and Response) seul, ni des produits XDR (Extended Detection and Response) en tant que tels. Ces sujets relèvent d'autres décisions et d'autres pages. Concrètement, l'objectif est de vous permettre, après lecture, de dresser une liste courte de 3 à 5 fournisseurs compatibles avec votre profil, de rédiger un cahier des charges qui tient debout, et de lancer une procédure d'achat dans laquelle vous restez en position de comparaison. Pas un guide commercial, donc, mais une méthode de cadrage. Si vous cherchez à benchmarker directement les acteurs, l'annuaire est ici : /fournisseurs. Si vous cherchez à chiffrer un projet, le calculateur de coût est là : /cout-mdr. Ce guide vient en amont des deux.

L'arbitrage entre construire un SOC interne et acheter un service MDR est, pour la majorité des organisations françaises, déjà tranché par les contraintes. La première contrainte est humaine. Le marché français de la cybersécurité affiche, selon les estimations consolidées par l'ANSSI et le syndicat de la profession, un taux de postes vacants proche de 50 % sur les profils d'analystes SOC niveau 2 et 3. Recruter cinq analystes pour tenir une astreinte 24/7 — soit la dotation minimale pour couvrir trois équipes plus une marge de congés — relève, hors grands groupes, de l'exception. La deuxième contrainte est budgétaire. Un SOC interne réellement opérationnel en 24/7 coûte rarement moins de 1,2 million d'euros par an en France, plateforme et CERT exclus. Le sujet est détaillé dans /mdr-vs-soc-interne. La troisième contrainte est réglementaire. NIS2 (directive Network and Information Security 2), transposée en France depuis octobre 2024, impose aux entités essentielles et importantes des obligations de détection et de réponse qu'aucun antivirus ni EDR seul ne couvre. DORA (Digital Operational Resilience Act), en vigueur dans le secteur financier depuis janvier 2025, va plus loin avec des tests de résilience opérationnelle et un reporting d'incident sous 4 heures. Pour les opérateurs d'importance vitale (OIV) et les opérateurs de services essentiels (OSE), la Loi de programmation militaire (LPM) impose en outre le recours à des prestataires qualifiés PDIS (Prestataires de détection d'incidents de sécurité) et PRIS (Prestataires de réponse aux incidents de sécurité). La quatrième contrainte tient à la pression du paysage des menaces. L'ANSSI rapporte, dans son Panorama 2024, une hausse continue des attaques ciblant les ETI françaises, avec un délai moyen entre intrusion initiale et chiffrement (ransomware) descendu sous les 24 heures. Aucune équipe en horaires de bureau ne tient ce tempo. Reste que le MDR n'est pas une réponse miracle. Il n'absorbe pas tous les risques, ne remplace pas une gouvernance cyber claire et n'a de valeur que si l'organisation cliente est capable de prendre des décisions de remédiation rapidement. C'est précisément pour cela qu'il faut le choisir avec soin.

Le marché du SOC managé charrie un vocabulaire technique qui se chevauche, glisse, et qu'il faut clarifier avant toute conversation commerciale. Ce chapitre fixe les définitions utiles pour comprendre la suite du guide et lire les fiches fournisseurs de /fournisseurs sans se perdre. On ne traite ici que ce qui revient dans les RFP (Request For Proposal, c'est-à-dire l'appel d'offres) MDR français. Le reste relève d'autres lectures.

MDR (Managed Detection and Response)

Service managé qui combine surveillance 24/7, détection sur des surfaces critiques (endpoints, identité, cloud, réseau), validation par des analystes humains et capacité de réponse — guidée ou active — sur l'environnement du client. Le MDR repose sur une plateforme moderne (généralement un EDR ou un XDR) et sur une équipe d'analystes en astreinte continue.

MSSP (Managed Security Service Provider)

Prestataire de services de sécurité managés au sens large. Historiquement centré sur l'exploitation d'équipements de sécurité (pare-feu, IDS, SIEM, proxies). Le MSSP gère des outils, le MDR gère un risque. La frontière s'estompe car beaucoup de MSSP historiques montent une offre MDR — la comparaison est détaillée dans /mdr-vs-mssp.

SOC (Security Operations Center)

Centre opérationnel de sécurité. Désigne aussi bien l'équipe (analystes, hunters, ingénieurs détection) que l'organisation qu'elle opère. Un SOC peut être interne (opéré par le client) ou managé (opéré par un prestataire dans le cadre d'un MDR ou d'un MSSP).

EDR (Endpoint Detection and Response)

Outil logiciel installé sur les postes et serveurs. Détecte les comportements suspects et permet une réponse — isolement, kill process, collecte forensique. Sans analyste qui l'opère, un EDR reste un outil. Le couplage EDR + analyste 24/7 est l'une des briques typiques d'un MDR.

XDR (Extended Detection and Response)

Plateforme étendue qui corrèle plusieurs surfaces : endpoint, identité, cloud, e-mail, réseau. Concrètement, un XDR est un produit ; un MDR est un service qui peut s'appuyer sur un XDR.

NDR (Network Detection and Response)

Détection comportementale sur le trafic réseau, par sondes ou analyse de logs. Souvent utilisé en complément de l'EDR sur les périmètres où l'agent n'est pas déployable (OT industriel, équipements legacy).

SIEM (Security Information and Event Management)

Plateforme de collecte, corrélation et stockage des logs de sécurité. Historiquement le cœur du SOC. De nombreux MDR modernes s'appuient sur un XDR plutôt que sur un SIEM, mais le SIEM reste incontournable pour la conformité, le legacy et l'investigation longue durée.

SOAR (Security Orchestration, Automation and Response)

Plateforme d'orchestration et d'automatisation des actions de réponse (isolement, blocage, ticket). Vit en couplage avec un SIEM ou un XDR. Indicateur de maturité opérationnelle chez un MDR.

CERT / CSIRT (Computer Emergency Response Team / Computer Security Incident Response Team)

Équipe spécialisée dans la réponse à incident — investigation forensique, éradication, accompagnement de crise. Le CERT/CSIRT est une brique complémentaire au MDR : le SOC détecte et confine, le CERT prend la suite sur les incidents majeurs.

PASSI

Prestataires d'audit de la sécurité des systèmes d'information. Qualification ANSSI pour les audits techniques et organisationnels. N'est pas une qualification de détection ou de réponse, mais signale une maturité globale du prestataire.

PDIS

Prestataires de détection d'incidents de sécurité. Qualification ANSSI dédiée à la détection. Obligatoire pour les OIV au titre de la LPM. Critère structurant pour tout acheteur soumis à NIS2 ou à des exigences souveraines fortes.

PRIS

Prestataires de réponse aux incidents de sécurité. Qualification ANSSI dédiée à la réponse — investigation, remédiation, gestion de crise. Souvent demandée en complément du PDIS pour disposer d'une chaîne complète de détection puis de réponse.

MTTA / MTTR

Mean Time To Acknowledge / Mean Time To Respond. Indicateurs clés d'engagement d'un MDR. Le MTTA mesure le délai entre la génération d'une alerte et sa prise en compte par un analyste ; le MTTR, le délai jusqu'à confinement effectif. Toujours exiger des valeurs garanties contractuellement, pas des moyennes marketing.

Choisir un MDR sans grille de lecture revient à comparer un Excel chez chaque fournisseur. Sept critères structurent une décision défendable. Aucun n'est secondaire : ils trient les acteurs entre eux et tracent la frontière entre une externalisation maîtrisée et une dépendance subie. Concrètement, chacun de ces critères doit donner lieu, dans votre cahier des charges, à une question fermée et à une réponse écrite — pas à une déclaration commerciale.

1. 01Souveraineté — Premier critère, pas second. La souveraineté se mesure sur trois dimensions cumulatives : l'actionnariat du prestataire (capitaux français, pas filiale de groupe extra-européen), la localisation du SOC qui traite vos données (analystes physiquement en France), et l'hébergement des données dans l'Union européenne avec absence d'exposition à des lois extraterritoriales (Cloud Act américain, notamment). Un MDR opéré depuis Paris mais hébergé sur un cloud non qualifié SecNumCloud n'est pas souverain au sens strict. Pour un OIV ou un OSE soumis à la LPM, c'est rédhibitoire ; pour une ETI soumise à NIS2, c'est un critère de robustesse réglementaire. Voir /conformite/nis2.
2. 02Autorité de réponse — Le MDR doit faire trois choses : détecter, valider, agir. La capacité d'action — isolement d'un endpoint, désactivation d'un compte AD, blocage d'un domaine — peut être active (le MDR exécute), guidée (le MDR propose, le client exécute) ou simple escalade (le MDR alerte, le client se débrouille). La majorité des fournisseurs vendent du « MDR » sans préciser ce qu'ils font vraiment. À clarifier précisément, par surface et par scénario, dans le contrat. Une réponse uniquement guidée est légitime sur un environnement sensible, mais elle change radicalement le niveau de service réel.
3. 03Qualifications ANSSI — PASSI, PDIS, PRIS, SecNumCloud — chacune répond à un besoin précis. PDIS est la qualification pivot pour le SOC managé : elle atteste d'un référentiel rigoureux sur les processus de détection. PRIS couvre la réponse à incident. PASSI signale une maturité d'audit. SecNumCloud qualifie l'hébergement. Un MDR sans PDIS n'est pas inéligible — beaucoup d'excellents acteurs n'en ont pas — mais pour un acheteur LPM, OIV ou candidat NIS2 strict, c'est obligatoire. Ne pas confondre une qualification valide avec un dossier « en cours » : seul un certificat publié sur le site ANSSI fait foi.
4. 04Surfaces couvertes — Endpoint (postes, serveurs), identité (Active Directory, Entra ID), cloud (AWS, Azure, GCP), e-mail, réseau (NDR), OT/industriel, applications web. Chaque MDR a un périmètre de force et des angles morts. Demandez la liste exhaustive des surfaces effectivement couvertes, et précisez le statut : « inclus », « en option payante », « via partenaire », « non couvert ». Une couverture limitée à l'endpoint, sur un environnement où la majorité des compromissions passent par l'identité ou le cloud, laisse une fenêtre ouverte que l'analyste 24/7 ne refermera jamais.
5. 05SLA opérationnels — Le MTTA et le MTTR doivent figurer dans le contrat avec des valeurs chiffrées et des modalités de mesure auditables. Un engagement de « 15 minutes MTTA sur les alertes critiques » sans définition de « critique » et sans pénalité associée n'a aucune valeur opérationnelle. Exigez les définitions, les seuils, les modalités de calcul, les pénalités en cas de non-respect, et les conditions de mesure (heures ouvrées vs 24/7). Demandez aussi le délai d'engagement de réponse humaine — pas seulement la prise en compte automatique.
6. 06Modèle de tarification — Trois grands modèles cohabitent : par poste/mois (lisible, prévisible, dominant chez les acteurs PME et mid-market), par volume de logs ou d'événements (typique des MSSP historiques, opacifie la facture en cas de pic), et au forfait par périmètre (utilisé pour les grands comptes). Méfiez-vous des modèles hybrides à composantes multiples (poste + log + appels au CERT) qui rendent toute comparaison impossible. Demandez systématiquement une simulation sur votre profil réel, voir /cout-mdr et /cout-mdr/couts-caches.
7. 07Transparence opérationnelle — Ce critère est qualitatif mais discriminant. Un MDR mature publie ou partage : un portail client en temps réel avec liste des alertes et statuts d'investigation ; des rapports mensuels exploitables ; un point de contact technique nommé ; des post-mortem d'incident structurés ; une politique d'accès au journal des actions effectuées par les analystes. À l'inverse, un fournisseur qui refuse de communiquer ses runbooks types, ses indicateurs de couverture (MITRE ATT&CK) ou ses compétences d'équipe n'est pas un partenaire opérationnel : c'est une boîte noire.

Un appel d'offres MDR mal structuré aboutit à des réponses incomparables, à un POC mal cadré et à un contrat déséquilibré. La méthode qui suit s'appuie sur les pratiques observées chez les RSSI d'ETI et de grands comptes français ayant mené plusieurs cycles de remise en concurrence sur leur SOC managé. Six étapes, dans cet ordre.

1. 011. Définir le périmètre — Avant tout contact fournisseur, écrivez noir sur blanc : nombre de postes, nombre de serveurs (Windows / Linux / Mac), nombre de comptes identités, plateformes cloud utilisées, surfaces sensibles (OT, e-commerce, R&D), volumétrie estimée de logs, contraintes réglementaires applicables (NIS2, DORA, HDS, LPM), périmètre géographique. Ce document fait 2 à 4 pages, et il est partagé tel quel à tous les fournisseurs consultés. Sans périmètre écrit, la suite ne tient pas.
2. 022. Établir une liste courte — Filtrez les acteurs sur des critères durs : souveraineté requise oui/non, qualifications ANSSI exigées, présence d'une référence vérifiable dans votre secteur, capacité technique sur votre stack EDR actuelle (si applicable). Visez 5 à 8 fournisseurs en liste longue, puis 3 à 5 en liste courte après un premier filtre documentaire. L'annuaire /fournisseurs permet ce filtrage rapide ; les pages /secteur/[slug] et /conformite/[slug] aident à cibler par profil.
3. 033. Cahier des charges structuré — Le cahier des charges doit poser des questions fermées, à réponse écrite, sur les sept critères du chapitre précédent. Une grille typique compte 60 à 100 questions regroupées en sections : périmètre, souveraineté, qualifications, surfaces, autorité de réponse, SLA, tarification, transparence, références. Chaque question attend une réponse oui / non / partiel + commentaire libre limité. Cette discipline rend les réponses comparables ligne à ligne. Un cahier des charges en format narratif libre garantit des réponses commerciales et inexploitables.
4. 044. POC structuré — Le proof of concept est l'étape qui sépare le marketing de la réalité. Durée recommandée : 30 à 60 jours, jamais moins. Périmètre : un sous-ensemble représentatif (10 à 20 % du parc), incluant au moins une surface identité et une surface cloud. Conditions : scénarios d'attaque injectés (red team interne ou équivalents), suivi des MTTA / MTTR mesurés, audit du portail client, entretien avec les analystes affectés au POC. Refusez les POC purement démonstratifs sur environnement de laboratoire — ils ne disent rien de la prestation réelle.
5. 055. Audit des références — Exigez 3 références clientes vérifiables, idéalement dans votre secteur et de taille comparable. Programmez un entretien direct, sans le commercial du fournisseur. Posez des questions précises : depuis combien de temps êtes-vous client, avez-vous vécu un incident majeur, comment le MDR a-t-il réagi, le contrat a-t-il été renouvelé, qu'est-ce qui vous fait rester ou partir. Les fournisseurs sérieux fournissent ces références sans difficulté ; les autres tergiversent.
6. 066. Négociation et signature — Le contrat fixe les SLA chiffrés, le périmètre exact, les conditions de réversibilité (récupération des données et des règles de détection en cas de sortie), la durée d'engagement, les conditions d'évolution du périmètre, les pénalités, les clauses de confidentialité et la conformité RGPD. Une attention particulière sur la clause de réversibilité : un MDR qui rend la sortie coûteuse ou impossible n'est pas un partenaire, c'est une cage. Faites relire le contrat par un juriste familier des contrats IT, pas par votre service achats général.

Ces pièges reviennent dans la majorité des cycles d'achat MDR observés en France. Aucun n'est anecdotique : chacun a déjà coûté à des organisations clientes des mois de relation dégradée, des sorties contractuelles compliquées ou, dans les cas les plus graves, une couverture de sécurité illusoire pendant un incident réel. Les repérer en amont change la qualité de la décision.

1. 01Plateforme imposée déguisée — Le fournisseur présente une offre « ouverte sur votre stack », mais le contrat précise que la facturation et le service ne fonctionnent que sur sa plateforme XDR propriétaire ou sur un EDR partenaire imposé. Vérifiez le statut BYO (Bring Your Own) : véritable BYO sur votre stack actuelle, BYO sur une short-list de plateformes éligibles, ou plateforme imposée sans alternative. Voir /techno pour cartographier le sujet par technologie.
2. 02MTTA non garanti contractuellement — Le commercial annonce « 5 minutes de prise en compte ». Le contrat parle d'engagement « best effort » sur les alertes critiques, sans pénalité. Aucune garantie réelle, donc. Exigez : valeur chiffrée, périmètre d'alertes concerné, modalité de mesure (avec preuve auditable), pénalité associée. Sans ces quatre éléments, le MTTA est un argument marketing, pas un engagement.
3. 03Scope flou sur les surfaces secondaires — Le contrat couvre l'endpoint. Le commercial évoque « bien sûr aussi l'identité et le cloud ». Lecture attentive du contrat : ces surfaces sont « disponibles en option » ou « en cours d'extension ». Au moment d'un incident sur Azure, le périmètre contractuel ne couvre rien. Liste exhaustive demandée par écrit, statut documenté pour chaque surface (inclus / option / via partenaire / non couvert).
4. 04Tarification d'appel anormalement basse — Une offre 3 €/poste/mois pour un MDR 24/7 souverain n'existe pas. Le coût analyste seul rend le modèle impossible sous 6 à 8 €/poste/mois pour un service réellement opéré en France. Une offre très basse cache : un service opéré offshore, une couverture limitée aux heures ouvrées avec astreinte minimale la nuit, une plateforme imposée avec marges arrière, ou un modèle de volume qui explosera à la première vague de logs. Demandez une simulation détaillée sur votre profil — voir /cout-mdr.
5. 05Placeholders dans la réponse au RFP — Réponses qui recyclent un texte générique : « notre SOC d'excellence, leader européen, opère 24/7… » sans répondre précisément à la question posée. Ce sont des signaux de désintérêt pour votre dossier ou de capacité commerciale industrielle qui ne traduit pas une capacité opérationnelle équivalente. Notez chaque réponse hors-sujet comme un point négatif au scoring final.
6. 06Absence de qualification ANSSI vérifiée — Le commercial déclare le PDIS « en cours » depuis 2 ans. Aucune qualification valide à ce jour. Pour un acheteur sous LPM ou en posture NIS2 stricte, c'est rédhibitoire à court terme. Vérifiez sur le site officiel de l'ANSSI la liste à jour des qualifiés ; aucune autre source ne fait foi. Voir /conformite/lpm.
7. 07Pas de clause de réversibilité claire — Le contrat ne précise pas comment vous récupérez vos données, vos règles de détection sur mesure, vos workflows d'investigation en cas de sortie. Le coût de sortie n'est pas chiffré. Vous êtes captif. Exigez une clause de réversibilité standard, avec délais, livrables et coûts plafonnés. Les fournisseurs matures la fournissent sans difficulté.

Le budget MDR varie d'un facteur 10 selon le profil, ce qui rend toute moyenne marketing inutilisable. Quelques fourchettes ancrent les décisions, en sachant qu'elles s'entendent hors coûts de mise en service et hors CERT externe. Pour une PME de 50 à 200 postes soumise à NIS2 en entité importante, un MDR souverain pure-player se situe typiquement entre 8 et 15 €/poste/mois, soit 5 000 à 35 000 € par an selon la taille du parc. Le service couvre alors endpoint et identité, avec une autorité de réponse guidée ou active selon le fournisseur. Pour une ETI de 500 à 2 000 postes en posture NIS2 entité essentielle ou DORA, la fourchette monte à 12 à 25 €/poste/mois, soit 70 000 à 600 000 € par an. La couverture inclut généralement endpoint, identité, cloud, et un threat hunting structuré. Pour un OIV soumis à la LPM, avec PDIS et PRIS, le coût se situe entre 25 et 60 €/poste/mois, hors CERT, soit plusieurs centaines de milliers d'euros à plusieurs millions selon le périmètre. Pour un opérateur santé sous HDS, ajoutez 20 à 40 % sur la base ETI pour couvrir les contraintes d'hébergement et de traçabilité. Pour une banque sous DORA avec exigences de tests de résilience, prévoyez un budget proche du profil OIV. Le calculateur /cout-mdr permet une simulation détaillée sur votre profil. Pour comprendre les coûts qui n'apparaissent pas dans la base affichée — onboarding, intégration EDR, CERT externe, formation, projets de durcissement — voir /cout-mdr/couts-caches.

Le tableau ci-dessous croise les profils types et les familles d'acteurs adaptées. Il ne dit pas qui choisir nominativement, mais oriente la liste courte. Le passage d'une famille à une autre se joue sur les sept critères du chapitre 03 et sur les contraintes réglementaires de votre secteur. Pour les profils complexes — multinationales avec contraintes multiples, filiales en consolidation, fusions en cours — la matrice est un point de départ, jamais une réponse définitive. Affinez en croisant avec les pages /secteur/[slug] et /conformite/[slug] propres à votre activité.

La méthode de ce guide n'a de valeur que si elle se traduit en action. Concrètement, quatre étapes pour démarrer. D'abord, explorer la liste des fournisseurs sur /fournisseurs en activant les filtres pertinents pour votre profil — souveraineté, qualifications, secteur, technologie. Cette première sélection prend 30 minutes et réduit le marché à une dizaine d'acteurs candidats. Ensuite, lire 3 à 5 fiches détaillées pour comprendre les spécificités de chaque acteur — surface couverte, autorité de réponse, modèle économique. Ces lectures prennent une demi-journée et permettent d'identifier les 5 fournisseurs à consulter en liste courte. Puis, calculer un ordre de grandeur budgétaire sur /cout-mdr pour cadrer la conversation interne avec la direction financière. Enfin, structurer un cahier des charges selon la méthode du chapitre 04, puis lancer la consultation. Pour les organisations qui n'ont pas la bande passante interne pour mener cette procédure, des cabinets de conseil indépendants — distincts des fournisseurs — proposent un accompagnement à l'achat. Soc-manage.fr ne vend pas ce conseil et n'a aucun lien commercial avec les fournisseurs cités. L'annuaire et les guides sont financés par un modèle d'apport d'affaires transparent, sans rémunération conditionnée à la sélection d'un acteur particulier.

Le choix d'un MDR engage votre organisation sur 3 à 5 ans, parfois plus. C'est une décision structurante au même titre qu'un choix de SIRH ou d'ERP, et elle ne se rattrape pas facilement. La méthode présentée dans ce guide — cadrer le périmètre, fixer une grille de sept critères, structurer un RFP rigoureux, sécuriser le contrat par une clause de réversibilité — ne garantit pas la meilleure offre, mais elle garantit une décision défendable. Reste que la qualité de l'externalisation tient autant à la qualité du prestataire qu'à la maturité du commanditaire. Un MDR n'absorbe pas l'absence de gouvernance cyber, ne suppléé pas un manque de décideur capable de trancher en quelques heures lors d'une crise, ne corrige pas une infrastructure non documentée. Avant de signer, vérifiez aussi votre propre côté de la table. Pour explorer le marché : /fournisseurs. Pour comparer les écosystèmes par technologie : /techno. Pour cadrer le budget : /cout-mdr.