Podman vs Docker : quelle différence et lequel choisir ?

Docker a démocratisé les conteneurs et reste la référence, mais Podman s’est imposé comme une alternative crédible, notamment dans l’écosystème Red Hat et sur les serveurs. Les deux exécutent des images OCI et partagent une ligne de commande quasi identique — au point qu’on peut souvent remplacer l’un par l’autre sans réécrire ses habitudes. Alors où se situe vraiment la différence, et lequel choisir pour votre projet ? Ce comparatif passe en revue les points concrets qui comptent au quotidien.

L’architecture : daemon contre daemonless

C’est la différence fondamentale. Docker repose sur un démon central, dockerd, un processus qui tourne en permanence en arrière-plan, généralement en root. Quand vous tapez docker run, le client envoie une requête à ce démon, qui crée et gère le conteneur. Tous vos conteneurs sont donc des enfants d’un même processus privilégié.

Podman est daemonless : il n’y a aucun processus central. Chaque commande podman lance directement le conteneur comme un processus fils de votre shell, via runc ou crun. Le conteneur appartient à votre session utilisateur.

# Docker : le client parle au démon dockerd
docker run -d nginx

# Podman : pas de démon, le conteneur est un fils du shell
podman run -d nginx

Cette différence a des conséquences très concrètes. Sans démon, Podman n’a pas de point de défaillance unique : si un plantage survient, il n’emporte pas tous les conteneurs. En revanche, l’absence de démon signifie qu’il n’y a personne pour redémarrer automatiquement un conteneur au boot — Podman délègue cette tâche à systemd (nous y revenons).

Le mode rootless et la sécurité

C’est l’argument phare de Podman. Historiquement, Docker exigeait des privilèges root pour son démon, ce qui posait un risque : un utilisateur autorisé à lancer des conteneurs pouvait potentiellement obtenir un accès root sur l’hôte.

Rootless nativement avec Podman

Podman a été conçu dès le départ pour fonctionner sans privilèges. Un utilisateur standard lance ses propres conteneurs, isolés dans son espace utilisateur grâce aux user namespaces du noyau Linux :

# Aucun sudo nécessaire, le conteneur tourne sous votre UID
podman run -d -p 8080:80 nginx

# Vérifier que vous êtes bien en rootless
podman info | grep -i rootless

Le processus à l’intérieur du conteneur voit un utilisateur root, mais sur l’hôte il correspond à votre UID sans privilège. Une évasion de conteneur ne donne donc pas les clés de la machine.

Le rootless côté Docker

Docker a rattrapé ce point avec le mode rootless, mais il s’agit d’une configuration supplémentaire à installer, pas du comportement par défaut :

# Installer le mode rootless de Docker
dockerd-rootless-setuptool.sh install

En pratique, pour un serveur où la sécurité prime, le modèle par défaut de Podman évite toute une classe de risques sans configuration.

La compatibilité de la ligne de commande

Bonne nouvelle : Podman réplique volontairement l’interface de Docker. Les commandes que vous connaissez fonctionnent à l’identique.

podman pull alpine
podman images
podman ps -a
podman build -t mon-image .
podman exec -it mon-conteneur sh
podman logs mon-conteneur

La migration est si transparente que beaucoup créent un alias pour ne rien changer à leurs réflexes :

# Faire répondre "docker" à Podman
alias docker=podman

Certains outils qui parlent au socket Docker (comme Testcontainers ou des scripts CI) attendent une API. Podman fournit un socket compatible :

# Activer le socket compatible API Docker
systemctl --user enable --now podman.socket

# Pointer les outils vers ce socket
export DOCKER_HOST=unix://$XDG_RUNTIME_DIR/podman/podman.sock

Docker Compose et son équivalent Podman

Beaucoup de projets reposent sur un fichier compose.yaml pour orchestrer plusieurs services. Là encore, Podman offre plusieurs voies.

# compose.yaml identique pour les deux outils
services:
  web:
    image: nginx
    ports:
      - "8080:80"
  db:
    image: postgres:16
    environment:
      POSTGRES_PASSWORD: secret

Côté Docker :

docker compose up -d

Côté Podman, deux approches. podman-compose (un projet Python) lit le même fichier :

podman-compose up -d

Ou, plus intégré, vous utilisez le socket Podman avec le vrai binaire docker compose en pointant DOCKER_HOST sur le socket vu plus haut. Le fichier ne change pas.

Les pods : la spécialité de Podman

Le nom « Podman » vient de pod manager. Contrairement à Docker, il sait regrouper plusieurs conteneurs dans un pod, exactement comme Kubernetes : les conteneurs d’un pod partagent le réseau et peuvent se joindre sur localhost.

# Créer un pod exposant un port
podman pod create --name mon-app -p 8080:80

# Ajouter des conteneurs dans le pod
podman run -d --pod mon-app --name web nginx
podman run -d --pod mon-app --name cache redis

# Lister les pods
podman pod ps

Encore plus parlant pour qui vise Kubernetes : Podman génère directement le manifeste YAML d’un pod, prêt à être appliqué sur un cluster.

# Exporter un pod au format Kubernetes
podman generate kube mon-app > mon-app.yaml

C’est un pont naturel entre le développement local et un déploiement Kubernetes, que Docker n’offre pas nativement.

Le démarrage automatique : systemd et Quadlet

Sans démon, comment relancer un conteneur au redémarrage du serveur ? Podman s’appuie sur systemd, le système d’init standard de Linux. L’approche moderne, Quadlet, décrit un conteneur dans un simple fichier .container :

# ~/.config/containers/systemd/web.container
[Container]
Image=nginx
PublishPort=8080:80

[Install]
WantedBy=default.target

# Recharger et démarrer le service généré
systemctl --user daemon-reload
systemctl --user start web

Le conteneur devient un service supervisé, avec redémarrage automatique et journalisation — souvent plus propre que la politique restart de Docker. Si vous débutez avec les conteneurs, notre guide Docker pour débutants pose d’abord les bases communes aux deux outils.

Migrer de Docker vers Podman

La transition est généralement indolore. Voici les points à vérifier :

# 1. Vos images existantes fonctionnent telles quelles
podman pull mon-registre/mon-image:latest

# 2. Les volumes se déclarent de la même façon
podman run -v mes-donnees:/data alpine

# 3. Vérifier les réseaux (Podman utilise Netavark)
podman network ls

Trois pièges classiques. D’abord, en rootless, les ports inférieurs à 1024 sont interdits par défaut : exposez sur 8080 plutôt que 80, ou ajustez net.ipv4.ip_unprivileged_port_start. Ensuite, les chemins de volumes montés depuis l’hôte doivent appartenir à votre utilisateur. Enfin, tout ce qui suppose l’existence d’un démon (montage du socket /var/run/docker.sock) demande d’activer le socket Podman.

Alors, lequel choisir ?

Choisissez Docker si vous travaillez en équipe sur des postes hétérogènes (Windows, macOS), si votre écosystème d’outils est déjà rodé autour de Docker Desktop, ou si vous voulez la solution la plus documentée avec le plus grand nombre de tutoriels et de réponses en ligne. Docker Desktop reste l’expérience la plus fluide sur les machines de développement non-Linux.

Choisissez Podman si vous déployez sur des serveurs Linux, si la sécurité rootless par défaut est un critère, si vous visez Kubernetes et voulez tester des pods en local, ou si vous préférez éviter un démon privilégié tournant en permanence. C’est le choix naturel dans l’univers Red Hat, Fedora et sur les serveurs de production sensibles.

Dans les faits, les deux ne s’excluent pas : beaucoup développent sous Docker Desktop et déploient sous Podman, la compatibilité des images et de la CLI rendant l’aller-retour transparent. Le vrai message est rassurant : quel que soit votre choix, vos compétences se transfèrent presque intégralement de l’un à l’autre.