Une visioconférence qui se fige, une partie en ligne ponctuée de téléportations, un transfert qui ralentit malgré un abonnement rapide : ces symptômes peuvent révéler des pertes de paquets, mais ils ne prouvent pas que la box ou l’ordinateur est défectueux. Le problème peut venir d’un réseau sans fil encombré, d’un envoi de fichiers qui monopolise la connexion, d’un pilote instable ou d’un incident chez un opérateur.
Pour éviter un achat inutile, le plus efficace consiste à comparer des mesures reproductibles, depuis l’ordinateur jusqu’au service concerné. Prenons le cas de Camille, qui travaille à domicile et subit des coupures audio chaque après-midi : son enquête permettra de distinguer un défaut local, une saturation passagère et une difficulté extérieure, puis de vérifier chaque correction sans remplacer immédiatement son équipement.
Pertes de paquets, latence et jitter : mesurer le bon problème
Pourquoi un bon débit ne garantit pas une connexion stable
Sur Internet, les informations circulent sous forme de petits blocs. Lorsqu’un de ces blocs n’atteint pas sa destination, on parle de perte ; selon le protocole et l’application, les données manquantes peuvent être retransmises, compensées ou abandonnées. Un téléchargement supporte souvent cette récupération, tandis qu’une conversation audio ne peut pas attendre indéfiniment un fragment de voix.
La latence correspond au délai de transmission, généralement observé sous forme de temps aller-retour. Le jitter, ou gigue, décrit ses variations : une liaison peut afficher une moyenne correcte tout en présentant des pointes gênantes. Ces indicateurs complètent le pourcentage de réponses manquantes, sans se confondre avec lui.
Les tests de débit mesurent surtout une capacité de transfert pendant une période donnée. Ils ne suffisent donc pas à expliquer une réunion hachée : Camille obtient une vitesse élevée, mais ses interlocuteurs l’entendent mal dès qu’une sauvegarde démarre. Son problème concerne alors davantage le comportement sous charge que la performance maximale annoncée.
Réaliser un test de ping suffisamment long
Commencez par identifier la passerelle par défaut, c’est-à-dire généralement l’adresse locale de la box. Sous Windows, la commande ipconfig permet de la retrouver ; ne supposez pas qu’elle vaut systématiquement 192.168.1.1. Dans deux fenêtres distinctes, vous pourrez ensuite interroger cette passerelle et une destination publique qui accepte les requêtes ICMP.
Un exemple sous Windows est ping -n 600 192.168.1.1, en adaptant l’adresse, puis ping -n 600 1.1.1.1. Avec les paramètres habituels, chaque série dure environ dix minutes, parfois davantage si des réponses expirent. Sous Linux ou macOS, utilisez par exemple ping -c 600 1.1.1.1.
Effectuez une première campagne au repos, puis une seconde pendant l’activité qui déclenche les coupures. Notez les horaires, le mode de raccordement, les applications ouvertes et les symptômes constatés. Si votre outil exporte les délais individuels, examinez aussi leur médiane et leur 95e centile : une moyenne seule peut masquer des ralentissements ponctuels importants.
- Tester la passerelle pour observer le trajet local.
- Interroger deux destinations publiques pour éviter de dépendre d’un seul serveur.
- Observer l’application concernée pendant la même plage horaire.
- Conserver les résultats bruts afin de comparer les essais suivants.
Interpréter les réponses manquantes sans faux diagnostic
Un serveur peut limiter les réponses au ping sans perdre le trafic utile. Inversement, une communication applicative peut échouer alors que les petites sondes ICMP passent normalement, notamment si les ports, les tailles de messages ou les chemins diffèrent. Un délai dépassé constitue un indice, pas une preuve suffisante de panne matérielle.
Quelques événements isolés n’ont pas le même effet qu’une rafale d’interruptions. Sur 600 sondes, six absences représentent 1 %, mais six secondes consécutives de silence peuvent être bien plus perceptibles que des événements dispersés. Certains mécanismes de contrôle de congestion utilisent d’ailleurs les pertes comme signal pour ralentir ; tout incident observé ne traduit donc pas un composant défaillant.
Camille associe finalement les coupures vocales à des pointes de délai, plutôt qu’à une baisse permanente de vitesse. La première étape du diagnostic réseau consiste à caractériser le symptôme avant de chercher son responsable.
Wi-Fi, ordinateur ou opérateur : localiser les pertes de paquets
Comparer les appareils et les modes de raccordement
Une fois le phénomène confirmé, changez une seule variable à la fois. Faites fonctionner le même ordinateur sur le réseau sans fil, puis en Ethernet si un câble est disponible, en désactivant temporairement le Wi-Fi pour garantir le trajet utilisé. Reprenez les mêmes destinations et une durée comparable : sinon, une amélioration peut simplement correspondre à une période moins chargée.
Répétez ensuite l’expérience avec un second terminal. Si un seul poste rencontre des difficultés alors que les autres fonctionnent correctement au même moment, examinez son pilote, ses logiciels et sa charge système. Si plusieurs machines présentent simultanément des anomalies, le point commun devient plus intéressant : point d’accès, box, liaison extérieure ou service distant.
Le test vers l’adresse de bouclage, comme 127.0.0.1, peut vérifier une partie du fonctionnement local, mais il ne traverse pas la carte physique. Un résultat parfait ne valide donc ni le câble ni la radio. Chez Camille, l’absence de problème en Ethernet oriente l’enquête vers le sans-fil, sans démontrer pour autant que son point d’accès doit être remplacé.
Lire traceroute et MTR sans accuser le mauvais routeur
La commande traceroute, appelée tracert sous Windows, révèle une succession de réponses provenant du chemin vers une destination. MTR répète ce type d’observation et présente des statistiques par saut. Ces outils permettent de repérer un changement de comportement, mais ils ne constituent pas une radiographie parfaite du réseau.
Un équipement intermédiaire peut ignorer les sondes qui lui sont adressées tout en transférant normalement les communications. Ainsi, un saut affichant 70 % d’absences, suivi d’une destination finale sans anomalie, ne prouve pas une perte de trafic traversant ce routeur. La persistance du problème jusqu’à la destination compte davantage qu’une ligne isolée.
Les trajets aller et retour peuvent également différer. Une dégradation visible à partir d’un certain niveau ne permet donc pas toujours d’identifier précisément le lien responsable. Par ailleurs, les commutateurs ordinaires de niveau 2 n’apparaissent pas dans ce relevé : leurs compteurs doivent être consultés séparément lorsque l’administration du réseau le permet.
| Observation reproductible | Piste à examiner | Vérification complémentaire |
|---|---|---|
| Passerelle instable uniquement en sans-fil | Couverture, encombrement radio ou pilote | Se rapprocher du point d’accès et comparer en Ethernet |
| Un seul ordinateur touché | Configuration ou ressources du poste | Comparer pilotes, charge et logiciels de filtrage |
| Passerelle stable, plusieurs destinations perturbées | Accès extérieur, congestion ou traitement dans la box | Comparer au repos, sous charge et à différents horaires |
| Un seul service affecté | Application, VPN, hébergement ou chemin particulier | Consulter son état et comparer depuis un autre accès autorisé |
Distinguer le trajet réseau du fonctionnement du service
Lorsque seule une plateforme pose problème, consultez sa page d’état et ses statistiques internes. Les outils de visioconférence indiquent parfois les pertes audio, les délais et la qualité de réception ; ces données sont souvent plus pertinentes que le ping vers un serveur sans rapport. Une erreur d’API peut aussi provenir d’une application distante et non du transport.
Un VPN ajoute un tunnel, du chiffrement et parfois un détour géographique. Comparez son comportement activé et désactivé uniquement si la politique de sécurité l’autorise, sans exposer les ressources professionnelles. Localiser une anomalie signifie réduire le périmètre par comparaison, pas désigner un équipement sur la seule foi d’une trace.
Interférences Wi-Fi et saturation du réseau : corriger sans remplacer la box
Améliorer les conditions radio avant de changer d’équipement
Les interférences Wi-Fi et le partage du temps d’antenne peuvent provoquer des retransmissions, des attentes et parfois des données perdues. Le nombre de barres affiché ne décrit pas tout : un signal fort peut coexister avec un canal très occupé. Comparez les résultats à proximité du point d’accès, puis à l’endroit où vous travaillez habituellement.
Déplacez si possible la box hors d’un meuble fermé, loin d’obstacles métalliques et d’appareils perturbateurs. Les bandes 5 GHz ou 6 GHz peuvent offrir davantage de possibilités selon les équipements disponibles, mais traversent généralement moins bien les obstacles que le 2,4 GHz. Choisissez donc à partir de mesures sur place, et non d’une préférence systématique pour la fréquence la plus élevée.
Si l’interface permet une sélection de canal, observez d’abord l’environnement radio. Une largeur de canal excessive peut devenir contre-productive dans un immeuble dense ; une configuration plus modeste peut améliorer la régularité. Camille découvre ainsi que son bureau fonctionne mieux avec un réglage moins ambitieux, sans aucune modification de son abonnement.
Repérer la saturation du réseau et les files d’attente
La saturation du réseau apparaît lorsqu’une ressource ne peut plus absorber la demande. Une sauvegarde vers le cloud peut remplir le débit montant, tandis qu’un téléchargement peut encombrer la réception. Avant même les rejets, des files d’attente trop longues augmentent fortement les délais : ce phénomène est souvent appelé bufferbloat.
Pour le mettre en évidence, observez simultanément les temps de réponse au repos puis pendant un transfert. Si la destination publique devient très lente alors que la passerelle reste régulière, un goulot d’étranglement en sortie constitue une piste sérieuse, sans exclure d’autres causes. Consultez également les appareils actifs : synchronisation de photos, console et caméra connectée peuvent expliquer une charge inattendue.
Suspendez provisoirement les flux secondaires, puis répétez l’expérience. Si la conversation redevient nette, programmez les sauvegardes hors des réunions ou limitez leur vitesse dans l’application. Cette modification simple permet de vérifier une hypothèse avant de toucher à des paramètres plus complexes.
Utiliser l’analyse du routeur et la QoS avec méthode
L’analyse du routeur doit porter sur les journaux, l’utilisation des interfaces, les déconnexions et les compteurs accessibles. Une durée de fonctionnement qui repart régulièrement de zéro peut révéler des redémarrages ; des événements WAN répétés orientent plutôt vers l’accès extérieur. Sauvegardez ces éléments avant un redémarrage, qui risque d’effacer des indices utiles.
La QoS permet, selon l’équipement, de favoriser certaines catégories de communications. Les fonctions de gestion active des files, parfois proposées sous l’appellation SQM, cherchent surtout à contenir les délais sous charge. Elles nécessitent généralement une estimation réaliste des capacités de la ligne et peuvent réduire légèrement le débit maximal pour gagner en régularité.
Ces mécanismes ne créent pas de bande passante et ne réparent pas une liaison défectueuse. Une priorité mal choisie peut même défavoriser d’autres usages ; activez donc une fonction à la fois et contrôlez ses effets. Pour Camille, limiter les envois de sauvegarde suffit à stabiliser les échanges, ce qui évite une modification générale de toute l’installation.
La stabilité de connexion dépend autant du partage des ressources que de la puissance des appareils. Si les ajustements radio et la maîtrise des transferts ne changent rien, l’étape suivante consiste à observer ce que le poste accepte, rejette ou retransmet réellement.
Diagnostic réseau sous Windows : pilotes, compteurs et captures Pktmon
Contrôler la carte réseau et les ressources du poste
Sur un ordinateur isolément touché, commencez par les vérifications peu intrusives. Consultez la version du pilote et la date d’apparition des incidents ; une mise à jour provenant du fabricant peut corriger une anomalie, tandis qu’un retour à une version précédente peut être pertinent si les coupures ont commencé juste après une installation. Conservez de quoi revenir au réglage initial.
Dans PowerShell, Get-NetAdapterStatistics expose notamment des compteurs d’erreurs et de rejets, selon ce que le pilote fournit. Relevez-les avant et après la période problématique : des valeurs cumulées depuis longtemps sont moins informatives que leur augmentation pendant un incident. L’absence d’erreur déclarée n’exclut cependant pas toutes les difficultés.
Examinez aussi le processeur, la mémoire et les paramètres d’alimentation. Un système momentanément débordé peut manquer de ressources de réception, tandis qu’une fonction d’économie d’énergie peut perturber certains adaptateurs. Testez sa désactivation de manière ciblée ; évitez les changements massifs qui empêchent de comprendre quel réglage a réellement aidé.
Capturer les pertes locales avec Packet Monitor
Pktmon, intégré aux versions récentes de Windows, peut enregistrer le passage des paquets dans différents composants et signaler certains motifs d’abandon local. Dans un terminal administrateur, lancez pktmon.exe start -c, reproduisez brièvement la difficulté, puis exécutez pktmon.exe stop. La commande pktmon.exe etl2txt PktMon.etl produit une représentation textuelle de la capture.
Le fichier obtenu peut contenir une indication comme transport endpoint was not found. Pour un datagramme UDP entrant, cela peut signifier qu’aucun socket local n’écoute sur le port visé : le système rejette alors un message qui n’a pas de destinataire applicatif. Ce constat n’accuse ni le Wi-Fi ni l’opérateur et invite plutôt à vérifier le programme, son port et son état.
D’autres motifs peuvent concerner un filtrage, un en-tête invalide, une route absente ou un manque de ressources. Une résolution ARP en IPv4, ou Neighbor Discovery en IPv6, qui n’aboutit pas peut également empêcher l’envoi vers le prochain voisin. Les paquets en attente finissent alors par être abandonnés localement.
Compléter avec netsh et Wireshark sans surinterpréter
Si les premières traces restent insuffisantes, netsh.exe trace start scenario=InternetClient permet de recueillir davantage de contexte. Arrêtez ensuite l’enregistrement avec netsh.exe trace stop ; le scénario InternetServer correspond plutôt à une investigation côté serveur. La conversion textuelle peut se faire avec netsh.exe trace convert suivi du chemin du fichier ETL concerné.
Une mention Inspection drop associée à la Windows Filtering Platform oriente vers un composant de filtrage. Vérifiez ses règles et ses journaux avec l’administrateur plutôt que de désactiver globalement le pare-feu. Un rejet intentionnel de trafic non sollicité peut être parfaitement normal et ne pas expliquer les symptômes étudiés.
Wireshark complète l’examen en montrant le comportement des protocoles. Une retransmission TCP indique que l’émetteur n’a pas obtenu la confirmation attendue, mais ne localise pas automatiquement l’origine : données perdues, accusés de réception manquants, réorganisation ou capture incomplète peuvent compliquer l’interprétation. Les fonctions de déchargement matériel peuvent aussi produire des sommes de contrôle apparemment incorrectes dans une capture locale.
Limitez les enregistrements à la période utile et protégez-les : ils peuvent exposer des adresses et des informations sensibles. Une trace devient utile lorsqu’elle relie un événement technique au symptôme observé, pas lorsqu’elle accumule simplement des alertes.
MTU, opérateur et validation : prouver la correction des pertes de paquets
Examiner les causes extérieures au réseau local
Lorsque plusieurs appareils rencontrent les mêmes difficultés en Ethernet, avec une passerelle stable et des essais vers plusieurs destinations, l’accès extérieur mérite une investigation. Comparez les heures creuses et les périodes chargées, puis consultez les informations de liaison disponibles dans la box. Une hausse récurrente en soirée constitue un élément à documenter, sans prouver à elle seule une congestion chez le fournisseur.
Les politiques distantes peuvent également rejeter certaines communications. Un serveur hors ligne, un port sans application à l’écoute ou une règle de sécurité peuvent produire un silence ressemblant à une défaillance de transport. C’est pourquoi il faut croiser les mesures avec les journaux applicatifs et, lorsque cela est possible, les observations réalisées à l’autre extrémité.
Une session peut aussi expirer dans un équipement conservant un état, comme un dispositif NAT, un pare-feu ou un répartiteur de charge. Le scénario est caractéristique lorsqu’une connexion fonctionne, reste inactive, puis échoue à sa reprise. La solution peut concerner les délais d’expiration ou les mécanismes de maintien de session prévus par l’application, plutôt qu’un remplacement de box.
Vérifier la MTU sans appliquer de valeur arbitraire
La MTU définit la taille maximale d’un paquet transportable sur une liaison. Un tunnel VPN réduit parfois la place disponible pour les données, et certains messages trop volumineux nécessitent une fragmentation ou une adaptation. Lorsque la découverte de la MTU du chemin échoue, de petites requêtes peuvent fonctionner alors que des transferts plus importants se bloquent.
Des essais de ping avec tailles variables et interdiction de fragmentation peuvent aider en IPv4, mais leur interprétation dépend des réponses ICMP autorisées. Le raisonnement diffère en IPv6, où les routeurs ne fragmentent pas les paquets en transit. Ne modifiez pas la MTU au hasard : recherchez d’abord un lien entre taille des échanges, tunnel utilisé et messages d’erreur observés.
La vitesse et le duplex Ethernet méritent aussi un contrôle si des erreurs physiques apparaissent. L’autonégociation reste généralement le réglage approprié ; forcer un seul côté peut créer une incohérence au lieu de la résoudre. Avant tout achat, essayez un autre port disponible ou un câble connu comme fonctionnel, en conservant exactement le même protocole de mesure.
Construire un dossier exploitable et vérifier durablement
Pour contacter le support, fournissez les horaires avec le fuseau, les destinations, le raccordement utilisé et les résultats complets. Précisez si le phénomène touche plusieurs postes, s’il persiste sans VPN et s’il apparaît au repos ou sous charge. Joignez les comparaisons vers la passerelle et vers Internet, sans prétendre qu’une ligne intermédiaire silencieuse identifie forcément le responsable.
Dans un environnement professionnel, des tests bidirectionnels autorisés et des compteurs d’interface renforcent le dossier. Évitez de publier des captures brutes sur un forum : transmettez seulement les données nécessaires par un canal adapté. Les preuves doivent permettre au technicien de reproduire ou de corréler l’incident, pas simplement montrer qu’une application a affiché une erreur.
Après chaque correction, rejouez les mêmes essais aux mêmes heures et pendant une durée comparable. Camille vérifie ainsi plusieurs réunions après le déplacement de sa box et la limitation des sauvegardes ; une seule minute sans coupure n’aurait pas suffi à démontrer une amélioration durable. Conservez également les réglages appliqués pour pouvoir annuler une modification inefficace.
Pour une activité sensible, définissez des objectifs adaptés : délais, gigue, fréquence et durée des interruptions, plutôt qu’un seuil universel de perte acceptable. Un suivi périodique permet de détecter les dérives et les récidives. Une correction est démontrée lorsque les mesures s’améliorent et que l’usage retrouve sa fiabilité dans les conditions qui déclenchaient l’incident.
Quel pourcentage de pertes de paquets devient gênant ?
Il n’existe pas de seuil universel. L’effet dépend de l’application, de la durée des interruptions et de leur regroupement : une courte rafale peut fortement perturber la voix, alors qu’un transfert de fichiers récupère les données par retransmission. Comparez les mesures aux symptômes réels.
Pourquoi le ping indique-t-il des pertes alors que les sites fonctionnent ?
Certains équipements limitent les réponses ICMP sans rejeter le trafic applicatif. Testez plusieurs destinations et observez le service concerné avant de conclure à un défaut de connexion.
Changer de DNS peut-il supprimer les pertes de paquets ?
Un autre résolveur peut résoudre un problème de traduction des noms ou parfois orienter vers une autre infrastructure. Il ne répare pas une liaison radio perturbée, un câble défectueux ou une saturation. Une anomalie reproduite vers une adresse IP directe ne s’explique généralement pas par la résolution DNS.
Faut-il réinitialiser toute la configuration réseau dès les premières coupures ?
Mieux vaut relever les paramètres et recueillir des mesures avant une réinitialisation. Celle-ci peut supprimer des configurations utiles, interrompre un accès distant ou compliquer un VPN ; privilégiez les actions ciblées et documentées.
Quand le remplacement d’un équipement devient-il justifié ?
Lorsqu’une comparaison reproductible l’isole : erreurs persistantes sur un port précis, panne suivant un adaptateur, ou disparition durable du problème avec un élément équivalent connu comme fonctionnel. Le remplacement repose alors sur des preuves plutôt que sur le seul ressenti.