Vous êtes dans un café où l’espresso est correct et le Wi-Fi douteux, et vous avez besoin du bureau de chez vous. Est-ce sûr de se connecter ? Tout dépend entièrement du chiffrement du transport — une session chiffrée de bout en bout est sûre sur le réseau le plus louche de la ville, et un protocole ancien non chiffré n’est pas sûr sur le plus agréable. Voici le modèle de menace en langage clair, les protocoles classés selon ce qu’ils laissent fuiter, et la liste de contrôle pour la prochaine fois que vous vous connecterez depuis un endroit que vous ne maîtrisez pas.
Ce que le Wi-Fi public peut réellement voir
Sur un réseau que vous ne contrôlez pas, deux parties sont en position d’observer votre trafic. La première est l’opérateur — celui qui gère le point d’accès et le routeur qui se trouve derrière, ce qui, sur un Wi-Fi public, désigne l’établissement, son prestataire réseau ou quiconque a discrètement monté un point d’accès portant le nom de l’établissement. La seconde, ce sont les autres appareils à proximité : sur les réseaux sans isolation des clients, un ordinateur portable deux tables plus loin peut capturer le trafic qui circule autour de lui. « Observer » signifie enregistrer les paquets que vous envoyez et recevez. Toute la question est de savoir ce que contiennent ces paquets.
- Si le protocole n’est pas chiffré, les paquets contiennent le contenu. Pour le bureau à distance, c’est aussi grave qu’il y paraît : images de l’écran, chaque frappe que vous envoyez — y compris les mots de passe saisis sur la machine distante — et, dans les pires cas hérités, des identifiants échangés au moment de la connexion.
- Si le protocole est correctement chiffré, les paquets contiennent du texte chiffré. L’observation se réduit alors aux métadonnées : avec quels points d’extrémité vous avez échangé du trafic, quand, et en quelle quantité. Assez pour en déduire que vous avez utilisé une app de bureau à distance ; inutile pour retrouver ce qui s’est passé dans la session.
Il vaut mieux se calibrer sur la réalité d’aujourd’hui plutôt que sur les histoires d’horreur de 2010. La plupart du trafic produit aujourd’hui par un ordinateur portable est déjà chiffré — le HTTPS a ôté tout le drame de l’espionnage de comptoir dans un café. Les menaces résiduelles réalistes sont l’observation des métadonnées et les faux points d’accès : un attaquant qui diffuse le nom du réseau de l’établissement pour se placer sur le chemin, en espérant intercepter tout ce qui négocie mal — protocoles anciens, invites de certificat expédiées, appareils qui se connectent automatiquement à des noms familiers. Ce n’est pas une raison de craindre le réseau. C’est une description précise des outils à y apporter : ceux qui ne négocient pas mal.
Les protocoles, classés selon ce qu’ils laissent fuiter
Les noms de produits comptent moins que les configurations ici — un même logiciel peut être très bien ou alarmant selon la version et les réglages ; le classement ci-dessous est donc établi par configuration, de la pire à la meilleure.
- RDP simple sans TLS ni NLA (ancien). La couche de sécurité d’origine de RDP est antérieure à la sécurité de transport moderne, et un client prêt à la négocier peut y être ramené par un attaquant en position d’homme du milieu. Les versions actuelles de Windows utilisent par défaut TLS avec l’authentification au niveau du réseau (NLA) ; cela décrit donc surtout d’anciens hôtes, d’anciens clients et des stratégies de groupe assouplies pour des raisons de compatibilité — mais sur un réseau hostile, une session qui peut être rétrogradée doit être considérée comme lisible.
- VNC sans chiffrement. Le protocole VNC classique envoie le framebuffer — votre écran réel — en clair, et sa connexion traditionnelle par défi-réponse est faible selon les normes actuelles, avec des mots de passe couramment limités à huit caractères. Certains serveurs et clients ajoutent TLS par-dessus ou passent par SSH ; beaucoup d’installations rapides ne le font pas. Un VNC non chiffré sur un Wi-Fi partagé laisse fuiter le contenu de l’écran à quiconque enregistre des paquets.
- RDP avec TLS et NLA. Le réglage moderne par défaut, et sur le réseau il tient bon : la session est chiffrée en transport depuis votre client jusqu’à l’hôte ou à la passerelle, et la NLA exige une authentification avant même la création d’une session. Sur un Wi-Fi public, le point faible pratique est humain — les certificats auto-signés banalisent les invites d’avertissement, et un utilisateur habitué à les passer est exactement ce qu’espère un faux point d’accès. Le chiffrement du transport ne dit d’ailleurs rien de l’exposition : le port 3389 ouvert sur Internet est une autre erreur, bien documentée, où que vous vous connectiez.
- Les apps modernes chiffrées de bout en bout. Les sessions sont chiffrées d’appareil à appareil avant qu’aucun réseau ne les touche. Le réseau de l’hôtel — et tout ce qui se trouve au-delà — voit des métadonnées de connexion : du texte chiffré circulant entre des points d’extrémité, avec un horaire et un volume. Jamais de pixels, jamais de frappes, jamais d’identifiants, car il n’y a aucun identifiant de protocole à voler.
| Configuration | Ce que récupère un observateur sur le réseau | Verdict sur un Wi-Fi public |
|---|---|---|
| RDP simple, sans TLS/NLA | Le contenu de la session lorsqu’une rétrogradation réussit ; identifiants menacés | À ne pas utiliser — considérez-le comme lisible |
| VNC sans chiffrement | Contenu de l’écran en clair ; connexion initiale faible | À ne pas utiliser |
| RDP avec TLS + NLA | Du texte chiffré en transit ; les invites de certificat sont le point faible | Acceptable via un tunnel ; n’exposez jamais le 3389 |
| App moderne à chiffrement de bout en bout | Du texte chiffré et des métadonnées de connexion seulement | Conçu exactement pour cela |
Pourquoi le chiffrement de bout en bout change la réponse
Le chiffrement du transport protège un tronçon ; le chiffrement de bout en bout protège la conversation. La distinction paraît théorique jusqu’à ce que l’on énumère ceux qui se trouvent entre un café et le bureau de chez vous : le point d’accès de l’établissement, son fournisseur d’accès, le vôtre, peut-être un serveur relais de l’éditeur. Avec le chiffrement de bout en bout, les clés sont convenues directement entre vos deux appareils, et les images sont chiffrées avant même de quitter l’appareil. Chaque partie de cette liste — y compris l’infrastructure de l’éditeur — transmet du texte chiffré dont elle n’a pas la clé.
Remio est bâti exactement sur ce modèle ; il sert donc d’exemple concret. La confiance s’établit quand vous associez deux appareils avec un code à six chiffres lu sur l’écran de l’hôte — il n’y a pas de compte, donc pas de mot de passe à pirater au café et aucune base d’identifiants à compromettre. Les clés de session sont négociées directement entre les appareils associés à chaque connexion, et chaque image, chaque frappe, chaque synchronisation du presse-papiers et chaque transfert de fichier est chiffré de bout en bout. Quand un réseau strict force la session à passer par un relais chiffré, le relais transmet des images chiffrées qu’il ne peut pas lire — le modèle de sécurité est identique que le chemin soit direct ou relayé. La conception complète se trouve sur la page sécurité.
Le but n’est pas de trouver un Wi-Fi digne de confiance. C’est de rendre la fiabilité du Wi-Fi sans importance.
Une limite en toute honnêteté : le chiffrement de bout en bout protège la session en transit, et rien d’autre. Si l’ordinateur portable du café est compromis, ou l’hôte à la maison, le meilleur chiffrement entre eux ne change rien — l’attaquant est à l’intérieur d’un point d’extrémité, et lit ce que vous lisez. L’hygiène des postes, l’historique des failles des éditeurs et le reste du tableau du durcissement relèvent d’un autre article, et nous l’avons écrit : le guide de sécurité du bureau à distance. Celui-ci reste sur le réseau.
La liste de contrôle du café
Six points, dans l’ordre où ils rapportent.
- Privilégiez une app de bureau à distance chiffrée de bout en bout. Elle règle la question du Wi-Fi public par conception plutôt que par discipline — le réseau transporte du texte chiffré, que vous ayez ou non bien fait tout le reste de cette liste.
- Si vous êtes coincé avec RDP, n’exposez jamais le port 3389. Passez plutôt par un VPN ou un autre tunnel chiffré au lieu d’une redirection de port sur le routeur ; les alternatives, y compris les apps à connexion sortante uniquement qui n’exigent aucun changement de routeur, se trouvent dans notre guide du bureau à distance sans redirection de ports.
- Laissez le pare-feu du système traiter le réseau comme public. Quand macOS ou Windows vous demande quel type de réseau vous avez rejoint, le profil public est la bonne réponse — il empêche le partage de fichiers, la découverte et d’autres services en écoute d’être visibles par des inconnus sur le même réseau.
- Gardez le client à jour. Un client de bureau à distance analyse des données complexes arrivant d’un réseau auquel vous avez décidé de ne pas faire confiance. Les correctifs existent pour une raison ; sur une machine qui voyage, la mise à jour automatique est le bon réglage.
- Vérifiez que vous êtes sur le vrai réseau de l’établissement. Demandez le nom exact du réseau et ignorez les sosies — un point d’accès peut diffuser n’importe quel nom que son propriétaire saisit. Demander à votre ordinateur d’oublier le réseau en partant l’empêche aussi de se connecter automatiquement à une imitation le mois prochain.
- Considérez la session elle-même comme la chose sensible. Vous pilotez votre machine de la maison ou du bureau depuis un lieu public : faites attention à qui peut voir votre écran, et verrouillez l’hôte distant en vous déconnectant pour ne pas laisser un bureau ouvert derrière vous.
Et un VPN par-dessus ?
Un VPN chiffre tout ce qui circule entre votre appareil et le serveur VPN, et sur un Wi-Fi non fiable c’est réellement utile — il protège les requêtes DNS, le bavardage des apps en arrière-plan et tout trafic non chiffré égaré du réseau local. Si vous en utiliseriez de toute façon un à l’aéroport, rien dans le bureau à distance n’y fait obstacle.
Pour la session de bureau à distance proprement dite, en revanche, la logique est plus étroite, et elle joue dans les deux sens. Un VPN n’est pas nécessaire pour une session chiffrée de bout en bout : le trafic est déjà du texte chiffré avant d’atteindre le tunnel, si bien que le VPN ajoute un saut (et généralement un peu de latence) sans ajouter de confidentialité qui manquait à la session. Et il n’est pas suffisant pour une session non chiffrée : un VPN du commerce protège le chemin jusqu’au serveur de sortie du VPN, après quoi le trafic continue vers l’hôte aussi exposé qu’au départ. L’exception qui confirme la règle est un tunnel qui se termine à l’intérieur du réseau de destination lui-même — un serveur WireGuard sur votre routeur domestique, un VPN d’entreprise vers le bureau — qui couvre tout le chemin et constitue la façon standard d’utiliser RDP à distance. Si vous comparez un VPN à une app de bureau à distance comme méthode d’accès proprement dite, c’est une autre comparaison, qui a son propre article : bureau à distance ou VPN.
Hôtel, aéroport, campus : les particularités réseau qui coupent les connexions
La sécurité mise à part, les réseaux publics ont un second trait de caractère : ils coupent les connexions d’une façon que les réseaux domestiques ne connaissent pas. Trois particularités expliquent l’essentiel.
- Les portails captifs. Tant que vous n’avez pas ouvert un navigateur et accepté les conditions, le réseau avale tout — une app de bureau à distance restera là à échouer sans raison visible. Terminez d’abord le portail ; et si une session qui a fonctionné tout l’après-midi meurt à la troisième heure, soupçonnez un portail qui se ré-authentifie sur minuterie.
- L’isolation des clients. Les hôtels et les campus bloquent couramment le trafic d’appareil à appareil à l’intérieur du réseau : deux de vos propres appareils dans la même pièce peuvent donc être invisibles l’un pour l’autre sur le réseau local. Les apps P2P à connexion sortante uniquement se connectent quand même — les deux appareils appellent vers l’extérieur et se retrouvent à travers Internet — mais le chemin peut être plus long que la pièce où vous êtes assis.
- Le blocage de l’UDP. Les réseaux invités stricts n’autorisent parfois guère plus que le TCP sur les ports web. Les protocoles temps réel préfèrent l’UDP, et c’est là que les apps diffèrent : celle qui dispose d’un repli TCP et relais continue de se connecter, au prix d’un peu de latence, tandis qu’une configuration en UDP seul cale. La mécanique — découverte d’adresse, hole punching et ce qui prend le relais quand — se trouve dans notre explication sur la traversée de NAT, et les ports et protocoles exacts qu’utilise une session figurent dans la documentation sur le pare-feu et le NAT.
FAQ
Est-il sûr d’utiliser le bureau à distance sur le Wi-Fi d’un hôtel ?
Oui, si la session est chiffrée de bout en bout. Avec une app de bureau à distance moderne à chiffrement de bout en bout, le réseau de l’hôtel ne transporte que du texte chiffré : ni l’opérateur ni les autres clients ne peuvent récupérer votre écran, vos frappes ou vos fichiers. Les installations anciennes sont le cas risqué : RDP sans TLS ni NLA, ou VNC sans chiffrement, peuvent exposer le contenu de la session et les identifiants au réseau, et ne doivent pas être utilisés sur le Wi-Fi d’un hôtel sans tunnel chiffré.
Quelqu’un sur le même Wi-Fi peut-il voir mon écran distant ?
Pas si la session est chiffrée de bout en bout. Quelqu’un sur le même réseau peut capturer vos paquets, mais avec le chiffrement de bout en bout ces paquets sont du texte chiffré et les clés n’existent que sur vos deux appareils : le contenu de l’écran n’est donc pas récupérable à partir de la capture. Ce qu’un observateur du même réseau peut encore voir, ce sont les métadonnées — qu’une connexion existe, quand elle est active, et à peu près quelle quantité de données elle fait circuler.
Ai-je besoin d’un VPN pour utiliser Remio sur un Wi-Fi public ?
Non. Les sessions Remio sont déjà chiffrées de bout en bout — les clés sont négociées directement entre vos appareils pour chaque session — la session ne dépend donc pas de la fiabilité du réseau. Un VPN ajoute malgré tout de la confidentialité pour le reste de votre trafic, comme les requêtes DNS et les autres apps, et faire passer Remio par un VPN ne pose aucun problème. C’est un choix qui concerne votre autre trafic, pas une exigence pour la session.
RDP est-il sûr sur un Wi-Fi public ?
Avec TLS et l’authentification au niveau du réseau (NLA) — le réglage moderne par défaut de Windows — la session est chiffrée en transport, et un espion sur le réseau du café ne voit donc que du texte chiffré. La règle permanente porte sur l’exposition plutôt que sur le lieu : n’ouvrez jamais le port 3389 directement sur Internet ; passez plutôt par un VPN ou un autre tunnel chiffré pour atteindre RDP. Les anciennes configurations qui peuvent être rétrogradées vers la sécurité RDP héritée, sans TLS, doivent être considérées comme peu sûres sur tout réseau non fiable.
Qu’apprend encore l’opérateur du Wi-Fi ?
Les métadonnées de connexion. Même avec une session entièrement chiffrée de bout en bout, l’opérateur du réseau peut observer l’horaire, le volume du trafic et les points d’extrémité avec lesquels vous échangez des paquets — assez pour en déduire qu’une session de bureau à distance a eu lieu et combien de temps elle a duré. Ce qu’il ne peut pas récupérer, c’est le contenu : ni images de l’écran, ni frappes, ni fichiers, ni presse-papiers.
Le fil conducteur de tout cela : ce n’est pas l’établissement qui décide si votre session est sûre — c’est le chiffrement. Si vous voulez la version qui ne demande aucune liste de contrôle, installez Remio sur les deux machines, associez-les avec le code à six chiffres, et connectez-vous depuis le réseau que la journée vous offre ; la session est chiffrée de bout en bout dans tous les cas. La page comment ça marche montre ce qui se passe sous le capot.
