NixOS : comprendre une autre façon de gérer Linux

En entreprise, Linux évoque d'abord Debian, Ubuntu ou RHEL, des systèmes installés, mis à jour paquet par paquet, puis alignés avec Ansible, Puppet ou des images. NixOS part du même monde Linux, mais sa configuration décrit l'état voulu, et la machine y arrive à l'identique autant de fois que nécessaire.

En France, la DINUM s'appuie sur cette approche pour ses projets Sécurix et Bureautix, encore en expérimentation sur ses postes internes (ordre de grandeur annoncé : environ 250 postes d'agents). D'autres administrations (Gendarmerie, DGFiP…) ont déjà une longue pratique de Linux. Ici, l'intérêt porte sur le modèle de gestion du parc, au-delà du choix d'un bureau.

Pour une organisation, l'enjeu se lit comme pour n'importe quel parc : des postes et serveurs reproductibles, auditables et réversibles, sans dépendre d'une mémoire orale ni d'un état accumulé machine par machine.

Deux façons de faire vivre une machine Linux

Sur une distribution classique, le parcours familier ressemble à ceci :

• installer des paquets
• modifier des fichiers de configuration
• démarrer des services
• automatiser ensuite avec un outil de gestion de configuration pour limiter la dérive

Ça fonctionne et c'est éprouvé. Mais l'état réel d'une machine reste en partie le produit de son histoire : ordre des mises à jour, correctifs manuels, paquets oubliés, exceptions locales. Deux serveurs « identiques » sur le papier peuvent diverger. Ansible ou équivalent réduit l'écart. Il ne l'élimine pas par construction.

NixOS inverse la priorité. Le système est déclaratif et déterministe : la configuration décrit l'état cible, et nixos-rebuild rapproche la machine de cette description. Deux machines alimentées par la même configuration convergent vers le même résultat, un peu comme deux builds CI produits à partir du même commit.

Le tableau compare les deux approches.

Les deux peuvent coexister dans une organisation. NixOS devient intéressant dès que l'homogénéité du parc et la capacité à revenir en arrière pèsent plus lourd que la familiarité immédiate des outils apt / dnf.

Configuration déclarative : décrire, puis appliquer

Comme pour de l'infrastructure as code, l'état souhaité est centralisé dans des fichiers, le plus souvent configuration.nix complété par des modules.

{
  services.nginx.enable = true;
  users.users.admin = {
    isNormalUser = true;
    extraGroups = [ "wheel" ];
  };
}

La commande suivante l'applique.

nixos-rebuild switch

Sur Debian, un administrateur enchaîne souvent apt install, l'édition de fichiers et le redémarrage des services. Sous NixOS, une seule opération rapproche le système de la description. En contrepartie, il faut apprendre le langage des modules. Le résultat n'est plus une approximation accumulée au fil des interventions manuelles.

Le store Nix face à `/usr`

Sur une distro classique, les paquets se partagent des chemins communs (/usr/lib, /usr/bin). C'est simple au quotidien. Ça crée aussi les conflits de versions et le « ça marche sur ma machine ».

Avec Nix, les artefacts construits vivent dans /nix/store. Chaque élément est :

• immuable une fois construit
• adressé par hash, le chemin encode ses dépendances
• isolé, deux versions d'un même logiciel peuvent coexister

Par exemple, /nix/store/…-nginx-1.24 et une autre génération de nginx coexistent. Le principe rappelle les environnements virtuels ou les images de conteneurs, appliqué au système entier.

Dérivations : des recettes plutôt que des paquets « boîte noire »

Chaque paquet Nix est une dérivation : une recette avec dépendances explicites et build reproductible. Une dérivation combine la source, les dépendances et un script de build, et produit un résultat immuable dans le store.

Pour une équipe informatique ou un intégrateur, le parallèle utile est le pipeline de build. Un environnement se reconstruit, s'audite et se transfère avec la même exigence que le code applicatif.

Rollback natif : le filet que les distros classiques improvisent

Sur un parc Windows ou Linux classique, revenir en arrière après une mauvaise mise à jour, c'est souvent image de restauration, snapshot d'hyperviseur, ou reconstruction. NixOS intègre l'idée de génération : chaque nixos-rebuild switch en crée une.

En cas de problème :

nixos-rebuild switch --rollback

Le menu de démarrage (GRUB) propose aussi les générations précédentes. En production, le gain ressemble à celui d'un déploiement blue/green ou d'un rollback de release : corriger une régression en minutes, sans reconstituer manuellement l'état d'hier.

Modules, Nixpkgs et Home Manager

Modules NixOS

Comme des rôles Ansible ou des manifests, NixOS expose des modules (réseau, pare-feu, nginx, PostgreSQL, SSH, comptes…). L'administrateur déclare l'intention, et le système génère la configuration effective. Tout passe par le même modèle déclaratif, du noyau aux services.

Nixpkgs

Nixpkgs est l'un des plus grands catalogues de paquets Linux. Au-delà du volume, il permet la coexistence de versions, les overlays personnalisés et les builds reproductibles. Avec les flakes, configuration et dépendances se verrouillent dans un flake.nix, ce qui rapproche encore le geste d'une infra versionnée comme du code (lab, staging, production).

Home Manager

Pour la couche utilisateur (shell, dotfiles, Git, IDE), Home Manager applique la même philosophie au poste de travail. Un parc classique combine souvent des GPO, des scripts de connexion et des images de référence. Ici, le poste utilisateur peut être décrit avec la même rigueur que le serveur.

Pourquoi ça intéresse l'État (et d'autres acteurs)

NixOS n'est pas réservé aux laboratoires. Dès qu'il faut industrialiser des déploiements, durcir des environnements, réduire la dérive entre machines ou accélérer la reprise après incident, le modèle déclaratif devient aussi un argument opérationnel.

C'est dans ce cadre que s'inscrivent Sécurix et Bureautix, portés par la DINUM (dépôts cloud-gouv) :

Sécurix (socle durci)

• configuration entièrement déclarée et auditable
• immuabilité du store et retour rapide à l'état précédent après un incident
• réduction des écarts entre machines d'un même parc
• durcissement selon les recommandations de l'Agence nationale de la sécurité des systèmes d'information (ANSSI), selon le projet

Bureautix (poste de travail maîtrisé)

• déploiement homogène des postes à partir d'une définition
• installation d'un nouveau poste à partir de sa description, sans longue installation manuelle
• couche bureautique et métier au-dessus du socle, pour les agents comme pour les administrateurs

La généralisation autour des ~250 postes internes de la DINUM ne signifie pas que toute l'administration bascule du jour au lendemain, ni que Sécurix / Bureautix soient prêts à être déployés ailleurs. C'est une expérimentation en cours : un signal fort sur NixOS, pas encore une offre généralisable.

Changer de modèle, sans tout jeter

Passer à NixOS revient à accepter un autre contrat que celui d'une distro classique :

• la description explicite du système est versionnée
• la reconstruction et le retour en arrière suivent une discipline proche du développement logiciel
• les compétences Linux classiques restent utiles, car le noyau, le réseau et les services ne changent pas. NixOS change la façon de les assembler

Chez Hebeko, nous déployons et exploitons des infrastructures open source (NixOS, Keycloak, Nextcloud, automatisation Ansible et Terraform). Nous suivons Sécurix / Bureautix et contribuons à leur développement. Nous n'en proposons pas de prestation de déploiement tant que le projet reste expérimental hors DINUM.

Aller plus loin

• Formation NixOS (3 jours), avec l'administration, les flakes, les secrets et les déploiements sur plusieurs machines
• Nos services, de l'audit à l'infogérance
• Contactez-nous pour parler de votre contexte