Windows ou Linux : ce qui se joue vraiment

La question qui est dessous

En pratique, le choix d’un système d’exploitation ne se fait presque jamais sur le système d’exploitation. Il se fait sur trois choses déjà vraies avant que quiconque pose la question.

• Quelle application doit tourner dessus. Si votre ERP ne tourne que sous Windows, la question est réglée. Si votre éditeur livre son logiciel en conteneur, elle l’est aussi, dans l’autre sens. C’est de loin le facteur le plus déterminant et le plus souvent le seul qui compte.
• Ce que vous payez déjà. Si votre organisation vit dans Microsoft 365 avec les identités dans Entra ID, un serveur Windows n’est pas un monde nouveau mais le prolongement d’un monde que vous gérez déjà. Cela vaut de l’argent, même si aucun devis ne le mentionne.
• Qui le relève la nuit. Une équipe à l’aise sur l’un est lente sur l’autre, et à trois heures du matin lent équivaut à cassé.

La comparaison ci-dessous n’intervient que si ces trois-là ne tranchent pas. Cela arrive moins souvent qu’on ne le croit.

Où se trouve réellement le coût

Aucun montant ne figure sur ce site ; la structure, si, car c’est là que se cachent les surprises.

Windows Server facture au cœur physique de la machine, avec un minimum par serveur et par processeur. Ce minimum est exactement là où le calcul dérape : une machine à peu de cœurs coûte le minimum, et un hôte dense à nombreux cœurs coûte un multiple de ce qui était budgété. S’y ajoutent les licences d’accès, comptées par utilisateur ou par appareil qui atteint le serveur, et non par session simultanée. Trois cents personnes sur cinquante postes en équipes, cela ne fait donc pas cinquante.

Linux n’a pas cette structure. Chez Red Hat et SUSE, vous payez un abonnement par machine ou par socket, et cet abonnement est du support et non un droit d’usage : il tourne aussi sans. Avec Debian et Ubuntu vous ne payez rien, et vous pouvez acheter du support séparément si vous le souhaitez.

C’est là que le côté gratuit pose son piège. Un système sans licence n’est pas un système sans coût. Ce que vous ne payez pas à un éditeur, vous le payez en heures de quelqu’un qui planifie les mises à jour, suit les versions du noyau et se réveille à deux heures du matin. Pour un serveur, cela disparaît dans le bruit. Pour trente, non.

La comparaison sécurité, honnêtement

C’est la partie sur laquelle on écrit le plus de bêtises, généralement avec un décompte de vulnérabilités publiées à l’appui. Ce décompte ne dit rien. Il mesure ce qui a été trouvé et publié, pas ce qui existe, et les deux ne comptent pas pareil : une distribution Linux inclut des milliers de paquets livrés séparément sous Windows.

Ce qui diffère vraiment en pratique, c’est ceci :

• La surface par défaut. Un serveur Linux nu exécute peu et écoute peu. Un serveur Windows arrive avec davantage à bord. Cela se corrige — on désactive les rôles inutilisés — mais cela demande un geste, et les gestes se sautent.
• Où sont les bijoux. Dans un parc Windows, c’est l’annuaire. Qui devient administrateur du domaine a tout. Côté Linux, l’équivalent est la gestion des clés et de sudo. Les deux se protègent, et dans les deux cas c’est là que va l’effort.
• Le rythme des correctifs. Windows a un cycle mensuel fixe, ce qui facilite la planification et allonge parfois le délai jusqu’au correctif. Sous Linux, cela arrive par paquet et par distribution, ce qui peut être plus rapide et demande plus d’attention.

Ce qui renverse les deux est identique, et n’appartient à aucun : un service exposé à internet en retard de correctifs, et un accès qui n’aurait jamais dû exister. Nous n’avons jamais vu d’incident imputable au choix entre ces deux-là. Beaucoup, en revanche, imputables à l’attention portée ensuite.

Sur les performances, brièvement

On cherche beaucoup de comparatifs de vitesse entre les deux. Pour le type de travail que nous traitons — services de fichiers, bases de données pour une organisation de dizaines à centaines de personnes, serveurs applicatifs — le système d’exploitation n’est presque jamais le frein.

Le frein, c’est le stockage, la mémoire, ou une requête que personne n’a jamais regardée. Un serveur trop lent ne devient pas rapide, neuf fois sur dix, en changeant de système, et le devient en remplaçant un disque à bout de souffle.

Nous n’accolons pas de chiffres ici. Un benchmark sans sa méthode est un avis avec une décimale, et la mesure qui compte est celle de votre charge.

Quand chacun l’emporte

Si les trois questions du début ne tranchent pas, cela se résume à ceci.

Windows Server l’emporte quand vos identités vivent déjà dans le monde Microsoft, quand les stratégies de groupe et les outils connus vous épargnent un travail que vous devriez sinon écrire, ou quand un éditeur ne supporte que cela. Ce dernier point n’est pas un argument technique, mais c’est un vrai argument : le support que vous n’avez pas, vous le payez vous-même.

Linux l’emporte pour tout ce qui est exposé à internet et se compte en nombre, pour les charges en conteneurs, et partout où le coût des licences suit une croissance que vous ne maîtrisez pas. Pour les services web, les couches de traitement et tout ce qui gravite autour de Docker ou Kubernetes, ce n’est généralement pas un choix mais une évidence.

Et souvent la réponse est les deux. La plupart des parcs que nous reprenons sont déjà mixtes, presque toujours sans que personne ne l’ait décidé. Ce n’est pas un problème tant qu’une chose tient : que pour chacun vous sachiez qui applique les correctifs, qui le restaure et où c’est écrit. Notre façon de le mettre en place figure sous infogérance.