Oui — le bureau à distance est sûr quand l’outil utilise un chiffrement de bout en bout et des connexions directes de pair à pair ; il est risqué quand il s’appuie sur un port exposé ou sur un protocole ancien non chiffré. Vous confiez à un logiciel le contrôle complet de votre ordinateur : cela mérite plus qu’une promesse de page marketing. Voici la carte des menaces, les quatre défenses qui comptent et sept réponses franches aux questions que les gens se posent vraiment.
La matrice des menaces
La plupart des articles sur la sécurité s’ouvrent sur un vague rassurement. Nous allons commencer par la surface d’attaque réelle. Voici les huit façons réalistes dont une session de bureau à distance peut être compromise en 2026, ce que Remio fait pour chacune, et ce que vous devriez faire pour les autres.
| Menace | Niveau de risque | Comment Remio se défend | Ce que vous devriez faire |
|---|---|---|---|
| Écoute du réseauTHR-01 | ÉLEVÉ | Chiffrement de bout en bout DTLS-SRTP sur chaque paquet ; les clés sont générées sur chaque extrémité et jamais envoyées à un serveur. | Évitez le Wi-Fi public pour du RDP en clair. Les applications modernes à chiffrement de bout en bout atténuent déjà cette menace. |
| Attaque de l’homme du milieuTHR-02 | ÉLEVÉ | L’empreinte du certificat DTLS est échangée sur un canal authentifié du serveur de connexion ; les deux extrémités la vérifient avant que le moindre flux ne circule. | Jumelez-vous uniquement avec un code lu sur l’écran de votre propre hôte, et supprimez tout appareil que vous ne reconnaissez pas. |
| Vol d’identifiantsTHR-03 | ÉLEVÉ | Pas de compte, pas d’e-mail, pas de mot de passe. Le jumelage utilise un code à six chiffres que vous pouvez renouveler à tout moment. | Si votre outil à distance exige un mot de passe, utilisez un gestionnaire de mots de passe et des identifiants uniques par service. |
| Détournement de sessionTHR-04 | MOYEN | Les jetons de session sont liés à la connexion DTLS et ne peuvent pas être rejoués. | Terminez explicitement les sessions une fois fini. Ne laissez pas un hôte sans surveillance avec une connexion active. |
| Force brute sur un port en écouteTHR-05 | ÉLEVÉ | Remio n’a besoin d’aucun port ouvert de votre côté : les deux extrémités se connectent vers l’extérieur, donc les scanners de ports ne trouvent normalement aucun service en écoute à attaquer. Mac Host 3.3 peut demander à un routeur qui l’autorise d’ouvrir un port pour une session (activé par défaut, et facultatif). | N’exposez jamais le port RDP 3389 à Internet. Placez au minimum WireGuard ou Tailscale devant. |
| Intrusion chez le fournisseur (chaîne d’approvisionnement)THR-06 | ÉLEVÉ | Notre serveur de connexion ne voit que des identifiants d’appareil anonymes et des métadonnées de négociation chiffrées. Une compromission totale du serveur ne livre aucun contenu de session. | Avant d’installer un outil à distance, cherchez le nom du fournisseur accompagné du mot « intrusion » (breach) et lisez les déclarations des deux dernières années. |
| Menace interne chez le fournisseurTHR-07 | MOYEN | Les clés des flux n’atteignent jamais l’infrastructure de Remio. Un employé malveillant ne peut pas déchiffrer une session, même avec un accès complet aux serveurs. | Pour les charges de travail réglementées, privilégiez les fournisseurs qui publient chaque année un rapport SOC 2 Type II couvrant la gestion des clés. |
| Pare-feu mal configuréTHR-08 | FAIBLE | La conception en sortie uniquement fait qu’un pare-feu mal configuré échoue en mode fermé, pas ouvert. La session ne se connecte simplement pas. | Auditez les règles de pare-feu entrantes chaque trimestre. Bloquez le port 3389 en sortie au niveau du périmètre, sauf si vous avez précisément besoin de RDP. |
Trois choses ressortent de cette carte. D’abord, chaque menace de risque ÉLEVÉ contre un bureau à distance moderne à chiffrement de bout en bout est déjà traitée au niveau du protocole, pas par la discipline de l’utilisateur. Ensuite, la pire surface d’attaque de l’histoire du bureau à distance reste Microsoft RDP exposé sur le port 3389. Enfin, le fournisseur lui-même est le plus grand risque résiduel de tout produit à relais cloud, car une seule intrusion touche tous les clients à la fois.
La défense en quatre couches
Si la matrice des menaces est ce que voient les attaquants, la défense en couches est ce que traversent vos paquets à la sortie. Remio superpose quatre protections indépendantes. Chacune serait utile seule ; ensemble, elles laissent très peu de prise à un attaquant.
DTLS négocie un canal authentifié avant qu’aucun paquet de flux ne quitte votre appareil. SRTP chiffre et authentifie ensuite chaque image vidéo et chaque événement de saisie, avec des clés générées directement entre vos deux appareils — votre écran ne passe jamais par nos serveurs. Voir RFC 5764.
Notre serveur de connexion utilise TLS 1.3 et ne transporte que du matériel de négociation opaque : adresses de connexion à essayer, empreintes DTLS et identifiants d’appareil éphémères. Le contenu des sessions ne transite jamais par le serveur de connexion. Voir draft-ietf-rtcweb-security-arch.
Pas de compte, pas d’e-mail, pas de mot de passe. Le jumelage utilise un code à six chiffres que vous pouvez renouveler à tout moment, avec un nombre d’essais limité par l’hôte. Il n’y a aucune base d’identifiants à voler, car il n’y a pas d’identifiants.
Les images sont décodées directement dans le GPU et jamais écrites sur le disque. Le presse-papiers, le transfert de fichiers et l’audio utilisent le même canal DTLS-SRTP que la vidéo, donc la couche de données hérite automatiquement des garanties de la couche de transport.
Le principe de cet empilement, c’est l’indépendance. Si un futur bogue casse une couche, la suivante tient toujours. Si nous changeons de fournisseur de relais demain, la couche d’identité n’est pas touchée. Si une faille zero-day de TLS 1.3 survient dans le serveur de connexion, le canal média DTLS-SRTP utilise toujours des clés à confidentialité persistante qui n’ont jamais emprunté le chemin du serveur de connexion.
Microsoft RDP, l’éléphant dans la pièce
Si vous cherchez la sécurité du bureau à distance, la plupart des résultats parlent de Microsoft RDP. Il y a une raison. RDP a été conçu en 1998 pour des réseaux d’entreprise internes. L’exposer directement à l’Internet public sur le port 3389 est le principal facteur de rançongiciels de la dernière décennie.
Des scanners automatisés balaient en continu l’espace IPv4 à la recherche du port 3389. Quand ils en trouvent un, ils essaient les mille mots de passe les plus courants. S’ils entrent, le rançongiciel se déploie en quelques heures. Plusieurs rapports de renseignement sur les menaces attribuent à RDP exposé plus de 60 pour cent des incidents d’accès initial par rançongiciel en 2025.
Exposer RDP sur le port 3389 revient, en sécurité, à laisser sa porte d’entrée ouverte avec une pancarte qui liste ce qu’il y a à l’intérieur.
La solution n’a rien de subtil. N’exposez jamais RDP à l’Internet public. Faites-le passer dans un tunnel WireGuard, Tailscale ou un VPN d’entreprise. Mieux : utilisez une application de bureau à distance conçue à cet effet, qui gère le réseau en sortie uniquement, de sorte qu’il n’y ait pas de port en écoute à attaquer au départ.
Quand le fournisseur est piraté
Ce ne sont pas des scénarios hypothétiques. Ils se sont produits au cours des deux dernières années.
AnyDesk, février 2024. AnyDesk a confirmé que des attaquants avaient compromis ses systèmes de production, exfiltré du code source et volé des certificats de signature de code. L’entreprise a révoqué tous les certificats et imposé une réinitialisation mondiale des mots de passe. L’intrusion est restée indétectée pendant des semaines avant d’être révélée. Tout binaire AnyDesk téléchargé durant cette fenêtre aurait pu être usurpé par des attaquants détenant les clés de signature d’origine.
TeamViewer, juin 2024. TeamViewer a révélé qu’APT29, le groupe soutenu par l’État russe à l’origine de l’attaque SolarWinds, avait pénétré son réseau d’entreprise. TeamViewer a affirmé que l’intrusion se limitait à l’informatique interne, mais APT29 ne repart en général pas les mains vides. Le fait qu’un des acteurs étatiques les plus sophistiqués ait ne serait-ce que visé un éditeur de bureau à distance est déjà le titre.
Le schéma est structurel. Un éditeur de bureau à distance centralisé détient des identifiants, des jetons de session et l’infrastructure de routage de millions de machines. Piratez l’éditeur, héritez des clés. C’est l’attaque de la chaîne d’approvisionnement de manuel. La seule architecture défendable est celle où l’éditeur ne peut pas aider un attaquant même totalement compromis, parce qu’il ne détient aucune clé de déchiffrement de session au départ.
Une liste de contrôle pratique
Quel que soit le produit que vous choisissez, ces dix pratiques réduisent le risque d’un ordre de grandeur.
- Utilisez une application de bureau à distance à chiffrement de bout en bout. Du RDP en clair exposé à Internet n’est pas acceptable en 2026.
- Préférez les connexions de pair à pair. Moins d’intermédiaires signifie une surface d’attaque plus petite et une latence plus faible.
- Activez l’authentification multifacteur sur tout compte qui touche votre outil à distance, y compris le système d’exploitation lui-même.
- Gardez les logiciels de l’hôte et du client à jour. La plupart des CVE ont un correctif disponible avant d’être exploitées à grande échelle.
- Ne réutilisez jamais vos mots de passe d’un éditeur de bureau à distance à l’autre. Des mots de passe uniques limitent le périmètre d’impact de toute intrusion.
- Choisissez des codes PIN et des mots de passe solides. Un code PIN numérique à six chiffres donne un million de combinaisons ; chaque chiffre supplémentaire les multiplie par dix.
- Désactivez l’accès à distance quand vous ne l’utilisez pas. La plus petite surface d’attaque est celle qui est éteinte.
- Passez en revue vos appareils connectés chaque semaine. Supprimez tout ce que vous ne reconnaissez pas. La plupart des outils à distance en gardent la trace.
- N’installez jamais un logiciel de bureau à distance depuis un lien reçu par e-mail. Téléchargez toujours directement depuis le domaine de l’éditeur.
- Cherchez le nom de l’éditeur accompagné du mot « intrusion » (breach) avant d’installer. Si les deux dernières années comportent des déclarations, tenez-en compte.
Questions courantes, réponses directes
Les mêmes questions reviennent dans chaque conversation sur la sécurité du bureau à distance. Voici des réponses directes.
Des pirates peuvent-ils accéder à votre ordinateur via le bureau à distance ?
Oui, si vous exposez Microsoft RDP sur le port 3389 directement à Internet sans VPN ni passerelle zero-trust. RDP exposé a été le vecteur d’accès initial dans plus de 60 pour cent des incidents de rançongiciel signalés en 2025. Une application de bureau à distance moderne qui utilise une connexion pair à pair chiffrée de bout en bout n’est pas vulnérable à cette catégorie d’attaque, car aucun port en écoute n’est exposé aux scanners.
Le trafic de bureau à distance est-il chiffré ?
Cela dépend de l’application. Microsoft RDP utilise TLS 1.2 par défaut et peut être configuré pour exiger TLS 1.3. Des applications comme Remio utilisent DTLS-SRTP pour chiffrer de bout en bout chaque paquet vidéo et de saisie, avec des clés négociées directement entre vos appareils. Les applications à relais cloud chiffrent en général en transit mais détiennent elles-mêmes les clés, ce qui signifie que l’éditeur, ou quiconque le pirate, peut déchiffrer votre session.
Faut-il un VPN pour le bureau à distance ?
Si vous utilisez Microsoft RDP, oui. Faites toujours passer RDP par un tunnel WireGuard, Tailscale ou un VPN d’entreprise. Si vous utilisez une application de bureau à distance moderne à chiffrement de bout en bout, la connexion est déjà chiffrée aux deux extrémités et un VPN ajoute de la latence sans ajouter de sécurité. Un VPN peut rester utile pour la conformité, le masquage d’IP ou la restriction géographique, mais il ne renforce pas une session déjà chiffrée.
Quelle est la différence entre un bureau à distance de pair à pair et à relais cloud ?
Les connexions de pair à pair circulent directement entre vos deux appareils. Le serveur de connexion ne fait que les aider à se découvrir. Ensuite, aucun tiers ne voit votre trafic. Les applications à relais cloud font transiter chaque image vidéo et chaque frappe par le centre de données de l’éditeur. L’éditeur peut techniquement inspecter votre session, et une seule intrusion chez lui expose toutes les sessions actives à la fois. Remio se connecte directement par défaut et n’utilise un relais chiffré que lorsque votre réseau l’exige — et même alors, le relais transmet du texte chiffré qu’il ne peut pas lire.
Quel est le protocole de bureau à distance le plus sûr en 2026 ?
Un empilement bâti sur le chiffrement DTLS-SRTP, avec génération des clés de bout en bout sur les appareils clients, est l’option grand public la plus solide. Il combine l’authentification par paquet et un échange de clés à confidentialité persistante, et n’exige l’ouverture d’aucun port entrant sur la machine hôte. Les spécifications pertinentes sont RFC 5764 et draft-ietf-rtcweb-security-arch.
Comment savoir si une application de bureau à distance est chiffrée de bout en bout ?
Lisez le livre blanc de sécurité. Si l’éditeur ne peut pas vous dire quelles clés sont générées sur l’appareil et lesquelles sont conservées côté serveur, l’application n’est pas chiffrée de bout en bout. Une véritable application à chiffrement de bout en bout affirmera que les clés des flux ne quittent jamais les extrémités et qu’une compromission du serveur ne peut déchiffrer ni les sessions passées ni les futures. AnyDesk, TeamViewer et Chrome Remote Desktop ne sont pas chiffrés de bout en bout par défaut.
Dois-je désactiver le bureau à distance quand je ne l’utilise pas ?
Oui. La plus petite surface d’attaque est celle qui est éteinte. Si votre application hôte prend en charge une fermeture après inactivité ou un mode sans écoute, activez-le. Pour Microsoft RDP, désactivez entièrement le service dans les paramètres de Windows quand vous n’êtes pas d’astreinte. Ne le réactivez que pendant la durée où vous avez besoin d’un accès.
Pourquoi nous avons construit Remio ainsi
Le principe de conception est simple. Remio ne devrait pas avoir besoin qu’on lui fasse confiance. La matrice des menaces ci-dessus ne fonctionne pas comme liste marketing si votre sécurité dépend de la promesse d’un éditeur d’être bien intentionné. Elle ne fonctionne que si l’éditeur ne peut pas aider un attaquant même s’il le voulait, parce qu’il ne détient pas les clés.
C’est pourquoi le jumelage est un code à six chiffres que vous contrôlez au lieu d’un compte. C’est pourquoi les clés des flux sont générées sur vos deux appareils et jamais envoyées ailleurs. C’est pourquoi le serveur de connexion ne voit que du matériel de négociation opaque. Si notre infrastructure était entièrement compromise demain, un attaquant hériterait d’une liste d’identifiants d’appareils anonymes qui ont un jour tenté de se jumeler entre eux. Pas de mots de passe. Pas d’enregistrements de sessions. Pas de contenu d’écran. Rien d’utile.
Pour tous les détails du protocole, lisez notre livre blanc de sécurité. Pour voir comment cette architecture se compare aux principaux acteurs en place, le guide honnête des applications de bureau à distance pour Mac passe en revue les éditeurs un par un.
Dernière mise à jour le 20-05-2026. Le paysage de la sécurité évolue vite ; nous révisons ce guide à mesure que de nouvelles déclarations et mises à jour de protocole arrivent.
