Supprimer le bloatware en toute sécurité : la raison de sécurité qui doit vous importer

Cet article vous a aidé ?

La batterie se vide, les ventilateurs hurlent, et votre laptop « neuf » contient déjà trois updaters, deux barres d’outils et un « assistant » qui n’aide personne. Vous pouvez ignorer la nuisance pendant des mois — jusqu’au jour où un updater devient le point d’appui d’un attaquant, ou qu’un service « d’essai » ouvre discrètement un port à l’écoute sur votre réseau d’entreprise.

En tant que SRE, je me préoccupe du bloatware pour la même raison que des règles de pare-feu inutilisées ou des RBAC Kubernetes orphelins : c’est de la surface d’attaque. La surface d’attaque devient des incidents. Le bloatware n’est pas seulement du bazar ; c’est du code supplémentaire avec des privilèges, des hooks d’autostart, un accès réseau et une propension à être oublié.

Ce qu’est réellement le « bloatware » (et pourquoi les équipes sécurité devraient s’en inquiéter)

Les gens appellent « bloatware » tout ce qu’ils n’aiment pas. C’est émotionnellement compréhensible, mais opérationnellement inutile. Pour une suppression sûre, il vous faut des catégories, car les catégories prédisent les modes de défaillance.

Catégorie A : utilitaires OEM préinstallés et « value add »

Ils proviennent du fabricant ou du revendeur : « assistants de support », gestionnaires de pilotes, « améliorateurs audio », essais de VPN, essais de synchronisation de stockage et l’éternel « optimiseur système ». Ils démarrent souvent au boot, sont livrés avec des privilèges élevés et contactent régulièrement leurs serveurs pour les mises à jour.

Catégorie B : bundles tiers et helpers proches de l’adware

Barres d’outils, notificateurs de coupons, extensions de navigateur, « assistants de recherche ». Ils ont peut‑être moins de privilèges mais sont souvent un pipeline direct vers des canaux de mise à jour douteux.

Catégorie C : applications intégrées de l’OS que vous n’utilisez pas

Sur Windows : packages Appx préprovisionnés et tâches d’arrière-plan. Sur macOS : éléments de connexion et launch agents. Sur Linux : paquets ramenés par des méta-paquets, bibliothèques orphelines et services activés par défaut.

Catégorie D : bloat interne (oui, les entreprises en envoient aussi)

Agents legacy, anciens outils endpoint, clients VPN abandonnés, reliquats de migration. Des logiciels « temporaires » qui deviennent permanents. Si vous avez déjà trouvé trois agents de télémétrie concurrents sur un laptop, bienvenue en entreprise.

Du point de vue de la fiabilité, le bloatware consomme CPU, RAM, I/O disque et rallonge le temps de démarrage. Du point de vue de la sécurité, c’est pire : il ajoute surface d’attaque, chemins de code privilégiés et mécanismes de mise à jour. Les mécanismes de mise à jour sont essentiellement des pipelines d’exécution de code à distance mieux marketés.

Blague n°1 : le bloatware, c’est comme une « réunion rapide » qui invite huit personnes — personne n’a demandé, et pourtant ça obtient des droits administrateur.

Faits intéressants et courte histoire : comment on en est arrivés là

Six à dix faits concrets, parce que le contexte vous aide à prédire ce que feront les fournisseurs :

  1. Le « crapware » est devenu courant au début des années 2000 lorsque les marges PC ont diminué et que les OEM monétisaient en préinstallant des essais et des apps sponsorisées.
  2. Les barres d’outils de navigateur furent une mine d’or du bloatware car elles pouvaient changer la recherche par défaut et générer des revenus publicitaires—souvent via des installateurs agressifs et un consentement douteux.
  3. Les auto-updaters ont explosé quand le logiciel est devenu « toujours à jour » ; chaque fournisseur voulait son service de mise à jour en arrière-plan, même quand l’OS en fournissait déjà un.
  4. Les logiciels de sécurité fournis en bundle étaient parfois un canal commercial, pas une stratégie de sécurité ; « antivirus gratuit 30 jours » n’était pas installé pour vous protéger mais pour vous convertir.
  5. La signature de code n’a pas éliminé le risque lié au bloatware ; elle a rendu la confiance plus facile et le blocage plus difficile. Les attaquants ont appris à abuser des canaux de mise à jour signés légitimes.
  6. Les systèmes d’exploitation ont commencé à préinstaller davantage d’apps grand public pour concurrencer sur l’attention et les services, brouillant la frontière entre composant OS et application supprimable.
  7. L’imagerie d’entreprise a réduit le bloat OEM—jusqu’au BYOD et aux livraisons directes. Les achats modernes (livraison directe au domicile) ont réintroduit les charges OEM dans les flottes d’entreprise.
  8. Les « driver helper » sont devenus populaires à mesure que les piles matérielles se complexifiaient, puis sont devenus des cibles attrayantes car ils tournent souvent avec de hauts privilèges et un accès profond au système.
  9. Le bloatware moderne vit souvent dans les tâches planifiées et les launch agents parce que la persistance est le produit ; l’application UI n’en est que la mascotte.

Modèle de menace : la raison de sécurité qui doit vous importer

Si vous voulez l’argument de sécurité en une ligne : le bloatware augmente le nombre de façons dont un attaquant peut exécuter du code sur votre machine.

1) Surface d’attaque : plus de paquets, plus de parseurs, plus de bugs

Chaque composant installé est un ensemble de binaires, services, bibliothèques, extensions de navigateur et pilotes. Beaucoup analysent des données : manifests de mise à jour, réponses réseau, fichiers locaux, métadonnées USB. Les parseurs sont l’endroit où vivent les bugs. Certains deviennent des vulnérabilités. Les autres deviennent des plantages et des comportements bizarres que vous prenez pour « Windows qui fait Windows ».

2) Privilège : le bloatware aime SYSTEM/root

Les assistants de support et gestionnaires de pilotes tournent souvent en tant que SYSTEM (Windows) ou root (macOS/Linux) parce que « ça doit installer des mises à jour ». C’est une exigence raisonnable, mais cela signifie que tout bug dans ce canal est une potentielle élévation de privilège ou exécution de code à distance.

3) Persistance : l’autostart est une fonctionnalité pour vendeurs et attaquants

Entrées de démarrage, tâches planifiées, services systemd, launch agents : ce sont légitimes. Ce sont aussi les premiers endroits où les répondeurs d’incident regardent pour la persistance. Le bloatware ajoute du bruit à ces listes, rendant la persistance malveillante plus difficile à repérer.

4) Chaîne d’approvisionnement : les updaters sont des chemins de confiance

Même quand l’app installée est inoffensive, l’updater est un mécanisme de distribution. Si un attaquant compromet la pipeline de mise à jour du fournisseur — ou le processus de mise à jour client — il obtient de l’exécution de code à grande échelle.

5) Télémétrie et confidentialité : les exhaustions de données comptent

Certain bloatware collecte des diagnostics. En contexte entreprise, cela peut fuir la liste des logiciels installés, les noms d’hôtes, les motifs d’activité utilisateur et parfois des identifiants qui aident les attaquants ou permettent du phishing ciblé. Ce n’est pas toujours malveillant ; c’est souvent excessif.

6) Fiabilité et réalité SRE : le bloatware casse le banal

Il interfère avec les clients VPN, les proxys, les stores de certificats, les pilotes réseau et le chiffrement de disque. Et quand il casse ces éléments, la solution n’est rarement pas « réinstaller l’assistant OEM ». C’est « reimager le dispositif », ce qui est l’option nucléaire avec un coût humain.

Une citation, parce qu’elle reste la meilleure formulation pour la sanity opérationnelle. Le principe de John Gall est souvent cité ainsi : « A complex system that works is invariably found to have evolved from a simple system that worked. » (John Gall). Le bloatware vous pousse dans la direction opposée : plus complexe, moins compris, moins prévisible.

Mode opératoire de diagnostic rapide : trouver vite le goulot et le risque

C’est le workflow « j’ai 20 minutes avant le prochain appel incident ». Il est volontairement impitoyable.

Premier : identifiez ce qui est réellement lent ou risqué

  • La machine est-elle lente au démarrage ? Concentrez-vous sur les tâches/services de démarrage.
  • Est‑elle lente en usage normal ? Concentrez‑vous sur la CPU, la pression mémoire et les updaters en arrière‑plan.
  • Le risque est‑il orienté sécurité ? Concentrez‑vous sur les services privilégiés, les écouteurs réseau et les mécanismes de mise à jour.

Deuxième : inventoriez persistance et privilège

  • Listez les services activés et les tâches planifiées.
  • Listez les programmes de démarrage/éléments de connexion.
  • Trouvez ce qui tourne en tant que SYSTEM/root.

Troisième : inventoriez l’exposition réseau

  • Listez les ports à l’écoute.
  • Identifiez quel processus en est propriétaire.
  • Décidez si ce listener est attendu.

Quatrième : suppression avec rollback en tête

  • Préférez désactiver → observer → désinstaller pour tout ce qui pourrait être lié à des pilotes, VPN ou outils de gestion.
  • Prenez un snapshot/point de restauration ou ayez une procédure de rollback testée.
  • Vérifiez après suppression : démarrage, réseau, VPN, impression, audio/vidéo, chiffrement disque et santé des mises à jour.

Tâches pratiques avec commandes : inventorier, décider, supprimer, vérifier

Ci‑dessous des tâches réelles que vous pouvez exécuter. Chaque entrée inclut : commande, sortie d’exemple, ce que cela signifie et la décision à prendre. Je mélange Linux/macOS/Windows parce que le bloatware ne respecte pas les frontières de plateforme. Exécutez ce qui convient à votre parc.

Task 1 (Linux): list running services and spot obvious passengers

cr0x@server:~$ systemctl list-units --type=service --state=running
UNIT                               LOAD   ACTIVE SUB     DESCRIPTION
cron.service                        loaded active running Regular background program processing daemon
ssh.service                         loaded active running OpenBSD Secure Shell server
packagekit.service                  loaded active running PackageKit Daemon
cups.service                        loaded active running CUPS Scheduler
avahi-daemon.service                loaded active running Avahi mDNS/DNS-SD Stack

Ce que cela signifie : Tout ce qui n’est pas requis pour le rôle de l’hôte est un candidat. Sur un serveur, avahi-daemon et cups sont fréquemment du type « pourquoi est‑ce présent ? »

Décision : Si ce n’est pas nécessaire, désactivez d’abord. Si rien ne casse, désinstallez.

Task 2 (Linux): confirm which services are enabled at boot

cr0x@server:~$ systemctl list-unit-files --type=service --state=enabled
UNIT FILE                     STATE   PRESET
ssh.service                    enabled enabled
cron.service                   enabled enabled
packagekit.service             enabled enabled
cups.service                   enabled enabled
avahi-daemon.service           enabled enabled

Ce que cela signifie : « Enabled » est la persistance. C’est là que vit le bloatware quand il veut survivre aux reboots.

Décision : Pour les services non essentiels, désactivez‑les et surveillez les logs et les retours utilisateurs.

Task 3 (Linux): see what’s listening on the network

cr0x@server:~$ ss -lntup
Netid State  Recv-Q Send-Q Local Address:Port  Peer Address:Port Process
tcp   LISTEN 0      128    0.0.0.0:22         0.0.0.0:*     users:(("sshd",pid=812,fd=3))
tcp   LISTEN 0      128    127.0.0.1:631      0.0.0.0:*     users:(("cupsd",pid=905,fd=7))
udp   UNCONN 0      0      0.0.0.0:5353       0.0.0.0:*     users:(("avahi-daemon",pid=742,fd=12))

Ce que cela signifie : Un démon d’impression et mDNS sur un serveur sont rarement justifiés. Même sur des laptops, vous voulez savoir qu’ils sont là.

Décision : Si un service écoute et que vous n’en avez pas besoin, désactivez/le désinstallez. Les écouteurs réseau sont une ligne droite vers « exposition inattendue ».

Task 4 (Linux): map a listener to the package that owns it

cr0x@server:~$ dpkg -S /usr/sbin/cupsd
cups-daemon: /usr/sbin/cupsd

Ce que cela signifie : Vous savez maintenant quoi supprimer (cups-daemon), pas seulement quel processus tuer temporairement.

Décision : Supprimez le paquet si la politique le permet et après validation qu’il n’est pas requis.

Task 5 (Linux): disable before uninstalling (safer)

cr0x@server:~$ sudo systemctl disable --now cups.service
Removed "/etc/systemd/system/printer.target.wants/cups.service".

Ce que cela signifie : Le service est arrêté maintenant et ne démarrera pas au boot.

Décision : Observez le comportement du système. Si rien ne casse (flux d’impression, intégrations bureau), procédez à la désinstallation.

Task 6 (Linux): uninstall and check for orphans

cr0x@server:~$ sudo apt-get remove --purge -y cups-daemon
Removing cups-daemon (2.4.7-1ubuntu1) ...
Purging configuration files for cups-daemon (2.4.7-1ubuntu1) ...

Ce que cela signifie : Paquet supprimé et config purgée. Bien : moins de résidus pour confondre des audits futurs.

Décision : Suivez avec autoremove pour nettoyer les dépendances—mais revoyez avant.

Task 7 (Linux): review what autoremove wants to delete

cr0x@server:~$ sudo apt-get -s autoremove
Remv cups-client [2.4.7-1ubuntu1]
Remv libcups2:amd64 [2.4.7-1ubuntu1]
Remv avahi-daemon [0.8-5ubuntu5]

Ce que cela signifie : Le mode simulation (-s) montre ce qui serait supprimé. Si cela veut supprimer des dépendances cœur, stoppez et réévaluez.

Décision : Si ça ne supprime que des composants liés que vous ne voulez pas non plus, lancez‑le réellement. Si ça touche quelque chose de critique, n’y touchez pas.

Task 8 (macOS): list login items and background items

cr0x@server:~$ osascript -e 'tell application "System Events" to get the name of every login item'
{"AcmeUpdater","ChatWidget","PrinterHelper"}

Ce que cela signifie : Les login items s’exécutent à la connexion utilisateur. Les entrées « Updater » sont des points de persistance communs au bloatware.

Décision : Si un item n’est pas requis pour l’usage métier, supprimez‑le ou désactivez‑le via la politique MDM.

Task 9 (macOS): inspect LaunchAgents and LaunchDaemons

cr0x@server:~$ ls -1 /Library/LaunchAgents /Library/LaunchDaemons | head
/Library/LaunchAgents:
com.acme.updater.plist
com.vendor.chatwidget.plist

/Library/LaunchDaemons:
com.acme.privilegedhelper.plist
com.vendor.driverhelper.plist

Ce que cela signifie : Les LaunchDaemons tournent typiquement en root. Ce sont ceux qui transforment « énervant » en « frontière de sécurité ».

Décision : Pour les éléments inconnus, identifiez le chemin du binaire à l’intérieur du plist avant de retirer quoi que ce soit.

Task 10 (macOS): read a plist to see what actually executes

cr0x@server:~$ plutil -p /Library/LaunchDaemons/com.acme.privilegedhelper.plist | head -20
{
  "Label" => "com.acme.privilegedhelper"
  "ProgramArguments" => [
    0 => "/Library/PrivilegedHelperTools/acmehelper"
    1 => "--daemon"
  ]
  "RunAtLoad" => 1
}

Ce que cela signifie : Vous avez maintenant le chemin de l’exécutable. Vous pouvez le hasher, vérifier la signature et déterminer la propriété.

Décision : Si le helper n’est pas requis et pas géré, désactivez/le déchargez et supprimez proprement l’application associée.

Task 11 (Windows via PowerShell): list installed software (traditional MSI)

cr0x@server:~$ powershell -NoProfile -Command "Get-ItemProperty HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\* | Select-Object DisplayName,DisplayVersion,Publisher | Sort-Object DisplayName | Select-Object -First 8"
DisplayName                 DisplayVersion Publisher
-----------                 -------------- ---------
Acme Support Assistant      4.2.1          Acme Corp
Contoso PDF Trial           1.0.0          Contoso
OEM Driver Updater          2.9.0          OEM Vendor

Ce que cela signifie : C’est votre inventaire de base pour les installations de type MSI. Il manquera certaines apps du Store et des installations par utilisateur.

Décision : Marquez tout ce qui a un comportement de mise à jour, des pilotes, des hooks VPN ou des services en arrière‑plan.

Task 12 (Windows via PowerShell): list provisioned Appx packages (baked into images)

cr0x@server:~$ powershell -NoProfile -Command "Get-AppxProvisionedPackage -Online | Select-Object DisplayName,Version | Sort-Object DisplayName | Select-Object -First 8"
DisplayName                         Version
-----------                         -------
Microsoft.XboxApp                   48.72.11001.0
Microsoft.SkypeApp                  15.115.3201.0
Microsoft.ZuneMusic                 11.2401.12.0

Ce que cela signifie : Les packages provisionnés s’installent pour les nouveaux utilisateurs. Même si vous les retirez pour un utilisateur, ils peuvent revenir pour le suivant.

Décision : En entreprise, supprimez‑les au niveau de l’image/politique MDM si vous ne les voulez vraiment pas.

Task 13 (Windows via PowerShell): list startup commands

cr0x@server:~$ powershell -NoProfile -Command "Get-CimInstance Win32_StartupCommand | Select-Object Name,Command,Location | Sort-Object Name | Select-Object -First 8"
Name              Command                                   Location
----              -------                                   --------
AcmeUpdater       ""C:\Program Files\Acme\updater.exe""     HKLM:Run
ChatWidget        ""C:\Program Files\Chat\chatwidget.exe""  Startup

Ce que cela signifie : Les entrées de démarrage sont des points de persistance. Elles expliquent aussi « pourquoi ma CPU chauffe au repos ».

Décision : Désactivez ce dont vous n’avez pas besoin ; si l’app est inutile, désinstallez‑la.

Task 14 (Windows via PowerShell): list scheduled tasks likely to be updaters

cr0x@server:~$ powershell -NoProfile -Command "Get-ScheduledTask | Where-Object { $_.TaskName -match 'Update|Updater|Assistant|Telemetry' } | Select-Object TaskName,State,TaskPath | Select-Object -First 10"
TaskName                 State   TaskPath
--------                 -----   --------
Acme Support Update      Ready   \Acme\
OEM Driver Updater       Ready   \OEM\
Vendor Telemetry Agent   Ready   \Vendor\

Ce que cela signifie : Les tâches peuvent tourner avec de hauts privilèges et à des heures improbables. Elles peuvent aussi ressusciter un logiciel supprimé.

Décision : Si une tâche appartient à un logiciel supprimable, désinstallez le logiciel d’abord ; puis supprimez la tâche si elle subsiste.

Task 15 (Windows via PowerShell): check for listening ports and owning process

cr0x@server:~$ powershell -NoProfile -Command "Get-NetTCPConnection -State Listen | Select-Object LocalAddress,LocalPort,OwningProcess | Sort-Object LocalPort | Select-Object -First 8"
LocalAddress LocalPort OwningProcess
------------ --------- -------------
0.0.0.0      135       1036
0.0.0.0      445       4
127.0.0.1    49664     8120

Ce que cela signifie : Tout écouteur n’est pas mauvais, mais tout écouteur doit être compris. Les écouteurs loopback comptent toujours pour des chaînes d’escalade de privilèges locales.

Décision : Mappez les PIDs inconnus aux processus et décidez s’ils sont légitimes.

Task 16 (Windows via PowerShell): map PID to process path

cr0x@server:~$ powershell -NoProfile -Command "Get-Process -Id 8120 | Select-Object Id,ProcessName,Path"
Id   ProcessName   Path
--   -----------   ----
8120 AcmeHelper    C:\Program Files\Acme\Helper\acmehelper.exe

Ce que cela signifie : Vous pouvez maintenant valider l’éditeur/la signature, vérifier la raison d’installation et supprimer si inutile.

Décision : Si c’est un helper OEM sans valeur métier, retirez‑le et vérifiez qu’aucune dépendance ne subsiste (pilotes, raccourcis clavier, stations d’accueil).

Task 17 (Linux): show installed packages sorted by install time (spot “why is this on my server?”)

cr0x@server:~$ zgrep " install " /var/log/dpkg.log* | tail -5
2025-11-02 10:41:03 install avahi-daemon:amd64 <none> 0.8-5ubuntu5
2025-11-02 10:41:04 install cups-daemon:amd64 <none> 2.4.7-1ubuntu1
2025-11-02 10:41:09 install packagekit:amd64 <none> 1.2.6-5

Ce que cela signifie : Vous pouvez corréler des installations avec des changements, images ou automatisations. Les installations surprises viennent souvent de méta-paquets ou de scripts « helpful ».

Décision : Si une installation n’est pas venue de votre pipeline de build, traitez‑la comme dérive de configuration et corrigez le pipeline, pas seulement l’hôte.

Task 18 (Linux): find large packages (disk bloat is also operational bloat)

cr0x@server:~$ dpkg-query -Wf '${Installed-Size}\t${Package}\n' | sort -n | tail -5
210000  linux-image-6.5.0-25-generic
230000  snapd
310000  libreoffice-common

Ce que cela signifie : La taille n’est pas synonyme de risque, mais les gros paquets apportent souvent beaucoup de dépendances et de services.

Décision : Sur serveurs, retirez les stacks de bureau et suites bureautiques à moins que la mission de l’hôte soit littéralement de les exécuter.

Blague n°2 : supprimer le bloatware, c’est comme nettoyer le garage — la moitié du temps vous trouvez un « outil indispensable » que vous avez apparemment acheté trois fois.

Trois mini-récits d’entreprise depuis le terrain

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

L’entreprise a renouvelé sa flotte. Nouveaux laptops, expédiés directement aux employés. L’IT était fier : enrollement MDM, chiffrement disque, politiques de base. L’hypothèse était simple : « Si c’est enrollé, c’est conforme. » C’est le genre de phrase qui vieillit mal.

Un mois plus tard, quelques endpoints ont commencé à faire des requêtes DNS étranges. Pas du niveau malware évident, plutôt « pourquoi un laptop corporate parle à ce domaine toutes les 15 minutes ». L’équipe sécurité a extrait des logs, trouvé un processus nommé comme un utilitaire de support, et l’a initialement balayé comme du stuff OEM.

La mauvaise hypothèse : les « assistants OEM » sont bénins. En réalité, un de ces utilitaires avait son propre updater, tournait avec des privilèges élevés et utilisait un chemin réseau contournant la configuration proxy de l’entreprise. Il n’était pas compromis de façon cinématographique. C’était juste un logiciel non géré avec son propre cycle de vie et ses propres opinions sur la confiance.

La correction n’a pas été héroïque. Ils ont bloqué les domaines, ensuite poussé une politique pour supprimer l’utilitaire, puis—plus important—changé la procurement : les appareils étaient livrés sans preload OEM, ou reimagés avant que l’enrôlement soit considéré « fini ». La conformité est devenue « enrollé plus inventaire propre », pas « enrollé donc propre ».

Mini-récit 2 : l’optimisation qui s’est retournée contre eux

Une autre organisation poursuivait des temps de démarrage plus rapides sur des kiosques Windows partagés. Quelqu’un a remarqué une foule de tâches planifiées : updaters, télémétrie, tâches vendor. La décision a été de tout supprimer. Radicalement. Si ce n’était pas Microsoft, c’était parti.

Le temps de démarrage s’est amélioré. Les tickets ont baissé. Tout le monde s’est félicité. Puis, des semaines plus tard, une vague de pannes d’appareils a frappé : les stations d’accueil n’ont plus négocié correctement les écrans, la stabilité du pilote Wi‑Fi s’est dégradée, et les périphériques audio disparaissaient après la mise en veille.

Le « bloatware » qu’ils avaient supprimé incluait le canal de mise à jour des pilotes OEM et un service de gestion matérielle qui (malheureusement) contenait aussi la colle politique pour certains quirks de firmware. Windows Update ne le remplaçait pas complètement pour cette ligne de modèles. L’optimisation était réelle, et elle s’est quand même retournée contre eux.

La récupération a consisté à reconstruire un ensemble approuvé plus petit : conserver les services matériels minimaux requis pour les pilotes et firmwares, supprimer le reste et mettre le tout sous contrôle de version. Ils ont aussi appris à étager les suppressions : désactiver d’abord, tester sur un anneau pilote, puis déployer. L’incident n’était pas une erreur de vouloir retirer le bloatware. C’était une erreur de le faire aveuglément.

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

Une société financière exploitait des jump hosts Linux pour les administrateurs. Ces boîtes étaient ennuyeuses par conception : pas d’environnement de bureau, pas de stack d’impression, paquets minimaux, règles sortantes strictes. Quelqu’un les a qualifiées de « sans âme ». C’était un compliment.

Pendant une large alerte chaîne d’approvisionnement, l’organisation a dû répondre vite à une question difficile : « Exécutons‑nous des auto-updaters tiers ou des agents de gestion qui contactent des canaux non approuvés ? » Ils n’ont pas paniqué. Ils ont exécuté leur playbook d’inventaire et l’ont comparé au manifeste de paquets baseline.

L’important : ils avaient un manifeste baseline. Il vivait dans leur repo de gestion de configuration. Il était relu. Il était appliqué. La dérive était détectée automatiquement. Donc quand les auditeurs ont demandé, ils ont pu montrer : voici les services activés, voici les paquets installés, voici les écouteurs, et voici les diffs dans le temps.

Ils avaient encore du travail—tout le monde en a—mais la réponse incident n’a pas impliqué de conjectures. La pratique ennuyeuse (builds minimaux + détection de dérive) a permis de gagner des jours de travail et d’éviter beaucoup de « hot fixes » risqués sous pression.

Erreurs courantes (symptômes → cause racine → correction)

Voici la partie où la plupart des efforts de debloating échouent : pas parce que la suppression est impossible, mais parce que les gens suppriment la mauvaise chose dans le mauvais ordre.

1) Symptom: “After removing bloatware, Wi‑Fi or Bluetooth is flaky”

Cause racine : Vous avez supprimé un service OEM qui gérait aussi des pilotes, du firmware ou des quirks de gestion d’énergie pour cette ligne de périphériques.

Correction : Réinstallez le paquet de support matériel minimal ou passez à une méthode de distribution de pilotes approuvée par le vendeur. En entreprise, figez et testez les versions de pilotes. Ne comptez pas sur des helpers mystérieux.

2) Symptom: “The app is gone but it keeps coming back”

Cause racine : Packages provisionnés (Appx), tâches planifiées ou outils de gestion réinstallent l’app. Sur macOS, un launch daemon peut recréer des composants.

Correction : Supprimez au niveau de la provision (AppxProvisionedPackage), supprimez la tâche planifiée après la désinstallation, et mettez à jour les politiques MDM pour empêcher la réinstallation.

3) Symptom: “CPU usage is still high at idle”

Cause racine : Vous avez supprimé l’UI mais pas le service/updater en arrière‑plan. Ou vous avez plusieurs agents concurrents (télémétrie, sécurité, gestion).

Correction : Inventoriez à nouveau les services en cours et les entrées de démarrage. Cherchez les updaters et la télémétrie. Supprimez/désactivez le service, pas seulement le raccourci bureau.

4) Symptom: “Disk space didn’t improve”

Cause racine : Répertoires de cache, anciens installateurs et logs restent. Sur Linux, les dépendances restent jusqu’à autoremove. Sur Windows, les installateurs vivent dans des caches.

Correction : Utilisez les outils natifs de nettoyage de l’OS et relevez les dépendances. Ne supprimez pas des dossiers aléatoires dans Program Files ; désinstallez proprement, puis nettoyez les caches connus.

5) Symptom: “VPN fails after removal”

Cause racine : Vous avez supprimé un driver filtre réseau, un helper de certificats ou un composant split‑tunnel installé par un utilitaire vendeur qui emballait des « features » non liées.

Correction : Réinstallez uniquement le client VPN supporté. Si le VPN s’appuyait sur des utilitaires OEM, corrigez cette architecture—séparez les responsabilités.

6) Symptom: “Security agent says ‘tampering detected’ after debloating”

Cause racine : Vous avez supprimé quelque chose dont la plateforme de sécurité dépend (intégration store de certificats, provider ETW, module kernel) ou vous avez effectué la suppression avec des droits admin en dehors des outils approuvés.

Correction : Travaillez avec la politique endpoint security. Utilisez des scripts de suppression sanctionnés. Validez les exclusions. Ne combattez pas vos propres contrôles en production.

7) Symptom: “Boot is slower after cleanup”

Cause racine : Vous avez déclenché des auto‑réparations d’installateurs répétées, des services cassés qui réessayent, ou du spam de logs. Certains uninstallers laissent des entrées d’autostart cassées.

Correction : Supprimez les tâches/services orphelins. Validez les logs. Sur Windows, vérifiez les éléments de démarrage et tâches planifiées ; sur Linux, vérifiez les échecs systemd.

Listes de contrôle / plan pas à pas (ennuyeux volontairement)

Voici le plan qui ne vous rendra pas célèbre, mais vous gardera employé.

Checklist 1: before you remove anything

  • Définissez l’objectif : performance, durcissement sécurité, conformité, ou les trois.
  • Classifiez le système : appareil personnel, endpoint géré, serveur, kiosk, poste réglementé.
  • Capturez une baseline : liste des logiciels installés, services activés, tâches planifiées, écouteurs, et métriques de boot.
  • Confirmez la propriété : le logiciel est‑il OEM, OS, sécurité, géré par l’IT ou installé par l’utilisateur ?
  • Planifiez le rollback : point de restauration/snapshot, procédure de reimage et manifeste de paquets connu‑bon.

Checklist 2: removal order (minimize blast radius)

  1. Désactivez l’autostart (service/tâche/élément de connexion) d’abord.
  2. Observez pendant un jour sur un anneau pilote : démarrage, mise en veille/réveil, VPN, Wi‑Fi, docking, impression.
  3. Désinstallez en utilisant les méthodes natives de l’OS.
  4. Retirez les résidus (tâches planifiées, launch agents, paquets orphelins) soigneusement.
  5. Vérifiez qu’il n’y a plus d’écouteurs, de démons privilégiés, ni de réinstallation récurrente.
  6. Appliquez via MDM/gestion de configuration pour empêcher le retour.

Checklist 3: enterprise hygiene that makes bloatware stay gone

  • Golden image ou baseline déclarative (même si vous utilisez la « modern management », vous avez besoin d’une baseline).
  • Allowlist/denylist logiciel liée à l’inventaire.
  • Anneaux pilotes pour suppressions et changements de pilotes.
  • Détection de dérive sur paquets/services/écouteurs.
  • Une stratégie d’updater par classe de logiciel. Moins d’updaters, moins de surprises.

FAQ

1) Is bloatware actually a security problem, or just annoying?

Problème de sécurité. L’ennui est le symptôme ; la surface d’attaque est la maladie. Les services privilégiés et les updaters sont des cibles de haute valeur.

2) Should I remove every preinstalled app?

Non. Supprimez ce dont vous n’avez pas besoin, mais conservez les composants critiques pour le matériel sauf si vous avez un plan de remplacement testé (pilotes, outils de firmware, support docking).

3) What’s the safest first move?

Désactiver l’autostart (services/tâches/éléments de connexion) avant de désinstaller. Si la désactivation n’entraîne pas de régressions, la désinstallation devient sans drama.

4) Why do “support assistants” and “driver updaters” worry SREs?

Ils tournent souvent élevés, interagissent avec pilotes/firmware et maintiennent leurs propres canaux de mise à jour. C’est puissant—et le pouvoir nécessite de la gouvernance.

5) Can removing bloatware break security tooling?

Oui. Certaines piles endpoint s’intègrent avec des pilotes, certificats ou filtres réseau. En environnements gérés, coordonnez‑vous avec sécurité/IT et utilisez des scripts approuvés.

6) How do I prove bloatware is responsible for performance issues?

Mesurez avant/après : temps de boot, CPU au repos, pression mémoire et I/O disque. Corrélez à des services spécifiques et des entrées de démarrage, pas aux impressions subjectives.

7) What if the software keeps reinstalling itself?

Cherchez des tâches planifiées, des packages provisionnés ou des politiques MDM. Supprimer l’app visible ne suffit pas ; il faut supprimer le mécanisme de réinstallation.

8) Is it better to uninstall or to reimage?

Pour des systèmes personnels ponctuels, la désinstallation suffit si vous êtes prudent. Pour les flottes d’entreprise, reimager vers une baseline connue est souvent plus rapide, plus sûr et plus répétable.

9) How do I handle bloatware on servers?

Soyez stricts. Les serveurs doivent être minimaux : pas de stack d’impression, pas de mDNS, pas de paquets bureau. Supprimez tout ce qui n’est pas lié au rôle du serveur et appliquez via gestion de configuration.

10) What’s the biggest debloating anti-pattern?

« Supprimer des dossiers au hasard jusqu’à ce que ça marche. » C’est comme ça qu’on finit avec des services cassés qui réessaient au boot, des erreurs DLL mystérieuses et un week‑end non prévu.

Conclusion : prochaines étapes réalisables aujourd’hui

Si vous ne faites rien d’autre, faites ces trois choses :

  1. Inventoriez la persistance : services, tâches planifiées, éléments de connexion. Le bloatware qui ne persiste pas n’est pour la plupart que du désordre.
  2. Inventoriez l’exposition : ports à l’écoute et démons privilégiés. Si vous ne pouvez pas expliquer un listener, il ne reste pas.
  3. Supprimez en sécurité : désactiver → observer → désinstaller → vérifier → appliquer une politique pour que ça reste supprimé.

Sur les systèmes de production — et les endpoints sont des systèmes de production avec un clavier — supprimer le bloatware n’est pas un rituel de pureté. C’est une réduction de risque. Vous réduisez le nombre de choses qui peuvent casser, le nombre de choses qui peuvent être exploitées et le nombre de choses qui vous surprendront à 2 h du matin. C’est une victoire mesurable.

← Précédent
Résolveurs DNS : pourquoi la mise en cache aggrave les pannes (et comment la maîtriser)
Suivant →
Wi‑Fi se déconnecte toutes les 10 minutes : le paramètre avancé du pilote qui le corrige

Laisser un commentaire