Docker a gagné, c'est entendu, et je ne vais pas prétendre le contraire. Mais après trois ans à faire tourner de la production sur des Jails FreeBSD, j'ai fini par avoir un avis assez tranché sur ce que chacun fait bien — et sur ce qu'on paie, dans un cas comme dans l'autre.

Comment j'en suis arrivé là

Je ne me suis pas réveillé un matin avec l'envie de faire de l'exotisme. J'y suis venu par un chemin très banal : des machines qui devaient tourner longtemps, sans surprise, avec peu de maintenance et un budget qui ne suivait pas la croissance du cluster. Le genre de contexte où l'on regarde la facture d'orchestration et où on se demande, honnêtement, ce qu'elle achète.

Les Jails existent depuis FreeBSD 4.0, c'est-à-dire depuis l'an 2000. Ce n'est pas une technologie émergente qu'on essaie de vendre, c'est une brique qui a eu vingt-cinq ans pour se stabiliser. Et cette stabilité-là, quand elle est le critère principal, change complètement la conversation.

Ce que les Jails font franchement mieux

L'isolation est dans le noyau, pas construite par-dessus

C'est la différence conceptuelle qui compte le plus, et elle est trop souvent réduite à un détail d'implémentation. Une Jail est une primitive du noyau FreeBSD : l'isolation est une propriété du système, pensée comme telle dès le départ. Un conteneur Linux, lui, est un assemblage — namespaces, cgroups, capabilities, seccomp, LSM — que le moteur de conteneurs orchestre pour vous. L'assemblage est excellent, mais c'est un assemblage, avec ce que ça implique de surfaces de contact et de configurations par défaut qu'il faut connaître pour ne pas se tromper.

En pratique, ça se voit dans l'historique des évasions de conteneurs : elles existent des deux côtés, mais elles ne se ressemblent pas. Côté Linux, plusieurs ont exploité précisément les jointures de l'assemblage. Je ne dirai jamais qu'une Jail est inviolable — ce serait stupide — mais la surface est plus étroite et plus lisible.

ZFS change la nature des opérations

C'est probablement l'argument que je mets en avant le plus souvent, et paradoxalement celui qui n'a rien à voir avec les Jails elles-mêmes. Avoir ZFS nativement, intégré au système et non rapporté, transforme le quotidien : un snapshot avant une mise à jour prend une seconde et ne coûte rien, un rollback est instantané, et cloner une Jail complète pour reproduire un bug se fait sans copier un octet.

Cette capacité à revenir en arrière sans réfléchir change la façon dont on aborde une intervention en production. On devient plus audacieux parce qu'on est mieux assuré.

Les performances sont natives, sans couche intermédiaire

Pas de système de fichiers en couches à traverser, pas de couche réseau à empiler quand on utilise VNET. Les processus s'exécutent directement, et ce qu'on mesure ressemble à ce qu'on mesurerait sur la machine nue. Sur des charges à forte pression disque, l'écart devient visible.

Ce que Docker fait mieux, et ce n'est pas rien

Il faut être honnête, sinon l'article ne vaut rien : sur la plupart des critères qui comptent pour une équipe produit, Docker gagne, et il gagne largement.

  • L'écosystème d'images. Vous voulez un PostgreSQL, un Redis, un service tiers quelconque ? C'est une ligne et trente secondes. Côté Jails, vous partez d'une base et vous assemblez vous-même. Ça se fait très bien, mais ça se fait.
  • La portabilité. Une image OCI tourne sur le portable du développeur, sur la CI et en production, à l'identique. Une Jail tourne sur FreeBSD, point final. C'est une contrainte structurelle, pas un détail qu'on contourne.
  • L'orchestration. Kubernetes n'a pas d'équivalent dans le monde FreeBSD. Il existe d'excellents outils de gestion — Bastille, iocage, CBSD — mais ce sont des outils de gestion, pas des orchestrateurs distribués avec réconciliation d'état.
  • L'intégration cloud. Les fournisseurs managés sont conçus pour Linux. Sortir de ce cadre, c'est renoncer à une partie de l'outillage que vous payez déjà.

Ce que ça coûte vraiment

Le coût réel n'est pas technique, il est humain et organisationnel — c'est presque toujours là que ça se joue.

Le premier poste, c'est la connaissance. FreeBSD n'est pas Linux : l'arborescence diffère, rc.conf remplace ce que vous connaissez, pf remplace iptables ou nftables, pkg remplace apt. Rien d'insurmontable pour quelqu'un qui a l'habitude des systèmes, mais il faut compter des semaines avant d'être réellement à l'aise, et non des jours.

Le deuxième, c'est le recrutement. Un développeur qui connaît Docker, vous en trouvez partout. Un administrateur à l'aise avec FreeBSD, beaucoup moins. Si votre infrastructure repose sur une personne seule, vous avez créé un point de défaillance humain, et ça ne se corrige pas avec une astreinte.

Le troisième, plus insidieux, c'est le coût d'intégration permanent. Chaque outil tiers, chaque agent de supervision, chaque solution SaaS de logs ou d'APM suppose Linux par défaut. Ça finit toujours par fonctionner, mais chaque intégration demande un travail que personne n'avait budgété.

Quand il ne faut PAS choisir les Jails

Je le dis à mes clients avant qu'ils ne me le demandent, parce que se tromper là-dessus coûte cher :

  • Votre équipe est entièrement Linux et votre priorité est de livrer vite. Le coût d'apprentissage arrivera exactement au mauvais moment.
  • Vous avez besoin de Kubernetes, réellement besoin — beaucoup d'équipes croient en avoir besoin sans que ce soit le cas, mais quand c'est vrai, c'est vrai. Restez sur Linux.
  • Vous dépendez massivement d'images tierces que vous ne voulez pas reconstruire.
  • Vous êtes sur du cloud managé et vous en tirez une vraie valeur.
  • Vous cherchez un gain de performance sans avoir profilé : si votre goulot d'étranglement est la base de données ou un appel réseau, changer de technologie de conteneurisation ne vous apportera strictement rien.

La migration se fait par le bord, jamais par le centre

Si le contexte s'y prête, la bonne approche n'est pas de tout basculer — c'est même le meilleur moyen d'échouer bruyamment. Ce que je recommande ressemble à ceci :

  1. Commencez par les services longs et stables : bases de données, caches, proxys inverses, tout ce qui vit longtemps et se redéploie peu. C'est là que la stabilité et ZFS rapportent le plus.
  2. Gardez Docker pour l'éphémère : la CI, les environnements de développement, tout ce qui doit être jetable et reproductible sur n'importe quelle machine.
  3. Mesurez sur trois mois — consommation, incidents, temps d'exploitation réel. Pas des impressions, des chiffres.
  4. Documentez au fur et à mesure, sans quoi vous fabriquez le point de défaillance humain évoqué plus haut.

Les deux mondes cohabitent très bien. C'est d'ailleurs la configuration que je rencontre le plus souvent chez ceux qui ont fait ce choix sans idéologie.

En résumé

Les Jails ne remplacent pas Docker, et quiconque vous vend ça n'a pas regardé le problème d'assez près. Elles répondent à un besoin différent : de l'infrastructure qui doit tourner longtemps, sobrement, avec une isolation solide et des opérations réversibles — le tout dans un contexte où la portabilité et l'orchestration distribuée ne sont pas les critères décisifs.

Si votre contrainte est de livrer vite, avec une équipe Linux et un écosystème riche, Docker reste le bon choix, et je vous le dirai. Si votre contrainte est de tenir des années avec peu de maintenance et une empreinte réduite, les Jails méritent au minimum qu'on les évalue sérieusement. La vraie erreur, dans les deux sens, c'est de choisir par habitude ou par mode plutôt qu'en fonction de ce qu'on cherche à obtenir.

Une infrastructure à consolider, ou simplement l'envie de savoir si ce choix aurait du sens chez vous ? Parlons-en — je préfère vous dire que ce n'est pas adapté plutôt que de vous vendre une migration dont vous n'avez pas besoin.