Toolpak veut faire pour les outils de développement ce que Flatpak a fait pour les applications
Le 26 septembre 2026, le développeur GNOME Jordan Petridis a présenté Toolpak, un format inspiré de Flatpak pour distribuer strace, ripgrep ou qemu sur les systèmes image-based sans les casser. Pour quiconque travaille sur Silverblue ou GNOME OS, c’est la pièce qui manquait au puzzle des distributions immuables.
26 septembre 2026. Le développeur GNOME Jordan Petridis publie un billet intitulé « Introducing Toolpak » pour présenter un format de distribution des outils de développement pensé pour les systèmes image-based. 26 septembre 2026. La proposition est reprise le jour même par Phoronix, qui la décrit comme « un Flatpak pour les outils ». Prochaines semaines. Un prototype est attendu dans le cadre d’un projet Prototypefund. Pourquoi c’est important : Flatpak a réglé la distribution des applications sur les distributions immuables, mais a laissé un trou béant pour les outils en ligne de commande — et c’est exactement ce trou que Toolpak veut combler.
Le trou que Flatpak n’a pas comblé
Les systèmes d’exploitation grand public — iOS, Android, macOS, ChromeOS — ont adopté depuis des années des architectures image-based : le système est un bloc signé et atomique qu’on ne modifie pas fichier par fichier. Le bureau Linux a commencé à suivre, avec Fedora Silverblue, GNOME OS, Vanilla OS ou openSUSE Aeon. Le bénéfice est réel : mises à jour atomiques, retours en arrière fiables, surface d’attaque réduite.
Flatpak a à peu près résolu la distribution des applications graphiques sur ces systèmes, avec Flathub comme catalogue. Mais l’histoire du côté développeur reste inachevée. Sur un système classique, installer un outil se résume à un apt install strace ou dnf install qemu, puis à compiler contre les bibliothèques du système. Sur un système image-based, ce réflexe ne fonctionne plus : l’image est en lecture seule, et toute surcouche globale menace sa cohérence.
Les contournements actuels ont chacun une limite connue. Les overlays rpm-ostree de Silverblue peuvent casser le système de façon imprévisible — c’est pourquoi l’itération suivante, basée sur bootc, les évite explicitement. L’overlay « developer » monolithique, façon Android ou iOS, est une liste finie d’utilitaires taillée pour compiler l’OS lui-même, pas la longue traîne des outils de débogage et de développement noyau. Toolbox et distrobox replacent l’expérience paquet dans un conteneur, mais un environnement conteneurisé restreint précisément les cas où l’on doit inspecter le système hôte. Homebrew fournit une chaîne indépendante, mais priorise ses binaires sur ceux du système — installez QEMU, et il peut écraser la GLib dont le reste du système dépend.
Flatpak lui-même ne convient pas : pensé pour les applications desktop, il impose les portals et un sandbox qui colle mal aux utilitaires en ligne de commande, aux débogueurs et aux IDE. Jordan Petridis le formule sans détour : une grande partie des utilitaires dont dépendent les développeurs « ne peuvent pas raisonnablement tourner dans un environnement confiné sans une réécriture quasi complète ».
Ce que Toolpak propose
Toolpak part de trois propriétés non négociables : les outils doivent être indépendants du système hôte et ne pas le casser s’ils échouent ; ils doivent bénéficier d’un large catalogue, comme dans les dépôts de distribution ; et ils doivent fonctionner immédiatement, sans portage — y compris lorsqu’ils invoquent d’autres outils du système.
L’implémentation imaginée par Petridis est précise. Le format d’image serait les Discoverable Disk Images de la spécification UAPI.3, ce qui ouvre la voie à Verity et aux builds reproductibles. Chaque outil serait monté dans un namespace de montage dédié, avec la séparation /usr / /app empruntée à Flatpak : /usr provient d’une image runtime partagée, /app contient le contenu de l’outil. Les binaires seraient préfixés au PATH de l’utilisateur, et un lanceur mettrait en place le namespace avant d’exécuter le vrai binaire — sans toucher au linker ni aux bibliothèques du système.
Deux choix structurent le projet. D’une part, les outils ne dépendent pas d’autres outils : ils regroupent toutes leurs dépendances, éliminant la résolution de dépendances qui alourdit les distributions classiques. D’autre part, tout ce que Flatpak sait déjà empaqueter est refusé : Toolpak ne s’occupe que de ce que Flatpak ne peut pas faire.
Pourquoi c’est plus sûr qu’un apt install global
Le point qui intéresse directement un SRE ou un administrateur de postes : Toolpak inverse la hiérarchie de confiance du apt install traditionnel. Installer un paquet global, c’est donner à un dépôt la possibilité d’écrire partout sur le système. Un Toolpak, lui, ne modifie jamais l’image de base ; il superpose un binaire à un point précis du PATH, et rien d’autre.
La sécurité est intégrée dès le départ. Les images devront être signées par une clé de confiance, vérifiées par Verity à l’exécution, et relues avant d’apparaître sur la boutique de référence. L’objectif affiché est de tuer le réflexe « télécharger un binaire statique et chmod +x » au profit d’une distribution vérifiable, sur le modèle de Flathub.
Le revers est assumé : parce qu’un Toolpak a un accès complet au système, la confiance se déplace du dépôt vers la signature et la revue. C’est le même compromis que Flathub, appliqué à une classe d’outils que personne n’avait encore couverte. La chaîne de build visée — orchestration des builds, cache en content-addressable storage, reproductibilité par défaut, gestion des licences et des SBOM, greffon Buildstream — répond au besoin de traçabilité qu’une équipe plateforme exige.
La bascule des distributions atomiques
Toolpak s’inscrit dans une accélération plus large. Fedora prépare la transition de Silverblue vers bootc, qui abandonne le paradigme des overlays rpm-ostree au profit d’images composées. GNOME OS expérimente sysupdate et composefs pour ses mises à jour. Vanilla OS et openSUSE Aeon poussent des modèles équivalents. Tous butent sur le même mur : l’application graphique est réglée par Flatpak, mais l’outil de développement reste un angle mort.
Ce vide explique la multiplication des bricolages. Certains développeurs font tourner une distribution classique dans une VM ou un conteneur juste pour garder strace et gdb sous la main. D’autres superposent des overlays qu’ils savent fragiles. Chacun de ces contournements réintroduit exactement la complexité que l’image atomique était censée supprimer.
Toolpak est une réponse de plus à ce problème, mais elle a une particularité : elle accepte de ne pas confiner. Là où Flatpak et les conteneurs partent du principe que tout doit être sandboxé, Petridis part du constat inverse — certains outils, comme strace qui inspecte le noyau via ptrace, ne peuvent pas être confinés sans perdre leur raison d’être. La signature et la revue remplacent alors le sandbox comme mécanisme de confiance.
Verdict
Si vous développez sur une distribution image-based — Silverblue, GNOME OS, Aeon — Toolpak n’est encore qu’une proposition et un prototype à venir ; en attendant, restez sur Toolbox ou distrobox pour les environnements jetables, et évitez les overlays rpm-ostree persistants pour tout ce qui n’est pas critique. Si vous maintenez des outils en ligne de commande, surveillez l’appel à contribution de Petridis sur Matrix (#gnome-os:gnome.org) : être parmi les premiers empaqueteurs du futur catalogue est un levier de distribution réel. Si vous gérez un parc de postes Linux, retenez la leçon de fond — la distribution des outils de développement est le prochain chantier de l’immutabilité, et les systèmes qui le règlent sans casser l’image gagneront les équipes d’ingénierie. Flatpak a fait le travail pour les applications ; Toolpak veut faire le même pour les outils, et c’est une pièce qui manquait depuis que le bureau Linux est devenu atomique.