Connexion RDP impossible : « This computer can’t connect to the remote computer » – Diagnostic & solutions Windows

Impossible d’ouvrir une session Bureau à distance ? Le message « This computer can’t connect to the remote computer » masque plusieurs causes. Ce guide 100 % pratique vous aide à diagnostiquer rapidement, puis à corriger durablement le problème sous Windows 10/11 et Windows Server.

Sommaire

Vue d’ensemble du problème

Lorsque l’authentification ou la négociation RDP échoue, le client Remote Desktop (MSTSC) affiche souvent ce message générique. Les origines les plus courantes sont :

Machine distante injoignable : hors tension, déconnectée du réseau, VPN non établi, NAT/routeur mal configuré.
RDP désactivé ou non autorisé : fonctionnalité non activée, utilisateur non membre du groupe Utilisateurs du Bureau à distance.
Blocage pare-feu / port 3389 : règle Windows ou sécurité tierce, redirection NAT manquante, FAI bloquant, port RDP modifié.
Incompatibilités NLA/TLS/CredSSP : exigences d’authentification au niveau réseau, protocoles désalignés, durcissement sécurité.
Services RDP ou sessions défaillants : service Remote Desktop Services stoppé, pile RDP figée, sessions saturées.
Éditions Windows : Windows Home n’accepte pas les connexions entrantes RDP.

Diagnostic express (5 minutes)

Vérifier l’état du PC distant : allumé, non en veille/hibernation, câble réseau/Wi‑Fi opérationnel (voyants, test local).
Tester l’accessibilité réseau (depuis le client) : ping <NomOuIP> powershell -c "Test-NetConnection <NomOuIP> -Port 3389"Résultat :
- Échec ping + port fermé : problème de réseau/VPN/NAT.
- Ping OK, port 3389 fermé : pare-feu ou service RDP non à l’écoute.
- Port 3389 ouvert mais toujours l’erreur : focuser NLA/TLS, autorisations, sessions.
Tenter “/admin” (bypass RemoteApp & limite de sessions) : mstsc /v:<NomOuIP> /admin
Essayer l’IP, puis le nom : exclure un souci DNS. Exemple : 192.168.1.25 puis SERVEUR01.domaine.local.
Vérifier rapidement NLA : si possible côté serveur, désactiver temporairement l’obligation NLA pour tester (ne pas laisser ainsi en production).

Tableau de contrôle : causes et solutions

Étape de vérification	Pourquoi c’est important	Comment procéder
Allumer et connecter le PC distant	RDP nécessite que la machine cible soit sous tension et reliée au réseau.	Vérifier localement ou via un contact que le PC est bien allumé et connecté (câble ou Wi‑Fi opérationnel).
Activer Remote Desktop sur le PC cible	Sans activation, Windows bloque toute session RDP entrante.	Paramètres ▶ Système ▶ Bureau à distance ▶ activer Bureau à distance.
Disposer d’un accès réseau	Le client doit atteindre l’IP ou le nom du PC distant.	En local : même sous‑réseau ou VPN actif. À travers Internet : VPN ou redirection du port 3389/TCP sur la box/routeur.
Être autorisé comme utilisateur RDP	Windows n’autorise que les comptes inscrits dans Utilisateurs du Bureau à distance.	Ajouter l’utilisateur via Système ▶ Bureau à distance ▶ Utilisateurs.
Autoriser RDP dans le pare‑feu Windows	Le pare‑feu peut bloquer le port 3389.	Activer les règles Bureau à distance (TCP‑In) pour les profils Domaine/Privé/Public. Désactiver temporairement tout outil de sécurité tierce le temps du test.
Vérifier le nom d’hôte ou l’adresse IP	Une faute empêche la résolution DNS.	Tester d’abord l’adresse IP directe, puis le nom NetBIOS/FQDN.
Contrôler les services Windows RDP	Remote Desktop Services doit tourner.	Exécuter services.msc, redémarrer Remote Desktop Services (TermService) si besoin.
S’assurer de la compatibilité NLA	Windows peut exiger l’authentification au niveau du réseau.	Activer NLA côté client, ou côté serveur décocher temporairement l’obligation NLA pour tester.

Procédure détaillée par scénario

Environnement LAN ou VPN d’entreprise

Confirmer l’IP du poste cible (ipconfig) et le sous‑réseau : le routage doit permettre l’accès bidirectionnel.
Tester le port 3389 depuis le client : powershell -c "Test-NetConnection <IP-cible> -CommonTCPPort RDP"
Vérifier la politique de groupe (GPO) pouvant désactiver RDP :
- Configuration ordinateur ▶ Modèles d’administration ▶ Composants Windows ▶ Services Bureau à distance ▶ Hôte de session ▶ Connexions : « Autoriser les utilisateurs à se connecter à distance » doit être Activé.
- « Exiger l’authentification au niveau du réseau » alignée avec vos clients.
Antivirus/EDR : certains durcissements (firewall driver, filtrage réseau) peuvent bloquer la pile RDP ; tester avec la politique relâchée ou le module réseau désactivé (temporairement).

Connexion via Internet (NAT/box/routeur)

Rediriger le port TCP 3389 de la box vers l’IP privée du PC RDP (ex. 192.168.1.25). Si le port a été changé (sécurité), rediriger vers ce nouveau port.
Adresse publique : se connecter à <IP_publique>[:port]. Exemple : 203.0.113.10:3390 si votre service écoute sur 3390.
UPnP/CGNAT : si le FAI utilise du CGNAT, la redirection peut être impossible → privilégier un VPN ou une passerelle RD Gateway.
Sécurité : éviter d’exposer 3389 directement sur Internet. Préférez VPN ou RD Gateway, et appliquez une ACL source (adresses IP autorisées) sur le pare‑feu.

VM/Cloud (ex. instances Windows Server)

Vérifier les règles réseau du fournisseur (NSG, Security Groups) : autoriser TCP 3389 depuis votre IP.
Confirmer l’état du service TermService dans l’OS invité et l’IP portée par l’interface.
Pour un premier accès, utiliser la console série/portail pour remettre RDP en ligne si le pare‑feu interne a été durci par erreur.

Compatibilité NLA, TLS et stratégies de sécurité

L’authentification au niveau du réseau (NLA) demande une authentification Kerberos/NTLM avant l’ouverture d’une session graphique. Les problèmes classiques :

Clients anciens ne supportant pas les exigences TLS/NLA modernes.
Serveur durci (ex. FIPS, TLS 1.2 only, ciphers restreints) rendant la négociation impossible.

Approche conseillée :

Vérifier que vos clients sont à jour (MSTSC / Microsoft Remote Desktop).
Si l’accès est urgent, désactivez temporairement l’obligation NLA côté serveur pour tester :
- Paramètres ▶ Système ▶ Bureau à distance ▶ Décochez « Autoriser les connexions uniquement à partir des ordinateurs exécutant le Bureau à distance avec l’authentification au niveau du réseau ».
- Ou via Registre : reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v UserAuthentication /t REG_DWORD /d 0 /f
Important : réactivez NLA ensuite.
Si le serveur est en mode FIPS/TLS strict, alignez les clients (TLS 1.2 activé) ou ajustez le durcissement.

Ports, conflits et écoute réseau

Par défaut, RDP écoute sur TCP 3389. Si un autre service l’utilise ou si vous changez le port, adaptez pare‑feu et NAT.

Port à l’écoute ? netstat -aon | findstr LISTENING | findstr :3389 Si rien n’apparaît, le service RDP n’écoute pas.
Identifier le processus utilisant le port : netstat -aon | findstr :3389 tasklist /FI "PID eq <PID>"
Changer le port RDP (ex. 3390) : reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" ^ /v PortNumber /t REG_DWORD /d 3390 /f Puis : net stop TermService & net start TermService Mettez à jour :
- Pare‑feu Windows (règle entrante TCP sur le nouveau port).
- NAT/routeur (redirection vers 3390).
- Client : se connecter à IP:3390.

Pare‑feu Windows et sécurité tierce

Activer les règles intégrées : powershell -c "Enable-NetFirewallRule -DisplayGroup 'Bureau à distance'"
Créer une règle personnalisée si port modifié : powershell -c "New-NetFirewallRule -Name 'RDP-3390' -DisplayName 'RDP (TCP 3390)' -Protocol TCP -LocalPort 3390 -Direction Inbound -Action Allow -Profile Any"
Produits de sécurité : un module network filter peut bloquer RDP même si la règle Windows est ouverte. Désactivez temporairement la protection réseau de l’EDR pour isoler la cause.

Services RDP & sessions

Redémarrer la pile RDP : services.msc Redémarrer Remote Desktop Services (TermService) et Remote Desktop Services UserMode Port Redirector (UmRdpService).
Sessions bloquées (écran noir/connexion impossible) : qwinsta /server:<NomOuIP> rwinsta <ID-session> /server:<NomOuIP>
Version Windows : Windows Home ne peut pas héberger une session RDP. Vérifiez l’édition (Pro/Enterprise/Education/Server).

Autorisations et droits utilisateur

Ajouter les comptes au groupe Utilisateurs du Bureau à distance.
Vérifier les stratégies locales :
- Stratégie de sécurité locale ▶ Attribution des droits utilisateur : « Autoriser l’ouverture d’une session par les Services Bureau à distance » et « Refuser l’ouverture d’une session par les Services Bureau à distance ».
- Verrouillage de compte (tentatives échouées) et exigences de mot de passe.

Journalisation utile pour le diagnostic

Observateur d’événements :
- Applications et services ▶ Microsoft ▶ Windows ▶ TerminalServices‑RemoteConnectionManager (événements de connexion, ex. 1149).
- Sécurité (échecs d’ouverture de session : événements 4625).
PowerShell (aperçu rapide) : powershell -c "Get-WinEvent -LogName 'Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational' -MaxEvents 50 | Select TimeCreated,Id,Message"

Erreurs voisines : décodeur rapide

Symptôme / Message	Cause probable	Action recommandée
« This computer can’t connect to the remote computer »	Port fermé, NLA/TLS incompatible, RDP désactivé	Tester port 3389, vérifier NLA, activer RDP, règles pare‑feu
« An authentication error has occurred »	CredSSP/TLS, horloge/domaine, NLA	Synchroniser l’heure, mettre à jour clients, ajuster NLA/TLS
Écran noir, déconnexion immédiate	Session bloquée, pilote GPU, politiques	Réinitialiser la session (`rwinsta`), MAJ pilote, tester /admin
Connexion via nom échoue, IP fonctionne	DNS/NetBIOS	Corriger enregistrement DNS, purger cache (`ipconfig /flushdns`)
Impossible depuis Internet, OK en LAN	NAT/CGNAT/FAI	Mettre en place VPN ou RD Gateway, revoir redirection de port

Scripts & commandes “prêtes à l’emploi”

Côté client

:: Test reachability & port
ping <NomOuIP>
powershell -c "Test-NetConnection <NomOuIP> -Port 3389"

:: Lancer RDP en mode admin (console)
mstsc /v: /admin

:: Forcer le nom d’utilisateur UPN
mstsc /v: /prompt

Côté serveur

:: Vérifier/relancer services RDP
sc query TermService
sc start TermService

:: Ouvrir les règles de pare-feu intégrées
powershell -c "Enable-NetFirewallRule -DisplayGroup 'Bureau à distance'"

:: Créer une règle pour port personnalisé
powershell -c "New-NetFirewallRule -Name 'RDP-3390' -Protocol TCP -LocalPort 3390 -Direction Inbound -Action Allow -Profile Any"

:: Voir sessions et réinitialiser
qwinsta
rwinsta 

:: Vérifier écoute du port
netstat -aon | findstr LISTENING | findstr :3389

Cas particuliers à connaître

Windows Home : ne peut pas recevoir une connexion RDP. Utiliser Windows Pro/Enterprise/Education ou Windows Server.
Nombre de sessions : Windows Pro limite à une session interactive. Utiliser /admin pour reprendre la console.
Horloge désalignée : un décalage de temps casse Kerberos/NTLM et la couche TLS. Synchroniser l’heure (NTP/AD).
Politiques EDR : après une mise à jour, certaines règles peuvent basculer en deny. Inspecter le journal de l’agent.

Bonnes pratiques sécurité (indispensables)

Évitez d’exposer 3389 sur Internet. Préférez un VPN ou une passerelle RD Gateway avec MFA.
Limiter par adresse source (liste blanche d’IP) au niveau pare‑feu.
Mots de passe forts et verrouillage de compte, journalisation activée, mises à jour régulières.
Réactiver NLA après vos tests. NLA empêche l’ouverture de session non authentifiée.

Checklist opérationnelle (à suivre pas à pas)

Confirmer que le PC distant est allumé et relié au réseau.
Tester IP puis nom DNS depuis le client.
Vérifier le port 3389 avec Test-NetConnection.
Contrôler RDP activé + utilisateur autorisé.
Ouvrir/valider les règles pare‑feu.
Redémarrer TermService si nécessaire.
Ajuster NLA/TLS (test temporaire sans NLA si besoin).
Si accès Internet : NAT, IP publique, éventuel CGNAT. Privilégier VPN/RD Gateway.
Analyser les journaux (RemoteConnectionManager, Sécurité).
En ultime recours : changer le port RDP et mettre à jour pare‑feu/NAT.

FAQ rapide

Q : Le ping répond mais RDP échoue.
R : Le port 3389 est probablement fermé ou NLA/TLS bloque la négociation. Vérifiez Test-NetConnection <IP> -Port 3389, les règles pare‑feu et la configuration NLA.

Q : IP OK, mais pas via nom.
R : Problème DNS. Purgez le cache (ipconfig /flushdns) et corrigez les enregistrements DNS/hosts.

Q : Puis-je me connecter à un Windows Home ?
R : Non, Windows Home ne reçoit pas les connexions RDP. Utilisez Windows Pro/Enterprise/Education/Server.

Q : Dois-je changer le port 3389 pour la sécurité ?
R : Ce n’est pas une protection suffisante, mais cela réduit le bruit. Si vous le faites, créez la règle pare‑feu correspondante et ajustez la redirection NAT, puis connectez‑vous à IP:NouveauPort.

Résumé

Le message « This computer can’t connect to the remote computer » est générique. En suivant la démarche ci‑dessus — accessibilité réseau, activation RDP, autorisations, pare‑feu, services, NLA/TLS, journaux — vous isolez rapidement la cause et restaurez l’accès de façon sécurisée. Conservez NLA activé et privilégiez VPN ou RD Gateway pour les accès distants exposés à Internet.

Annexes pratiques

Emplacements utiles

Registre (port RDP) : HKLM\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp\PortNumber
Journaux : Observateur d’événements ▶ Applications et services ▶ Microsoft ▶ Windows ▶ TerminalServices‑RemoteConnectionManager
Règles pare‑feu : Bureau à distance (TCP-In) profils Domaine/Privé/Public
Groupes : Utilisateurs du Bureau à distance

Mémo client macOS/iOS/Android

Utiliser l’application officielle Microsoft Remote Desktop.
Pour un port non standard : saisir hôte:port (ex. example.org:3390).
Vérifier que le réseau mobile/Wi‑Fi n’interdit pas le port 3389.

Bonnes pratiques d’entreprise

RD Gateway + MFA pour publier les accès RDP.
Journalisation centralisée des événements RDP et alerting sur échecs répétés.
Segmentation réseau (VLAN) et règles entrantes minimales (least privilege).
Durcissement TLS cohérent entre serveurs et clients, inventaire régulier des ciphers/protocoles.

En appliquant ces contrôles dans l’ordre, vous résoudrez la grande majorité des échecs « This computer can’t connect to the remote computer » et renforcerez la posture sécurité de vos postes Windows et serveurs.