Mode veille et bureau à distance : maintenir les machines éveillées

Vous tentez de vous connecter à une machine distante et elle ne répond pas — elle est en veille. Ce guide élimine les mythes et propose des schémas « keep‑awake » concrets qui fonctionnent réellement pour les flux de travail de bureau à distance : quand empêcher la mise en veille, quand compter sur Wake‑on‑LAN, et comment faire les deux en toute sécurité sur Windows, macOS et Linux.

Comment les états de veille perturbent l'accès à distance

Comprendre ce que « veille » signifie est la première étape. Il y a trois comportements courants : display‑off (écran éteint, CPU actif), suspend/S3 (RAM hors tension, CPU arrêté), et hibernation/S4 (contenu de la RAM sauvegardé sur disque et presque tout éteint). Si une machine est en S3 ou S4, elle n'acceptera pas une connexion entrante à moins d'être réveillée d'abord. Le simple display‑off permet généralement encore les connexions à distance, car le système d'exploitation et la pile réseau restent actifs.

Pour le bureau à distance, il vous faut soit : la machine reste réactive (pas de S3/S4), soit un moyen de la réveiller (Wake‑on‑LAN ou réveil programmé). Le choix dépend de la consommation d'énergie, du matériel et des exigences de sécurité.

Deux modèles pratiques : empêcher la mise en veille vs réveil à la demande

Il existe deux approches réalistes utilisées en production :

• Maintenir éveillé (empêcher la mise en veille) : la machine n'entre jamais en veille profonde tant que vous avez besoin d'accès distant. Simple, fiable et adapté aux postes dédiés ou aux sessions courtes. Inconvénients : consommation électrique plus élevée, usure possible, et nécessité de gérer les assertions entre redémarrages et mises à jour.
• Réveil à la demande (Wake‑on‑LAN / réveil programmé) : laissez la machine en veille et réveillez‑la à distance quand nécessaire. Économe en énergie et préféré pour des cibles peu utilisées ou des flottes géographiquement distribuées — mais nécessite du matériel compatible WOL, le support du routeur pour Wake‑on‑WAN, ou un service de relais capable d'envoyer des paquets magiques depuis l'extérieur du LAN.

D'après mon expérience : pour un poste de dev utilisé quotidiennement, maintenir l'éveil génère moins de friction. Pour des serveurs ou machines de labo rarement manipulés, WOL est le bon choix.

Recettes par OS : commandes concrètes utilisables

Ci‑dessous des commandes testées, indépendantes de la version, et des tactiques pour chaque OS. Ces exemples sont sûrs à copier‑coller ; lisez les remarques pour la permanence et les compromis de sécurité.

Windows (10 / 11)

Vérifications et commandes rapides :

powercfg /requests            # see what is currently preventing sleep
powercfg /devicequery wake_armed  # devices allowed to wake the PC
powercfg /lastwake            # why the PC last woke

Désactiver la mise en veille automatique sur secteur (maintient la machine éveillée lorsqu'elle est branchée) :

powercfg /change standby-timeout-ac 0
powercfg /change monitor-timeout-ac 10  # keep display off but system awake

Activer Wake‑on‑LAN :

• Ouvrez le Gestionnaire de périphériques → votre carte réseau → Gestion de l'alimentation et cochez Autoriser cet appareil à réveiller l'ordinateur et, facultativement, Autoriser uniquement un paquet magique à réveiller l'ordinateur.
• Vérifiez dans le BIOS/UEFI que Wake‑on‑LAN est activé.

Empêcher la mise en veille via un script (court terme) : utilisez une petite boucle PowerShell qui effectue une opération inoffensive périodiquement, ou créez une tâche planifiée qui s'exécute tant que vous avez besoin que la machine reste éveillée. Par exemple, un processus keep‑alive persistant qui tourne dans la session utilisateur :

while ($true) { Add-Type -AssemblyName System.Windows.Forms; [System.Windows.Forms.Cursor]::Position = [System.Drawing.Point]::new(0,0); Start-Sleep -Seconds 300 }

Cette technique est utile pour des sessions ponctuelles mais reste un bricolage — préférez configurer des plans d'alimentation de façon centrale pour des machines gérées.

macOS (Ventura et versions ultérieures)

macOS propose deux outils pragmatiques : pmset pour des modifications persistantes et caffeinate pour des assertions limitées à une session.

# prevent system sleep while on AC (persistent)
sudo pmset -c sleep 0

# keep the system awake temporarily for 1 hour
caffeinate -i -t 3600

Remarques : les changements pmset persistent après les redémarrages tant que vous ne les revenez pas. caffeinate est pratique pour des sessions distantes courtes ou des scripts d'encapsulation ; il ne change pas les valeurs par défaut du système. Si vous avez besoin que la machine reste éveillée avec le capot fermé, Apple n'autorise officiellement cela que pour des écrans externes ou du matériel spécifique — fermer le capot d'un portable met la plupart des modèles en veille sauf en modes clamshell approuvés.

Linux (distributions basées sur systemd)

Sur les Linux modernes, systemd-inhibit est l'outil pratique pour bloquer la mise en veille d'un processus en cours. Exemple :

# block sleep while a shell session runs
systemd-inhibit --why='remote desktop session' --mode=block bash -c 'while true; do sleep 60; done' &

Pour les environnements GNOME, vous pouvez ajuster les paramètres d'alimentation par session ou avec gsettings, par exemple :

gsettings set org.gnome.settings-daemon.plugins.power sleep-inactive-ac-type 'nothing'
# revert with: 'suspend' or another choice

Les changements au niveau système peuvent être gérés via /etc/systemd/logind.conf (HandleLidSwitch=ignore) ou via les profils d'alimentation du bureau, mais ces modifications requièrent de la prudence — changer le comportement du lid‑switch affecte la sécurité physique et les limites thermiques.

Wake‑on‑LAN et considérations réseau

WOL envoie un paquet magique à une carte réseau pour réveiller la machine. Deux problèmes courants le bloquent : le BIOS/UEFI non activé et les équipements réseau qui perdent l'état ARP après la mise en veille de la machine.

• Activez WOL dans le BIOS/UEFI et dans les paramètres de l'adaptateur réseau de l'OS.
• Sous Windows, confirmez avec

  powercfg -devicequery wake_armed

  .
• Testez l'envoi d'un paquet magique localement avec wakeonlan MAC sous Linux ou avec des outils comme wolcmd sous Windows.

Wake‑on‑WAN (réveil via Internet) ajoute de la complexité côté routeur ou relais : soit vous faites du port‑forward UDP vers l'adresse de broadcast (non supporté par tous les routeurs), soit vous utilisez un appareil persistant dans le LAN cible pour retransmettre un paquet magique local, soit vous utilisez un service cloud/de relais capable d'envoyer le paquet depuis l'extérieur du réseau.

Si Wake‑on‑WAN est nécessaire, lisez notre guide d'installation détaillé : Remote Desktop Wake on LAN: Setup and Troubleshooting. Pour les cas où le port‑forwarding n'est pas souhaitable, consultez Remote Desktop Without Port Forwarding Explained pour des modèles alternatifs.

Utiliser Tenvo : relais géré vs auto‑hébergement, et compromis de sécurité

Opérationnellement, l'option la plus simple est d'utiliser le relais géré de Tenvo. Tenvo fournit des clients natifs pour Windows, macOS et Linux, un client navigateur en bêta publique, et un relais géré multi‑région par défaut. Les formules sont Free $0, Lite $2.99/mo et Pro $7.99/mo. Le relais géré évite la configuration de Wake‑on‑WAN compliquée et la nécessité d'assurer la disponibilité de vos propres nœuds relais.

Remarque honnête sur la sécurité : Tenvo utilise TLS avec un certificat par appareil. Lorsque deux points se connectent directement (peer‑to‑peer), TLS est de bout en bout entre ces appareils. Mais lorsqu'une session bascule sur un relais, TLS se termine au relais — l'opérateur du relais peut accéder aux données de session. Si la politique de votre organisation interdit les relais tiers, l'auto‑hébergement n'est justifié que si une exigence écrite l'impose (conformité, réseaux isolés, résidence des données). L'auto‑hébergement transfère la charge de la mise à jour, de la garde des clés et du renouvellement des certificats sur vous et peut coûter plus cher une fois le temps d'astreinte pris en compte. Voir Is Remote Desktop Secure? An Honest Threat Model pour comprendre les compromis en détail.

Si vous voulez garder les machines en veille tout en vous connectant de manière fiable sans exposer WOL sur Internet, le relais géré de Tenvo peut être utilisé pour délivrer des signaux de réveil depuis le cloud vers votre LAN si vous exécutez un petit relais ou une passerelle de confiance à l'intérieur du réseau. C'est un compromis pratique par rapport à l'ouverture des ports du routeur.

Dépannage : que vérifier lorsque la mise en veille bloque toujours l'accès à distance

Liste de contrôle pour diagnostiquer des cibles injoignables :

• La machine est‑elle réellement en veille ? Consultez le temps d'activité ou les journaux du dernier réveil : Windows powercfg -lastwake, Linux journalctl -b | grep -i wake, macOS pmset -g log.
• Si elle se met en veille immédiatement après votre départ, cherchez des assertions d'alimentation conflictuelles : Windows powercfg /requests.
• Pour WOL, confirmez que la NIC prend en charge le réveil uniquement via paquet magique et que la gestion d'alimentation du périphérique permet le réveil.
• Pour Wake‑on‑WAN, vérifiez le comportement ARP/redirection de port du routeur ; de nombreux routeurs SOHO ignorent les broadcasts depuis le WAN. Un petit helper interne persistant (Raspberry Pi) qui accepte une requête authentifiée et envoie un paquet magique local est un modèle robuste.

Conseils de surveillance et d'automatisation : ajoutez un processus léger de heartbeat qui enregistre la dernière activité de la machine dans un point central (syslog, Influx, ou une URL interne de healthcheck). Pour des flottes, utilisez la gestion de configuration pour appliquer des profils d'alimentation cohérents plutôt que de dépendre de scripts par machine.

Quand choisir chaque approche — guide de décision rapide

• Poste de travail interactif utilisé quotidiennement : empêcher la mise en veille (plan d'alimentation au niveau système ou caffeinate) pour pouvoir se reconnecter instantanément.
• Serveur de labo peu utilisé : utilisez Wake‑on‑LAN avec un forwarder local ; évitez de laisser des milliers de machines éveillées.
• Utilisateurs distants répartis sans contrôle réseau central : reposez‑vous sur un relais géré (Tenvo) et maintenez éveillées les machines critiques ; auto‑hébergez uniquement si une exigence de conformité écrite l'impose.

Pour une liste de configuration plus large et une configuration initiale, voir How to Set Up Remote Access in 60 Seconds.

En conclusion : il n'y a pas de solution universelle. Les schémas de maintien éveillé sont simples et fiables pour les machines que vous utilisez fréquemment. Wake‑on‑LAN est le choix économe en énergie lorsque le matériel et le réseau le permettent. Et si vous voulez l'option multi‑réseau nécessitant le moins d'effort, le relais géré de Tenvo vous permet de travailler de façon fiable — avec les compromis décrits ci‑dessus.

Si vous voulez une référence copiable : utilisez les commandes Windows et macOS ci‑dessus pour des sessions courtes, configurez WOL dans le BIOS et l'OS pour le réveil sans surveillance, et ajoutez un petit relais interne ou utilisez le relais géré de Tenvo pour les scénarios Wake‑on‑WAN. Téléchargez les clients Tenvo et commencez depuis /download.