Bureau à distance auto-hébergé : le guide complet 2026 (RustDesk + GoDesk Relay)

Pour la plupart des utilisateurs, le relais hébergé par le fournisseur (TeamViewer, AnyDesk, GoDesk) suffit. Le chiffrement de bout en bout fait que le relais ne voit que du texte chiffré — il ne peut pas lire les images d'écran, les frappes au clavier ou les fichiers. Mais "suffisant" n'est pas "idéal" si vous avez l'une de ces contraintes :

• Conformité : industrie réglementée où les données ne doivent pas transiter par une infrastructure tierce (juridique, défense, certains établissements de santé).
• Souveraineté : vous ne voulez pas que vos métadonnées d'accès à distance (qui s'est connecté à quoi, quand, combien de temps) soient collectées par quiconque.
• Coût à l'échelle : si vous faites transiter 100+ appareils par un relais, les frais fournisseurs s'accumulent — un relais auto-hébergé sur un $5 VPS gère des milliers de sessions.
• Réseaux isolés ou restreints : le relais du fournisseur n'est pas joignable depuis votre environnement.

Si l'une de ces situations vous concerne, ce guide explique comment auto-héberger l'ensemble sur un VPS basique. La pile de référence est le hbbs + hbbr de RustDesk, auxquels les clients GoDesk et RustDesk peuvent se connecter. Temps d'installation total : environ 30 minutes, TLS inclus.

Ce que vous allez construire

Deux services :

• hbbs (serveur de rendez-vous) : gère la poignée de main initiale. Les deux clients s'y connectent brièvement pour se découvrir mutuellement, échanger les clés publiques et déterminer si un P2P direct est possible. Écoute sur TCP/UDP 21115-21117.
• hbbr (serveur relais) : si le P2P direct échoue (NAT, pare-feu), le trafic transite par le relais. Écoute sur TCP 21117 (et UDP dans certains scénarios).

Le relais n'intervient que lorsque le P2P ne fonctionne pas — ce qui est la majorité des scénarios grand public à cause du NAT, mais rare sur un réseau local. Donc même avec un relais auto-hébergé, vous ne payez la bande passante du VPS que pour les sessions qui en ont besoin.

Étape 1 : Choisir un VPS

La ressource principale est la bande passante. CPU et RAM sont minimaux (le relais se contente de transférer des octets). Choix raisonnables en 2026 :

• Hetzner CX22 (€4/mo, 2 vCPU, 4 GB RAM, 20 TB bandwidth, EU data centers) — meilleur ratio prix/bande passante.
• DigitalOcean Basic Droplet ($6/mo, 1 vCPU, 1 GB, 1 TB bandwidth) — bonne ergonomie, régions US/EU.
• OVH VPS Starter (€3.50/mo, 2 vCPU, 2 GB, unmetered bandwidth) — préférable pour les scénarios à fort débit.
• Hetzner Storage Box — PAS un VPS, mentionné car certains lecteurs demandent. Ne conviendra pas ici ; il vous faut un vrai serveur.

Choisissez une région proche des clients qui se connecteront — cela compte pour la latence puisque le trafic relayé est lié au trajet aller-retour.

Étape 2 : Préparer le serveur

Démarrez un VPS Ubuntu 22.04 ou Debian 12 propre. Connectez-vous en SSH en tant que root.

# Update + harden basics
apt update && apt upgrade -y
apt install -y ufw fail2ban docker.io docker-compose-plugin
ufw allow 22/tcp     # SSH
ufw allow 21115:21119/tcp
ufw allow 21115:21119/udp
ufw enable
systemctl enable --now docker

Ne sautez pas la configuration du pare-feu. La configuration par défaut de RustDesk n'expose que les ports nécessaires, mais le reste doit être verrouillé.

Étape 3 : Lancer hbbs + hbbr via Docker

Créez /opt/godesk-relay/docker-compose.yml :

services:
  hbbs:
    image: rustdesk/rustdesk-server:latest
    container_name: hbbs
    restart: unless-stopped
    ports:
      - "21115:21115/tcp"
      - "21116:21116/tcp"
      - "21116:21116/udp"
      - "21118:21118/tcp"
    command: hbbs -r your-server.example.com:21117
    volumes:
      - ./data:/root
  hbbr:
    image: rustdesk/rustdesk-server:latest
    container_name: hbbr
    restart: unless-stopped
    ports:
      - "21117:21117/tcp"
      - "21119:21119/tcp"
    command: hbbr
    volumes:
      - ./data:/root

Remplacez your-server.example.com par le nom d'hôte réel. Démarrez :

cd /opt/godesk-relay
mkdir -p data
docker compose up -d
docker compose logs --tail 20

Vous devriez voir hbbs afficher une clé publique au premier démarrage — sauvegardez-la depuis les logs (id_ed25519.pub dans le volume data) car les clients l'utilisent pour vérifier qu'ils se connectent à VOTRE relais et non à un MITM.

Étape 4 : Configurer le DNS

Pointez un enregistrement A pour relay.yourdomain.com vers l'IP du VPS. RustDesk accepte aussi une IP nue, mais un nom d'hôte est plus flexible si vous migrez ultérieurement.

Étape 5 : Pointer les clients vers le relais auto-hébergé

C'est la partie que la plupart des guides survolent. Chaque client a besoin de trois valeurs de configuration :

• Serveur ID = relay.yourdomain.com:21116
• Serveur relais = relay.yourdomain.com:21117
• Clé publique = le contenu de data/id_ed25519.pub sur votre VPS

Sur Windows / macOS / Linux :

1. Ouvrez le client GoDesk ou RustDesk.
2. Paramètres → Réseau → Serveur ID/Relais.
3. Saisissez les trois valeurs ci-dessus. Enregistrez.
4. Redémarrez le client.

L'indicateur de statut devrait passer au vert en quelques secondes, indiquant qu'il est enregistré auprès de votre relais. S'il reste rouge, vérifiez les règles du pare-feu et que la clé publique correspond exactement.

Étape 6 : Ajouter TLS (optionnel mais recommandé)

Le protocole RustDesk par défaut est déjà chiffré au niveau application (la clé publique que vous avez copiée en fait partie). Ajouter TLS apporte une seconde couche et protège contre certaines attaques en mode passif. L'installation implique un reverse proxy (nginx ou Caddy) devant les ports du relais.

Version Caddy (plus simple) :

relay.yourdomain.com {
    reverse_proxy /ws/* localhost:21118
    reverse_proxy * localhost:21115
}

Caddy émet automatiquement le certificat Let's Encrypt. Mettez à jour les clients pour utiliser le port 443 avec TLS activé.

Étape 7 : Sauvegarder les clés

Le répertoire data/ contient la paire de clés du serveur de rendez-vous. Si vous la perdez, chaque client devra être reconfiguré avec la nouvelle clé publique. Sauvegardez-la :

# Local backup
rsync -avz vps:/opt/godesk-relay/data/ ~/godesk-relay-backup-$(date +%Y%m%d)/
# OR copy the two key files
scp vps:/opt/godesk-relay/data/id_ed25519* ~/godesk-keys/

Conservez la sauvegarde hors ligne. Si le VPS est compromis, vous devez pouvoir en lancer un nouveau avec les mêmes clés pour que les clients existants continuent de fonctionner sans reconfiguration.

Modes de défaillance que la doc n'évoque pas

Défaillance 1 : Les clients n'atteignent pas le relais. 90 % du temps, c'est le pare-feu. Vérifiez ufw status, vérifiez que le groupe de sécurité du fournisseur cloud autorise également les mêmes ports, et lancez nc -vz relay.yourdomain.com 21116 depuis un client pour vérifier la joignabilité.

Défaillance 2 : Le P2P retombe toujours sur le relais. Un NAT symétrique ou des pare-feu d'entreprise stricts forcent tout le trafic via le relais. C'est normal — les performances restent correctes mais la facturation de la bande passante s'applique. Utilisez relay.yourdomain.com avec un plan VPS à haut débit.

Défaillance 3 : Le processus relais meurt et ne redémarre pas. Le paramètre Docker restart: unless-stopped couvre la plupart des cas. Ajoutez docker compose ps dans une tâche cron qui vous alerte en cas de conteneurs manquants.

Défaillance 4 : Le certificat SSL expire. Si vous utilisez Caddy, c'est automatique — il renouvelle 30 jours avant l'expiration. Si vous utilisez nginx + certbot, configurez une tâche cron pour renouveler. certbot.eff.org contient le guide officiel.

Calcul de la bande passante

La qualité compte. Estimation approximative :

• Faible qualité (travail majoritairement textuel) : ~50 KB/s = 180 MB/hour
• Qualité moyenne (bureautique générale) : ~200 KB/s = 720 MB/hour
• Haute qualité (vidéo, design) : ~1 MB/s = 3.6 GB/hour

Un Hetzner CX22 avec 20 TB/month de bande passante gère environ 5 500 heures de sessions haute qualité par mois — bien plus que l'utilisation d'un particulier ou d'une petite équipe. Le plafond de 20 TB concerne surtout les organisations avec des centaines d'appareils.

Option pré-construite : le relais auto-hébergeable de GoDesk

Tout ce qui précède est la voie manuelle avec la pile open-source de RustDesk. GoDesk publie un bundle auto-hébergeable basé sur la même pile hbbs/hbbr avec des valeurs par défaut sensées pré-configurées. Si vous ne voulez pas gérer des fichiers Docker compose, voyez notre guide d'auto-hébergement — même architecture, avec un script d'installation en une commande qui enveloppe les étapes ci-dessus.

Quand NE PAS auto-héberger

L'auto-hébergement ajoute une charge opérationnelle : supervision, sauvegardes de clés, mises à jour OS, renouvellement de certificats. Si votre cas d'usage est « je veux me connecter à mon PC personnel », le relais hébergé par le fournisseur (le forfait gratuit de GoDesk gère 5 GB/month) demande bien moins de travail que d'exploiter un VPS en permanence.

Auto-hébergez si vous avez une vraie raison — conformité, souveraineté, montée en charge. Évitez-le si « ce serait cool » est la seule motivation ; la taxe opérationnelle vous rattrapera.

Récapitulatif

1. VPS à $5/month dans la région de votre choix.
2. Docker + UFW + conteneurs hbbs/hbbr de RustDesk.
3. Enregistrement DNS A pointant vers le VPS.
4. Trois valeurs de configuration sur chaque client (Serveur ID, Serveur relais, Clé publique).
5. Sauvegarder les clés.
6. Optionnel : TLS via Caddy/nginx.

Temps d'installation de bout en bout : 30 minutes. Maintenance continue : minimale. Résultat : un bureau à distance dont le trafic ne transite jamais par l'infrastructure d'un tiers.

Pour en savoir plus sur l'aspect GoDesk — documentation d'auto-hébergement, le paysage open-source, ou le client lui-même.