Un test de stabilité observe plusieurs réponses successives pour montrer comment une connexion se comporte pendant une courte période. Dans Onde, il envoie des requêtes HTTP vers Cloudflare pendant 30 ou 60 secondes et affiche leur durée sur une courbe. Il complète le test de débit, sans mesurer la puissance Wi-Fi ni la perte de paquets. Son intérêt est de rendre visibles des variations que quelques chiffres finaux peuvent masquer, puis de vous aider à choisir une vérification concrète.
Quand préférer une courbe à un test de débit
Le suivi temporel est particulièrement utile lorsque le problème est décrit comme intermittent. Une page qui fonctionne puis attend, un appel parfois difficile ou une impression de connexion irrégulière ne se résument pas toujours à une faible capacité de transfert. Une courbe apporte un ordre chronologique : vous voyez si les réponses restent proches ou si certains moments se distinguent.
La durée reste limitée. Une minute sans incident n’efface pas une difficulté observée plus tard, et une minute perturbée ne décrit pas automatiquement toute la journée. Choisissez un moment pertinent : celui où le problème se manifeste habituellement, puis un autre moment pour comparer. Notez la pièce et les activités connues du foyer pendant chaque série.
Commencez par une question mesurable. « Les réponses deviennent-elles irrégulières quand ma sauvegarde fonctionne ? » prépare une comparaison utile. « Mon Internet est-il parfait ? » demande une conclusion que ce test ne peut pas donner. Notre guide de préparation des mesures explique comment transformer une impression générale en expérience reproductible.
Ce que le suivi HTTP enregistre
Chaque tentative demande une réponse à une destination distante. Le temps mesuré inclut le fonctionnement du navigateur et de la connexion utilisée pour cet échange. Il ne correspond donc pas nécessairement au délai affiché par un outil système ou par un jeu. La méthode doit rester visible dans les exports et dans toute comparaison avec d’autres résultats.
Les tentatives se succèdent avec un rythme visé d’environ une par seconde. Si une requête prend plus de temps, le nombre de points peut être inférieur à la durée exprimée en secondes. Il ne faut pas inventer des points manquants pour produire une courbe visuellement régulière. Le nombre réel de tentatives fait partie de l’information utile.
Les appels utilisent une destination de mesure Cloudflare, dont la documentation du moteur décrit également les échanges de test. Le suivi spécifique d’Onde utilise sa propre présentation et ses propres limites. Une fonction décrite ailleurs pour un moteur ne doit pas être attribuée automatiquement à ce suivi HTTP.
Choisir 30 ou 60 secondes
Trente secondes permettent une première observation courte. Soixante secondes donnent davantage de contexte lorsqu’une irrégularité semble apparaître de façon moins fréquente. Ce choix n’établit pas un niveau de certification : il définit simplement la fenêtre pendant laquelle vous observez le comportement de la requête utilisée par le test.
Pour une comparaison entre deux emplacements, utilisez la même durée dans les deux séries. Sinon, la série la plus longue a davantage d’occasions de rencontrer un événement rare. Si vous changez la durée volontairement, indiquez-le dans votre commentaire et évitez de comparer seulement le nombre brut d’échecs sans rappeler le nombre de tentatives.
Gardez l’onglet visible. Dans les ajouts préparés pour Onde, masquer l’onglet interrompt le suivi afin de ne pas présenter une observation en arrière-plan comme une série équivalente. Le résultat interrompu est marqué partiel. Relancez un essai complet si vous avez besoin d’une comparaison homogène, au lieu de retirer simplement la mention d’interruption.
Lire la courbe point par point
L’axe horizontal représente le temps écoulé et l’axe vertical la durée des réponses. Une pointe montre une réponse plus lente dans cette série. Les tentatives inabouties sont distinguées visuellement ; elles ne deviennent pas des réponses à zéro milliseconde. Cette séparation évite une courbe faussement rassurante lorsque le test n’a pas obtenu de résultat.
Regardez ensuite la forme générale. Une hausse durable n’appelle pas la même investigation qu’un point isolé. Plusieurs pointes regroupées peuvent correspondre à un événement identifiable, mais la courbe ne révèle pas cet événement toute seule. Notez ce qui se passait dans la pièce ou sur les appareils afin de rapprocher la chronologie du contexte.
Ne comparez pas seulement la hauteur apparente de deux images. Une échelle verticale adaptée automatiquement aux valeurs peut rendre deux courbes visuellement semblables malgré des durées différentes. Lisez les unités et les repères numériques. Conservez les exports lorsque vous voulez établir une comparaison plus précise que l’impression donnée par le dessin.
Comprendre médiane, percentile et échecs
La médiane décrit le centre des réponses disponibles. Le percentile 95 donne un repère situé dans la partie haute de la série. Sur une courte observation, ces valeurs restent sensibles au nombre de points. Elles facilitent la lecture, mais ne remplacent pas les réponses individuelles ni l’examen des tentatives qui n’ont pas abouti.
Les échecs HTTP sont comptés séparément. Ils indiquent que certaines tentatives n’ont pas fourni le résultat attendu dans les limites du test. Ils ne constituent pas un pourcentage de perte de paquets. Pour comprendre cette différence, consultez notre article sur les pertes de paquets et erreurs de requêtes.
Une synthèse doit conserver les valeurs absentes comme absentes. Si aucune réponse valable n’a été obtenue, afficher une médiane égale à zéro serait faux. De même, une série partielle ne doit pas être présentée comme un test complet simplement parce qu’elle contient quelques points utilisables. L’état de la mesure est aussi important que ses nombres.
Comparer deux situations sans brouiller le résultat
Pour examiner un problème local, testez d’abord dans votre emplacement habituel, puis près du routeur avec le même appareil. Si possible, ajoutez une observation câblée. Gardez la destination, la durée et le navigateur. Une différence répétée entre les séries constitue une piste à approfondir, pas une mesure directe de la qualité radio.
Pour examiner les usages simultanés, distinguez une période calme d’une période représentative de votre quotidien. Notez précisément les activités connues. N’utilisez pas plusieurs tests de débit concurrents comme substitut à un usage réel non documenté : vous créeriez une situation difficile à interpréter. Le guide sur la latence sous charge développe cette question.
Dans un exemple fictif, la série calme reste régulière, puis des réponses plus lentes apparaissent pendant une synchronisation. L’hypothèse utile est une association avec cette activité. La prochaine étape consiste à répéter le scénario ou à modifier son horaire, puis à vérifier l’effet, plutôt qu’à conclure immédiatement à un défaut permanent de la ligne.
Exporter et commenter une observation
L’export JSON conserve les points et une synthèse. Ajoutez une note séparée avec l’emplacement, l’appareil, le chemin déclaré et les activités présentes. La date du fichier ne raconte pas toute l’expérience : sans contexte, un technicien devra vous redemander les informations qui permettent d’interpréter la courbe.
Choisissez quelques séries représentatives au lieu d’envoyer un dossier rempli de captures presque identiques. Présentez une observation favorable et une observation défavorable si elles aident à isoler une condition. Gardez les originaux, signalez les interruptions et ne modifiez pas les données pour faire apparaître une différence plus nette qu’elle ne l’était réellement.
Vous pouvez enfin relier le résultat à votre usage : « la courbe devient irrégulière au moment où la voix se dégrade » est une observation à vérifier. « cette courbe prouve que le fournisseur est responsable » dépasse ce que la mesure établit. Une conclusion utile contient toujours le périmètre du test et la prochaine action proposée.
FAQ : comprendre les limites du suivi
Une minute suffit-elle pour déclarer ma connexion stable ?
Elle suffit pour décrire la minute observée, pas pour garantir toute la journée. Si votre problème se produit à certains horaires, répétez le suivi dans ces conditions et à un autre moment. Conservez les dates et le contexte. Plusieurs observations ciblées apportent davantage d’informations qu’une conclusion générale tirée d’un seul passage favorable.
Pourquoi ai-je moins de points que de secondes ?
Les requêtes sont successives. Lorsqu’une tentative prend plus longtemps, elle peut réduire le nombre total d’observations pendant la fenêtre choisie. Le test ne doit pas inventer des points pour remplir le graphique. Regardez la durée réellement observée, le nombre de tentatives et les échecs avant de comparer deux séries.
Puis-je lancer le test de débit en même temps ?
Les ajouts d’Onde empêchent ces deux tests de fonctionner simultanément dans la même page. Cette séparation rend le suivi plus facile à interpréter. Si vous voulez étudier un réseau chargé, définissez un scénario d’usage explicite et documenté. Ne confondez pas une mesure au repos avec une mesure perturbée par un autre test.
Pourquoi le suivi s’arrête-t-il quand je change d’onglet ?
Le parcours conserve une condition visible et indique l’interruption au lieu de présenter une observation en arrière-plan comme équivalente. Revenez sur la page et relancez le test si nécessaire. Le résultat partiel peut rester informatif, mais il doit conserver son état et ne pas être comparé sans précaution à une série complète.
Les points rouges correspondent-ils à des paquets perdus ?
Non. Ils représentent des tentatives HTTP inabouties selon les limites du suivi. La cause n’est pas identifiée par cette seule observation. Gardez ce vocabulaire dans votre compte rendu et utilisez une méthode dédiée si vous avez besoin d’une mesure de perte de paquets vers une destination particulière.