Cas pratiques DevOps avec Nix : standardiser les environnements et fiabiliser la CI/CD

Vous avez des flakes, des devShells, un flake.lock qui verrouille chaque dépendance. Maintenant, comment en faire un usage d'équipe concret ? Ce guide transforme les briques des guides 8 à 10 en six cas pratiques opérationnels : poste de travail standardisé, CI/CD identique au local, checks automatisés, build reproductible d'un outil interne, stratégie de mise à jour et onboarding express. Chaque exemple s'appuie sur la même flake.nix de référence, rejouée le 1er octobre 2026 avec Nix 2.35.2 et nixos-26.05, la branche stable courante.

Ce que vous allez apprendre

• Construire un devShell d'équipe embarquant Terraform, Ansible, kubectl, Helm et les outils de qualité
• Consommer ce devShell dans GitHub Actions et GitLab CI, sans configuration supplémentaire
• Définir des checks reproductibles (lint, format) exécutés localement et en CI avec nix flake check
• Empaqueter un script d'administration comme dérivation Nix reproductible avec writeShellApplication
• Gérer les mises à jour de flake.lock sans surprises pour l'équipe
• Ramener l'onboarding d'un nouveau membre à git clone + nix develop

Dans quel contexte ?

Nix devient particulièrement utile dès qu'une équipe est impliquée, parce que chaque poste et chaque runner de CI dérive de son côté. Les situations suivantes en sont les symptômes typiques :

• Deux ingénieurs ont des versions différentes de Terraform ou d'Ansible, les plans divergent
• La CI installe des paquets avec sudo apt install dans le pipeline, créant des builds fragiles et lents
• Un nouveau contributeur passe une demi-journée à installer l'outillage avant d'écrire la première ligne
• Une mise à jour silencieuse de helm en CI casse le déploiement, impossible de reproduire localement
• Les scripts shell sont valides "sur ma machine" mais pas sur le runner

Un flake.nix versionné avec le code résout structurellement chacun de ces problèmes.

Prérequis

Ce guide fait suite aux guides 8 (environnements), 9 (factorisation) et 10 (flakes). Vous devez :

• avoir Nix installé avec les flakes activés (voir le guide d'installation),
• comprendre la structure d'un flake.nix (inputs, outputs, devShells),
• savoir utiliser nix develop et nix flake check.

Structure du projet de référence

Créez ce projet dans votre répertoire de lab. Tous les cas pratiques utilisent cette même base :

mkdir -p ~/Projets/lab-nix && cd ~/Projets/lab-nix
mkdir -p nix scripts src
git init

• Répertoirelab-nix/

  • flake.nix (point d'entrée, inputs + délégation aux modules)
  • flake.lock (révisions verrouillées, toujours commité dans Git)
  • Répertoirenix/

    • devshells.nix (devShell d'équipe)
    • checks.nix (vérifications automatisables)
    • packages.nix (builds reproductibles)
  • Répertoirescripts/

    • lint.sh (lint shell)
    • validate.sh (validation Terraform)
  • Répertoiresrc/ (code source)

    • …
  • .envrc (activation automatique avec direnv, optionnel)

Le flake.nix racine reste court grâce à la factorisation dans nix/. C'est la convention introduite dans le guide 9. Deux détails comptent : Terraform est publié sous licence BSL depuis la version 1.6, et nixpkgs refuse de l'évaluer tant qu'on ne l'autorise pas explicitement ; et le fichier est écrit au format de nixfmt, sans quoi le check de format du cas pratique 3 échoue sur lui.

flake.nix

{
  description = "Boîte à outils DevOps : reproductible pour toute l'équipe";

  inputs = {
    nixpkgs.url = "github:nixos/nixpkgs/nixos-26.05";
    flake-utils.url = "github:numtide/flake-utils";
  };

  outputs =
    {
      self,
      nixpkgs,
      flake-utils,
    }:
    flake-utils.lib.eachDefaultSystem (
      system:
      let
        pkgs = import nixpkgs {
          inherit system;
          config.allowUnfreePredicate = pkg: builtins.elem (nixpkgs.lib.getName pkg) [ "terraform" ];
        };
        src = ./.;
      in
      {
        devShells.default = import ./nix/devshells.nix { inherit pkgs; };
        checks = import ./nix/checks.nix { inherit pkgs src; };
        packages = import ./nix/packages.nix { inherit pkgs; };
      }
    );
}

Sans le bloc allowUnfreePredicate, pkgs = nixpkgs.legacyPackages.${system} suffit pour tout le reste, mais l'entrée dans le shell échoue :

error: Refusing to evaluate package 'terraform-1.15.3' in /nix/store/…/pkgs/applications/networking/cluster/terraform/default.nix:85 because it has an unfree license (‘bsl11’)

git add avant toute commande Nix

Dans un dépôt Git, les flakes ne voient que les fichiers suivis par Git. Après chaque création de fichier, faites git add <fichier> avant de lancer nix develop, nix build ou nix flake check. Sinon, Nix refuse le fichier avec Path '…' in the repository … is not tracked by Git.

---

Cas pratique 1, Boîte à outils DevOps standardisée

L'objectif

Un devShell unique qui embarque tout l'outillage d'une équipe DevOps. Chaque membre entre dans cet environnement avec nix develop et obtient les mêmes versions, peu importe sa distribution ou son historique d'installation. Attention au nom des attributs : dans nixpkgs, helm désigne un synthétiseur audio, le gestionnaire de paquets Kubernetes s'appelle kubernetes-helm.

nix/devshells.nix

{ pkgs }:

pkgs.mkShell {
  name = "devops-toolkit";

  packages = with pkgs; [
    # Contrôle de version
    git
    git-crypt

    # Traitement de données structurées
    jq
    yq-go

    # Qualité de code shell
    shellcheck
    shfmt

    # Infrastructure as Code
    terraform
    opentofu

    # Gestion de configuration
    ansible
    ansible-lint

    # Kubernetes
    kubectl
    kubernetes-helm
    kustomize
    k9s

    # Sécurité
    trivy
    cosign

    # Debug réseau
    curl
    httpie
  ];

  shellHook = ''
    echo "Environnement DevOps actif ($(uname -m))"
    echo "  Terraform : $(terraform version 2>/dev/null | head -1)"
    echo "  kubectl   : $(kubectl version --client 2>/dev/null | head -1)"
    echo "  Helm      : $(helm version --short 2>/dev/null)"
    echo "  Ansible   : $(ansible --version 2>/dev/null | head -1)"
  '';
}

Test

Ajoutez les deux fichiers à l'index Git, puis entrez dans le shell : le shellHook affiche les versions fournies par nixos-26.05.

cd ~/Projets/lab-nix
git add flake.nix nix/devshells.nix
nix develop

Environnement DevOps actif (x86_64)
  Terraform : Terraform v1.15.3
  kubectl   : Client Version: v1.36.3
  Helm      : v3.20.2+gv3.20.2
  Ansible   : ansible [core 2.21.1]

Plusieurs devShells dans un même flake

Pour des équipes aux besoins différents, ops, sécurité, développeurs, créez plusieurs shells nommés dans devshells.nix en retournant un attribute set :

{ pkgs }:
{
  default = pkgs.mkShell { packages = with pkgs; [ terraform ansible kubectl ]; };
  sec     = pkgs.mkShell { packages = with pkgs; [ trivy cosign grype syft ]; };
  dev     = pkgs.mkShell { packages = with pkgs; [ python312 nodejs_22 go ]; };
}

Puis dans flake.nix : devShells = import ./nix/devshells.nix { inherit pkgs; };

Utilisation : nix develop .#sec ou nix develop .#dev.

---

Cas pratique 2, CI/CD identique au poste local

Le principe

Votre flake.nix est versionné avec le code. La CI le consomme directement avec la même commande qu'en local :

# En local
nix develop --command bash -c "shellcheck scripts/*.sh && terraform -chdir=infra validate"

# En CI : exactement la même commande
nix develop --command bash -c "shellcheck scripts/*.sh && terraform -chdir=infra validate"

Les trois onglets suivants déclinent ce principe pour GitHub Actions, GitLab CI et un runner auto-hébergé. Les actions GitHub sont épinglées sur le SHA de leur commit, avec la version en commentaire, et le workflow ne reçoit que la permission de lire le dépôt.

GitHub Actions

.github/workflows/ci.yml

name: CI

on: [push, pull_request]

permissions: {}

jobs:
  validate:
    runs-on: ubuntu-24.04
    permissions:
      contents: read
    steps:
      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1  # v7.0.1
        with:
          persist-credentials: false

      - uses: cachix/install-nix-action@13d8dd58da0234aa297dedd986986ccb8e7f3e24  # v31.11.1
        with:
          github_access_token: ${{ secrets.GITHUB_TOKEN }}
          extra_nix_config: |
            experimental-features = nix-command flakes

      # Cache binaire : réduit drastiquement le temps de téléchargement
      - uses: cachix/cachix-action@38b082610b782e7e93e209c35fd730d399dee866  # v17
        with:
          name: my-org-cache
          authToken: ${{ secrets.CACHIX_AUTH_TOKEN }}

      - name: Vérification de la structure du flake
        run: nix flake check --no-build

      - name: Lint et validation IaC
        run: |
          nix develop --command bash -c "
            shellcheck scripts/*.sh
            terraform -chdir=infra validate
            ansible-lint playbooks/ || true
          "

GitLab CI

.gitlab-ci.yml

image: nixos/nix:2.35.2@sha256:7a007c766426c1877758ddc5cb87a965ac131fc78c582ce0083d922d51ae945c

variables:
  NIX_CONFIG: "experimental-features = nix-command flakes"

stages:
  - validate
  - test

flake-check:
  stage: validate
  script:
    - git config --global --add safe.directory "$CI_PROJECT_DIR"
    - nix flake check --no-build

lint:
  stage: validate
  script:
    - nix develop --command shellcheck scripts/*.sh

validate-iac:
  stage: test
  script:
    - nix develop --command terraform -chdir=infra validate
    - nix develop --command ansible-lint playbooks/ || true

Pas de bloc cache: sur /nix/store ici : le cache GitLab n'accepte que des chemins situés dans le répertoire du projet, et un /nix/store déclaré dans cache:paths n'est tout simplement pas sauvegardé. Pour éviter de retélécharger les paquets à chaque job, passez par un cache binaire (Cachix, ou un cache S3 renseigné dans NIX_CONFIG) ou par un runner persistant.

Runner auto-hébergé

Sur un runner persistant, installez Nix une seule fois. Le store /nix est partagé entre tous les jobs, plus de re-téléchargement.

# Installateur de Nix 2.35.2, vérifié par son empreinte avant exécution
curl -fsSL -o install-nix.sh https://releases.nixos.org/nix/nix-2.35.2/install
echo "$(curl -fsSL https://releases.nixos.org/nix/nix-2.35.2/install.sha256)  install-nix.sh" \
  | sha256sum --check

# Installation multi-utilisateur sur le serveur de CI
sh install-nix.sh --daemon

# Activer les flakes pour l'utilisateur CI
mkdir -p /home/ci-runner/.config/nix
echo "experimental-features = nix-command flakes" \
  >> /home/ci-runner/.config/nix/nix.conf

Le premier job peuple le store, ce qui prend quelques minutes. Les suivants réutilisent les paquets déjà présents, et nix develop n'a plus qu'à évaluer le flake.

Premier run lent, les suivants rapides

Le premier nix develop sur un runner vierge télécharge tous les paquets depuis cache.nixos.org. Avec Cachix ou un runner persistant, les runs suivants réutilisent le cache binaire. Investissez dans cette infrastructure dès le départ : c'est elle qui rend le pipeline Nix plus rapide qu'une installation par apt à chaque job.

---

Cas pratique 3, Checks reproductibles avec nix flake check

L'objectif

Définir des vérifications (lint, format) comme des dérivations Nix : le check devient un paquet comme un autre, construit dans le bac à sable de Nix.

• exécutables en local avec nix flake check,
• intégrées automatiquement en CI,
• mises en cache, un check déjà réussi ne tourne pas une deuxième fois.

Définir les checks

Chaque check est un runCommandLocal qui lance l'outil puis crée $out : si l'outil échoue, la dérivation échoue, et nix flake check avec elle. Le paquet nixfmt est le formateur officiel de Nix ; l'ancien nom nixfmt-rfc-style n'est plus qu'un alias.

nix/checks.nix

{ pkgs, src }:

{
  # Vérification des scripts shell
  shellcheck = pkgs.runCommandLocal "check-shellcheck" { buildInputs = [ pkgs.shellcheck ]; } ''
    find ${src}/scripts -name "*.sh" -exec shellcheck {} +
    touch $out
  '';

  # Format des fichiers Nix (RFC-style)
  nixfmt = pkgs.runCommandLocal "check-nixfmt" { buildInputs = [ pkgs.nixfmt ]; } ''
    nixfmt --check ${src}/flake.nix
    find ${src}/nix -name "*.nix" -exec nixfmt --check {} +
    touch $out
  '';
}

src = ./. dans le flake.nix

Le paramètre src vaut ./. dans le flake.nix. Il capture le répertoire du flake comme chemin du store au moment de l'évaluation. C'est plus fiable que d'utiliser self directement depuis un fichier importé.

Exécuter les checks

Lancez tous les checks d'un coup, ou un seul quand vous déboguez : nix build sur l'attribut du check affiche ses journaux en cas d'échec.

cd ~/Projets/lab-nix
git add nix/checks.nix scripts/

# Tous les checks
nix flake check

# Un seul check, avec trace détaillée si erreur
nix build .#checks.x86_64-linux.shellcheck --show-trace

Résultat (fin de sortie)

running 2 flake checks...
building '/nix/store/cfk8z97ymsxb5wiiw5qawd5pd53j400q-check-nixfmt.drv'...
building '/nix/store/z09h1az790v0m84jsyd5ivcn2w9ksyig-check-shellcheck.drv'...
all checks passed!
warning: The check omitted these incompatible systems: aarch64-darwin, aarch64-linux, x86_64-darwin
Use '--all-systems' to check all.

Si shellcheck détecte un problème, le check échoue et Nix affiche la fin du journal :

       Last 10 log lines:
       >
       > In /nix/store/…-source/scripts/lint.sh line 3:
       > echo $x
       >      ^-- SC2086 (info): Double quote to prevent globbing and word splitting.
       >
       > Did you mean:
       > echo "$x"

Le check de format se comporte de la même façon : un fichier Nix mal formaté sort en flake.nix: not formatted. Lancez nixfmt flake.nix nix/*.nix pour le corriger avant de commiter.

Intégration CI

En GitLab CI et GitHub Actions, remplacez vos scripts de lint ad hoc par :

nix flake check

C'est une seule commande, indépendante du runner, qui exécute exactement les mêmes vérifications qu'en local.

---

Cas pratique 4, Build reproductible d'un outil interne

L'objectif

Empaqueter un script d'administration comme dérivation Nix. Le résultat est construit à partir des mêmes entrées sur toutes les machines, donc au même chemin du store, et peut être distribué via un cache binaire ou installé directement avec nix profile add.

Exemple : script d'audit Kubernetes

Le script ne suppose rien du poste qui l'exécute : kubectl et jq viennent du store, à la version fixée par le flake.lock, et writeShellApplication refuse de construire un script que shellcheck juge fautif.

nix/packages.nix

{ pkgs }:

{
  # Outil d'audit Kubernetes avec ses dépendances exactes embarquées
  k8s-audit = pkgs.writeShellApplication {
    name = "k8s-audit";
    runtimeInputs = with pkgs; [
      kubectl
      jq
    ];
    text = ''
      echo "=== Nœuds du cluster ==="
      kubectl get nodes -o json \
        | jq -r '.items[] | "\(.metadata.name)\t\(.status.conditions[]
            | select(.type=="Ready") | .status)"'

      echo ""
      echo "=== Pods non Running ==="
      kubectl get pods --all-namespaces \
        --field-selector 'status.phase!=Running,status.phase!=Succeeded' \
        2>/dev/null || echo "(aucun)"

      echo ""
      echo "=== Événements Warning récents ==="
      kubectl get events --all-namespaces \
        --field-selector type=Warning \
        --sort-by='.lastTimestamp' \
        2>/dev/null | tail -15
    '';
  };
}

writeShellApplication vs writeShellScript

pkgs.writeShellApplication est la version recommandée pour des scripts destinés à la distribution. Le script généré commence par set -o errexit, nounset et pipefail, puis par export PATH="…kubectl-1.36.3/bin:…jq-1.8.2-bin/bin:$PATH" :

• set -euo pipefail activé automatiquement
• les runtimeInputs passent en tête du PATH du script : il trouve ses propres versions d'abord, sans toucher au PATH de l'utilisateur
• shellcheck est exécuté à la construction, un script bugué ne compile pas

pkgs.writeShellScript est plus simple mais sans ces garanties.

Construire, tester, distribuer

Les quatre commandes couvrent le cycle complet : construire l'outil, l'exécuter depuis ./result, l'essayer sans l'installer, puis l'ajouter au profil.

cd ~/Projets/lab-nix
git add nix/packages.nix

# Construire
nix build .#k8s-audit

# Tester (le binaire est dans ./result/bin/)
./result/bin/k8s-audit

# Utiliser temporairement sans installer
nix shell .#k8s-audit --command k8s-audit

# Installer dans le profil utilisateur
nix profile add .#k8s-audit

Le binaire k8s-audit utilise ses propres versions de kubectl et jq depuis le store Nix : il fonctionne sur n'importe quelle machine avec Nix installé, sans dépendance système.

---

Cas pratique 5, Stratégie de mise à jour de flake.lock

Le problème

flake.lock fige la révision de nixpkgs. Il doit être mis à jour régulièrement pour obtenir les correctifs de sécurité et les nouvelles versions d'outils, sans casser l'équipe au passage.

Workflow de mise à jour

Les six étapes isolent la mise à jour dans une branche, la font valider par la CI, et gardent un chemin de retour arrière.

1. Créer une branche dédiée

   git checkout -b chore/nix-update-$(date +%Y-%m)

2. Mettre à jour toutes les dépendances

   nix flake update

   Cela recrée flake.lock avec les révisions les plus récentes de chaque input déclaré.

3. Inspecter ce qui a changé

   git diff flake.lock

   "rev": "<ancienne révision, 40 caractères>",
   "rev": "78e9c786dc08cd4f3420c2395cd977206a9b1da2",

   La révision de nixpkgs est la seule vraie information. Consultez github.com/NixOS/nixpkgs/compare/<ancienne-rev>...<nouvelle-rev> pour voir les changements inclus.

4. Valider localement

   nix flake check
   nix develop --command bash -c "terraform version && kubectl version --client"

5. Ouvrir une PR/MR

   La CI valide les checks automatiquement. La PR est fusionnée si tout est vert.

6. Rollback si problème

   # Revenir simplement à la révision précédente de nixpkgs
   git revert HEAD
   
   # Ou épingler une révision spécifique
   nix flake lock --override-input nixpkgs \
     github:nixos/nixpkgs/<révision-de-40-caractères>

Cadence recommandée

La bonne fréquence dépend du rythme de l'équipe et de son exposition : plus les dépendances sont nombreuses, plus une mise à jour tardive ramène de changements d'un coup.

Fréquence	Cas d'usage
Hebdomadaire	Équipes avec forte activité CI/CD, dépendances nombreuses
Mensuelle	Projets stables, outillage peu changeant
À la demande	CVE critique dans une dépendance détectée par la veille

Glissez pour voir

Automatiser avec Renovate

Renovate sait mettre à jour les inputs Nix : il ouvre des PRs avec le diff de flake.lock à la cadence que vous configurez. C'est le même principe que la gestion des dépendances npm ou Dependabot sur GitHub.

---

Cas pratique 6, Onboarding express

Un nouveau DevOps rejoint l'équipe. En moins de 15 minutes, il dispose de l'environnement complet, aux mêmes versions que ses collègues.

1. Installer Nix (une seule fois, 3-5 minutes)

   curl -fsSL -o install-nix.sh https://releases.nixos.org/nix/nix-2.35.2/install
   echo "$(curl -fsSL https://releases.nixos.org/nix/nix-2.35.2/install.sha256)  install-nix.sh" \
     | sha256sum --check
   sh install-nix.sh --no-daemon
   source ~/.nix-profile/etc/profile.d/nix.sh

2. Activer les flakes

   mkdir -p ~/.config/nix
   echo "experimental-features = nix-command flakes" >> ~/.config/nix/nix.conf

3. Cloner et entrer dans l'environnement

   git clone https://gitlab.mon-org.example.com/infra/devops-tools.git
   cd devops-tools
   nix develop

4. Vérifier

   terraform version
   kubectl version --client
   helm version
   ansible --version

   Toutes les versions affichées sont identiques à celles du reste de l'équipe.

5. (Optionnel) Activation automatique avec direnv

   nix profile add nixpkgs#direnv
   echo 'eval "$(direnv hook bash)"' >> ~/.bashrc
   source ~/.bashrc
   direnv allow .

   À partir de là, l'environnement du flake se charge automatiquement à chaque cd dans le répertoire, à condition que le dépôt contienne un .envrc avec use flake.

Le README d'installation se réduit à ces 5 étapes. Plus de liste de paquets à maintenir, plus de "ça marche chez moi" : la source de vérité est le flake.

---

Fil rouge : projet Python + Terraform + Ansible

Voici comment les six cas pratiques se combinent dans un projet réaliste. Le shell ci embarque tout ce que le pipeline appelle, ansible-lint compris : un outil absent du shell ferait échouer le job avec command not found. Le fichier est déjà au format de nixfmt, que son propre check vérifie.

flake.nix (version complète)

{
  description = "Infra : Python + Terraform + Ansible";

  inputs = {
    nixpkgs.url = "github:nixos/nixpkgs/nixos-26.05";
    flake-utils.url = "github:numtide/flake-utils";
  };

  outputs =
    {
      self,
      nixpkgs,
      flake-utils,
    }:
    flake-utils.lib.eachDefaultSystem (
      system:
      let
        # Terraform est sous licence BSL : nixpkgs refuse de l'évaluer sans autorisation explicite
        pkgs = import nixpkgs {
          inherit system;
          config.allowUnfreePredicate = pkg: builtins.elem (nixpkgs.lib.getName pkg) [ "terraform" ];
        };
        src = ./.;
      in
      {
        # Cas pratique 1 : plusieurs shells selon le rôle
        devShells = {
          default = pkgs.mkShell {
            name = "infra-full";
            packages = with pkgs; [
              python312
              python312Packages.boto3
              terraform
              ansible
              ansible-lint
              kubectl
              kubernetes-helm
              shellcheck
              shfmt
            ];
            shellHook = ''
              echo "Environnement complet actif"
            '';
          };
          ci = pkgs.mkShell {
            # Shell allégé pour la CI : sans éléments interactifs
            name = "infra-ci";
            packages = with pkgs; [
              python312
              terraform
              ansible
              ansible-lint
              kubectl
              shellcheck
            ];
          };
        };

        # Cas pratique 3 : checks automatisés
        checks = {
          shellcheck = pkgs.runCommandLocal "check-shellcheck" { buildInputs = [ pkgs.shellcheck ]; } ''
            find ${src}/scripts -name "*.sh" -exec shellcheck {} +
            touch $out
          '';
          nixfmt = pkgs.runCommandLocal "check-nixfmt" { buildInputs = [ pkgs.nixfmt ]; } ''
            nixfmt --check ${src}/flake.nix
            touch $out
          '';
        };

        # Cas pratique 4 : outil interne empaquetable
        packages.default = pkgs.writeShellApplication {
          name = "infra-status";
          runtimeInputs = with pkgs; [
            kubectl
            jq
            python312
          ];
          text = ''
            echo "=== Cluster status ==="
            kubectl get nodes -o json | jq -r '.items[].metadata.name'
          '';
        };
      }
    );
}

Le pipeline correspondant appelle le shell ci pour chaque outil, et construit l'outil interne exposé sous packages.default, d'où un nix build sans attribut :

.github/workflows/ci.yml (fil rouge)

name: Infra CI

on: [push, pull_request]

permissions: {}

jobs:
  checks:
    runs-on: ubuntu-24.04
    permissions:
      contents: read
    steps:
      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1  # v7.0.1
        with:
          persist-credentials: false
      - uses: cachix/install-nix-action@13d8dd58da0234aa297dedd986986ccb8e7f3e24  # v31.11.1
        with:
          github_access_token: ${{ secrets.GITHUB_TOKEN }}
          extra_nix_config: |
            experimental-features = nix-command flakes
      - run: nix flake check
      - run: nix develop .#ci --command terraform -chdir=infra validate
      - run: nix develop .#ci --command ansible-lint playbooks/
      - run: nix build

---

Pièges spécifiques au contexte DevOps

Ces pièges ne relèvent pas de la syntaxe Nix mais de son usage en équipe : ils passent inaperçus sur un poste isolé et se révèlent en CI ou au premier changement de version.

Piège	Impact	Correctif
git add oublié avant nix develop	Nix refuse le fichier : Path '…' is not tracked by Git	git add -A systématique avant toute commande Nix
flake.lock absent du dépôt	Chaque machine ou CI job résout une révision différente	Commiter flake.lock, c'est une fonctionnalité, pas un artefact jetable
Terraform sans autorisation de licence	Refusing to evaluate package 'terraform-…' because it has an unfree license	allowUnfreePredicate limité à terraform, ou passer à opentofu
helm au lieu de kubernetes-helm	Un synthétiseur audio s'installe, helm version ne répond pas	Utiliser l'attribut kubernetes-helm
Cache Nix absent en CI	Premier job lent (plusieurs minutes de téléchargements)	Configurer Cachix ou un runner persistant avec /nix monté
Trop d'outils dans un seul devShell	Temps d'entrée long, résolution de conflits plus probable	Plusieurs devShells nommés selon le rôle (default, sec, ci)
shellHook lourd	Ralentit chaque nix develop	Garder le shellHook court, déléguer aux scripts
Ignorer nix flake check en PR	Erreurs de structure détectées trop tard	Ajouter nix flake check --no-build comme premier job
Mettre à jour flake.lock sans branche dédiée	Impossible de revenir en arrière proprement	Toujours une branche + PR dédiée pour les mises à jour

Glissez pour voir

---

À retenir

• La flake devient le contrat entre le poste de développement, la CI et les collègues, une seule source de vérité pour toute l'équipe
• nix develop --command ... en CI consomme exactement le même environnement qu'en local, plus de divergence
• flake.lock doit être versionné dans Git, il garantit que tout le monde et la CI travaillent avec les mêmes révisions
• Les checks Nix sont mis en cache : un check déjà réussi ne tourne pas une deuxième fois
• writeShellApplication est le moyen propre d'empaqueter des scripts avec leurs dépendances, placées en tête du PATH du seul script
• L'onboarding se résume à : installer Nix une fois + git clone + nix develop
• Mettez flake.lock à jour régulièrement via une PR dédiée, jamais directement sur la branche principale

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

×

📖 Voir la documentation →