Bureau à distance auto-hébergé : pourquoi, comment et ce qui casse

"Bureau à distance auto-hébergé" signifie généralement l'une des deux choses : héberger votre propre infrastructure de relais/rendez-vous pour un outil comme RustDesk, ou héberger une plateforme d'accès à distance web complète comme Apache Guacamole ou MeshCentral. Les deux approches sont valables ; elles présentent des compromis différents. Cet article explique pourquoi vous pourriez auto-héberger, présente les trois outils sérieux de cet espace, décrit concrètement la charge opérationnelle, et indique quand l'auto-hébergement est vraiment préférable à l'utilisation d'un service géré.

TL;DR : Auto-hébergez si vous avez des exigences strictes de souveraineté des données (GDPR, HIPAA, secteurs régulés, déploiements internes), si vous voulez zéro coût de licence récurrent à l'échelle, ou si vous préférez véritablement exploiter votre propre infrastructure. Évitez l'auto-hébergement si vous êtes une petite équipe sans DevOps dédié, si vous avez besoin de certifications prêtes pour les achats publics, ou si vous préférez payer $7.99/mo pour faire disparaître le problème.

Pourquoi auto-héberger ?

Souveraineté des données

La raison numéro un qui pousse les organisations à auto-héberger. Si vous êtes soumis au GDPR, à HIPAA, ou à des régulations sectorielles (banque allemande, administrations françaises, sous-traitants de la défense), le fait d'acheminer des sessions de bureau à distance via un SaaS tiers, même fortement chiffré, peut ne pas satisfaire vos auditeurs. L'auto-hébergement sur une infrastructure que vous possédez (ou louez dans une région que vous contrôlez) supprime complètement la dépendance tierce. Notre relais géré termine le TLS, donc "the relay is ours" est une position de conformité matériellement plus forte que de confier ce rôle à un tiers.

Déploiements internes uniquement

Si votre trafic de bureau à distance ne doit jamais sortir de votre réseau — par exemple un système de contrôle industriel isolé d'internet, ou un LAN hospitalier avec filtrage d'egress strict — un service cloud géré est structurellement inadapté. Vous voulez un relais qui réside sur votre LAN, accessible uniquement par vos appareils autorisés.

Coût à grande échelle

Pour de très grands déploiements (1000+ endpoints), la tarification par poste des services gérés s'accumule. Un relais auto-hébergé exécuté sur un VPS à $40/mois peut desservir des milliers de sessions simultanées si votre bande passante le permet. Le point d'équilibre vis-à-vis d'une offre managée dépend de l'outil, mais à l'échelle MSP et entreprise, l'auto-hébergement l'emporte sur le plan du coût brut.

Personnalisation et contrôle

L'auto-hébergement vous permet de modifier le code source (dans le respect des obligations AGPL-3.0), de personnaliser le branding sans payer pour un palier white-label, et d'ajuster le comportement du relais en fonction de votre topologie réseau spécifique.

Les compromis à accepter

L'auto-hébergement n'est pas gratuit. La facture se paie en surcharge DevOps, pas nécessairement en dollars par mois. Concrètement :

• Provisionnement et maintenance des serveurs : Vous avez besoin d'un serveur Linux avec une IP publique (pour la joignabilité du relais), de la surveillance, de la rotation des logs, des mises à jour OS, et probablement d'une infrastructure de sauvegarde. Prévoyez 2–4 heures/mois de maintenance en régime stable, plus en cas d'incident.
• Configuration NAT et pare-feu : Le relais doit être joignable depuis Internet sur des ports spécifiques (21115–21119 pour la configuration par défaut de RustDesk). Si vous êtes derrière un NAT, vous devez configurer du port forwarding de votre edge vers l'hôte du relais.
• Gestion des certificats : Si vous souhaitez TLS sur l'interface de gestion (ce que nous recommandons), vous avez besoin de Let's Encrypt (certbot) ou équivalent. Renouvellements tous les 60–90 jours, automatisés via cron.
• Planification de capacité : Un seul relais peut gérer beaucoup de trafic, mais à un moment donné il faut un second relais, puis du load balancing. Vous devenez alors une équipe d'infrastructure.
• Pas de support fournisseur : Quand quelque chose casse à 2 h du matin, il n'y a pas de hotline. Vous le dépannez vous-même ou attendez que la communauté réponde.

Les trois outils sérieux

RustDesk (et des forks comme Tenvo)

Le plus simple sur le plan architectural des trois. Deux binaires : hbbs (serveur de rendez-vous, ~30 Mo RAM) et hbbr (relay, ~50 Mo RAM). Ce sont des binaires Rust statiques sans dépendances externes. L'installation se résume grossièrement à :

# On a Linux VPS with a public IP
wget https://github.com/rustdesk/rustdesk-server/releases/latest/download/rustdesk-server-linux-amd64.zip
unzip rustdesk-server-linux-amd64.zip

# Start hbbs (rendezvous) and hbbr (relay) as services
sudo ./hbbs -r your.public.ip
sudo ./hbbr

# Open ports 21115/tcp, 21116/tcp+udp, 21117/tcp, 21118/tcp, 21119/tcp
sudo ufw allow 21115:21119/tcp
sudo ufw allow 21116/udp

# Point clients at your server: in client settings,
# ID Server = your.public.ip, Relay Server = your.public.ip,
# Public Key = (printed by hbbs on first start, or check id_ed25519.pub)

L'empreinte en ressources est minime : un droplet DigitalOcean à $5/mois gère des dizaines de sessions simultanées. Le serveur RustDesk Pro officiel (payant) ajoute une console d'administration web, des journaux d'audit, LDAP/OIDC et des fonctionnalités de type broker pour des déploiements plus importants.

Apache Guacamole

Architecture différente : Guacamole est une application web HTML5 sans client natif. Les utilisateurs se connectent via un navigateur ; le backend de Guacamole (guacd) traduit RDP, VNC et SSH en flux HTML5 canvas/WebSocket. Il n'y a pas de client natif à installer côté contrôleur, ce qui est utile pour les workflows d'assistance où l'on ne peut pas installer de logiciel sur la machine de contrôle.

La complexité opérationnelle est plus élevée que RustDesk : Guacamole tourne en Java + Tomcat avec une base de données (MySQL ou Postgres) pour la gestion des utilisateurs/connexions, plus le démon guacd. Le déploiement avec Docker Compose simplifie beaucoup, mais vous exécutez 3–4 conteneurs au lieu de 2 binaires.

Guacamole est le bon choix si vous voulez spécifiquement un accès via navigateur sans logiciel client. Ce n'est pas le bon choix si vous voulez un outil qui gère la traversée NAT entre deux endpoints hors de la boîte : Guacamole suppose que le serveur Guacamole peut déjà atteindre la machine cible via RDP/VNC/SSH.

MeshCentral

MeshCentral est une plateforme de gestion à distance basée sur Node.js développée par Ylian Saint-Hilaire (anciennement chez Intel). Elle prend en charge le bureau à distance, le transfert de fichiers, le terminal, la console web et une UI de gestion de parc. Sur le plan architectural, c'est une seule application Node + une base de données (NeDB par défaut, Postgres en option), accessible en HTTPS.

MeshCentral est davantage un outil de gestion de flotte que pur relais de bureau à distance : pensez à RustDesk + inventaire des appareils + console d'administration web. L'installation est simple (un seul npm install + fichier de configuration), et elle a été déployée en production par des organisations de taille importante, y compris Intel.

Les limites de MeshCentral : l'UI est dense et pas particulièrement soignée, les clients mobiles sont moins aboutis que ceux de RustDesk, et le codec/la performance pour le streaming de bureau n'est pas aussi optimisé que RustDesk ou AnyDesk. Il est meilleur si vous voulez une console d'administration web unifiée pour une flotte, moins adapté comme outil unique de bureau à distance.

À quoi ressemble réellement un relais RustDesk auto-hébergé

Étape par étape sur un VPS Hetzner CX11 ($4/month) Ubuntu 24.04 :

1. Approvisionnez le VPS avec une IPv4 publique. Définissez un mot de passe root robuste et activez l'authentification par clé SSH.
2. Ouvrez le pare-feu :

   sudo ufw allow OpenSSH
   sudo ufw allow 21115:21119/tcp
   sudo ufw allow 21116/udp
   sudo ufw enable

3. Installez les binaires serveur RustDesk depuis la page des releases GitHub. Placez-les sous /opt/rustdesk-server/.
4. Créez des unit files systemd pour hbbs et hbbr afin qu'ils redémarrent au reboot. Le wiki RustDesk fournit des unités de référence ; nous maintenons une copie validée dans notre help center.
5. Récupérez la clé publique imprimée par hbbs au premier démarrage. Distribuez-la à vos clients avec le nom d'hôte du serveur.
6. Configurez les clients : dans les paramètres du client Tenvo, définissez ID Server, Relay Server et Public Key. Le client utilise maintenant votre relais au lieu du nôtre.
7. Optionnel : terminaison TLS via Caddy si vous souhaitez servir une console d'administration web (RustDesk Pro) sur le port 443 avec des certificats Let's Encrypt renouvelés automatiquement.

Temps total sur un VPS vierge : environ 30 minutes la première fois, 10 minutes si vous l'avez déjà fait. Maintenance continue : apt update && apt upgrade hebdomadaire, surveiller les logs du relais, redémarrer en cas de fuites mémoire (rare). Pour des détails de déploiement Linux, consultez notre page plateforme Linux.

La position de Tenvo sur l'auto-hébergement

Nous vous laissons auto-héberger le relais même sur les paliers payants, si vous le souhaitez. Le client Pro est configuré par défaut pour parler à notre relais géré, mais vous pouvez basculer vers votre propre relais dans les paramètres à tout moment. Il n'y a pas de verrou "enterprise on-prem add-on". C'est volontaire : la licence AGPL-3.0 vous donne le droit d'auto-héberger, et nous voulons que cela reste réel.

La plupart des utilisateurs ne s'en préoccupent pas. Notre relais géré fonctionne simplement, dispose de PoP globaux, et est inclus dans l'abonnement de base. Si votre exigence de souveraineté des données impose « aucun relais tiers nulle part dans le chemin », auto-hébergez. Sinon, économisez le temps DevOps et utilisez le relais géré — c'est ce que l'abonnement vous achète. Pour l'architecture de sécurité complète qui sous-tend les deux modes de déploiement, voir notre page sécurité.

Quand l'auto-hébergement n'est pas la bonne solution

• Vous êtes une petite équipe sans capacité DevOps. La charge de maintenance est réelle. Si vous n'avez personne dont la description de poste inclut « patcher des serveurs Linux », l'auto-hébergement est une taxe récurrente.
• Vous avez besoin de documents fournisseurs pour la procurement. Les auditeurs demandant des rapports SOC 2 n'accepteront pas « nous faisons tourner notre propre serveur » comme réponse. Les services managés avec certifications formelles sont plus adaptés ici.
• Vous n'avez que 5–20 endpoints. Le point d'équilibre entre l'auto-hébergement et un plan managé à $7.99/mo est des centaines d'euros/dollars par an de temps DevOps économisé. À 20 endpoints, le managé est sans ambiguïté moins cher.
• Vous le faites pour économiser sur un seul siège. Un VPS à $5/mois plus 2 heures/mois d'administration à un taux horaire raisonnable coûte déjà plus qu'un seul siège managé.

Conclusion

L'auto-hébergement d'un bureau à distance est une option réelle, et pour certaines organisations c'est la bonne. RustDesk (et des forks comme Tenvo) est l'approche d'auto-hébergement la plus simple ; Guacamole est le bon choix pour l'accès via navigateur ; MeshCentral est le généraliste gestion de flotte. Le compromis reste toujours temps DevOps contre dépenses. Si vous avez des exigences de souveraineté des données, auto-hébergez. Si vous avez $7.99/mo et préférez développer produit plutôt qu'infrastructure, utilisez le relais géré. Voir les tarifs ou télécharger Tenvo et essayez d'abord le flux managé, vous pourrez toujours migrer vers l'auto-hébergé plus tard en changeant une seule ligne de configuration.

FAQ

Puis-je auto-héberger le relais et continuer à utiliser l'UI / les comptes Tenvo ?
Oui. Pointez le client vers votre relais dans les paramètres. Les fonctionnalités de comptes qui dépendent du plane de contrôle Tenvo (billing, team management) continuent de fonctionner ; seul le trafic de session passe par votre relais.

Quel matériel pour un relais RustDesk auto-hébergé ?
Un petit VPS : 1 vCPU, 1 Go de RAM, 1 To/mois de bande passante gère des dizaines de sessions simultanées. Hetzner CX11, DigitalOcean basic ou AWS t4g.nano conviennent. À l'échelle, la bande passante est généralement le facteur limitant, pas le CPU.

Le RustDesk auto-hébergé supporte-t-il 2FA / SSO ?
Le serveur open-source gratuit (hbbs/hbbr) non. Le serveur RustDesk Pro (payant, licence séparée) ajoute console web, OIDC et journaux d'audit. Le palier Pro de Tenvo en mode managé inclut la 2FA prête à l'emploi.

Puis-je héberger le relais sur AWS Lightsail / Cloudflare / etc. ?
Tout fournisseur disposant d'une IPv4 publique et la possibilité d'ouvrir des ports UDP/TCP personnalisés fonctionne. Le proxy standard de Cloudflare termine le TCP sur le port 443 seulement ; vous auriez besoin de Cloudflare Spectrum (payant) ou d'un écouteur TCP dédié pour les ports RustDesk.

Comment l'auto-hébergement interagit-il avec le GDPR ?
Si votre relais est dans l'UE et que vos données n'en sortent jamais, les règles de transfert transfrontalier du GDPR ne s'appliquent pas. C'est la principale raison pour laquelle le secteur public européen et les établissements de santé choisissent l'auto-hébergement.