Nix vs Docker :
ce que la hype ne vous dit pas

Introduction

En deux semaines, deux CTO m'ont posé la même question. L'un à Abidjan, l'autre à La Réunion. Les deux avaient vu passer des contenus affirmant que "Nix est le nouveau Docker" et que les containers étaient finis. Cet article remet les choses en perspective : Nix et Docker ne résolvent pas le même problème.

Ce que Docker résout - et ce qu'il ne résout pas

Docker popularise l'idée d'emballer une application et ses dépendances dans une image portable. Le format OCI est aujourd'hui le standard de fait pour le déploiement moderne : Kubernetes, ECS, Cloud Run, Fly.io, Railway...

Mais Docker ne garantit pas la reproductibilité du build, seulement celle du runtime. Un Dockerfile classique utilise des tags mutables et des dépôts qui évoluent dans le temps.

FROM node:20-alpine
RUN apk add --no-cache python3 make g++
COPY . .
RUN npm ci
CMD ["node", "dist/index.js"]

Si vous rebuildez cette image dans 6 mois sans cache, le résultat peut différer. C'est la configuration drift au build.

Ce que Nix résout - et son périmètre réel

Nix traite les packages comme des valeurs pures : chaque artefact est adressé par un hash de ses inputs (sources, dépendances, flags de compilation).

/nix/store/abc123xyz-curl-8.5.0/
/nix/store/def456uvw-openssl-3.2.1/

Mêmes inputs = même hash = même résultat. Le build est sandboxé (pas de réseau arbitraire, pas d'état cache hôte), ce qui rend la reproductibilité structurelle.

Nix Flakes : reproductibilité projet

Avec les Flakes et leur fichier de lock, l'équipe partage exactement les mêmes versions d'outils.

{
  inputs.nixpkgs.url = "github:NixOS/nixpkgs/nixos-24.05";
  outputs = { self, nixpkgs }: {
    devShells.x86_64-linux.default =
      nixpkgs.legacyPackages.x86_64-linux.mkShell {
        packages = with nixpkgs.legacyPackages.x86_64-linux; [
          nodejs_20
          python311
          postgresql_16
        ];
      };
  };
}

Les deux problèmes sont orthogonaux

La hype les oppose, mais ils opèrent à des couches différentes.

La preuve de complémentarité : Nix peut aussi générer des images OCI déterministes via dockerTools.

Le cas Anthropic : souvent mal cité

La conférence SCALE 22x (mars 2025) est souvent interprétée comme "Nix remplace Docker en prod". En réalité, Anthropic a traité un problème de cold start extrême sur des images de modèles > 25 GB avec une architecture Nix cachée et distribuée, à leur échelle.

C'est une solution d'ingénierie avancée, pas un pattern universel pour un projet client standard.

Réalité terrain (2025-2026)

• Projet existant Docker : migrer vers Nix introduit une dette d'apprentissage et un risque de transition, pour peu de gain visible côté client.
• Projet greenfield : Nix est pertinent si l'équipe est formée et si la reproductibilité stricte est un requirement explicite (compliance, benchmarking, supply chain).
• Question clé : votre problème est-il le build reproductible ou le déploiement portable ?

Recommandations concrètes

• En local : nix develop ou devenv.sh est une alternative sérieuse à Docker Compose (moins d'overhead sur macOS, pas de daemon).
• En CI : Nix + cache binaire (Cachix ou self-hosted) peut réduire les temps de build sur des pipelines lourdes.
• En production : sauf contrainte forte, gardez les images OCI classiques.
• Approche hybride : générez vos images OCI avec Nix pour cumuler reproductibilité du build et compatibilité de déploiement.

Conclusion

Docker n'est pas mort. Nix n'est pas son successeur. Ce sont deux outils qui résolvent deux problèmes différents, avec des zones de complémentarité très concrètes.

Avant d'adopter un outil "parce que c'est le futur", posez une question simple : quel problème concret cela résout-il, dans mon contexte, avec mon équipe, chez mon client ?