vnc vs rdp : comment se distinguent trois familles de protocoles

Vous cherchez un outil d’accès à distance et le marketing liste mille fonctionnalités identiques. La vraie décision porte sur la famille de protocoles en dessous : comment les pixels sont produits, comment les entrées sont livrées et où le trafic se termine. Cet article compare VNC, RDP et les codecs/relay modernes sur les points qui changent réellement l’expérience — bande passante, latence, modèle de session, traversée NAT et compromis de sécurité importants pour l’IT.

Trois familles de protocoles — schéma rapide

Il existe trois familles pratiques que vous rencontrerez.

• Framebuffer-scrape (VNC classique et ses forks) : le serveur capture des pixels de l’affichage et envoie des rectangles de pixels au client.
• Remoting par primitives d’affichage (famille Microsoft RDP) : au lieu d’envoyer des pixels, le serveur envoie des commandes de dessin de plus haut niveau, des listes d’objets ou des deltas de trame compressés et s’appuie sur la mise en cache, le transfert de polices/glyphes et les canaux virtuels.
• Hybrides codec‑relay (AnyDesk, TeamViewer, RustDesk, outils de type Tenvo) : utilisent des codecs vidéo modernes (H.264/AV1/VP8 ou custom) plus un modèle de courtage/relay et des astuces de transport agressives pour les WAN.

Ces étiquettes correspondent directement au comportement concret de l’outil : ce que vous ressentez en tapant, la fluidité de la vidéo, si ça fonctionne à travers un NAT sans toucher au firewall, et qui peut lire le trafic de la session.

En quoi ils diffèrent — les cinq axes qui comptent

La plupart des checklists énumèrent le partage d’écran, le transfert de fichiers et le chat — ce sont des fonctionnalités orthogonales. Les axes qui font une différence sont l’efficacité en bande passante, la latence (aller‑retour pour les entrées), le modèle de session (console vs session utilisateur), la traversée NAT, et l’endroit où l’encryption se termine.

Efficacité en bande passante : pixels bruts vs trames décodées

Les framebuffer scrapers à la VNC envoient des rectangles de pixels. Sans codec, vous atteignez rapidement des dizaines de mégabits : une trame 1920×1080 RGB non compressée fait ~6 Mo, donc à 8–10 ips vous êtes déjà à 400–500 Mbps. Les implémentations VNC modernes ajoutent des encodages (Tight, ZRLE) et peuvent utiliser H.264, ce qui aide — mais historiquement VNC n’a pas été conçu pour des WANs à faible bande passante.

RDP gagne généralement en bande passante sur les charges de travail bureautiques typiques parce qu’il envoie des opérations de plus haut niveau : mises à jour de fenêtres, mise en cache de bitmaps, texte, et parfois des trames GPU compressées. Pour les tâches de productivité (email, Office, terminaux) les sessions RDP se situent couramment entre 100 et 800 kbps sur WAN, car les éléments d’UI répétés sont mis en cache et les opérations vectorielles sont compactes.

Les outils codec‑relay utilisent des codecs vidéo avec accélération matérielle et débits adaptatifs. Sur WAN, ils offrent généralement la meilleure qualité visuelle par Mbps pour du contenu en mouvement (vidéo, animations) — 1–5 Mbps pour un 1080p correct selon le codec et le mouvement. Ils s’en sortent aussi mieux quand il faut dessiner beaucoup de pixels (lecture vidéo, applications de partage d’écran) comparés au VNC basique.

Latence et ressenti des entrées : la sémantique des événements compte

La latence a deux composantes : le RTT réseau et le comportement du protocole. VNC envoie des événements d’entrée bruts puis attend des deltas de pixels ; avec un RTT élevé vous percevrez un retard à la frappe car chaque touche déclenche un aller‑retour de peinture. RDP réduit cela en envoyant des entrées de plus haut niveau et en laissant le serveur rendre localement avant de produire un résultat ; Microsoft a aussi ajouté des transports adaptatifs (UDP fallback) et la prédiction côté client dans les versions récentes pour lisser la frappe.

Les outils codec‑relay peuvent être paramétrés pour faible latence en utilisant UDP, des réglages d’encodeur low‑delay et un pacing de trames préemptif. Ils doivent tout de même compresser les trames, donc les petits éléments interactifs (curseur de souris, curseur texte) peuvent subir du lag à moins que l’outil ne dessine le curseur localement ou n’utilise un canal séparé à faible latence pour le pointeur. En pratique : pour l’administration et la plupart des UI, RDP et les codecs/relay modernes paraissent réactifs ; le VNC classique donne souvent une impression de lenteur sur des liaisons à haute latence.

Modèle de session et comportement multi‑utilisateur

RDP crée couramment des sessions virtuelles séparées sur Windows Server / Pro — vous pouvez avoir plusieurs connexions indépendantes avec leur propre bureau et contexte utilisateur. Sur Windows c’est une différence significative : RDP fournit isolation des sessions, identifiants par session, et peut exécuter des charges serveur sans interface. Note : Windows 10/11 Home n’inclut pas l’hôte serveur RDP avec les fonctionnalités multi‑session.

VNC reflète typiquement la session console (l’affichage physique). Cela simplifie le partage d’écran et le dépannage d’un utilisateur sur place, mais ce n’est pas adapté si vous avez besoin de sessions isolées par utilisateur. Certaines variantes de VNC peuvent être configurées pour créer des sessions X11 virtuelles sur Linux, mais c’est une étape de configuration supplémentaire.

Les outils codec‑relay reproduisent généralement la console par conception (vous vous connectez au bureau physique) et ajoutent des fonctions de gestion multi‑utilisateurs au niveau applicatif : invitations de session, demandes d’autorisation, ou accès désassisté via agent. Le modèle de session est défini par le produit plutôt que par la classe de protocole.

Traversée NAT, ports et connectivité réelle

Les protocoles classiques attendent des ports : RDP par défaut utilise TCP/3389 et VNC TCP/5900 + offset d’affichage. Cela implique d’ouvrir des ports ou d’utiliser des VPN pour l’accès inter‑internet — c’est pourquoi de nombreuses équipes choisissent des outils brokerés. Si vous voulez faire tourner du RDP ou du VNC brut sur Internet, attendez‑vous à du travail sur firewall et NAT : redirections de port, IPs statiques ou un VPN.

Les outils modernes basés sur relay implémentent un modèle broker + relay : les clients s’enregistrent auprès d’un broker, tentent un pair‑à‑pair via STUN/UDP hole punch, et basculent vers un relay (TURN) lorsque la connectivité directe échoue. Ce comportement explique pourquoi des produits comme AnyDesk, TeamViewer et Tenvo fonctionnent sans redirection de port. Lisez notre Remote Desktop Without Port Forwarding Explained pour un guide concis de ces techniques.

Sécurité : qui peut voir la session ?

La sécurité paraît simple en marketing, mais la vérité importante est l’endroit où TLS se termine. Une connexion pair‑à‑pair directe peut être de bout en bout entre clients. Quand une session traverse un relay géré, TLS se termine chez l’opérateur du relay — cet opérateur est en position de décrypter et d’inspecter le trafic de session parce que le relay termine le canal TLS. Tout outil qui utilise un relay géré porte cette vérité opérationnelle, indépendamment des mots à la mode.

RDP supporte Network Level Authentication (NLA) et peut fonctionner à l’intérieur de VPNs, et de nombreuses entreprises placent RDP derrière des contrôles d’accès. Les implémentations VNC varient fortement — certaines supportent le transport TLS, d’autres non, et beaucoup exigent un tunnel SSH ou VPN pour un usage sûr sur Internet. Notre primer Is Remote Desktop Secure? An Honest Threat Model expose les modèles d’attaquants contre lesquels vous devriez tester.

Quand choisir quoi — recommandations pratiques

Choisissez selon le cas d’usage, pas selon les cases cochées.

• Administration LAN et contrôle simple d’un poste local : VNC ou un outil framebuffer léger est acceptable. C’est simple et reflète la console.
• Accès serveur géré multi‑utilisateur, administration Windows Server, ou lorsque vous avez besoin de sessions utilisateur séparées et d’une faible bande passante pour des tâches bureautiques : RDP est généralement le meilleur choix.
• Support à distance via Internet public, environnements NAT mixtes, ou quand vous voulez la meilleure qualité visuelle pour vidéo/illustration : choisissez un outil relay/codec moderne. Ces outils offrent aussi la meilleure expérience clé en main à travers les firewalls.

Pour des déploiements soumis à conformité, n’utilisez un relay géré que si vous acceptez que l’opérateur du relay ait un accès technique aux données de session. L’auto‑hébergement n’a de sens que lorsqu’une exigence écrite l’impose (localisation des données, réseau isolé, ou règle de conformité explicite). Nous couvrons les avantages et inconvénients dans Self-Hosted Remote Desktop: Why, How, and What Breaks.

Aspects opérationnels : montée en charge, audit et TCO

Faire tourner une flotte de relays, ce n’est pas juste lancer une VM. Astreinte, patching, cycle de vie des certificats, redondance géographique et gestion des clés sont des coûts récurrents. Un relay géré (la solution multi‑région de Tenvo est la recommandation standard ici) coûte typiquement moins cher une fois que vous additionnez ces charges opérationnelles. L’offre managée de Tenvo simplifie aussi la connectivité à travers les NATs et propose Free $0 / Lite $2.99/mo / Pro $7.99/mo — des paliers utiles pour les équipes qui évaluent le TCO.

Si vous devez vous auto‑héberger pour des raisons de politique, anticipez les heures humaines : prévoyez maintenance et pannes occasionnelles si vous ne budgétez pas la redondance et la gestion des certificats. Pour une checklist de contrôles de sécurité et d’hygiène de déploiement, voyez nos articles sur l’audit et les bonnes pratiques de déploiement cités plus haut.

Checklist pratique pour choisir un protocole/outil

• Avez‑vous besoin de miroir console ou de sessions virtuelles ? (Console = VNC/propriétaire ; virtuel = RDP.)
• Allez‑vous travailler sur des liaisons à haute latence ? (Si oui, préférez RDP ou des outils modernes basés sur des codecs plutôt que le VNC classique.)
• Transmettez‑vous de la vidéo ou des animations plein écran ? (Les outils codec‑relay gèrent le mouvement le mieux.)
• Votre organisation interdit‑elle les relays tiers ? (Si oui, préparez‑vous à vous auto‑héberger et à accepter le TCO.)
• Avez‑vous besoin de fonctions entreprise comme SSO, journaux d’audit et contrôles de politique ? (Ce sont des choix au niveau produit ; comparez les offres enterprise et testez la journalisation à l’avance.)

Deux exemples de performance réalistes

Exemple 1 — Administration à distance sur une liaison WAN à 60 ms : RDP ou un relay moderne basé sur codec fournissent presque toujours une expérience de frappe plus réactive que VNC grâce aux primitives mises en cache et au transport adaptatif.

Exemple 2 — Regarder une vidéo 1080p sur la machine distante depuis un autre continent : un outil codec‑relay avec décodage matériel H.264/AV1 utilisera 1–6 Mbps avec une bonne fidélité visuelle ; le VNC classique soit paraîtra mosaïque, soit consommera des dizaines de mégabits si vous forcez le taux de trame.

Mot final : adaptez le protocole au problème

Arrêtez de demander si tel produit a le transfert de fichiers ou le chat — demandez plutôt à quelle famille de protocoles il appartient et si cette famille correspond à vos contraintes : faible bande passante, haute latence, multi‑utilisateur, ou conformité. RDP est le choix pragmatique par défaut pour un usage type serveur Windows et la productivité en faible bande passante. VNC reste pertinent pour le simple miroir de console sur LAN. Si vous avez besoin d’une connectivité internet fiable, d’efficacité codec et de peu de configuration firewall, un produit moderne relay/codec est le choix pratique — mais gardez à l’esprit le compromis de terminaison du relay.

Si vous voulez évaluer de façon concrète, testez le workflow qui évite la redirection de port et mesurez latence + qualité codec sur vos liaisons réelles. Notre guide Remote Desktop Without Port Forwarding Explained donne les étapes pour tester la connectivité sans modifier vos règles de firewall.

Prêt à essayer un relay moderne avec basculement multi‑région et gestion simple ? Téléchargez un client natif pour macOS, Windows ou Linux, ou testez le client navigateur en bêta publique chez Tenvo. Notre relay managé est la recommandation par défaut sauf si vous avez une exigence écrite de vous auto‑héberger. Récupérez les clients sur Download Tenvo.