Calipia : le blog

Tout développeur ayant reçu un PC neuf connaît la liturgie. Il y a d’abord l’OOBE et son chapelet de propositions commerciales à décliner poliment, puis l’arrivée sur un bureau encombré de widgets, de flux MSN et de recommandations dont personne n’a jamais demandé l’existence. Vient ensuite l’heure consacrée à cocher « afficher les extensions de fichiers », activer le mode développeur, faire taire la recherche Bing, puis installer un par un PowerShell 7, Git, VS Code, WSL et une dizaine d’autres outils. Une demi journée perdue, multipliée par le nombre de développeurs de l’entreprise et par le nombre de renouvellements de parc : le calcul est vite fait, et il n’est pas flatteur.

Microsoft vient de publier sur GitHub une réponse officielle à ce problème : Windows Developer Config, un projet open source sous licence MIT qui promet de transformer une installation fraîche de Windows 11 en station de développement opérationnelle via une seule commande PowerShell. L’éditeur le qualifie lui même d’« opinionated », autrement dit de configuration qui assume ses partis pris. Windows Latest l’a testé sur une machine vierge, et le résultat mérite qu’on s’y arrête, autant pour ce qu’il apporte que pour ce qu’il révèle de la stratégie de Redmond.

Un contexte qui n’a rien d’anodin

Le calendrier de cette publication n’est pas un hasard. Nous vous parlions hier d’un sondage plaçant Windows à seulement 12 % d’adoption chez les développeurs interrogés, malgré les efforts répétés de Microsoft pour rendre son système plus accueillant. Le chiffre est à prendre avec les précautions d’usage (un sondage en ligne n’est pas une étude de marché), mais il illustre une réalité que tout DSI a pu constater dans ses équipes : le MacBook et le poste Linux sont devenus des marqueurs culturels chez les développeurs, et Windows peine à reconquérir ce public.

Windows Developer Config s’inscrit donc dans une offensive plus large. Il y a quelques semaines, Microsoft présentait Project Zenith, une déclinaison de Windows orientée développeurs réservée à du matériel spécialement configuré exigeant 64 Go de RAM. Windows Developer Config en constitue la version démocratique : aucun prérequis matériel particulier, si ce n’est 15 Go d’espace libre et la patience de laisser tourner le script une demi heure.

Une architecture bien pensée

Sur le plan technique, le projet est plus sérieux qu’un énième script de « debloat » trouvé sur un forum. Le cœur du dispositif repose sur 50 étapes réparties en 11 phases, chacune structurée selon un triptyque vérification, application, re vérification. Le script est idempotent : chaque modification est confrontée à l’état courant avant exécution, si bien qu’une seconde exécution sur une machine déjà configurée se contente de confirmer les réglages sans rien refaire. Le dépôt revendique par ailleurs des configurations testées en intégration continue, ce qui le distingue nettement des bricolages habituels.

Le lancement tient en deux lignes PowerShell qui téléchargent un script d’amorçage depuis raw.githubusercontent.com et l’exécutent directement en mémoire. Le bootstrap demande l’élévation UAC si nécessaire, vérifie la signature Microsoft Corporation des scripts, les copie dans un dossier protégé sous %ProgramData%\CalmOS, puis se met au travail. Oui, le nom interne du projet est « Calm OS », ce qui en dit long sur la perception qu’ont les équipes de Microsoft de l’expérience par défaut de leur propre système. On apprécie l’autodérision.

Le seul redémarrage intervient en fin de parcours, pour l’activation de la fonctionnalité optionnelle WSL. Un avertissement de 10 secondes précède la relance, puis une tâche planifiée nommée WindowsDevConfigResume reprend le travail environ 30 secondes après la reconnexion, avec une seconde invite UAC. Microsoft annonce une trentaine de minutes sur une machine propre dotée d’une connexion correcte, essentiellement consacrées au téléchargement de VS Code, du SDK .NET, de PowerToys et d’Ubuntu. Le testeur de Windows Latest confirme ce délai. Petite nuance toutefois : la documentation affirme que la fenêtre PowerShell n’a pas besoin d’être élevée, mais le script n’a fonctionné qu’en mode administrateur lors du test.

Quinze paquets via winget

La phase 2 installe quinze paquets, tous via winget, en mode silencieux avec acceptation préalable des conditions : Windows Terminal, PowerShell 7 (sur lequel le script se relance dès qu’il est disponible), Git, GitHub CLI, GitHub Copilot CLI, Visual Studio Code, le SDK .NET 10, Python 3.14 accompagné de uv, Node.js LTS, nvm for Windows, Coreutils for Windows, Oh My Posh, Windows App CLI et PowerToys. Un paquet n’est considéré comme traité qu’une fois déclaré à la fois installé et à jour par winget, ce qui permet à une réexécution de faire office de mise à jour.

Une incohérence mérite d’être signalée : la configuration installe simultanément Node.js LTS et nvm for Windows, deux approches concurrentes de la gestion de Node !! Microsoft recommande d’ailleurs de désinstaller Node.js si l’on souhaite confier le PATH à nvm, et un ticket GitHub ouvert en juin documente précisément ce conflit. Installer deux gestionnaires pour ensuite conseiller d’en retirer un, voilà une démarche qui rappelle les meilleures heures de l’administration Windows.

Le script ajoute aussi, en option, les modèles WinUI pour dotnet new et enregistre auprès de GitHub Copilot CLI les « Windows Development Skills » et le plugin WinUI. On retrouve ici la volonté de Microsoft de relancer le développement d’applications natives, en permettant à Copilot de générer une application WinUI sans passer par Visual Studio.

24 modifications de registre, et pas une de moins

Les phases 3 à 9 appliquent 24 modifications de registre regroupées en six catégories. Côté système, on trouve l’activation de sudo en mode inline, du mode développeur, du support des chemins longs Win32 (adieu la limite historique de 260 caractères, héritage que l’on traîne depuis MS-DOS) et des connexions Bureau à distance. Point important : la règle de pare-feu RDP n’est pas ouverte, la machine n’est donc pas exposée sur le réseau par ce seul réglage.

L’Explorateur de fichiers affiche désormais les extensions et fichiers cachés, le chemin complet dans la barre de titre, s’ouvre sur « Ce PC » plutôt que sur l’accès rapide, et abandonne les dossiers fréquents, fichiers récents et suggestions cloud. La barre des tâches gagne l’option « Terminer la tâche » dans le menu contextuel, tandis que les résultats web, les « points forts » de la recherche et les recommandations du menu Démarrer disparaissent. Les Widgets sont désactivés via la valeur de stratégie système, le bouton utilisateur n’ayant plus d’effet depuis la 24H2. Le mode Ne pas déranger est activé globalement, Edge reçoit une page de nouvel onglet vierge et son expérience de premier lancement est supprimée.

Côté cosmétique, le thème sombre s’applique au système et aux applications, Windows Terminal adopte PowerShell 7 comme profil par défaut et la police Cascadia Mono Nerd Font, et Oh My Posh est initialisé depuis le profil PowerShell. Détail révélateur d’une certaine rigueur : Microsoft épingle une version précise de Cascadia Code (2407.24), vérifiée contre une empreinte SHA-256 connue avant installation, plutôt que de récupérer aveuglément la dernière version publiée. Voilà une bonne pratique de chaîne d’approvisionnement qu’on aimerait voir plus souvent.

Il faut être clair sur un point : il ne s’agit pas d’un outil de « débloatage » au sens des scripts communautaires qui arrachent composants et applications. Aucun composant Windows n’est supprimé. Le script se contente de neutraliser les réglages par défaut dont la vocation est de vendre ou de montrer quelque chose. La nuance est importante pour la supportabilité, et c’est probablement la seule manière pour Microsoft de publier un tel outil sans se tirer une balle dans le pied commercial.

WSL, Linux et la reconnaissance implicite d’une défaite

La dernière phase installe la plateforme WSL et Ubuntu. Le script ne touche en revanche à rien à l’intérieur de la distribution : ce travail revient à un second outil du même dépôt, WSL Comfort. Celui ci, interactif par défaut mais utilisable en mode non interactif ou minimal, propose le choix entre zsh et bash, le prompt Starship, un lot d’outils CLI modernes (fzf, ripgrep, fd, bat, eza, zoxide, jq), des émulations de pbcopy, pbpaste et open, Homebrew en option et des réglages Git par défaut.

On notera l’ironie : pour séduire les développeurs, Microsoft leur offre un shell Linux configuré pour ressembler à un terminal macOS, jusqu’aux commandes pbcopy et pbpaste. C’est habile, et c’est aussi un aveu. Canonical a d’ailleurs indiqué que l’usage d’Ubuntu via WSL croissait plus vite que les installations natives d’Ubuntu desktop. Windows devient, pour une partie des développeurs, un excellent hyperviseur à Linux doté d’une bonne suite bureautique.

Une étagère de configurations par langage

Pour ceux qui ne veulent qu’une seule chaîne d’outils, le dépôt propose des « workloads » unitaires, chacun sous forme d’un fichier configuration.winget accompagné d’un script qui rafraîchit le PATH : TypeScript, PHP 8.5, .NET SDK 10, Go, OpenJDK 25 LTS de Microsoft, Rust via rustup, Python 3.14 avec uv, SQL Server allégé avec sqlcmd, PowerShell 7 avec son outillage VS Code, WinForms et WinUI 3. Le README consulté ce jour en liste même un douzième, dédié à Windows App CLI. Attention, WinForms et WinUI 3 embarquent plusieurs gigaoctets de composants Visual Studio, ce que la documentation qualifie elle même de pénible sur une petite machine virtuelle.

Ces workloads reposent sur winget configure, c’est à dire sur le mécanisme de configuration déclarative basé sur DSC que Microsoft pousse depuis plusieurs années. C’est sans doute l’aspect le plus intéressant pour un architecte : ces fichiers constituent des modèles réutilisables, versionnables et adaptables à un catalogue interne. Une extension pour la Command Palette de PowerToys est également en préparation, mais elle n’est pas encore livrée.

Ce qu’un DSI doit regarder de près

Passé l’enthousiasme, plusieurs points méritent une lecture attentive avant toute généralisation en entreprise.

Le premier concerne le mode de distribution. Télécharger un script depuis Internet et l’exécuter directement en mémoire avec des droits administrateur est exactement le schéma que les équipes sécurité passent leur temps à interdire. La vérification de signature atténue le risque, mais un détail a retenu notre attention : la commande affichée dans le README au moment de la rédaction de cet article comporte un paramètre -AllowUnsigned, qui exécute la copie source du dossier src plutôt que la copie signée. Dans un contexte d’entreprise, la bonne pratique reste de forker le dépôt, d’auditer les scripts, de les héberger en interne et de les distribuer via les outils de gestion du parc.

Le deuxième point est la cohabitation avec la gestion centralisée. Le script écrit deux paramètres Edge sous forme de stratégie, si bien que le navigateur affiche fièrement « géré par votre organisation » sur un poste qui ne l’est peut être pas. Sur un poste réellement géré par Intune ou par GPO, ces écritures risquent d’entrer en conflit avec les stratégies existantes, et le dernier qui écrit gagne rarement de manière prévisible.

Le troisième point touche aux réglages eux mêmes. L’activation globale du Bureau à distance, même sans ouverture du pare-feu, élargit la surface d’attaque potentielle. Le mode Ne pas déranger permanent fait taire toutes les notifications, y compris celles que la DSI juge importantes. Le fichier settings.json de Windows Terminal est réécrit par sérialisation JSON, ce qui efface les commentaires (une sauvegarde .bak est heureusement créée). Enfin, il n’existe ni désinstallation automatique, ni mode simulation, ni écran de sélection des composants à l’exécution. La documentation détaille la manière d’annuler chaque réglage, mais cela reste un travail manuel.

Le dernier point est d’ordre philosophique. Le mode développeur, sudo et les droits administrateur nécessaires à l’installation posent la vieille question du développeur administrateur de son poste. L’outil ne la tranche pas, il la suppose résolue. Or dans beaucoup d’organisations, notamment dans les secteurs régulés, elle ne l’est pas.

Notre avis

Windows Developer Config n’est pas un outil révolutionnaire. C’est mieux que cela : c’est l’aveu public, documenté et versionné de tout ce que les développeurs faisaient subir à Windows à la main depuis des années. Microsoft écrit noir sur blanc que ses propres réglages par défaut gênent les professionnels, et fournit le correctif. On pourra ironiser sur un éditeur qui publie un outil pour désactiver ses propres publicités, mais la démarche est saine.

Pour une DSI, l’intérêt principal n’est pas la commande magique, qui n’a pas sa place telle quelle dans un parc maîtrisé. C’est la qualité des briques : scripts idempotents, configurations winget déclaratives, workloads par langage, dépendances épinglées et vérifiées. Autant de matériaux à intégrer dans une démarche d’industrialisation du poste développeur, via Intune, Windows Autopilot ou un catalogue interne. On regrettera simplement que Microsoft n’ait pas directement intégré cette logique dans l’option « Développement » proposée lors de l’installation de Windows. Cela viendra peut être. En attendant, la reconquête des développeurs passe par un script PowerShell, ce qui, au fond, est assez cohérent.