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

• 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

Les 6 moteurs comparés

Docker, Podman, containerd, CRI-O, LXC et Incus — leurs forces et faiblesses.

Recommandation par cas

Développement local, production, Kubernetes, sécurité — quel moteur pour quel usage.

Critères de décision

Architecture, sécurité, écosystème, courbe d’apprentissage.

Outils complémentaires

Portainer, LazyDocker, Podman Desktop — les interfaces graphiques.

Recommandation rapide

Vous êtes pressé ? Voici le résumé en un tableau :

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 + Colima	100% open source

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.

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.

Moteur vs runtime vs conteneur système

Cette page compare des outils de natures différentes. Voici le vocabulaire précis :

Terme	Exemples	Rôle
Engine (moteur)	Docker, Podman	Build + run + UX complète
Runtime	containerd, CRI-O	Exécution uniquement, orienté CRI/Kubernetes
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é est garantie.

L’analogie du transport maritime

Le nom « conteneur » vient directement du transport maritime. 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

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

Tous les moteurs de conteneurs reposent sur les mêmes primitives du noyau Linux :

• 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

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 (risque sécurité)
• Docker Desktop payant pour les entreprises > 250 employés
• 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é

Podman (POD Manager) est l’alternative de Red Hat, conçue pour répondre aux critiques de sécurité de Docker.

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
• Support natif des pods (concept Kubernetes)
• 100% open source, pas de licence commerciale

Points faibles :

• Écosystème moins mature que Docker
• Quelques incompatibilités mineures avec Docker Compose
• 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 ?

containerd est le moteur de conteneurs utilisé en interne par Docker et adopté nativement par 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.

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 build d’images intégré (utiliser 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

CRI-O est un runtime minimaliste conçu exclusivement pour Kubernetes. Contrairement à containerd (qui peut être utilisé seul), CRI-O n’a de sens qu’avec 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

LXC (Linux Containers) est la technologie de conteneurisation originelle de Linux, antérieure à Docker. Elle crée des conteneurs système : des environnements qui ressemblent à des VM légères.

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 un fork de LXD (créé par Canonical), maintenu par Stéphane Graber. Il ajoute une couche de gestion avancée au-dessus de LXC.

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	✅ Natif	✅ podman-compose	⚠️ Via nerdctl	❌ 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 n’est pas pour tout le monde. Voici les interfaces graphiques pour gérer vos conteneurs :

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

Utilisez ce guide pour choisir :

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
3. Utilisez podman-compose pour vos stacks

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.

Pièges fréquents à éviter

Erreurs courantes

1. Confondre engine et runtime : Docker/Podman sont des moteurs complets (build + run + UX) ; containerd/CRI-O sont des runtimes d’exécution uniquement.

2. Croire que Docker est le runtime Kubernetes : depuis K8s 1.24, dockershim est supprimé. Kubernetes utilise containerd ou CRI-O, pas Docker directement.

3. Penser que LXC/Incus n’ont pas de mode rootless : ils supportent les conteneurs non privilégiés via user namespaces — le root dans le conteneur est mappé sur un utilisateur standard côté hôte.

4. Supposer que Podman est daemonless partout : c’est vrai sur Linux, mais sur macOS/Windows il utilise une VM (podman machine).

À retenir

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

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 ?

Containerd peut-il exécuter des images Docker ?

Pourquoi Kubernetes n'utilise plus Docker directement ?

Incus est-il rootless comme Docker ou Podman ?

Docker Desktop est-il gratuit ?

Nerdctl remplace-t-il la CLI Docker ?

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

Puis-je utiliser Docker Compose avec Podman ?

×

📖 Voir la documentation →