NixOS pour développeurs et serveurs : reproductibilité totale en 2026

NixOS, le pari de la reproductibilité totale

Quand un nouveau collègue arrive et qu’il doit cloner trois dépôts, installer Node 18, Postgres 14, lancer une vieille version de Redis et patcher un fichier /etc/hosts avant de pouvoir compiler le projet, la machine devient un brouillon. Chaque poste de travail diverge silencieusement : la production tourne sur Debian 12, le poste du dev sur Ubuntu 24.04, le CI sur une image Docker qui date d’il y a six mois. It works on my machine n’est pas un meme, c’est un mode de défaillance.

NixOS prend ce problème par la racine. Plutôt que d’installer des paquets et d’éditer des fichiers de configuration au fil de l’eau, on décrit l’état complet de la machine — paquets, services, utilisateurs, fichiers de configuration, version du noyau — dans un fichier déclaratif. nixos-rebuild switch applique cette description et garantit que deux machines partant du même fichier produiront le même système, octet près. Cette page rassemble les concepts, le vocabulaire et le parcours d’apprentissage pour passer de la curiosité à la production sur NixOS 25.11 « Xantusia ».

Pourquoi NixOS et pourquoi maintenant

NixOS n’est plus une curiosité de laboratoire. Plusieurs signaux convergent en 2026 : la version stable 25.11 a basculé nixos-rebuild-ng (réécriture Python du gestionnaire) par défaut, le projet nixos-init en Rust permet désormais de booter sans interpréteur, et l’écosystème de flakes a mûri au point que de grosses bases de code (terraform-providers, infrastructures Hetzner/Hetzner Cloud, fermes de runners GitHub) tournent en production sur NixOS. Le manuel officiel maintient une cadence de release tous les six mois (mai et novembre), et la 26.05 sortira fin mai 2026.

La promesse pratique tient en quatre points. Atomicité : un changement de configuration produit une nouvelle « génération » sans casser l’existante ; un boot rate pousse à un menu GRUB qui propose toutes les anciennes configurations. Reproductibilité : un flake.lock fige les hashes des dépendances comme un package-lock.json, mais pour le système entier. Isolation : nix develop donne à chaque projet son interpréteur Python ou Node sans toucher au système, sans asdf, sans pyenv, sans nvm. Multi-cible : la même description génère un poste de travail, un serveur SSH-only, une AMI EC2, un ISO live ou une image Docker.

Le coût d’entrée est réel. Le langage Nix est paresseux, dynamique, fonctionnel pur ; sa syntaxe surprend la première semaine. Les messages d’erreur sont parfois cryptiques. La culture documentaire est éclatée entre le manuel officiel, le wiki officiel wiki.nixos.org (relancé en avril 2024 à partir du contenu de l’ancien nixos.wiki), les tickets GitHub et les blogs d’opérateurs comme tweag.io ou jade.fyi. Cette page principale donne la carte ; les tutoriels qui la suivent fournissent les itinéraires.

Les concepts fondamentaux à intérioriser

Le store : /nix/store

Tout paquet, tout fichier de configuration généré, toute version d’un binaire vit sous un chemin du type /nix/store/abc123...-firefox-128.0/. Le préfixe abc123 est un hash qui dépend des sources, des dépendances et des options de compilation. Deux machines qui demandent exactement la même chose obtiennent le même hash, donc le même chemin. Si vous changez une option de compilation de Firefox, le hash change : Firefox-avec-cette-option et Firefox-sans-cette-option coexistent dans le store. Aucune mise à jour ne casse une version précédente, parce que rien n’écrase rien.

Les dérivations

Une dérivation est la recette de fabrication d’un chemin du store : sources, build script, dépendances, plateforme. Le langage Nix sert à écrire ces recettes. Quand vous évaluez nixpkgs.firefox, Nix calcule la dérivation correspondante (un fichier .drv) puis lance la compilation, ou récupère le résultat depuis le cache binaire cache.nixos.org si le hash existe déjà.

Les générations

Chaque nixos-rebuild switch produit une génération numérotée. nix-env --list-generations --profile /nix/var/nix/profiles/system liste l’historique. Pour rouler un changement, il suffit de lancer nixos-rebuild switch --rollback ou de redémarrer en sélectionnant l’ancienne entrée GRUB. Cette propriété est ce qui rend NixOS sûr en production : un déploiement raté ne nécessite ni snapshot LVM, ni image disque, ni câble série. La machine boote sur la dernière génération qui marchait.

Les flakes et flake.lock

Un flake est un dépôt git qui expose une API Nix standardisée : devShells, packages, nixosConfigurations, nixosModules. Le fichier flake.lock fige les commits exacts des inputs (nixpkgs, home-manager, agenix…) pour que nix build de demain donne le même résultat que nix build d’aujourd’hui. Les flakes restent techniquement marqués « experimental » dans le manuel officiel, mais la quasi-totalité de l’écosystème moderne — incluant nixos-rebuild en mode flake, deploy-rs, colmena, nix-darwin — repose dessus. C’est le format à apprendre en 2026.

Le langage Nix en cinq idées qu’il faut comprendre

Le langage Nix ressemble par moments à JSON, par moments à Haskell, et c’est cette dualité qui dérange au début. Tout est expression, rien n’est instruction. Un fichier Nix valide est une seule expression qui s’évalue vers une valeur. Pas de séquencement, pas de boucle for impérative ; on construit des listes, des attributs, des fonctions. Cette contrainte est ce qui permet à Nix d’être pur et reproductible : la même expression évaluée deux fois donne la même valeur.

Les attributs sont la structure de base. { name = "alice"; age = 30; } est un attrset (record) ; on accède aux champs avec . ou via let ... in. Les modules NixOS sont essentiellement de gros attrsets imbriqués où vous écrivez services.nginx.enable = true;. Le système d’options et de modules transforme ces attributs en configuration concrète.

Les fonctions sont anonymes et currifiées. x: y: x + y définit une fonction à deux arguments. (x: x * 2) 21 appelle la fonction sur 21 et donne 42. Quand vous lisez un flake, le bloc outputs = { self, nixpkgs, ... }: { ... } est exactement cela : une fonction qui reçoit les inputs déstructurés et renvoie un attrset d’outputs.

L’évaluation est paresseuse. Une valeur n’est calculée que quand quelque chose la lit vraiment. C’est ce qui rend nixpkgs viable : la collection contient 90 000+ paquets, mais évaluer nixpkgs.firefox ne touche pas nixpkgs.libreoffice. C’est aussi ce qui rend les erreurs parfois opaques : la trace pointe vers le moment où la valeur a été forcée, pas vers l’endroit où elle a été définie.

Le système de modules absorbe la complexité. Quand vous écrivez services.postgresql.enable = true;, vous touchez une option déclarée dans nixos/modules/services/databases/postgresql.nix. Le module définit un type, une valeur par défaut, une description, et la traduction vers la configuration concrète (unité systemd, fichiers de config, scripts d’init). Lire un module bien écrit est la meilleure pédagogie pour apprendre Nix.

La carte du territoire : ce que vous allez vraiment manipuler

Sur un poste de travail NixOS, deux fichiers concentrent la quasi-totalité de la configuration. configuration.nix (ou flake.nix selon le style) décrit le système : paquets installés globalement, services activés (sshd, postgresql, nginx), utilisateurs, montages, paramètres réseau, version du noyau. home.nix, géré par le projet home-manager, décrit l’environnement utilisateur : dotfiles, fonts, configuration Neovim ou VS Code, alias shell, GPG, SSH. La frontière entre les deux est explicite : ce qui appartient à toutes les sessions du système est dans la config système, ce qui appartient à votre identité utilisateur est dans home-manager.

Pour le développement, on ne pollue plus son $HOME avec des installations globales. Chaque projet déclare son flake.nix qui expose un devShell avec exactement la version de Node, Python, Rust, des outils de build et des paquets système (libssl, openssl, postgresql_16) dont il a besoin. nix develop à la racine du projet vous laisse tomber dans un shell où ces outils sont disponibles, et seulement ceux-là. Plus de conflit entre Node 18 d’un projet et Node 22 d’un autre. Si vous utilisez direnv avec nix-direnv, l’environnement charge automatiquement à l’entrée du dossier.

Pour le déploiement, le même fichier flake.nix qui décrit votre serveur peut être appliqué localement (nixos-rebuild switch --flake .#monServeur) ou à distance (nixos-rebuild switch --flake .#monServeur --target-host root@1.2.3.4). Les outils plus avancés comme colmena ou deploy-rs orchestrent le rebuild de plusieurs hôtes en parallèle avec rollback automatique en cas d’échec health-check.

Les tutoriels de la série

Cette page rassemble la vue d’ensemble. Les guides détaillés ci-dessous prennent chaque brique et la déroulent en pas-à-pas vérifié, avec sortie attendue à chaque étape :

• Installer NixOS 25.11 sur un poste de travail — partition GPT/UEFI, formatage ext4, LUKS, premier nixos-rebuild switch.
• Flakes : essentiels et premier projet reproductible — schéma d’un flake, flake.lock, mise à jour des inputs, nix flake show et nix flake check.
• Home-Manager : prendre le contrôle de votre environnement utilisateur — installation standalone ou en module NixOS, gestion des dotfiles, premiers programmes (zsh, git, neovim) déclarés.
• Dev-shells par projet avec nix develop — un flake.nix minimal pour un projet Node + Postgres, intégration direnv, partage entre coéquipiers.
• nixos-rebuild remote : pousser une configuration sur un serveur distant — clé SSH, --target-host, --build-host, gestion des bandwidth limités.
• Gérer les secrets avec agenix — chiffrement par clés SSH publiques, intégration au flake, déploiement de secrets sans les commit en clair.
• CI Nix : intégration continue avec flakes — GitHub Actions, cache binaire cachix, nix flake check en pipeline, partage du store entre runs.
• Build d’un ISO NixOS et d’une AMI EC2 sur mesure — nixos-generators, image bootable USB pour récupération, AMI déposable sur AWS.

Comment situer NixOS face à Ansible, Docker, Guix

NixOS occupe une place que ni Ansible, ni Docker, ni Terraform ne couvrent. Ansible est un orchestrateur impératif : il décrit des étapes (installe ce paquet, modifie ce fichier, redémarre ce service) et exécute ces étapes dans l’ordre via SSH. Le résultat dépend de l’état initial de la machine ; deux exécutions sur des serveurs subtilement différents donnent des résultats différents. NixOS, lui, décrit l’état final souhaité ; le moteur d’évaluation produit un système identique quel que soit le point de départ. Beaucoup d’équipes utilisent Ansible pour bootstrapper l’OS et NixOS pour la configuration applicative ; en pratique, NixOS remplace les deux dès que la machine peut booter sur un ISO NixOS.

Docker et NixOS sont complémentaires plutôt qu’opposés. Docker isole un processus dans un namespace ; NixOS construit le système complet, avec ou sans containers. dockerTools.buildImage dans nixpkgs génère des images OCI dont le hash est déterministe — un avantage net sur les Dockerfile classiques où apt-get install peut renvoyer une version différente d’un jour à l’autre. Pour les équipes qui veulent un kubelet sur leur cluster, NixOS est l’OS hôte ; pour les images applicatives, buildImage remplace utilement les Dockerfiles fragiles.

Terraform reste pertinent pour la couche infra (créer la VM, le réseau, le bucket S3) ; NixOS prend le relais pour configurer la VM créée. Les outils terranix et OpenTofu permettent même d’écrire le Terraform en Nix, mais c’est un raffinement avancé.

Guix System partage le modèle conceptuel mais utilise Guile Scheme et reste politiquement attaché au logiciel libre strict — pas de firmware non-libre dans la distribution officielle. La communauté est plus petite, le catalogue de paquets aussi (~22 000 contre 90 000+ pour nixpkgs), mais l’expérience est élégante pour qui aime Lisp.

Chef et Puppet sont des contemporains d’Ansible avec une logique d’idempotence : appliquer la même recette deux fois doit donner le même résultat. NixOS va plus loin : appliquer la même configuration sur deux machines vierges donne des systèmes identiques bit pour bit, là où Chef/Puppet héritent de la dérive du système hôte.

Le store, la garbage collection et la facture en disque

Le revers de la médaille de l’immutabilité, c’est le poids du store. Une machine NixOS de bureau avec quelques mois d’usage occupe facilement 30 à 60 Go dans /nix/store avant collection. Chaque génération conservée garde référencées toutes les dépendances de cette génération. Sur un VPS frugal, la situation devient critique en quelques semaines si rien n’est fait.

La discipline de base tient en deux mécanismes. La collection automatique s’active dans la configuration : nix.gc.automatic = true; nix.gc.options = "--delete-older-than 14d"; programme un nettoyage hebdomadaire des générations de plus de deux semaines. L’optimisation du store avec nix.optimise.automatic = true; remplace les fichiers identiques par des hard links — un gain de 25 à 40 % typique sur un store de 30 Go. Pour les serveurs avec disque limité, nix-collect-garbage -d en root supprime tout sauf la génération courante après un déploiement validé.

Côté bande passante, le cache binaire cache.nixos.org évite la recompilation locale dans la grande majorité des cas. Sur une connexion lente, un nixos-rebuild switch qui met à jour 200 paquets télécharge plusieurs centaines de mégaoctets ; on apprend vite à programmer les mises à jour la nuit ou à pointer un cache miroir local (nix-serve sur un serveur LAN).

Le parcours d’apprentissage réaliste, en quatre paliers

Semaine 1 — l’utilisateur curieux. Vous installez Nix sur votre distribution actuelle (pas NixOS, juste Nix). Vous testez nix run nixpkgs#cowsay -- "hello", nix shell nixpkgs#nodejs_22, et nix-env -iA nixpkgs.firefox. Vous comprenez que Nix est un gestionnaire de paquets parallèle qui ne casse pas votre système. C’est le moment où la magie opère : un binaire arrivé sans toucher /usr.

Semaine 2 à 4 — le développeur productif. Vous écrivez votre premier flake.nix avec un devShell pour un projet, vous installez direnv et nix-direnv, vous découvrez que vous n’avez plus besoin de nvm. Vous lisez la série d’introduction sur nix.dev et vous parcourez nixpkgs pour voir comment vos paquets favoris sont définis. Vous gardez encore Ubuntu en hôte ; Nix tourne dessus.

Mois 2 — la migration du poste de travail. Vous installez NixOS dans une VM, puis sur un disque externe, puis vous franchissez le pas. Vous réécrivez vos dotfiles dans home-manager. Vous écrivez votre première option custom. Vous comprenez ce que veut dire infinite recursion et comment éviter une let qui se référence elle-même. Vous parlez de mkOption et mkIf à des amis qui ne comprennent pas.

Mois 3 et au-delà — l’opérateur d’infra. Vous déployez votre premier serveur NixOS via nixos-rebuild --target-host. Vous mettez vos secrets sous agenix ou sops-nix. Vous écrivez un module pour empaqueter votre application interne. Vous découvrez colmena, deploy-rs, ou NixOps selon vos préférences. À ce stade, NixOS n’est plus un hobby : c’est l’OS le plus rapide à reprovisioner, le plus facile à auditer, et le moins traître à mettre à jour.

Communauté, gouvernance et pérennité

Le projet Nix est gouverné par la NixOS Foundation, une organisation néerlandaise à but non lucratif (KvK 63520583, Utrecht). Les RFC publiques (github.com/NixOS/rfcs) tracent les évolutions majeures du langage et de l’écosystème. Plusieurs sponsors industriels (Tweag, Determinate Systems, plusieurs cloud providers, et un éventail d’entreprises listées sur Open Collective) financent l’infrastructure du cache binaire et des serveurs Hydra qui compilent en continu nixpkgs sur trois architectures. La cadence est soutenue : entre 4000 et 6000 commits sur nixpkgs chaque mois.

L’écosystème commercial se structure : Determinate Systems propose un installeur amélioré et un service de cache enterprise, Cachix offre du cache binaire managé pour les flakes privés, Replit a basculé toute sa plateforme sur Nix dès octobre 2023 pour ses environnements éphémères. Cette base élargit l’horizon : Nix n’est plus seulement l’outil d’une niche d’enthousiastes, c’est une plateforme d’infrastructure que des entreprises ont intérêt à voir vivre dix ans de plus.

Quelques cas d’usage typiques pour ancrer la décision

L’équipe de quatre développeurs qui en a marre du onboarding

Avant : un wiki Notion de douze pages, deux jours pour qu’un nouveau builds-and-runs, des « oh attends il faut downgrade Postgres ». Après : un flake.nix dans le dépôt, direnv allow en arrivant, nix develop, et le projet compile. Le flake est versionné, le flake.lock est commit, tout le monde a exactement la même version d’OpenSSL et de Node. Les conflits « ça marche chez moi » disparaissent.

Le sysadmin qui gère cinq VPS hétérogènes

Avant : Ansible avec des playbooks qui dérivent, des serveurs où « on avait juste fait un apt install en urgence » il y a six mois. Après : un dépôt git avec un fichier par hôte, nixos-rebuild switch --target-host pour propager. La drift est impossible : si un fichier de configuration n’est pas dans le flake, il sera écrasé au prochain rebuild. Auditer la config d’un serveur revient à git log.

Le freelance qui jongle avec sept projets clients

Avant : nvm, pyenv, rbenv, deux versions de Postgres en parallèle, des ~/.envrc oubliés. Après : chaque dossier projet a son flake.nix, le shell se reconfigure automatiquement à l’entrée du dossier, rien ne pollue le $HOME. La machine peut être reformatée le lundi : un git clone et un nix develop remettent chaque projet en marche.

L’équipe qui fait du Kubernetes mais voudrait du reproductible aussi sur les images

NixOS génère des images Docker via dockerTools.buildImage : pas de Dockerfile, pas de couches successives qui se rebuild, pas de apt-get update && apt-get install aux résultats variables. L’image est définie comme une dérivation Nix, son hash est déterministe, et cache.nixos.org fournit déjà la plupart des dépendances en binaire.

Les pièges fréquents les premières semaines

Foire aux questions

Faut-il abandonner mon Ubuntu/Debian existant ? Non. nix peut s’installer sur n’importe quelle distribution Linux ou sur macOS via le Determinate Systems installer ou l’installeur officiel. Vous bénéficiez des dev-shells, des flakes et de home-manager sans switcher l’OS. Le passage à NixOS complet vient quand vous voulez gérer aussi le système.

Flakes ou pas flakes ? Flakes. Le manuel officiel les marque encore « experimental », mais l’écosystème moderne — outils de déploiement, formations, exemples GitHub — suppose flakes par défaut. Apprendre l’ancien channels/shell.nix en 2026 n’a d’intérêt que pour maintenir du legacy.

Combien de RAM pour compiler ? 8 Go suffisent dans 90 % des cas grâce au cache binaire cache.nixos.org. Vous ne compilez que ce qui est custom (overlays, paquets non encore poussés). Pour des compilations lourdes (Firefox, Chromium, Linux kernel custom), privilégier 16 Go et un swap ou un --build-host plus puissant.

NixOS marche-t-il avec Docker, Podman, Kubernetes ? Oui, via les modules virtualisation.docker, virtualisation.podman, et k3s/kubernetes. NixOS est aussi populaire comme OS hôte de cluster que comme générateur d’images conteneur.

Que faire des binaires propriétaires (Slack, Zoom, IDE Jetbrains) ? La plupart sont packagés dans nixpkgs avec allowUnfree = true. Pour les binaires « raw » non packagés, nix-ld et steam-run fournissent un environnement compatible FHS qui résout le linker dynamique manquant.

L’écosystème supporte-t-il les architectures ARM ? aarch64-linux est supporté ; les Raspberry Pi 4 et 5, les serveurs Ampere et les Mac M1/M2 sous Asahi Linux tournent NixOS. Le cache binaire couvre la majorité des paquets, mais quelques compilations restent à faire localement.

Quelle différence avec Guix System ? Guix repose sur Guile Scheme et la philosophie GNU pure (pas de logiciels non-libres dans la distribution principale). NixOS a un écosystème plus large, plus de paquets (90 000+ vs ~22 000), et une politique pragmatique sur les firmwares propriétaires. Le modèle conceptuel est très proche.

Ressources à garder sous la main

• Manuel officiel NixOS — référence sur les modules, les options et la procédure d’installation.
• nix.dev — tutoriels officiels maintenus par l’équipe Nix, beaucoup plus accessibles que l’ancien manuel.
• search.nixos.org — moteur de recherche des paquets et des options. Indispensable au quotidien.
• Noogle — moteur de recherche pour les fonctions de la bibliothèque standard nixpkgs.lib.
• Home-Manager — projet et documentation officielle.
• wiki.nixos.org — wiki officiel relancé en avril 2024, trésor d’astuces pratiques.
• Discourse NixOS — forum officiel, archive de plus de dix ans de questions.
• Blog officiel et annonces — releases, breaking changes, RFC.

Une fois que nixos-rebuild switch ne fait plus peur, que flake.lock n’est plus une boîte noire et que vos dotfiles vivent dans un home.nix versionné, vous découvrez que le retour en arrière vers une configuration impérative (« juste un petit apt install en plus« ) fait grincer des dents. C’est le signe que la reproductibilité est devenue un confort, pas une contrainte.