Antivirus qui casse des PC : l’ironie qui se répète

L’ironie répétée : pourquoi la « sécurité » devient une indisponibilité

L’antivirus est une espèce invasive par conception. Il s’accroche aux ouvertures de fichiers, surveille la création de processus, inspecte la mémoire, détourne les appels réseau et parfois s’insère dans les flux d’authentification. S’il ne le faisait pas, il serait aveugle. Mais cette même visibilité signifie qu’il se situe exactement là où les performances et la stabilité sont fragiles : pilotes du noyau, filtres de système de fichiers, piles réseau et chargeur de processus.

Quand il casse, ça casse fort. Il n’y a pas une dégradation douce ; c’est des boucles de démarrage, des écrans bleus, des « accès refusé » sur les binaires système, des compilations 10× plus longues et des bases de données qui se comportent comme si elles tournaient depuis une clé USB. C’est parce que les outils de sécurité endpoint sont conçus pour être autoritatifs. Ils peuvent bloquer ce que vous essayez de faire, et ils peuvent le faire avant que votre logiciel n’ait voix au chapitre.

Le schéma récurrent n’est pas que « la sécurité est mauvaise ». Le schéma, c’est que nous traitons les outils de sécurité comme une mise à jour de navigateur : on les pousse partout, immédiatement, avec une discipline de déploiement minimale — parce que l’outil est censé réduire le risque. C’est à l’envers. Traitez l’outil de sécurité comme une mise à jour du noyau, parce que c’en est effectivement une.

Idée paraphrasée de John Allspaw : « La fiabilité vient de la capacité à apprendre et à s’adapter en conditions réelles. » Cela inclut les agents de sécurité : déployez-les comme s’ils allaient échouer, parce qu’ils finissent par échouer.

Une petite blague, parce qu’il en faut une : le logiciel antivirus est le seul produit qui peut dire « j’ai trouvé un virus » et vouloir dire « je suis le virus aujourd’hui ».

Faits et contexte historique intéressants (court, concret)

• Années 1980 : Les premiers « antivirus » étaient surtout des correspondances de signatures pour les infecteurs de secteur d’amorçage et de fichiers ; ils n’étaient pas profondément intégrés aux noyaux car les systèmes d’exploitation ne l’étaient pas non plus.
• Années 1990 : Les virus macros (notamment via les documents bureautiques) ont déplacé la détection vers l’inspection de contenu et le scanning heuristique, augmentant l’utilisation CPU sur les flux de travail riches en documents.
• Fin des années 1990–2000 : Les vers propagés par e‑mail ont poussé les éditeurs à ajouter le scan en temps réel des magasins de mail et des pièces jointes, provoquant souvent une amplification pénible des E/S sur PST/OST et formats similaires.
• Années 2000 : Les drivers minifilter du système de fichiers Windows sont devenus un mécanisme standard pour le scan à l’accès — puissant, mais proche du noyau et facile à déstabiliser lorsque buggy ou mal configuré.
• Années 2010 : L’EDR s’est étendu au-delà du malware vers la détection comportementale, la prévention du vol d’identifiants et la détection des mouvements latéraux — plus de capteurs, plus d’accroches, plus de choses susceptibles de casser.
• Endpoints modernes : De nombreux agents utilisent des détections délivrées depuis le cloud et des mises à jour fréquentes de règles. Cela rend les « mises à jour de définitions » plus proches des « mises à jour de politiques », avec un impact comportemental réel.
• Réalité performance : Le scan à l’accès peut transformer une opération logique en plusieurs lectures/écritures physiques, surtout avec le scan d’archives et la décompression de contenu.
• Réalité opérationnelle : Une mise à jour d’agent de sécurité est souvent un installateur privilégié qui met à jour des drivers/services, parfois exige un redémarrage, parfois le fait de toute façon.

Modes de défaillance : comment l’antivirus casse les PC en pratique

1) Boucles de démarrage et écrans bleus : la proximité du noyau est une lame tranchante

La sécurité endpoint adore le noyau. Pas toujours directement, mais suffisamment proche : drivers de filtre de système de fichiers, callouts réseau, fournisseurs d’identifiants, hooks d’intégrité du code et composants de scan mémoire. Quand l’un de ces drivers se comporte mal — conditions de concurrence, mauvaises hypothèses sur les versions d’OS, métadonnées de fichiers inattendues — vous n’obtenez pas un plantage propre en espace utilisateur. Vous obtenez une machine qui ne peut pas démarrer ou rester allumée.

Déclencheurs typiques : une mise à jour qui introduit un nouveau driver, une mise à jour cumulative Windows qui change le comportement du noyau, ou l’activation d’un flag de fonctionnalité qui étend la portée de la surveillance à un chemin de code jamais testé en charge sur votre mix matériel/driver.

2) « Tout est lent » : amplification d’E/S et contention

Le scan à l’accès signifie souvent : ouverture de fichier → l’antivirus intercepte → lit le contenu → peut-être décompresse → scanne → autorise la lecture originale. Multipliez cela par des systèmes de build (milliers de petits fichiers), des gestionnaires de paquets (beaucoup d’archives) et des workflows développeur (node_modules, target/, bin/obj), et vous avez construit un radiateur déguisé en portable.

Le stockage aggrave le problème. Les charges antivirus sont des « petites lectures aléatoires » plus un fort churn de métadonnées. Sur disques rotatifs c’est misère ; sur SSD c’est une misère plus rapide. Sur des lecteurs réseau, c’est la misère avec latence.

3) Applications qui cassent : faux positifs et remédiation agressive

Les outils modernes ne se contentent pas de détecter ; ils remédient. Quarantaine, suppression, blocage d’exécution, blocage de chargement de DLL, refus d’ouverture de handles. Si l’outil signale un binaire légitime (artefact de build récent, outil interne non signé, installateur compacté), la « correction » devient une panne de production parce qu’un agent a décidé que votre logiciel avait l’air suspect.

4) Anomalies réseau : inspection TLS et altérations de paquets

Certaines piles endpoint s’insèrent dans le réseau pour la protection web, la défense contre le phishing ou l’inspection TLS. Mal faite, vous obtenez des chaînes de certificats cassées, des réinitialisations de connexions intermittentes et des chutes de performance sur des applications à haut débit (CI runners, caches d’artefacts, pulls de conteneurs).

5) Tempêtes de mises à jour : un changement de politique qui se propage instantanément

Les équipes de sécurité aiment les consoles centrales. Les consoles centrales aiment les bascules globales instantanées. Basculez un interrupteur qui augmente l’agressivité des scans, et soudain chaque endpoint commence à hasher des fichiers, scanner des archives et rescanner des caches. Votre « problème » n’est pas une seule machine ; c’est une bombe de charge synchronisée.

6) VDI et machines partagées : un hôte, beaucoup de victimes

En VDI, un seul hôte exécute de nombreux postes. Si l’agent sur chaque VM décide de « lancer un scan complet maintenant », le stockage partagé et le CPU sont attaqués. Si l’outil est installé sur l’image « gold » sans exclusions correctes, chaque clone hérite du problème instantanément.

7) Environnements développeurs et SRE : scanners vs graphes de build

Les outils de build créent des milliers de fichiers temporaires. Les gestionnaires de paquets écrivent des caches. Les conteneurs produisent des couches. L’antivirus voit ça comme une orgie d’activité suspecte. Vous voyez : « pourquoi ma suite de tests est passée de 8 minutes à 45 ? »

Deuxième petite blague, parce qu’on l’a mérité : le moyen le plus rapide de benchmarker votre SSD est d’installer un antivirus sur zèle et de le regarder découvrir de nouvelles limites passionnantes.

Playbook de diagnostic rapide (ce qu’il faut vérifier d’abord/deuxièmement/troisièmement)

Ceci est la boucle « arrêtez de deviner ». Vous essayez de répondre à une question : L’agent de sécurité est‑il le goulot d’étranglement, et si oui, quel sous‑système étouffe‑t‑il ?

Premier : confirmer la portée et le timing (rayon d’impact)

• Est‑ce un seul hôte, un service ou tout le monde ?
• Est‑ce que ça a commencé juste après une mise à jour d’agent, une mise à jour de politique ou une mise à jour d’OS ?
• Est‑ce corrélé avec des redémarrages, des connexions utilisateur ou des changements réseau ?

Décision : Si le rayon d’impact est large et que l’apparition est synchronisée, traitez‑le comme un incident de déploiement/politique, pas comme « les PC sont vieux ». Geler les changements et commencer la contention.

Second : identifier la ressource contrainte (CPU, disque, mémoire, réseau)

• CPU élevé dans les processus de sécurité ? Probablement scan, analyse comportementale ou télémétrie qui dérape.
• Forte activité disque / profondeur de file d’attente ? Probablement scan à l’accès ou churn de quarantaine.
• Anomalies réseau ? Peut‑être module de protection web, proxy, inspection TLS ou boucles de récupération de règles cloud.
• Échecs au démarrage/BSOD ? Problème côté driver, souvent lié à une mise à jour.

Décision : Choisissez l’outil de mesure le plus rapide disponible sur l’OS impacté et prouvez le goulot avant de modifier les paramètres.

Troisième : prouver la causalité (désactiver vs exclure vs rollback)

• Pouvez‑vous reproduire la lenteur en touchant un chemin chaud connu (par ex. construire un repo, décompresser une archive) ?
• Le problème disparaît‑t‑il en Mode Sans Échec (où beaucoup de drivers/services tiers sont désactivés) ?
• L’ajout d’une exclusion ciblée réduit‑t‑il la charge sans désactiver complètement la protection ?

Décision : Si le Mode Sans Échec ou une désactivation contrôlée règle le problème, montez en escalade vers la sécurité / le fournisseur avec des preuves et restaurez ou déployez une configuration étagée.

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

Voici des tâches pratiques que vous pouvez exécuter sur une station/serveur Linux ou un endpoint Windows en utilisant un environnement shell (WSL, Git Bash ou outil distant). Les commandes sont réalistes ; l’objectif est le workflow : exécuter → interpréter → décider.

Tâche 1 : Trouver les plus gros consommateurs CPU (est‑ce le scanner qui brûle des cycles ?)

cr0x@server:~$ ps -eo pid,ppid,cmd,%cpu,%mem --sort=-%cpu | head -n 8
  PID  PPID CMD                         %CPU %MEM
 2143     1 /opt/edr/agentd              186.3  2.1
 2210  2143 /opt/edr/scanner --realtime   94.2  1.4
 1055     1 /usr/lib/systemd/systemd      1.2  0.1
 1899     1 /usr/sbin/sshd               0.3  0.2

Ce que cela signifie : L’agent et le scanner dominent le CPU. Si cela coïncide avec des plaintes utilisateurs, ce n’est pas « juste une perception ».

Décision : Passez ensuite aux vérifications disque et activité fichier ; si le CPU est saturé sans beaucoup d’E/S, suspectez une boucle du moteur comportemental ou une tempête de télémétrie.

Tâche 2 : Détecter la pression disque (est‑ce lié aux E/S ?)

cr0x@server:~$ iostat -xz 1 3
Linux 6.5.0 (server) 	01/22/2026 	_x86_64_	(16 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          12.50    0.00    9.20   38.10    0.00   40.20

Device            r/s     w/s   rkB/s   wkB/s  await  aqu-sz  %util
nvme0n1         320.0   210.0  8200.0  6400.0  18.40    6.20  98.70

Ce que cela signifie : iowait est élevé ; l’utilisation du périphérique est ~99%. Le système attend sur le stockage.

Décision : Identifiez le processus qui génère les E/S (probablement le scanner). Envisagez des exclusions pour les répertoires chauds et la limitation des scans complets.

Tâche 3 : Identifier le coupable I/O (quel PID frappe le disque ?)

cr0x@server:~$ sudo iotop -o -b -n 3
Total DISK READ: 45.12 M/s | Total DISK WRITE: 12.34 M/s
  PID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN      IO>    COMMAND
 2210 be/4   root     42.10 M/s   0.00 B/s    0.00 %  92.00 %  /opt/edr/scanner --realtime
 2143 be/4   root      2.20 M/s   9.80 M/s    0.00 %  18.00 %  /opt/edr/agentd

Ce que cela signifie : Le scanner saturant les lectures. Cela arrive souvent lorsqu’il rescanne des caches ou des artefacts de build.

Décision : Inspectez les chemins de fichiers accédés, puis implémentez des exclusions ciblées ou ajustez le mode de scan.

Tâche 4 : Voir quels fichiers le scanner touche (chemins chauds)

cr0x@server:~$ sudo lsof -p 2210 | head -n 12
COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF     NODE NAME
scanner  2210 root  cwd    DIR  259,1     4096  1310730 /home/dev/build
scanner  2210 root   12r   REG  259,1  5242880  1311102 /home/dev/build/node_modules/.cache/tmp.bin
scanner  2210 root   13r   REG  259,1   912384  1311120 /home/dev/build/target/classes/app.jar

Ce que cela signifie : Il campe dans les sorties de build et les caches de dépendances.

Décision : Excluez les répertoires de build éphémères et les caches de paquets ; continuez à scanner le code source et les artefacts téléchargés si la politique l’exige.

Tâche 5 : Détecter les tempêtes de modification de fichiers (rescans dus au churn du FS ?)

cr0x@server:~$ inotifywatch -t 10 -r /home/dev/build
Establishing watches...
Finished establishing watches, now collecting statistics.
total  184532
create  61210
delete  60210
modify  48200
close_write  14912

Ce que cela signifie : Churn massif ; les scanners en temps réel peuvent devenir une DoS auto‑infligée ici.

Décision : Pour les arborescences de build, préférez les modes « scan à la fermeture » ou « scan à l’exécution », ou excluez le répertoire et scannez les artefacts dans la CI à la place.

Tâche 6 : Vérifier la pression mémoire (swap dû à un agent gonflé ?)

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:            31Gi        28Gi       1.1Gi       312Mi       2.0Gi       1.6Gi
Swap:          8.0Gi       5.2Gi       2.8Gi

Ce que cela signifie : Le système est profondément engagé dans le swap. Même un « petit » pic CPU devient catastrophique quand tout pagine.

Décision : Réduisez les fonctionnalités de l’agent, limitez la télémétrie ou redimensionnez les endpoints — puis vérifiez quel processus détient réellement le RSS avec la tâche suivante.

Tâche 7 : Trouver quels processus occupent la mémoire (réalité RSS)

cr0x@server:~$ ps -eo pid,cmd,rss --sort=-rss | head -n 6
  PID CMD                           RSS
 2143 /opt/edr/agentd            1824300
 2210 /opt/edr/scanner --realtime 943200
 3321 /usr/lib/firefox/firefox    612400

Ce que cela signifie : L’agent est un gros consommateur de mémoire. Certains outils mettent en cache signatures/modèles de façon agressive ; parfois c’est une fuite.

Décision : Si la croissance mémoire est illimitée dans le temps, planifiez un rollback ou une escalation fournisseur avec preuves (trend RSS).

Tâche 8 : Vérifier la santé du service et les redémarrages récents (les crash loops sont un indice)

cr0x@server:~$ systemctl status edr-agent --no-pager
● edr-agent.service - Endpoint Detection and Response Agent
     Loaded: loaded (/etc/systemd/system/edr-agent.service; enabled)
     Active: active (running) since Wed 2026-01-22 09:11:02 UTC; 3min ago
   Main PID: 2143 (agentd)
     Tasks: 48 (limit: 38241)
     Memory: 1.8G
     CGroup: /system.slice/edr-agent.service
             ├─2143 /opt/edr/agentd
             └─2210 /opt/edr/scanner --realtime

Ce que cela signifie : Le service tourne maintenant, mais le statut seul ne montre pas les flapping.

Décision : Inspectez le journal pour les crashes/restarts récents et corrélez avec les rapports utilisateurs.

Tâche 9 : Lire les logs autour de la fenêtre d’incident (repérer les changements de politique/moteur)

cr0x@server:~$ sudo journalctl -u edr-agent --since "2026-01-22 08:30" --no-pager | tail -n 12
Jan 22 08:58:10 server agentd[2143]: policy update received: profile=Workstations-Strict
Jan 22 08:58:11 server agentd[2143]: enabling feature: archive_deep_scan=true
Jan 22 08:58:12 server scanner[2210]: started full content scan: reason=policy_change
Jan 22 08:58:13 server scanner[2210]: warning: scan queue length=8421
Jan 22 08:58:20 server agentd[2143]: telemetry backlog increasing: 1200 events/sec

Ce que cela signifie : Ce n’est pas mystérieux. Une mise à jour de politique a activé le scan profond des archives et déclenché des scans complets.

Décision : Revenez en arrière sur la politique ou réduisez sa portée ; ajoutez des garde‑fous pour que les changements de politique n’entraînent pas de scans complets automatiques sur toute la flotte.

Tâche 10 : Vérifier le churn réseau (frappe‑t‑on les endpoints cloud ?)

cr0x@server:~$ ss -tpn | head -n 12
State  Recv-Q Send-Q Local Address:Port  Peer Address:Port Process
ESTAB  0      0      10.0.3.14:51944    52.85.12.33:443  users:(("agentd",pid=2143,fd=28))
ESTAB  0      0      10.0.3.14:51946    52.85.12.33:443  users:(("agentd",pid=2143,fd=29))
ESTAB  0      0      10.0.3.14:51948    52.85.12.33:443  users:(("agentd",pid=2143,fd=30))

Ce que cela signifie : Plusieurs sessions TLS persistantes. Normal — à moins que les comptes explosent ou que le trafic ne sature les liens.

Décision : Si les endpoints sont lents uniquement en étant « en ligne », testez en isolant temporairement une machine (dans un VLAN labo) pour voir si les lookups cloud bloquent l’exécution.

Tâche 11 : Confirmer la limitation CPU / problèmes thermiques (parfois l’agent n’est que le déclencheur)

cr0x@server:~$ cat /proc/cpuinfo | grep -E "model name|cpu MHz" | head -n 6
model name	: Intel(R) Core(TM) i7-10610U CPU @ 1.80GHz
cpu MHz		: 799.932
model name	: Intel(R) Core(TM) i7-10610U CPU @ 1.80GHz
cpu MHz		: 800.021

Ce que cela signifie : Le CPU est bloqué autour de 800 MHz — très probablement throttling thermique/power. La charge de l’agent peut pousser un système de refroidissement limite au-delà de ses capacités.

Décision : Corrigez le profil d’alimentation/thermique sous‑jacent (BIOS, politique d’alimentation OS) et ajustez quand même le scan. Ne blâmez pas seulement « l’antivirus » pour un portable qui ne peut pas se refroidir.

Tâche 12 : Mesurer la latence d’une opération lourde en fichiers (avant/après exclusions)

cr0x@server:~$ time find /home/dev/build -type f -maxdepth 4 -print0 | xargs -0 sha256sum >/dev/null
real	0m42.118s
user	0m8.901s
sys	0m31.772s

Ce que cela signifie : Un temps système élevé suggère un overhead noyau/E/S de fichiers — classique avec le scan à l’accès.

Décision : Appliquez une exclusion ciblée pour le répertoire de build et relancez. Si le temps chute fortement, vous avez prouvé la causalité sans désactiver globalement la protection.

Tâche 13 : Inspecter les drivers filtres de système de fichiers chargés (adjacent Windows, mais concept important)

cr0x@server:~$ fltmc
Filter Name                     Num Instances    Altitude    Frame
------------------------------  -------------  ------------  -----
WdFilter                                 10       328010         0
edrFilter                                 8       321200         0
luafv                                    1       135000         0

Ce que cela signifie : Plusieurs filtres sont empilés. L’altitude indique l’ordre ; les interactions comptent. Deux produits scannant les mêmes ouvertures peuvent doubler le travail ou provoquer des deadlocks dans des cas limites.

Décision : Évitez d’exécuter deux scanners en temps réel. Si nécessaire, mettez l’un en mode passif/compatibilité et validez l’ordre des filtres avec les recommandations du fournisseur.

Tâche 14 : Vérifier rapidement l’état de Windows Defender (commun en configurations EDR mixtes)

cr0x@server:~$ powershell -NoProfile -Command "Get-MpComputerStatus | Select AMServiceEnabled,AntispywareEnabled,RealTimeProtectionEnabled,IoavProtectionEnabled"
AMServiceEnabled AntispywareEnabled RealTimeProtectionEnabled IoavProtectionEnabled
---------------- ----------------- ------------------------- ---------------------
            True              True                      True                  True

Ce que cela signifie : La protection en temps réel de Defender est activée. Si vous avez aussi un EDR tiers faisant du scan à l’accès, vous pouvez être en double scan.

Décision : Décidez quel produit est autoritatif pour le scan en temps réel ; mettez l’autre en mode passif si possible, et confirmez via la politique.

Tâche 15 : Vérifier les récents bugchecks Windows (preuves de BSOD)

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -FilterHashtable @{LogName='System'; Id=1001} -MaxEvents 3 | Format-Table TimeCreated,Message -Auto"
TimeCreated           Message
-----------           -------
1/22/2026 8:14:02 AM  The computer has rebooted from a bugcheck. The bugcheck was: 0x0000007e ...
1/22/2026 8:01:44 AM  The computer has rebooted from a bugcheck. The bugcheck was: 0x0000007e ...

Ce que cela signifie : Bugchecks répétés. Si l’horodatage s’aligne sur la mise à jour d’agent/changement de politique, vous avez une piste solide.

Décision : Préservez les crash dumps, arrêtez le déploiement et coordonnez un rollback/hotfix. Ne « réinstallez et passez à autre chose » pas avant d’avoir contenu le risque sur la flotte.

Trois mini-récits d’entreprise issus du terrain

Mini-récit 1 : L’incident causé par une mauvaise hypothèse

L’entreprise avait deux outils endpoint : un EDR tiers et Microsoft Defender. L’équipe sécurité croyait que Defender deviendrait automatiquement passif lorsqu’un agent tiers était installé. Ils l’avaient vu arriver dans certains environnements, et cela est devenu « comment Windows fonctionne » dans leur tête.

Puis une mise à jour Windows est arrivée, et Defender s’est réactivé en mode temps réel sur un sous‑ensemble de machines. Personne n’a tout de suite remarqué, car rien ne « cassait » de façon évidente. Ce qui est arrivé, c’est une lente agonie : les connexions ont pris plus de temps, Outlook gelait aléatoirement et les builds sur les portables développeurs commençaient à expirer lors du dépaquetage des dépendances.

Les SRE ont été appelés parce que « le dépôt d’artefacts est lent ». Ce n’était pas le cas. Les endpoints scannaient chaque archive téléchargée deux fois, et l’un des scanners avait l’inspection profonde d’archives activée. L’équipe stockage a vu un pic d’opérations de métadonnées SMB et a pointé le fichier ; l’équipe réseau a vu plus de TLS vers des endpoints cloud de sécurité et a blâmé la « congestion Internet ». Le classique jeu de ping‑pong des responsabilités.

La correction fut ennuyeuse : définir explicitement Defender en mode passif via une politique sur les machines où l’EDR tiers fournissait le scan en temps réel, et vérifier cela en continu. La leçon fut plus nette : ne jamais compter sur une « coexistence automatique » entre produits de sécurité. Si vous ne pouvez pas décrire la machine d’états, vous ne la contrôlez pas.

Mini-récit 2 : L’optimisation qui s’est retournée

Une autre organisation a essayé de réduire le temps de réponse en activant un blocage agressif « block on first sight » et des lookups cloud pour toute exécution nouvelle. Le fournisseur vendait cela comme plus rapide et plus intelligent pour prévenir les malwares inconnus. Ça marchait — jusqu’à rencontrer une flotte de postes développeurs.

Les développeurs exécutaient des outils internes non signés, construisaient des binaires constamment et exécutaient depuis les répertoires de sortie de build. La nouvelle politique a fait que chaque artefact de build fraîchement créé était traité comme suspect et envoyé pour vérification de réputation. Certaines vérifications prenaient des secondes. D’autres prenaient des minutes quand l’endpoint cloud était lent ou quand l’agent décidait d’uploader plus de contexte.

Soudain, « make test » n’était plus une commande ; c’était une retraite de méditation. Les gens ont commencé à copier les sorties de build dans des répertoires étranges pour « éviter le scan », ce qui a fait l’inverse : cela a créé plus de binaires inconnus à plus d’emplacements, augmentant la surface de scan. L’optimisation a généré une industrie de contournements shadow IT au sein de l’entreprise.

Après deux semaines, l’équipe sécurité a retiré la politique pour les machines développeurs et CI et l’a remplacée par un schéma plus sûr : scan strict pour les téléchargements et pièces jointes, contrôles d’exécution pour les chemins risqués connus et une chaîne de signature pour les outils internes. Le retour de flamme n’était pas la fonctionnalité. C’était l’application sans compréhension de la charge de travail.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la situation

Une entreprise a réellement traité son EDR comme une infrastructure critique. Ils avaient des anneaux : test IT, un petit pilote dans chaque unité, puis un déploiement échelonné au reste. Ils avaient aussi un processus « kill switch » : une manière pré-approuvée de mettre en pause les déploiements et de revenir en arrière sans une semaine de réunions.

Quand un fournisseur a livré une mise à jour qui augmentait l’agressivité de scan sur les fichiers d’archives, l’anneau test IT s’est allumé immédiatement. L’équipe build a remarqué un ralentissement 4× sur un benchmark de compilation standard qu’ils exécutaient après chaque changement d’endpoint. Ils ont déposé un ticket avec logs, horodatages et une charge reproductible en quelques heures.

Parce que le déploiement était échelonné, seul l’anneau test a été affecté. Aucun dirigeant n’a été tiré dans un appel « pourquoi la boîte est en feu ». L’équipe sécurité a travaillé avec le fournisseur, reçu une configuration mise à jour et ajusté des exclusions pour des caches chauds connus.

La pratique était ennuyeuse : un anneau canari, un benchmark et un plan de rollback. Cela a empêché une panne de masse. Voilà le but des opérations ennuyeuses — on n’a pas la une des journaux, mais on dort bien.

Erreurs courantes : symptôme → cause racine → correction

Symptôme : Le PC est « lent », le disque à 100 %, les ventilateurs hurlent

Cause racine : Scan en temps réel de répertoires à fort churn (sorties de build, caches, profils VDI), souvent combiné à l’inspection profonde d’archives.

Correction : Ajouter des exclusions ciblées pour les répertoires éphémères ; changer le mode de scan en scan‑à‑la‑fermeture/à‑l’exécution ; planifier les scans complets en dehors des heures de travail avec des démarrages aléatoires. Valider avec des mesures d’E/S avant/après.

Symptôme : Échecs d’applications aléatoires (« accès refusé », échecs de chargement de DLL)

Cause racine : Blocage comportemental ou faux positifs mettant en quarantaine des binaires nouvellement construits/mis à jour ; parfois Controlled Folder Access ou règles de protection contre les ransomwares appliquées à tort.

Correction : Créer des règles d’autorisation pour les binaires internes signés ; mettre en place la signature de code ; ajuster les règles pour les postes développeurs ; collecter les logs de l’agent et les empreintes pour escalade fournisseur.

Symptôme : Boucle de démarrage ou BSOD juste après une mise à jour d’agent

Cause racine : Driver kernel/minifilter défectueux, incompatibilité avec un patch OS récent, ou installation de driver échouée laissant un état incohérent.

Correction : Arrêter immédiatement le rollout. Utiliser le Mode Sans Échec/récupération pour désactiver le driver/service, revenir à la dernière version d’agent connue bonne, préserver les crash dumps et coordonner avec le fournisseur pour une build corrigée.

Symptôme : Le réseau est instable ; les certificats semblent « incorrects »

Cause racine : Module de protection web agissant comme proxy local ou inspection TLS insérant une CA racine ; conflits avec VPN, proxy d’entreprise ou applications à pinning strict.

Correction : Désactiver l’inspection TLS pour les applications/domaines affectés ; s’assurer du déploiement correct de la CA racine ; valider la compatibilité proxy/VPN dans un anneau pilote.

Symptôme : Les runners CI ou agents de build ralentissent soudainement

Cause racine : EDR installé avec des paramètres workstation par défaut ; scan des répertoires workspace et caches de dépendances ; scan agressif des couches de conteneur.

Correction : Créer une politique CI spécifique : scan en temps réel minimal, scan d’entrée strict (téléchargements), scan d’artefacts au moment de la publication et exclusions agressives pour les workspaces éphémères.

Symptôme : Pics CPU simultanés sur de nombreuses machines

Cause racine : Push de politique déclenchant un scan complet ou un rehash ; mise à jour de définitions/règles provoquant des rescans ; vidage d’un backlog de télémétrie.

Correction : Utiliser des anneaux et des limites de rythme ; désactiver « scanner immédiatement après changement de politique » ; randomiser le démarrage des scans ; plafonner l’utilisation CPU ; surveiller la conformité aux mises à jour vs performance.

Symptôme : Un seul utilisateur est affecté ; les autres vont bien

Cause racine : Corruption locale, mise à jour partielle, logiciel tiers en conflit ou charge de travail atypique (grosse archive mail, repo massif, conteneur chiffré).

Correction : Comparer versions/politiques de l’agent ; réappliquer la politique ; réinstaller l’agent proprement ; recueillir métriques avant/après ; ne pas « corriger la flotte » pour un cas isolé sans preuves.

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

Checklist de contention (lorsque les endpoints cassent activement)

1. Geler le déploiement : arrêter les nouveaux déploiements d’agent et mettre en pause la propagation des politiques dans la console centrale.
2. Identifier les anneaux : déterminer quel groupe a reçu le changement (pilote vs large). Si vous n’avez pas d’anneaux, vous en avez maintenant — commencez par grouper « déjà mis à jour » vs « pas encore ».
3. Capturer des preuves : rassembler logs, versions et horodatages de 3–5 machines affectées et 1 contrôle non affecté.
4. Décider de la portée du rollback : rollback de la politique d’abord si possible ; rollback de la version agent si des problèmes côté driver sont suspectés.
5. Communiquer clairement : note pour les utilisateurs : ce qui est cassé, contournement, ETA et ce qu’il ne faut pas faire (par ex. ne pas réinstaller des nettoyeurs aléatoires).
6. Protéger la sécurité : si vous devez réduire temporairement la protection, compensez (restreindre l’accès réseau, bloquer les téléchargements à haut risque, renforcer les contrôles email) jusqu’à stabilisation.

Checklist stabilité par conception (comment arrêter de répéter cela)

1. Déploiements en anneaux : test → pilote → échelonné. Faites suivre à l’agent la même gestion de changement que le patching OS.
2. SLOs de performance pour endpoints : définir des budgets mesurables (overhead CPU, latence disque, deltas de temps de build) et rejeter les changements qui les violent.
3. Politiques conscientes de la charge : séparer postes développeurs, VDI, serveurs et runners CI. Une politique unique pour tous est la recette de la douleur universelle.
4. Exclusions disciplinées : exclure les répertoires et caches éphémères ; n’excluez pas des disques entiers ; revoir les exclusions trimestriellement.
5. Contrôle du double scan : s’assurer qu’un seul produit effectue le scan en temps réel ; les autres en mode passif/télémétrie.
6. Garde‑fous de mise à jour : éviter « scan complet immédiatement après changement de politique » sur toute la flotte ; randomiser les plannings de scan.
7. Rétention des dumps et logs : conserver ce qui est nécessaire pour prouver un bug de driver ; sinon chaque incident devient superstition.
8. Package d’escalade fournisseur : bundle standard : logs agent, build OS, crash dumps, étapes de reproduction et timeline.

Optimisation orientée stockage des endpoints (parce que les disques souffrent en silence)

1. Ne scannez pas ce que vous pouvez régénérer : sorties de build, caches de dépendances et répertoires temporaires sont généralement sûrs à exclure.
2. Scannez aux frontières : scanner les téléchargements, pièces jointes et artefacts au moment de la publication — les points où le contenu entre ou devient durable.
3. Évitez le deep scanning d’archives par défaut : l’activer sélectivement là où le risque est réel (passerelles email, dossiers de téléchargement), pas partout.
4. VDI : coordonner les scans : étaler les heures de démarrage et plafonner les ressources ; sinon votre stockage partagé devient une victime.

FAQ

1) « Antivirus » est‑il la même chose que l’EDR ?

Non. L’antivirus traditionnel se concentre sur la détection de malwares (signatures/heuristiques). L’EDR ajoute la surveillance comportementale, la télémétrie et des actions de réponse. Beaucoup de produits font les deux aujourd’hui, ce qui explique pourquoi ils peuvent à la fois vous sauver et vous casser.

2) Pourquoi l’antivirus ralentit tant les builds ?

Les builds créent et touchent un très grand nombre de petits fichiers. Le scan en temps réel peut inspecter chaque ouverture/écriture/fermeture, multipliant les E/S. Ajoutez le scan d’archives et vous scannez des dépendances compressées à répétition.

3) Les exclusions sont‑elles dangereuses ?

Certaines le sont. Exclure « C:\ » revient à se rendre. Exclure des répertoires éphémères, régénérables (comme les sorties de build et caches) est généralement acceptable quand c’est associé à des scans à l’ingress (téléchargements) et à la publication (artefacts).

4) Devons‑nous exécuter deux produits antivirus pour la « défense en profondeur » ?

Pas comme deux scanners en temps réel. C’est de la « défense en profondeur sur disque ». Si vous avez besoin de deux outils, mettez‑en un en mode passif/monitoring uniquement, et vérifiez cet état en continu.

5) Comment prouver que l’agent de sécurité est la cause sans le désactiver ?

Mesurez une charge reproductible (hash d’un arbre de répertoires, build d’un repo, décompression d’un ensemble de dépendances), puis appliquez une exclusion étroite et relancez. Si le delta est important, vous avez établi la causalité avec un risque minimal.

6) Quel est l’indicateur le plus rapide d’un problème de politique sur la flotte ?

La corrélation temporelle. Si beaucoup de machines se dégradent dans la même heure et que les logs montrent une mise à jour de politique ou un changement de feature flag, traitez‑le comme un incident de changement et faites un rollback d’abord.

7) Pourquoi des BSOD surviennent‑ils après des mises à jour de sécurité ?

Parce que les outils endpoint embarquent souvent des drivers ou composants filtres. Un bug ou une incompatibilité à ce niveau peut planter l’OS. La voie de correction est autant opérationnelle (stopper le rollout, rollback, collecter les dumps) que technique.

8) Que doivent recevoir les machines développeurs que les postes comptables n’ont pas ?

Des politiques différentes. Les développeurs ont besoin d’exclusions pour les caches de build et d’une approche sensée des « exécutables inconnus » (idéalement signature de code). Les postes comptables peuvent tolérer des contrôles d’exécution plus stricts et un scan plus agressif.

9) De simples améliorations de stockage peuvent‑elles résoudre la douleur antivirus ?

Des SSD plus rapides réduisent le symptôme mais pas la cause. Le scan à l’accès peut toujours saturer des disques rapides et brûler du CPU. Ajustez le modèle de scan ; n’achetez pas juste une solution matérielle.

10) Quel est le meilleur contrôle opérationnel ?

Les déploiements échelonnés avec un interrupteur de rollback. La plupart des désastres antivirus sont dus au fait que « tout le monde l’a reçu en même temps ». Ne faites pas ça.

Conclusion : étapes suivantes pour réduire les incidents

Si votre antivirus peut mettre hors service des endpoints, ce n’est pas « juste un outil ». C’est une partie de votre système d’exploitation. Traitez‑le avec la même discipline : déploiements en anneaux, budgets de performance mesurables et plan de rollback exécutable sous stress.

Faites ceci ensuite :

1. Établir des anneaux pour les changements d’agent et de politique de sécurité (test/pilote/étagé).
2. Définir trois benchmarks endpoint (temps de connexion, temps de build/dépaquetage et test de hachage par parcours de fichiers) et les exécuter après chaque changement.
3. Séparer les politiques pour développeurs, VDI, serveurs et runners CI.
4. Auditer le double scan et imposer le mode passif quand nécessaire.
5. Créer un bundle d’incident standard (logs, versions, horodatages, crash dumps) pour que la prochaine panne devienne un diagnostic rapide, pas du folklore.

L’ironie continuera tant que vous ne changerez pas le workflow autour de l’outil. Le logiciel de sécurité qui casse des PC n’est pas un paradoxe. C’est ce qui arrive quand du code privilégié est livré sans opérations de classe production.