Podman remplace Docker sans daemon, sans root et sans abonnement

Le 12 septembre 2024, Docker annonçait une refonte de ses abonnements. Résultat : Docker Pro passe de 5 $ à 9 $ par mois, Docker Team de 9 $ à 15 $ par utilisateur et par mois. Docker Personal reste gratuit, mais avec des limites de pulls Docker Hub entrées en vigueur le 1er mars 2025. Le 31 août 2021, Docker avait déjà réservé Docker Desktop aux entreprises de plus de 250 salariés ou de plus de 10 millions de dollars de chiffre d’affaires, sauf abonnement payant.

Podman, lui, n’a jamais coûté un centime. Le 6 mai 2026, le projet affiche 32 400 étoiles GitHub, 27 900 commits et une licence Apache 2.0. Il tourne sans daemon, sans privilèges root, et sa CLI est interchangeable avec celle de Docker.

Le daemon qui coûte cher

Docker repose sur une architecture client-serveur. Un daemon unique — dockerd — tourne en permanence avec les droits root, écoute sur un socket Unix (/var/run/docker.sock) et exécute toutes les opérations. Ce modèle a trois conséquences directes :

• Sécurité. Monter docker.sock dans un conteneur lui donne un accès équivalent root au host. Chaque conteneur capable d’écrire sur le socket peut s’échapper et compromettre la machine.
• Fiabilité. Si le daemon plante, tous les conteneurs deviennent orphelins. Pas de daemon, pas de conteneurs — même ceux qui tournaient parfaitement.
• Coût. Depuis les changements de licence de 2021 et la refonte tarifaire de 2024, Docker Desktop est payant pour toute utilisation professionnelle. Le plan le moins cher — Docker Pro — coûte 9 $/mois (facturation annuelle), soit 108 $ par an et par développeur. Une équipe de cinq paye 900 $/an pour une interface graphique de conteneurs.

Ces 9 $ par mois ne couvrent que l’accès à Docker Desktop. Le Docker Engine sous-jacent reste gratuit et open source — c’est l’interface graphique, les fonctionnalités de build cloud, le scanning de vulnérabilités et les pulls illimités sur Docker Hub que vous achetez. Mais l’alternative existe, et elle est intégralement gratuite.

Podman, l’architecture sans daemon

Podman est un moteur de conteneurs OCI développé par Red Hat et maintenu par la communauté sous l’égide de la CNCF. Sa différence architecturale avec Docker est radicale : il n’y a pas de daemon central.

Chaque conteneur Podman est un processus fils direct du processus qui l’a lancé — exactement comme un fork + exec classique. Pas de socket Unix intermédiaire, pas de processus central à maintenir en vie, pas de privilèges root requis. Le résultat :

• Rootless par défaut. Un conteneur Podman lancé par un utilisateur non privilégié tourne avec les UID/GID de cet utilisateur dans un user namespace dédié. Le processus à l’intérieur du conteneur croit être root, mais il est mappé sur un UID non privilégié sur le host. Même en cas d’échappement du conteneur, l’attaquant atterrit avec les droits d’un utilisateur normal — pas root.
• Pas de point de défaillance unique. Si un conteneur Podman crash, les autres continuent. Il n’y a pas de daemon à redémarrer.
• CLI compatible Docker. alias docker=podman suffit dans 95 % des cas. podman run, podman build, podman pull, podman ps — la syntaxe est identique. Podman supporte même docker-compose via podman-compose ou le backend Docker Compose natif depuis la version 5.0.

Voici la même stack nginx + Redis dans les deux syntaxes :

# Docker
docker run -d --name nginx -p 80:80 nginx:alpine
docker run -d --name redis -p 6379:6379 redis:alpine

# Podman — strictement identique
podman run -d --name nginx -p 80:80 nginx:alpine
podman run -d --name redis -p 6379:6379 redis:alpine

Podman Desktop, le remplaçant gratuit

L’argument le plus fréquent pour justifier Docker Desktop est son interface graphique. Podman Desktop apporte la même chose, gratuitement, avec une couverture fonctionnelle supérieure.

Podman Desktop est une application desktop (Linux, macOS, Windows) qui gère tous vos moteurs de conteneurs — pas seulement Podman. L’interface permet de :

• Lister, démarrer, arrêter et inspecter les conteneurs, images, volumes et réseaux
• Visualiser les logs en temps réel avec coloration syntaxique
• Gérer les pods Kubernetes nativement — créer, inspecter, déployer
• Accéder à un terminal dans n’importe quel conteneur en un clic
• Étendre via des extensions — registres privés, Kind, Minikube, OpenShift
• Debugger avec un accès direct aux métriques, volumes et variables d’environnement
• Accélération GPU pour les workloads IA locaux

Le projet est sous licence Apache 2.0, hébergé à la CNCF aux côtés de Kubernetes. Il ne verrouille rien derrière un paywall — pas de limites de pulls, pas de « pro features » réservées aux abonnés.

Quadlet, l’intégration systemd native

C’est l’argument qui tue pour les serveurs Linux. Docker tourne via un daemon qui démarre les conteneurs au boot — mais cette orchestration repose sur le daemon lui-même, avec des politiques de restart (--restart=always) qui ne sont pas natives à systemd.

Quadlet est un générateur systemd intégré à Podman depuis la version 4.4. Il transforme des fichiers de configuration déclaratifs en unités systemd natives, sans daemon intermédiaire.

Un exemple concret. Pour lancer nginx au démarrage de la machine avec Docker Compose :

# docker-compose.yml — dépend de dockerd
services:
  nginx:
    image: nginx:alpine
    ports:
      - "80:80"
    restart: always

Avec Podman et Quadlet, le même service devient une unité systemd native — un simple fichier texte dans /etc/containers/systemd/ :

# /etc/containers/systemd/nginx.container
[Container]
Image=nginx:alpine
PublishPort=80:80

[Install]
WantedBy=default.target

Un systemctl daemon-reload et systemctl start nginx suffisent. Le conteneur est géré par systemd comme n’importe quel service Linux — systemctl status nginx, journalctl -u nginx, systemctl enable nginx. Pas de daemon Docker à superviser, pas de YAML YAML à maintenir, pas de plugin Compose à installer.

Quadlet supporte les fichiers .container, .volume, .network, .pod, .kube, .build et .image. Il gère les dépendances entre services, les ressources cgroups, les variables d’environnement, les secrets et les mises à jour automatiques (podman auto-update). C’est la solution la plus propre pour faire tourner des conteneurs en production sur un serveur Linux standard — sans Kubernetes, sans swarm, sans orchestration lourde.

Pods Kubernetes natifs

Docker ne connaît pas la notion de pod. Un pod Kubernetes est un groupe de conteneurs qui partagent le même espace réseau, les mêmes volumes et le même cycle de vie. Podman, lui, implémente les pods nativement — sans Kubernetes installé.

# Créer un pod avec partage réseau
podman pod create --name webapp -p 8080:80

# Ajouter des conteneurs au pod
podman run -d --pod webapp --name nginx nginx:alpine
podman run -d --pod webapp --name redis redis:alpine

# Exporter le pod en YAML Kubernetes
podman generate kube webapp > webapp-pod.yaml

# Le redéployer ailleurs ou plus tard
podman play kube webapp-pod.yaml

Cette boucle pod → kube → pod est une passerelle directe entre le développement local et un cluster Kubernetes de production. Vous développez avec des pods locaux, vous exportez le manifeste, vous le déployez sur votre cluster sans retoucher une ligne.

La migration en pratique

Migrer de Docker à Podman se fait en trois commandes :

# Installer Podman (Ubuntu/Debian)
sudo apt install podman

# Alias pour garder les habitudes musculaires
alias docker=podman

# Compatibilité Docker Compose
sudo apt install podman-compose
# ou utiliser le backend natif : podman compose (Podman 5.0+)

Les images construites avec docker build sont compatibles OCI — elles tournent sur Podman sans modification. Les registries (Docker Hub, GHCR, Quay, registres privés) sont accessibles en podman pull comme en docker pull. Les volumes nommés, les réseaux bridge et les variables d’environnement fonctionnent à l’identique.

Ce qui ne passe pas directement :

• docker-compose avec depends_on conditionnel. Podman-compose le supporte partiellement — privilégiez Quadlet pour du multi-conteneur en production.
• BuildKit. Podman utilise Buildah en backend, qui couvre la quasi-totalité des syntaxes Dockerfile mais pas les features BuildKit propriétaires (cache mount avancé, --mount=type=ssh).
• Swarm. Podman ne remplace pas Docker Swarm. Pour de l’orchestration, utilisez Kubernetes, Nomad ou Quadlet sur plusieurs machines avec supervision externe.
• Docker Desktop sur macOS/Windows. Podman Desktop couvre le même besoin, avec une VM Linux intégrée. La migration est transparente pour l’utilisateur final.

Tableau comparatif

Verdict

Prenez Podman si vous administrez des serveurs Linux, si la sécurité et l’isolation vous importent, si vous voulez une intégration systemd propre via Quadlet, ou si vous préparez une migration vers Kubernetes — les pods Podman sont le chemin le plus court entre votre machine et votre cluster.

Gardez Docker si votre équipe fonctionne déjà avec Docker Desktop et que le coût de 9 $/mois par développeur est inférieur au coût d’opportunité d’une migration, si vous dépendez de BuildKit pour des Dockerfiles avancés, ou si votre stack repose sur Docker Swarm — Podman n’a pas d’équivalent direct.

La bascule est pourtant plus simple qu’elle n’en a l’air. alias docker=podman couvre déjà l’essentiel de votre quotidien. Le seul vrai coût de migration est l’apprentissage de Quadlet pour remplacer restart: always et docker-compose en production — mais cet apprentissage vous donne en échange des conteneurs sans daemon, sans root et sans abonnement. Pour un homelab ou une PME, le calcul est vite fait : 0 $ contre 9 $ par mois et par développeur, avec une sécurité meilleure et une architecture plus simple.

Références

• Podman — Site officiel — consulté le 6 mai 2026
• Podman GitHub Repository — 32,4k étoiles, 27 900 commits, Apache 2.0
• Podman Desktop — interface graphique CNCF, cross-platform, gratuite
• Podman Documentation — Quadlet — générateur systemd natif
• Docker Pricing — Pro 9 $/mois, Team 15 $/mois, Business 24 $/mois (tarifs annuels)
• Docker — Annonce des nouveaux abonnements — 12 septembre 2024
• Red Hat — What is Podman? — consulté le 6 mai 2026
• Docker — Licensing FAQ — consulté le 6 mai 2026