Nix sans se mouiller : ma config minimaliste 2026

J'ai essayé Nix trois fois. Les trois fois, j'ai abandonné devant le mur conceptuel — flakes, home-manager, overlays, channels, derivations, stdenv. Chaque tutoriel suppose que tu maîtrises les 5 autres concepts. Fin 2025, j'ai pris une décision différente : utiliser Nix pour UNE seule chose, simplement. Installer mes outils de dev (claude-code, atuin, zellij, git-lfs, etc.) proprement, en environnement déclaratif, sans toucher à mon système. Voici ma config en 40 lignes qui marche sans me faire détester Nix.

Ce que je voulais vraiment

Pas de rewriting complet de ma config système. Pas de home-manager. Pas de NixOS. Juste :

• •Un fichier shell.nix qui liste mes outils de dev
• •nix-shell qui me les installe et les met dans mon PATH
• •Synchronisable entre mes 3 machines (desktop, laptop, VPS)
• •Pas de cassage quand Nix bouge

La config en 40 lignes

~/dev/shell.nix :

{ pkgs ? import <nixpkgs> {} }:

pkgs.mkShell {
  name = "patrice-devtools";

  buildInputs = with pkgs; [
    # Terminal moderne
    zellij
    atuin
    starship
    zoxide
    fzf

    # Git et outils repo
    git
    lazygit
    git-lfs
    gitleaks
    pre-commit

    # Runtime / langages
    nodejs_22
    python312
    bun
    rustup

    # Outils CLI modernes
    ripgrep
    fd
    bat
    eza
    jq
    yq

    # Databases CLI
    sqlite
    postgresql
    turso-cli

    # Sécurité / secrets
    age
    sops
  ];

  shellHook = ''
    export DEVTOOLS_LOADED=1
    echo "🔧 patrice-devtools shell activé"
  '';
}

Usage :

cd ~/dev
nix-shell   # charge tous les outils dans un shell éphémère

Tu peux aussi faire un alias :

alias devshell='nix-shell ~/dev/shell.nix'

Pourquoi ça marche (et pourquoi j'ai abandonné les alternatives)

Pourquoi `shell.nix` et pas `flake.nix` ?

Les flakes sont la direction officielle de Nix, mais elles exigent :

• •Activer une option expérimentale
• •Écrire un flake.lock versionné
• •Comprendre le concept d'« output »
• •Gérer les inputs

Pour mon usage (outils dev), tout ça est du bruit. shell.nix avec <nixpkgs> qui pointe vers mon channel installé fait exactement ce que je veux, en 10× moins de concepts.

Contrepartie : mes versions d'outils changent quand je fais nix-channel --update. Je n'ai pas de reproductibilité hermétique. Pour un usage dev solo, c'est OK. Pour un projet en équipe, j'aurais pris flakes.

Pourquoi pas `home-manager` ?

home-manager permet de déclarer ta config shell, vim, tmux, etc. entièrement en Nix. C'est magnifique sur le papier. En pratique :

• •Écrire un vim config en Nix est 10× plus verbeux qu'en Lua
• •Chaque nouveau outil nécessite de trouver son « module » ou d'écrire du Nix
• •Les erreurs sont cryptiques

Je garde ma config shell/vim/tmux en fichiers standards (~/.zshrc, ~/.vimrc) versionnés dans un repo dotfiles. Nix gère seulement les binaires à installer, pas la config. Séparation claire.

Pourquoi pas NixOS ?

J'ai testé 2 semaines. Plus jamais. Chaque fois que je voulais installer un truc non-packagé (une extension VS Code spécifique, un outil pip install), j'étais bloqué dans un rabbit-hole de 2h. Retour à Ubuntu + Nix package manager.

Les 3 gains réels

Gain 1 : sync entre machines

Je commit shell.nix dans mon repo dotfiles. Sur une nouvelle machine :

curl -L https://nixos.org/nix/install | sh
git clone https://github.com/patrice/dotfiles ~/.dotfiles
cd ~/.dotfiles
nix-shell

15 minutes plus tard, j'ai exactement les mêmes outils que sur ma machine principale. Sans pollution du système — tout est dans /nix/store/ et activé seulement quand je lance nix-shell.

Gain 2 : isolation des versions

Parfois, un projet client a besoin de nodejs_18 au lieu de nodejs_22. Je crée un shell.nix dédié dans le repo du projet, je cd dedans, nix-shell, et j'ai la bonne version. Zéro conflit avec mon environnement principal.

# shell.nix dans le projet client
{ pkgs ? import <nixpkgs> {} }:
pkgs.mkShell {
  buildInputs = [ pkgs.nodejs_18 pkgs.yarn ];
}

Gain 3 : cleanup facile

nix-collect-garbage -d supprime tout ce qui n'est plus référencé. Aucun fichier système bricolé. Je peux tout supprimer et recommencer en 10 minutes.

Les limites que j'accepte

• •Pas de reproductibilité parfaite (channel qui bouge)
• •Pas tous les outils dans nixpkgs (rare, mais quand ça arrive, c'est pénible)
• •La première install d'un package est lente (compilation)
• •Documentation hostile pour les débutants

Ma règle mentale

Nix gère les binaires, pas les configs. Les binaires sont standardisés (un numéro de version → un package). Les configs sont personnelles (mon .zshrc n'est pas le tien). Mélanger les deux dans Nix, c'est accepter une courbe d'apprentissage sans bénéfice.

Ce qu'il faut retenir

1. 1.Un shell.nix simple suffit pour 90% des usages dev.
2. 2.Évite flakes, home-manager, NixOS si tu veux juste des outils.
3. 3.Nix gère les binaires, dotfiles versionnés pour la config.
4. 4.Sync entre machines en 15 minutes.
5. 5.Accepte les limites — pas de reproductibilité parfaite, mais simplicité conservée.

Pour les workflows dev qui tournent autour de Claude Code et Ralph Loop sur différentes machines, j'ai écrit un livre dédié :

La Boucle Ralph

Guide Pratique du Coding Autonome par IA.

Découvrir →