« Antimalware Service Executable » : CPU élevé — corrigez-le sans désactiver la sécurité

Ce qu’est réellement Antimalware Service Executable (et pourquoi il provoque des pics)

Antimalware Service Executable est le moteur d’antivirus Windows Defender s’exécutant comme service. Le nom du processus que vous verrez habituellement est MsMpEng.exe. Il effectue l’analyse en temps réel, l’analyse à la demande, les analyses planifiées et des tâches de maintenance en arrière-plan comme la mise à jour des signatures et la gestion des caches.

Une utilisation élevée du processeur survient lorsque Defender effectue un travail coûteux :

• Analyse d’un grand nombre de petits fichiers (dossiers de développeur, caches de paquets, magasins de mails).
• Analyse de gros conteneurs compressés/virtualisés (ZIP, ISO, VHD/VHDX, couches de conteneurs).
• Interception de chemins I/O très sollicités où des fichiers sont constamment créés/modifiés (sorties de build, dossiers temporaires).
• Conflit avec un autre outil de sécurité (double analyse, contention de drivers de filtre).
• Post-mise à jour ou changement de signatures qui déclenche une réévaluation.
• CPU d’entrée de gamme + disque occupé qui donne l’impression d’un problème CPU alors qu’il s’agit d’attente I/O et d’échanges de contexte.

L’objectif n’est pas d’« arrêter l’analyse ». L’objectif est de rendre l’analyse ciblée, planifiée et prévisible, et d’éliminer les rescans inutiles de dossiers à forte rotation.

Un principe qui tient en production : si vous ne contrôlez pas où votre outil de sécurité dépense du CPU, il choisira le moment le plus inopportun possible. Comme un chat, mais avec des hooks noyau.

Playbook de diagnostic rapide (premières/deuxièmes/troisièmes vérifications)

Premier : confirmer que c’est Defender et identifier le déclencheur

1. Gestionnaire des tâches : vérifiez que le processus est Antimalware Service Executable et que l’utilisation du CPU est soutenue (pas un pic de 5 secondes).
2. Moniteur de ressources : voyez s’il s’agit de calcul CPU ou d’un orage I/O fichier.
3. Windows Security → Virus & threat protection : vérifiez si une analyse est en cours, ou si vous venez de mettre à jour les signatures.

Deuxième : trouver ce qu’il analyse

1. Consultez le journal d’événements opérationnel de Defender pour l’activité récente d’analyse et les chemins concernés.
2. Corrélez avec ce qui a changé : nouvel outil dev, nouveau dépôt, nouvelles VM, nouvelle synchronisation OneDrive, mise à jour Windows.
3. Si vous êtes sur un poste d’entreprise : vérifiez la présence d’un second agent AV/EDR. Deux piles de filtres système de fichiers peuvent transformer la « sécurité » en « art de la performance ».

Troisième : choisir le levier de performance le plus sûr

1. Planification : déplacez les analyses lourdes en dehors des heures actives ; réduisez l’intensité des analyses si la politique le permet.
2. Exclusions : ajoutez des exclusions étroites et basées sur des preuves pour les dossiers de build/caches à forte rotation — pas « C:\ » parce que vous aimez vivre dangereusement.
3. Mise à jour/réparation : corrigez l’état de signatures cassé ; nettoyez les caches endommagés ; mettez à jour la plateforme Defender.
4. Résolution de conflits : si vous avez un autre AV, configurez des exclusions mutuelles ou suivez la politique de l’organisation pour éviter la double analyse.

Faits intéressants et contexte historique

• Defender n’a pas toujours été « l’antivirus » par défaut. Les premières versions étaient des téléchargements séparés et un niveau « assez bon » ; aujourd’hui il est profondément intégré et géré comme un composant système.
• MsMpEng.exe n’est que la façade en espace utilisateur. Le travail lourd implique des drivers de filtre en mode noyau qui interceptent les opérations sur les fichiers pour analyser le contenu avant exécution/utilisation.
• L’analyse en temps réel est fondamentalement une taxe sur la rotation de fichiers. Si votre charge crée 200 000 petits fichiers, Defender le remarquera. Bruyamment.
• « Haute CPU » masque souvent « lié au disque ». Quand un processus attend le stockage, Windows peut toujours afficher une CPU élevée à cause des échanges de contexte, de l’activité DPC/ISR et de la contention des files d’attente.
• Les archives compressées sont coûteuses. Analyser un gros ZIP peut impliquer l’analyse logique du contenu décompressé, ce qui demande beaucoup de calcul et peut provoquer de longues rafales d’un seul processus.
• Les mises à jour de signatures peuvent déclencher une réévaluation. Un nouvel ensemble d’intelligences peut rendre obsolètes les décisions de scan en cache, entraînant des rescans.
• Les machines de développeur sont des cas extrêmes. Node modules, wheels Python, caches NuGet, dépôts Maven — ce sont essentiellement des « tests de charge de petits fichiers ».
• Les disques virtuels multiplient la douleur. Scanner un VHDX pendant que la VM effectue aussi des analyses côté invité crée une boucle de rétroaction très stupide.

Tâches pratiques : commandes, sorties et décisions (12+)

Ces tâches sont conçues pour répondre à une question : que fait Defender, et quel levier est le plus sûr à actionner ? La plupart des commandes utilisent PowerShell. Les blocs de code sont affichés avec un prompt bash pour la cohérence du format ; exécutez-les dans une fenêtre PowerShell élevée sauf indication contraire.

Tâche 1 : Confirmer le processus et son empreinte CPU

cr0x@server:~$ tasklist /fi "imagename eq MsMpEng.exe"
Image Name                     PID Session Name        Session#    Mem Usage
========================= ======== ================ =========== ============
MsMpEng.exe                   4128 Services                   0    312,456 K

Ce que ça signifie : MsMpEng.exe est présent et vous avez un PID pour le corréler avec d’autres outils.

Décision : Si MsMpEng.exe n’est pas présent, vous poursuivez le mauvais coupable (souvent « Microsoft Defender Antivirus Service » est désactivé ou remplacé par un AV tiers ; le CPU élevé peut alors venir d’un agent EDR).

Tâche 2 : Instantané de l’utilisation CPU et vérifier si c’est soutenu

cr0x@server:~$ powershell -NoProfile -Command "Get-Process MsMpEng | Select-Object Id,CPU,WorkingSet,StartTime | Format-List"
Id         : 4128
CPU        : 1842.53
WorkingSet : 328232960
StartTime  : 02/05/2026 08:41:12

Ce que ça signifie : Le champ CPU est le cumul de secondes depuis le démarrage du processus. Relancez après 30 secondes pour voir le delta.

Décision : Si le CPU augmente rapidement et reste élevé pendant le travail normal, passez à l’identification du déclencheur d’analyse et des chemins chauds.

Tâche 3 : Vérifier si une analyse est en cours

cr0x@server:~$ powershell -NoProfile -Command "Get-MpComputerStatus | Select-Object AMRunningMode,RealTimeProtectionEnabled,OnAccessProtectionEnabled,AntispywareEnabled,AntivirusEnabled"
AMRunningMode              : Normal
RealTimeProtectionEnabled  : True
OnAccessProtectionEnabled  : True
AntispywareEnabled         : True
AntivirusEnabled           : True

Ce que ça signifie : Defender est actif. Cela ne confirme pas qu’une analyse est en cours, mais confirme que le moteur est activé et intercepte l’accès aux fichiers.

Décision : Si Defender est désactivé ici mais que MsMpEng est toujours chaud, vous pouvez avoir une corruption de plateforme ou des conflits de politique — passez aux vérifications de réparation/mise à jour.

Tâche 4 : Voir les derniers temps d’analyse et indicateurs rapides

cr0x@server:~$ powershell -NoProfile -Command "Get-MpComputerStatus | Select-Object QuickScanEndTime,FullScanEndTime,FullScanStartTime,QuickScanStartTime,AntivirusSignatureLastUpdated"
QuickScanEndTime              : 02/05/2026 09:05:31
FullScanEndTime               : 
FullScanStartTime             : 02/05/2026 09:06:10
QuickScanStartTime            : 02/05/2026 09:03:02
AntivirusSignatureLastUpdated : 02/05/2026 08:59:44

Ce que ça signifie : Une analyse complète a démarré il y a quelques minutes. Voilà le « pourquoi maintenant ».

Décision : Si une analyse complète est en cours pendant les heures de travail, corrigez d’abord la planification/la politique. Ne commencez pas par saupoudrer des exclusions à tout-va.

Tâche 5 : Inspecter les exclusions de Defender (chemins, processus, extensions)

cr0x@server:~$ powershell -NoProfile -Command "Get-MpPreference | Select-Object -ExpandProperty ExclusionPath"
C:\ProgramData\Docker
C:\Users\dev\AppData\Local\Temp

Ce que ça signifie : Defender ignore déjà ces chemins. Bon à savoir avant d’en ajouter d’autres.

Décision : Si vous voyez des exclusions trop larges (comme des profils utilisateurs entiers ou des racines de lecteur), c’est un problème de sécurité déguisé en « optimisation ». Resserrez-les.

Tâche 6 : Trouver la configuration d’analyse planifiée qui pourrait être mal programmée

cr0x@server:~$ powershell -NoProfile -Command "Get-MpPreference | Select-Object ScanScheduleDay,ScanScheduleTime,DisableCatchupFullScan,DisableCatchupQuickScan"
ScanScheduleDay        : 0
ScanScheduleTime       : 02:00:00
DisableCatchupFullScan : False
DisableCatchupQuickScan: False

Ce que ça signifie : Les analyses planifiées sont définies (le jour 0 signifie souvent tous les jours selon le contexte de la politique), et les scans de rattrapage sont autorisés.

Décision : Si les portables sont en veille à 2h du matin, les scans de rattrapage s’exécuteront à 9h — juste au démarrage de votre journée. Envisagez de contrôler le comportement de rattrapage via la politique si approprié.

Tâche 7 : Vérifier le journal opérationnel de Defender pour l’activité d’analyse

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -LogName 'Microsoft-Windows-Windows Defender/Operational' -MaxEvents 20 | Select-Object TimeCreated,Id,LevelDisplayName,Message | Format-Table -AutoSize"
TimeCreated           Id LevelDisplayName Message
-----------           -- ---------------- -------
2/5/2026 9:06:11 AM 1000 Information      Scan started.
2/5/2026 9:06:12 AM 1001 Information      Scan type: Full Scan
2/5/2026 9:06:13 AM 1116 Warning          Malware detected: ... (remediated)

Ce que ça signifie : Vous pouvez confirmer le démarrage de l’analyse, le type, et si des détections causent du travail supplémentaire (la remédiation peut aussi faire monter la CPU).

Décision : Si le journal montre des démarrages répétés d’analyse ou des erreurs, vous pouvez avoir une tâche bloquée ou un état corrompu. Corrigez la condition sous-jacente ; ne vous contentez pas de replanifier.

Tâche 8 : Mesurer si le stockage est le goulet d’étranglement (méthode rapide)

cr0x@server:~$ powershell -NoProfile -Command "Get-Counter '\PhysicalDisk(_Total)\Avg. Disk Queue Length','\PhysicalDisk(_Total)\Disk Bytes/sec' -SampleInterval 1 -MaxSamples 5 | Select-Object -ExpandProperty CounterSamples | Select-Object Path,CookedValue | Format-Table -AutoSize"
Path                                           CookedValue
----                                           -----------
\\DESKTOP\physicaldisk(_total)\\avg. disk queue length   9.2
\\DESKTOP\physicaldisk(_total)\\disk bytes/sec    84539212

Ce que ça signifie : Une longueur de file d’attente élevée suggère que le disque est saturé. Defender peut lire de manière agressive, et tout le reste attend dans la file.

Décision : Si la file disque est élevée, concentrez-vous sur la réduction de la rotation de fichiers et l’exclusion des caches sûrs à forte rotation. L’ajustement CPU seul n’aidera pas beaucoup.

Tâche 9 : Identifier l’activité fichier principale de MsMpEng avec Resource Monitor (substitut CLI)

cr0x@server:~$ powershell -NoProfile -Command "Get-Process -Id (Get-Process MsMpEng).Id | Select-Object Id,Threads,Handles,Path"
Id Threads Handles Path
-- ------- ------- ----
4128     64    1750 C:\ProgramData\Microsoft\Windows Defender\Platform\4.18.24090.11-0\MsMpEng.exe

Ce que ça signifie : Pas encore la liste des fichiers, mais un indice : une explosion de threads/handles corrèle souvent avec une énorme énumération de fichiers.

Décision : Si les handles/threads sont anormalement nombreux et que la machine échange, considérez cela comme « portée d’analyse trop large » ou « explosion de chemins ». Utilisez les logs et la stratégie d’exclusion.

Tâche 10 : Vérifier les versions de la plateforme Defender (les moteurs obsolètes peuvent mal se comporter)

cr0x@server:~$ powershell -NoProfile -Command "Get-MpComputerStatus | Select-Object AMEngineVersion,AMProductVersion,AMServiceVersion,AntivirusSignatureVersion"
AMEngineVersion           : 1.1.24090.11
AMProductVersion          : 4.18.24090.11
AMServiceVersion          : 4.18.24090.11
AntivirusSignatureVersion : 1.409.1123.0

Ce que ça signifie : Vous pouvez savoir si vous êtes sur un moteur ancien ou plutôt actuel. Certains bugs de performance sont spécifiques à une version de moteur.

Décision : Si la plateforme est en retard par rapport à la baseline corporate, mettez à jour/corrigez d’abord. Optimiser une version boguée, c’est comme polir un pneu crevé.

Tâche 11 : Forcer une mise à jour des signatures (sûr et souvent corrige les comportements étranges)

cr0x@server:~$ powershell -NoProfile -Command "Update-MpSignature"

Ce que ça signifie : L’absence de sortie signifie généralement réussite (ou gestion centralisée). Vérifiez le statut ensuite.

Décision : Si les mises à jour échouent de façon répétée, vous pouvez avoir des problèmes réseau/proxy/politique. Corrigez-les ; des signatures périmées peuvent provoquer des scans plus longs et des faux positifs.

Tâche 12 : Lancer une analyse ciblée au lieu d’une analyse complète (contrôler le rayon d’action)

cr0x@server:~$ powershell -NoProfile -Command "Start-MpScan -ScanType CustomScan -ScanPath 'C:\Users\dev\Downloads'"

Ce que ça signifie : Vous dites à Defender quoi analyser maintenant, au lieu de le laisser parcourir tout le disque.

Décision : Utile sur les machines de dev : analysez plus fréquemment les points d’entrée à risque (Downloads, clés USB, pièces jointes) ; gardez les analyses complètes hors heures de travail.

Tâche 13 : Ajouter une exclusion étroite pour un cache dev à forte rotation (seulement après preuve)

cr0x@server:~$ powershell -NoProfile -Command "Add-MpPreference -ExclusionPath 'C:\Users\dev\AppData\Local\npm-cache'"

Ce que ça signifie : Defender ignorera ce chemin à l’accès (la politique peut annuler). Cela peut réduire drastiquement le CPU sur les systèmes Node intensifs.

Décision : N’excluez que des caches reproductibles et qui ne sont pas des chemins d’exécution courants. Si des utilisateurs exécutent des binaires depuis là, ne l’excluez pas.

Tâche 14 : Ajouter une exclusion de processus pour un outil de build (à utiliser avec parcimonie)

cr0x@server:~$ powershell -NoProfile -Command "Add-MpPreference -ExclusionProcess 'C:\Program Files\Git\usr\bin\bash.exe'"

Ce que ça signifie : Les fichiers ouverts par ce processus peuvent être exclus de l’analyse. C’est puissant et risqué.

Décision : Préférez les exclusions de chemin aux exclusions de processus. Les exclusions de processus peuvent devenir « ne rien analyser quand ce processus accède au fichier », ce qui est trop large.

Tâche 15 : Supprimer une mauvaise exclusion héritée

cr0x@server:~$ powershell -NoProfile -Command "Remove-MpPreference -ExclusionPath 'C:\'"

Ce que ça signifie : Si cela réussit, vous venez de combler un cratère de sécurité.

Décision : Si votre organisation a vraiment besoin d’exclusions larges, mettez en place un processus d’exception de sécurité — pas un ajustement improvisé.

Tâche 16 : Vérifier les tâches planifiées qui peuvent déclencher des analyses de manière répétée

cr0x@server:~$ powershell -NoProfile -Command "Get-ScheduledTask -TaskPath '\Microsoft\Windows\Windows Defender\' | Select-Object TaskName,State | Format-Table -AutoSize"
TaskName                          State
--------                          -----
Windows Defender Cache Maintenance Ready
Windows Defender Cleanup          Ready
Windows Defender Scheduled Scan   Ready
Windows Defender Verification     Ready

Ce que ça signifie : Defender utilise des tâches planifiées pour la maintenance. Si l’une est coincée sur « Running » en permanence, c’est un indice.

Décision : Si des tâches sont bloquées, inspectez leur historique et envisagez de réparer la plateforme Defender plutôt que de tuer systématiquement MsMpEng.

Causes racines qui créent une forte CPU (et comment les confirmer)

1) Analyse complète s’exécutant au pire moment possible

C’est le classique. Quelqu’un a planifié une analyse à 2h du matin. Les portables sont en veille à 2h. Defender attend poliment, puis lance une analyse de rattrapage à 9h07 quand tout le monde ouvre Teams et un IDE.

Confirmer : Get-MpComputerStatus montre le démarrage récent d’une analyse ; le journal opérationnel de Defender montre « Scan started » et le type d’analyse.

Corriger : Ajustez la planification des analyses et le comportement de rattrapage via la politique ; assurez-vous que les postes peuvent se réveiller pour la maintenance si autorisé, ou planifiez dans une fenêtre de pause déjeuner.

2) Dossiers de build ou CI à forte rotation

Si votre machine passe son temps à générer des fichiers objets, à télécharger des dépendances et à exploser des archives en milliers de fichiers, l’analyse en temps réel multiplie chaque étape de build.

Confirmer : Le pic corrèle avec les builds (dotnet build, npm install, mvn package), et la longueur de file disque augmente. Les journaux de Defender montrent souvent une activité intense à ces moments, même s’ils ne listent pas chaque fichier.

Corriger : Excluez des dossiers spécifiques de cache/sortie de build (pas les dépôts sources) ; maintenez l’analyse activée pour les sources et les points d’entrée de téléchargement.

3) Virtualisation et « double analyse »

L’hôte scanne le VHDX. L’invité scanne son système de fichiers. Les deux ont raison isolément, et la combinaison est ridicule.

Confirmer : Les pics CPU surviennent quand les VM sont actives ; le débit disque est élevé ; les fichiers VHDX sont beaucoup lus ; l’OS invité montre aussi une activité antivirus.

Corriger : Préférez l’analyse à l’intérieur de l’invité pour le contenu invité, et envisagez d’exclure les fichiers disque VM sur l’hôte (avec une politique claire et des contrôles compensatoires). Même logique pour Docker/WSL2 si votre organisation l’autorise.

4) Un autre produit de sécurité qui se dispute avec Defender

Certaines environnements font tourner Defender en même temps qu’un agent EDR, ou un antivirus tiers censé « supplanter » Defender. Si la configuration est mauvaise, vous obtenez une contention de drivers de filtre, une double analyse, et des pics CPU mystérieux.

Confirmer : Les programmes installés montrent un autre AV/EDR ; les journaux montrent les deux acteurs touchant les mêmes chemins ; les problèmes de performance persistent même quand les analyses Defender ne sont pas planifiées.

Corriger : Suivez les recommandations des éditeurs pour les exclusions mutuelles et assurez-vous qu’un seul moteur AV effectue l’analyse en temps réel (si la politique le permet). Ne faites pas ça en freestyle sur un poste corporate sans approbation.

5) État corrompu ou maintenance bloquée

Parfois Defender entre dans une boucle : analyses répétées, vérification de cache répétée, ou tentatives de mise à jour de signatures qui échouent. C’est moins fréquent que « vous avez un million de fichiers », mais ça arrive.

Confirmer : Le journal opérationnel de Defender montre des événements répétés, des erreurs ou des mises à jour échouant ; la version de la plateforme est obsolète ; des tâches planifiées sont coincées sur « Running ».

Corriger : Mettez à jour la plateforme/signatures ; réparez les fichiers système ; redémarrez (oui, vraiment) pour vider les drivers/tâches bloqués ; escaladez vers une réparation OS si les logs montrent une corruption de composant.

Blague #1 : Désactiver Defender pour réparer une CPU élevée, c’est comme couper votre ceinture de sécurité pour perdre du poids. Vous vous sentirez plus léger jusqu’à ce que la physique intervienne.

Correctifs qui conservent la sécurité activée

Arrêtez de traiter les exclusions comme une fonctionnalité de performance

Les exclusions sont une décision de sécurité. Elles doivent être :

• Étroites (un dossier spécifique, pas un lecteur entier).
• Justifiées (vous pouvez expliquer pourquoi l’analyse est de faible valeur ou redondante).
• Compensées (vous scannez les entrées vers ce dossier, ou vous analysez les sorties avant publication).
• Auditées (revues périodiquement ; supprimées quand elles ne sont plus nécessaires).

Rendez les analyses ennuyeuses : planifiez-les et évitez les surprises de rattrapage

Sur les endpoints, le plus grand gain est de déplacer les analyses complètes hors des heures interactives. Si les portables ne restent pas allumés la nuit, il vous faut une politique pour les scans de rattrapage ou une fenêtre de maintenance où les appareils sont branchés et réveillés.

En environnement d’entreprise, c’est typiquement une décision de Group Policy / MDM, pas un ajustement individuel. La bonne méthode est ennuyeuse, répétable et documentée — c’est pourquoi elle fonctionne.

Exclure les caches à forte rotation, pas ce que vous exécutez

Exemples raisonnables d’exclusions en contexte de développement après revue :

• Caches de gestionnaires de paquets : caches npm/yarn/pnpm, global-packages NuGet, caches Maven/Gradle.
• Répertoires de sortie de build régénérés : bin/obj (par projet), target, dist.
• Bacs temporaires de compilation.

Exemples généralement non raisonnables :

• Downloads, caches de pièces jointes de messagerie, répertoires de cache du navigateur utilisés pour les téléchargements.
• Racines de profils utilisateur.
• Racines entières de dépôt où des scripts et binaires sont exécutés.
• Tout emplacement recevant du contenu depuis Internet puis exécuté.

Contrôlez les « points d’entrée » plutôt que d’analyser tout en permanence

Si vous devez troquer quelque chose, troquez la portée, pas la sécurité. Maintenez une analyse stricte sur :

• Dossiers de téléchargements et pièces jointes
• Chemins pour supports amovibles / USB
• Ingress du navigateur et clients mail

Puis utilisez des analyses ciblées pour les espaces de travail quand nécessaire, et comptez sur les pipelines de build pour analyser les artefacts avant diffusion.

Corrigez la santé des mises à jour et du niveau plateforme

Un nombre surprenant de cas « Defender fait fondre mon CPU » s’explique par « Defender est en mauvaise santé ». Les mises à jour qui échouent peuvent mener à des tentatives répétées ; des plateformes obsolètes peuvent contenir des bugs de performance déjà corrigés.

Ce que je fais en pratique :

• Vérifier les versions avec Get-MpComputerStatus.
• Déclencher Update-MpSignature.
• Vérifier la santé de Windows Update en général (parce que Defender s’appuie sur cette infrastructure dans de nombreux environnements).

Savoir quand escalader : les serveurs de fichiers et de build nécessitent des réglages au niveau politique

Pour les serveurs hébergeant du code, des artefacts ou de grands jeux de données, la configuration de Defender appartient à la gestion de configuration. Des exclusions aléatoires par serveur deviennent un cauchemar de conformité.

Sur les serveurs de build/CI, la pratique courante consiste à exclure :

• Répertoires cache de workspace qui sont reconstruits
• Stockage des couches de conteneurs (si les images sont scannées ailleurs)
• Caches d’artefacts

Mais faites-le avec un modèle de menace : où entrent les artefacts, et où sont-ils scannés avant publication ?

Une citation fiabilité pour rester honnête

« L’espoir n’est pas une stratégie. » — General Gordon R. Sullivan

Planifier les analyses, limiter les exclusions et vérifier la santé des mises à jour sont des stratégies. Espérer que les utilisateurs ne cliquent pas est pas une stratégie.

Trois mini-histoires d’entreprise issues du terrain

Mini-histoire 1 : L’incident causé par une fausse hypothèse

Dans une entreprise de taille moyenne avec une flotte Windows tout à fait normale, les développeurs se plaignaient que leurs builds ralentissaient chaque semaine. Le Gestionnaire des tâches pointait MsMpEng.exe, donc l’hypothèse immédiate fut « Defender doit analyser notre dépôt source et tuer la performance ».

L’équipe desktop a ajouté des exclusions larges pour la racine du dépôt. La CPU a baissé. Tout le monde a célébré. Puis un audit interne a signalé que l’exclusion était trop large, et la sécurité a posé la question gênante : « Pourquoi exclure des scripts exécutables et des outils qui s’exécutent depuis ce dépôt ? »

En regardant de près, le dépôt n’était pas le véritable coupable. Le coupable était le répertoire de cache de paquets situé sous le profil utilisateur et qui changeait constamment pendant les builds. Le dépôt contenait de gros fichiers mais une rotation relativement stable ; le cache avait un ouragan d’écritures de petits fichiers.

La solution fut plus étroite et plus sûre : exclure uniquement les caches et dossiers de sortie de build, garder l’analyse du dépôt activée, et ajouter une analyse ciblée des Downloads. Les temps de build se sont améliorés sans élargir la surface d’attaque.

Leçon : ne devinez pas. Confirmez quels chemins tournent, puis excluez la rotation — pas les éléments précieux.

Mini-histoire 2 : L’optimisation qui s’est retournée contre eux

Une autre organisation gérait quelques agents de build Windows qui produisaient des artefacts signés. Les agents étaient « trop lents », donc quelqu’un a essayé d’accélérer en excluant tout l’espace de travail et le répertoire de staging. Les agents furent immédiatement plus rapides.

Deux mois plus tard, une compromission de dépendance dans l’écosystème plus large a frappé. L’agent de build a tiré un paquet empoisonné qui s’est retrouvé dans le cache workspace. À cause de l’exclusion, Defender ne l’a jamais inspecté à l’accès. Le pipeline avait un scanner de sécurité, mais il s’exécutait après le packaging et n’inspectait pas profondément les chemins d’exécution au build-time.

Aucun impact client n’est survenu — quelqu’un l’a détecté avant la release — mais la réponse a été coûteuse : revue du pipeline, ré-imaging des agents, nettoyage d’urgence de la politique et une réunion très désagréable « pourquoi avons-nous fait ça ».

Le problème n’était pas l’existence d’exclusions. Le problème était d’avoir exclu un chemin qui acceptait des entrées non fiables sans contrôles compensatoires. La performance s’est améliorée ; le risque a augmenté discrètement.

Leçon : les exclusions doivent être assorties d’un scan des points d’entrée et d’une validation des artefacts. Sinon vous déplacez le problème vers la file des incidents.

Mini-histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Dans une grande entreprise, les endpoints étaient gérés strictement : politiques Defender via MDM, fenêtres d’analyse standardisées et un processus formel pour demander des exclusions. Les développeurs détestaient la paperasse, évidemment. Personne n’aime la paperasse.

Puis une mise à jour Windows a coïncidé avec une mise à jour de la plateforme Defender, et un sous-ensemble de machines a commencé à voir des pics CPU matinaux. La différence clé : cette organisation avait déjà une baseline et de la télémétrie. Ils ont pu comparer rapidement les configurations « saines » et « spiky ».

La correction fut ennuyeuse : ajuster la planification des analyses et le comportement de rattrapage pour les portables qui restent rarement éveillés la nuit, plus une petite liste d’exclusions revue pour les caches de build à forte rotation. La liste d’exclusions vivait dans la politique, pas dans une page wiki que quelqu’un lirait peut-être un jour.

En une semaine, le nombre de tickets a chuté et les plaintes de performance ont disparu. La posture sécurité ne s’est pas affaiblie ; elle est devenue plus cohérente.

Leçon : la pratique ennuyeuse — politique centralisée, petites exclusions approuvées, planification cohérente — bat le dépannage héroïque sur des machines individuelles.

Erreurs courantes : symptôme → cause → correctif

1) « MsMpEng.exe est à 80–100% CPU juste après la connexion »

Cause : Scan de rattrapage ou maintenance s’exécutant après que l’appareil était en veille pendant la fenêtre planifiée.

Correctif : Ajuster la planification des analyses vers un moment où les appareils sont réveillés, ou gérer le comportement de rattrapage. Confirmer avec les temps de démarrage d’analyse et les journaux opérationnels de Defender.

2) « Les CPU montent quand je build ou installe des dépendances »

Cause : Analyse en temps réel des dossiers de cache/sortie à forte rotation (milliers de petits fichiers).

Correctif : Ajouter des exclusions étroites pour les caches/sorties (ex. cache npm, packages NuGet, obj/bin), et garder l’analyse activée pour les téléchargements et les racines de dépôts.

3) « Defender a une CPU élevée mais le disque est aussi saturé »

Cause : Goulet d’étranglement stockage ; les lectures/marches de métadonnées de Defender saturent le disque et créent une lenteur système globale.

Correctif : Réduire la portée d’analyse (exclusions), planifier les analyses complètes, et envisager une montée en gamme du stockage (HDD → SSD). Confirmer via les compteurs de file disque.

4) « Defender ne se calme jamais ; il scanne toujours »

Cause : Tâche planifiée bloquée, échecs répétés de mise à jour, ou problème de santé de la plateforme provoquant des tentatives répétées.

Correctif : Vérifier l’état des tâches planifiées, les journaux de Defender, les mises à jour de signatures. Réparer la santé des mises à jour ; redémarrer si des tâches/drivers sont bloqués.

5) « Nous avons exclu un dossier et maintenant des détections bizarres apparaissent ailleurs »

Cause : Exclusion d’un répertoire contenant des toolchains ou scripts ; le malware a migré dans l’angle mort.

Correctif : Supprimer les exclusions larges ; n’exclure que des caches. Assurer le scan des points d’entrée et l’analyse des artefacts en CI.

6) « Haute CPU après l’installation d’un autre agent de sécurité »

Cause : Double analyse et contention des drivers de filtre de fichiers.

Correctif : Confirmer quel produit gère l’AV temps réel, configurer les exclusions mutuelles selon la politique, et éviter d’exécuter deux moteurs AV complets en parallèle.

Blague #2 : Deux moteurs antivirus qui analysent le même fichier, c’est comme deux managers qui vérifient la même feuille de calcul. Le seul résultat qui augmente de façon fiable, c’est le temps de réunion.

Listes de contrôle / plan étape par étape

Plan étape par étape pour un seul PC (15–45 minutes)

1. Confirmer le coupable : vérifier que MsMpEng.exe est le processus chaud ; revérifier après 30 secondes pour voir une croissance CPU soutenue.
2. Vérifier l’état d’analyse : lire les derniers temps de début/fin d’analyse ; confirmer si une analyse complète est en cours.
3. Corréler avec l’activité utilisateur : builds, téléchargements, démarrage de VM, synchronisation OneDrive, extraction d’archives volumineuses.
4. Vérifier la contention disque : collecter un échantillon rapide de la longueur de file disque ; décider si c’est du calcul CPU ou du thrash stockage.
5. Inspecter les exclusions : lister les exclusions existantes ; supprimer celles dangereusement larges si présentes (avec approbation adéquate).
6. Ajouter une exclusion étroite à la fois : choisir le dossier cache à forte rotation le plus impactant et l’exclure ; mesurer à nouveau.
7. Corriger la santé des mises à jour : mettre à jour les signatures ; confirmer que les versions de plateforme sont à jour ; redémarrer si des tâches étaient bloquées.
8. Planifier les analyses : s’assurer que les analyses complètes se déroulent hors heures de travail (ou dans une fenêtre contrôlée) et ne surprennent pas les utilisateurs à la connexion.
9. Documenter le changement : consigner ce qui a été exclu et pourquoi ; programmer une revue dans 30–90 jours.

Checklist pour postes de développement (pragmatique et sûr)

• N’exclure que des caches/outputs reproductibles, pas les racines de dépôt.
• Garder l’analyse sur Downloads et chemins de pièces jointes.
• Préférer les analyses personnalisées des dossiers à risque plutôt que des analyses complètes fréquentes.
• Éviter les exclusions de processus sauf si l’impact est bien justifié.
• Si vous utilisez Docker/WSL2/VMs, décidez où l’analyse doit se produire : hôte ou invité — pas les deux pour le même contenu.

Checklist pour équipes IT/SRE gérant des flottes

• Centraliser la politique Defender (MDM/GPO), y compris les horaires d’analyse et les exclusions approuvées.
• Maintenir un catalogue d’exclusions approuvées pour les outils dev courants (npm, NuGet, Maven) avec un périmètre clair.
• Surveiller les exclusions larges et la dérive de configuration.
• Définir la propriété si plusieurs agents de sécurité existent (Defender AV vs comportement de monitoring EDR).
• Tester les mises à jour majeures avec des charges de travail représentatives (tempêtes de petits fichiers) avant déploiement large.

FAQ

1) Antimalware Service Executable est-il un virus ?

Généralement non. C’est le moteur légitime de Microsoft Defender Antivirus (MsMpEng.exe). S’il se trouve en dehors du répertoire de la plateforme Defender, ou s’il a une signature étrange, alors investigatez un usurpateur.

2) Puis-je simplement désactiver la protection en temps réel pour arrêter l’utilisation CPU ?

Vous pouvez, mais vous ne devriez pas. C’est échanger un problème de performance contre un incident de sécurité. Corrigez la planification, la portée et la rotation d’abord ; désactivez seulement sous politique explicite et pour de courtes fenêtres de dépannage contrôlées.

3) Pourquoi la CPU monte-t-elle après des mises à jour Windows ?

Les mises à jour peuvent modifier des composants système, des signatures et des versions de plateforme. Cela peut déclencher une invalidation de cache et des rescans, plus une maintenance en arrière-plan qui n’a pas tourné pendant le redémarrage ou l’absence réseau.

4) Quelles exclusions sont sûres pour les développeurs ?

Les exclusions plus sûres sont les caches à forte rotation et les sorties générées qui sont reproductibles et pas des points d’entrée d’exécution typiques : caches de paquets et dossiers de sortie de build. Les exclusions non sûres incluent Downloads, racines de profil utilisateur ou racines de dépôt où des scripts/binaries s’exécutent.

5) Exclure un dossier signifie-t-il que Defender ne l’analyse jamais ?

Les exclusions réduisent ou suppriment généralement l’analyse en temps réel/à l’accès pour ce chemin, selon la politique. Cela ne garantit pas que rien ne l’inspecte jamais (les analyses planifiées et d’autres protections peuvent encore s’appliquer), mais vous devez considérer que cela crée un angle mort.

6) Pourquoi la haute CPU de Defender semble pire sur HDD que sur SSD ?

Parce que l’analyse est fortement consommatrice en lectures et métadonnées. Les HDD souffrent sur les I/O aléatoires et les petits fichiers ; la profondeur de file augmente et tout attend. Les SSD gèrent beaucoup mieux ce pattern.

7) J’ai ajouté des exclusions mais la CPU reste élevée — que faire maintenant ?

Vérifiez si une analyse complète est encore en cours, si la file disque est saturée, et si un autre outil de sécurité double-analyse. Vérifiez aussi la santé de la plateforme/signatures Defender ; une boucle de mise à jour bloquée peut maintenir l’activité malgré les exclusions.

8) Dois-je exclure les fichiers VHDX sur l’hôte si j’analyse dans la VM ?

Souvent oui dans des environnements contrôlés, car sinon vous analysez les mêmes octets deux fois. Mais c’est une décision politique : il faut s’assurer que l’AV invité est sain et que des contrôles hôtes restent en place pour protéger l’OS hôte.

9) Quel est le « quick win » le plus sûr si j’ai besoin d’un PC utilisable aujourd’hui ?

Replanifiez les analyses complètes hors des heures de travail et ajoutez une unique exclusion étroite pour le plus gros dossier cache connu à forte rotation. Puis mesurez. N’excluez pas des chemins larges dans la panique.

Conclusion : prochaines étapes pratiques

Si Defender brûle du CPU, c’est généralement parce qu’il fait quelque chose de rationnel dans un environnement irrationnel — comme analyser 400 000 petits fichiers créés par vos outils parce qu’il le peut. Votre travail est de rendre ce travail borné et prévisible sans transformer la sécurité en accessoire optionnel.

Faites ceci ensuite :

1. Confirmez s’il s’agit d’une analyse complète ou d’un scan de rattrapage (statut + journal d’événements).
2. Vérifiez si le système est réellement lié au stockage (longueur de file disque).
3. Corrigez la planification des analyses pour qu’elles n’embusquent pas les utilisateurs.
4. Ajoutez des exclusions étroites et basées sur des preuves pour les caches à forte rotation et les sorties générées.
5. Mettez à jour les signatures/la plateforme Defender et vérifiez la santé.
6. Si vous êtes dans un environnement géré, poussez la correction via la politique pour qu’elle reste appliquée.

Laissez Defender activé. Rendez-le moins coûteux. Dormez mieux.