Pourquoi un proxy mobile rame le soir alors que le test de débit affiche le maximum

Nous avons collecté 5964 mesures sur des réseaux mobiles et observé le comportement du canal heure par heure. Résultat : le chiffre sur lequel tout le monde se base pour choisir un proxy grimpe justement au moment où la connexion devient la pire.

Pourquoi les mégabits ne décrivent pas du tout la qualité d'un canal, nous l'avons expliqué dans l'article « Les Mbit/s ne disent rien sur la qualité d'un proxy mobile ». Ici, même idée, mais avec des données concrètes : comment la latence, le jitter et les pertes évoluent selon l'heure.

Un scénario familier

Vous prenez un proxy plus rapide, mais l'antidetect vous déconnecte quand même, le scraper attrape des timeouts, les téléchargements se coupent en plein milieu. Vous lancez un test de débit : 40 mégabits, tout va bien. Le vendeur hausse les épaules : le canal est normal, regardez vous-même.

Le canal est effectivement normal — selon la mesure que vous avez effectuée. Le problème, c'est que vous avez mesuré la mauvaise chose.

Ce qui casse vraiment le travail

La bande passante ne sert qu'à une seule chose : déterminer à quelle vitesse un gros fichier se télécharge. Tout le reste — ouverture de pages, maintien des sessions, réponses aux captchas, requêtes longues de scraper — dépend d'autres paramètres.

Un réseau mobile ne se distingue pas d'une connexion filaire par sa lenteur. Il est instable : la cellule se sature le soir, l'opérateur change de bande de fréquence, le shaping s'active selon un planning. Une seule mesure dans un navigateur décrit une seconde sur une journée — et généralement celle pendant laquelle vous avez décidé de vérifier.

Ce que montrent les données

Nous avons compilé des mesures passant par les réseaux MTS sur dix mois, puis calculé les moyennes heure par heure. Trois valeurs sur trois échelles distinctes — volontairement séparées : les superposer sur un même axe reviendrait à forcer le graphique.

De haut en bas : vitesse de téléchargement (Mbit/s), jitter (ms), pertes de paquets (%). 5964 mesures sur les réseaux MTS, septembre 2025 — août 2026. Chaque point est une moyenne par heure, de 72 à 388 mesures par heure. L'intervalle du soir (18h–23h) est surligné en orange ; ×3,4 et ×6,8 indiquent la hausse de la valeur vers la nuit. Les points marquent le minimum et le maximum sur 24 heures.

L'essentiel sur ce graphique

La vitesse ne change presque pas. De sept heures du matin à minuit, elle se maintient entre 54 et 68 Mbit/s. Une personne qui lance un test de débit à n'importe quelle heure de la journée verra à peu près le même chiffre et conclura que la connexion est bonne.

Le jitter, lui, est multiplié par 3,4 sur la même période — de 25 ms à huit heures du matin à 86 ms à onze heures du soir. Les pertes de paquets augmentent de 6,8 fois : de 0,79 % en journée à 5,37 % en fin de nuit.

Et la coïncidence la plus gênante : à 20h, la vitesse atteint son maximum quotidien — 68 Mbit/s — alors que le jitter à la même heure est de 64 ms, soit deux fois et demie la valeur du matin. C'est à ce moment que le test de débit affiche le meilleur résultat de la journée. Et c'est à ce moment que travailler est le plus difficile.

C'est très exactement pour ça que les plaintes du genre « le soir, tout rame, mais le test affiche une vitesse normale » ne sont ni une invention ni un effet placebo. Le test mesure la seule valeur qui ne se dégrade pas le soir.

Comment bien mesurer

Il ne faut pas une mesure unique, mais une série. On installe le CLI, on le lance selon un planning et on accumule dans un fichier :

speedmeter --json | jq -c '{t:.timestamp, d:.download, p:.ping, j:.jitter}' >> proxy.jsonl

Dans cron, toutes les quinze minutes :

*/15 * * * * /usr/local/bin/speedmeter --json >> /var/log/proxy-speed.jsonl

En une journée, on obtient 96 points, et on voit immédiatement si votre canal a un creux le soir. Le binaire est autonome, environ 400 Ko, sans aucune dépendance — il s'installe sur n'importe quel serveur où tourne votre automatisation.

Quelles valeurs sont acceptables

Remarquez ce qui n'apparaît pas dans ce tableau : une colonne avec des mégabits. Pour toutes ces tâches, la bande passante cesse d'être un facteur limitant à partir d'environ dix mégabits.

Données heure par heure

Les mêmes chiffres que sur le graphique — pour que vous puissiez les vérifier ou les comparer avec vos propres mesures.

Précision sur les données

Il s'agit d'une moyenne sur de nombreux utilisateurs et de nombreuses cellules, pas d'une seule carte SIM sous contrôle. Cette vue d'ensemble montre la forme de la courbe quotidienne, mais ne remplace pas la mesure de votre canal spécifique — il faut la faire vous-même, avec le script ci-dessus.

L'outil utilisé pour collecter ces chiffres est ouvert et gratuit : speedmeter.dev. Il mesure le jitter et les pertes côté serveur, sans se fier au rapport du navigateur, et renvoie le résultat en JSON pour les scripts.