Flakes : comprendre la fonctionnalité la plus utilisée (et la plus débattue) de l'écosystème Nix

Il existe, dans l'écosystème Nix, une situation qui mérite d'être expliquée avant d'être commentée. Une fonctionnalité aujourd'hui adoptée par la majorité des utilisateurs de Nix, recommandée par défaut dans une grande partie des projets open source, continue de porter huit ans après son introduction l'étiquette officielle "expérimentale". Cette fonctionnalité, ce sont les flakes. Chez Hebeko, nous travaillons régulièrement avec des environnements Nix pour nos clients, et cette ambiguïté de statut revient systématiquement dans les échanges avec les équipes techniques qui évaluent l'outil. Cet article a pour objectif de poser clairement les termes du débat, sans en éluder la dimension conflictuelle.

Le problème que les flakes viennent résoudre

Nix se distingue des autres gestionnaires de paquets par une promesse forte : fournir la même expression à deux machines différentes doit produire un résultat strictement identique, au bit près. Cette promesse constitue l'un des principaux arguments en faveur de l'adoption de Nix en entreprise, notamment pour les équipes soucieuses de traçabilité et de conformité de leurs environnements de production.

Avant l'introduction des flakes, cette promesse comportait néanmoins une faille. Les projets Nix s'appuyaient sur des channels, des canaux globaux et mutables susceptibles de différer d'une machine à l'autre, ainsi que sur un chemin de recherche (NIX_PATH) dont la résolution dépendait de l'environnement local. Deux collaborateurs travaillant sur un même dépôt pouvaient, sans modification de code, obtenir des résultats de build différents.

Ce que les flakes apportent concrètement

flowchart LR
    A["flake.nix<br/>déclare les entrées<br/>(nixpkgs, flakes tierces...)"] --> B["flake.lock<br/>épingle chaque entrée<br/>à un commit précis"]
    B --> C["Reproductibilité bit à bit<br/>nix develop produit le même<br/>environnement partout"]

En 2019, Eelco Dolstra, créateur de Nix, propose les flakes en réponse à ce problème. Le principe repose sur quatre éléments :

Un fichier flake.nix, qui déclare explicitement l'ensemble des dépendances d'un projet.
Un fichier flake.lock, généré automatiquement, qui épingle chacune de ces dépendances à un commit précis.
Une évaluation dite "pure", indépendante des variables d'environnement et de l'état local de la machine.
Une structure de sortie standardisée (packages, devShells, nixosConfigurations), qui rend tout projet immédiatement compréhensible par une autre équipe, sans documentation additionnelle.

L'effet pratique est significatif pour une organisation : cloner un dépôt et exécuter nix develop suffit à obtenir un environnement de développement rigoureusement identique à celui de son auteur d'origine, sans étape d'installation manuelle. Il s'agit d'un gain réel en matière de fiabilité des environnements techniques, qu'il convient de reconnaître avant d'aborder les points de désaccord.

Un désaccord persistant au sein de la communauté

Ce gain n'a cependant jamais suffi à produire un consensus au sein de la communauté Nix. Ce désaccord mérite d'être détaillé, car il éclaire directement les précautions à prendre lors d'une adoption en entreprise.

Premier point de friction : le mode d'introduction de la fonctionnalité

Une partie de la communauté a mal accueilli le fait que la RFC initiale consacrée aux flakes ait été abandonnée en cours de route, alors que la fonctionnalité elle-même a néanmoins fini par être intégrée à Nix. D'autres contributeurs n'étaient pas opposés, par principe, à l'intégration de fonctionnalités expérimentales sans RFC formelle (une pratique courante dans le projet), mais leur reprochaient de ne s'être, dans les faits, jamais comportées comme des fonctionnalités réellement expérimentales : peu de retours en arrière, peu d'itérations profondes sur la conception, et une adoption si rapide qu'elle a rendu, de fait, tout changement de rupture politiquement difficile à assumer.

Deuxième point de friction : des choix de conception contestés

flowchart TD
    P["Votre projet"] --> A["Flake A<br/>nixpkgs @ a1b2"]
    P --> B["Flake B<br/>nixpkgs @ c3d4"]
    P --> C["Flake C<br/>nixpkgs @ e5f6"]
    A --> W["Trois copies distinctes de nixpkgs<br/>temps de build et espace disque potentiellement multipliés"]
    B --> W
    C --> W

Plusieurs utilisateurs signalent des frictions opérationnelles concrètes. Chaque flake tierce peut embarquer sa propre version de nixpkgs : si un projet dépend par exemple de trois flakes tierces non harmonisées, chacune peut apporter sa propre copie de nixpkgs à un commit différent, ce qui peut multiplier les temps de build et l'espace disque utilisé. Par ailleurs, le couplage étroit avec Git constitue un piège fréquent pour les nouveaux utilisateurs, qui doivent penser à indexer (git add) chaque modification avant de reconstruire, sous peine de la voir silencieusement ignorée. Ces éléments ont une incidence directe sur les temps de développement et méritent d'être anticipés dans le cadre d'une adoption en environnement professionnel.

Troisième point de friction : une conception perçue comme trop spécifique

Une partie des critiques soutient que les flakes auraient été conçues, à l'origine, pour répondre aux besoins d'un client unique, et que leur statut prolongé de fonctionnalité expérimentale limiterait, dans les faits, la probabilité que les lacunes de l'implémentation soient corrigées. Cet argument, bien que formulé de manière parfois polémique, revient régulièrement dans les discussions techniques et ne peut être écarté sans examen.

La position des défenseurs des flakes

Face à ces critiques, les partisans des flakes disposent d'arguments substantiels. Graham Christensen, cofondateur de Determinate Systems (société où travaille également Eelco Dolstra), défend de longue date l'idée que les flakes sont, dans les faits, déjà stables, et que leur étiquette expérimentale n'aurait jamais dû perdurer aussi longtemps. Sa position se résume ainsi : les critiques les plus fréquentes, à savoir la duplication de nixpkgs, l'absence de support natif pour la compilation croisée et le format du fichier de verrouillage, sont, selon lui, soit mal posées, soit sans lien direct avec la conception des flakes, soit déjà en cours de traitement par la communauté. Son entreprise a d'ailleurs publié sa propre distribution de Nix, dans laquelle les flakes sont marquées stables par défaut.

À cet argument s'ajoute un constat difficilement contestable : la majorité des utilisateurs actuels de Nix utilisent également les flakes, un usage de facto qui pèse lourdement dans l'appréciation de leur maturité réelle.

Le compromis institutionnel : la RFC 0136

La gouvernance du projet Nix a tenté de sortir de cette impasse par un texte de référence, la RFC 0136. Ce texte établit d'abord des principes généraux sur l'évolution de Nix, avant de définir un plan de stabilisation progressif : dans un premier temps l'interface en ligne de commande, puis, dans un second temps seulement, les flakes elles-mêmes, dont la conception finale devra encore faire l'objet d'une nouvelle RFC.

L'auteur du texte demande explicitement aux "sceptiques des flakes" de ne pas rouvrir le débat sur le fond de la conception, afin d'éviter de reproduire des discussions longues et sans issue observées par le passé. Cette précaution indique à elle seule le niveau de tension accumulé sur ce sujet au sein du projet.

La RFC reconnaît par ailleurs explicitement que les flakes sont devenues très largement adoptées par les nouveaux utilisateurs de Nix, au point de représenter de facto l'usage majoritaire de l'ensemble de l'écosystème, un constat qui limite considérablement la marge de manœuvre pour toute remise en cause substantielle de leur fonctionnement.

Recommandations pour une adoption en entreprise

Sur la base de ces éléments, nous recommandons chez Hebeko les points de vigilance suivants pour toute organisation évaluant l'adoption des flakes :

L'adoption des flakes ne constitue pas, à ce stade, un choix technologique risqué. Aucune des parties prenantes du débat, y compris les plus critiques, n'envisage sérieusement leur abandon.
L'étiquette "expérimentale" protège principalement contre des changements de rupture ciblés, et non contre un retrait de la fonctionnalité. Il convient d'activer explicitement le paramètre (experimental-features = nix-command flakes) et de suivre les évolutions annoncées du format de verrouillage.
Le couplage avec Git constitue le principal point de friction pour les équipes découvrant Nix. Une modification non indexée est, pour l'outil, une modification qui n'existe pas.
Les dépendances tierces nécessitent une vigilance particulière, en particulier celles peu maintenues, ce point constituant une source de risque plus significative que la conception des flakes elle-même.

Conclusion

Le débat entourant les flakes ne semble pas près de se refermer, et son issue n'est pas certaine à court terme. Les deux positions défendent chacune une exigence légitime : la rigueur du processus de stabilisation d'un côté, la reconnaissance d'un usage déjà massif de l'autre. Pour une organisation qui évalue Nix aujourd'hui, l'essentiel est de comprendre ce contexte plutôt que de l'ignorer. Cette compréhension permet d'anticiper les points de friction réels plutôt que de les découvrir en cours de projet.

HeBeKo accompagne l'adoption de NixOS et des flakes en production. Voir NixOS chez HeBeKo ou contactez-nous.

---

Sources