SSD Nodes Learn 🎉 VPS dès $5.50/mois
Guides Matt ConnorPar Matt Connor

Quel OS Linux choisir pour votre VPS ?

Ubuntu LTS par défaut, ou Debian, Rocky, AlmaLinux, CentOS Stream et Fedora : comparez support, fraîcheur des paquets, compatibilité RHEL et documentation.

Quel OS choisir pour votre VPS

Pour votre VPS, choisissez la version LTS actuelle d’Ubuntu, sauf si l’une des quatre questions ci-dessous vous oriente vers une autre distribution. LTS signifie « support à long terme » : cinq ans de mises à jour de sécurité gratuites, contre neuf mois. Sur un VPS (virtual private server) qui héberge 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 la grande majorité des 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 packagés, les instructions que vous pouvez suivre sans les traduire et la compatibilité du résultat avec Red Hat Enterprise Linux (RHEL).

Si vous cherchez encore à déterminer l’usage de la machine, la liste des utilisations possibles d’un VPS constitue un meilleur point de départ. La page qui explique 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. Prenez cette distribution, sauf si l’une des sections ci-dessous s’applique à votre cas.
  • Debian. Une base plus réduite, dont l’évolution est plus lente, avec une équipe de sécurité bénévole et aucun niveau de support commercial.
  • Rocky Linux. Une reconstruction de RHEL, à utiliser lorsque la plate-forme cible doit être compatible avec RHEL.
  • AlmaLinux. L’autre reconstruction de RHEL, avec une version compatible avec les anciens CPU abandonnés par RHEL 10.
  • CentOS Stream. Ce que RHEL deviendra ensuite. Utilisez-la lorsque vous développez des logiciels pour RHEL.
  • Fedora. Le noyau et l’espace utilisateur 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 devrez 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 plante. Le serveur cesse simplement de recevoir des correctifs pour les vulnérabilités nouvellement publiées. Aucun message d’erreur ne l’indique. Personne ne s’en aperçoit avant un audit ou une compromission. La solution consiste à effectuer une mise à niveau de la distribution sur place ou à reconstruire le système à partir d’une image vierge. Dans les deux cas, vous y consacrerez une soirée.

Chaque projet publie ses propres dates de cycle de vie. À partir d’août 2026 et avec un arrondi à une décimale, voici la durée de support restante pour chaque version actuelle.

ChartYears of security support left on each current release, August 2026
The data behind this chart
[
  {
    "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."
  }
]

Toutes les 6 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 la prise en charge de la même installation jusqu’en 2036, gratuitement 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 cesse son support. L’équipe LTS bénévole prolonge ensuite la prise en charge d’environ deux années supplémentaires, pour un ensemble plus restreint de paquets et d’architectures. Les deux chiffres sont exacts. Ils sont calculés différemment. C’est pourquoi il faut être prudent lorsque vous comparez les durées de support entre projets.

Cette question comporte deux pièges. Le premier concerne les versions intermédiaires d’Ubuntu. Elles sortent 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 préférer une version LTS à une version intermédiaire d’Ubuntu développe cet argument. C’est aussi la cause la plus fréquente d’un VPS qui devient discrètement non corrigé. Le deuxième 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 reconstructions de RHEL proposent leurs propres équivalents.

Quelle doit être la nouveauté des paquets ?

Une distribution stable fige les versions de ses paquets lors de sa publication, puis rétroporte les correctifs de sécurité dans ces versions pendant des 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 actuelle de cette période. Il est corrigé, mais pas mis à jour. Ubuntu LTS fonctionne de la même manière. Fedora fait l’inverse et fournit les versions actuelles de l’amont. C’est précisément pour cela que sa période de support est courte : personne ne veut maintenir deux fois des branches vieilles de cinq ans.

Les anciens paquets ne posent problème que si votre application exige une version plus récente. Avant de choisir toute une distribution pour satisfaire un seul paquet, examinez les solutions de repli. 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 seul composant. 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 contient son propre userland et utilise uniquement le kernel.

Toutes ces solutions de repli 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 doit être surveillé et corrigé par vos soins le jour où cela cesse de fonctionner. Les dépôts supplémentaires sont également une source fréquente d’erreurs dans les fichiers de sources. 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 fonctions réseau et de nouveaux systèmes de fichiers, plutôt qu’une meilleure prise en charge du matériel. Ubuntu LTS fournit également des kernels HWE issus de versions ultérieures. Une installation LTS n’est donc pas limitée au kernel fourni lors de sa publication.

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 distinction vous suivra 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 firewall est différent : 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 également, et c’est elle 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 alors que ses permissions l’y 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. Il s’agit d’un travail de traduction que vous répétez pour chaque tutoriel consulté, souvent tard le soir. Si vous débutez avec les serveurs Linux, c’est déjà une raison suffisante pour choisir 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 la stack 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 utiliser la même distribution que Red Hat Enterprise Linux ?

Si la matrice de support d’un éditeur mentionne RHEL ou si votre parc de production utilise cette distribution, choisissez une distribution compatible avec RHEL. Ce n’est plus une préférence. Rocky Linux et AlmaLinux sont toutes deux compilées à partir des sources de RHEL. Elles maintiennent une ABI (application binary interface) stable par rapport à RHEL. Un RPM compilé pour RHEL 10 s’installe et fonctionne donc 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.

Rocky Linux reste aussi proche que possible de RHEL. Depuis la version 9, AlmaLinux vise la compatibilité ABI plutôt que l’identité binaire. Cette approche lui permet d’ajouter des éléments que Red Hat a supprimés. La prise en charge des processeurs en est l’exemple le plus clair. RHEL 10 a relevé sa base matérielle à x86-64-v3, un niveau de fonctionnalités du processeur 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 processeur émulé générique, avx2 peut être absent de lscpu, et une version compilée pour 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 reconstructions. Il se situe en amont de RHEL. Les modifications arrivent donc d’abord dans Stream, puis dans RHEL lors de la prochaine version mineure. Cette distribution est suffisamment stable pour la production et évolue en continu, au lieu de progresser par versions mineures. Choisissez-la si vous développez ou testez des logiciels qui doivent fonctionner avec la prochaine version de RHEL, et non avec la version déjà publiée. Il reste 3.8 années de support à CentOS Stream 10, soit moins que pour les reconstructions, car son support prend fin lorsque RHEL 10 quitte la phase de support complet.

Quelle place Fedora occupe sur un serveur

Fedora fournit le noyau et l’espace utilisateur les plus récents des six distributions, et prend en charge chaque version pendant environ 13 mois. Ce chiffre résume tout. Un serveur Fedora doit être mis à niveau environ une fois par an : selon votre calendrier si vous planifiez l’opération, ou selon celui de Fedora dans le cas contraire. Si vous ignorez deux mises à niveau, la machine n’est plus prise en charge.

Utilisez Fedora sur un serveur lorsque vous avez besoin de logiciels plus récents que ceux proposés par toute distribution stable et que vous acceptez déjà ce rythme de mise à niveau, par exemple sur une machine de build personnelle ou un poste de développement que vous réinstallez souvent. Ne l’utilisez pas sur une machine que vous voulez pouvoir oublier. Fedora 43 cesse de recevoir des mises à jour en décembre 2026, environ quatorze mois après sa sortie. Le projet fonctionne ainsi comme prévu ; il ne s’agit pas d’une défaillance.

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

Réinstaller un VPS est une opération disponible dans le control panel qui ne prend que quelques minutes. Changer d’avis ne coûte donc rien le premier jour, mais peut devenir très pénalisant au bout de deux cents jours. Il n’existe pas de méthode prise en charge pour convertir Ubuntu en AlmaLinux sur place. Prenez votre décision avant de placer des données sur la machine.

Deux habitudes permettent de garder ce choix 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 dépendre de ce dont vous vous souvenez : 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 managé, le fournisseur peut imposer à la fois le choix du système et le calendrier des mises à jour.

La recommandation par défaut reste valable. 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 nécessite la compatibilité RHEL. Choisissez CentOS Stream si vous préparez un environnement pour RHEL. Choisissez Fedora uniquement si la mise à niveau annuelle figure déjà dans votre calendrier.

FAQ

Quelle distribution Linux choisir pour un VPS quand on débute avec Linux ?

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

Debian ou Ubuntu sont-elles meilleures pour un serveur ?

Ce sont des distributions proches. Ubuntu est basée sur Debian, utilise apt, et la plupart des instructions Debian fonctionnent sans modification. Debian installe moins de composants par défaut, ne propose pas de niveau de support commercial et confie les dernières années d’une version aux bénévoles pour les mises à jour de sécurité. Ubuntu fige une version LTS tous les deux ans, à une date prévisible, la prolonge jusqu’à dix ans avec Ubuntu Pro et constitue la cible de la plupart des documentations des éditeurs. Choisissez Debian pour une base minimale que vous comptez conserver pendant des années. Choisissez Ubuntu si vous voulez que la documentation corresponde à ce que vous avez saisi.

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 se défendent donc. Rocky Linux suit RHEL aussi étroitement que possible. Cette approche convient à une matrice de support éditeur stricte concernant la plateforme. AlmaLinux vise plutôt la compatibilité ABI. Elle peut ainsi publier des composants supplémentaires, notamment une build x86-64-v2 pour les processeurs qui n’atteignent pas le niveau de référence x86-64-v3 requis par RHEL 10. Sur un VPS équipé d’un processeur ancien ou émulé de manière générique, cette build justifie le choix d’AlmaLinux.

Puis-je utiliser 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 être mis à niveau environ une fois par an. Il cesse de recevoir des mises à jour de sécurité si vous ignorez deux mises à niveau. Choisissez Fedora si vous avez besoin d’un noyau 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 une version enterprise.

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

Pas d’une manière que vous pourrez probablement mesurer. Les distributions utilisent le même noyau 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 x86-64-v3 comme niveau de référence du processeur. Cela apporte un léger gain sur le matériel récent, 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.