Terminal Services, rebaptisé Remote Desktop Services (RDS) depuis Windows Server 2008, reste un terme que j’entends encore régulièrement chez des clients qui ont appris le vocabulaire il y a quinze ans et ne l’ont jamais mis à jour. Le principe de base n’a pas changé : permettre à plusieurs utilisateurs de se connecter à distance à un même serveur, chacun avec sa propre session.
Le vocabulaire qui prête à confusion
Au-delà du nom historique, je constate une confusion fréquente entre RDS et le Bureau à distance simple (Remote Desktop, activable sur une machine individuelle sans rôle serveur). Le Bureau à distance simple permet à un seul utilisateur de se connecter à distance à SON poste, avec sa propre session ; RDS permet à PLUSIEURS utilisateurs de se connecter simultanément à un SERVEUR partagé, chacun avec une session distincte. Confondre les deux mène à des attentes irréalistes — un client qui demande « d’activer le bureau à distance » pour cinq personnes simultanément sur un simple poste Windows se heurte à une limitation technique du système qui n’autorise qu’une session active à la fois sur cette configuration, RDS étant précisément la réponse à ce besoin de multi-session.
Pourquoi une PME en aurait besoin
Le cas le plus fréquent que je rencontre : une application métier ancienne, encore indispensable, qui ne fonctionne correctement que sur un poste Windows spécifique ou avec des dépendances complexes à installer partout. Plutôt que de dupliquer cette configuration sur chaque poste, RDS centralise l’application sur un serveur unique, accessible en session distante depuis n’importe quel poste léger.
Installation sur Windows Server
Sur Windows Server 2022, le rôle s’installe via PowerShell :
Install-WindowsFeature -Name RDS-RD-Server -IncludeManagementTools
Install-WindowsFeature -Name RDS-Licensing -IncludeManagementToolsLe point que beaucoup de PME sous-estiment, et qui a un impact financier direct : RDS nécessite des CAL (Client Access Licenses) RDS distinctes des CAL Windows Server classiques, en plus de la licence du serveur lui-même. Ce n’est pas une option facultative — sans ces licences, le service fonctionne en période de grâce de 120 jours puis cesse d’accepter de nouvelles connexions.
Le cas rencontré
Une PME de Rennes m’a signalé que ses sessions RDS devenaient de plus en plus lentes à mesure que le nombre d’utilisateurs simultanés augmentait, jusqu’à huit ou neuf personnes en même temps. Le serveur, dimensionné à l’origine pour trois ou quatre sessions, manquait simplement de RAM : chaque session RDS consomme une part significative de mémoire pour son propre environnement graphique, en plus de l’application elle-même.
Le diagnostic s’est fait via le Moniteur de ressources (resmon.exe), qui a confirmé une saturation mémoire aux heures de pointe. La solution n’était pas d’optimiser l’application — elle fonctionnait normalement — mais d’ajouter de la RAM physique au serveur, un correctif simple une fois le vrai goulot d’étranglement identifié plutôt que le supposé.
Alternative à considérer
Pour une petite structure qui démarre ce type de besoin, RDS via Azure Virtual Desktop ou une solution cloud équivalente mérite d’être évaluée avant d’investir dans un serveur physique dédié : le coût initial est plus prévisible, et le dimensionnement peut évoluer sans changement de matériel. Ce n’est pas systématiquement le bon choix — la latence réseau peut poser problème pour des applications très interactives — mais ça mérite d’être chiffré en parallèle d’une solution locale.
Sécurité : un point non négociable
Attention, beaucoup se trompent en exposant directement le port RDP (3389) sur internet pour permettre l’accès distant. C’est une des surfaces d’attaque les plus exploitées par les campagnes automatisées de force brute. La bonne pratique est un accès via VPN d’abord, RDP ensuite, jamais RDP directement exposé — je le répète à chaque audit où je le trouve, et je le trouve encore régulièrement.
Dimensionnement : la règle empirique que j’utilise
Faute de chiffrage officiel unique de Microsoft applicable à tous les contextes, je pars d’une règle empirique construite sur mes propres déploiements : compter environ 1 Go de RAM par session utilisateur active pour un usage bureautique standard, davantage si l’application métier hébergée est elle-même gourmande. Pour dix utilisateurs simultanés avec une application de gestion commerciale classique, ça place la barre autour de 16 à 24 Go de RAM pour le serveur, en plus de la RAM nécessaire au système lui-même. Ce chiffre reste une base de départ à ajuster après une période d’observation réelle, pas une valeur figée à appliquer aveuglément.
Le cas des sessions qui ne se ferment jamais
Un problème classique en PME : des sessions RDS qui restent ouvertes en arrière-plan après que l’utilisateur a fermé sa fenêtre de connexion sans se déconnecter proprement, continuant à consommer des ressources indéfiniment. Configurer une limite de temps d’inactivité avant déconnexion automatique évite cette accumulation :
Set-RDSessionCollectionConfiguration -CollectionName "NomCollection" -DisconnectedSessionLimitMin 60Sur le cas cité plus haut, ce réglage seul a récupéré suffisamment de mémoire pour repousser de plusieurs mois le besoin d’ajout de RAM physique, le temps de budgétiser la mise à niveau matérielle correctement plutôt que dans l’urgence.
À retenir pour votre projet
RDS reste une solution pertinente pour centraliser des applications anciennes en PME, à condition de budgétiser les CAL dès le départ, de dimensionner la RAM en fonction du nombre réel d’utilisateurs simultanés, et de ne jamais exposer RDP directement sur internet.
Un dernier point sur la maintenance
Un serveur RDS centralisant une application critique devient, par construction, un point de défaillance unique pour l’ensemble des utilisateurs connectés. Ça justifie une politique de sauvegarde et de redémarrage planifié plus stricte que pour un poste individuel : une panne sur ce serveur immobilise tout le monde en même temps, contrairement à une panne sur un poste isolé qui n’affecte qu’une personne. Cette centralisation est précisément ce qui rend RDS utile au quotidien, mais elle demande une vigilance de maintenance proportionnée à cet enjeu.
Pour aller plus loin
Pour une référence externe, consultez les recommandations de l’ANSSI sur la sécurisation des accès distants.