Trois objections, une seule origine
Si Microsoft Intune est déjà déployé mais que la sécurité des postes repose sur un antivirus tiers, la question du passage à Microsoft Defender revient tôt ou tard. Trois arguments reviennent systématiquement chez les administrateurs qui hésitent à franchir le pas :
- « Mon EDR tiers fait déjà le travail, pourquoi tout changer ? »
- « Que se passe-t-il pendant la bascule, existe-t-il une fenêtre sans protection ? »
- « Je gère Windows, macOS, Linux et des serveurs, je n'ai pas la bande passante pour ce chantier. »
Ces trois positions partent du même constat : Intune gère déjà le parc, mais la couche endpoint security reste externe, parfois installée avant même l'arrivée d'Intune dans l'environnement. Cet article répond aux trois objections avec des faits techniques, que vous soyez sur Microsoft Defender for Business (PME) ou sur Microsoft Defender for Endpoint à l'échelle d'une grande organisation.
Périmètre de l'article
Cet article traite de la décision stratégique de migrer. Le détail pas à pas des politiques Intune, des règles de réduction de la surface d'attaque et du séquencement complet par plateforme fait l'objet d'un traitement plus poussé dans un futur article dédié.
Pourquoi remplacer un antivirus tiers qui « fait le travail »
L'argument de la redondance — « je ne mets pas tous mes œufs dans le même panier » — inverse en réalité la logique de risque. Un antivirus tiers connecté à Intune via un connecteur ajoute des couches de traduction et des points de rupture potentiels dans la chaîne de détection. Avec Microsoft Defender nativement intégré à Intune, détection, conformité et application des politiques appartiennent au même flux, sans hand-off manuel.
La différence n'est pas seulement une histoire d'intégration plus fluide. Elle porte sur une capacité que la plupart des solutions tierces n'offrent pas : la défense proactive pendant une attaque active, capable de bloquer le déplacement latéral d'un attaquant avant qu'il ne cause de dégâts. Microsoft avance un délai moyen de 30 secondes pour stopper une propagation de ransomware une fois la détection déclenchée — une position marketing, certes, mais qui s'appuie sur une architecture réelle.
Voici le déroulé d'un scénario concret :
- Un utilisateur ouvre un e-mail de phishing et exécute un script malveillant.
- Microsoft Defender détecte une anomalie comportementale et marque l'appareil comme suspect.
- L'état de conformité de cet appareil dans Intune bascule automatiquement en non conforme.
- Les stratégies d'accès conditionnel de Microsoft Entra ID détectent l'appareil non conforme tentant d'accéder à Exchange Online ou SharePoint, et bloquent l'accès.
Aucun ticket au support, aucune intervention manuelle. La boucle se referme d'elle-même, de la détection jusqu'au blocage. Avec un connecteur tiers, la détection a bien lieu, mais le relais vers l'application de la politique traverse davantage d'étapes — et dans un incident réel, chaque étape supplémentaire est du temps perdu.
| Critère | Antivirus tiers + connecteur Intune | Microsoft Defender natif + Intune |
|---|---|---|
| Chaîne détection → conformité | Passe par un connecteur, plusieurs hand-offs | Flux automatisé de bout en bout |
| Application de l’accès conditionnel | Délai lié aux étapes intermédiaires | Boucle fermée, sans intervention manuelle |
| Défense pendant une attaque active | Dépend de l’éditeur tiers | Blocage proactif du pivot attaquant |
| Console unique multiplateforme | Souvent fragmentée par OS | Une console pour Windows, macOS, Linux, serveurs |
Migrer sans zone de vulnérabilité
La crainte d'une fenêtre non protégée pendant la transition est légitime, mais elle repose sur une mauvaise compréhension du mécanisme de bascule. Microsoft Defender ne remplace jamais brutalement un antivirus existant : il détecte automatiquement la présence d'une solution tierce active et se place en mode passif. L'AV tiers reste le moteur de scan principal, sans aucun changement visible pour l'utilisateur.
Déployer Defender en mode passif via Intune
Le déploiement cible les appareils par une politique d'onboarding EDR (Endpoint Detection and Response). Tant qu'un antivirus tiers actif est détecté, Defender reste passif : il collecte des signaux sans intervenir en scan.
Configurer les politiques Defender dans Intune
Il ne s'agit pas de migrer d'anciennes règles, mais de repartir d'une base propre. Les security baselines d'Intune fournissent des recommandations préconfigurées et testées. Des modèles orientés scénario couvrent l'antivirus, l'EDR et les règles de réduction de la surface d'attaque (Attack Surface Reduction).
Valider avant coupure
L'AV tiers reste actif pendant toute cette phase de validation. Aucune coupure de protection n'intervient, quel que soit le temps nécessaire pour tester la configuration.
Désinstaller l'antivirus tiers
Une fois la configuration validée, la désinstallation du produit tiers déclenche automatiquement le passage de Defender en mode actif. Le poste reste protégé à chaque instant de la transition.
L'image la plus parlante reste celle d'un changement de société de gardiennage : la nouvelle équipe est déjà formée et en poste avant que l'ancienne ne rende les clés. Le bâtiment n'est jamais sans surveillance.
Ressource officielle
Le guide de bascule vers Microsoft Defender séquence chaque étape, du mode passif à la désinstallation finale, pour éviter les migrations qui traînent par excès de prudence.
Couvrir tout le parc multiplateforme depuis une seule console
La fatigue de gérer Windows, macOS, Windows Server, macOS Server et Linux Server avec des outils disparates est un problème réel, souvent aggravé par l'historique : les postes macOS restent parfois totalement dépourvus de protection parce que « personne n'y a pensé », ou chaque OS tourne avec un produit différent, sans vision consolidée.
Intune et Microsoft Defender couvrent désormais la configuration des politiques et le reporting sur l'ensemble de ces plateformes depuis une console unique :
- Appareils onboardés via Defender attach (rattachement direct à Defender).
- Appareils onboardés via une politique Intune.
- Mêmes schémas de configuration et de visualisation des détections, quel que soit l'OS.
L'onboarding lui-même reste simple : cibler une politique d'onboarding EDR Defender via Intune, puis vérifier que l'état d'onboarding passe au vert dans la console. Pas d'intervention appareil par appareil. Une fois onboardés, les security baselines couvrent le cas standard, tandis que les modèles orientés scénario (politique antivirus, configuration EDR, règles ASR) permettent d'aller plus loin, toujours depuis la même interface.
Microsoft publie également un guide de déploiement dédié Defender + Intune, structuré et séquencé par plateforme — à distinguer d'une documentation générique éclatée sur plusieurs pages Learn.
Controlled configuration : un atout pour les environnements multi-tenant
Une capacité récente mérite l'attention des prestataires gérant plusieurs tenants clients : la controlled configuration. Elle permet de verrouiller un ensemble validé de paramètres de sécurité Defender, de façon à empêcher toute modification locale sur l'appareil ou via une politique locale concurrente.
Une fois défini, ce verrouillage s'applique de façon cohérente à travers les tenants gérés. Pour tout MSP (Managed Service Provider) ayant déjà constaté qu'un paramètre de sécurité critique avait été discrètement désactivé chez un client, cette fonctionnalité comble une lacune opérationnelle concrète.
Vérifier la licence avant de généraliser
Les capacités de sécurité proactive décrites ici (défense pendant une attaque active, boucle fermée avec l'accès conditionnel) dépendent du niveau de licence Microsoft Defender for Endpoint (Plan 1 ou Plan 2) ou Defender for Business déployé. Vérifiez le niveau de fonctionnalités couvert par votre licence actuelle avant de dimensionner un projet de migration.
Points clés à retenir
- Ian (redondance perçue) : l'intégration native Defender + Intune n'ajoute pas seulement de la cohérence, elle ouvre une catégorie de protection différente — la défense proactive pendant une attaque active, avec une boucle détection → conformité → accès conditionnel entièrement automatisée.
- Jason (peur de la coupure) : il n'existe pas de fenêtre sans protection. Defender démarre en mode passif tant que l'AV tiers est actif, et ne bascule en mode actif qu'après désinstallation de ce dernier.
- Neil (fatigue multiplateforme) : Windows, macOS, Linux et leurs variantes serveur se pilotent depuis une console unique, avec des security baselines et des modèles scénario réutilisables sur l'ensemble du parc.
- La controlled configuration verrouille les paramètres de sécurité validés à travers plusieurs tenants, un vrai plus pour les environnements MSP.
La prochaine étape logique consiste à dérouler ce projet en environnement de test : onboarder un lot pilote via une politique Intune, valider le mode passif, puis appliquer une security baseline avant d'envisager une bascule à l'échelle du parc.
