Windows 11 pour des machines de build: le mauvais outil

Des machines de build bare-metal, automatisées, posées dans une salle serveur sans écran ni clavier et dessus Windows 11 édition client. Sur le papier ça marche, dans la durée ça coûte et ce billet est le détail de ce que ça coûte, parce que chaque friction prise isolément a l’air surmontable et que c’est leur addition, répétée à chaque feature update, qui finit par faire le vrai prix. La conclusion tient en une phrase: pour une machine de build qui a besoin d’une session graphique, Windows Server avec Desktop Experience fait exactement le même travail sans aucune de ces frictions et Windows 11 devrait rester sur les postes où un humain s’assoit devant la machine, l’usage pour lequel Microsoft l’a conçu.

Le provisioning se bat contre l’OS

Windows 11 télécharge et installe des mises à jour pendant et après l’OOBE, reboots non sollicités compris, ce qui entre directement en collision avec l’automatisation post-install, un playbook qui tourne et une machine qui disparaît en plein milieu. Les éditions Server diffèrent les mises à jour par défaut et attendent une policy. À cela s’ajoutent les contrôles matériels, TPM 2.0, Secure Boot et génération de CPU, que Windows 11 impose et qu’un environnement PXE n’expose pas, d’où les clés de registre de bypass à injecter au moment de l’install, chacune un point de défaillance et une surface de test de plus par génération de matériel. Et l’OOBE grand public, comptes Microsoft, Copilot, télémétrie, écrans de confidentialité, qu’il faut supprimer un par un dans l’unattend, lequel enfle en conditionnels propres à Windows 11 qu’une simple feature update, 24H2, 25H2, peut casser sans prévenir en ajoutant un écran. Server a un OOBE minimal et pensé pour l’automatisation et aucune de ces exigences matérielles.

SSH, Ansible et une dette de transport

C’est ici que ça se corse et il faut nommer la cause de fond: le transport natif et recommandé d’Ansible pour Windows est WinRM, pas SSH. Une policy IT groupe interdisait WinRM dans l’infrastructure, ce qui a conduit à adopter SSH comme transport unique pour l’automatisation Windows et toute la dette qui suit découle de cet usage de SSH là où WinRM était prévu (les limites de session du transport SSH sont détaillées dans l’article sur le transport durci ).

Sur Windows 11 précisément, le sous-système PowerShell émet des objets d’erreur CLIXML sur stderr de façon plus agressive que les éditions Server, ce qui casse le parsing JSON d’Ansible sur un classique No start of json char found, un bug de longue date observé en vrai sur les hôtes 11 quand le même playbook passe sans broncher sur Server 2022. Le multiplexage de connexions SSH, pratique standard pour la performance d’Ansible, est instable avec l’OpenSSH de Windows 11, avec des UNREACHABLE intermittents, donc il faut le désactiver et accepter un handshake par tâche. Et les tâches longues, win_updates en tête, voient l’OpenSSH de Windows 11 couper la session en plein milieu, Connection reset by peer, ce qui oblige à envelopper chaque mise à jour dans un async/poll, à séparer le reboot dans une tâche conditionnelle parce que l’async est incompatible avec reboot: true et à durcir le keepalive, soit trois fois plus de YAML qu’un simple win_updates: reboot: true qui, lui, marche de façon fiable sur Server. S’ajoutent un bug dépendant de la verbosité où une tâche échoue en niveau normal et passe en -vvvv et un historique documenté de Microsoft cassant OpenSSH d’une feature update à l’autre, 23H2 et 24H2, là où l’OpenSSH de Server est un composant système bien plus résilient. Une migration vers WinRM est désormais prévue et elle fera disparaître tout cet espace de problèmes d’un coup, mais elle représente elle-même un effort qui n’aurait jamais été nécessaire si WinRM avait été permis dès le départ.

RDP, sessions et GPU headless

Une machine de build a besoin d’une session graphique ouverte, outils de build, pipelines de rendu, charges GPU et elle est en salle serveur sans écran. Windows Server supporte nativement plusieurs sessions RDP concurrentes, donc une session de build et une session d’admin coexistent. Windows 11 n’autorise qu’une seule session interactive à la fois, une restriction de licence et non technique sans contournement supporté, ce qui veut dire qu’un admin qui se connecte pour une maintenance déconnecte la session de build en cours, au risque de corrompre une compilation de shaders ou un asset cooking et que surveiller la session de l’utilisateur de build la perturbe. La 24H2 a de surcroît introduit plusieurs régressions RDP documentées, écran figé à la reconnexion qui n’a pour remède qu’un reboot complet, transport UDP cassé à contourner en forçant le TCP, détection réseau fautive à désactiver par GPO, chacune à revalider après chaque cumulative update. Et en salle serveur sans écran, Windows 11 peut présenter des soucis de driver GPU quand aucun moniteur n’est détecté, d’où les bouchons HDMI factices ou les profils headless, là où Server traite le headless et le partitionnement GPU comme des configurations supportées.

Un mot d’exploitation au passage, parce qu’il vaut pour n’importe quel parc en salle: un KVM sur IP pour la console, BIOS, écran bleu, diagnostics pré-boot et un PDU manageable pour le power-cycle par prise, suppriment l’essentiel des interventions physiques, Windows 11 ou pas.

Le reste et le coût récurrent

Windows 11 arrive avec son bloatware grand public, Teams, Copilot, Widgets, Store, qui consomme et ajoute du bruit non déterministe sur des machines où la performance doit être prévisible et dont le retrait est à revalider après chaque feature update parce que Microsoft réintroduit ce qu’on a retiré. Les feature updates, justement, sont annuelles et chacune est en pratique une mise à niveau complète de l’OS qui peut casser les templates, OpenSSH, le comportement RDP, les drivers et il n’existe pas de LTSC de Windows 11 pour usage général, l’IoT Enterprise LTSC étant licencié pour les seuls appareils à fonction fixe. Server offre au contraire des releases LTSC à support long, pas de feature update forcée, correctifs de sécurité seulement. Tout cela représente du temps d’ingénierie récurrent qui n’existe pas sur le pipeline Server, déjà validé et opérationnel: des group_vars SSH dédiés, le patron async/poll + win_reboot sur chaque win_updates, des conditionnels d’unattend par feature update, des contournements GPO revalidés par cumulative update, des scripts de dé-bloatware revalidés par feature update, un cycle de QA annuel complet.

Un bureau pour personne

Chaque friction de ce billet est surmontable prise seule et c’est le piège, parce qu’on les surmonte une par une sans voir l’addition, jusqu’à ce que le coût récurrent devienne la norme. Windows Server avec Desktop Experience donne le même shell, le même bureau, la même accélération GPU, le multi-session RDP natif, un provisioning stable déjà en production, le support LTSC, un OS sans bloatware et un OpenSSH stable, sans aucun de ces contournements. Le choix n’est pas idéologique, il est économique: on paie Windows 11 en temps d’ingénierie récurrent et Server reprend ce temps. Windows 11 est fait pour un humain devant sa machine et une machine de build headless en salle serveur n’est pas cet usage.