Découvrez comment mesurer la vitesse de connexion de votre VPS vers votre broker grâce à de simples tests ping et commandes pour optimiser l'exécution.
- Tester la latence de votre VPS vers votre broker exige de mesurer la latence réseau directement depuis le VPS, et non depuis votre ordinateur personnel, à l'aide d'outils tels qu'ICMP ping, Psping pour les tests de ports TCP, tracert/pathping pour l'analyse des sauts intermédiaires et WinMTR pour une surveillance prolongée
- Une mesure précise de la latence est indispensable à l'exécution de stratégies automatisées sur un Forex VPS, afin de limiter le slippage et d'optimiser vos résultats en trading
- Effectuez vos tests de latence pendant les heures d'ouverture habituelles de votre broker, lorsque l'activité du marché bat son plein. Réaliser ces tests durant les périodes de pointe garantit des résultats représentatifs des conditions réelles de trading.
La valeur de latence affichée dans MetaTrader 4 ou MetaTrader 5 ne reflète pas le temps d'aller-retour (RTT) réel vers votre broker. MT4 et MT5 sont des plateformes de trading, pas des outils de mesure réseau. Le chiffre indiqué en bas à droite du terminal n'est qu'une estimation issue de la couche application, qui sous-estime ou traduit souvent mal le temps d'aller-retour réel vers le serveur d'exécution du broker.
Pour faire les bons choix d'infrastructure, vous devez mesurer la latence au niveau de la couche réseau, directement depuis le VPS, en interrogeant le port approprié. Un ping lancé depuis votre ordinateur personnel vers le nom d'hôte d'un broker ne vous renseignera absolument pas sur les conditions réelles d'exécution de votre Expert Advisor.
Ce guide présente quatre méthodes distinctes :
- Le ping ICMP
- Le test de port TCP avec Psping
- L'analyse du routage saut par saut avec tracert et pathping
- La surveillance continue avec WinMTR
Chacune de ces méthodes répond à un objectif de diagnostic précis. Il est recommandé de les combiner toutes les quatre avant d'arrêter le choix de l'emplacement de votre VPS ou du serveur de votre broker.
Que faut-il préparer avant de tester la latence ?
Avant de lancer le moindre test, vous devez réunir trois informations essentielles. Sans elles, vous risquez de cibler le mauvais hôte, le mauvais port ou le mauvais chemin d'acheminement.
1. Le nom d'hôte ou l'adresse IP du serveur de trading de votre broker
Il ne s'agit pas du site vitrine du broker, mais bien du serveur d'exécution physique auquel votre instance de plateforme de trading se connecte. Vous pouvez l'obtenir de deux façons :
- Dans MT4/MT5 : rendez-vous dans Fichier > Ouvrir un compte > visualisez l'adresse du serveur indiquée dans la fenêtre de connexion. Exemple : ICMarketsEU-MT5-Live01.gbm.network
- Dans cTrader : rendez-vous dans Paramètres > Connexion > champ Adresse du serveur
N'utilisez pas le nom de domaine principal du site du broker pour évaluer votre latence. Les plateformes de trading communiquent avec des serveurs d'exécution dédiés, souvent situés dans des centres de données distincts de ceux hébergeant le site marketing.
2. Le port TCP utilisé par votre broker
La plupart des brokers Forex grand public exploitent l'une de ces trois configurations de ports :
- Port 443 (HTTPS/TLS) : la configuration par défaut la plus courante pour MT4 et MT5 en 2025–2026
- Port 1950 : un standard historique de MetaQuotes encore utilisé par certains brokers sur MT4
- Port 443 : également très fréquent sur cTrader et NinjaTrader
Si vous ne connaissez pas le port de votre broker, consultez sa documentation technique ou contactez son assistance. Le choix du port est déterminant : les pare-feu des brokers bloquent fréquemment le protocole ICMP (ping classique) tout en autorisant les flux TCP sur le port de trading.
D'après la documentation de Cloudflare sur le protocole ICMP, les requêtes ICMP Echo sont fréquemment rejetées par les pare-feu des infrastructures financières par mesure élémentaire de sécurité. Un test basé sur le protocole TCP s'avère donc indispensable pour mesurer avec exactitude la latence vers les serveurs des brokers.
3. Une session Bureau à distance active sur le VPS
L'ensemble des tests doit être impérativement exécuté depuis le VPS via la Connexion Bureau à distance (RDP), et jamais depuis votre ordinateur local. C'est sur le VPS que tourne votre Expert Advisor. Seul le routage entre le VPS et le broker détermine la réactivité et la qualité de vos exécutions.
Quelles sont les quatre méthodes pour tester la latence entre votre VPS et votre broker ?
Méthode 1 : mesurer le RTT de base vers votre broker avec le ping ICMP
Le ping ICMP offre le moyen le plus rapide d'obtenir une valeur de référence pour le temps d'aller-retour et de repérer les coupures de connectivité flagrantes. Utilisez-le comme première étape de contrôle. Si la requête expire, cela ne signifie pas que le broker est inaccessible, mais simplement que le trafic ICMP est filtré, ce qui est très fréquent sur les pare-feu des infrastructures financières. Passez alors directement à la méthode 2 (Psping).
Quand l'utiliser : pour une première estimation rapide et pour vous assurer que le nom d'hôte de votre broker répond correctement.
Comment exécuter un ping ICMP depuis un VPS Windows
Ouvrez l'Invite de commandes sur le VPS (raccourci Windows + R, saisissez cmd, puis validez avec Entrée).
Ping continu classique (Ctrl+C pour l'interrompre) :
ping -t BROKER_HOSTNAME_OR_IPExemple :
ping -t ICMarketsEU-MT5-Live01.gbm.networkPing prolongé sur échantillon défini (200 paquets pour plus de fiabilité statistique) :
ping -n 200 BROKER_HOSTNAME_OR_IPComment interpréter les résultats d'un ping ICMP
| Indicateur | Signification |
|---|---|
| RTT moyen (ms) | Temps d'aller-retour moyen sur l'ensemble des pings aboutis. Principal indicateur de latence. |
| Écart Min / Max | Un écart resserré (ex. 2 ms min / 4 ms max) témoigne d'une liaison stable. Un écart important (ex. 2 ms min / 180 ms max) signale une instabilité de routage ou une congestion réseau. |
| Paquets perdus (%) | Tout taux supérieur à 0 % doit vous alerter immédiatement. Consultez la méthode 4 (WinMTR) pour une analyse détaillée. |
| Délai d'attente de la demande dépassé | Le pare-feu du broker bloque les paquets ICMP. Passez sans attendre à la méthode 2 (Psping sur le port TCP). |
Limites du ping ICMP pour l'analyse de latence broker
Le ping ICMP emprunte un chemin réseau différent de celui de votre plateforme de trading. Cette dernière communique via une connexion TCP sur un port dédié. Les infrastructures des brokers sont bien souvent configurées pour déprioriser ou bloquer les réponses ICMP, tout en traitant normalement les flux de trading TCP. Un délai dépassé ne signifie donc pas que votre exécution est lente : il indique simplement que le pare-feu rejette ce protocole de diagnostic. Privilégiez la méthode 2 pour obtenir une mesure fidèle aux conditions réelles de production.
Méthode 2 : tester la latence du port TCP vers votre broker avec Psping
Psping s'impose comme l'outil de référence pour évaluer la latence sur un Forex VPS. Il mesure le temps d'aller-retour TCP sur le port précis utilisé par votre plateforme de trading, contournant ainsi le blocage de l'ICMP tout en fournissant un échantillonnage statistiquement fiable. Vous pouvez télécharger gratuitement cet utilitaire signé par Microsoft sur la page Sysinternals : learn.microsoft.com/en-us/sysinternals/downloads/psping.
Quand l'utiliser : pour mesurer avec précision et robustesse la latence TCP sur le port de trading de production. C'est la méthode à privilégier pour choisir l'emplacement de votre VPS et le serveur de votre broker.
Installation et configuration
- Téléchargez la suite Sysinternals (ou Psping seul) depuis la page Microsoft Sysinternals : learn.microsoft.com/en-us/sysinternals/downloads/psping
- Décompressez le fichier psping.exe dans un dossier permanent, par exemple C:\Tools\psping.exe
- Acceptez le contrat de licence lors du premier lancement : psping.exe -accepteula
Commandes Psping essentielles pour tester la latence vers un broker
Test de latence TCP standard (échantillon de 100 paquets, protocole IPv4 forcé) :
psping.exe -4 -n 100 BROKERIP:PORTExemple :
psping.exe -4 -n 100 198.51.100.45:443Test de latence TCP continu avec intervalle (actif jusqu'à l'interruption par Ctrl+C) :
psping.exe -4 -t BROKERIP:PORTTest étendu sur 500 paquets pour une analyse statistique approfondie :
psping.exe -4 -n 500 -i 0.1 BROKERIP:PORTEnregistrer les résultats dans un fichier texte pour les examiner ultérieurement :
psping.exe -4 -n 200 BROKERIP:PORT > C:\latency_test_results.txtDétail des paramètres :
- -4 — Force l'utilisation d'IPv4 pour éviter les déviations de routage propres à IPv6
- -n 100 — Envoie un volume de 100 paquets de test
- -t — Maintient l'envoi en boucle jusqu'à l'interruption manuelle par Ctrl+C
- -i 0.1 — Transmet un paquet toutes les 100 millisecondes (soit 10 paquets par seconde)
Principaux indicateurs fournis par Psping
| Résultat Psping | Impact sur l'exécution auprès du broker |
|---|---|
| RTT moyen | Temps d'aller-retour TCP moyen sur la totalité des paquets testés. Baromètre clé des performances. |
| RTT minimum | Meilleur temps de réponse possible avec le routage actuel ; il correspond au plancher physique de votre latence. |
| RTT maximum | Pire délai enregistré sur un seul paquet. Un RTT max élevé traduit des pics de latence susceptibles de dégrader vos ordres en période de forte volatilité. |
| Écart-type | Un écart-type faible (< 1 ms sur une infrastructure performante) atteste d'une exécution très stable. Un écart-type important révèle une route instable. |
| Paquets reçus (%) | Tout résultat sous les 100 % indique des pertes de connexion TCP sur le port de production, ce qui met directement en péril la qualité d'exécution de vos ordres. |
Méthode 3 : comment utiliser tracert et pathping pour décomposer la latence saut par saut ?
Tracert (traceroute) et pathping mettent en évidence le saut réseau intermédiaire qui génère le plus de latence entre votre VPS et le broker. Ces solutions servent au diagnostic plutôt qu'au contrôle opérationnel quotidien. Utilisez tracert et pathping lorsque Psping renvoie un RTT anormalement haut et que vous cherchez à identifier le tronçon responsable de cet engorgement. Vous trouverez des informations détaillées sur ces outils dans la documentation officielle de Microsoft sur les commandes Windows : tracert et pathping.
Quand l'utiliser : lorsque Psping affiche une latence anormale et que vous devez localiser précisément le saut qui pose problème. Ces outils sont également très pratiques pour comparer plusieurs hébergeurs VPS afin de vérifier l'acheminement physique vers le centre de données du broker.
Commandes Tracert
Tracert standard (limité à 30 sauts) :
tracert BROKER_HOSTNAME_OR_IPTracert étendu avec seuil de sauts plus large et IPv4 forcé :
tracert -4 -h 50 BROKER_HOSTNAME_OR_IPParamètres :
- -h 50 — Autorise jusqu'à 50 sauts intermédiaires (le réglage par défaut étant de 30)
- -4 — Force l'usage d'IPv4
Pathping pour croiser cartographie du réseau et pertes de paquets
Pathping associe le tracé des nœuds réseau façon tracert à des statistiques détaillées de perte de paquets calculées sur la durée. En envoyant 100 paquets vers chaque routeur traversé, il permet d'isoler la source exacte des pertes de manière bien plus fine que tracert :
pathping -4 BROKER_HOSTNAME_OR_IP
Pathping opère en deux temps : il répertorie d'abord le chemin complet (comme tracert), puis transmet 100 paquets d'évaluation à chaque équipement pour calculer le taux de perte correspondant. L'exécution complète prend généralement quelques minutes.
Comment interpréter les données d'un tracé Tracert
| Comportement observé sur Tracert | Ce que cela indique |
|---|---|
| Faible latence continue jusqu'à un routeur précis, puis bond soudain | Le saut suivant le palier introduit une latence majeure ; il s'agit la plupart du temps d'une liaison de transit saturée ou de la traversée d'une dorsale longue distance (ex. câble sous-marin transatlantique) |
| * * * (délai d'attente dépassé) sur un saut intermédiaire | Le routeur en question est configuré pour ne pas renvoyer de réponses aux sondes tracert. Ce comportement est tout à fait habituel sur de nombreux réseaux de transit et n'indique aucune anomalie. |
| * * * sur le tout dernier saut (serveur du broker) | Le pare-feu du broker bloque le protocole ICMP. Le routage fonctionne parfaitement, mais la machine finale ne répond pas aux paquets de test. Fiez-vous aux mesures de Psping pour connaître le RTT effectif. |
| RTT important sur un nœud intermédiaire, mais stable sur le saut d'après | Ce routeur relègue simplement les paquets ICMP au second plan (comportement standard). Cela ne traduit en rien un goulet d'étranglement réel. Basez-vous plutôt sur les relevés de Psping. |
Méthode 4 : comment utiliser WinMTR pour surveiller en continu la latence entre le VPS et le broker ?
WinMTR assure une observation dynamique et mise à jour en temps réel de la latence ainsi que des pertes de paquets sur chaque saut d'un tracé. Il s'agit de l'outil le plus abouti sous Windows VPS pour ausculter une liaison réseau sur la durée. Vous pouvez vous le procurer sur le dépôt GitHub officiel : github.com/White-Tiger/WinMTR. Ne nécessitant aucune installation, il s'exécute directement et constitue l'équivalent sous Windows de la commande mtr bien connue sous Linux.
Quand l'utiliser : pour suivre la latence et les pertes de paquets sur une période conséquente (plus de 30 minutes), particulièrement au cours des sessions de marché actives. WinMTR reste la solution idéale pour repérer des pertes de paquets intermittentes qu'un bref test Psping laisserait passer inaperçues.
Installation et paramétrage
- Téléchargez WinMTR sur github.com/White-Tiger/WinMTR
- Décompressez l'archive et lancez WinMTR.exe — aucune installation n'est requise
- Dans le champ Host, entrez le nom d'hôte ou l'adresse IP de votre broker
- Ajustez l'intervalle sur 100 ms (soit 10 paquets émis par seconde) pour des mesures en conditions de marché réelles
- Cliquez sur Start et laissez tourner l'outil pendant au moins 30 minutes lors d'une session de trading active
Indicateurs clés de WinMTR
| Indicateur | Valeur habituelle | Interprétation / Action |
|---|---|---|
| Last | < 5 ms (en colocalisation) | RTT relevé sur le dernier paquet envoyé |
| Avg | < 5 ms (en colocalisation) | RTT moyen sur l'ensemble de la session, indicateur central de performance |
| Best | < 1 ms (en colocalisation) | Temps d'aller-retour le plus rapide, qui définit votre plancher physique |
| Worst | < 10 ms idéalement | Des valeurs Worst élevées traduisent des hausses brutales de latence en cas de congestion |
| Loss % | 0 % | Toute perte supérieure à 0 % exige un diagnostic immédiat |
| Sent | Incrémentation constante | Permet de vérifier que WinMTR diffuse ses paquets de test en continu |
Exporter les rapports WinMTR
Cliquez sur Export to TEXT pour enregistrer l'intégralité du tableau de données saut par saut. Si vous devez signaler un souci d'acheminement à votre fournisseur de VPS, pensez à joindre systématiquement cet export WinMTR en précisant le créneau horaire exact du test, le nom d'hôte du serveur testé et la session de trading durant laquelle le dysfonctionnement s'est produit.
Quelle est la latence acceptable entre un VPS et un broker selon votre style de trading ?
Les exigences de temps de réponse varient grandement en fonction de votre méthode de trading.
| Stratégie de trading | Latence acceptable (RTT moyen Psping) | Objectif visé |
|---|---|---|
| EA de scalping (objectifs de 2 à 5 pips, 100+ trades/jour) | < 5 ms | < 1 ms (au sein du même campus Equinix) |
| Robots de news trading (déclenchements à la microseconde) | < 10 ms | < 3 ms |
| Bots de trading en grille à haute fréquence | < 5 ms | < 2 ms |
| Stratégies standard avec EA (journalières ou intraday) | < 20 ms | < 10 ms (même ville ou région proche) |
| EA de swing trading (positions conservées d'un jour sur l'autre) | < 50 ms | < 20 ms |
| Trading de position (sur plusieurs jours ou semaines) | < 100 ms | Non critique |
L'InfoBrief d'IDC commandé par Equinix confirme que la proximité physique avec les infrastructures d'exécution constitue le facteur prédominant de la latence sur les réseaux financiers. Un VPS hébergé à Equinix NY4, aux côtés d'un broker dont le moteur d'appariement se trouve sur le même campus, affiche régulièrement une latence sous la barre de la milliseconde. À l'inverse, un VPS situé dans un centre de données généraliste de l'est des États-Unis, à seulement 80 km du broker, peut subir 20 à 80 ms de latence, quelle que soit la puissance brute de son matériel.
Comment interpréter vos résultats de test de latence
Après avoir appliqué ces quatre méthodes d'évaluation, reportez-vous à la grille de référence ci-dessous pour juger de la qualité de connexion entre votre VPS et votre broker :
| RTT moyen sous Psping | Diagnostic | Recommandation |
|---|---|---|
| < 1 ms | Excellent : colocalisation directe ou interconnexion physique (cross-connect) dans le même campus Equinix | Optimal. Aucun ajustement d'infrastructure n'est requis. |
| 1–5 ms | Bon : même pôle financier, routage de proximité immédiate | Parfaitement adapté à la grande majorité des stratégies de scalping et de trading haute fréquence (HFT). |
| 5–20 ms | Acceptable : même zone géographique, mais centres de données distincts | Suffisant pour la plupart des stratégies standard basées sur des EA. Privilégiez un VPS plus proche si vous pratiquez le scalping. |
| 20–50 ms | Moyen : éloignement de routage notable par rapport au broker | Vérifiez l'emplacement de votre VPS face aux infrastructures de votre broker. Examinez d'autres emplacements disponibles chez ForexVPS.net. |
| > 50 ms | Insuffisant : le VPS se trouve trop loin du moteur d'appariement du broker | Modifiez l'emplacement de votre VPS. Dépasser les 50 ms provoque un slippage mesurable à chaque ordre sensible au facteur temps. |
Pour les clients ForexVPS.net, pensez à consulter notre outil de latence des brokers afin d'identifier, parmi nos 22 implantations à travers le monde, celle qui procure le meilleur temps de réponse pour votre broker avant même de déployer votre serveur.
Foire aux questions sur les tests de latence entre votre VPS et votre broker
Retrouvez ci-dessous les réponses aux interrogations les plus fréquentes concernant l'évaluation de la latence entre votre VPS et votre broker :
Pourquoi la commande ping échoue-t-elle alors que MetaTrader est bien connecté ?
Les pare-feu des brokers rejettent très souvent les requêtes ICMP Echo (ping) à des fins de sécurité, même quand votre plateforme de trading fonctionne normalement. Cette dernière s'appuie en effet sur une liaison TCP établie sur un port dédié (habituellement 443 ou 1950), et non sur le protocole ICMP. Comme le rappelle la documentation ICMP de Cloudflare, bloquer les requêtes ICMP relève d'une pratique de sécurité élémentaire sur les infrastructures financières. En cas de blocage d'ICMP, utilisez Psping en mode TCP (psping.exe -4 -t BROKERIP:PORT) pour obtenir une mesure fiable.
Faut-il tester la latence depuis son ordinateur personnel ou depuis le VPS ?
Toujours directement depuis le VPS. Un test lancé depuis votre domicile analyse la liaison reliant votre fournisseur d'accès à Internet au broker, ce qui n'a aucun impact sur l'exécution réelle de vos ordres. Votre Expert Advisor est hébergé sur le VPS : seul compte le trajet reliant le centre de données du VPS au serveur d'exécution du broker. Vous pourriez constater 5 ms de latence depuis chez vous alors que le VPS subit 80 ms, et inversement. Comme le souligne la documentation sur les VPS de MetaQuotes, la latence entre le VPS et le broker demeure l'unique métrique déterminante pour l'exécution de vos ordres.
À quelle fréquence convient-il de vérifier la latence VPS-broker ?
Réalisez un contrôle approfondi (Psping associé à WinMTR) au minimum une fois par mois, ainsi qu'après chaque changement d'offre VPS, de serveur chez votre broker ou de paramétrage de plateforme. Testez également la liaison sans attendre si vous remarquez un slippage inhabituel, des rejets d'ordres ou des déconnexions intempestives en cours de séance. La latence peut se dégrader à la suite d'ajustements de routage chez les opérateurs de transit, sur lesquels ni l'hébergeur du VPS ni le broker n'ont de prise directe.
La perte de paquets est-elle plus pénalisante qu'une latence élevée ?
Pour le trading par EA, la réponse est oui. Il est bien plus avantageux d'avoir une faible latence constante assortie d'un taux de perte de paquets de 0 % plutôt qu'une latence moyenne très basse polluée par des pertes résiduelles. D'après les études de Cloudflare sur le sujet, les retransmissions TCP provoquées par la disparition de paquets engendrent des délais équivalant à plusieurs fois le RTT de départ. Un RTT régulier de 15 ms sans aucune perte surpasse systématiquement une moyenne de 5 ms perturbée par 0,1 % de pertes de paquets dès lors qu'un EA exécute des ordres à haute cadence.
