Moteurs de conteneurs : guide complet pour choisir Docker, Podman ou LXC

Vous devez choisir un moteur de conteneurs mais vous êtes perdu entre Docker, Podman, containerd et LXC ? Cette page vous guide vers le bon choix en 5 minutes. Docker reste le standard pour débuter, Podman pour la sécurité rootless, containerd pour Kubernetes, et LXC/Incus pour les conteneurs système.

Que vous soyez développeur, administrateur système ou architecte, ce guide comparatif vous aide à identifier le moteur adapté à votre contexte et vous oriente vers les ressources détaillées.

En 30 secondes

Si vous n’avez que quelques secondes, retenez simplement ceci : chaque moteur répond à un besoin spécifique. Voici le résumé ultra-rapide pour vous orienter immédiatement :

• Docker : meilleur choix par défaut (dev, docs, Compose)
• Podman : rootless/daemonless sur Linux + compatibilité Docker
• containerd : runtime CRI-compatible (Kubernetes)
• CRI-O : minimal « K8s only »
• LXC/Incus : conteneurs système (OS complet), unprivileged/userns

Ce que vous allez apprendre

Cette page est conçue comme un hub de navigation : elle vous donne les clés pour choisir, puis vous oriente vers les guides détaillés. Vous allez découvrir :

• Les 6 moteurs comparés : Docker, Podman, containerd, CRI-O, LXC et Incus — leurs forces et faiblesses, avec les cas d’usage où chacun excelle
• Recommandation par cas : Développement local, production, Kubernetes, sécurité — quel moteur pour quel usage, avec des critères concrets pour trancher
• Critères de décision : Architecture, sécurité, écosystème, courbe d’apprentissage — les questions à se poser avant de choisir
• Outils complémentaires : Portainer, LazyDocker, Podman Desktop — les interfaces graphiques pour piloter vos conteneurs sans ligne de commande

Recommandation rapide

Vous êtes pressé et voulez une réponse immédiate ? Ce tableau vous oriente directement vers le moteur le plus adapté à votre situation. Chaque ligne correspond à un cas d’usage courant — identifiez le vôtre et vous saurez immédiatement par où commencer.

Votre situation	Moteur recommandé	Pourquoi
Débutant / Apprentissage	Docker	Documentation abondante, écosystème mature
Développement local	Docker ou Podman	Docker Compose, intégration IDE
Sécurité prioritaire (rootless)	Podman	Sans daemon, rootless par défaut
Kubernetes en production	containerd	Runtime natif K8s, léger
Kubernetes minimaliste	CRI-O	Conçu uniquement pour K8s
Conteneurs système (VM légères)	LXC / Incus	OS complet dans un conteneur
Éviter la licence Docker Desktop	Podman	100% open source (Docker Desktop payant >250 employés ou >10M$)

Glissez pour voir

Le choix par défaut

Si vous débutez ou n’avez pas de contrainte particulière, commencez par Docker. C’est le standard de facto, avec la meilleure documentation et le plus grand écosystème. Vous pourrez migrer vers Podman ou containerd plus tard si nécessaire — les images et commandes sont compatibles.

Ce que vous installez réellement

Une source fréquente de confusion : Docker sur Linux ≠ Docker sur macOS/Windows. Cette distinction est cruciale pour comprendre les performances, les contraintes de licence et l’architecture réelle de votre environnement. Voici ce qui s’installe concrètement selon votre système d’exploitation :

Docker

Sur Linux : vous installez Docker Engine (daemon + CLI), c’est tout.

Sur macOS/Windows : vous installez Docker Desktop = application + VM + intégrations IDE + Kubernetes optionnel.

⚠️ Docker Desktop est payant au-delà du free tier (<250 employés ET <10M$ revenus). Docker Engine Linux reste 100% open source.

Podman

Sur Linux : installation native, daemonless par défaut.

Sur macOS/Windows : nécessite une VM via podman machine (similaire à Docker Desktop, mais gratuit).

containerd/CRI-O

Runtimes système : installés sur les nodes Kubernetes, rarement utilisés directement en développement local.

Pour une CLI conviviale avec containerd, installez nerdctl.

LXC/Incus

Linux uniquement : conteneurs système, pas de support Windows/macOS.

Qu’est-ce qu’un moteur de conteneurs ?

Un moteur de conteneurs (ou container engine) est le logiciel qui permet de créer, exécuter et gérer des conteneurs. C’est la fondation sur laquelle repose toute votre infrastructure conteneurisée.

Mais attention : le terme “moteur” est souvent utilisé de manière imprécise. Docker, containerd, LXC… ces outils ne font pas tous la même chose, même s’ils tournent tous autour des conteneurs. Clarifier le vocabulaire dès maintenant vous évitera des confusions plus tard.

Moteur vs runtime vs build tools vs conteneur système

Cette page compare des outils de natures différentes — c’est volontaire, car c’est ce que les équipes comparent réellement sur le terrain. Voici le vocabulaire précis pour éviter les amalgames :

Terme	Exemples	Rôle
Engine (moteur)	Docker, Podman	Build + run + UX complète
Runtime	containerd, CRI-O	Exécution uniquement, orienté CRI/Kubernetes
Build tools	BuildKit, Buildah, Kaniko	Construction d’images (voir guide build)
System containers	LXC, Incus	OS complet dans un conteneur (logique « VM légère »)

Glissez pour voir

Compatibilité OCI

Tous ces outils convergent vers le standard OCI (Open Container Initiative) : une image Docker fonctionne avec Podman, containerd, CRI-O. La portabilité des images est garantie.

Nuance importante : image portable ≠ stack runtime identique. Les drivers réseau (CNI vs Docker), volumes, security contexts (SELinux, AppArmor) peuvent différer entre moteurs.

L’analogie du transport maritime

Pour bien comprendre l’intérêt des conteneurs logiciels, il faut revenir à leur origine conceptuelle. Le nom « conteneur » n’est pas une métaphore vague — il vient directement du transport maritime, et cette analogie éclaire parfaitement leur valeur. Avant l’invention du conteneur standardisé dans les années 1950, charger un navire prenait des jours : chaque colis avait une forme différente, nécessitait une manutention spécifique.

Le conteneur maritime a tout changé : une boîte standardisée qui se charge de la même façon à Shanghai, Rotterdam ou Los Angeles. Peu importe ce qu’il y a dedans — le transport est identique.

Les conteneurs logiciels fonctionnent pareil : ils standardisent le déploiement d’applications. Peu importe le langage, les dépendances ou la configuration — si ça tourne dans un conteneur, ça tourne partout où le moteur est installé.

Ce que fait un moteur de conteneurs

Maintenant que vous comprenez le concept, voyons concrètement ce qu’un moteur de conteneurs fait au quotidien. Voici les 5 fonctions essentielles que tous les moteurs assurent, avec plus ou moins de sophistication selon l’outil :

Fonction	Description
Créer des images	Construire des packages contenant application + dépendances
Exécuter des conteneurs	Lancer des instances isolées à partir des images
Gérer l’isolation	Séparer CPU, mémoire, réseau, filesystem entre conteneurs
Orchestrer le réseau	Permettre aux conteneurs de communiquer entre eux
Persister les données	Gérer les volumes pour conserver les données

Glissez pour voir

Technologies Linux sous-jacentes

Voici un point crucial : tous les moteurs de conteneurs utilisent les mêmes fondations Linux. Que vous choisissiez Docker, Podman, containerd ou LXC, vous exploitez les mêmes briques bas niveau du noyau. Ce qui change, c’est la manière dont ces briques sont orchestrées et présentées à l’utilisateur.

Les trois primitives essentielles :

• Namespaces : isolent ce que le conteneur voit (processus, réseau, utilisateurs, filesystem)
• Cgroups : limitent ce que le conteneur utilise (CPU, mémoire, I/O)
• Union filesystems : permettent le système de couches (layers) des images

La différence entre les moteurs réside dans l’architecture, l’interface utilisateur et les fonctionnalités supplémentaires.

Les 6 moteurs de conteneurs en détail

Maintenant que vous avez le contexte général, plongeons dans le détail de chaque moteur. Pour chacun, vous trouverez : ce qu’il fait bien, ses limites, et quand le choisir. Cette section vous donne les informations concrètes pour décider en connaissance de cause.

Docker — Le standard de facto

Docker a démocratisé les conteneurs en 2013. Aujourd’hui encore, c’est le moteur le plus utilisé, avec l’écosystème le plus riche.

Points forts :

• Documentation exhaustive et communauté massive
• Docker Hub : des millions d’images prêtes à l’emploi
• Docker Compose pour les applications multi-conteneurs
• Intégration native dans tous les IDE et outils CI/CD

Points faibles :

• Daemon root par défaut (mode rootless possible mais pas le chemin standard)
• Appartenance au groupe docker = privilèges root-like (risque sécurité)
• Docker Desktop payant au-delà du free tier (<250 employés ET <10M$ revenus)
• Plus lourd que les alternatives minimalistes

Quand choisir Docker :

• Apprentissage des conteneurs
• Développement local
• Équipes qui ont besoin de documentation abondante

Guide complet Docker 8 guides pour maîtriser Docker : concepts, installation, CLI, volumes, réseaux, secrets, sécurité

Podman — Sécurité et compatibilité

Si Docker est le standard, Podman est l’alternative qui monte. Créé par Red Hat, Podman corrige les principaux reproches adressés à Docker : architecture daemon root, surface d’attaque, contrôle fin. Et le meilleur ? Il parle exactement la même langue que Docker — vous pouvez souvent remplacer docker par podman dans vos commandes.

Points forts :

• Rootless par défaut : pas besoin de privilèges root (sur Linux)
• Sans daemon sur Linux : chaque commande est un processus isolé (sur macOS/Windows, Podman utilise une VM via podman machine)
• Compatible Docker : mêmes commandes, mêmes images, migration facile
• Build intégré : podman build s’appuie sur Buildah
• Support natif des pods (concept Kubernetes)
• 100% open source, pas de licence commerciale

Points faibles :

• Écosystème moins mature que Docker
• Compose : podman compose délègue à un provider externe (docker-compose, podman-compose), compatibilité partielle selon les stacks
• Sur macOS/Windows : nécessite une VM (podman machine), pas de mode natif
• Moins de documentation pour les débutants

Quand choisir Podman :

• Sécurité prioritaire (environnements réglementés)
• Éviter la licence Docker Desktop
• Préparation à Kubernetes (concept de pods)

Guide complet Podman Installation, pods, rootless, migration depuis Docker

Quel runtime pour Kubernetes : containerd ou CRI-O ?

On change de catégorie : Docker et Podman sont des moteurs complets (build + run + UX). containerd est un runtime : il fait uniquement l’exécution, pas le build, avec une interface minimaliste. C’est le composant utilisé en interne par Docker, et c’est devenu le runtime par défaut de Kubernetes.

Kubernetes et Docker : ce qui a changé

Depuis Kubernetes 1.24 (mai 2022), le support direct de Docker via dockershim a été supprimé. Kubernetes nécessite désormais un runtime conforme à la CRI (Container Runtime Interface) : containerd ou CRI-O.

Clarification importante : Kubernetes n’a pas “arrêté Docker” — il a retiré le composant dockershim. Docker reste utilisable localement, et les images OCI restent 100% compatibles avec tous les runtimes.

Points forts :

• Léger et performant : fait uniquement l’exécution
• Runtime officiel Kubernetes depuis la suppression de dockershim
• Interface CRI native (Container Runtime Interface)
• Maintenu par la CNCF

Points faibles :

• Pas d’interface utilisateur conviviale (CLI ctr basique)
• Pas de workflow de build clé en main comme Docker/Podman (utiliser nerdctl, BuildKit ou Buildah)
• Destiné aux administrateurs expérimentés

Quand choisir containerd :

• Clusters Kubernetes en production
• Besoin d’un runtime minimal
• Infrastructure cloud-native

nerdctl : la CLI Docker pour containerd

Si vous utilisez containerd et regrettez la CLI Docker, essayez nerdctl. C’est une CLI 100% compatible Docker qui pilote containerd directement — vous pouvez même utiliser docker-compose.yml !

Guide containerd Installation, configuration, intégration Kubernetes

CRI-O — Kubernetes only

Si containerd peut être utilisé seul (avec nerdctl par exemple), CRI-O va encore plus loin dans le minimalisme : il est conçu exclusivement pour Kubernetes, rien d’autre. Contrairement à containerd (qui peut tourner en standalone), CRI-O n’a de sens qu’intégré à un cluster K8s.

Points forts :

• Ultra-léger : fait uniquement ce que Kubernetes demande
• Moins de surface d’attaque que containerd
• Adopté par OpenShift (Red Hat)

Points faibles :

• Inutilisable hors Kubernetes
• Moins polyvalent que containerd

Quand choisir CRI-O :

• Clusters OpenShift
• Kubernetes avec exigences de sécurité strictes

LXC — Conteneurs système

On change à nouveau de monde : LXC (Linux Containers) ne crée pas des conteneurs applicatifs comme Docker/Podman, mais des conteneurs système qui ressemblent à des machines virtuelles légères. Là où Docker lance un processus (votre app), LXC lance un OS complet (init, services, shell…).

C’est la technologie de conteneurisation originelle de Linux, antérieure à Docker.

Points forts :

• Conteneurs système complets : init, services, comme une VM
• Conteneurs non privilégiés (unprivileged) via user namespaces — le root dans le conteneur est mappé sur un UID non privilégié côté hôte
• Contrôle fin des ressources (cgroups avancés)
• Idéal pour migrer des workloads VM vers conteneurs

Points faibles :

• Plus bas niveau que Docker/Podman
• Pas de Dockerfile, pas de layers
• Courbe d’apprentissage plus raide

Quand choisir LXC :

• Virtualisation légère de systèmes complets
• Migration depuis des VM
• Besoin de plusieurs services dans un même conteneur

Guide LXC Installation, création de conteneurs système

Incus — LXC avec des super-pouvoirs

Incus est à LXC ce que Podman est à Docker : une surcouche moderne qui corrige les limites et ajoute des fonctionnalités avancées. C’est un fork de LXD (créé par Canonical), maintenu par Stéphane Graber (le créateur original de LXC/LXD). Il ajoute une couche de gestion avancée au-dessus de LXC, avec une API REST complète et des capacités de clustering.

Points forts :

• Gère conteneurs ET machines virtuelles (via QEMU)
• Conteneurs non privilégiés par défaut (user namespaces / idmap)
• Clustering natif pour la haute disponibilité
• API REST complète
• Images prêtes à l’emploi (Ubuntu, Debian, Alpine…)

Points faibles :

• Écosystème plus petit que Docker
• Moins adapté aux conteneurs applicatifs

Quand choisir Incus :

• Infrastructure unifiée conteneurs + VM
• Alternative légère à Proxmox
• Conteneurs système en production

Guide Incus Installation, gestion conteneurs et VM, clustering

Tableau comparatif détaillé

Critère	Docker	Podman	containerd	CRI-O	LXC	Incus
Type de conteneurs	Applicatifs	Applicatifs	Applicatifs	Applicatifs	Système	Système + VM
Architecture	Daemon (dockerd)	Sans daemon (Linux)*	Daemon	Daemon	Bas niveau	Daemon + API
Unprivileged/Rootless	Optionnel	Par défaut (Linux)	Selon setup	Selon setup	✅ Unprivileged	✅ Par défaut
CLI conviviale	✅ Excellente	✅ Compatible Docker	⚠️ Basique (ctr)	❌ Via kubectl	⚠️ Technique	✅ Bonne
Build d’images	✅ Dockerfile	✅ Containerfile	❌ Externe (BuildKit)	❌ Non	❌ Non	❌ Non
Docker Compose	✅ docker compose	⚠️ Selon provider	✅ nerdctl compose	❌ Non	❌ Non	❌ Non
Support Kubernetes	⚠️ Via containerd	✅ Pods natifs	✅ Runtime officiel	✅ Conçu pour K8s	❌ Non	❌ Non
Documentation	✅ Abondante	✅ Bonne	⚠️ Technique	⚠️ Technique	⚠️ Limitée	⚠️ Correcte
Licence	Apache 2.0 (Desktop payant)**	Apache 2.0	Apache 2.0	Apache 2.0	LGPL	Apache 2.0
Cas d’usage principal	Développement, CI/CD	Sécurité, Red Hat	Kubernetes	Kubernetes	VM légères	Infra hybride

Glissez pour voir

* Sur macOS/Windows, Podman utilise une VM (podman machine).
** Docker Desktop est payant pour les entreprises > 250 employés ou > 10M$ de revenus.

Rootless ≠ Unprivileged system containers

Rootless (Docker/Podman) = le daemon et les conteneurs tournent sans privilèges root côté hôte.
Unprivileged (LXC/Incus) = le root dans le conteneur système est mappé sur un UID non privilégié via user namespaces. Le résultat sécurité est similaire.

Outils complémentaires : les interfaces graphiques

La ligne de commande reste l’outil de référence pour les conteneurs, mais elle n’est pas obligatoire. Si vous préférez une interface visuelle, si vous gérez des dizaines de conteneurs, ou si vous voulez embarquer des collègues moins techniques, ces outils graphiques offrent une expérience complète sans sacrifier la puissance.

Voici les 3 interfaces graphiques les plus populaires, chacune avec son positionnement :

Portainer CE Interface web complète pour Docker, Swarm et Kubernetes

LazyDocker Interface TUI dans le terminal — léger et efficace

Podman Desktop Application graphique pour Podman et Kubernetes

Outil	Type	Moteurs supportés	Idéal pour
Portainer CE	Interface web	Docker, Swarm, K8s	Équipes, gestion multi-environnements
LazyDocker	TUI (terminal)	Docker	Développeurs CLI qui veulent du visuel
Podman Desktop	Application desktop	Podman, Docker, K8s	Développeurs sur poste local
Docker Desktop	Application desktop	Docker	Windows/macOS (licence commerciale)

Glissez pour voir

Arbre de décision

Vous avez maintenant toutes les informations. Cet arbre de décision vous guide pas à pas selon votre profil et vos contraintes. Sélectionnez l’onglet qui vous correspond le mieux, et suivez les étapes recommandées pour démarrer rapidement.

Je débute

Recommandation : Docker

1. Installez Docker
2. Suivez le guide CLI Docker
3. Apprenez Docker Compose

Quand vous serez à l’aise, vous pourrez explorer Podman ou containerd.

Sécurité prioritaire

Recommandation : Podman

1. Installez Podman
2. Profitez du mode rootless par défaut (Linux)
3. Utilisez podman compose ou podman-compose pour vos stacks (compatibilité selon provider)

Bonus : les commandes sont identiques à Docker — pas de réapprentissage.

Kubernetes

Recommandation : containerd (ou CRI-O)

1. containerd pour la polyvalence
2. CRI-O si vous êtes sur OpenShift ou voulez le minimum

En développement local, gardez Docker ou Podman pour le confort.

VM légères

Recommandation : Incus (ou LXC)

1. Incus pour la gestion avancée
2. LXC pour le bas niveau

Ces outils créent des conteneurs système qui ressemblent à des VM.

Checklist avant de choisir

Avant de vous lancer, prenez 2 minutes pour vérifier ces points critiques. Ce sont les pièges classiques dans lesquels tombent même les équipes expérimentées. Cette checklist vous évite les mauvaises surprises en production, les incompréhensions avec Kubernetes, ou les problèmes de licence inutiles.

Questions à se poser

Environnement :

• ✅ Suis-je sur Linux, macOS ou Windows ? (impact : Podman nécessite VM hors Linux, Docker Desktop payant sur Mac/Win)
• ✅ Ai-je besoin de Docker Compose ? (Docker natif, Podman selon provider, containerd via nerdctl)
• ✅ Est-ce pour un cluster Kubernetes ? (préférer containerd/CRI-O comme runtime node)

Sécurité :

• ✅ Suis-je en contexte réglementé nécessitant rootless obligatoire ? (Podman par défaut, Docker rootless possible mais pas standard)
• ✅ Ai-je compris que le groupe docker = privilèges root-like ? (risque sécurité)

Distinctions importantes :

• ✅ Engine vs runtime : Docker/Podman = build + run + UX ; containerd/CRI-O = exécution uniquement
• ✅ Kubernetes 1.24+ : dockershim supprimé, K8s utilise containerd/CRI-O (pas Docker directement)
• ✅ LXC/Incus supportent les conteneurs non privilégiés via user namespaces (rootless)
• ✅ Portabilité OCI = images compatibles, pas forcément réseau/volumes/security contexts identiques

À retenir

Vous êtes arrivé au bout de ce guide. Avant de passer à la pratique, voici les 7 points essentiels à retenir — ce sont les fondamentaux qui vous permettront de prendre les bonnes décisions, maintenant et dans 6 mois quand vos besoins évolueront.

1. Docker reste le standard pour débuter et pour le développement local — écosystème incomparable.

2. Podman = Docker + sécurité : rootless par défaut (Linux), sans daemon, commandes compatibles.

3. containerd est le runtime Kubernetes : léger, performant, mais sans interface conviviale. Utilisez nerdctl pour une CLI Docker-compatible.

4. LXC/Incus = conteneurs système : quand vous avez besoin d’un OS complet dans un conteneur, avec support unprivileged.

5. Les images sont compatibles : grâce au standard OCI, une image Docker fonctionne avec Podman, containerd, CRI-O.

6. La migration est possible : commencez par Docker, migrez vers Podman ou containerd quand le besoin se présente.

7. Les interfaces graphiques existent : Portainer, LazyDocker, Podman Desktop selon vos préférences.

Prochaines étapes

Vous savez maintenant quel moteur choisir. Passez à la pratique avec ces guides détaillés. Chacun couvre l’installation, la configuration, les commandes essentielles et les bonnes pratiques pour être opérationnel rapidement.

Guide Docker complet 8 guides pour maîtriser Docker de A à Z

Podman : alternative sécurisée Rootless, sans daemon, compatible Docker

containerd pour Kubernetes Le runtime léger adopté par K8s

Incus : conteneurs et VM Gestion unifiée conteneurs système et machines virtuelles

Écrire un Dockerfile Créez vos propres images conteneurs

Docker Compose Orchestrez vos applications multi-conteneurs

FAQ — Questions fréquentes

Podman est-il compatible avec Docker ?

Oui, Podman est conçu pour être compatible avec Docker. La CLI accepte les mêmes commandes (podman run = docker run), les Dockerfiles fonctionnent (appelés Containerfile), et les images Docker Hub s'exécutent sans modification. Un alias docker=podman permet une migration transparente.

Containerd peut-il exécuter des images Docker ?

Oui, containerd exécute les images Docker sans problème car les deux respectent le standard OCI (Open Container Initiative). Une image construite avec Docker fonctionne avec containerd, Podman, CRI-O ou tout runtime compatible OCI.

Pourquoi Kubernetes n'utilise plus Docker directement ?

Depuis Kubernetes 1.24 (mai 2022), le support de Docker via dockershim a été supprimé. Kubernetes nécessite un runtime conforme à la CRI (Container Runtime Interface). Docker n'implémente pas CRI nativement, contrairement à containerd et CRI-O qui sont les runtimes recommandés.

Incus est-il rootless comme Docker ou Podman ?

Incus utilise des conteneurs non privilégiés (unprivileged) par défaut via user namespaces. Le root dans le conteneur est mappé sur un UID non privilégié côté hôte (ex: 100000). C'est différent du rootless Docker/Podman mais offre une sécurité similaire.

Docker Desktop est-il gratuit ?

Docker Desktop est gratuit pour l'usage personnel, l'éducation, les projets open source et les petites entreprises (moins de 250 employés ET moins de 10M$ de revenus annuels). Les entreprises dépassant ces seuils doivent souscrire un abonnement Pro, Team ou Business.

Nerdctl remplace-t-il la CLI Docker ?

Nerdctl est une CLI compatible Docker pour containerd. Elle n'est pas un remplacement de Docker mais permet d'utiliser containerd avec une syntaxe familière. Nerdctl supporte les commandes docker run, build, compose et même les fonctionnalités avancées comme les builds multi-plateformes.

Quelle est la différence entre un conteneur applicatif et un conteneur système ?

Un conteneur applicatif (Docker, Podman) exécute un processus unique (votre application). Un conteneur système (LXC, Incus) exécute un OS complet avec init, services et gestion utilisateurs — comme une VM légère. Les conteneurs applicatifs sont pour les microservices, les conteneurs système pour migrer des VM.

Puis-je utiliser Docker Compose avec Podman ?

Oui, vous pouvez utiliser docker-compose.yml avec Podman via podman-compose ou en activant le socket compatible Docker (podman system service). Les fonctionnalités de base fonctionnent, mais certaines options avancées peuvent différer légèrement.

×

📖 Voir la documentation →