Bureau contre écran de connexion : ce que coûte une session utilisateur
Sur cette page
Réponse courte
Section intitulée « Réponse courte »Un bureau connecté coûte plus cher qu’un écran de connexion, mais bien moins qu’il n’y paraît : en veille stationnaire, il occupe environ 0.012 cœur contre 0.0074 sur l’écran de connexion, soit 1.6 fois plus. Le vrai coût d’une session utilisateur, c’est la première heure après la connexion : l’analyse Defender et la vague de mises à jour Store consomment ensemble environ 79% de toute l’activité CPU d’une fenêtre de cinq heures. L’interface elle-même est presque gratuite : explorer, sihost, dwm et le flux du menu Démarrer dépensent ensemble environ 2.3% du budget.
Statut : mesuré lors d’une seule exécution de 5 heures sur Windows 11 26H2 dans une machine virtuelle. La comparaison avec l’écran de connexion a été faite sur la même build et le même instantané. Le transfert vers du matériel physique, d’autres builds et des fenêtres nocturnes n’a pas été vérifié.
Affirmation vérifiable
Section intitulée « Affirmation vérifiable »Nous avons vérifié quatre affirmations :
- Un bureau connecté coûte nettement plus cher qu’un écran de connexion au repos.
- Le coût principal de la session est le fonctionnement permanent de l’interface.
- La session utilisateur modifie sensiblement le profil réseau au repos.
- Les mécanismes planifiés de Windows (mises à jour, minuteries de service) se comportent en session comme sans elle.
Périmètre de l’étude
Section intitulée « Périmètre de l’étude »- Windows 11 Pro, build 26300.9457 (26H2), machine virtuelle 4 vCPU / 8 Go ;
- installation propre sans logiciel tiers ; la veille et les mises à jour de configuration n’ont pas été désactivées ;
- deux exécutions sur le même instantané : écran de connexion sans session utilisateur (6 heures) et bureau connecté (4 heures 46 minutes, arrêté prématurément) ;
- connexion effectuée manuellement ; l’observation a commencé après confirmation du démarrage de l’interface ;
- instantanés à la minute : CPU des processus, ensembles de services actifs, mémoire et connexions établies.
Les mesures n’incluaient pas le matériel physique, le travail réel sur l’ordinateur, la charge GPU et les fenêtres nocturnes (les tâches de maintenance quotidiennes ne sont pas entrées dans le cadre).
Méthodologie
Section intitulée « Méthodologie »Pour chaque processus, les secondes CPU cumulées étaient enregistrées une fois par minute ; la différence entre instantanés voisins donne la consommation sur l’intervalle. Les services étaient suivis par ensembles d’instances actives et par transitions ; le réseau, par les connexions établies au moment de l’instantané. Le bruit de notre propre surveillance (environ 3.6% CPU) est exclu de l’interprétation. Les deux exécutions ont été comparées sur des valeurs normalisées à l’heure.
Résultats
Section intitulée « Résultats »Comparaison synthétique
Section intitulée « Comparaison synthétique »| Métrique | Écran de connexion | Bureau | Écart |
|---|---|---|---|
| CPU en moyenne sur la fenêtre, cœurs | 0.0098 | 0.0492 | ×5.0 |
| CPU d’une heure stationnaire, cœurs | 0.0074 | 0.0120 | ×1.61 |
| CPU de la première heure après connexion/démarrage, cœurs | 0.0185 | 0.2942 | ×15.9 |
| Lancements de processus système par heure | 26.1 | 79.5 | ×3.05 |
| Minutes avec activité supérieure à 1 CPU-s | 5% | 13.5% | ×2.4 en part |
| Connexions établies par heure (minutes-endpoints) | 88.3 | 228.1 | ×2.58 |
| Connexions permanentes | 1 | 3 | ×3 |
Fait clé : le chiffre moyen « ×5 » se compose presque entièrement de la première heure. Les heures stationnaires du bureau sont homogènes (0.0118–0.0127 cœur) et ne dérivent pas.
Première heure : deux vagues
Section intitulée « Première heure : deux vagues »| Vague | Part | Ce qui se passait |
|---|---|---|
| Analyse de connexion Defender | ~55% CPU de l’heure | Le processus antivirus a fonctionné environ 0.7 cœur pendant 8 minutes d’affilée ; l’analyse a commencé immédiatement après la connexion |
| Mise à jour Store et USO | ~27% CPU de l’heure | Installation de 24 applications, téléchargement d’environ 880 Mo via Delivery Optimization, y compris le peering |
La vague Store est importante à part : dans cette exécution, les mises à jour sont arrivées via Microsoft Store et Delivery Optimization, et non via le Windows Update classique. Le pic réseau à la connexion est 67 fois supérieur au niveau stationnaire.
Veille stationnaire : qui travaille
Section intitulée « Veille stationnaire : qui travaille »| Source | Secondes CPU par heure | Commentaire |
|---|---|---|
| Enveloppe svchost globale | 13–14 | Minuteries des services |
| Noyau (System) | 8 | Une partie du travail de Defender et de l’infrastructure |
| Antivirus hors analyse | ~3 | Vérifications périodiques |
| Interface (explorer, sihost, dwm, flux du menu Démarrer, recherche, widgets, OneDrive) | 4.1 | 2.3% du budget ; le « repos du bureau » est presque gratuit |
Trois quarts de l’écart dans les lancements de processus proviennent des mécanismes périodiques de la session utilisateur : l’hôte d’arrière-plan des tâches UWP (cycle d’environ 13 minutes), RuntimeBroker et SoftLanding toutes les 15 minutes.
Réseau : trois connexions permanentes et deux nouvelles minuteries
Section intitulée « Réseau : trois connexions permanentes et deux nouvelles minuteries »Sur l’écran de connexion, une seule connexion permanente subsiste. Sur le bureau, il y en a trois : deux sont maintenues par le flux du menu Démarrer (contenu MSN : météo, actualités, tuiles dynamiques) dès la première minute et sans interruption, la troisième par un service système de notifications. Le coût CPU du flux sur toute la fenêtre est inférieur à 2 secondes CPU, mais la connexion elle-même subsiste toujours.
Nouvelles minuteries de session : OneDrive se synchronise toutes les 32–33 minutes via deux connexions, les mises à jour Edge sont vérifiées toutes les quelques heures. Les vérifications de signatures Defender se font par grappes toutes les 30–40 minutes. Tout le trafic est dirigé vers l’infrastructure Microsoft ; aucune connexion étrangère n’a été observée.
Minuteries de service
Section intitulée « Minuteries de service »La mise à jour des stratégies de groupe sur le bureau boucle toutes les 16–17 minutes contre environ 80 minutes sur l’écran de connexion. Le service d’applications (AppXSvc) et la protection des licences (sppsvc) ont conservé le même rythme. Cinq services de session subsistent en permanence, notamment les notifications utilisateur et Clipboard.
Aucune fuite système : l’antivirus a libéré 81 Mo après l’analyse, l’interface n’a augmenté que durant les 30 premières minutes puis a atteint un plateau. Le nombre de processus est de 130–153 contre 84–98 sur l’écran de connexion.
Ce qui est confirmé
Section intitulée « Ce qui est confirmé »- Mesuré : un bureau stationnaire coûte 1.61 fois plus cher qu’un écran de connexion en CPU ; la première heure après la connexion est le coût principal de la session (79% du CPU de la fenêtre).
- Mesuré : le flux du menu Démarrer maintient deux connexions permanentes durant toute la session ; OneDrive se synchronise toutes les 32–33 minutes.
- Mesuré : la vague Store à la connexion a téléchargé environ 880 Mo via Delivery Optimization ; le pic réseau à la connexion est 67 fois supérieur au niveau stationnaire.
- Mesuré : l’interface (explorer, dwm, flux du menu Démarrer, recherche, widgets) en veille stationnaire dépense environ 2.3% de CPU.
- Observé : les mises à jour sont arrivées via Store/DO, et non via le WU classique ; les tâches de maintenance nocturnes ne sont pas entrées dans le cadre.
Ce qui n’est pas confirmé
Section intitulée « Ce qui n’est pas confirmé »- Le comportement sur du matériel physique et sur d’autres builds de Windows.
- Les fenêtres nocturnes et les tâches de maintenance quotidiennes (l’exécution est diurne, arrêtée prématurément).
- L’effet de la désactivation du flux du menu Démarrer ou de OneDrive sur ces chiffres : nous avons seulement mesuré leur contribution, la désactivation n’a pas été testée.
- L’effet sur les FPS et la performance finale en jeu : non mesuré.
Une exécution par état, machine virtuelle, fenêtre diurne. Le travail d’arrière-plan de Windows arrive par pics, donc transférer les valeurs absolues à un autre matériel et à un cycle complet n’est pas justifié. Les processus de moins d’une minute et le trafic UDP (DNS, NTP) ne sont pas entièrement visibles. Une partie des journaux n’enregistrait pas les événements durant la seconde exécution ; les transitions de services ont été reconstituées à partir des instantanés.
Conclusion pratique
Section intitulée « Conclusion pratique »Le « bruit d’arrière-plan de Windows » se décompose en trois choses différentes, et il faut les traiter différemment. Les vagues post-connexion (analyse Defender et mises à jour Store) fournissent la majeure partie du CPU — elles ne se désactivent pas par des réglages fins, mais elles se terminent d’elles-mêmes. Les métronomes système (polling WMI, vérifications de licence, minuterie OneDrive) forment un fond stable mais faible. L’interface est presque gratuite.
Conséquences pratiques : ne mesurez pas une « optimisation » sur la première heure après la connexion si vous n’isolez pas les vagues ; pour minimiser le réseau, désactivez le flux du menu Démarrer et OneDrive s’ils ne sont pas nécessaires ; attendre le « silence » juste après la connexion n’est pas justifié.
Restauration de l’état
Section intitulée « Restauration de l’état »Le système n’a pas été modifié : les deux exécutions sont une pure observation sans modification des réglages, des services ni du registre. La machine virtuelle a été ramenée à un instantané propre après les mesures.
Sources et limites
Section intitulée « Sources et limites »Les mesures ont été réalisées par BoosterX Research sur la machine virtuelle décrite. L’étude appartient au développeur de BoosterX, le développeur a un intérêt direct dans le résultat ; la méthodologie et les limites sont décrites ci-dessus, les observations initiales peuvent être reproduites selon la méthodologie ouverte.
- Microsoft: Delivery Optimization, vérifié le 2026-09-22.
- Microsoft: Connected User Experiences and Telemetry, vérifié le 2026-09-22.
Dernière vérification : 2026-09-22.
