Définitions sans jargon
Les trois acronymes circulent depuis plusieurs années dans la communication des éditeurs et des intégrateurs. Leur sens technique demeure stable, mais leur usage commercial s’est brouillé. Une remise au clair s’impose.
EDR : Endpoint Detection and Response. Il s’agit d’un outil technique installé sur les terminaux (postes de travail, serveurs, certains équipements mobiles). Cet outil collecte la télémétrie d’exécution (processus, connexions réseau, fichiers ouverts, modifications du registre, élévations de privilège), la confronte à des signatures et à des modèles comportementaux, génère des alertes et propose des actions de réponse au niveau du poste (isolement réseau, suppression d’un processus, restauration d’un fichier).
MDR : Managed Detection and Response. Il s’agit d’un service géré fourni par un prestataire spécialisé. Le prestataire opère des analystes en équipes 24/7, exploite les outils techniques (EDR, SIEM, XDR), trie les alertes, qualifie les incidents, propose ou conduit les actions de réponse selon le périmètre contractuel, et alimente l’entité en rapports et indicateurs. Le service MDR est une réponse organisationnelle, pas un produit technique.
XDR : eXtended Detection and Response. Il s’agit d’une plateforme qui agrège et corrèle des signaux provenant de plusieurs sources : endpoint, identité (annuaires et fournisseurs SSO), cloud (IaaS et SaaS critiques), courrier électronique, réseau. La promesse du XDR est la corrélation : une plateforme XDR doit pouvoir relier un événement endpoint à un événement d’authentification, à un événement cloud et à un événement courrier, pour reconstituer la chaîne d’attaque.
Ces trois objets ne sont pas substituables. Un EDR sans analystes 24/7 produit des alertes qui ne sont pas exploitées la nuit. Un MDR sans EDR ne dispose pas de la télémétrie pour détecter. Un XDR sans personnes pour interpréter les corrélations devient un tableau de bord coûteux.
Ce que chacun fait réellement
| Dimension | EDR | XDR | MDR |
|---|---|---|---|
| Nature | Outil logiciel | Plateforme | Service géré |
| Couverture | Endpoints (postes, serveurs) | Endpoint + identité + cloud + courrier + réseau | Dépend de l’outil exploité |
| Modèle d’achat | Licence par poste | Licence plateforme + connecteurs | Abonnement service |
| Prérequis interne | Équipe sécurité opérationnelle | Maturité SIEM ou équivalent | Sponsoring direction |
| Couverture horaire | Selon l’organisation | Selon l’organisation | 24/7 contractuel |
| Complexité de déploiement | Modérée | Élevée | Modérée à élevée (intégration) |
| Délégation possible | Faible (outil) | Faible (plateforme) | Élevée (service) |
| Conformité NIS2 / ReCyF | Brique nécessaire | Brique optionnelle | Réponse possible à la 24/7 |
Cette table met en évidence un point fondamental : EDR et XDR sont des outils, MDR est un service. Comparer un outil et un service comme s’ils étaient interchangeables conduit à des erreurs d’investissement.
EDR : profondeur sur le poste
Un EDR moderne combine quatre fonctions techniques principales [1].
Collecte continue de télémétrie. L’agent EDR installé sur le poste observe en permanence les événements système : création de processus, ouverture de fichiers, connexions réseau sortantes, modifications du registre Windows ou des configurations Linux, élévations de privilège. Cette télémétrie est centralisée vers le serveur EDR pour analyse.
Détection par signatures et par comportements. Le moteur de détection combine deux approches. Les signatures, héritées de la logique antivirus, identifient les codes malveillants connus. Les modèles comportementaux, plus récents, repèrent des séquences d’événements caractéristiques d’une attaque, indépendamment de la signature du code utilisé. La détection par comportements est particulièrement utile face aux outils légitimes détournés (PowerShell, certutil, mshta).
Investigation à distance. Une fois une alerte générée, l’analyste peut interroger en temps réel le poste suspect pour vérifier la persistance, examiner les processus actifs, récupérer un échantillon de fichier suspect, et reconstituer la chronologie des événements. Cette capacité d’EDR live response est devenue un critère de sélection central.
Réponse au niveau du poste. L’EDR permet des actions de réponse exécutées sur le poste lui-même : isolement du poste du réseau tout en maintenant la connexion à la console de gestion, tuer un processus malveillant, supprimer un fichier, restaurer une clé de registre modifiée, exécuter un script de remédiation.
Le critère de différenciation entre EDR du marché en 2026 porte moins sur la qualité de la détection (les leaders sont sensiblement équivalents) que sur la richesse de la télémétrie collectée, la rétention des données, la capacité d’investigation rétrospective et la qualité des intégrations avec les autres outils (SIEM, XDR, SOAR).
XDR : largeur d’attaque corrélée
Le XDR répond à une limite structurelle de l’EDR : la majorité des attaques sophistiquées n’est pas confinée à l’endpoint. Une intrusion typique en 2026 combine un hameçonnage par courrier, une authentification compromise sur un fournisseur d’identité, une élévation de privilège dans le cloud, une persistance sur un poste de travail et une exfiltration via un canal réseau légitime.
Un EDR observe le poste. Un journal de courrier observe le mail. Un journal d’identité observe les authentifications. Un journal cloud observe les actions sur l’IaaS. Sans corrélation, chaque silo ne voit qu’un fragment de l’attaque. Le XDR comble cette lacune en agrégeant les sources et en appliquant des règles de corrélation [2].
Les sources couvertes par un XDR mature incluent :
- Endpoint : télémétrie EDR.
- Identité : journaux d’authentification, événements MFA, anomalies de comportement utilisateur (UEBA).
- Cloud : journaux IaaS (AWS CloudTrail, Azure Activity Log, GCP Audit Logs), journaux SaaS critiques (Microsoft 365, Google Workspace).
- Courrier : alertes des passerelles anti-hameçonnage, indicateurs de compromission liés à des pièces jointes.
- Réseau : flux NDR (Network Detection and Response), journaux de pare-feu, télémétrie DNS.
La promesse du XDR n’est pas la collecte (un SIEM le fait depuis vingt ans) mais la corrélation native, c’est-à-dire la capacité à présenter à l’analyste une vue unifiée d’une chaîne d’attaque, plutôt qu’une succession d’alertes isolées à corréler manuellement.
Le déploiement d’un XDR exige une maturité préalable. Une entité sans EDR, sans collecte centralisée des journaux d’identité et sans visibilité cloud minimale ne tire pas de valeur d’un XDR. À l’inverse, une entité disposant déjà d’un SIEM opérationnel doit évaluer si le XDR remplace, complète ou rationalise son SIEM existant.
MDR : le service humain 24/7
Le MDR est la réponse organisationnelle au principal défi opérationnel de la cybersécurité en 2026 : la rareté des analystes qualifiés et la difficulté de constituer en interne une équipe de trois équipes capable d’assurer une couverture continue.
Un service MDR fournit, contre un abonnement, les composantes suivantes [3].
Une équipe d’analystes en équipes 24/7. L’entité bénéficie d’une couverture continue sans avoir à recruter, former, fidéliser et gérer la rotation des équipes nuit. Les analystes sont mutualisés entre plusieurs clients, ce qui rend le modèle économiquement soutenable.
Le triage des alertes. Le prestataire reçoit les alertes générées par les outils (EDR, XDR, SIEM) et les trie selon une matrice de gravité contractuelle. Les faux positifs sont éliminés au plus tôt. Les incidents confirmés sont escaladés vers l’entité avec un contexte d’investigation.
La réponse à incident. Selon le périmètre contractuel, le prestataire conduit ou propose les actions de réponse : isolement de postes, blocage de comptes compromis, communication avec l’entité pour les décisions sensibles, coordination avec le CERT-FR.
Le threat hunting. Au-delà de la réponse aux alertes, le prestataire conduit des campagnes de recherche proactive de menaces dormantes, à partir d’hypothèses (TTP MITRE ATT&CK, indicateurs de compromission sectoriels, vulnérabilités récemment publiées).
Le reporting et les indicateurs. Le prestataire fournit des rapports mensuels et trimestriels, avec des indicateurs de performance (temps moyen de détection, temps moyen de réponse, volume d’alertes traitées, incidents qualifiés).
Ce qui n’est généralement pas délégué au MDR : la communication réglementaire (notification CNIL, CERT-FR, ACPR), la communication interne et externe en cas de crise, la décision sur les actions susceptibles d’impacter le métier (couper un service en production), et la conservation des preuves pour une éventuelle action judiciaire. Ces éléments restent de la responsabilité du RSSI et de la direction.
La séquence recommandée en 2026
Pour une entité partant d’un niveau de maturité moyen, une trajectoire en trois temps fait consensus.
Étape 1 : EDR moderne sur tous les endpoints. C’est la brique technique de base, sans laquelle aucune détection sérieuse n’est possible en 2026. Le déploiement doit couvrir 100 % des postes et serveurs, y compris les serveurs Linux et les machines virtuelles dans le cloud. Le ticket d’entrée est modéré et le retour sur investissement est immédiat.
Étape 2 : couche XDR quand la maturité l’exige. Une fois l’EDR opérationnel et la collecte centralisée des principaux journaux mise en place, l’évaluation d’un XDR devient pertinente. La décision dépend de la diversité des sources à corréler, de la complexité de l’infrastructure (multi-cloud, multi-IdP) et de la capacité d’une équipe à exploiter une plateforme avancée.
Étape 3 : MDR ou MXDR pour exploiter 24/7. L’externalisation de la couverture continue devient la voie de conformité la plus accessible pour les entités qui ne peuvent pas constituer un SOC interne complet. Le terme MXDR (Managed XDR) désigne un service MDR qui exploite spécifiquement une plateforme XDR, par opposition à un MDR centré sur l’EDR seul.
Cette séquence n’est pas universelle. Une grande entreprise dotée d’un SOC interne mature peut sauter l’étape MDR. Une PME peut commencer directement par un MDR clé en main qui embarque l’EDR dans son offre. Le principe à retenir est l’ordre logique : la télémétrie d’abord, la corrélation ensuite, le service de pilotage en dernier.
Ce que NIS2 et ReCyF ANSSI exigent
La directive NIS2 et le ReCyF publié par l’ANSSI le 17 mars 2026 imposent un résultat opérationnel : une capacité de détection 24/7, une qualification structurée, une notification au CERT-FR sous 24 puis 72 heures, et un plan de réponse formalisé [4]. Nous analysons en détail le référentiel dans notre article ReCyF ANSSI : le référentiel cybersécurité 2026.
Le ReCyF n’impose pas un choix entre EDR, XDR ou MDR. Il fixe une exigence de résultat et énumère plusieurs voies d’atteinte : SOC interne, SOC externalisé, modèle hybride, SOC mutualisé sectoriel. Le RSSI doit donc, à partir du résultat attendu, construire une architecture combinant outils et services qui convient à son contexte. Notre guide NIS2 entreprise 2026 détaille les obligations applicables aux entités essentielles et importantes.
Critères de choix d’un MDR fiable
La sélection d’un prestataire MDR ne se réduit pas à un comparatif tarifaire. Six critères structurants doivent guider la décision.
Transparence du playbook. Le prestataire doit pouvoir présenter ses playbooks de qualification et de réponse, ses critères d’escalade, et les seuils de notification au client. L’opacité sur ces points est rédhibitoire.
SLA de réponse. Les engagements contractuels doivent inclure un temps maximal entre la génération d’une alerte critique et la prise en charge par un analyste. Un SLA crédible se mesure en minutes, pas en heures.
Géographie des analystes. Pour les entités assujetties à NIS2 ou DORA, la localisation des analystes en Union européenne est un critère de souveraineté et de conformité. Certains référentiels (SecNumCloud, qualification PDIS) imposent cette localisation.
Intégration avec l’EDR existant. Le prestataire doit pouvoir exploiter l’EDR déjà déployé par l’entité, sans imposer une migration vers son propre outil. À défaut, l’entité se retrouve captive du prestataire.
Qualification PDIS ou équivalent. L’ANSSI maintient un dispositif de qualification des prestataires de détection d’incidents de sécurité (PDIS) [5]. Cette qualification, sans être obligatoire, constitue un signal de qualité reconnu et facilite la justification du choix devant les auditeurs.
Plan de sortie. Le contrat doit prévoir la réversibilité : restitution des règles de détection personnalisées, transfert de l’historique d’incidents, accompagnement à la transition. L’absence de plan de sortie est un signal d’alerte.
Pièges fréquents
Trois erreurs reviennent régulièrement dans les retours d’expérience.
Confondre MDR et SOC interne. Un MDR n’exonère pas l’entité de disposer en interne d’au moins un RSSI ou un responsable sécurité capable de prendre les décisions opérationnelles, d’assurer la communication réglementaire, et d’arbitrer en cas d’incident majeur. Le MDR fournit la détection et le triage, pas la décision.
Sous-estimer la phase d’onboarding. L’intégration d’un service MDR exige typiquement trois à six mois entre la signature du contrat et la pleine opérationnalité. Cette phase couvre la connexion des sources de télémétrie, la calibration des règles de détection, la rédaction des playbooks personnalisés, et la conduite des premiers exercices. Une mise en production prématurée génère du bruit et de la frustration.
Absence de plan de sortie. Une dépendance technique et organisationnelle s’installe rapidement avec un prestataire MDR. Sans clause de réversibilité contractuelle et sans documentation des règles et playbooks, le changement de prestataire devient impossible ou prohibitivement coûteux.
Le rôle du SIEM dans l’équation
Le SIEM (Security Information and Event Management) n’apparaît pas dans le titre du présent comparatif, mais il occupe une place réelle dans l’architecture de détection-réponse en 2026. Trois positionnements coexistent.
SIEM autonome, sans XDR. L’entité collecte les journaux de toutes les sources dans un SIEM (Splunk, Elastic, Microsoft Sentinel, IBM QRadar, autres), écrit ses propres règles de corrélation, et les exploite via une équipe SOC. Ce modèle, historiquement dominant dans les grandes organisations, reste pertinent pour les entités disposant d’une équipe SOC mature et d’un besoin de personnalisation poussée des règles.
XDR sans SIEM. L’entité fait le choix d’un XDR comme couche principale de corrélation, sans SIEM séparé. Ce modèle simplifie l’architecture et réduit les coûts de licence, au prix d’une dépendance plus forte à un éditeur unique et d’une moindre flexibilité sur les règles personnalisées.
SIEM et XDR combinés. L’entité conserve un SIEM pour la conformité (rétention longue durée, requêtes ad hoc, sources non standard) et adopte un XDR pour la détection-réponse opérationnelle. Ce modèle hybride est désormais fréquent dans les grandes organisations, au prix d’une complexité d’intégration.
Le choix dépend principalement de la maturité préexistante, du budget, et des contraintes de rétention longue durée (certains secteurs réglementés imposent une conservation des journaux supérieure à ce que propose un XDR du marché).
Convergence MXDR : le service complet
Le terme MXDR (Managed XDR) désigne une offre de service qui combine la fourniture d’une plateforme XDR (logiciel) et son exploitation par une équipe d’analystes 24/7 (service). Le client achète un résultat opérationnel sans avoir à acquérir séparément l’outil et le service. Cette convergence s’est accélérée en 2025-2026, sous la pression de la demande des entités essentielles confrontées au calendrier NIS2.
L’avantage du MXDR est la cohérence : les analystes maîtrisent la plateforme qu’ils opèrent, les règles de détection sont optimisées en continu sur la base de la base installée multi-clients, et le client est exonéré de la complexité d’intégration. L’inconvénient est la dépendance accrue à un fournisseur unique pour à la fois l’outil et le service, ce qui pose la question du plan de sortie avec une acuité particulière.
Références
[1] NIST, SP 800-207 et publications connexes sur la détection et la réponse. [2] ENISA, publications sur la détection des incidents et la réponse. [3] ANSSI, référentiel de qualification PDIS (Prestataires de détection d’incidents de sécurité). [4] Article 21 et article 23 de la directive (UE) 2022/2555 (NIS2) ; ReCyF ANSSI, chapitres 1 et 4. [5] CIS Controls v8, contrôles 8 (Audit Log Management) et 13 (Network Monitoring and Defense).