Repérer ce qui consomme la bande passante sous Windows (sans applications douteuses)

Quelqu’un est toujours « en train de télécharger un fichier », et d’un coup votre appel Teams se transforme en performance de mime.
Le pire n’est pas la lenteur—c’est l’incertitude. Est-ce Windows Update ? OneDrive ? Un onglet de navigateur devenu incontrôlable ?
Ou votre propre PC qui exécute discrètement des tâches d’entreprise en arrière-plan ?

Voici comment trouver le coupable en n’utilisant que les outils intégrés à Windows. Pas d’installateurs mystérieux. Pas de « booster réseau gratuit ».
Juste ce que vous avez déjà—et la rigueur nécessaire pour l’interpréter correctement.

Plan d’action pour un diagnostic rapide

Vous êtes responsable de votre propre portable. Vous n’avez pas le temps pour un séminaire de philosophie réseau.
Voici l’ordre d’opérations qui apporte des réponses rapidement avec un minimum d’efforts.

1) Confirmez que c’est votre PC et pas le réseau

• Si toute la maison/le bureau est lent, arrêtez. Votre machine Windows ne « consomme » pas forcément la bande passante—le lien montant est saturé.
  Vérifiez d’abord l’état du routeur/du FAI.
• Si seul votre PC est lent : poursuivez.

2) Identifiez le processus principal par I/O réseau

• Gestionnaire des tâches → Processus → triez par Réseau.
• Si c’est une application normale (navigateur, OneDrive) : vous avez essentiellement la réponse ; décidez d’arrêter, de limiter ou de planifier.
• Si c’est Service Host ou « System » : passez au Moniteur de ressources et à netstat pour trouver le service/la connexion réelle.

3) Décidez : hog de débit ou problème de latence ?

• Si quelque chose tire 50–500 Mbps et que votre appel plante : hog de débit.
  Résolvez en arrêtant/limitant/planifiant, ou en définissant une connexion mesurée / limites Delivery Optimization.
• Si la colonne « Réseau » est faible mais que tout « paraît » lent : cherchez DNS, perte de paquets, boucles d’authentification proxy ou retransmissions.
  Le Moniteur de ressources et les compteurs aident ici.

4) Reliez le trafic à un point distant

• Utilisez le Moniteur de ressources (TCP Connections) ou netstat -b/netstat -ano.
• L’IP/port distant vous dira si vous parlez à un CDN Microsoft, votre proxy d’entreprise, ou à quelque chose de plus étrange.

5) Appliquez la correction la moins dangereuse

• Préférez la limitation et la planification plutôt que de tuer des processus.
  La bande passante est une ressource partagée ; la stabilité est le vrai SLO.
• Si le trafic est géré par l’entreprise (mises à jour, agent endpoint) : coordonnez-vous plutôt que de faire du whack-a-mole.

Une citation que je garde depuis des années, car c’est le seul antidote à la pensée « Je suis sûr que c’est X » :
En exploitation, on n’est pas crédité pour avoir deviné ; on est crédité pour avoir mesuré.
(idée paraphrasée attribuée à l’ingénierie qualité de type Deming)

D’abord, définissez la vérité terrain (et ne vous volez pas)

Les plaintes sur la « bande passante » signifient généralement une des trois choses :

1. Saturation réelle : un processus consomme une grosse part de votre lien montant/descendant.
2. Inflation de la latence : délais DNS, boucles proxy, perte de paquets, retransmissions Wi‑Fi, bufferbloat. Votre débit peut être correct.
3. Contention au niveau application : tunnel VPN, inspection par un agent de sécurité, ou orchestration de mises à jour provoquant des blocages.

Si vous ne les séparez pas, vous « réparerez » la mauvaise chose. Vous aurez aussi le classique d’entreprise :
quelqu’un désactive le VPN pour « améliorer les performances », puis se demande pourquoi les applications internes ne fonctionnent plus. Un vrai mystère.

Votre objectif est de répondre, avec preuves :

• Quel processus transfère des données ?
• Quel service (si c’est un processus hôte comme svchost.exe) ?
• Quel point distant (domaine/IP/port) ?
• Est-ce continu ou par rafales ?
• La douleur est-elle due à la bande passante ou à la latence/perte ?

Tâches 1–2 : Commencez par le Gestionnaire des tâches (il est mieux que vous ne vous en souvenez)

Task 1: Trier par Réseau dans le Gestionnaire des tâches

Le Gestionnaire des tâches n’est pas une inspection de paquets profonde, mais c’est le moyen le plus rapide de trouver les contrevenants évidents.
Si vous avez un émetteur clair ici, ne compliquez pas le reste.

cr0x@server:~$ taskmgr.exe
...Task Manager opens. Go to Processes, click the Network column to sort...

Ce que vous cherchez :

• Un seul processus montrant des Mbps soutenus. Navigateurs, OneDrive, Teams, Steam, Windows Update sont fréquents.
• Si le sommet est Service Host: … ou System, vous aurez besoin de l’outil suivant pour désambiguïser.

Décision :

• Si c’est une application utilisateur : fermez-la, mettez en pause le téléchargement, ou planifiez-le. Confirmez l’amélioration.
• Si c’est un processus hôte/système : passez au Moniteur de ressources.

Task 2: Utiliser Historique des applications pour la « mort par mille transferts en arrière-plan »

Certains problèmes de bande passante ne sont pas un gros flux—ce sont des dizaines de petits transferts en arrière-plan. L’historique des applications vous donne une vue sur la durée.

cr0x@server:~$ cmd /c "start ms-settings:datausage"
...Settings opens at Data usage; inspect per-app usage for the last 30 days...

Ce que signifie la sortie :

• Si une application a une utilisation choquante sur la durée, c’est un contributeur persistant, pas un pic ponctuel.
• Si « System » domine, vous regardez probablement des mises à jour, Delivery Optimization, ou du trafic VPN/proxy.

Décision :

• Utilisation élevée par OneDrive/Dropbox : vérifiez les paramètres de synchronisation, la synchronisation sélective, les limites d’upload.
• Utilisation élevée par « System » : évitez de deviner ; identifiez le service avec le Moniteur de ressources et le mappage des services.

Tâches 3–4 : Moniteur de ressources pour sockets par processus et indices de latence

Le Moniteur de ressources est une pépite sous-utilisée. Il montre processus, connexions et ports à l’écoute dans un seul endroit.
Ce n’est pas joli. C’est efficace. Comme un bon SRE.

Task 3: Ouvrir le Moniteur de ressources directement et inspecter Réseau

cr0x@server:~$ resmon.exe
...Resource Monitor opens. Go to the Network tab...

Ce qu’il faut vérifier :

• Processes with Network Activity : affiche les débits d’envoi/réception par processus.
• Network Activity : détails des fichiers et des points distants (pour certains processus).
• TCP Connections : le jackpot—adresse locale/distante, port et latence.

Décision :

• Si un processus a plusieurs connexions vers la même plage IP distante (CDN), il télécharge probablement des mises à jour/contenu.
• Si vous voyez beaucoup de connexions courtes et une latence élevée, suspectez DNS/proxy/auth plutôt que du débit pur.

Task 4: Filtrer par un processus suspect et relever ses points distants

Dans le Moniteur de ressources, cochez la case à côté du processus suspect. Les tableaux du bas se filtrent automatiquement.
Notez les adresses et ports distants.

cr0x@server:~$ cmd /c "echo Use Resource Monitor: tick the process checkbox; then read Remote Address/Port in TCP Connections."
Use Resource Monitor: tick the process checkbox; then read Remote Address/Port in TCP Connections.

Ce que cela signifie :

• Port distant 443 : HTTPS (la plupart du trafic moderne). Vous ne verrez ici que des IPs, pas de domaines.
• Port distant 80 : HTTP (plus rare, souvent legacy ou interne).
• Port distant 53 : DNS (si quelque chose inonde le DNS, c’est un mauvais signe).
• Port distant 123 : NTP pour la synchronisation temporelle (petit, mais fréquent).

Décision :

• Si les points distants ressemblent à Microsoft/CDN et que le processus est lié aux mises à jour : passez à la section fonctionnalités Windows.
• Si les points distants semblent internes/proxy d’entreprise : suspectez des boucles proxy, VPN, ou agents de sécurité.

Tâches 5–6 : netstat + mappage PID (le classique qui marche toujours)

Quand les interfaces graphiques trompent par omission, netstat vous donne la vérité brute des sockets. Ce n’est pas glamour, mais la production non plus.

Task 5: Lister les connexions établies avec PID

cr0x@server:~$ cmd /c "netstat -ano | findstr ESTABLISHED"
TCP    192.168.1.50:51322   52.96.12.34:443      ESTABLISHED     4960
TCP    192.168.1.50:51340   13.107.6.171:443     ESTABLISHED     1348
TCP    192.168.1.50:51355   142.250.72.206:443   ESTABLISHED     17824

Ce que signifie la sortie :

• La dernière colonne est le PID. C’est votre poignée pour identifier le processus propriétaire.
• Si vous voyez beaucoup de connexions établies vers de nombreuses IPs distantes, le processus peut être un navigateur, un updater, ou un outil de synchronisation.

Décision :

• Sélectionnez les principaux PIDs et mappez-les aux noms de processus.

Task 6: Mapper le PID au processus et à la ligne de commande

cr0x@server:~$ cmd /c "tasklist /fi "PID eq 4960" /v"
Image Name                     PID Session Name        Session#    Mem Usage Status          User Name          CPU Time Window Title
msedge.exe                     4960 Console                    1    350,000 K Running         CORP\alice         0:12:41  Project - Edge

Tasklist suffit pour le nom et un indice. Pour la vraie réponse, incluez la ligne de commande (surtout pour
svchost.exe, les navigateurs avec plusieurs profils, et les agents d’entreprise).

cr0x@server:~$ powershell -NoProfile -Command "Get-CimInstance Win32_Process -Filter 'ProcessId=4960' | Select-Object ProcessId,Name,CommandLine | Format-List"
ProcessId  : 4960
Name       : msedge.exe
CommandLine: "C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe" --profile-directory=Default

Décision :

• Si la ligne de commande pointe vers un updater/planificateur : vous pouvez souvent le mettre en pause proprement.
• Si c’est un agent d’entreprise : ne le tuez pas d’emblée. Identifiez les réglages de politique et les fenêtres de maintenance.

Tâches 7–9 : PowerShell pour les adaptateurs, routes, et le moment « pourquoi le DNS est lent ? »

Les « problèmes » de bande passante viennent fréquemment de la mauvaise interface, de la mauvaise route, ou d’une résolution de noms défaillante.
PowerShell vous donne des preuves répétables, copiables/collables, que vous pouvez envoyer au service IT sans passer pour un théoricien du complot.

Task 7: Vérifier quelle interface est réellement utilisée (et à quelle vitesse link)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetAdapter | Sort-Object -Property Status,LinkSpeed -Descending | Format-Table -Auto Name,Status,LinkSpeed,MacAddress"
Name          Status  LinkSpeed   MacAddress
Ethernet      Up      1 Gbps      00-11-22-33-44-55
Wi-Fi         Down    0 bps       AA-BB-CC-DD-EE-FF

Ce que cela signifie :

• Si Ethernet est « Up » à 100 Mbps alors que vous attendiez 1 Gbps, vous avez peut-être un problème de négociation câble/switch.
• Si le Wi‑Fi est actif à faible débit, vous êtes peut-être bloqué sur 2.4 GHz, éloigné du point d’accès, ou en présence d’interférences.

Décision :

• Corrigez la couche physique/liens avant de chasser les processus. Un lien 100 Mbps saturé fera paraître criminelles des tâches d’arrière-plan normales.

Task 8: Identifier les serveurs DNS et si vous utilisez quelque chose d’inhabituel

cr0x@server:~$ powershell -NoProfile -Command "Get-DnsClientServerAddress -AddressFamily IPv4 | Format-Table -Auto InterfaceAlias,ServerAddresses"
InterfaceAlias ServerAddresses
Ethernet        {10.10.0.10, 10.10.0.11}

Ce que cela signifie :

• Le DNS d’entreprise est normal sur VPN. Un DNS public sur un appareil d’entreprise peut être normal, ou violer une politique. Connaissez votre environnement.
• Un mauvais DNS (mauvais serveurs, serveurs morts) provoque un « tout est lent » sans usage élevé de bande passante.

Décision :

• Si les serveurs DNS semblent incorrects ou injoignables, corrigez le DNS avant de blâmer la « bande passante ».

Task 9: Mesurer rapidement la latence et les échecs DNS

cr0x@server:~$ powershell -NoProfile -Command "Measure-Command { 1..10 | ForEach-Object { Resolve-DnsName -Name microsoft.com -Type A | Out-Null } } | Select-Object TotalMilliseconds"
TotalMilliseconds
-----------------
842

Ce que cela signifie :

• Moins d’une seconde pour 10 résolutions est acceptable dans de nombreux environnements (avec effet de cache).
• Si cela prend plusieurs secondes ou génère des erreurs intermittentes, vous avez trouvé un coupable de latence qui imite une famine de bande passante.

Décision :

• Corrigez le DNS (accessibilité serveur, DNS split sur VPN, politique de résolveur) plutôt que d’essayer de « limiter les téléchargements ».

Tâches 10–12 : Compteurs Performance Monitor qui comptent vraiment

PerfMon est assez ancien pour avoir des opinions sur vos choix de police, mais c’est toujours l’un des meilleurs moyens
de voir si vous saturez une interface ou si vous êtes noyé dans des retransmissions et des files d’attente.

Task 10: Identifier le nom de l’interface réseau utilisé par les compteurs

cr0x@server:~$ powershell -NoProfile -Command "Get-Counter -ListSet 'Network Interface' | Select-Object -ExpandProperty Paths | Select-Object -First 8"
\\DESKTOP-7Q9K\Network Interface(Intel[R] Ethernet Connection)\Bytes Received/sec
\\DESKTOP-7Q9K\Network Interface(Intel[R] Ethernet Connection)\Bytes Sent/sec
\\DESKTOP-7Q9K\Network Interface(Intel[R] Ethernet Connection)\Output Queue Length
\\DESKTOP-7Q9K\Network Interface(Intel[R] Ethernet Connection)\Packets Outbound Errors
\\DESKTOP-7Q9K\Network Interface(Intel[R] Ethernet Connection)\Packets Received Errors

Ce que cela signifie :

• Les instances de compteurs incluent la chaîne du modèle d’adaptateur. Vous avez besoin du bon si vous avez VPN, Wi‑Fi, Ethernet, switches virtuels.

Décision :

• Sélectionnez l’interface pertinente et échantillonnez quelques compteurs clés pendant la fenêtre « c’est lent ».

Task 11: Échantillonner bytes/sec et longueur de file pendant 30 secondes

cr0x@server:~$ powershell -NoProfile -Command "Get-Counter '\Network Interface(Intel[R] Ethernet Connection)\Bytes Total/sec','\Network Interface(Intel[R] Ethernet Connection)\Output Queue Length' -SampleInterval 1 -MaxSamples 10 | Select-Object -ExpandProperty CounterSamples | Select-Object Path,CookedValue | Format-Table -Auto"
Path                                                                 CookedValue
----                                                                 -----------
\\...\Bytes Total/sec                                                8234512
\\...\Output Queue Length                                            0
\\...\Bytes Total/sec                                                9123301
\\...\Output Queue Length                                            0

Ce que cela signifie :

• Bytes Total/sec indique le débit réel. Convertissez en Mbps approximativement : bytes/sec × 8 ÷ 1 000 000.
• Output Queue Length constamment au-dessus de 0 peut indiquer congestion/problèmes de buffer (le contexte importe avec les pilotes modernes).

Décision :

• Si vous êtes près de la capacité du lien pendant de longues périodes, il faut une décision de politique de bande passante (throttle/planification), pas une chasse aux sorcières.
• Si le buffering est élevé mais le débit faible, suspectez un pilote, des retransmissions Wi‑Fi, ou une congestion amont.

Task 12: Surveiller les retransmissions TCP (la perte déguisée en « internet lent »)

cr0x@server:~$ powershell -NoProfile -Command "Get-Counter '\TCPv4\Segments Retransmitted/sec','\TCPv4\Segments/sec' -SampleInterval 1 -MaxSamples 10 | Select-Object -ExpandProperty CounterSamples | Group-Object Path | ForEach-Object { $_.Group | Select-Object -First 1 } | Format-Table -Auto"
Path                                   CookedValue
----                                   -----------
\\DESKTOP-7Q9K\TCPv4\Segments/sec       18500
\\DESKTOP-7Q9K\TCPv4\Segments Retransmitted/sec 240

Ce que cela signifie :

• Les retransmissions arrivent. Beaucoup de retransmissions, de manière constante, signifient perte ou congestion sévère. Cela tue les applications interactives.
• Si les retransmissions grimpent sur le Wi‑Fi mais pas sur Ethernet, vous avez votre coupable sans blâmer Windows Update.

Décision :

• Problème de perte : changez de support (Ethernet), améliorez le signal, réduisez les interférences, mettez à jour pilote/firmware, vérifiez le MTU du VPN.

Les suspects habituels : Windows Update, Delivery Optimization, OneDrive, Store, Defender

Si vous travaillez en entreprise, Windows n’est pas « juste un OS ». C’est une plateforme avec un système de distribution de contenu,
une protection endpoint, du reporting de conformité et des fonctionnalités de synchronisation. Ce n’est pas optionnel dans de nombreux environnements.
Votre travail est de les rendre prévisibles.

Delivery Optimization (DoSvc) : peer-to-peer et « pourquoi mon upload est occupé ? »

Delivery Optimization est la fonction intégrée de distribution de contenu de Windows. Elle peut télécharger des mises à jour depuis Microsoft,
et selon la politique, depuis des pairs sur le LAN ou même sur Internet. Le côté upload surprend souvent les gens.

cr0x@server:~$ powershell -NoProfile -Command "Get-Service DoSvc | Format-List Name,Status,StartType,DisplayName"
Name       : DoSvc
Status     : Running
StartType  : Manual
DisplayName: Delivery Optimization

Ce que cela signifie :

• Si le service tourne lors d’un ralentissement, il peut être en train de transférer du contenu activement.
• StartType Manual ne signifie pas « inactif ». Windows le lance quand il le veut.

Décision :

• En entreprise, ne le désactivez pas aveuglément—la politique peut en dépendre. Limitez plutôt son débit.

Pour inspecter le comportement de Delivery Optimization (supporté, intégré) :

cr0x@server:~$ powershell -NoProfile -Command "Get-DeliveryOptimizationStatus | Select-Object -First 5 | Format-Table -Auto"
FileId                               SourceURL                          BytesDownloaded BytesUploaded PeerCaching
------                               ---------                          -------------- ------------- -----------
{A1B2C3D4-...}                        https://...                        104857600       5242880       True

Ce que cela signifie :

• Affiche les téléchargements/uploads attribuables à Delivery Optimization.
• Si BytesUploaded est non négligeable et que votre lien montant est contraint, c’est la réponse à « pourquoi l’upload est occupé ? ».

Décision :

• Définissez des limites de bande passante via Paramètres ou politique. Si vous possédez l’appareil, utilisez Paramètres. Si l’IT le gère, demandez un changement de politique.

Windows Update (wuauserv) : gros téléchargements, mauvais timing

cr0x@server:~$ powershell -NoProfile -Command "Get-Service wuauserv,BITS | Format-Table -Auto Name,Status,StartType,DisplayName"
Name     Status  StartType DisplayName
----     ------  --------- -----------
wuauserv Running Manual    Windows Update
BITS     Running Manual    Background Intelligent Transfer Service

Ce que cela signifie :

• BITS est un service de transfert « poli », mais « poli » dépend du contexte. Il peut quand même gêner un appel sur un petit lien montant.
• Windows Update utilisera aussi Delivery Optimization selon les paramètres/politiques.

Décision :

• Définissez correctement les Heures actives et envisagez une connexion mesurée si vous êtes sur un hotspot.
• En entreprise : assurez-vous de disposer d’anneaux de mise à jour et de fenêtres de maintenance, sinon vous aurez des pics aléatoires en journée.

OneDrive : les tempêtes de synchronisation existent

OneDrive est généralement bien élevé jusqu’à ce qu’il ne le soit plus : gros déplacements de dossiers, actifs CAO, fichiers PST,
ou un utilisateur qui « organise » un dossier partagé en le déplaçant.

cr0x@server:~$ powershell -NoProfile -Command "Get-Process OneDrive -ErrorAction SilentlyContinue | Select-Object Name,Id,CPU,Path | Format-Table -Auto"
Name    Id    CPU Path
----    --    --- ----
OneDrive 7324  88 C:\Users\alice\AppData\Local\Microsoft\OneDrive\OneDrive.exe

Ce que cela signifie :

• Si OneDrive est actif et que le Gestionnaire des tâches montre une utilisation réseau, vous êtes probablement en train de synchroniser.

Décision :

• Mettre la synchronisation en pause pendant les appels. Configurez les limites d’upload/download si vous êtes souvent contraint.

Microsoft Store / mises à jour d’apps

Les mises à jour d’apps peuvent se lancer discrètement et de manière répétée, surtout après le déploiement d’une image ou lorsque beaucoup d’apps se mettent à jour en même temps.

cr0x@server:~$ powershell -NoProfile -Command "Get-Service InstallService | Format-List Name,Status,StartType,DisplayName"
Name       : InstallService
Status     : Running
StartType  : Manual
DisplayName: Microsoft Store Install Service

Décision :

• Si les mises à jour du Store posent problème en journée, désactivez la mise à jour automatique en politique (entreprise) ou ajustez les paramètres du Store (personnel).

Microsoft Defender et outils de sécurité : les scans peuvent déclencher du réseau

Defender lui-même n’est généralement pas un gros consommateur de bande passante, mais les piles de sécurité peuvent faire des recherches cloud, vérifications de réputation,
et de la télémétrie. Le « hog » peut être un agent d’entreprise plutôt que Windows.

cr0x@server:~$ powershell -NoProfile -Command "Get-Process | Where-Object { $_.ProcessName -match 'MsMpEng|Sense|Crowd|Carbon|Sentinel' } | Select-Object ProcessName,Id,CPU | Sort-Object CPU -Descending | Format-Table -Auto"
ProcessName Id    CPU
----------- --    ---
MsMpEng     4100  120

Décision :

• Si l’agent effectue un travail lourd pendant les heures de bureau, la solution est la planification et la politique—évitez de jouer au tueur de processus.

Blague #1 : Si vous installez un « optimiseur de bande passante », votre PC ira plus vite—directement dans un nouveau ticket d’incident.

Quand le coupable est svchost.exe : lever le masque en sécurité

svchost.exe est un hôte de services, pas un « programme » au sens utilisateur. De nombreux services Windows y tournent.
Si svchost consomme de la bande passante, votre mission est d’identifier quel service à l’intérieur est responsable.

Tâche : Mapper le PID svchost aux services hébergés

cr0x@server:~$ cmd /c "tasklist /svc /fi "imagename eq svchost.exe""
Image Name                     PID Services
svchost.exe                   1348 BITS, wuauserv
svchost.exe                   1720 DoSvc
svchost.exe                   1020 Dhcp, NlaSvc

Ce que cela signifie :

• Vous pouvez maintenant relier les points : si le PID 1720 parle à beaucoup d’extrémités 443 et qu’il héberge DoSvc, vous avez une histoire Delivery Optimization.
• Si c’est DHCP/NLA, ce n’est généralement pas très consommateur de bande passante, mais cela peut indiquer des oscillations réseau (qui génèrent d’autres trafics).

Décision :

• Pour BITS/wuauserv/DoSvc : appliquez des throttles et une planification des mises à jour/DO.
• Pour des services étranges : étudiez leur fonction avant de les désactiver. « Désactiver des services au hasard » n’est pas une stratégie ; c’est un passe-temps.

Trois mini-récits d’entreprise tirés du terrain

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

Une entreprise de taille moyenne a déployé une nouvelle image Windows 11 sur quelques centaines de portables. Une semaine plus tard, la file d’assistance s’est remplie de
tickets « Le Wi‑Fi est inutilisable », principalement entre 9h et 11h. La première hypothèse était classique : « Le FAI a un problème. »
Cette hypothèse a tenu jusqu’à ce que quelqu’un remarque que le bureau voisin (autre locataire, même FAI) allait bien.

La seconde hypothèse était plus assurée : « C’est Teams. » Les utilisateurs étaient en appel, les appels étaient mauvais, donc l’application était blâmée.
Les gens ont commencé à recommander de désactiver la vidéo HD et de n’utiliser que l’audio. Cela a aidé un peu, ce qui a donné l’illusion d’une solution,
mais cela n’a pas résolu le problème de fond et a rendu les réunions pénibles. Une atténuation partielle reste un échec si vous cessez d’investiguer.

La cause réelle est apparue au moment où quelqu’un a lancé le Moniteur de ressources sur une machine en difficulté :
svchost.exe poussait beaucoup de données, et netstat montrait des sessions 443 longue durée vers des plages IP appartenant à Microsoft.
Le mappage PID vers les services pointait vers DoSvc et BITS. Delivery Optimization avait été configuré (par des « paramètres par défaut aidants »)
pour autoriser les uploads entre pairs sur le LAN. Dans un bureau avec des uplinks faibles et beaucoup de machines nouvellement imagées, cela a créé un churn constant.

La solution n’a pas été de désactiver les mises à jour. Il a fallu régler Delivery Optimization pour être LAN-only (ou désactiver l’upload pair),
limiter la bande passante en arrière-plan pendant les heures de bureau, et étaler les téléchargements via des fenêtres de maintenance.
Les appels sont revenus à la normale. L’assistance a arrêté de diagnostiquer la météo.

La leçon : « Problème FAI » est une hypothèse confortable parce qu’elle ne demande aucune action. Elle est fréquemment fausse.

Mini-récit 2 : L’optimisation qui a mal tourné

Une équipe entreprise a tenté de réduire l’usage WAN pour des sites distants. Leur idée brillante :
forcer un caching agressif et la distribution pair-à-pair des mises à jour partout. L’intention était bonne—la sortie CDN coûte cher,
et Windows supporte la distribution distribuée. Le problème était la contrainte ignorée : l’asymétrie des uplinks.

Dans les petits sites, les téléchargements étaient corrects mais l’upload était minuscule. L’upload pair signifiait que dès qu’un PC avait une mise à jour,
il devenait un mini-serveur de contenu sur une connexion à peine capable d’envoyer des pièces jointes. Les utilisateurs se plaignaient que « l’internet meurt »
quand l’ordinateur d’un collègue était allumé. Ce collègue ne faisait rien de mal ; il était juste victime de la politique.

L’équipe réseau a réagi en ajoutant des règles QoS priorisant la voix. Les règles ont aidé, mais ont aussi introduit de la complexité et
un comportement incohérent selon les modèles de matériel. Certains points d’accès respectaient les marquages, d’autres non. Pendant ce temps, les endpoints continuaient d’uploader.
L’« optimisation » est devenue une taxe opérationnelle continue.

Finalement, ils ont remplacé la politique globale par des réglages par niveau : les grands sites pouvaient utiliser la distribution pair, les petits non.
Ils ont aussi limité fortement l’upload et appliqué des fenêtres de mises à jour. La consommation n’a pas disparu, mais elle est devenue prévisible.
Prévisible bat « surprenant » à chaque fois.

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

Un service financier avait un processus de clôture mensuelle. Même jour chaque mois, même énergie frénétique, mêmes plaintes « le réseau est lent ».
L’équipe IT n’a pas paniqué ; elle avait l’habitude ennuyeuse suivante : capturer un baselines léger chaque semaine en utilisant des compteurs intégrés
et un petit script PowerShell stocké dans un runbook partagé.

Quand la plainte est arrivée, ils savaient déjà à quoi ressemblait le « normal » : bytes/sec typiques sur l’interface principale,
taux de retransmission typiques sur le Wi‑Fi, et services d’arrière-plan principaux. Ils avaient aussi une checklist commençant par :
« Sommes‑nous saturés, ou la latence est‑elle élevée ? » La réponse a été immédiate—le débit n’était pas si élevé, mais les retransmissions ont explosé.

Ils ont parcouru les locaux et trouvé un nouveau switch non géré branché sur un port uplink qui créait une boucle.
Le réseau était inondé de trafic broadcast et de retries, pas de « applications hog ». Ils ont retiré le switch,
les retransmissions ont chuté, et tout est revenu à la normale. Pas de débogage héroïque. Juste baseline + méthode.

Voilà l’intérêt de la pratique ennuyeuse : elle raccourcit la durée des problèmes excitants.

Faits intéressants et contexte historique

• PerfMon précède la plupart des outils d’observabilité « modernes ». Les compteurs de performance Windows existent depuis l’ère NT et sont toujours de première classe.
• BITS a été conçu pour des transferts « polis ». Il tente d’utiliser la bande passante idle, mais « idle » n’est pas une vérité universelle—surtout sur les liens asymétriques.
• La consolidation svchost était une stratégie de ressources. Héberger plusieurs services réduisait la surcharge, mais compliquait l’attribution jusqu’à l’arrivée de meilleurs outils.
• Delivery Optimization est essentiellement un système de distribution de contenu. Pas nouveau en concept—les CDN et la distribution pair existent depuis des décennies—mais maintenant c’est intégré à l’OS.
• Windows sépare depuis longtemps les apps utilisateur de l’infrastructure de service. C’est pourquoi « System » et « Service Host » apparaissent : beaucoup de travail se passe en dessous de la couche applicative.
• Les retransmissions TCP sont le tueur caché des liens « rapides ». Vous pouvez avoir un bon signal et souffrir d’interférences ou de bufferbloat.
• Les connexions mesurées ont été ajoutées parce que les gens recevaient des factures surprises. Windows a appris, lentement, que les réseaux ne sont pas tous illimités.
• Netstat est plus ancien que la plupart des problèmes qu’il diagnostique. Il reste utile parce que les sockets restent la source de vérité pour les connexions.

Erreurs courantes : symptôme → cause racine → correction

Cette section est volontairement franche. La plupart des dépannages de bande passante déraillent parce que les gens traitent les symptômes comme des diagnostics.

1) « La qualité de mon appel est terrible » → « hog de bande passante » → En réalité perte de paquets/retransmissions Wi‑Fi

• Symptôme : Les appels saccadent alors que le Gestionnaire des tâches montre une faible utilisation réseau.
• Cause racine : Perte/retransmissions, interférence, pilote défaillant, ou AP congestionné.
• Correction : Vérifiez les compteurs de retransmissions TCP ; essayez Ethernet ; mettez à jour le pilote Wi‑Fi ; rapprochez‑vous du point d’accès ; passez en 5 GHz/6 GHz ; vérifiez les problèmes MTU du VPN.

2) « L’upload est saturé mais je n’envoie rien » → Delivery Optimization upload pair

• Symptôme : Uplink occupé, surtout après le patch Tuesday ou l’imagerie de nouveaux appareils.
• Cause racine : DoSvc uploadant du contenu vers des pairs (piloté par la politique).
• Correction : Utilisez Get-DeliveryOptimizationStatus ; limitez l’upload ; désactivez l’upload pair là où c’est inapproprié ; imposez des fenêtres de mise à jour.

3) « Tout est lent » → « Le FAI est mauvais » → En réalité DNS/boucles proxy

• Symptôme : Les pages web restent bloquées au démarrage, les téléchargements ne montent pas, les apps semblent collantes.
• Cause racine : Réponses DNS lentes, DNS split cassé sur VPN, boucles d’auth proxy générant de petites requêtes répétées.
• Correction : Mesurez le temps DNS avec PowerShell ; vérifiez les serveurs DNS ; contrôlez la configuration proxy et les identifiants ; consultez l’Observateur d’événements si nécessaire.

4) « svchost utilise de la bande passante » → « Tuez‑le » → Puis Windows devient bizarre

• Symptôme : Service Host en tête de la colonne Réseau.
• Cause racine : L’un des nombreux services hébergés (BITS/wuauserv/DoSvc) effectuant un travail légitime.
• Correction : Mappez le PID aux services avec tasklist /svc ; ajustez les paramètres/politiques ; évitez de tuer les hôtes essentiels.

5) « On va limiter la bande passante avec le QoS et c’est réglé » → L’optimisation se retourne contre vous

• Symptôme : Certains utilisateurs s’améliorent, d’autres empirent ; comportement différent selon l’appareil/AP.
• Cause racine : QoS appliqué de manière incohérente, ou plafonds mis sur la mauvaise classe de trafic ; asymétrie du lien ignorée.
• Correction : Commencez par l’attribution côté endpoint et une planification sensée ; appliquez ensuite le QoS comme un contrôle ciblé, pas comme un substitut au diagnostic.

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

Checklist A: « Quelque chose bouffe la bande passante maintenant » (10 minutes)

1. Gestionnaire des tâches → trier par Réseau. Notez les 3 processus principaux.
2. Ouvrez le Moniteur de ressources → onglet Réseau → filtrez le processus suspect → notez les IPs/ports distants.
3. Exécutez netstat -ano et mappez les principaux PIDs aux processus/commandes.
4. Si c’est svchost.exe : mappez le PID aux services avec tasklist /svc.
5. Si c’est lié aux mises à jour : vérifiez DoSvc/BITS/wuauserv et l’état de Delivery Optimization.
6. Appliquez le contrôle le moins risqué : pause synchronisation, pause mises à jour temporaire, définir connexion mesurée, ou throttler DO.

Checklist B: « Ça paraît lent, mais les chiffres de bande passante sont faibles » (15 minutes)

1. Vérifiez l’adaptateur et la vitesse link (Get-NetAdapter).
2. Mesurez la performance DNS (Resolve-DnsName en boucle + Measure-Command).
3. Vérifiez les compteurs de retransmissions TCP (Get-Counter).
4. Si vous êtes en Wi‑Fi : testez en Ethernet ou hotspot pour isoler problèmes RF vs amont.
5. Si vous êtes sur VPN : testez la politique de split tunneling et les serveurs DNS ; cherchez des symptômes MTU (sites partiellement chargés, gros uploads bloqués).

Checklist C: « Empêcher que cela se reproduise » (continu)

1. Fixez des fenêtres de mise à jour/heures actives réalistes.
2. Configurez des limites d’upload Delivery Optimization adaptées à votre lien montant.
3. Définissez le périmètre de synchronisation OneDrive (synchronisation sélective) et des limites de bande passante.
4. Faites une baseline régulière des compteurs clés : bytes/sec, retransmits/sec, taux link Wi‑Fi.
5. Documentez les « top talkers » attendus dans votre environnement (agent endpoint, client VPN, patching).

Blague #2 : Le réseau n’est jamais « en panne ». Il est juste en train de prendre une pause de carrière non planifiée.

Plus de tâches pratiques (avec commandes, signification et décisions)

Vous avez déjà 12 tâches ci‑dessous. En voici d’autres qui rapportent dans des environnements désordonnés—surtout avec des builds d’entreprise.
Utilisez‑les quand les vérifications évidentes ne donnent pas de réponse claire.

Tâche : Afficher les connexions TCP actives avec le nom du processus propriétaire (admin requis pour -b)

cr0x@server:~$ cmd /c "netstat -abno | more"
...Shows connections plus the executable involved; may prompt for elevation...

Ce que cela signifie : -b ajoute le nom du binaire. Cela peut révéler quel exécutable auxiliaire fait réellement des connexions.

Décision : Si le binaire est inattendu (updater, helper, agent), localisez son application parente et vérifiez son planning/paramètres.

Tâche : Vérifier quels processus écoutent (utile pour « pourquoi ce port est ouvert ? »)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetTCPConnection -State Listen | Select-Object -First 10 | Format-Table -Auto LocalAddress,LocalPort,OwningProcess"
LocalAddress LocalPort OwningProcess
------------ --------- -------------
0.0.0.0      445       4
0.0.0.0      135       988
127.0.0.1    49664     1020

Ce que cela signifie : Les ports à l’écoute ne sont pas une consommation de bande passante, mais aident à identifier des services (SMB, RPC, proxies locaux) corrélés au trafic.

Décision : Si vous voyez un proxy local ou un listener inhabituel, vérifiez si votre navigateur/VPN/stack de sécurité y tunnelise le trafic.

Tâche : Mapper un PID propriétaire de Get-NetTCPConnection à un processus

cr0x@server:~$ powershell -NoProfile -Command "Get-Process -Id 988 | Select-Object Id,ProcessName,Path | Format-List"
Id          : 988
ProcessName : svchost
Path        : C:\Windows\System32\svchost.exe

Décision : Si c’est svchost, mappez aux services (tasklist /svc) avant de toucher quoi que ce soit.

Tâche : Vérification rapide de la table de routage (une mauvaise route = lenteur étrange)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetRoute -AddressFamily IPv4 | Sort-Object RouteMetric | Select-Object -First 12 | Format-Table -Auto DestinationPrefix,NextHop,InterfaceAlias,RouteMetric"
DestinationPrefix NextHop     InterfaceAlias RouteMetric
----------------- -------     -------------- -----------
0.0.0.0/0         192.168.1.1 Ethernet        25
10.0.0.0/8        10.8.0.1    VPN             5

Ce que cela signifie : Les métriques de route décident où va le trafic. Les routes VPN avec une métrique faible peuvent canaliser tout le trafic via un tunnel contraint.

Décision : Si votre route par défaut passe par le VPN de façon inattendue, vérifiez les paramètres/politiques du VPN ; ne « corrigez » pas en supprimant des routes au hasard.

Tâche : Vérifier le proxy WinHTTP (souvent différent du proxy du navigateur)

cr0x@server:~$ cmd /c "netsh winhttp show proxy"
Current WinHTTP proxy settings:

    Proxy Server(s) : 10.10.0.20:8080
    Bypass List     : (none)

Ce que cela signifie : Certains services utilisent les paramètres proxy WinHTTP. Un proxy mal configuré peut créer des retries et de la lenteur.

Décision : Si le proxy est erroné/obsolète, corrigez via la politique ou réinitialisez (dans les environnements gérés, coordonnez avec l’IT).

Tâche : Afficher les détails du lien Wi‑Fi (signal/débit indicatifs)

cr0x@server:~$ cmd /c "netsh wlan show interfaces"
    Name                   : Wi-Fi
    State                  : connected
    Signal                 : 68%
    Receive rate (Mbps)    : 433.3
    Transmit rate (Mbps)   : 144.4

Ce que cela signifie : Un faible débit de transmission peut nuire aux appels et aux uploads même si les téléchargements semblent corrects.

Décision : Si les débits sont faibles ou fluctuants, traitez cela comme un problème RF : congestion de canal, distance, interférence.

FAQ

1) Puis‑je trouver l’utilisation de la bande passante par processus sans rien installer ?

Oui. Utilisez le Gestionnaire des tâches (colonne Réseau) pour une vue rapide, le Moniteur de ressources pour les connexions, et netstat + mappage PID pour l’attribution.

2) Pourquoi « Service Host » utilise de la bande passante au lieu d’un nom d’application ?

Parce que de nombreux services Windows s’exécutent à l’intérieur de svchost.exe. Utilisez tasklist /svc pour mapper le PID aux services spécifiques.

3) Est‑ce sûr de désactiver BITS ou Windows Update pour arrêter l’utilisation de la bande passante ?

Arrêter temporairement un service peut être une étape de dépannage, mais désactiver l’infrastructure de mise à jour à long terme est un risque de sécurité.
Préférez la planification, le throttling et des fenêtres de mise à jour appropriées.

4) Quel est le moyen le plus rapide pour dire si le problème est saturation de débit ou latence ?

Vérifiez le débit de l’interface (PerfMon Bytes Total/sec) et les retransmissions. Un débit élevé proche de la capacité du lien suggère une saturation.
Beaucoup de retransmissions avec un débit modeste suggèrent perte/latence.

5) Pourquoi mon upload est occupé alors que je « télécharge » des mises à jour ?

Delivery Optimization peut uploader du contenu vers des pairs. Confirmez avec Get-DeliveryOptimizationStatus et ajustez les limites/politiques d’upload.

6) Le Gestionnaire des tâches montre une faible utilisation réseau, mais les sites web mettent une éternité à commencer à se charger. Pourquoi ?

Souvent latence DNS, problèmes proxy, ou boucles d’authentification. Mesurez le DNS avec des Resolve-DnsName répétées et vérifiez les paramètres proxy WinHTTP.

7) Windows peut‑il limiter la bande passante en arrière‑plan sans outils tiers ?

Oui. Utilisez les paramètres/politiques Delivery Optimization et les connexions mesurées. Beaucoup de services Microsoft respectent ces réglages.

8) Comment identifier les serveurs distants avec lesquels un processus communique ?

Le Moniteur de ressources et netstat -ano montrent les IPs et ports distants. Traduire une IP en « nom » n’est pas toujours fiable à cause des CDN,
mais la plage IP et le mappage des services vous rapprochent généralement d’une décision.

9) Le trafic « System » est‑il toujours Windows Update ?

Non. « System » peut inclure l’activité de la pile réseau, des transferts SMB, des pilotes VPN, et d’autres composants au niveau kernel.
Utilisez les tables de connexion et le mappage des services plutôt que d’assumer.

10) Que dois‑je envoyer à l’IT si j’ai besoin d’aide ?

Fournissez : horodatage, interface (Wi‑Fi/Ethernet/VPN), processus principal par Réseau, PIDs pertinents, IPs/ports distants, et si les retransmissions sont élevées.
C’est un ticket exploitable.

Prochaines étapes que vous pouvez faire aujourd’hui

1. Lors du ralentissement, capturez deux captures d’écran : Gestionnaire des tâches trié par Réseau, Moniteur de ressources TCP Connections filtré sur le processus principal.
   Les preuves valent mieux que les impressions.
2. Exécutez netstat -ano et mappez les PIDs importants. Si c’est svchost, mappez aux services avec tasklist /svc.
3. Si les mises à jour sont en cause, ne faites pas la guerre au patching. Définissez les Heures actives, ajustez Delivery Optimization, et limitez l’upload sur les liens contraints.
4. Si l’utilisation est faible mais la lenteur élevée, traitez‑le comme un problème de latence/perte : vérifiez les débits Wi‑Fi et les retransmissions TCP.
5. Notez à quoi ressemble le « normal » sur votre machine une fois. Les baselines sont peu coûteuses. Les pannes, non.

L’astuce consiste à refuser de deviner. Windows vous donne suffisamment d’observabilité intégrée pour identifier le coupable,
le service derrière le coupable, et le type de correction qui n’explosera pas en incident demain.