Installer Windows sans bloat : les réglages essentiels au premier démarrage

Les trois principes du premier démarrage : réduire les surprises, réduire le travail en arrière-plan, faciliter la récupération

1) Réduire les surprises : la machine doit faire ce que vous attendez

« Le bloat » n’est pas seulement des applications. C’est aussi du bloat comportemental : des réglages qui changent discrètement, des téléchargements en arrière-plan,
des aides au démarrage automatiques, des pilotes « remplacés » de façon « utile », et des notifications qui habituent vos utilisateurs à ignorer les alertes.
Le premier démarrage est l’endroit où vous décidez si votre installation Windows sera une station de travail ou une machine à sous.

2) Réduire le travail en arrière-plan : l’inactivité doit rester principalement inactive

Une installation Windows toute neuve a tendance à être occupée : indexation, analyse Defender, mises à jour du Store, configuration de OneDrive,
agents OEM, installateurs Teams, widgets, envois de télémétrie, Delivery Optimization et mises à jour de pilotes.
Certains sont légitimes ; beaucoup sont optionnels. Votre objectif n’est pas de tout désactiver — il est de rendre le travail en arrière-plan
prévisible et borné. « Mon portable fait tourner les ventilateurs dès que j’arrête de taper » n’est pas une fonctionnalité.

3) Faciliter la récupération : chaque réglage doit être réversible

Sur des systèmes en production, la fiabilité vaut mieux que l’astuce. Il en va de même ici. Préférez les bascules de paramètres aux bidouilles du registre.
Préférez « désactiver une entrée au démarrage » à « supprimer des binaires ». Préférez des politiques faciles à auditer. Et conservez une trace écrite :
ce que vous avez changé, quand et pourquoi.

Il existe une idée paraphrasée de Werner Vogels (CTO d’Amazon) que les opérations internalisent : construire des systèmes « opérables » en priorité — faciles à surveiller, diagnostiquer et récupérer.
Une configuration Windows au premier démarrage doit aussi être opérable.

Brève histoire & faits intéressants (pourquoi Windows se comporte ainsi)

• Windows XP et l’« ère du dossier Démarrage » : les premiers bloat vivaient souvent dans des endroits évidents (dossier Démarrage, clés Run). Le bloat moderne préfère les tâches planifiées et les services — plus difficiles à repérer, plus faciles à persister.
• La « télémétrie » est devenue un véritable sous‑système : Windows 10 a formalisé les pipelines de données diagnostiques ; ce qui était autrefois des journaux éparpillés est devenu un canal configurable, piloté par des politiques.
• Le Microsoft Store a changé le cycle de vie des applications : le packaging UWP/MSIX a rendu les installations/mises à jour plus faciles — et a aussi rendu les installations « suggérées » indolores.
• L’indexation Windows Search a été réécrite plusieurs fois : elle est meilleure qu’avant, mais l’indexation au premier démarrage plus Defender plus OneDrive peut encore saturer un petit SSD.
• Delivery Optimization est essentiellement un système P2P de mise à jour : il peut utiliser votre liaison montante et votre disque pour aider d’autres PC, ce qui est excellent dans le bon contexte et exaspérant dans le mauvais.
• La culture des préinstallations OEM n’est pas morte ; elle s’est juste rebrandée : « SupportAssist », « Optimizer », « Updater », « Experience », « Hub ». Même histoire, plus jolies icônes.
• Les plans d’alimentation sont devenus moins visibles : Windows moderne cache certains réglages derrière des « modes d’alimentation » et du firmware OEM. Le vieux débat « Haute performance » vs « Équilibré » s’est déplacé dans les piles de pilotes et les politiques.
• Windows Update est devenu cumulatif : vous ne choisissez plus comme avant. C’est bon pour la sécurité, mais cela signifie que vous avez besoin d’un contrôle opérationnel (heures actives, reports, comportement de redémarrage) pour éviter les arrêts surprises.

Décisions OOBE qui comptent vraiment (et celles qui n’en valent pas la peine)

Décidez du modèle d’identité : compte local vs compte Microsoft

Si c’est une machine personnelle qui bénéficie de OneDrive, des achats sur le Store, de la synchronisation inter‑appareils et des clés de récupération liées à votre compte,
utilisez un compte Microsoft. Si c’est une machine de travail, une machine de labo, une borne ou tout ce que vous pourriez réimage souvent, un compte local est généralement
plus propre. Le chemin via un compte Microsoft tend à vous « aider » vers un couplage cloud plus grand (OneDrive, synchronisation Edge, applications suggérées).

En entreprise, vous voulez typiquement une jointure Entra ID (Azure AD) ou Active Directory. Le point important : choisissez intentionnellement,
car changer ensuite est possible mais fastidieux, et cela peut réinitialiser les attentes sur l’emplacement des paramètres et des données.

Bascule vie privée : gardez‑les ennuyeuses

Pendant l’OOBE on vous demandera la localisation, les diagnostics, les expériences personnalisées et l’identifiant publicitaire. Si vous optimisez pour
le bruit minimal et la fuite de données minimale, les valeurs par défaut ne sont pas vos amies. Désactivez ce dont vous n’avez pas besoin :
la localisation (sauf si vous utilisez vraiment la machine pour des cartes), l’identifiant publicitaire, les expériences personnalisées et la plupart des bascules « laisser les applications utiliser… ».

Ne confondez pas « données diagnostiques » et « rapport d’erreur ». Vous voulez que les plantages produisent des informations exploitables localement.
Vous ne voulez pas nécessairement que des données optionnelles soient envoyées en amont. Conservez les diagnostics requis si la politique l’exige ; évitez les optionnels.

OneDrive : décidez maintenant, pas plus tard

Si vous voulez Known Folder Move de OneDrive (redirection Bureau/Documents/Images), configurez‑le immédiatement et acceptez que votre profil utilisateur
devienne un client de synchronisation. Si vous ne le voulez pas, ne « passez pas pour l’instant ». Empêchez réellement le démarrage automatique et évitez l’invite « correction » plus tard.

Le mode d’échec : les utilisateurs stockent de grands jeux de données en changements fréquents (VM, dépôts Git, bases de données) dans des dossiers redirigés.
OneDrive devient alors un générateur d’E/S en arrière‑plan et une machine à conflits. Parfait pour des tableurs ; catastrophique pour des artefacts de build.

Utilitaires de restauration OEM : désinstallez‑les sauf si un contrat de support l’exige

Les outils OEM ajoutent souvent des services, des tâches planifiées et des fonctionnalités « d’optimisation » qui rivalisent avec Windows lui‑même. Si vous êtes responsable de la disponibilité,
vous voulez un seul mécanisme de mise à jour (Windows Update, plus votre approche gérée des pilotes). Les outils « assistant » OEM sont rarement additionnels.

Blague #1 : les « optimiseurs système » OEM ressemblent à mettre un deuxième volant dans une voiture — techniquement possible, émotionnellement éducatif.

Construire une référence : à quoi ressemble un système « sain » avant de modifier

Avant de commencer à supprimer des applications, capturez une référence. En termes SRE, vous avez besoin d’un SLO pour votre portable : temps de démarrage, CPU à l’inactivité, E/S disque à l’inactivité,
pression mémoire et comportement des mises à jour. Si vous ne mesurez pas, vous ne pouvez pas dire si vous avez amélioré le système ou simplement rendu les choses bizarres.

Les références vous protègent aussi de la superstition. « J’ai désactivé 14 services et ça semble plus rapide » n’est pas une preuve.
« CPU à l’inactivité est passé de 8–12% à 0–1% et la file d’attente disque est tombée sous 1 » est une preuve.

Tâches pratiques au premier démarrage (commandes, sorties, décisions)

Les tâches ci‑dessous sont conçues pour être exécutées au premier démarrage (ou juste après la fin de l’OOBE). Chacune inclut :
une commande, une sortie d’exemple, ce que cela signifie et la décision à en tirer.

Ces exemples supposent que vous avez un shell disponible sur un hôte de gestion (ou Windows avec les outils installés). En milieu professionnel,
vous exécutez souvent des vérifications Windows via des sessions à distance ou des outils de gestion. L’important est la méthode, pas le transport.

Tâche 1 — Vérifier la version et le build de l’OS (pour savoir à quoi vous avez affaire)

cr0x@server:~$ uname -a
Linux server 6.5.0-26-generic #26-Ubuntu SMP PREEMPT_DYNAMIC x86_64 GNU/Linux

Ce que cela signifie : Cette commande est une vérification de cohérence pour votre environnement d’exécution. Si vous vous attendiez à être sur Windows et que vous voyez Linux,
vous n’êtes pas sur ce que vous pensiez.

Décision : Confirmez votre chemin d’accès. Pour Windows, vous voulez PowerShell (de préférence élevé) sur l’hôte cible. Si vous passez par un jump box, documentez‑le pour que votre « référence » soit reproductible.

Tâche 2 — Confirmer la santé du disque depuis la couche stockage (résumé SMART)

cr0x@server:~$ sudo smartctl -H /dev/nvme0n1
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.5.0-26-generic] (local build)
Copyright (C) 2002-22, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

Ce que cela signifie : Votre périphérique de stockage ne montre pas de défaillance évidente. Un « FAILED » ici change tout le playbook : ne pas optimiser le logiciel sur un disque en train de mourir.

Décision : Si la santé n’est pas PASSED, arrêtez et remplacez le disque avant de chasser des fantômes de « bloat Windows ». Les pannes de stockage se déguisent en lenteurs.

Tâche 3 — Vérifier l’espace libre et l’utilisation du système de fichiers (la marge sur SSD compte)

cr0x@server:~$ df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme0n1p2  476G  118G  334G  27% /

Ce que cela signifie : Beaucoup d’espace libre. Sur Windows, un faible espace libre déclenche des nettoyages agressifs, des échecs de mise à jour et des écritures lentes liées au comportement du SSD.

Décision : Gardez au moins ~15–20% d’espace libre sur les SSD pour des performances constantes. Si vous êtes en dessous, corrigez d’abord la capacité (déplacer des données, étendre, disque plus grand).

Tâche 4 — Voir ce qui écrit constamment (I/O top)

cr0x@server:~$ sudo iotop -b -n 1 | head
Total DISK READ: 0.00 B/s | Total DISK WRITE: 12.35 M/s
  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND
 1321 be/4 root        0.00 B/s    5.40 M/s  0.00 % 15.20 %  updatedb.mlocate
 2110 be/4 root        0.00 B/s    3.10 M/s  0.00 %  9.50 %  systemd-journald

Ce que cela signifie : Vous pouvez identifier les processus bruyants en écriture. Sur Windows, vos analogues sont Resource Monitor et Process Explorer — même idée.

Décision : Si vous voyez un service en arrière‑plan saturer le disque sur une nouvelle installation, c’est votre premier suspect : indexation, mises à jour, synchronisation cloud, antivirus.

Tâche 5 — Vérifier la pression CPU à l’inactivité

cr0x@server:~$ top -b -n 1 | head -n 8
top - 10:21:44 up  2:13,  1 user,  load average: 0.25, 0.41, 0.36
Tasks: 246 total,   1 running, 245 sleeping,   0 stopped,   0 zombie
%Cpu(s):  1.2 us,  0.8 sy,  0.0 ni, 97.6 id,  0.3 wa,  0.0 hi,  0.1 si,  0.0 st
MiB Mem :  31973.0 total,  12433.5 free,   3821.8 used,  15717.7 buff/cache
MiB Swap:   8192.0 total,   8192.0 free,      0.0 used.  26944.8 avail Mem

Ce que cela signifie : À l’« inactivité », le CPU est à ~98% inactif. C’est ce que vous voulez après que la charge initiale du premier démarrage se soit apaisée.

Décision : Si le CPU à l’inactivité reste constamment élevé après la fin des mises à jour, trouvez le coupable (applications au démarrage, tâches planifiées, télémétrie, synchronisation cloud).

Tâche 6 — Vérifier la pression mémoire et le swap

cr0x@server:~$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  0      0 12734928  21264 16088264    0    0    12   148  513  821  1  1 98  0  0
 0  0      0 12730000  21264 16088300    0    0     0     0  502  799  0  1 99  0  0

Ce que cela signifie : Pas d’échanges en/sort (si/so). L’analogue Windows : vérifiez la mémoire engagée, les hard faults/sec et le tracas du fichier d’échange.

Décision : Si vous voyez du swap/des hard faults à l’inactivité, vous n’avez pas un problème de bloat — vous avez un problème de dimensionnement RAM ou un processus qui fuit.

Tâche 7 — Inventaire des tâches planifiées qui causent du travail surprise

cr0x@server:~$ systemctl list-timers --all | head
NEXT                        LEFT          LAST                        PASSED       UNIT                         ACTIVATES
Tue 2026-02-06 00:00:00 UTC 11h left      Mon 2026-02-05 00:00:00 UTC 12h ago      logrotate.timer              logrotate.service
Tue 2026-02-06 06:00:00 UTC 17h left      Mon 2026-02-05 06:00:00 UTC 4h ago       apt-daily.timer              apt-daily.service

Ce que cela signifie : Des planifications en arrière‑plan existent et sont découvrables. Sur Windows, le Planificateur de tâches est l’endroit d’où viennent les « CPU mystérieux à 2h du matin ».

Décision : Sur Windows, passez en revue les tâches planifiées pour les updaters OEM, les programmes « d’expérience » et la télémétrie redondante. Désactivez seulement ce que vous comprenez.

Tâche 8 — Vérifier la qualité de la résolution DNS (parce qu’un DNS lent ressemble à « Windows est lent »)

cr0x@server:~$ resolvectl query windowsupdate.microsoft.com
windowsupdate.microsoft.com: 13.107.4.50                    -- link: eth0

-- Information acquired via protocol DNS in 46.8ms.
-- Data is authenticated: no

Ce que cela signifie : La résolution DNS est rapide (<100ms). Un DNS lent provoque des blocages du Store/des mises à jour, des délais de connexion et des « ça tourne juste ».

Décision : Si le temps de résolution est élevé ou si des timeouts surviennent, corrigez le réseau/DNS avant de blâmer l’OS. On ne peut pas optimiser un mauvais DNS.

Tâche 9 — Mesurer le débit réseau et la perte de paquets (les mises à jour et OneDrive dépendent du réseau)

cr0x@server:~$ ping -c 5 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=57 time=14.2 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=57 time=13.7 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=57 time=13.9 ms
64 bytes from 1.1.1.1: icmp_seq=4 ttl=57 time=14.0 ms
64 bytes from 1.1.1.1: icmp_seq=5 ttl=57 time=13.8 ms

--- 1.1.1.1 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 13.7/13.9/14.2/0.2 ms

Ce que cela signifie : Latence stable, pas de perte. Les téléchargements Windows Update et Store se comporteront correctement.

Décision : Si vous voyez de la perte ou une gigue élevée, attendez‑vous à des corruptions de mise à jour, des tempêtes de réessais et à un comportement « bloqué à 0% ». Réparez le réseau d’abord.

Tâche 10 — Confirmer la synchronisation horaire (les échecs de certificats ressemblent à « le Store est cassé »)

cr0x@server:~$ timedatectl
               Local time: Mon 2026-02-05 10:22:11 UTC
           Universal time: Mon 2026-02-05 10:22:11 UTC
                 RTC time: Mon 2026-02-05 10:22:10
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Ce que cela signifie : L’horloge est synchronisée. Sur Windows, la dérive w32time provoque des erreurs TLS, des échecs de mise à jour et des problèmes de connexion de domaine.

Décision : Si l’heure n’est pas synchronisée, corrigez cela avant de dépanner des installations d’apps, des problèmes du Store ou des boucles d’authentification.

Tâche 11 — Inspecter le nombre de services en cours (trop d’« aides » est un signe)

cr0x@server:~$ systemctl list-units --type=service --state=running | wc -l
132

Ce que cela signifie : Un nombre de services n’est pas intrinsèquement mauvais, mais c’est une référence. Les systèmes Windows avec beaucoup d’agents OEM et tiers ont tendance à accumuler des services.

Décision : Si vous constatez une « prolifération de services », auditez : avez‑vous besoin de chaque agent ? Consolidez les outils de mise à jour et la protection des endpoints.

Tâche 12 — Vérifier la mise à l’échelle/la gouverne de fréquence CPU (réglages d’alimentation vs attentes de performance)

cr0x@server:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
powersave

Ce que cela signifie : La gestion d’alimentation est réglée pour économiser l’énergie. Windows a un comportement similaire via les modes d’alimentation et le firmware du vendeur.

Décision : Si les utilisateurs se plaignent de lenteur sur secteur, définissez un mode d’alimentation approprié (« Meilleure performance » sur postes fixes, équilibré sur portables) et vérifiez que les outils du vendeur n’ont pas pris le contrôle.

Tâche 13 — Identifier les principaux émetteurs réseau (téléchargements en arrière-plan)

cr0x@server:~$ ss -tpn | head
State  Recv-Q Send-Q Local Address:Port   Peer Address:Port  Process
ESTAB  0      0      10.0.0.10:45718     13.107.4.50:443    users:(("curl",pid=2440,fd=3))

Ce que cela signifie : Vous pouvez relier des connexions à des processus. Sur Windows, utilisez Resource Monitor ou des équivalents netstat pour trouver quel processus consomme la bande passante.

Décision : Si « les mises à jour sont lentes » mais qu’un client de synchronisation en arrière‑plan sature la liaison, limitez‑le ou planifiez‑le. La bande passante est une ressource partagée.

Tâche 14 — Vérifier les régressions du temps de démarrage (référence pour « c’est devenu plus lent »)

cr0x@server:~$ systemd-analyze
Startup finished in 6.231s (firmware) + 2.014s (loader) + 4.889s (kernel) + 9.321s (userspace) = 22.456s
graphical.target reached after 9.287s in userspace.

Ce que cela signifie : Vous avez une chronologie mesurable de démarrage. Windows a le même concept via l’Observateur d’événements (Diagnostics-Performance) et l’impact au démarrage du Gestionnaire des tâches.

Décision : Si le temps de démarrage augmente au fil des semaines, suspectez les applications au démarrage, les tâches planifiées au logon et les mises à jour de pilotes. Ne devinez pas — mesurez et comparez à la référence.

Tâche 15 — Valider le volume de journaux (les logs doivent informer, pas DDoS votre disque)

cr0x@server:~$ journalctl --disk-usage
Archived and active journals take up 384.0M in the file system.

Ce que cela signifie : Les journaux sont bornés. Sur Windows, des journaux d’événements massifs peuvent indiquer des erreurs répétées (réessais de pilotes, échecs de mise à jour) et se corréler avec des problèmes de performance.

Décision : Si les journaux explosent, ne vous contentez pas de les effacer — trouvez l’erreur répétée. Vider les journaux est la façon dont on perd la seule piste disponible.

Blague #2 : effacer les journaux d’événements pour améliorer la performance, c’est comme éteindre le détecteur de fumée pour améliorer la qualité de l’air.

Maintenant, les réglages Windows à prioriser (ce qu’il faut réellement changer)

Applications au démarrage : coupez la liste des démarrages automatiques sans pitié

Allez dans Gestionnaire des tâches → Démarrage. Désactivez tout ce qui n’est ni la sécurité, ni votre principal outil de collaboration, ni un panneau de contrôle de pilote dont vous avez vraiment besoin.
Les suspects habituels : démarrage automatique de Teams, OneDrive (si vous ne l’utilisez pas), agents de mise à jour OEM, applications « assistant », lanceurs de jeux, aides d’imprimante.

Mode d’échec : désactiver le mauvais élément casse des raccourcis, des améliorations audio ou les contrôles d’accès VPN. C’est pourquoi vous désactivez une classe à la fois et observez.

Windows Update : rendez‑le prévisible, pas optionnel

Les mises à jour ne sont pas du bloat. Les mises à jour sont le loyer que vous payez pour être en ligne. Le bloat, c’est les redémarrages surprises, les pics de bande passante
et les pilotes remplacés sans consentement.

• Définissez les heures actives pour correspondre à votre journée réelle. Empêchez la « roulette des redémarrages ».
• Désactivez « Obtenir les dernières mises à jour dès qu’elles sont disponibles » sur les machines où la stabilité compte. Laissez les early adopters être early adopters.
• Vérifiez les mises à jour optionnelles (surtout les pilotes). N’installez pas les pilotes aveuglément sur des postes de production.
• Delivery Optimization : sur les réseaux domestiques cela peut convenir ; sur des liaisons montantes contraintes, limitez‑le ou désactivez les uploads pair à pair.

Confidentialité & autorisations : retirez la posture « oui » par défaut

Dans Paramètres → Confidentialité et sécurité, vérifiez :

• Diagnostics & feedback : conservez requis, désactivez optionnel quand c’est possible. Désactivez les expériences personnalisées si vous voulez moins de « suggestions ».
• Général : désactivez l’identifiant publicitaire et les bascules du type « Me montrer du contenu suggéré ».
• Autorisations des applications : localisation, caméra, microphone — refuser par défaut, accorder par application. La plupart des machines n’ont pas besoin de la localisation.

Indexation de la recherche : gardez‑la ciblée

La recherche est utile. Indexer tout votre disque (y compris images VM, répertoires de build ou archives lourdes) n’est pas utile.
Dans Paramètres → Confidentialité et sécurité → Recherche Windows, choisissez « Classique » si « Améliorée » commence à manger votre disque.
Ensuite, excluez les répertoires lourds.

OneDrive : soit vous vous y engagez, soit vous le désactivez proprement

Si vous l’utilisez, configurez‑le. Si vous ne l’utilisez pas, empêchez‑le de posséder vos dossiers.
Pour les machines personnelles, OneDrive peut être une amélioration réelle de la fiabilité (suppression accidentelle, perte d’appareil).
Pour des postes d’ingénierie avec de gros repos et artefacts, c’est souvent un risque de performance et de conflits.

Notifications : coupez le bruit pour que les alertes aient du sens

Désactivez les notifications promotionnelles. Conservez les alertes de sécurité et de mise à jour. Réduisez les « astuces et trucs ». L’objectif est opérationnel :
quand Windows vous avertit, vous devez le croire.

Applications par défaut et invites de navigateur : décidez une bonne fois pour toutes

Choisissez votre navigateur, votre lecteur PDF et votre terminal. Puis cessez de repasser la question. N’autorisez pas les « paramètres recommandés » à se réaffirmer après les mises à jour.
Si c’est une flotte gérée, appliquez des politiques pour forcer les défauts, pas les habitudes des utilisateurs.

Storage Sense : automatisez le nettoyage ennuyeux

Configurez Storage Sense pour nettoyer les fichiers temporaires et la corbeille sur un calendrier, surtout pour les machines avec de petits SSD.
C’est l’une des rares fonctionnalités d’automatisation qui rapporte généralement sans dommage collatéral.

BitLocker : protégez les données, mais comprenez la gestion des récupérations

Si l’appareil sort du bâtiment, activez BitLocker. Puis assurez‑vous que les clés de récupération sont stockées quelque part que vous contrôlez.
Le bloat que vous évitez est l’indisponibilité : « On ne peut pas accéder à l’ordinateur parce que la carte mère est morte » est un incident évitable.

Defender : ne le désactivez pas ; affinez les exclusions avec discipline

Defender n’est pas votre ennemi. Les exclusions aveugles le sont. Si vous avez besoin de performance pour des builds ou des VM,
excluez des dossiers spécifiques (comme un répertoire de sortie de build) et vérifiez que vous n’excluez pas « Téléchargements » ou des disques entiers.

Mode opératoire de diagnostic rapide : trouver le goulot en minutes

Premièrement : déterminer quelle ressource est saturée

• CPU saturé ? Vérifiez Gestionnaire des tâches → Processus triés par CPU. Si c’est « Antimalware Service Executable », vous êtes dans une phase d’analyse ; si c’est un agent fournisseur, vous avez trouvé votre bloat.
• Disque à 100% ? Vérifiez Gestionnaire des tâches → Performances → Disque et Resource Monitor → Disque. Si c’est SearchIndexer ou OneDrive, limitez la portée et planifiez. Si c’est « Système », examinez les mises à jour, les pilotes ou les erreurs de stockage.
• Pression mémoire ? Si la mémoire engagée est proche de la limite et que les hard faults sont élevés, arrêtez d’optimiser les apps et ajoutez de la RAM ou stoppez la fuite.
• Réseau saturé ? Si la liaison montante est saturée, suspectez OneDrive, Delivery Optimization et les mises à jour du Store.

Deuxièmement : vérifiez les éléments de « churn » du premier démarrage

• Windows Update (y compris les pilotes) : est‑il en cours d’installation ?
• Mises à jour du Microsoft Store : des applications se mettent‑elles à jour en arrière‑plan ?
• Indexation de recherche : l’index est‑il encore en construction ?
• Analyses Defender : les analyses initiales après l’installation peuvent être lourdes.
• Synchronisation cloud : la synchronisation initiale OneDrive peut être brutale.

Troisièmement : prouvez‑le avec un seul journal ou un seul compteur

Ne devinez pas. Choisissez un seul signal faisant autorité :
Observateur d’événements (Diagnostics-Performance pour le démarrage ; WindowsUpdateClient pour les problèmes de mise à jour),
Resource Monitor (file d’attente disque et fichiers),
ou Reliability Monitor (schémas de plantage).

Quatrièmement : appliquez le plus petit changement réversible

Désactivez une application au démarrage. Suspendez OneDrive. Limitez l’upload Delivery Optimization. Passez la recherche d’Améliorée à Classique.
Redémarrez une fois. Mesurez de nouveau. Répétez. C’est de la discipline d’intervention d’incident, appliquée à une station de travail.

Trois mini‑récits en entreprise depuis le terrain

Mini‑récit 1 — L’incident causé par une mauvaise hypothèse : « Une installation propre signifie des performances propres »

Une entreprise de taille moyenne a déployé de nouveaux portables à un groupe d’ingénierie. L’informatique a appliqué ce qu’elle croyait être la norme d’or :
image Windows fraîche, pilotes récents, « applications minimales ». La première semaine, les tickets ont afflué : démarrage lent, autonomie en baisse,
ventilateurs forts à l’inactivité, déconnexions VPN. Les machines étaient neuves, ce qui rendait psychologiquement plus difficile d’accepter qu’il puisse y avoir un problème.

L’hypothèse erronée était subtile : ils ont supposé qu’une image OS propre impliquait un profil comportemental propre.
Mais l’image incluait une suite de gestion OEM requise pour le support de garantie, plus un outil secondaire « d’optimisation »
qui exécutait des tâches planifiées au logon, à l’inactivité et lors des transitions secteur. Elle embarquait aussi un agent de sauvegarde cloud
qui tentait de sauvegarder les profils utilisateurs — alors que OneDrive était déjà configuré via une politique. Deux systèmes de synchronisation, un disque.

Le symptôme était « Windows est lent ». La cause racine était « le travail en arrière‑plan ne s’arrête jamais ». Le disque restait très actif
car l’indexation et l’analyse poursuivaient les fichiers réécrits par la synchronisation et la sauvegarde. Le CPU restait actif car la télémétrie OEM
et les tâches de mise à jour réveillaient fréquemment la machine. L’instabilité VPN était un effet secondaire : la gestion d’alimentation
n’atteignait jamais un état stable, et le roaming Wi‑Fi devenait bizarre.

La correction fut ennuyeuse et efficace : choisir un seul mécanisme de synchronisation/sauvegarde, désinstaller le doublon, et désactiver l’optimiseur OEM.
Ensuite, ils ont créé une checklist de premier démarrage : vérifier un CPU inactif sous 2%, file d’attente disque sous contrôle, et statut de synchronisation OneDrive stable.
Les tickets ont chuté sans que quiconque « débloate » Windows lui‑même. La leçon : une installation propre est un point de départ, pas une garantie.

Mini‑récit 2 — L’optimisation qui s’est retournée contre eux : exclusions Defender agressives

Une équipe expérience développeur voulait des builds plus rapides. Ils ont remarqué Defender utilisant du CPU pendant la compilation et ont décidé de « corriger » cela centralement.
Leur approche : ajouter des exclusions larges pour des chemins développeurs communs. Ça a marché — les builds se sont accélérés, les ventilateurs se sont tus, et tout le monde était content
pendant environ un mois.

Puis un incident subtil : un petit sous‑ensemble d’endpoints a commencé à présenter du trafic sortant suspect. Pas un événement dramatique de ransomware — juste
une fuite lente de credentials via une extension de navigateur qui n’aurait pas dû être présente. L’intervention a trouvé le payload dans un chemin qui avait été exclu pour « performance ».
L’exclusion n’a pas causé la compromission, mais elle a supprimé une couche de détection qui aurait réduit le temps de présence.

Le postmortem fut inconfortable car personne n’avait agi malicieusement. Ils avaient optimisé pour la vitesse des développeurs sans budget de risque explicite.
Ils n’avaient pas non plus testé la politique sur un ensemble représentatif de machines : le chemin exclu chevauchait un répertoire de cache modifiable par l’utilisateur
utilisé par plusieurs outils.

La correction fut chirurgicale : resserrer les exclusions aux répertoires de sortie de build régénérés, pas aux racines de profil utilisateur ; exclure par processus quand c’est possible.
Ils ont aussi ajouté une étape de vérification : un audit périodique pour s’assurer que les exclusions restent dans la liste approuvée. Les builds sont restés suffisamment rapides,
et la sécurité a retrouvé de la visibilité. La leçon : les ajustements de performance deviennent de l’architecture de sécurité, que vous le vouliez ou non.

Mini‑récit 3 — La pratique ennuyeuse mais correcte qui a sauvé la situation : référence + rollback

Un département financier utilisait une application métier sensible aux pilotes d’imprimante (oui, vraiment). Une mise à jour de fonctionnalité Windows a été déployée
et soudain les factures s’imprimaient avec des marges incorrectes. Le vendeur accusait les imprimantes. Le fournisseur d’imprimantes accusait Windows. Tout le monde s’est rejeté la faute,
ce qui est le cercle de vie corporatif.

L’équipe IT qui a résolu le plus vite n’était pas la plus astucieuse. Elle était la plus méthodique. Elle disposait d’une image de référence, d’un jeu de pilotes connus bons,
et d’un journal de changements des réglages de premier démarrage qui comptaient : comportement d’imprimante par défaut, réglages du spooler et reports de mise à jour. Ils avaient aussi un plan de rollback
réellement pratiqué, pas seulement rédigé.

Ils ont comparé les machines affectées à leur référence : des versions de pilotes avaient changé via des mises à jour optionnelles. La « correction » n’a pas été un hack du registre ; c’était
un contrôle opérationnel. Ils ont rollbacké le pilote, bloqué cette version de pilote pour qu’elle ne se redéploie pas, et ajusté l’anneau de mise à jour pour que ces systèmes reçoivent les mises
à jour de fonctionnalités plus tard que les machines de bureau générales.

C’était ennuyeux, ce qui explique pourquoi ça a fonctionné. La leçon : les réglages du premier démarrage ne sont pas un acte ponctuel ; ils font partie du contrôle du cycle de vie.
Quand vous pouvez expliquer ce qui a changé, vous pouvez l’inverser rapidement.

Erreurs fréquentes : symptôme → cause racine → correction

1) « Le disque est à 100% tout le temps »

Symptôme : Le Gestionnaire des tâches indique 100% d’utilisation disque ; la machine semble gelée ; démarrage/connexion lents.

Cause racine : Indexation du premier démarrage + analyses Defender + synchronisation OneDrive + mises à jour du Store frappant un petit SSD, parfois amplifié par un faible espace libre.

Correction : Laissez les mises à jour se terminer une fois. Ensuite : passez Search en Classique, excluez les répertoires lourds, mettez OneDrive en pause pendant la configuration initiale, assurez‑vous d’avoir 15–20% d’espace libre, et passez en revue les applications au démarrage.

2) « Mon CPU n’est jamais au repos »

Symptôme : Les ventilateurs montent à l’inactivité ; la batterie se vide vite ; le portable chauffe en ne faisant rien.

Cause racine : « Optimiseur »/agents de télémétrie OEM, vérificateurs de mise à jour redondants, clients de chat, flux de widgets, ou onglets de navigateur hors contrôle. Parfois un pilote causant de la charge DPC.

Correction : Désactivez les applications au démarrage non essentielles. Désinstallez les assistants OEM sauf si requis. Vérifiez les mises à jour pilotes depuis l’OEM (pas depuis des sites de pilotes aléatoires). Si vous suspectez du DPC, recherchez des pilotes audio/Wi‑Fi.

3) « Windows Update échoue sans cesse »

Symptôme : Les mises à jour se téléchargent à répétition, l’installation échoue ou reste bloquée ; les apps du Store ne se mettent pas à jour non plus.

Cause racine : Dérive horaire, problèmes DNS/proxy, espace disque insuffisant ou cache de mise à jour corrompu.

Correction : Vérifiez la synchronisation horaire, la performance de résolution DNS, l’espace libre, puis réparez les composants de mise à jour. En environnements gérés, assurez‑vous que la politique et le proxy autorisent les points de terminaison de mise à jour.

4) « La connexion prend une éternité, puis tout charge en même temps »

Symptôme : Écran noir ou « Bienvenue » pendant longtemps ; puis pop‑ups soudains et thrash disque.

Cause racine : Trop d’éléments de démarrage par utilisateur, scripts GPO lourds au logon, OneDrive KFM, bootstrapper Teams et tâches OEM planifiées au logon.

Correction : Réduisez les tâches au moment du logon. Déplacez le travail vers des planifications à l’inactivité. Désactivez les entrées de démarrage par utilisateur inutiles. Gardez la configuration OneDrive intentionnelle, pas « plus tard ».

5) « La recherche est lente ou provoque des pics »

Symptôme : La recherche prend des secondes ; SearchIndexer utilise le disque/le CPU de façon intermittente.

Cause racine : Portée d’indexation Améliorée trop large, indexation de répertoires volatils, ou filtres de contenu qui s’étouffent sur de grands ensembles binaires.

Correction : Utilisez l’indexation Classique, excluez les chemins de build/VM, laissez l’indexation initiale se terminer sur secteur, et maintenez le stockage sain.

6) « L’autonomie est terrible après une installation propre »

Symptôme : Nouveau portable se décharge rapidement, surtout à l’inactivité ou en veille.

Cause racine : Réveils en arrière‑plan (sync, télémétrie, agents de mise à jour), mode d’alimentation haute performance, ou pilotes défaillants empêchant les états basse consommation.

Correction : Utilisez le mode d’alimentation équilibré, auditez les apps au démarrage, limitez l’activité en arrière‑plan, et installez les pilotes chipset/gestion d’alimentation OEM. Si la veille est instable, testez les réglages modern standby et les versions de pilotes.

7) « J’ai supprimé le ‘bloat’ et maintenant quelque chose est cassé »

Symptôme : Pages de réglages manquantes, Store cassé, menu Démarrer étrange, notifications absentes ou mises à jour échouent après des « scripts de débloat ».

Cause racine : Suppression trop agressive de composants système, dépendances d’apps cassées, ou politiques appliquées sans comprendre le périmètre.

Correction : Évitez les scripts de débloat en un clic sur des systèmes de production. Préférez désactiver des fonctionnalités et désinstaller des applications utilisateur via des mécanismes normaux. Si vous avez déjà exécuté un script, soyez prêt à réparer des composants système ou à réinstaller proprement.

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

Plan « rendre sain » en 30 minutes (risque minimal)

1. Exécuter Windows Update et le laisser se terminer une fois. Redémarrez si nécessaire. Ne commencez pas à optimiser en plein processus de mise à jour.
2. Définir les heures actives et le comportement de redémarrage. Vous évitez les arrêts surprises.
3. Gestionnaire des tâches → Démarrage : désactivez les évidents non essentiels (assistants OEM, lanceurs de jeux, bootstrappers de chat redondants).
4. Paramètres → Notifications : désactivez astuces, suggestions et contenu promotionnel.
5. Paramètres → Confidentialité & sécurité : désactivez identifiant publicitaire et expériences personnalisées.
6. Décidez OneDrive : configurez maintenant ou désactivez le démarrage automatique maintenant. Ne « peut‑être plus tard » pas votre chemin vers le chaos.

Plan « poste de travail production » en 2 heures (mesuré et réversible)

1. Référence : notez le temps de démarrage, le CPU à l’inactivité et l’activité disque après les mises à jour. Utilisez une note simple : date, build, pilotes clés.
2. Désinstallez le bloat OEM qui ajoute services/updaters sauf si la politique l’exige.
3. Indexation : passez en Classique si nécessaire ; excluez les répertoires d’ingénierie lourds.
4. Storage Sense : configurez le planning de nettoyage.
5. Defender : gardez‑le activé ; ajoutez des exclusions étroites pour les sorties de build seulement si nécessaire et approuvé.
6. Delivery Optimization : limitez l’upload pair à pair sur les réseaux contraints.
7. Mode d’alimentation : équilibré pour les portables, performance pour les postes fixes (sauf si le bruit/thermique a plus d’importance).

Plan « prêt flotte » en 1 jour (réalité d’entreprise)

1. Définir une norme : listez les apps autorisées au démarrage, les tâches planifiées autorisées, l’anneau/les reports de mises à jour et la posture de confidentialité.
2. Automatiser via politique : appliquez les réglages de mise à jour, le comportement OneDrive et la politique de suggestions du Store quand c’est applicable.
3. Créer une checklist d’audit : vérifiez les métriques de référence et les réglages clés après chaque mise à jour de fonctionnalité.
4. Documenter le rollback : étapes de rollback de pilotes, règles de pause/report de mise à jour et gestion des clés de récupération BitLocker.
5. Former le support : un flux de « diagnostic rapide » pour que le helpdesk n’ait pas pour habitude de réinstaller Windows à chaque ticket.

FAQ

1) Le « débloat » de Windows vaut‑il le coup ?

Sélectivement, oui. Désinstallez les évidents inutiles et désactivez les entrées bruyantes au démarrage. Non, si cela implique d’exécuter un script qui supprime des composants système
que vous ne comprenez pas. L’objectif est un comportement prévisible, pas la pureté idéologique.

2) Dois‑je désactiver Windows Defender pour la performance ?

Non. Ajustez‑le. Utilisez des exclusions étroites et justifiées pour les répertoires de sortie de build ou les images VM si nécessaire, et vérifiez que vous n’avez pas exclu des emplacements écrits par l’utilisateur.
Le désactiver complètement, c’est échanger une légère lenteur contre un gros risque pour l’investigation d’incidents.

3) Quel est le réglage le plus impactant au premier démarrage ?

Les applications au démarrage. Réduire le clutter d’auto‑démarrage réduit le temps de démarrage, le CPU à l’inactivité et l’usage réseau en arrière‑plan sans nuire à la maintenance de Windows.

4) Ai‑je besoin d’un compte Microsoft ?

Pas forcément. Si vous voulez l’intégration OneDrive et la synchronisation inter‑appareils, c’est pratique. Pour des endpoints de labo/production où vous voulez moins de couplage,
un compte local (ou une identité d’entreprise gérée) est souvent plus propre.

5) Pourquoi l’utilisation disque monte‑t‑elle pendant des heures après l’installation ?

Vous observez Windows effectuer son travail initial : téléchargements de mises à jour, indexation, analyses Defender et mises à jour d’apps. La correction n’est pas de paniquer ; c’est d’ordonner :
laisser les mises à jour se terminer, puis mesurer le comportement à l’inactivité, puis optimiser.

6) Dois‑je désactiver l’indexation Windows Search ?

La plupart du temps non. Mais vous devez la restreindre. Passez à l’indexation Classique et excluez les répertoires volumineux et volatils (VM, sorties de build, grosses archives).
La recherche doit être rapide et discrète, pas un planificateur de tâches en arrière‑plan.

7) Les utilitaires OEM sont‑ils toujours mauvais ?

Pas toujours. Certains fournissent des mises à jour firmware ou des paquets pilotes que Windows Update manque. La règle : conservez l’utilitaire qui apporte une valeur unique et nécessaire ;
supprimez les « optimisateurs », updaters dupliqués et hubs marketing redondants.

8) Désactiver Delivery Optimization va‑t‑il casser les mises à jour ?

Non, cela change juste la façon dont les mises à jour sont distribuées. Désactiver le pair à pair peut réduire l’usage de la liaison montante et le thrash disque sur de petits réseaux.
En LAN d’entreprise, Delivery Optimization peut être bénéfique ; configurez‑le, n’en ayez pas peur.

9) Et les Widgets, Chat et applications « suggérées » ?

Si vous voulez une machine plus silencieuse, désactivez‑les. Ils ajoutent des appels réseau en arrière‑plan et du bruit UI. Si un utilisateur en dépend, conservez‑les — mais faites‑en un choix conscient, pas un défaut.

10) BitLocker est‑il du « bloat » ?

Non. C’est du contrôle du risque. L’exigence opérationnelle est la gestion des clés : stockez les clés de récupération de manière fiable, et assurez‑vous que le personnel de support peut les récupérer
sans partir en chasse.

Conclusion : prochaines étapes pratiques

Une installation Windows propre est comme une baie de datacenter fraîche : l’espace vide invite aux mauvaises décisions. Le premier démarrage est l’endroit où vous décidez si votre machine sera
une station de travail calme ou un carnaval de tâches en arrière‑plan.

Faites cela ensuite :

• Laissez les mises à jour se terminer une fois, puis prenez une référence : CPU à l’inactivité, activité disque, temps de démarrage.
• Coupez les applications au démarrage de manière impitoyable mais réversible.
• Rendez Windows Update prévisible : heures actives, reports quand approprié, et mises à jour pilotes prudentes.
• Décidez intentionnellement de OneDrive et de la portée de l’indexation Search.
• Gardez Defender activé ; ajustez uniquement avec des exclusions étroites et justifiées.
• Notez ce que vous avez changé. Le « vous » du futur est une partie prenante.

Vous n’avez pas besoin d’un Windows « débloaté ». Vous avez besoin d’un Windows opérable : silencieux à l’inactivité, prévisible sous changement et facile à récupérer quand l’inévitable arrive.