Docker contre les jails, la comparaison honnête

Tous les six mois, le même marronnier revient dans les fils de discussion : les jails FreeBSD écraseraient Docker sur le terrain de l’efficacité et on devrait tous se sentir coupables d’avoir choisi les conteneurs. L’argumentaire n’est pas entièrement faux, il contient même quelques remarques justes, mais celles-ci se retrouvent noyées sous des comparaisons sélectives et des métriques trompeuses.

Je vais reprendre les points un par un, parce que distinguer la critique légitime de la désinformation me semble plus utile que de défendre un camp.

Ce qui est vrai et qu’il faut reconnaître

Les images par défaut sont obèses, personne de sérieux ne prétendra le contraire. Le layer caching exige de la discipline et sans cette discipline on accumule effectivement des couches inutiles. Quant au licensing de Docker Desktop, c’est une vraie préoccupation pour un contexte d’entreprise et je me demande d’ailleurs qui continue de payer cela.

Ces trois critiques tiennent la route. Le problème commence quand on les mélange à des chiffres qui ne veulent rien dire.

Le daemon à 5,3 Go ou l’art de citer la mauvaise colonne

On nous ressort régulièrement un daemon Docker qui consommerait 5,3 Go. Sauf qu’il s’agit de mémoire virtuelle, pas de RSS. Un processus peut réserver des gigaoctets en adressage virtuel tout en n’occupant qu’une fraction de la RAM réellement résidente et c’est le comportement normal d’à peu près tout ce qui tourne sur un système moderne.

Citer VIRT au lieu de RSS, c’est soit de l’ignorance, soit une désinformation volontaire. Dans les deux cas, le chiffre ne prouve rien.

150 Mo pour une image, un choix et non un défaut

On compare ensuite les 150 Mo d’un conteneur par défaut aux quelques mégaoctets d’une jail, comme si Docker vous imposait cette taille. Alpine tient dans 150 Mo, l’image par défaut dans 1 Go, mais c’est un choix de l’utilisateur, pas une tare de l’outil. Mieux encore, les multi-stage builds existent précisément pour cela : l’outillage est là et ne pas s’en servir relève de votre responsabilité, pas de celle du moteur. [edit: 2026] On peut aussi avoir des images FROM scratch qui, dans le cas de binaires standalone, ne contiennent que ledit binaire et ne pèsent donc quasiment rien; llmp2p en est un exemple, un binaire Go statique seul dans l’image. Sur le durcissement d’une image et sa diète, je renvoie à mes notes sur le hardening Docker et le mode rootless .

Quant au 4 Mo par jail opposé aux 150 Mo par conteneur, la comparaison est malhonnête dans son principe même. Une jail partage un système de base déjà installé sur l’hôte. Un conteneur embarque explicitement ses dépendances pour rester reproductible sur n’importe quelle machine. Cette redondance apparente, c’est la fonctionnalité recherchée, pas le bug.

Les jails existent depuis 2000 et pourtant

L’argument de l’antériorité revient toujours : les jails sont là depuis 2000, bien avant la mode des conteneurs. C’est exact et l’industrie a quand même choisi les conteneurs. Pourquoi ?

Parce que les jails sont cantonnées à FreeBSD. Pas d’écosystème, pas de registries d’images, pas d’intégration CI/CD standard, pas de portabilité multi-plateforme. L’élégance technique ne vaut rien sans adoption et l’adoption se construit sur un écosystème, pas sur une prouesse isolée.

On nous vante aussi un démarrage à froid en quelques millisecondes. Un conteneur en cache démarre lui aussi en millisecondes et le temps du premier pull est comparable à celui qu’on passe à installer un système de base FreeBSD. L’avantage s’évapore dès qu’on mesure la même chose des deux côtés.

Reposer la vraie question

Au fond, le débat n’est pas Docker contre jails. La question qui compte, c’est : quel niveau d’isolation, de portabilité et de support d’écosystème votre cas d’usage exige-t-il réellement ?

Opposer un écosystème mature et multi-plateforme à une technologie mono-OS, puis décréter la victoire sur un critère d’empreinte mémoire, revient à féliciter un vélo de consommer moins de carburant qu’un avion. Techniquement exact et complètement à côté du sujet.

Les jails FreeBSD sont excellentes. Sur FreeBSD, pour des charges FreeBSD, administrées par des gens qui connaissent FreeBSD. Pour tout le reste, il y a une raison pour laquelle l’industrie est passée à autre chose. L’écosystème des conteneurs n’a pas ignoré la sécurité ni l’efficacité, il les a résolues autrement, en faisant de la portabilité une contrainte de premier ordre et non une variable d’ajustement.

Pour ceux qui veulent une isolation plus forte sans renoncer à l’écosystème, des projets comme Kata Containers ou les micro-VM à la Firecracker (dont j’ai parlé dans isolation Firecracker ) combinent déjà les avantages des machines virtuelles et des conteneurs, en visant une meilleure isolation des charges tout en conservant la rapidité des conteneurs traditionnels. C’est là que se joue la vraie discussion, pas sur une colonne de htop mal lue.

Alors, lequel ?

Un chiffre de mémoire ne veut rien dire tant qu’on ne précise pas s’il s’agit de VIRT ou de RSS.
La taille d’une image est un choix de build, pas une fatalité imposée par Docker.
Une jail partage le système de base, un conteneur embarque ses dépendances pour rester reproductible et c’est exactement ce qu’on lui demande.
L’élégance technique ne survit pas sans écosystème, registries et portabilité.
La bonne question n’est pas l’outil, c’est le niveau d’isolation, de portabilité et de support dont votre usage a besoin.

[edit: 2026] L’implémentation Ansible de tout ceci: les rôles docker et podman .