Programmation · DevOps · Conteneurs

Docker vs Podman : quel moteur de conteneurs, et quand ?

Réponse rapide : Docker et Podman font le même travail de fond — construire et exécuter des conteneurs — et utilisent le même format d’image, si bien qu’une image construite avec l’un tourne sur l’autre. La principale différence est l’architecture : Docker exécute les conteneurs via un daemon central de longue durée (dockerd) qui tourne généralement en root, tandis que Podman est sans daemon et rootless par conception, en lançant chaque conteneur comme un simple processus enfant. Leurs lignes de commande sont assez proches pour que alias docker=podman couvre l’essentiel de l’usage quotidien. Choisissez Podman pour vous passer de daemon root et profiter d’une intégration systemd serrée ; restez sur Docker si vous dépendez de Docker Desktop, d’un workflow Compose mûr ou d’un écosystème plus large.

Si vous débutez avec l’un ou l’autre, il est utile de comprendre d’abord ce que sont Docker et les conteneurs. Ce guide part de là et se concentre sur ce qui distingue les deux moteurs.

Architecture : avec daemon vs sans daemon

Docker repose sur un modèle client-serveur. La commande docker que vous tapez est un client qui parle à un service en arrière-plan, le daemon Docker (dockerd), qui crée et exécute réellement vos conteneurs. Ce daemon tourne en continu et, dans la configuration par défaut, en root. C’est pratique — un seul service gère tout — mais c’est aussi un unique processus privilégié qui possède tous les conteneurs de l’hôte.

Podman emprunte une autre voie. Pas de daemon central : quand vous lancez un conteneur, Podman le fork puis l’exec directement comme processus enfant de votre shell, en s’appuyant sur les mêmes primitives Linux (namespaces, cgroups). Chaque conteneur n’est qu’une arborescence de processus ordinaire. Ce modèle sans daemon signifie qu’il n’y a pas de service root toujours actif à compromettre, et qu’un crash dans un conteneur ne transite pas par un daemon partagé.

Conteneurs rootless et sécurité

Cette différence d’architecture mène à la différence de sécurité qui compte le plus. Podman a été conçu pour tourner en rootless : un utilisateur non privilégié peut construire et exécuter des conteneurs sans root, en utilisant les user namespaces pour mapper les UID des conteneurs vers l’hôte. Docker peut aussi tourner en rootless, et le supporte depuis des années, mais son installation par défaut reste centrée sur le daemon root : le rootless est donc un mode optionnel plutôt que la base.

Ne pas avoir de daemon root réduit la surface d’attaque : aucun service privilégié en arrière-plan qu’une évasion de conteneur pourrait viser pour prendre le contrôle de l’hôte. Pour les serveurs multi-utilisateurs et les runners de CI, cette propriété « pas de daemon root » est une vraie raison concrète de passer à Podman. Ce n’est pas magique — les conteneurs demandent toujours une configuration soignée — mais la posture par défaut est plus prudente.

Mêmes images, CLI quasi identique

Voici ce qui rend le passage indolore : les deux outils suivent les standards OCI (Open Container Initiative) pour les images et l’exécution. Une image construite avec Docker tourne sous Podman et inversement, et les deux tirent des mêmes registres (Docker Hub, GitHub Container Registry, Quay, et d’autres). Il n’existe pas de format d’image propre à Docker ou à Podman.

Les lignes de commande sont volontairement proches. podman run, podman build, podman ps et podman pull reproduisent leurs équivalents Docker, avec les mêmes options courantes. Beaucoup de gens posent simplement un alias :

alias docker=podman

et gardent leurs habitudes. Les Dockerfiles fonctionnent tels quels sous Podman aussi. La CLI n’est pas identique à 100 % dans tous les cas de figure, mais pour construire et exécuter au quotidien, elle est assez proche pour que la mémoire musculaire se transfère.

Les pods : le regroupement façon Kubernetes de Podman

Podman tire son nom du pod — un concept emprunté à Kubernetes. Un pod est un groupe de conteneurs qui partagent des ressources comme un namespace réseau, si bien qu’ils communiquent entre eux via localhost comme s’ils étaient sur la même machine. Podman peut créer et gérer ces pods directement, ce qui rapproche le développement local de la façon dont les choses tournent dans un cluster Kubernetes. Docker n’a pas de primitive « pod » native au même sens ; on compose les montages multi-conteneurs avec les réseaux Compose à la place.

Intégration systemd

Comme les conteneurs Podman sont des processus enfants ordinaires plutôt que les enfants d’un daemon, ils s’intègrent naturellement à systemd, le gestionnaire de services de Linux. Historiquement, on pouvait lancer podman generate systemd pour produire un fichier d’unité par conteneur ; l’approche actuelle recommandée est Quadlet, qui permet de décrire les conteneurs dans des fichiers déclaratifs de style unité que systemd gère directement — démarrage au boot, redémarrage en cas d’échec, et suivi comme n’importe quel autre service. Pour les serveurs qui utilisent déjà systemd pour tout le reste, c’est une façon propre de placer les conteneurs sous le même superviseur, sans daemon supplémentaire.

Compose : docker compose vs podman

Beaucoup de projets s’appuient sur Compose pour démarrer plusieurs conteneurs à partir d’un seul fichier YAML. Docker fournit docker compose (le plugin Compose v2) comme outil de première classe, bien maintenu. Podman supporte aussi les workflows Compose : il peut fonctionner avec l’outil séparé podman-compose, et il expose également un socket auquel l’outillage Compose standard peut se connecter, si bien que des fichiers compose.yaml existants tournent souvent sans modification ou presque. En pratique, l’expérience Compose de Docker est la plus mûre et la plus aboutie des deux, ce qui explique que les équipes très portées sur Compose restent parfois sur Docker.

Licence Docker Desktop vs modèle open source de Podman

Sous Windows et macOS, Docker s’utilise généralement via Docker Desktop. Docker Desktop est gratuit pour l’usage personnel, l’éducation et les petites entreprises, mais il exige un abonnement payant pour les grandes organisations (au-delà du seuil de taille publié par Docker). Ce changement de licence est une vraie question de budget et de conformité pour les plus grandes entreprises.

Podman est entièrement open source et gratuit, sans licence par poste. Son compagnon bureau, Podman Desktop, est lui aussi open source. Pour les organisations qui veulent éviter une licence bureau commerciale — ou simplement préférer une pile open source de bout en bout — cette différence compte autant que n’importe quelle différence technique.

Alors, lequel choisir ?

Critère	Docker	Podman
Architecture	Daemon central (dockerd)	Sans daemon (fork/exec par conteneur)
Rootless	Supporté, optionnel	Rootless par conception (défaut)
Format d’image	OCI	OCI — interchangeable avec Docker
CLI	CLI de référence	Quasi identique (alias docker=podman)
Pods	Pas de primitive pod native	Pods natifs (façon Kubernetes)
systemd	Tourne sous le daemon	Unités natives via Quadlet
Compose	docker compose (mûr)	podman-compose / Compose via socket
Licence bureau	Docker Desktop payant pour grandes orgs	Open source, gratuit (Podman Desktop)

Il n’y a pas de vainqueur universel. Choisissez Podman pour vous passer de daemon root, avoir des conteneurs rootless par défaut, une gestion systemd/Quadlet native, ou éviter la licence Docker Desktop. Restez sur Docker si vous dépendez de Docker Desktop, d’un workflow Compose mûr, ou de l’ampleur de son écosystème et de sa documentation. Comme les deux parlent OCI, vous pouvez aussi les mélanger — construire avec l’un, exécuter avec l’autre — ou tester Podman sans jeter vos images et Dockerfiles existants. Et si vous devez ensuite orchestrer beaucoup de conteneurs sur plusieurs machines, c’est l’affaire de Kubernetes, qui se situe au-dessus des deux.