Bureau à distance auto‑hébergé : le guide honnête 2026

Si vous recherchez des guides pour bureau à distance auto‑hébergé, vous trouverez une douzaine de tutoriels qui s'arrêtent après docker compose up -d. L'installation est la partie facile, et elle prend vraiment 30 minutes. Ce guide la couvre en intégralité — puis détaille la partie qui décide si vous auriez dû le faire : combien ça coûte de maintenir le service une fois le tutoriel terminé.

La réponse courte

Auto‑hébergez lorsque vous y êtes contraint par une exigence. Utilisez un relais géré sinon. Cela paraît simpliste, voici le vrai test :

• Auto‑hébergez si : une obligation écrite de conformité indique que le trafic de session ne doit pas transiter par une infrastructure tierce ; vous exploitez des réseaux air‑gapped ou autrement restreints où un relais externe est inaccessible ; ou des règles de résidence des données imposent une juridiction dans laquelle vous devez rester.
• Utilisez un relais géré si : votre raison est toute variante de « Je préfère l'exploiter moi‑même. » C'est une préférence légitime, et c'est aussi un travail d'exploitation permanent — voyez la facture ci‑dessous avant de vous engager.

Il vaut mieux être clair sur le choix, car il ne s'agit pas de deux produits différents. Tenvo est AGPL-3.0 et le relais géré exécute la même architecture hbbs/hbbr que ce guide installe. Le choix porte sur qui exploite la machine, pas sur ce que fait le logiciel.

Premièrement : ce qu’un relais peut réellement voir

Ceci importe plus que tout, car c'est généralement la raison pour laquelle les gens optent pour l'auto‑hébergement — et c'est généralement mal expliqué.

Sur une connexion P2P directe, la session s'exécute de bout en bout entre les deux appareils. Quand une connexion directe ne peut pas être établie — NAT symétrique, pare‑feux d'entreprise stricts — la session est relayée, et TLS est terminé au niveau du relais. Celui qui exploite ce relais est donc en mesure de voir le trafic relayé. Nous ne prétendrons pas le contraire pour le nôtre.

C'est une propriété du protocole, pas de celui qui paie le serveur. Héberger le relais vous‑même n'empêche pas l'accès à des données que le relais d'un fournisseur autoriserait ; cela change qui occupe cette position. Si la réponse à « qui est autorisé à l'occuper » figure dans une obligation de conformité écrite, l'auto‑hébergement est la bonne solution et le reste de ce guide s'adresse à vous. Si cela n'est écrit nulle part, vous vous engagez dans une tâche d'exploitation pour résoudre un problème que vous n'avez pas.

Ce que vous construisez

Deux services :

• hbbs (rendezvous server): gère la poignée de main initiale. Les deux clients se connectent brièvement pour se découvrir, échanger des clés publiques, et déterminer si le P2P direct est possible. Écoute sur TCP/UDP 21115-21117.
• hbbr (relay server): transporte la session lorsque le P2P direct échoue. Écoute sur TCP 21117 (et UDP pour certains scénarios).

Le relais ne s'active que lorsque le P2P ne fonctionne pas — fréquent avec les NAT domestiques, rare sur un réseau local. Donc même en auto‑hébergement, vous ne payez la bande passante VPS que pour les sessions qui nécessitent effectivement le relais.

Étape 1 : choisir un VPS

La bande passante est la ressource qui compte. CPU et RAM sont secondaires, car le relais transfère des octets plutôt que de les traiter.

• Hetzner CX22 (€4/mo, 2 vCPU, 4 GB RAM, 20 TB bandwidth, EU data centres) — meilleur rapport prix/bande passante.
• DigitalOcean Basic Droplet ($6/mo, 1 vCPU, 1 GB, 1 TB bandwidth) — bonne UX, régions US/EU.
• OVH VPS Starter (€3.50/mo, 2 vCPU, 2 GB, unmetered bandwidth) — meilleur pour des scénarios à haute bande passante.

Choisissez une région proche des clients qui se connecteront. Le trafic du relais dépend du temps aller‑retour, c'est donc le levier principal sur la latence perçue — et, comme vu ci‑dessous, celui pour lequel un VPS unique est le pire.

Étape 2 : préparer le serveur

Lancez 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 l'étape du pare‑feu. La configuration par défaut n'expose que les ports nécessaires ; tout le reste doit être verrouillé.

Étape 3 : lancer hbbs + hbbr via Docker

Créez /opt/tenvo-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, puis démarrez :

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

hbbs imprime une clé publique au premier démarrage. Sauvegardez‑la depuis les logs (id_ed25519.pub dans le volume data) — les clients l'utilisent pour vérifier qu'ils se connectent à votre relais et non à un imposteur.

Étape 4 : configurer le DNS

Pointez un enregistrement A pour relay.yourdomain.com vers l'IP du VPS. Une IP brute fonctionne aussi, mais un nom d'hôte est beaucoup plus simple à gérer en cas de migration.

Étape 5 : configurer les clients pour utiliser votre relais

La partie que la plupart des guides survolent. Chaque client a besoin de trois valeurs :

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

Sur Windows, macOS et Linux :

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

L'indicateur d'état devrait passer au vert en quelques secondes. S'il reste rouge, vérifiez les règles du pare‑feu et que la clé publique correspond exactement — un saut de ligne en fin de fichier est la cause habituelle.

Étape 6 : ajouter TLS

Placez un reverse proxy devant les ports du relais. Caddy est la solution la plus simple :

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

Caddy émet et renouvelle le certificat Let's Encrypt pour vous. Mettez les clients à jour pour utiliser le port 443 avec TLS activé — ce qui permet aussi de traverser des pare‑feux sortants restrictifs qui n'autorisent que le 443.

É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 une nouvelle clé publique — manuellement, sur chaque machine.

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

Conservez‑la hors ligne. Si le VPS venait à être compromis, vous voulez reconstruire sur une machine propre avec les mêmes clés, afin que les clients existants continuent de fonctionner sans modification.

Les modes de défaillance que les tutoriels omettent

Les clients n'atteignent pas le relais. Presque toujours le pare‑feu. Vérifiez ufw status, vérifiez que le groupe de sécurité du fournisseur cloud autorise les mêmes ports, et exécutez nc -vz relay.yourdomain.com 21116 depuis un client pour confirmer la reachabilité.

Tout passe systématiquement par le relais. Le NAT symétrique et les pare‑feux d'entreprise stricts forcent chaque session à transiter par le relais. Les performances tiennent, mais votre facture de bande passante devient l'élément principal plutôt que l'exception.

Le relais meurt et ne redémarre pas. Le restart: unless-stopped de Docker couvre les cas courants. Il ne couvre pas un disque plein, un OOM kill ou un kernel panic — pour ceux‑ci vous avez besoin d'un monitoring qui notifie quelqu'un, et cette personne, c'est vous.

Le certificat expire. Automatique avec Caddy. Avec nginx + certbot, c'est une tâche cron dont vous devez vous souvenir ; certbot.eff.org propose le guide officiel.

La facture que les tutoriels ne montrent pas

Le VPS à €4 est la ligne la moins chère sur la facture, et le citer comme coût de l'auto‑hébergement revient à citer le prix d'achat d'une voiture comme coût de conduite. Le reste :

• Vous êtes d'astreinte pour votre propre relais. Lorsqu'il tombe en panne à 2h du matin, l'accès à distance est justement ce que vous n'aurez plus pour le réparer.
• Mises à jour OS, pour toujours. Une machine exposée sur Internet est une machine dont vous êtes responsable pour les correctifs.
• Garde des clés. Perdre data/ vous oblige à reconfigurer chaque client à la main. Cette sauvegarde devient quelque chose que vous devez réellement vérifier, pas simplement planifier.
• Renouvellement des certificats. Automatique jusqu'au jour où ce ne l'est plus.
• Une région, une machine. Un VPS unique se situe dans un seul lieu et n'offre pas de basculement. Les clients à l'autre bout du monde paient pour cela en latence aller‑retour ; si la machine est down, tout le monde est down.

La bande passante est le seul coût véritablement simple à estimer. Chiffres approximatifs par session relayée :

• Basse qualité, travail majoritairement texte : ~50 KB/s = 180 MB/hour
• Moyen, travail de bureau général : ~200 KB/s = 720 MB/hour
• Élevé, travail vidéo et design : ~1 MB/s = 3.6 GB/hour

Les 20 TB/month d'un Hetzner CX22 couvrent environ 5 500 heures de sessions relayées de haute qualité. Pour un individu ou une petite équipe, ce plafond n'est généralement pas la contrainte limitante — et c'est précisément le point. Si la bande passante était la raison pour laquelle vous envisagiez de vous auto‑héberger, ce n'est pas un bon motif. Les contraintes réelles sont les quatre puces ci‑dessus.

Ce que fait le relais géré à la place

Même architecture, opérateur différent. La flotte de relais est multi‑régions plutôt qu'un VPS unique, donc les clients se connectent à quelque chose proche d'eux plutôt que proche de vous. Elle est monitorée par des personnes dont c'est le métier. Le matériel clé, les correctifs et le renouvellement des certificats cessent d'être votre problème. Quand quelque chose casse à 2h du matin, la personne notifiée n'est pas vous.

C'est ce que l'abonnement achète : Free à $0, Lite à $2.99/mo, Pro à $7.99/mo — voir tarifs pour le contenu de chaque niveau, ou les plans entreprise si vous déployez à l'échelle d'une équipe. Mis en regard d'un VPS à €4 et de votre propre astreinte, l'arithmétique n'est pas en faveur de l'auto‑hébergement pour la plupart des gens.

Quand l'auto‑hébergement est vraiment la bonne option

C'est la bonne option quand une obligation l'exige : travail réglementé où le trafic ne doit pas traverser d'infrastructure tierce, réseaux isolés (air‑gapped) ou restreints où un relais externe est inaccessible, ou règles de résidence qui vous obligent à rester dans une juridiction. Dans ces cas, le coût opérationnel n'est pas une surcharge, c'est l'exigence, et ce guide est exactement ce dont vous avez besoin.

Il importe aussi que l'option existe. Tenvo est AGPL-3.0 et la pile serveur est open source, donc le relais géré est une commodité que vous achetez plutôt qu'un verrou que vous acceptez. Si nous cessons un jour d'en valoir la peine, la sortie est le guide ci‑dessus — c'est le sens de sa publication. Voir comment la version gérée se compare à RustDesk, ou comment fonctionne le modèle de sécurité.

Récapitulatif

1. Un VPS dans la région la plus proche de vos clients.
2. Docker, UFW, et les containers hbbs/hbbr.
3. Un enregistrement A DNS pointant vers le VPS.
4. Trois valeurs de configuration sur chaque client : Serveur d'ID, Serveur relais, clé publique.
5. Une sauvegarde hors ligne de data/ que vous avez réellement restaurée au moins une fois.
6. TLS via Caddy, et un monitoring qui vous notifie.

Trente minutes pour déployer ; indéfiniment à assumer. Si une exigence vous place dans ce cas, les étapes ci‑dessus constituent l'intégralité du travail. Si aucune exigence n'existe, commencez par le relais géré — téléchargez le client, et revenez sur cette page le jour où un formulaire de conformité le rendra pertinent.