Linux serveur : quelle stratégie pour tirer un vrai bénéfice de l’Open Source ?

Premier article d’une série de deux consacré au socle Linux serveur. Ce premier article expose quelques raisons pour lesquelles une Direction des Services Informatique (DSI) peut et même devrait rouvrir le dossier de son socle Linux, même quand tout fonctionne. Il s’agit surtout de savoir ce qu’elle choisit réellement lorsqu’elle croit s’orienter vers une distribution Linux.

Contrairement aux systèmes d’exploitation du poste de travail, exposés aux innovations du moment (l’IA en tête), le socle Linux serveur peut fonctionner pendant des années sans être réexaminé et influencer durablement toute la stratégie du SI. Pendant ce temps long, les contrats sont renouvelés, les applications (souvent métiers et stratégiques) sont certifiées sur un périmètre précis, les procédures d’exploitation s’épaississent et les compétences internes comme externes se spécialisent. Comme toute décision d’architecture, même un choix de l’Open Source peut finir par devenir une dépendance, sans que personne ait jamais eu à la valider comme telle. Cela a fortiori lorsqu’il est étendu aux environnements virtualisés, souvent dans un alignement avec la stratégie globale.

Ainsi, la question utile pour une DSI est de définir quel assemblage de distributions, quel choix de maintenance, de support, de certifications, d’outillage et de compétences doivent ou peut-elle conserver dans la durée et pour quelle durée ? L’enjeu se chiffre rapidement en millions d’euros, et les éditeurs de distributions positionnés sur ce segment ont adopté des modèles tarifaires et contractuels proches de ceux des éditeurs propriétaires — ce qui impose de définir des stratégies qui mixent les modèles traditionnels d’Open Source mais aussi quelques réserves proches des modèles propriétaires.

Rouvrir le dossier n’engage aucune décision de quitter le socle actuel, qu’il s’agisse de RHEL, SLES, Ubuntu, Debian ou une autre distribution. Mais cela doit permettre de confirmer son choix, d’en mesurer le coût complet, d’en négocier les conditions et de conserver une trajectoire de rechange crédible, qui s’appuie pleinement sur les libertés et garanties offertes par l’Open Source. Compte tenu des pratiques strictes, une telle démarche doit être ouverte avant toute entrée en négociation, quand l’inventaire peut encore être corrigé et le périmètre contractuel discuté afin de pouvoir réellement dessiner une stratégie durable.

Du poste de travail au serveur, changer d’unité d’analyse

En 2025, nous avions consacré un premier billet au poste de travail sous Linux qui revenait sur les bénéfices attendus, mais aussi les conditions de succès d’une telle migration. Dans ce domaine, force est de constater que le sujet a grandement progressé : le 8 avril 2026, la DINUM a annoncé sa sortie de Windows au profit de postes sous Linux, dans le cadre de plans ministériels qui couvrent aussi les outils collaboratifs, les antivirus, l’intelligence artificielle, les bases de données, la virtualisation et les équipements réseau. Des travaux concrets de construction de postes sécurisés et personnalisables sont déjà visibles comme SécurixOS, distribution fondée sur NixOS, développée par la DINUM (en version alpha), et Bureautix, exemple de poste bureautique qui en est dérivé. En juillet 2026, le rapport de la commission d’enquête de l’Assemblée nationale sur les dépendances numériques, auquel nous avons consacré trois billets d’analyse, a donné à cette orientation une traduction politique.

À l’échelle européenne, la dynamique est tout aussi forte du côté des acteurs publics. Le Land de Schleswig-Holstein a fait de LibreOffice le standard bureautique de son administration et a basculé sa messagerie sur des briques libres, les postes Linux étant en phase de test. Les forces armées allemandes ont signé un contrat-cadre de sept ans pour déployer la suite libre openDesk. Au Danemark, le ministère du Numérique a lancé un projet pilote de remplacement de Microsoft Office par une solution fondée sur LibreOffice, et Copenhague et Aarhus ont engagé la réduction de leur dépendance à Microsoft. En France, la Ville de Lyon remplace progressivement la suite Microsoft Office par des solutions libres, avec Linux et PostgreSQL côté serveurs.

En matière de serveurs, la messe est dite et l’Open Source est devenu l’environnement standard au sein des organisations. Pour preuve : Microsoft indique que plus de 60 % des cœurs de client dans Azure exécutent des charges de travail Linux et maintient sa propre distribution Open Source (Azure Linux) pour les machines virtuelles, les conteneurs et les clusters Kubernetes. Néanmoins le raisonnement est différent en matière de serveurs :

• en termes de criticité : les critères d’étude d’un socle serveur portent ainsi généralement sur la criticité, les enjeux de certification applicative, les fins de support et la reconstructibilité, quatre critères qui ont en commun de pouvoir être anticipés.
• en termes d’unité considérée :
  • Sur le poste, l’unité d’analyse est généralement l’utilisateur ou une population d’utilisateurs : ainsi les usages, l’ergonomie, les formats de documents, les périphériques et l’accompagnement du changement sont centraux.
  • Sur les serveurs, l’unité pertinente est la charge applicative ou la classe de service : base de données, serveur d’applications, infrastructure, calcul, service exposé ou composant d’une plateforme conteneurisée.
• en termes d’interlocuteurs internes : équipes système, production, sécurité, architecture, responsables applicatifs, achats et juristes doivent conforter et confronter leurs contraintes. Une modification invisible pour les utilisateurs peut affecter la correction d’une vulnérabilité, la disponibilité d’un service critique ou le support d’un logiciel métier.
• en termes de fournisseurs de solutions :
  • si aucun éditeur ne publie de ventilation entre poste et serveur, mais leurs offres parlent d’elles-mêmes : le poste est gratuit ou facturé au prix d’un accessoire, 25 dollars par an pour Ubuntu Pro Desktop, 129 dollars pour SUSE Linux Enterprise Desktop, 329 dollars pour RHEL Workstation avec support standard, quand le serveur se facture par hôte, par socket ou par instance, de 500 à plusieurs milliers de dollars par an.
  • en termes de marché associé : la ligne Red Hat d’IBM (RHEL, OpenShift, Ansible) atteint 7,3 milliards de dollars en 2025, Canonical 292 millions de dollars en 2024, et SUSE affichait 655 millions de dollars de revenus récurrents annuels fin 2022, avant son retrait de cote. Le marché des systèmes d’exploitation serveur payants, Windows Server compris, pesait 14,6 milliards de dollars en 2021 selon IDC.

Les ordres de grandeur confirment cette différence de nature :

• Sur le poste de travail, Linux représente 8,9 % du trafic web mondial, 6,4 % en Europe et 4,5 % en France à l’été 2026 selon StatCounter, et moins de 2 % des parcs d’entreprise scannés par Lansweeper, sur un marché de plus de 270 millions de PC livrés en 2025.
• Sur les serveurs, il est majoritaire partout où une mesure existe : plus de 60 % des cœurs de client dans Azure, 62 % des sites web dont le système est identifié, les systèmes en tête du TOP500 des supercalculateurs, et déjà plus de la moitié des déploiements commerciaux de systèmes serveur en 2018, dernier chiffre d’IDC rendu public sur ce point. Le nombre de machines virtuelles et d’instances cloud, lui, n’est publié par personne.

Une DSI ne choisit pas seulement une distribution

Pour une DSI, la stratégie Open Source est loin d’être négligeable. Avec la virtualisation et le cloud, le nombre d’instances peut croître beaucoup plus vite que le nombre de serveurs physiques. Une règle de comptage appliquée instance par instance devient un poste budgétaire suivi en comité de direction. Une différence de quelques dizaines d’euros par instance et par an change d’ordre de grandeur dès que le parc se compte en milliers d’instances, quel que soit le fournisseur. Avant un renouvellement, deux écarts comptent davantage qu’un tarif :

• Le nombre d’instances réellement en service face au nombre d’instances couvertes.
• Le nombre d’instances couvertes au niveau de service le plus élevé alors qu’une classe inférieure suffirait.

Ces écarts se mesurent avant la négociation et tout au long de la durée du contrat.

Le choix d’une distribution (par ex. Debian ou RHEL) ne doit pas être binaire et exclusif : les DSI organise en réalité plusieurs fonctions, qui peuvent être réunies chez un même acteur ou réparties entre plusieurs intervenants interagissant autour des distributions Linux. Une DSI peut segmenter son besoin au lieu d’appliquer le même service à toutes ses machines : une charge critique certifiée n’appelle pas nécessairement la même maintenance ni le même support qu’un environnement de développement standard. Deux exemples:

• le CERN n’acquiert, selon les termes de sa documentation, qu’un nombre limité de licences RHEL avec support complet, réservées aux hôtes dont les conditions de licence exigent un système supporté, comme certaines bases de données Oracle.
• L’URSSAF a fait le chemin inverse de la gratuité : le manifeste de Numeum relate comment elle a remplacé ses composants Open Source communautaires par des versions supportées par des éditeurs, pour simplifier leur cycle de vie et dégager ses équipes des tâches d’intégration et de test.
• d’autres organisations, comme la gendarmerie, se tourne massivement vers Debian ou encore Ubuntu Server pour couvrir ses besoins internes.

Le choix de la distribution fournit un ensemble cohérent de composants et un rythme de versions qui conditionne et est conditionné par différents services pour lesquels aussi plusieurs stratégies peuvent opérer :

• L’offre de maintenance vise à garder cet ensemble utilisable dans le temps : qualification et publication de correctifs de sécurité, corrections d’anomalies, rétroportages (application d’un correctif récent à une version ancienne, sans en changer le numéro) et gestion du cycle de vie (généralement limité au socle Open Source de la distribution). Le périmètre de la maintenance est lui-même une variable : Canonical, avec Ubuntu Pro, étend la maintenance de sécurité d’une version LTS de cinq à dix ans et du seul dépôt Main à l’ensemble de l’archive, y compris le dépôt communautaire Universe, ce qui revient à vendre une couverture sur un grand nombre de composants Open Source que la distribution de base n’engage pas. ;
• L’offre de support vise la réassurance pour assurer une usage paisible et fluide des serveur : réception d’un incident, diagnostic, contournement, escalade et, selon le contrat et la phase du cycle de vie, engagement de correction. Le périmètre de support publié par Red Hat illustre cette distinction : installation, usage, configuration et diagnostic en font partie, tandis que les paquets modifiés, les logiciels et pilotes tiers, ainsi que les matériels et hyperviseurs non certifiés sont exclus de cette offre (et couverts, le cas échéant, par d’autres)
• D’autres facteurs centraux s’ajoutent tels que les certifications des matériels et des applications, ou encore la capacité d’exploitation de la DSI (images, dépôts, automatisations, supervision, sauvegarde et compétences internes). Parallèlement, il convient de demander à chaque éditeur métier si sa certification vise la distribution ou le contrat de support qui l’accompagne, et d’accepter que l’accès aux erreurs et à la chaîne d’escalade de l’éditeur d’origine cesse. À noter que les modèles fondés sur la peur comme celui de Novell — qui associait à ses contrats de support de SUSE Linux Enterprise Server un programme de compensation couvrant les actions en violation de droit d’auteur — n’ont pas survécu à la montée en compétences des DSI quant au modèle de l’Open Source.

Le choix est ainsi un choix d’architecture : réunir ces fonctions simplifie les responsabilités, alors que les dissocier ouvre d’autres scénarios, plus complexes mais souvent mieux adaptés. Les entreprises positionnées sur le marché jouent sur les deux tableaux : SUSE indique par exemple, avec son offre Multi-Linux Support, pouvoir maintenir et supporter des systèmes RHEL existants sans migration vers SLES. Un tel scénario suppose d’avoir vérifié la portée, la date de fin et les conditions de résiliation de tout accord de licences encore actif.

Les libertés des logiciels libres et Open Source

Les logiciels libres et Open Source réduisent l’obstacle majeur de l’accès juridique et technique au code, ce qui a permis l’existence de plusieurs distributions, de prestataires indépendants et de trajectoires qui seraient impossibles avec un logiciel entièrement propriétaire. Les offres commerciales reposent néanmoins sur une frontière franche entre ce qu’apporte l’Open Source et ce qu’apportent les services associés. Red Hat indique ainsi que, lorsque toutes les souscriptions d’un client ont expiré, celui-ci conserve le droit d’utiliser le logiciel selon les licences applicables, mais perd l’accès aux versions certifiées, au portail client et au support technique.

À noter que le Cyber Resilience Act va déplacer cette frontière et les modèles économiques associés (au bénéfice des utilisateurs finaux) : à compter du 11 décembre 2027 (les obligations de notification des vulnérabilités activement exploitées s’appliquant dès le 11 septembre 2026), tout fabricant qui met sur le marché un produit comportant des éléments numériques dans le cadre d’une activité commerciale devra traiter les vulnérabilités et fournir des mises à jour de sécurité pendant toute une période d’assistance qu’il lui revient de déterminer et de déclarer. L’éditeur d’une distribution commerciale étant un fabricant au sens du règlement, certaines de ces obligations viendront rebattre les cartes entre produit et service (voir, pour le détail de ces mécanismes, le guide CRA publié avec le CNLL).

La Commission européenne décrit depuis 2013 l’enfermement propriétaire comme la difficulté de changer de fournisseur à l’expiration d’un contrat, parce que les informations indispensables à une reprise efficiente ne sont pas disponibles. À l’échelle d’une organisation et d’une DSI, la seule existence d’une licence Open Source n’est pas suffisante et d’autres enfermements doivent être anticipés car la dépendance peut devenir :

1. Technique, lorsqu’une application ou un agent (interne ou externe) n’est certifié que sur certaines versions ;
2. Opérationnelle, lorsque les images, scripts, procédures et outils ont été construits autour d’un seul socle ;
3. Humaine, lorsque les compétences sont concentrées chez quelques personnes ou un prestataire ;
4. Contractuelle et économique, lorsque les unités de souscription, les extensions de cycle de vie, les clauses de vérification ou la requalification rendent la sortie coûteuse.

Red Hat, est un cas d’école historique et intéressant à approfondir :

• tournée vers le risque, l’offre est incontournable et son modèle a structuré une large part du Linux d’entreprise. RHEL apporte un cycle de vie de dix ans, dont la nature des correctifs se restreint au fil des phases, et que des extensions payantes peuvent prolonger jusqu’à quatorze ans, voire au-delà. S’y ajoutent des correctifs qualifiés, un vaste écosystème certifié et plusieurs niveaux de support. Le tout est bien cadré, avec un modèle de souscription qui se rapproche des modèles d’éditeurs propriétaires. La FAQ de Red Hat sur les souscriptions indique que, pendant la durée d’un accord actif, chaque installation ou instance doit faire l’objet d’une souscription correspondant à son cas d’usage.
• La controverse ouverte en 2023 sur les sources de RHEL apporte un second enseignement. Red Hat a fait de CentOS Stream, branche de développement en amont de RHEL, le dépôt public unique des sources liées à RHEL, tout en maintenant l’accès aux sources RHEL pour ses clients et partenaires via son portail. L’entreprise justifie ce changement par la concentration de ses efforts sur l’amont et par le coût du travail d’intégration et de maintenance de long terme. Cette posture a été contestée dans le milieu de l’Open Source, notamment par la Software Freedom Conservancy, qui considère que cela revient à faire payer l’exercice des droits accordés par les licences libres, tout en reconnaissant que seule une décision de justice trancherait la question.

Ainsi, pour une DSI : une évolution de gouvernance, de publication ou de contrat peut modifier la qualité des options disponibles. C’est l’une des questions instruites dans nos travaux de recherche-action sur la soutenabilité des modèles ouverts : payer la valeur produite et préserver sa liberté de choix ne sont pas contradictoires. La difficulté apparaît lorsque la relation économique rend l’alternative juridiquement possible, mais opérationnellement peu crédible.

Transformer une dépendance subie en décisions révisables

L’Open Source reste bien entendu un sujet stratégique, de plus en plus discuté sous couvert de souveraineté, afin d’assurer que les bénéfices attendus (réversibilité, concurrence entre fournisseurs de maintenance et de support, maîtrise des coûts) soient réels. Pour ce faire, il est nécessaire de comprendre ce que les licences permettent réellement, comment les éditeurs monétisent la maintenance et où se logent les dépendances. Cette culture ne s’improvise pas ; sans elle, une migration « souveraine » reproduit les enfermements qu’elle prétend défaire. C’est l’un des messages du manifeste Open Source publié par Numeum en juillet 2025 : les DSI y cherchent la réversibilité, l’interopérabilité et un modèle économique plus abordable. Le rachat de VMware par Broadcom leur a rappelé brutalement ce qu’il en coûte de dépendre d’un fournisseur.

Une étude utile ne commence pas par un classement des distributions existantes et des alternatives hypothétiques. Elle part du parc réel (et donc des usages réels) et répond à quatre questions évoquées de manière transversales dans les lignes qui précèdent :

• Quelles charges sont réellement exploitées ? Il faut pour cela un inventaire qui relie chaque instance à une criticité, une application, un propriétaire, une date de fin de support et une exigence de certification ;
• Qui a acheté quoi, pour quel usage ? Cela couvre notamment les questions de maintenance, de support, de certification, d’outillage et d’expertise ;
• Où sont les adhérences ? Une dépendance métier ne doit pas être déclarée intangible sans avoir été testée. Deux témoignages de collectivités portent sur le poste de travail, mais leur méthode se transpose. Nicolas Vivant, DSI de la ville de Fontaine, explique s’être rendu sur chaque poste dont l’utilisateur exigeait la suite Microsoft pour identifier avec lui le point bloquant, et décrit la centralisation de tous les budgets informatiques au niveau de la DSI. Olivier Simon, directeur de Nancy Ville Numérique, décrit une politique consistant à faire développer par les prestataires les connecteurs et fonctionnalités manquants, avec obligation de les reverser sur des forges. À l’échelle d’un grand compte, une adhérence peut ainsi devenir un objet d’ingénierie, de négociation ou de mutualisation plutôt qu’une fatalité ;
• Quelles trajectoires restent praticables ? Maintien optimisé, segmentation du support, introduction d’un second socle, changement de mainteneur ou encore migration progressive.

Chaque scénario qui en découle doit comparer le coût du changement au coût du non-changement et préciser ses conditions de sortie. Ce travail peut ensuite être revu périodiquement, dans le cadre d’études internes ou externes. Compte-tenu de l’évolution rapide du secteur, un tel travail ne peut être mené dans la durée que si :

• Les sources soient vérifiables ;
• Le modèle économique soit compris et compatible avec les enjeux de la DSI ;
• les fournisseurs soient entendus ;
• L’équipe qui l’instruit n’ait aucun intérêt dans les solutions comparées ni dans la prolongation du projet ;
• La méthode soit transférée.

Il est aussi de réfléchir à une mise en commun entre DSI, constituant un levier encore insuffisamment employé, mais qui devient de plus en plus tangible. Plusieurs grands utilisateurs peuvent partager des critères de qualification, financer ensemble un connecteur ou une certification, consolider leurs besoins et contribuer aux communautés dont ils dépendent : ils améliorent ainsi leur pouvoir de négociation tout en participant à la soutenabilité de l’écosystème. Les initiatives de TOSIT, association de grands utilisateurs publics et privés, ou d’EuroCommons, lancée par la Caisse des Dépôts en juillet 2026 pour organiser des migrations collectives par coalitions de DSI et d’éditeurs Open Source sont de bons exemples.

Choisir de rester

Une étude sérieuse doit pouvoir conclure que l’existant reste la meilleure option. Elle peut aussi recommander de le conserver pour certaines charges, de le compléter ailleurs, d’en renégocier le support ou de préparer une sortie progressive.

« Quelle distribution remplacera RHEL ? » est une question trop étroite qui doit être élargie:

Quel modèle de socle Linux nous apporte le service attendu, à un coût maîtrisé, tout en préservant les options dont nous aurons besoin dans trois, cinq ou dix ans ?

Le second article de cette série portera sur la conduite de l’étude elle-même : comparer des distributions et des modèles de support sans fabriquer le résultat, chiffrer le changement et le non-changement, tester les hypothèses sur des charges représentatives, et laisser à la DSI de quoi reprendre la décision sans dépendre de ceux qui l’ont instruite.

Image d’en-tête : NOIRLab HQ Server Racks, NOIRLab/NSF/AURA/T. Slovinský, CC BY 4.0, via Wikimedia Commons. Graphiques : inno³, CC BY-SA 4.0, données et sources indiquées en légende.