Tester la latence du bureau à distance : mesurer l'UX

Vous avez besoin que le contrôle à distance soit réactif — pas lent et imprévisible. Si glisser une fenêtre, taper ou déplacer la souris dans une session distante paraît lent, vous dépannez la latence. Ce guide montre comment exécuter un « remote desktop latency test » pratique qui sépare les problèmes réseau des problèmes d’encodage/rendu et fournit des mesures reproductibles que vous pouvez comparer dans le temps.

Pourquoi mesurer la latence (et à quoi s'attendre)

La latence dans les sessions de bureau à distance est multi-dimensionnelle. Il y a le temps de trajet réseau brut (RTT), le jitter et la perte de paquets, le délai d’encodage/décodage sur l’hôte et le client, et le délai de traitement affichage/entrée sur chaque machine. Tout cela s’additionne pour former le délai qu’un humain perçoit lorsqu’il tente de cliquer ou de glisser.

Seuils pratiques à utiliser comme règles empiriques :

• < 20 ms RTT: imperceptible dans la plupart des cas (excellent pour le travail interactif).
• 20–60 ms RTT: très utilisable pour la plupart des travaux à distance (délai mineur seulement lors de mouvements rapides du pointeur).
• 60–150 ms RTT: acceptable mais perceptible; certaines tâches (dessin, jeu) en pâtiront.
• > 150–200 ms RTT: clairement perceptible, inadapté pour des tâches d’interface nécessitant de la précision.

Ce sont des fourchettes approximatives — la latence perçue réelle dépend du pipeline d’encodage du logiciel distant. Les solutions propriétaires (TeamViewer, AnyDesk) utilisent souvent des codecs personnalisés et de la prédiction pour réduire la latence perçue ; les logiciels open-source/auto‑hébergés (Tenvo, RustDesk) peuvent se comporter différemment selon la configuration. Si vous souhaitez un déploiement auto‑hébergé, consultez notre guide d’auto‑hébergement pour les notes de déploiement.

Aperçu : deux tests complémentaires à exécuter

Effectuez ces deux tests successivement. Ils isolent la latence réseau de la latence perçue bout à bout par l’utilisateur.

1. Repères au niveau réseau: ping, traceroute/MTR et iperf3 pour débit/jitter/perte de paquets.
2. Mesure bout à bout entrée→affichage: méthode de benchmark visuel utilisant un carré clignotant et une caméra haute fréquence d’images ou des images horodatées.

Étape 1 — Mesures au niveau réseau (rapide et objectives)

Commencez par mesurer le chemin réseau entre le client et l’hôte. Cela ne dit pas tout, mais élimine rapidement les problèmes réseau évidents.

Outils nécessaires

• ping (intégré sur Windows/macOS/Linux)
• traceroute ou MTR (mtr sur Linux/macOS; WinMTR sur Windows)
• iperf3 (installation via le gestionnaire de paquets; utilisé couramment pour débit, jitter et perte de paquets)

Commandes de base et valeurs attendues

Remplacez host.example.com ou 198.51.100.10 par l’IP/le nom de votre hôte distant.

ping -c 20 host.example.com
# On Windows: ping -n 20 host.example.com

Regardez le min/avg/max RTT et la perte de paquets. Sur le même LAN vous devriez voir <1 ms min/avg ; sur une connexion domestique vers un serveur régional 10–40 ms est courant ; les liaisons transcontinentales se situent souvent entre 80 et 200 ms.

mtr -c 100 host.example.com
# Windows: use WinMTR with default 100 cycles

MTR vous donne la perte de paquets par saut, ce qui est utile pour repérer un lien congestionné ou un problème d’ISP.

Mesurer le jitter et la perte avec iperf3 (UDP)

Démarrez un serveur iperf3 sur l’hôte :

iperf3 -s

Depuis le client, lancez un test UDP ajusté au débit que vous attendez pour votre session distante. Les flux de bureau à distance typiques sont de 1–10 Mbps selon la résolution et la fréquence d’images ; choisissez 5M comme test réaliste :

iperf3 -c host.example.com -u -b 5M -t 30

iperf3 rapportera la perte de paquets et le jitter. Si vous voyez >1% de perte de paquets ou un jitter supérieur à ~10 ms, cela affectera significativement certains codecs de bureau à distance.

Simuler des réseaux dégradés

Si vous souhaitez tester le comportement de votre logiciel distant sous délai, jitter ou perte de paquets, utilisez netem sous Linux pour ajouter des altérations sur le client ou l’hôte :

sudo tc qdisc add dev eth0 root netem delay 100ms 20ms loss 1%

Cette commande ajoute 100 ms de délai avec un écart‑type de 20 ms et 1% de perte de paquets. Pour supprimer les règles :

sudo tc qdisc del dev eth0 root netem

Étape 2 — Latence bout à bout entrée→affichage (latence perçue par l’utilisateur)

Les chiffres réseau ne correspondent pas toujours à la latence perçue. Une pile logicielle qui met en tampon les images, utilise un encodeur logiciel lent ou attend le V‑sync peut ajouter des dizaines voire des centaines de millisecondes. Utilisez cette méthode pour mesurer la vraie latence entrée→affichage de façon mesurable.

Méthode A — Caméra haute fréquence d’images (la plus fiable, matériel requis)

Vue d’ensemble : lancez une petite page web sur l’hôte qui bascule un carré visible quand vous appuyez sur une touche ; connectez-vous avec le client distant, puis positionnez une caméra 120–240 ips (ou un smartphone en mode haute fréquence d’images) pour qu’elle filme à la fois l’écran de l’hôte et la fenêtre du client distant dans le même plan. Comptez les images entre le changement sur l’hôte et le changement sur le client.

Étapes :

1. Sur l’hôte, ouvrez une page simple qui change la couleur d’un grand carré à l’écran chaque fois que vous appuyez sur la barre d’espace. Collez ce HTML dans un fichier local :

<!doctype html>
<html>
<meta charset="utf-8">
<title>Latency Blink Test</title>
<style>body{margin:0;background:#222;color:#fff;font-family:sans-serif}#s{width:300px;height:300px;margin:50px auto;background:#fff}</style>
<script>document.addEventListener('keydown',e =>{if(e.code==='Space'){let s=document.getElementById('s');s.style.background=(s.style.background==='#fff'?'#0f0':'#fff');}});</script>
<body><div id="s"></div>
<p>Press SPACE to toggle the square</p>
</body>
</html>

2. Démarrez une session distante et positionnez à la fois le moniteur physique de l’hôte et la fenêtre du client distant dans le cadre de la caméra afin que celle‑ci voie les deux simultanément (d’où le besoin d’un champ large ou de placer les écrans côte à côte).
3. Enregistrez à haute fréquence d’images (120 ips suffit ; 240 ips est préférable). Appuyez sur SPACE et regardez les images. Ensuite, avancez image par image dans l’enregistrement et comptez combien d’images s’écoulent entre le changement sur l’hôte et sur le client. Latence = nombre d’images / fréquence_caméra.

Exemple : si vous comptez 6 images à 120 ips, latence ≈ 6 / 120 = 0,05 s (50 ms).

Méthode B — Horodatage logiciel (sans caméra, moins précis)

Si vous pouvez exécuter du code à la fois sur l’hôte et sur le client avec des horloges synchronisées (NTP suffit pour une précision d’environ 10 ms), vous pouvez horodater un événement sur l’hôte et demander au client de reporter l’heure d’affichage. Cela nécessite de modifier le client distant ou d’ajouter une surcouche de test, donc c’est plus avancé.

Avantages/inconvénients : la méthode caméra mesure l’ensemble de la chaîne, y compris la persistance d’écran et les erreurs de synchronisation de la caméra, mais reste simple. L’horodatage peut être automatisé mais exige une synchronisation d’horloge serrée (utilisez chrony ou pool.ntp.org) et un moyen de détecter la mise à jour d’image côté client.

Isoler l’origine du délai

Une fois les mesures obtenues, décomposez le problème :

• Si ping/iperf montrent faible RTT/jitter et que votre test bout à bout reste élevé, examinez l’encode/décodeur ou le rendu côté client. Surveillez CPU/GPU sur l’hôte et le client (Task Manager / top / nvidia-smi). CPU élevé ou mise en file d’attente de l’encodage génèrent du lag.
• Si iperf indique une perte de paquets significative ou du jitter, corrigez le réseau. La perte de paquets provoque souvent le blocage des codecs ou la redemande d’images.
• Si le débit est en cause (par ex. le flux vidéo distant utilise continuellement plus de bande passante que votre lien), limitez le débit du bureau distant à un bitrate ou une résolution inférieure et retestez.
• Vérifiez les paramètres du logiciel distant : profondeur de couleur, plafond de fréquence d’images, accélération matérielle (activez NVENC ou VA-API si disponible).

Surveillance des ressources hôte/client

Contrôles typiques :

• Windows : Task Manager > onglets Performance et GPU. Vérifiez si l’encodeur utilise l’encodage matériel H.264/HEVC.
• Linux : top/htop pour le CPU ; nvidia-smi pour inspecter l’utilisation de l’encodeur GPU ; iostat pour les blocages liés au disque.
• macOS : Activity Monitor et vérifiez l’utilisation GPU/encodeur si supportée.

Comparer différents logiciels distants et configurations

Lors des benchmarks, gardez les tests cohérents : même machine hôte, même client, mêmes conditions réseau, même résolution d’écran. Testez chaque version du client et chaque mode de protocole (P2P direct vs serveur relais). Quelques points à tester :

• LAN filaire vs Wi‑Fi vs VPN — le filaire offrira toujours la latence la plus faible.
• Connexion directe vs relais : les relais peuvent ajouter 20–100 ms selon l’emplacement.
• Encodage matériel activé vs encodage logiciel.

Note honnête : des fournisseurs comme AnyDesk et TeamViewer optimisent souvent leurs codecs pour l’interactivité perçue et peuvent surpasser RDP/VNC générique dans des scénarios à forte latence ou faible bande passante. Si vous comparez, exécutez les mêmes tests sur chacun. Nous avons traité des comparaisons plus approfondies dans AnyDesk vs TeamViewer 2026 : fonctions et prix et dans notre article sur Bureau distant sans redirection de ports : explication si vous testez modes relayés vs directs.

Plan de benchmark pratique et notation

Exécutez ce plan pour produire des résultats répétables et comparables :

1. Référence : test LAN filaire — enregistrez ping, iperf3 (5M) et le test de clignotement filmé.
2. Bande passante domestique : client en Wi‑Fi, hôte en filaire — exécutez les mêmes tests.
3. À distance via Internet : client à domicile, hôte en datacenter (ou au travail) — lancez les tests et notez les régions des serveurs relais si utilisés.
4. Test de charge : utilisez netem pour ajouter 100 ms de délai + 2% de perte et relancez pour observer le comportement du logiciel sous altération.

Attribuez un score à chaque exécution sur trois axes (0–10) : santé du réseau (selon iperf/ping), santé de l’encodeur (utilisation CPU/GPU et pertes d’images), et interactivité perçue (latence test caméra). Combinez-les en un score unique si vous avez besoin d’un classement rapide.

Conseils et corrections rapides pour réduire la latence

• Privilégiez l’Ethernet filaire plutôt que le Wi‑Fi. Le Wi‑Fi ajoute de la latence variable et du jitter.
• Activez l’encodage matériel sur l’hôte (NVENC/QuickSync/VA-API) et le décodage matériel sur le client si pris en charge.
• Réduisez la résolution ou la fréquence d’images. 720p@30 offre souvent une meilleure sensation d’interactivité que 1080p@60 sur des liaisons contraintes.
• Utilisez des connexions P2P directes quand c’est possible — les relais ajoutent de la latence.
• Fermez les applications gourmandes en CPU/GPU inutiles sur l’hôte et le client pour éviter la mise en file d’attente de l’encodeur.
• Si vous contrôlez les équipements réseau, priorisez le trafic bureau distant avec QoS pour les sessions critiques.

Consigner les résultats et benchmarks

Enregistrez les métadonnées du test : nom et version du logiciel (par ex., Tenvo v0.9.x, AnyDesk 7.x, TeamViewer 15.x), versions des OS, matériel client et hôte, type de réseau, sortie iperf3 et fréquence d’images caméra. Conservez la vidéo brute de la caméra et le compte d’images pour pouvoir reproduire la mesure ultérieurement. C’est particulièrement utile lors d’évaluations après mises à jour de drivers ou modifications des réglages de codec.

Pour les utilisateurs de Tenvo : notre page de téléchargement à /download liste les builds courants ; si vous testez Tenvo, incluez le build/commit exact. Si vous prévoyez d’auto‑héberger, notre Bureau à distance auto‑hébergé : le guide honnête 2026 explique les détails de déploiement du serveur qui affectent le mode de connexion et la latence.

Conclusion

Un bon « remote desktop latency test » combine des mesures réseau objectives avec un test bout à bout orienté utilisateur. Les outils réseau (ping, traceroute/MTR, iperf3) identifient rapidement les problèmes de connectivité ; le test de clignotement filmé mesure le délai réel entrée→affichage ressenti par les utilisateurs. Utilisez netem pour reproduire des conditions problématiques et surveillez les ressources hôte/client pour trouver les goulets d’étranglement de l’encodeur.

Si vous voulez une base répétable entre différents éditeurs, automatisez les tests réseau avec des scripts et conservez une courte vidéo des tests de clignotement. En comparant plusieurs exécutions, vous verrez quelle part du délai est réseau vs pipeline logiciel — et cela indique la bonne action à mener.

Si vous testez des options auto‑hébergées vs relais hébergés, notre article sur Bureau distant sans redirection de ports : explication aborde plus en profondeur les compromis des relais. Pour les comparaisons fournisseurs (comportement des codecs et compromis tarifaires), consultez AnyDesk vs TeamViewer 2026 : fonctions et prix.

Prêt à lancer des tests sur un client open‑source que vous pouvez auto‑héberger et modifier ? Téléchargez Tenvo à /download et suivez les notes de déploiement dans notre Bureau à distance auto‑hébergé : le guide honnête 2026. Si vous avez besoin d’aide pour interpréter vos résultats de benchmark, collez la sortie iperf3 et votre mesure caméra et nous analyserons ensemble les goulets d’étranglement probables.