NetDiag+
Des preuves que votre opérateur ne peut pas balayer
« Le soir, mon internet est lent » est un ressenti, et le support est formé à répondre aux ressentis par un redémarrage de box. Un chiffre avec un lieu et une heure, c'est une autre conversation : la perte de paquets commence à mon troisième saut chaque soir après vingt-et-une heures, voici les mesures. Trois mesures font ce travail — où commence la perte, comment se comporte la latence sous charge, à quelle distance et à quel point sont instables les serveurs que vous utilisez vraiment — et depuis NetDiag+ 1.4.6, chacune s'exporte en texte brut à coller dans un ticket, un forum ou le formulaire du régulateur.
Trois mesures qui nomment un lieu et une heure
- Localisez la perte avec MTR. Un traceroute qui continue de pinguer chaque saut montre où les paquets commencent à disparaître. Une perte qui débute à un saut et persiste jusqu'au bout est réelle, et ce saut nomme le réseau responsable. Une perte sur un seul saut qui disparaît au suivant, c'est ce routeur qui limite ses propres réponses — normal, pas une preuve. Lancez-le à la mauvaise heure et notez le saut.
- Ajoutez la latence sous charge et le tableau de latence. Un test de bufferbloat dit de combien la latence grimpe quand la ligne est occupée, et dans quel sens : un pic en envoi pointe votre propre box, un pic en réception l'équipement du fournisseur — et c'est ce sens qui décide de qui est le problème. Le Tableau de latence ajoute médiane, jitter et perte vers les serveurs nommés que vous utilisez, en mesurant d'abord votre propre box pour que personne ne puisse accuser votre Wi-Fi s'il est propre.
- Exportez en texte, aux bonnes heures, plus d'une fois. Chaque outil a Partager → rapport texte : cibles, horodatages, chaque chiffre. Une mesure ne prouve rien ; trois à la mauvaise heure sur des jours différents plus une à une heure calme comme témoin, c'est un motif. Le graphique de tendance bufferbloat garde le pire pic de chaque mesure sur 7, 30 ou 90 jours, le motif se voit donc sans prendre de notes. L'historique garde tout ce que vous avez lancé.
Gratuit · 27 outils · achat unique pour retirer la publicité · sans abonnement
Les questions que les gens posent vraiment
Que doit contenir le ticket, concrètement ?
Dates et heures de chaque mesure. Le saut où la perte commence et son pourcentage. Latence au repos contre latence en réception et en envoi. Médiane et jitter vers deux ou trois serveurs que votre foyer utilise. Quel test servait de témoin. Tout collé en texte, pas décrit — un technicien peut agir sur une liste de sauts, pas sur « ça rame ».
Le support dit que la ligne est bonne. Ils mentent ?
En général non. Leurs tests vérifient les niveaux de signal, les compteurs d'erreurs et le débit, et tout cela peut être parfait pendant qu'une file d'attente ajoute 300 ms ou qu'un lien d'interconnexion saturé jette 2% des paquets à 21 h. Vous mesurez quelque chose qu'ils ne mesurent pas. Dites-le, et donnez-leur les chiffres.
Captures d'écran ou texte ?
Texte. On peut le chercher, le citer, le coller dans un outil interne et le transmettre à l'ingénieur qui répare vraiment ; pas une capture. Le texte survit aussi à la compression d'images d'un forum et au formulaire web d'un régulateur. Gardez les captures pour vous.
Combien de mesures pour constituer un dossier ?
Assez pour montrer que le problème est reproductible et lié à l'heure. Trois mesures à la mauvaise heure sur deux ou trois jours, plus une à une bonne heure qui revient propre, c'est le minimum qui transforme une plainte en rapport. Si la mesure à la bonne heure est mauvaise aussi, la cause n'est pas la congestion — c'est utile aussi.
Est-ce que ça fait vraiment réparer quelque chose ?
Ça fait passer le ticket du premier niveau à quelqu'un qui sait lire une liste de sauts, l'étape où ça bloque d'habitude. Là où un régulateur existe, les formulaires de plainte demandent exactement cela : dates, mesures, ce que l'opérateur a répondu. Les preuves ne garantissent pas une réparation ; elles retirent les raisons de dire non.
Le chiffre le plus fort de tout cela, c'est la latence sous charge. Ensuite : quel serveur est loin, et lequel est instable →