Pourquoi les développeurs boudent encore Windows (et ce que cela change pour les DSI)

Windows et les développeurs : 12,8 %, le chiffre qui fâche Redmond

Il y a une vingtaine d’années, Steve Ballmer arpentait une scène en répétant « developers, developers, developers » avec son énergie d’un coach sportif sous caféine. La formule a fait le tour du monde, et elle a fonctionné : pendant une décennie, Windows fut le poste de travail naturel de celui qui écrit du code. En 2026, Microsoft court toujours après les développeurs, mais le terrain de jeu a radicalement changé. Et un sondage publié fin septembre rappelle que la course est loin d’être gagnée.

Gergely Orosz, auteur de la très suivie newsletter The Pragmatic Engineer, a demandé à son audience sur X quel système d’exploitation elle utilisait pour développer. Sur environ 4 000 réponses, macOS rafle 61,6 % des voix, Linux 24,2 % et Windows ferme la marche avec 12,8 %. Un second sondage mené sur LinkedIn pour la même newsletter, avec près de 6 000 votes, donne des proportions quasi identiques : 66 %, 20 % et 12 %. Autrement dit, sur une dizaine de milliers de votants, Windows arrive bon troisième d’une course à trois.

Le plus cruel pour Microsoft, c’est le calendrier. L’éditeur vient de passer une année entière à retravailler Windows 11 spécifiquement pour ce public.

Un sondage n’est pas un recensement

Avant de sonner le glas, un peu de rigueur méthodologique s’impose. Orosz lui-même qualifie son audience de « bulle », composée majoritairement de développeurs de start-up et de la Big Tech. Ce n’est pas le développeur d’un éditeur de progiciel de gestion à Clermont-Ferrand, ni l’équipe .NET d’une grande banque, ni le prestataire d’une ESN travaillant sur le poste fourni par son client.

Les grandes enquêtes racontent d’ailleurs une autre histoire. Le Stack Overflow Developer Survey 2025, qui porte sur des dizaines de milliers de répondants, place Windows en tête des systèmes d’exploitation principaux chez les développeurs professionnels, autour de 49,5 %, contre 32,9 % pour macOS. Attention toutefois : cette enquête autorise les réponses multiples, alors que le sondage d’Orosz impose un choix unique. Comparer 12,8 % et 49,5 % revient donc à comparer une préférence exclusive avec un usage déclaré. Les deux chiffres peuvent être vrais simultanément, et c’est précisément ce qui est intéressant : Windows reste massivement utilisé, mais il est peu choisi par les populations les plus visibles et les plus prescriptrices.

Petite parenthèse pour les amateurs de courbes virales : le débat a été relancé par une capture Statcounter montrant Linux proche de 18 % sur le desktop américain. Or Statcounter mesure des pages vues, pas des machines ni des humains, et continue de distinguer « OS X » et « macOS » comme s’il s’agissait de deux systèmes différents. En juillet, une autre capture prétendait que Windows était passé de 79 % à 56 % en deux mois ; il s’agissait en réalité d’une erreur de classification, corrigée depuis. De même, les données de Cloudflare montrent Linux autour de 4,7 % sur le trafic humain nord-américain, alors que le trafic automatisé (les bots, notamment ceux liés à l’IA) le fait grimper jusqu’à 26 % certains jours. Les statistiques de parts de marché des OS ont décidément la fiabilité d’un bulletin météo à trois semaines 🙂

Un seul mot pour tout expliquer : Unix

Pourquoi les développeurs qui ont le choix se tournent-ils vers macOS ou Linux ? La réponse tient en quatre lettres.

macOS offre un environnement Unix natif, avec un shell, des outils en ligne de commande et des gestionnaires de paquets familiers, le tout dans une interface qui a le bon goût de ne pas pousser d’abonnements ni d’applications préinstallées à chaque redémarrage. Les puces Apple Silicon ajoutent un argument de poids avec leur rapport performances/autonomie. Et pour tout ce qui touche à l’écosystème Apple (iOS, iPadOS, watchOS, visionOS), la question ne se pose même pas : Xcode, ses SDK et ses simulateurs n’existent que sur Mac.

Linux, lui, bénéficie d’un argument encore plus structurel : c’est là que le logiciel moderne tourne en production. Conteneurs Docker, orchestration Kubernetes, stacks Python, infrastructures cloud, charges d’IA : le développeur veut que son poste ressemble à sa cible de déploiement. Développer sur l’OS de production, c’est éliminer une classe entière de bugs du type « ça marche sur ma machine ».

Face à cela, Microsoft a choisi une stratégie pragmatique : puisque les développeurs veulent Linux, mettons Linux dans Windows. C’est tout le sens de WSL. Mais la solution a ses limites techniques. WSL 2 repose sur une machine virtuelle légère avec un vrai noyau Linux, et la documentation de Microsoft elle-même prévient que stocker ses fichiers de projet côté Windows tout en les compilant avec des outils Linux dans WSL entraîne une pénalité d’entrées/sorties. Traverser la frontière entre les deux systèmes de fichiers a un coût, que connaît bien quiconque a lancé un npm installsur un répertoire monté depuis /mnt/c.

Ce que Microsoft a mis sur la table en 2026

On ne pourra pas reprocher à Microsoft d’être resté les bras croisés. L’année 2026 ressemble à une offensive méthodique.

WSL d’abord, qui n’est plus un projet annexe. Microsoft a amélioré l’accès aux fichiers, la gestion réseau et la simplicité d’installation, en le présentant comme la fondation des charges Linux sur Windows. Ce travail a débouché sur WSL Containers et l’outil intégré wslc, qui permet de construire et d’exécuter des conteneurs Linux sans passer par Docker Desktop. Pour une DSI, le détail n’est pas anodin : Docker Desktop est soumis à une licence commerciale payante au-delà d’un certain seuil de taille d’entreprise, et une alternative native intégrée à l’OS simplifie à la fois la conformité et le déploiement.

La conférence Build 2026 a ensuite accéléré le mouvement, avec la promesse de faire de Windows 11 « l’OS pour construire l’IA ». Au menu : Coreutils pour Windows, une réimplémentation en Rust des utilitaires GNU en ligne de commande fonctionnant nativement ; Windows Developer Configurations, qui s’appuie sur WinGet pour installer VS Code, GitHub Copilot, WSL et PowerShell 7 en une seule commande ; Windows Development Skills pour le développement d’applications natives assisté par agents ; un Intelligent Terminal expérimental ; et Microsoft Execution Containers, une couche pilotée par des politiques qui permet de contrôler ce qu’un agent IA a le droit de toucher sur un poste. Ce dernier point mérite l’attention des RSSI : laisser un agent de code exécuter des commandes sur un poste de développeur n’est pas une mince affaire, et disposer d’un périmètre d’exécution gouverné au niveau de l’OS est une vraie brique de sécurité.

Enfin, annoncé le 4 septembre, Project Zenith pousse la logique jusqu’au bout : une déclinaison de Windows avec des réglages par défaut pensés pour le développeur, exigeant au moins 64 Go de mémoire unifiée et 250 Go/s de bande passante afin de faire tourner localement des modèles de code de 30 milliards de paramètres. Windows Terminal et VS Code sont épinglés dans la barre des tâches, GitHub Copilot, PowerToys et les Dev Skills sont préinstallés. En creux, c’est un aveu intéressant : pour séduire les développeurs, Microsoft doit leur proposer un Windows plus sobre, débarrassé de ce qui agace au quotidien. Le matériel suit avec la Surface RTX Spark Dev Box et le Surface Laptop Ultra, qui associent NVIDIA RTX Spark, grande mémoire unifiée et support CUDA pour le développement d’IA en local. Yusuf Mehdi a par ailleurs annoncé vouloir consacrer sa dernière année chez Microsoft à repenser Windows pour l’ère agentique, et l’événement Windows prévu en octobre, le premier de cette ampleur depuis deux ans, devrait préciser cette trajectoire.

Le paradoxe WSL : une victoire en trompe-l’œil

Voici sans doute l’élément le plus savoureux du dossier. Jon Seager, vice-président de l’ingénierie chez Canonical, a expliqué à The Pragmatic Engineer que l’usage d’Ubuntu dans WSL progresse plus vite que les installations natives d’Ubuntu sur desktop, et qu’il s’attend à ce que WSL les dépasse d’ici quelques mois. Le moteur de cette croissance ? Des développeurs à qui l’employeur a remis un portable Windows et qui ont besoin de Linux pour leurs travaux d’IA et de machine learning.

Lu d’un œil, c’est un succès pour Microsoft : les développeurs restent sur Windows. Lu de l’autre, c’est un constat d’échec : ils y restent parce qu’on ne leur a pas laissé le choix, et ils passent leur journée dans un Linux virtualisé. Windows devient ainsi l’un des meilleurs hôtes Linux du marché de l’entreprise. Un peu comme un restaurant dont la table la plus réservée serait celle du traiteur voisin…

C’est d’ailleurs la vraie clé de lecture des deux sondages. Le 12,8 % d’Orosz mesure ce que choisissent les développeurs quand ils sont libres ; le 49,5 % de Stack Overflow mesure en partie ce que les organisations leur fournissent. L’écart entre les deux, c’est la marge de persuasion qui manque encore à Microsoft.

Ce que cela change pour les DSI

Pour une direction des systèmes d’information, ce débat n’a rien d’académique. Il touche à la fois la standardisation du parc, la sécurité et l’attractivité employeur. Nous aborderons ceci lors du prochain Briefing Calipia.

Premier arbitrage : standardiser ou diversifier. Une flotte Windows avec WSL, Dev Drive (le volume optimisé sur ReFS pour les charges de développement) et les nouvelles Developer Configurations offre une homogénéité appréciable pour le déploiement et la gestion. Mais refuser un Mac à un développeur senior qui en fait une condition d’embauche est devenu, dans certains secteurs, un vrai frein au recrutement. Accepter une flotte macOS gérée via Intune est désormais techniquement mature ; encore faut-il en assumer le coût d’exploitation et les politiques de conformité spécifiques.

Deuxième arbitrage : la sécurité. WSL introduit de fait un second système d’exploitation sur le poste, avec ses propres paquets, ses propres processus et sa propre surface d’attaque. Il convient de vérifier que la télémétrie EDR couvre bien ces environnements (Defender for Endpoint propose une extension dédiée à WSL) et que les politiques de contrôle d’accès s’y appliquent. L’arrivée des agents de code sur les postes rend cette question encore plus pressante, et c’est là que Microsoft Execution Containers pourrait devenir un argument différenciant face à macOS.

Troisième arbitrage : le budget matériel. Un poste Zenith à 64 Go de mémoire unifiée n’a rien d’un portable d’entrée de gamme. Pour faire tourner des modèles en local, la question se pose de l’équiper chaque développeur ou de mutualiser la puissance via des postes virtuels de type Microsoft Dev Box ou Windows 365, voire de consommer les modèles dans le cloud. Chaque option a ses implications en matière de coût, de confidentialité des données et de latence.

Conclusion : Microsoft a peut-être déjà gagné ailleurs

Il serait injuste de résumer la situation à un échec. Windows conserve des atouts considérables : Visual Studio reste un environnement de référence, .NET est officiellement multiplateforme, l’empreinte entreprise est gigantesque et le jeu vidéo sur PC lui appartient largement. Microsoft n’ignore pas les développeurs, il investit massivement pour eux. Le problème est ailleurs : beaucoup de développeurs n’ont pas besoin de Windows, ils ont besoin d’Unix. Et aucune couche de compatibilité, aussi réussie soit-elle, ne transforme une nécessité technique en désir.

Reste une ironie que Steve Ballmer appréciera peut-être. Le développeur type du sondage d’Orosz code sur un Mac, dans VS Code, avec GitHub Copilot, pousse son code sur GitHub et le déploie souvent sur Azure. Microsoft n’a jamais autant été présent dans la vie des développeurs ; ce n’est simplement plus par Windows. La vraie question pour Redmond n’est donc peut-être pas de reconquérir le poste de travail, mais de savoir si le poste de travail compte encore autant qu’avant.

Votre commentaire

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur la façon dont les données de vos commentaires sont traitées.