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

Quand on parle de Linux en entreprise, on pense d'abord à Debian, Ubuntu ou RHEL : des systèmes qu'on installe, qu'on met à jour paquet par paquet, et qu'on fait converger avec Ansible, Puppet ou des images. NixOS part du même monde Linux, mais change la question centrale. Au lieu de « comment maintenir cette machine au fil du temps ? », on demande « comment décrire l'état souhaité pour que la machine y arrive, à l'identique, autant de fois que nécessaire ? »

Ce n'est plus un sujet de niche. En France, la DINUM s'appuie sur cette approche pour ses projets Sécurix et Bureautix, avec une bascule progressive de ses postes internes vers un environnement Linux bâti sur NixOS. L'ordre de grandeur annoncé : environ 250 postes d'agents en généralisation, après des phases d'expérimentation. D'autres administrations (Gendarmerie, DGFiP…) ont déjà une longue pratique de Linux ; ici, l'intérêt est le modèle de gestion du parc, pas seulement le 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 configuration management pour limiter la dérive.

Ça fonctionne. 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.

On peut le voir ainsi :

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, on centralise l'état souhaité dans des fichiers (souvent configuration.nix, complétés par des modules) :

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

Puis on applique :

nixos-rebuild switch

Là où, sur Debian, on enchaîne souvent apt install, édition de fichiers et restart de services, ici une seule opération rapproche le système de la description. Ce n'est pas magique : il faut apprendre le langage des modules. En revanche, le résultat n'est plus une approximation accumulée au fil des interventions manuelles.

Le store Nix : ce que `/usr` ne fait pas de la même façon

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 fameux 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.

Exemple : /nix/store/…-nginx-1.24 et une autre génération nginx côte à côte. On retrouve l'esprit des environnements virtuels ou des images de conteneurs, appliqué au système entier, pas seulement à une appli.

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. Conceptuellement : source + dépendances + script de build → résultat immuable dans le store.

Pour une équipe IT ou un intégrateur, le parallèle utile est celui du pipeline de build : on peut reconstruire, auditer et transférer un environnement avec la même exigence qu'on a déjà pour 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

On peut aussi choisir une génération précédente au boot (GRUB). 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…). On déclare l'intention ; le système génère la configuration effective. La différence : 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. L'intérêt n'est pas seulement le volume : coexistence de versions, overlays personnalisés, 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. Sur un parc classique, on combine souvent GPO, scripts de login et images gold ; 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 un argument opérationnel, pas seulement technique.

C'est dans ce cadre que s'inscrivent Sécurix et Bureautix, portés dans l'écosystème cloud-gouv / DINUM :

Sécurix (socle durci)

• configuration entièrement déclarée et auditable ;
• immuabilité du store et rollback rapide après incident ;
• réduction des écarts entre machines d'un même parc ;
• orientation sécurité (durcissement type recommandations ANSSI, selon le projet).

Bureautix (poste de travail maîtrisé)

• déploiement homogène des postes à partir d'une définition ;
• onboarding accéléré : un poste devient une description, pas une installation manuelle longue ;
• couche métier / bureautique au-dessus du socle, pour des usages au-delà des seuls admins systèmes.

La généralisation autour des ~250 postes internes de la DINUM ne signifie pas que toute l'administration bascule du jour au lendemain. Elle montre qu'un acteur majeur teste et déploie NixOS là où la maîtrise du parc et la souveraineté logicielle comptent. Pour les organisations qui suivent ce mouvement, l'enjeu n'est pas de « devenir DINUM », mais de pouvoir forker et adapter ces briques à leur propre contexte.

Changer de modèle, sans tout jeter

Passer à NixOS, ce n'est pas remplacer une distro par une autre du même genre. C'est accepter un autre contrat :

• on versionne une description explicite du système ;
• on reconstruit et on revient en arrière avec une discipline proche du développement logiciel ;
• on garde, si besoin, des compétences classiques Linux : le noyau, le réseau et les services restent familiers ; c'est la façon de les assembler qui change.

Chez HeBeKo, nous explorons et utilisons cette approche pour le déploiement et l'exploitation d'infrastructures open source (NixOS, Keycloak, Nextcloud, automatisation Ansible et Terraform), et nous aidons les organisations à évaluer ce que Sécurix / Bureautix peuvent leur apporter une fois adaptés à leur parc.

Aller plus loin

• Formation NixOS (3 jours) : administration, flakes, secrets, déploiements multi-machines.
• Nos services : audit, migration et infogérance sur stack open source.
• Contactez-nous pour parler de votre contexte. Réponse sous 24 h ouvrées.