Quel OS Linux choisir pour votre VPS ?

Quel système d’exploitation choisir pour votre VPS

Le système d’exploitation à choisir pour votre VPS est la version actuelle d’Ubuntu LTS, sauf si l’une des quatre questions ci-dessous vous conduit à opter pour autre chose. LTS signifie « support à long terme » : cinq ans de mises à jour de sécurité gratuites, contre neuf mois. Sur un VPS (virtual private server) qui exécute une application web, une base de données, un game server ou un mail relay, Ubuntu LTS est le choix par défaut le plus sûr. C’est aussi le système d’exploitation supposé par presque tous les tutoriels disponibles sur Internet, y compris les nôtres.

Six distributions méritent votre attention sur un serveur loué : Ubuntu, Debian, CentOS Stream, Rocky Linux, AlmaLinux et Fedora. Elles utilisent le même noyau Linux, le même nginx, le même PostgreSQL et le même OpenSSH. Le logiciel que vous prévoyez d’exécuter est donc rarement le facteur déterminant. Quatre éléments diffèrent, et ils déterminent entièrement le choix : la durée pendant laquelle la version reçoit des correctifs, l’ancienneté des logiciels empaquetés, les instructions que vous pouvez suivre sans les traduire, et la compatibilité du résultat avec Red Hat Enterprise Linux (RHEL).

Si vous êtes encore en train de déterminer l’usage de la machine, la liste des utilisations possibles d’un VPS constitue un meilleur point de départ. ce qu’est réellement un VPS présente les bases nécessaires pour comprendre tout le reste.

Voici la version courte pour chacune d’elles.

• Ubuntu LTS. Le choix par défaut. Choisissez cette distribution, sauf si l’une des sections ci-dessous s’applique à votre cas.
• Debian. Une base plus légère et dont l’évolution est plus lente, avec une équipe de sécurité bénévole et aucun niveau d’offre commerciale.
• Rocky Linux. Une reconstruction de RHEL, à choisir lorsque la plateforme cible doit être compatible avec RHEL.
• AlmaLinux. L’autre reconstruction de RHEL, avec une version compatible avec les anciens processeurs abandonnés par RHEL 10.
• CentOS Stream. Ce que RHEL deviendra ensuite. À choisir lorsque vous développez des logiciels pour RHEL.
• Fedora. Le noyau et le userland les plus récents, avec environ 13 mois de mises à jour par version.

Combien de temps voulez-vous laisser cette machine sans intervention ?

La durée de support détermine la fréquence à laquelle vous devez effectuer des opérations risquées. Répondez donc d’abord à cette question. Lorsqu’une version arrive en fin de vie, les paquets continuent de fonctionner. Rien ne tombe en panne. Le serveur cesse simplement de recevoir des correctifs pour les nouvelles vulnérabilités publiées. Aucun message d’erreur ne l’indique. Personne ne s’en aperçoit avant un audit ou une intrusion. La solution consiste à effectuer une mise à niveau de la distribution sur place ou à reconstruire le serveur avec une image vierge. Dans les deux cas, vous y consacrerez une soirée.

Chaque projet publie ses propres dates de cycle de vie. En partant d’août 2026 et en arrondissant à une décimale, voici la durée de support restante pour chaque version actuelle.

[
  {
    "distro": "Ubuntu 26.04 LTS",
    "years_of_support_left": 4.7,
    "notes": "Free updates to April 2031. Ubuntu Pro extends the same release to April 2036."
  },
  {
    "distro": "Debian 13",
    "years_of_support_left": 2.0,
    "notes": "Debian security team to August 2028. The LTS team then carries it to June 2030."
  },
  {
    "distro": "CentOS Stream 10",
    "years_of_support_left": 3.8,
    "notes": "Ends May 2030, when the RHEL 10 full support phase ends."
  },
  {
    "distro": "Rocky Linux 10",
    "years_of_support_left": 8.8,
    "notes": "Ends May 2035, following the RHEL 10 lifecycle."
  },
  {
    "distro": "AlmaLinux 10",
    "years_of_support_left": 8.8,
    "notes": "Ends May 2035. Adds an x86-64-v2 build for older CPUs."
  },
  {
    "distro": "Fedora 44",
    "years_of_support_left": 0.8,
    "notes": "Released April 2026, ends June 2027. Every Fedora release lasts about 13 months."
  }
]

Les 6 versions reçoivent des correctifs aujourd’hui. C’est l’écart qui compte. Rocky Linux 10 et AlmaLinux 10 disposent encore de 8.8 années de mises à jour, car elles suivent le cycle de vie de dix ans de RHEL, tandis que Fedora 44 n’en dispose plus que de 0.8.

Ubuntu 26.04 LTS dispose encore de 4.7 années de mises à jour gratuites. Ubuntu Pro prolonge cette même installation jusqu’en 2036, sans frais pour un usage personnel sur un petit nombre de machines. Debian 13 affiche 2.0 années, car c’est à cette échéance que l’équipe de sécurité Debian s’arrête. L’équipe LTS bénévole prolonge ensuite le support d’environ deux ans, pour un ensemble plus limité de paquets et d’architectures. Les deux chiffres sont exacts. Ils sont calculés différemment. C’est pourquoi il faut comparer avec prudence les durées de support entre les projets.

Cette question comporte deux pièges. Le premier concerne les versions intermédiaires d’Ubuntu. Elles paraissent tous les six mois et sont prises en charge pendant neuf mois. Ainsi, 25.10 a cessé de recevoir des mises à jour le 1 juillet 2026, alors que ses utilisateurs la considéraient encore comme récente. Pourquoi choisir LTS plutôt qu’une version intermédiaire d’Ubuntu développe cet argument, et c’est la manière la plus courante pour qu’un VPS cesse discrètement d’être corrigé. Le second piège consiste à supposer qu’une nouvelle version impose une réinstallation. Ce n’est pas le cas. La mise à niveau sur place d’Ubuntu 24.04 vers 26.04 est une procédure prise en charge. Debian et les rebuilds de RHEL proposent également leurs propres équivalents.

À quel point les paquets doivent-ils être récents ?

Une distribution stable fige les versions de ses paquets au moment de sa sortie, puis rétroporte les correctifs de sécurité dans ces versions pendant plusieurs années. C’est le compromis que vous acceptez. Debian 13 a figé ses versions à la mi-2025. Le serveur de base de données que vous installez aujourd’hui depuis cette distribution correspond donc à la version disponible à ce moment-là : elle est corrigée, mais pas mise à jour. Ubuntu LTS fonctionne de la même manière. Fedora fait l’inverse et fournit les versions amont actuelles. C’est précisément pour cela que sa période de support est courte : maintenir des branches vieilles de cinq ans est un travail que personne ne veut faire deux fois.

Les anciens paquets ne posent problème que lorsque votre application exige une version plus récente. Avant de choisir une distribution entière pour satisfaire un seul paquet, examinez les solutions de contournement, car elles constituent généralement une meilleure réponse. La plupart des projets amont publient leur propre dépôt. Vous pouvez donc ajouter la source apt ou dnf du fournisseur et obtenir les versions actuelles de ce composant uniquement. Les runtimes de langage disposent de leurs propres gestionnaires de versions. Exécuter l’application dans un conteneur élimine complètement la question, car une stack Docker Compose embarque son propre userland et n’utilise que le kernel.

Toutes ces solutions de contournement ont le même coût. Un paquet fourni par votre distribution est corrigé par l’équipe de sécurité de cette distribution et arrive avec le apt upgrade ou le dnf upgrade habituel. Tout ce que vous ajoutez depuis l’extérieur, c’est à vous de le surveiller et de le corriger le jour où il cesse de fonctionner. Les dépôts supplémentaires sont également une source fréquente d’erreurs dans les fichiers sources, et le nouveau format de sources d’Ubuntu provoque souvent l’erreur de sources apt en double.

Le kernel est une question moins importante qu’on ne le pense. Sur un VPS, le matériel est virtuel et l’hôte fournit les vrais pilotes. Un kernel plus récent apporte donc surtout de nouvelles fonctionnalités réseau et de système de fichiers, plutôt qu’une meilleure prise en charge du matériel. Ubuntu LTS fournit également des kernels d’activation matérielle issus de versions ultérieures. Une installation LTS n’est donc pas bloquée sur le kernel avec lequel elle a été publiée.

Quelle documentation allez-vous suivre ?

C’est la question que l’on sous-estime, et celle qui coûte le plus d’heures. Ubuntu et Debian utilisent les paquets apt et .deb. CentOS Stream, Rocky Linux et AlmaLinux utilisent les paquets dnf et .rpm. Cette différence vous suit bien au-delà de la commande d’installation.

Les noms des paquets diffèrent : le serveur web Apache s’appelle apache2 sur Ubuntu et Debian, et httpd sur la famille RHEL. Le nom du service diffère donc lui aussi. Le pare-feu diffère également : ufw sur Ubuntu, firewalld sur la famille RHEL, avec nftables sous-jacent dans les deux cas. La couche de contrôle d’accès obligatoire diffère aussi, et c’est celle qui pose le plus de problèmes. La famille RHEL exécute SELinux (security enhanced Linux) en mode enforcing par défaut. Un service peut donc se voir refuser l’accès à un fichier dont les permissions l’autorisent clairement. La raison n’apparaît alors que dans l’audit log via ausearch -m AVC. Ubuntu et Debian utilisent AppArmor, qui fournit moins de profils et vous interrompt moins souvent.

Rien de tout cela n’est difficile. C’est un travail de traduction que vous devez répéter dans chaque tutoriel consulté, souvent tard dans la nuit. Si vous utilisez finalement Rocky Linux, AlmaLinux ou Fedora avec une page de commandes Ubuntu sous les yeux, les équivalents de apt vers dnf couvrent la correspondance, y compris les éléments qui n’ont pas d’équivalent direct. Si vous débutez avec les serveurs Linux, cela suffit à justifier le choix d’Ubuntu LTS, car la page d’installation du fournisseur sur laquelle vous arriverez partira de cette distribution. Nos guides font de même : le guide de déploiement de la pile LAMP et le guide Certbot et nginx sont écrits et testés avec Ubuntu, tout comme les dix premières minutes sur un nouveau VPS.

Faut-il adopter Red Hat Enterprise Linux ?

Si la matrice de support d’un éditeur mentionne RHEL, ou si le parc de production de votre entreprise l’utilise, choisissez une distribution compatible avec RHEL et ne considérez plus cela comme une préférence. Rocky Linux et AlmaLinux sont toutes deux compilées à partir des sources de RHEL. Elles maintiennent toutes deux l’ABI (application binary interface) compatible avec RHEL : un RPM compilé pour RHEL 10 s’installe et fonctionne sur l’une ou l’autre. Les agents commerciaux et les outils de conformité ciblent cette plateforme et ne prennent souvent rien d’autre en charge. Il existe deux rebuilds et non un seul parce que Red Hat a arrêté le CentOS d’origine fin 2020 ; l’histoire de cette scission explique qui a fondé chaque projet et ce que chacun avait promis.

Rocky Linux reste aussi proche de RHEL que possible. Depuis la version 9, AlmaLinux vise la compatibilité ABI plutôt que des bits identiques, ce qui lui permet d’ajouter des éléments supprimés par Red Hat. La prise en charge des CPU en est l’exemple le plus clair. RHEL 10 a relevé sa base à x86-64-v3, un niveau de fonctionnalités CPU qui nécessite AVX2, et Rocky Linux 10 suit cette évolution. AlmaLinux 10 a ajouté une architecture x86-64-v2 distincte pour les anciens matériels. Cela compte sur un serveur loué : si votre fournisseur expose un modèle de CPU générique émulé, avx2 peut être absent de lscpu, et un build v3 ne fonctionnera pas. Vérifiez d’abord, puis choisissez AlmaLinux 10 ou restez sur la série 9 si le flag est absent.

CentOS Stream est un produit différent de ces deux rebuilds. Il se situe en amont de RHEL : les changements arrivent d’abord dans Stream, puis dans RHEL lors de la prochaine version mineure. Il est suffisamment stable pour être utilisé en production et évolue en continu, plutôt que par étapes de version mineure. Choisissez-le si vous développez ou testez des logiciels qui doivent fonctionner sur la prochaine version de RHEL, et non sur celle déjà publiée. Il reste 3.8 années de support à CentOS Stream 10, soit moins que pour les rebuilds, car son support s’arrête lorsque RHEL 10 quitte son support complet.

Intérêt de Fedora sur un serveur

Fedora fournit le kernel et le userland les plus récents des six distributions, et prend en charge chaque version pendant environ 13 mois. Cette durée résume tout. Un serveur Fedora doit être mis à niveau environ une fois par an, selon votre calendrier si vous le planifiez, ou selon celui de Fedora si vous ne le faites pas. Si vous sautez deux mises à niveau, la machine n’est plus prise en charge.

Utilisez Fedora sur un serveur lorsque vous avez besoin de versions plus récentes que celles proposées par les distributions stables et que vous acceptez déjà ce rythme de mise à niveau, par exemple pour une machine de build personnelle ou un poste de développement que vous reconstruisez régulièrement. Ne l’utilisez pas sur une machine dont vous voulez pouvoir vous désintéresser. Fedora 43 ne recevra plus de mises à jour en décembre 2026, environ 14 mois après sa sortie. Le projet fonctionne alors comme prévu, il n’est pas en échec.

Ce qu’un mauvais choix coûte réellement

Réinstaller un VPS est une opération du panneau de contrôle qui prend quelques minutes. Changer d’avis ne coûte donc rien le premier jour, mais peut coûter cher deux cents jours plus tard. Il n’existe aucune méthode prise en charge pour convertir Ubuntu en AlmaLinux sur place. Prenez votre décision avant de stocker des données sur la machine.

Deux habitudes permettent de garder cette décision réversible. Conservez votre configuration dans un script plutôt que dans l’historique de votre shell. Ainsi, une reconstruction rejoue les étapes au lieu de les laisser dans votre mémoire : un premier playbook Ansible suffit pour un serveur unique. Vérifiez ensuite qui gère réellement le système d’exploitation, car avec une offre de VPS administré, le fournisseur peut imposer le choix et le calendrier des mises à jour.

Le choix par défaut reste le même. Choisissez Ubuntu LTS. Choisissez Debian si vous voulez une base plus légère, sans couche commerciale. Choisissez Rocky Linux ou AlmaLinux lorsqu’un logiciel exige la compatibilité RHEL. Choisissez CentOS Stream si vous développez pour RHEL. Choisissez Fedora uniquement si la mise à niveau annuelle figure déjà dans votre calendrier.

FAQ

Quelle distribution Linux choisir pour un VPS lorsque l’on débute avec Linux ?

La version actuelle d’Ubuntu LTS. Deux raisons principales le justifient. Presque toutes les pages d’installation de logiciels tiers donnent d’abord une commande Ubuntu. Vous pouvez donc la coller sans devoir la traduire. Chaque version LTS reçoit aussi cinq ans de mises à jour de sécurité gratuites. Rien ne vous oblige donc à effectuer une mise à niveau pendant votre première année. Debian constitue un deuxième choix raisonnable si vous voulez une base plus légère et si vous êtes à l’aise avec la lecture d’une documentation écrite pour apt en général, plutôt que spécifiquement pour Ubuntu.

Debian ou Ubuntu est-il préférable pour un serveur ?

Ce sont des distributions très proches. Ubuntu est basée sur Debian, utilise apt, et la plupart des instructions Debian y fonctionnent sans modification. Debian installe moins de composants par défaut, ne propose pas de niveau de support commercial et laisse les bénévoles assurer la maintenance de sécurité pendant les dernières années d’une version. Ubuntu fige une version LTS tous les deux ans, à une date prévisible, et prolonge son support jusqu’à dix ans avec Ubuntu Pro. C’est aussi la distribution ciblée par la plupart des documentations des éditeurs. Choisissez Debian si vous voulez une base minimale que vous comptez conserver pendant des années. Choisissez Ubuntu si vous voulez que la documentation corresponde aux commandes saisies.

Dois-je utiliser Rocky Linux ou AlmaLinux ?

Les deux sont des reconstructions gratuites de RHEL, prises en charge jusqu’en mai 2035. Les deux choix sont donc défendables. Rocky Linux suit RHEL d’aussi près que possible. Cette distribution convient à une matrice de support éditeur stricte sur la plateforme. AlmaLinux vise plutôt la compatibilité ABI. Elle peut ainsi fournir des composants supplémentaires, notamment une build x86-64-v2 pour les CPU qui n’atteignent pas le niveau de référence x86-64-v3 requis par RHEL 10. Sur un VPS équipé d’un CPU ancien ou émulé de manière générique, cette build justifie le choix d’AlmaLinux.

Puis-je exécuter Fedora sur un serveur ?

Oui, mais il faut accepter son calendrier de mise à niveau. Chaque version de Fedora est prise en charge pendant environ 13 mois. Le serveur doit donc effectuer une mise à niveau de version environ une fois par an. Il cesse de recevoir des mises à jour de sécurité si vous en ignorez deux. Choisissez Fedora si vous avez besoin d’un kernel ou d’une toolchain très récente et si vous effectuerez réellement ces mises à niveau. Pour une machine que vous voulez laisser fonctionner sans intervention, choisissez plutôt une version LTS ou enterprise.

La distribution modifie-t-elle les performances d’un VPS ?

Pas d’une manière que vous pourrez probablement mesurer. Ces distributions utilisent le même kernel et les mêmes logiciels serveur. Un benchmark de nginx sur Ubuntu comparé à nginx sur Rocky Linux mesure donc surtout votre configuration. RHEL 10 compile bien ses paquets avec le niveau de référence CPU x86-64-v3. Cela apporte un léger gain sur le matériel moderne, mais ce n’est pas une base solide pour choisir un système d’exploitation. Votre disque et la configuration de votre base de données déterminent le débit.