Le Bureau à distance peut échouer juste après une mise à niveau de Windows 10, car les mises à jour n’ajoutent pas seulement des fonctionnalités, elles peuvent discrètement réinitialiser ou réinterpréter des hypothèses de sécurité et de réseau dont dépend la pile RDP. Une machine qui acceptait des connexions hier peut soudainement cesser de le faire parce que l’autorisation de l’hôte a été désactivée, la règle du pare-feu ne correspond plus au profil réseau actif, le service RDP est en cours d’exécution mais ne se lie pas correctement à l’écouteur, ou une modification de stratégie/du Registre a changé le port. Parfois, l’hôte est en bon état et la panne se situe côté client, où des modifications de transport après mise à jour (notamment le comportement UDP) peuvent rendre les sessions instables ou sembler “ne pas se connecter”.
Cet article explique ces causes déclenchées par des mises à jour en des termes simples et décrit une démarche de correction pratique qui reflète ce que les administrateurs et les utilisateurs rapportent fonctionner : confirmez que l’hôte est autorisé à accepter les connexions RDP, utilisez un logiciel de bureau à distance alternatif comme HelpWire, assurez-vous que le pare-feu l’autorise réellement sur le bon profil, vérifiez que les services et l’écouteur sont en bon état, vérifiez la configuration du port, traitez les particularités de transport côté client, et seulement ensuite envisagez de revenir sur une mise à jour problématique.
Solution 1: Réactiver les connexions Bureau à distance
Les mises à niveau de Windows désactivent parfois le paramètre Bureau à distance côté hôte. C’est la panne post-mise à niveau la plus fréquente et, s’il est désactivé, rien d’autre n’y fera. Le réactiver restaure l’autorisation du système d’exploitation d’accepter les sessions RDP entrantes et rétablit généralement l’écoute.
Dans un fil de discussion Microsoft Q&A sur les problèmes RDP après Windows 10 21H1 largement commenté, un administrateur a noté qu’après avoir dépanné des problèmes de service et de pare-feu, il a découvert que “l’accès au Bureau à distance était désactivé dans l’onglet Distant de la fenêtre sysdm.cpl” même s’il ne l’avait pas modifié manuellement, la mise à jour l’avait simplement désactivé.
Utilisez ceci en premier si : RDP fonctionnait avant la mise à niveau et échoue maintenant immédiatement, vous n’avez rien modifié manuellement, ou l’hôte n’est pas à l’écoute sur 3389 parce que RDP est désactivé.
Étapes:
Appuyez sur Windows + R
Tapez
sysdm.cpl→ Entrée
Accédez à l’onglet Remote
Sélectionnez Autoriser les connexions à distance à cet ordinateur
Cliquez sur OK
Solution 2: Configurer le Pare-feu Windows pour autoriser RDP
Même lorsque le Bureau à distance est activé, le Pare-feu Windows peut le bloquer après une mise à niveau, en particulier si le profil réseau change (comme Privé → Public). Les règles entrantes intégrées pour le Bureau à distance contrôlent le trafic vers le port RDP, et les mises à jour peuvent réinitialiser l’état d’activation de ces règles ou les profils auxquels elles s’appliquent.
Le même administrateur Microsoft Q&A a mentionné que “après avoir publié ceci, j’ai eu des machines où, bien que ce paramètre dans sysdm.cpl n’ait pas été modifié et soit toujours correctement défini, les paramètres Bureau à distance dans le Pare-feu Windows avaient été désélectionnés et devaient être cochés à nouveau”.
À utiliser si : l’hôte est joignable mais la connexion RDP expire, le réseau est désormais marqué Public, ou des stratégies de domaine pourraient modifier le comportement du pare-feu.
Étapes:
Recherchez le Pare-feu Windows Defender avec fonctions avancées de sécurité (ou exécutez
wf.msc)
Dans le volet gauche, cliquez sur Règles de trafic entrant
Filtrez ou faites défiler pour trouver la règle prédéfinie nommée Remote Desktop (TCP-In)
Vérifiez les éléments suivants:
• Activée: La règle doit être activée (icône verte)
• Protocole: TCP
• Port local: 3389 (ou votre port personnalisé)
• Profils: La règle doit être autorisée pour le profil réseau actuellement utilisé par le PC (Domaine, Privé, etc.)
Solution 3 : Vérifier et redémarrer les services RDP
Si le Bureau à distance est activé et que les règles du pare-feu semblent correctes, RDP peut quand même échouer lorsque la couche de service reste bloquée dans un état de limbes post-mise à niveau. Les Services Bureau à distance (TermService) gèrent les sessions et l’écouteur, et des mises à jour peuvent le laisser “en cours d’exécution” sans se lier correctement au port 3389.
Dans la même discussion Microsoft Q&A, des administrateurs ont signalé des cas où “netstat -ano sur le poste impacté indique que RDP n’écoute pas sur le port 3389” alors que services.msc indiquait que les Services Bureau à distance étaient en cours d’exécution. La solution a consisté à forcer l’arrêt de TermService.exe et à le laisser redémarrer, après quoi “Le service ‘Remote Desktop Service’ écoute désormais sur le port 3389 et les utilisateurs peuvent se connecter à distance à leur ordinateur”.
À utiliser si : netstat n’affiche aucun écouteur sur le port 3389, RDP tombe en panne par intermittence au fil des redémarrages, ou le service indique “En cours d’exécution” mais l’hôte refuse toujours les connexions.
Étapes:
Appuyez sur Windows + R → tapez
services.msc
Rechercher les Services Bureau à distance
Clic droit → Propriétés
Confirmer et corriger :
• Type de démarrage : Définissez-le sur Automatique
• État : Cliquez sur Démarrer s’il n’est pas en cours d’exécution actuellementCliquez sur OK
Si vous avez apporté des modifications, redémarrez la machine hôte
Solution 4 : Activer le "Remote Desktop Services UserMode Port Redirector" service
Dans des environnements renforcés ou fortement gérés, les lignes de base de sécurité peuvent désactiver ce service et déstabiliser la pile RDP. Il prend en charge les fonctionnalités de redirection RDP et aide le sous-système à se comporter normalement ; lorsqu’il est désactivé, vous pouvez observer le symptôme classique après mise à niveau où l’hôte n’écoute pas sur le port 3389 même si TermService paraît correct.
À utiliser si : vous êtes sur une image d’entreprise/renforcée ou si la machine a récemment été affectée par des audits de sécurité ou des scripts de verrouillage.
Étapes:
Ouvrez
services.mscLocalisez Remote Desktop Services UserMode Port Redirector
Clic droit → Propriétés
Si désactivé, passez à Manuel ou Automatique
Cliquez sur Démarrer si disponible
Redémarrez les Services Bureau à distance (Solution 3) pour que les modifications prennent effet
Solution 5 : Vérifier les paramètres du Registre pour le port RDP
Si le port RDP change, le client continuera d’essayer 3389 et échouera même si tout le reste peut sembler correct. L’écouteur RDP lit son port dans le Registre, et des mises à niveau, des stratégies ou un durcissement antérieur peuvent le modifier discrètement.
Les répondants de Microsoft Q&A recommandent spécifiquement de vérifier la valeur de Registre PortNumber et la rétablir à 3389 si nécessaire, puis de redémarrer les Services Bureau à distance.
À utiliser si : votre organisation renforce la sécurité de RDP en abandonnant le 3389, ou vous soupçonnez qu’une dérive des stratégies ou d’anciennes modifications de sécurité ont altéré la configuration de l’écouteur.
Étapes:
Exécutez
regeditAccédez à :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-TcpOuvrir PortNumber
Confirmez 3389 (décimal) sauf si votre organisation utilise un port personnalisé
Redémarrer (recommandé après toute modification de port)
Solution 6 : Vider le cache DNS
Après une mise à niveau ou un changement de réseau, RDP peut échouer simplement parce que votre client résout le nom d’hôte en une ancienne adresse IP. Vider le cache DNS efface les entrées locales obsolètes et force une nouvelle résolution de noms, ce qui peut corriger immédiatement les cas où l’hôte est joignable mais où le nom pointe vers une adresse obsolète.
À utiliser si : RDP échoue avec le nom d’hôte mais fonctionne avec l’adresse IP, ou si vous avez récemment renommé le PC ou changé d’adaptateurs réseau.
Étapes:
Ouvrez Windows Terminal (Admin)
Exécutez :
ipconfig /flushdns
Solution 7: Désactiver le pilote graphique WDDM pour les connexions à distance
Ce n’est pas un correctif classique de type “impossible de se connecter”, c’est un correctif de stabilité après connexion qui peut ressembler à un échec de connexion, surtout lorsque des mises à jour perturbent les pilotes GPU. La désactivation de WDDM force RDP à utiliser un chemin de rendu plus compatible, ce qui peut éviter des écrans noirs ou des déconnexions instantanées juste après l’authentification.
Utilisez ceci si : vous obtenez un écran noir immédiatement après la connexion, vous êtes déconnecté juste après l’authentification, ou la machine utilise des pilotes GPU complexes ou des charges de travail gourmandes en ressources graphiques.
Étapes:
Exécutez
gpedit.mscAccédez à : Configuration ordinateur → Modèles d’administration → Composants Windows → Services Bureau à distance → Hôte de session Bureau à distance → Environnement de session à distance
Ouvrir: Utiliser le pilote d’affichage graphique WDDM pour les connexions Bureau à distance
Définir sur Désactivé
Redémarrer
Solution 8: Utilisez le client du Microsoft Store / Windows App comme solution de contournement
Parfois, le client RDP intégré se comporte mal après des mises à jour, même lorsque l’hôte est sain. Parce que différents clients officiels peuvent s’appuyer sur des composants et des cadences de mise à jour légèrement différents, passer au client du Microsoft Store/Windows App peut contourner une régression spécifique au client.
Dans des discussions sur les problèmes RDP de Windows 11 24H2, un utilisateur a noté : “Cela se produit 100 % du temps avec le client RDP normal. Et cela n’arrive généralement pas avec le client Bureau à distance du Windows Store.”
Utilisez ceci si : l’hôte est sain et à l’écoute sur 3389, ou plusieurs utilisateurs signalent qu’un client fonctionne tandis qu’un autre ne fonctionne pas.
Solution 9: Rechercher et désinstaller les mises à jour problématiques
Lorsque RDP tombe en panne immédiatement après une mise à jour cumulative spécifique, la désinstaller peut être le moyen le plus rapide de rétablir la situation. Les mises à jour introduisent parfois des régressions temporaires qui perturbent la chaîne RDP, les services, le réseau ou l’authentification.
Des rapports récents du terrain appuient cette approche. Dans une discussion Microsoft Q&A d’octobre 2025, plusieurs utilisateurs ont signalé des problèmes RDP après l’installation des mises à jour KB5066835 et KB5066131, l’un d’eux indiquant “nous avons désinstallé la mise à jour KB5066835, ce qui a résolu les problèmes RDP.” De plus, des administrateurs gérant Windows 11 24H2 ont rapporté avoir réussi à supprimer des mises à jour cumulatives récentes lorsque les défaillances RDP coïncidaient précisément avec les dates d’installation des correctifs.
À utiliser si : vous avez un schéma clair “fonctionnait hier, en panne aujourd’hui” ou vous pouvez corréler la panne avec une mise à jour récemment installée.
Étapes:
Paramètres → Windows Update
Voir l’historique des mises à jour
Désinstaller les mises à jour
Supprimez la mise à jour suspecte la plus récente
Redémarrer
Solution 10 : Solution alternative de bureau à distance : HelpWire
Si RDP fonctionne mal après une mise à niveau de Windows 10, HelpWire peut constituer une solution de repli pratique pendant que vous dépannez. Il offre un accès sécurisé, assisté et non assisté, et peut vous aider à rester productif même lorsque RDP est bloqué, instable ou présente des problèmes post-mise à jour comme des écrans noirs. Avec la prise en charge de Windows, macOS et Linux, une configuration non assistée simple et des sessions “send-a-link” rapides, il fonctionne bien comme solution temporaire de contournement ou comme option d’accès à distance parallèle jusqu’à ce que votre configuration RDP soit entièrement stable.
Conclusion
Dans la plupart des cas après mise à niveau, le Bureau à distance n’est pas tant « cassé » que réinitialisé : une option de l’hôte désactivée, une incompatibilité de profil de pare-feu, un service qui s’exécute mais n’écoute pas, ou un changement de port/transport introduit par une stratégie ou par la mise à jour elle-même. Appliquez les correctifs dans l’ordre et vous rétablirez généralement le RDP sans tâtonner. Et si vous avez besoin d’un accès immédiat pendant que vous stabilisez la pile, une solution de repli comme HelpWire peut vous maintenir connecté.
