NixOS transforme votre serveur en un fichier texte rebuildable à l’identique

Le 30 novembre 2025, NixOS publie sa version 25.11 « Xantusia ». Le projet réunit 2 857 contributeurs sur le cycle précédent et franchit la barre des 100 000 paquets dans nixpkgs — le plus grand dépôt de paquets de l’écosystème Linux, également classé numéro un sur Repology pour la fraîcheur des versions. En avril 2026, la distribution maintient son rythme semestriel de releases stables et enfonce un clou que le monde DevOps feint encore d’ignorer : un serveur Linux peut être un fichier texte de 200 lignes, rebuildé à l’identique sur n’importe quelle machine, sans jamais dériver.

NixOS n’est pas une distribution Linux comme les autres

NixOS n’est pas une énième déclinaison de Debian ou d’Arch. C’est une distribution construite intégralement autour du Nix package manager, un gestionnaire de paquets purement fonctionnel conçu par Eelco Dolstra dans le cadre de sa thèse de doctorat en 2006 à l’Université d’Utrecht. Le principe est simple : chaque paquet est stocké dans /nix/store/ sous un hash cryptographique unique qui encode l’intégralité de son graphe de dépendances — version du compilateur, flags de build, bibliothèques liées. Deux paquets ne peuvent pas entrer en conflit parce qu’ils n’occupent jamais le même chemin.

Le système d’exploitation lui-même est décrit dans un unique fichier /etc/nixos/configuration.nix (ou un flake.nix depuis la généralisation des flakes en 2025). Ce fichier déclare l’intégralité de l’état souhaité : paquets installés, services actifs, utilisateurs, règles de pare-feu, conteneurs, machines virtuelles, configurations systemd. Une seule commande applique l’état :

nixos-rebuild switch

Cette commande ne « met pas à jour » le système au sens classique. Elle construit une nouvelle génération, l’ajoute au menu de boot, et bascule dessus atomiquement. L’ancienne génération reste disponible. Si quelque chose casse, un redémarrage sur la génération précédente ramène le serveur à son état antérieur en moins de 30 secondes.

La boutique : 100 000 paquets et le plus frais de la planète

Nixpkgs est le dépôt de paquets commun à NixOS et au gestionnaire Nix autonome (utilisable sur macOS, WSL et toute distribution Linux). Au 30 novembre 2025, nixpkgs comptabilise :

• 7 002 nouveaux paquets ajoutés pendant le cycle 25.11
• 25 252 paquets existants mis à jour
• 6 338 paquets obsolètes supprimés
• 107 nouveaux modules NixOS et 1 778 options de configuration ajoutées

Ces chiffres ne sont pas anecdotiques. Ils traduisent un rythme de maintenance que seul Arch Linux approche dans l’écosystème Linux — mais nixpkgs couvre quatre fois plus de paquets que l’AUR. Repology le classe systématiquement premier pour le nombre total de paquets ET pour le pourcentage de paquets à jour.

Le noyau par défaut est le Linux 6.17 (le 6.12 LTS reste disponible). GNOME 49 est livré sans session X11 — un choix qui signale la direction : NixOS n’a pas peur de casser la rétrocompatibilité quand la migration est documentée. LLVM 21 et GCC 14 sont disponibles en parallèle, ce qui en fait une plateforme de choix pour les développeurs qui compilent du Rust, du Go ou du C++ moderne.

Le stockage en /nix : pourquoi votre serveur ne dérive jamais

Pour comprendre NixOS, il faut comprendre /nix/store/. Chaque paquet y est installé sous un chemin du type :

/nix/store/v5pzi9x8wj6h1lzr3p0k7d4nq2by9amc-nginx-1.28.0/

Le hash en préfixe encode toutes les entrées qui ont produit le binaire : le code source, les patches, les flags de compilation, les dépendances, et même la version du compilateur. Si une seule de ces entrées change, le hash change — et le paquet est reconstruit dans un nouveau chemin. L’ancien paquet reste intact.

Cette propriété a trois conséquences directes pour l’administration de serveurs :

• Pas de conflits de dépendances. Deux applications peuvent exiger deux versions différentes de OpenSSL sans que l’administrateur ait à gérer des /usr/local ou des conteneurs ad hoc.
• Mises à jour atomiques. nixos-rebuild switch ne remplace jamais un binaire en cours d’exécution. Il construit la nouvelle génération à côté, puis bascule. Si le service plante après la bascule, le rollback est immédiat — pas de session SSH perdue sur un apt upgrade qui a mal tourné.
• Reproductibilité totale. Le même configuration.nix (ou flake.lock) produit exactement les mêmes binaires sur deux machines différentes. Pas de « ça marche sur mon poste », pas de dérive de configuration entre la staging et la production.

Flakes et Home Manager : la stack NixOS moderne

Depuis 2025, l’écosystème Nix s’est stabilisé autour de deux briques qui changent la donne pour les équipes.

Les flakes (stabilisés dans Nix 2.24, novembre 2024) remplacent le traditionnel configuration.nix par un format qui verrouille les versions des entrées — un peu comme un Cargo.lock ou un package-lock.json, mais pour l’intégralité d’un système d’exploitation. Un flake.nix déclare des inputs (une version précise de nixpkgs, un dépôt home-manager, un outil perso) et des outputs (la configuration NixOS, des paquets, des templates de projet). Le flake.lock fige chaque input à un commit précis. Résultat : deux ingénieurs qui partagent le même dépôt Git construisent exactement le même OS, bit pour bit.

Home Manager est un module Nix qui applique le même principe déclaratif au niveau utilisateur : shell, éditeur, thème GTK, extensions GNOME, fichiers de configuration — le tout dans ~/.config/home-manager/home.nix. Combiné à un flake.nix, il permet de provisionner un poste de développement complet en une commande :

nixos-rebuild switch --flake .#mon-serveur

L’intérêt pour les équipes n’est pas seulement la reproductibilité — c’est la vitesse de reconstruction. Un serveur qui brûle est reconstruit en 20 minutes (temps de compilation compris) sur un VPS neuf, sans inventaire manuel, sans playbook Ansible qui échoue à l’étape 7 parce que le dépôt Ubuntu n’a plus la bonne version de libssl.

NixOS contre Ansible et Docker : une comparaison qui réorganise les responsabilités

Le tableau ci-dessous compare les trois approches sur les critères qui comptent en production — pas sur le confort du développeur au premier jour.

Ansible applique une convergence : il compare l’état courant à l’état désiré et exécute les tâches nécessaires pour combler l’écart. Si une tâche échoue silencieusement — un fichier corrompu, un package partiellement installé — l’écart persiste sans que l’opérateur le sache. NixOS ne compare rien : il reconstruit l’état à partir de zéro et remplace l’ancien. La différence est philosophique, mais elle se mesure en appels à 3 h du matin.

Docker résout le problème de reproductibilité au niveau applicatif, pas au niveau du système hôte. Vous pouvez déployer une image immuable sur un hôte qui dérive depuis six mois — les deux couches coexistent sans que personne ne sache exactement ce qui tourne sous le capot. NixOS remonte la garantie d’immutabilité au niveau de l’OS : pas de apt upgrade oublié, pas de pip install sauvage qui traîne dans /usr/local, pas de différence entre la machine de staging et la production.

La vérité opérationnelle : NixOS n’est pas un remplacement direct d’Ansible ou de Docker. Il se combine avec les deux — NixOS comme OS de base, Docker pour les workloads conteneurisés, Ansible réduit à un simple ansible-playbook -i inventory deploy.yml qui ne fait plus que lancer nixos-rebuild sur les cibles. Dans cette architecture, Ansible ne gère plus la configuration — il ne fait que déclencher la reconstruction déclarative à distance.

Ce que NixOS vous coûte vraiment

Le prix d’entrée n’est pas en euros. Il se paie en temps d’apprentissage.

Le langage Nix est un langage fonctionnel pur, paresseux, avec une syntaxe qui ressemble à du JSON sans être du JSON. Écrire une dérivation simple demande de comprendre les fixed points, les overlays et la différence entre callPackage et import. La documentation officielle est exhaustive mais peu didactique — la communauté a comblé le vide avec des ressources comme nix.dev, Zero to Nix (Determinate Systems) et le NixOS Wiki.

Pour un ingénieur qui maîtrise déjà Ansible et Docker, le seuil de productivité se situe autour de deux semaines à temps plein. Passé ce cap, la configuration d’un nouveau service suit un patron répétable :

services.nginx = {
  enable = true;
  recommendedProxySettings = true;
  virtualHosts."monapp.example.com" = {
    forceSSL = true;
    enableACME = true;
    locations."/" = {
      proxyPass = "http://127.0.0.1:3000";
    };
  };
};

Ce bloc de 10 lignes remplace un fichier de configuration nginx de 60 lignes, un playbook Ansible de 30 lignes pour installer le certificat Let’s Encrypt, et une tâche cron pour le renouvellement automatique. NixOS embarque tout cela nativement dans le module services.nginx.

Le vrai coût caché, c’est la dette d’abstraction : quand un service n’a pas de module NixOS officiel, l’utilisateur doit écrire sa propre dérivation ou activer le service via systemd.services.<nom> en mode impératif — ce qui annule une partie du bénéfice déclaratif. Heureusement, les 1 778 options ajoutées dans la 25.11 couvrent l’essentiel des services utilisés en production (PostgreSQL, Redis, Caddy, Nginx, Prometheus, Grafana, Tailscale, WireGuard…), et la communauté maintient un rythme d’ajout soutenu.

Verdict : à partir de trois serveurs, NixOS rattrape son investissement

NixOS n’est pas un choix rentable pour un VPS unique. Pour un serveur solitaire, Debian + Docker Compose + un apt upgrade mensuel suffisent et le temps d’apprentissage de Nix ne sera jamais amorti.

À partir de trois serveurs, l’équation bascule. La reproductibilité bit-à-bit élimine les dérives de configuration entre les environnements. Le rollback atomique transforme les mises à jour risquées en opérations réversibles en 30 secondes. Et la configuration déclarative centralisée dans un dépôt Git fait du git push le nouveau ssh serveur && vim /etc/nginx/nginx.conf.

Si votre parc dépasse dix machines, la question n’est plus de savoir si NixOS vaut l’investissement — elle est de savoir combien de temps vous allez continuer à patcher des dérives de configuration à la main. Ansible et Docker ne disparaissent pas, mais ils changent de rôle : Ansible devient un simple lanceur de nixos-rebuild, et Docker reste le runtime pour les applications qui n’ont pas de module natif. NixOS prend la place que ni l’un ni l’autre n’a jamais réussi à occuper proprement : la couche zéro, celle qui garantit que tous vos serveurs tournent exactement la même chose.

Références

• NixOS 25.11 Release Announcement — NixOS Foundation, 30 novembre 2025
• NixOS 25.05 Release Announcement — NixOS Foundation, 23 mai 2025
• Repology — Repository Statistics — consulté en avril 2026
• NixOS Wiki — Flakes — consulté en avril 2026
• Home Manager Manual — Nix Community, consulté en avril 2026
• Phoronix, « NixOS 25.11 Released With 7,002 New Packages Added » — 30 novembre 2025
• Linuxiac, « NixOS 25.11 Ships with GNOME 49, Linux Kernel 6.17 » — 30 novembre 2025