bureau à distance sur internet satellite : réglages pour la latence

Si vous tentez de contrôler une machine distante via Internet satellite, vous connaissez la douleur : des aller‑retour longs et variables et des pertes de paquets occasionnelles transforment une session de bureau à distance fluide en une expérience saccadée et instable. Ce guide — axé sur les scénarios de bureau à distance sur Internet satellite — explique comment mesurer le problème, quels réglages client et réseau ont un impact, et propose des profils pragmatiques pour les liaisons GEO et LEO afin que la session devienne utilisable plutôt qu'inutilisable.

Pourquoi le satellite ajoute autant de friction

Les liaisons satellite introduisent trois problèmes prévisibles et un joker. Prévisibles : temps d'aller‑retour (RTT) élevé, perte de paquets supérieure à celle des liaisons filaires, et débit disponible par flux souvent plus faible. Joker : le jitter — variations soudaines de délai — qui ruine la sensation d'interactivité plus qu'une latence stable.

Chiffres réels à utiliser lors de la planification :

• GEO (géostationnaire) : RTT typique de 500–700 ms (un saut vers le satellite et retour).
• LEO (Starlink, OneWeb) : RTT typique de 20–80 ms, mais avec des rafales de jitter et des pertes ponctuelles selon la congestion et le firmware du terminal.
• Perte de paquets : prévoyez 0,1 %–2 % les bons jours, plus élevée en cas d'atténuation par pluie ou de congestion.

Mesurez avant d'ajuster

Avant de changer codecs et fréquence d'images, mesurez RTT, jitter et perte pour savoir à quel point vous devez agir. Un simple ping est utile mais ne donne que le temps aller‑retour vers un hôte. Pour le bureau à distance, ce qui compte, c'est la latence côté application et l'effet des pertes et des retransmissions.

1. Pinguez une IP publique stable pour obtenir une base RTT et jitter :

   ping -c 50 8.8.8.8

   Surveillez min/avg/max/stddev.
2. Mesurez la perte de paquets avec un test de flux TCP/UDP (iperf3) :

   iperf3 -c iperf.server.address -t 30 -i 5

   Faites les tests TCP et UDP pour observer le comportement des retransmissions.
3. Exécutez un benchmark de latence bureau à distance si possible — voir notre article Test de latence du bureau à distance pour un processus de mesure centré sur l'UX.
4. Si vous avez besoin de latence aller simple, utilisez des horloges synchronisées et des outils comme owamp (rare en configuration ad hoc). Pour la plupart des administrateurs, le RTT et le jitter suffisent pour dimensionner les réglages.

Réglages qui aident vraiment (client et serveur)

Les applications de bureau à distance offrent de nombreux curseurs. Ceux qui changent la réactivité perçue sur des liaisons à forte latence ne sont pas forcément les codecs bas niveau mais l'interaction entre fréquence d'images, plafond de bande passante, lissage des entrées et la façon dont le client gère le retour du pointeur local. Ci‑dessous des changements pratiques ; je donne des valeurs de départ concrètes à ajuster ensuite.

• Réduire la fréquence d'images. Passer de 30–60 fps à 5–15 fps diminue fortement le trafic et réduit le ressenti de saccades sur de la haute latence. Commencez à 10 fps pour GEO, 20–25 fps pour LEO.
• Réduire la résolution. Utilisez 1024×768 ou 1280×720 plutôt que 1920×1080 natif pour le travail interactif. Beaucoup de clients permettent de demander un framebuffer plus petit ; moins de pixels = moins de données.
• Réduire la profondeur de couleur. 16 bits (65k couleurs) suffit généralement pour la productivité ; passez de 24/32 bits quand c'est possible.
• Limiter le bitrate. Calez le bitrate de session à un plafond raisonnable (par ex. 500–1500 kbps pour GEO, 2–4 Mbps pour LEO selon la liaison). Un plafond fixe empêche l'encodeur de saturer le chemin et d'induire de la mise en file d'attente.
• Allonger modérément l'intervalle d'images‑clés. Un intervalle d'images‑clés plus long réduit la charge de l'encodeur ; essayez 2–4 secondes en point de départ. Des intervalles trop longs pénalisent en cas de perte importante.
• Rendu local du curseur. Laissez le client dessiner le curseur localement pour que le mouvement soit instantané ; évitez la peinture distante du curseur quand c'est possible.
• Prédiction / lissage des entrées. Activez le lissage côté client et la prédiction de mouvement si disponible ; cela réduit la latence perçue sur les clics et glissements en animant localement les mouvements pendant l'attente des mises à jour serveur.
• Désactiver l'audio et la synchronisation du presse‑papier par défaut. L'audio utilise une bande passante continue et nuit à l'interactivité sur les liaisons à haute latence ; activez‑le seulement si nécessaire. La synchronisation du presse‑papier provoque des rafales occasionnelles — désactivez‑la si vous remarquez des blocages.
• Désactiver les animations du bureau, le fond d'écran et la transparence sur la machine distante. Cela génère des mises à jour d'écran supplémentaires pour peu de valeur.
• Privilégier le transport UDP si le client le prend en charge. UDP évite le head‑of‑line blocking présent dans certaines implémentations TCP, mais attention : les sessions UDP peuvent retomber sur TCP/relay selon le NAT et le comportement du relais.
• Ajuster les temporisations de retransmission et de keepalive. Raccourcissez les keepalives TCP pour éviter de longs blocages de session sur des liaisons instables, mais attention à ne pas déclencher de déconnexions intempestives lors de brèves coupures.

Configurations de départ concrètes

Ci‑dessous des points de départ pratiques à coller dans des profils client et à itérer. Les étiquettes supposent le type de liaison ; ajustez à la hausse ou à la baisse selon le jitter et la perte mesurés.

• GEO (RTT 500–700 ms) : Résolution 1024×768, 8–10 fps, 16‑bit couleur, bitrate 400–800 kbps, intervalle d'images‑clés 3–4 s, audio désactivé, curseur local activé. Utilisez UDP si disponible avec pacing des paquets et un petit tampon de réception pour limiter la mise en file d'attente.
• LEO (RTT 20–80 ms) : Résolution 1280×720, 20 fps, 24‑bit couleur, bitrate 1,5–4 Mbps, intervalle d'images‑clés 2 s, audio optionnel à 64–96 kbps. Lissage des entrées activé. Surveillez les pics de jitter ; si présents, réduisez le fps à 15.
• Hotspot mobile / liaison congestionnée : Résolution 800×600, 5–8 fps, 16‑bit couleur, bitrate 300–700 kbps, audio désactivé, presse‑papier désactivé. Attendez‑vous à des sauts de trame ; utilisez la synchronisation de fichiers plutôt que le copier/coller pour les gros fichiers.

Astuces au niveau réseau qui aident

Certaines modifications relèvent de la pile réseau plutôt que du client. Elles nécessitent l'accès à la passerelle ou au routeur et font souvent la différence entre « à peine utilisable » et « utilisable ».

• Activer QoS / traffic‑shaping. Priorisez le trafic de bureau à distance par rapport aux transferts volumineux. Sur des terminaux grand public vous n'aurez peut‑être que la priorisation par application ; sur des réseaux managés utilisez DSCP et des disciplines de file d'attente (fq_codel ou fq) pour éviter le bufferbloat.
• Limiter MTU avec précaution. PPPoE satellite ou les encapsulations peuvent réduire la MTU effective ; la fragmentation nuit aux performances. Réduisez la MTU seulement si vous constatez des problèmes de fragmentation.
• Utiliser des petits tampons TCP de réception si vous rencontrez du bufferbloat. De grands tampons combinés à un RTT élevé causent de longs délais de mise en file sous charge ; fq_codel à l'egress corrige beaucoup de scénarios.
• Considérer la correction d'erreur en avant (FEC) pour les profils avec forte perte. Si votre client ou passerelle supporte la FEC, elle peut masquer de courtes rafales de pertes sans retransmission. La FEC coûte de la bande passante mais réduit la distortion visible.

Tactiques opérationnelles : composer avec la latence, pas lutter contre

Certaines méthodes de travail sont mal adaptées au bureau à distance sur satellite. Plutôt que de forcer un flux temps réel, changez votre façon de travailler.

• Utilisez des éditeurs locaux et un service de synchronisation (rsync, cloud drive) pour les grosses modifications de fichiers. Ouvrez le fichier localement plutôt que d'éditer via l'interface distante quand c'est possible.
• Regroupez les actions GUI. Si vous devez exécuter une séquence de clics, script‑ez‑la ou utilisez une automation légère sur la machine distante qui s'exécute avec moins d'aller‑retour.
• Privilégiez le terminal/SSH pour les opérations textuelles. Un TTY SSH utilise très peu de bande passante et est bien plus réactif qu'une session GUI à forte latence.
• Planifiez les transferts lourds (sauvegardes, gros téléchargements) en dehors des heures de pointe pour qu'ils ne concurrencent pas les sessions interactives.

Par défaut recommandé par Tenvo : relais géré (et compromis)

Nous recommandons le relais géré de Tenvo comme option par défaut pour les scénarios satellite à moins que vous ayez une exigence écrite d'auto‑hébergement. Tenvo fournit des clients natifs pour Windows, macOS et Linux ainsi qu'un client navigateur en bêta publique, et notre relais géré multi‑régions réduit les sauts supplémentaires en terminant les sessions de relais dans une région edge proche. Les paliers de tarification Tenvo sont Free $0 / Lite $2.99/mo / Pro $7.99/mo.

Soyez clair sur ce que fait le relais géré : le relais termine TLS avec des certificats par appareil, donc quand le trafic retombe sur le relais TLS s'arrête là et l'opérateur du relais est en mesure d'inspecter les charges utiles de session. Cela a de l'importance pour la conformité et le modèle de menace — choisissez l'auto‑hébergement seulement lorsqu'une politique écrite exige l'absence d'infrastructure tierce, lorsque le réseau est isolé, ou lorsque vous devez contrôler la garde des certificats/clefs et la topologie de basculement vous‑même. Pour la plupart des équipes, le relais géré coûte moins cher une fois que vous incluez l'astreinte, le patching, le renouvellement des certificats et le risque de basculement en région unique.

Quand auto‑héberger

N'exécutez votre propre relais que si l'une des conditions suivantes est vraie : une règle de conformité interdit les relais tiers, les machines cibles sont sur un réseau isolé sans Internet sortant, ou vous avez besoin du contrôle complet des logs et de la garde des clefs. L'auto‑hébergement implique une charge opérationnelle : vous devez provisionner un basculement multi‑régions, maintenir le logiciel à jour, faire tourner les certificats et assurer l'équipe de réponse aux incidents. Si vous pensez que l'auto‑hébergement est la bonne option, notre Bureau à distance auto‑hébergé : le guide honnête de 2026 détaille les vrais compromis.

Checklist de dépannage pour sessions satellite instables

1. Reproduisez le problème et mesurez RTT/jitter/perte autour du moment où le problème survient.
2. Basculez sur un profil basse‑bande (résolution basse, 8–10 fps) et voyez si l'UX s'améliore — cela isole les problèmes de bande passante vs latence.
3. Vérifiez la présence de bufferbloat sur le uplink avec un Speedtest rapide ou un test dédié de bufferbloat. Si du bufferbloat est présent, activez fq_codel ou limitez l'AQM sur la passerelle.
4. Désactivez temporairement audio/presse‑papier/synchro de fichiers pour voir si des rafales en sont la cause.
5. Si le client supporte TCP et UDP, testez les deux et notez les différences ; UDP est souvent plus fluide mais peut être bloqué ou limité par le fournisseur.

Lectures complémentaires et guides associés

Si votre problème est le faible débit plutôt que la latence, lisez notre Bureau à distance — faible bande passante : guide d'optimisation. Pour les calculs derrière les choix de bande passante et comment réduire l'utilisation, voyez Bande passante du bureau à distance : les maths et comment la réduire. Et si vous devez benchmarker les changements effectués, revisitez Test de latence du bureau à distance : comment mesurer et benchmarker l'UX.

Notes finales — attentes et acceptation

Aucun réglage ne fera ressentir une liaison GEO comme un LAN. L'objectif pragmatique est une interactivité prévisible et acceptable pour les tâches dont vous avez réellement besoin. Privilégiez les workflows qui réduisent les aller‑retour (outils locaux, automation, synchronisation) et configurez votre client pour réduire le nombre de pixels et d'images envoyés. Commencez par les profils concrets ci‑dessous, mesurez, puis itérez.

Vous voulez essayer des réglages rapidement ? Téléchargez le client natif Tenvo ou testez la bêta navigateur et utilisez les profils intégrés comme point de départ. Récupérez le client sur Télécharger Tenvo.