Docker Compose vs Docker Swarm vs Kubernetes : ce qui a vraiment du sens pour une petite équipe

Toute conversation sur le self-hosting ou le choix d'un PaaS finit par la même question : Compose, Swarm, ou Kubernetes ? La réponse honnête, c'est que les trois restent des choix légitimes en 2026, ils résolvent simplement des problèmes différents, et se tromper coûte soit du temps maintenant, soit de la douleur plus tard. Voici ce que chacun apporte réellement, en s'appuyant sur où en est chaque projet aujourd'hui plutôt qu'il y a cinq ans.

Docker Compose : le point de départ par défaut

Compose est un outil mono-machine. On décrit un ensemble de conteneurs, de réseaux et de volumes dans un fichier YAML, et docker compose up les fait tourner sur une seule machine. Pas d'ordonnanceur, pas d'état de cluster, pas de bascule automatique si cette machine tombe. Ça ressemble à une limite, et ça en est une, mais c'est aussi exactement pour ça que Compose reste pertinent : presque tout le monde qui a touché à Docker le connaît déjà, le format de fichier se lit de haut en bas sans effort, et il colle directement au modèle mental « voici mes services ».

Pour un seul VPS qui fait tourner quelques apps derrière un reverse proxy, Compose n'est pas un compromis, c'est le bon outil. Dès qu'il faut plus d'une machine (pour la redondance, pour la capacité, pour isoler des tenants les uns des autres), Compose atteint sa limite : pas de répartition de charge entre machines intégrée, pas d'orchestration si un nœud disparaît.

Docker Swarm : toujours vivant, mais qui n'avance plus à la même vitesse

La réputation de Swarm a pris un coup il y a plusieurs années quand Docker Inc. l'a visiblement mis de côté au profit de Kubernetes. Ce qui est moins connu, c'est que Mirantis, qui possède désormais l'activité Docker entreprise, s'est engagé publiquement à continuer de maintenir et développer Swarm, avec des versions de sécurité régulières sur un rythme d'environ six semaines (plus rapide pour les CVE critiques) et des clients entreprise qui le font tourner en production à une échelle non négligeable. Swarm n'est pas mort. Il a arrêté de grandir vite, et ce qui tourne aujourd'hui reste reconnaissablement le même produit qu'il y a quelques années, avec des progrès côté sécurité et solidité opérationnelle plutôt que côté nouvelles fonctionnalités.

Ça en fait un choix véritablement raisonnable dans des conditions précises : une petite équipe (disons un à cinq ingénieurs), moins d'une vingtaine de services, pas d'équipe plateforme dédiée, et le besoin d'avoir un cluster de production qui tourne en un après-midi plutôt qu'en un trimestre. Si vous connaissez déjà Docker, vous connaissez déjà la majorité de Swarm : le même format de fichier Compose s'étend en docker stack deploy, l'ordonnancement multi-machines et les mises à jour progressives arrivent quasiment gratuitement, et la courbe d'apprentissage se compte en heures. Le compromis, c'est un écosystème plus restreint : moins d'offres managées, moins d'intégrations tierces, et un rythme de nouvelles fonctionnalités plus lent que celui de Kubernetes.

Kubernetes (et K3s) : la référence du secteur, avec un vrai coût d'entrée

Kubernetes s'est imposé de facto comme la réponse standard du secteur à « comment orchestrer des conteneurs à une échelle sérieuse ». Ça vient avec de vrais avantages : l'écosystème le plus profond de tous les orchestrateurs (contrôleurs d'ingress, outillage GitOps, gestion de secrets, autoscalers, stacks d'observabilité), les compétences les plus transférables si vous ou vos recrues travaillez un jour sur l'infrastructure d'une autre entreprise, et un rythme de développement très actif.

Ça vient aussi avec un vrai poids : etcd, les composants du control plane, RBAC, les CRD, et un vocabulaire (Pods, Services, Ingresses, ReplicaSets) qui demande un vrai temps d'appropriation. Faire tourner du Kubernetes vanille soi-même, sur ses propres serveurs, représente un investissement légitime de plusieurs semaines avant de s'y sentir à l'aise.

C'est là que les distributions allégées changent la donne. K3s retire une grande partie de ce poids opérationnel : il s'installe en un seul binaire, remplace etcd par SQLite par défaut sur les petits clusters, embarque un contrôleur d'ingress, et reste totalement compatible avec l'API Kubernetes standard. Pour une petite équipe qui s'auto-héberge sur quelques VPS ou machines physiques, K3s est souvent le meilleur pari sur le long terme : la courbe d'apprentissage est réelle mais concentrée au début, et tout ce qu'on apprend (charts Helm, kubectl, le modèle d'API) se transfère directement vers n'importe quel service Kubernetes managé plus tard.

Comment choisir concrètement

Quelques repères honnêtes, dans l'ordre :

• Si vous faites tourner une app sur une machine et que la redondance n'est pas encore un besoin, utilisez Compose. Tout le reste est de la complexité prématurée.
• S'il vous faut plus d'une machine, que l'équipe est petite, et que vous voulez quelque chose qui tourne cette semaine sans embaucher un ingénieur plateforme, Swarm reste un choix défendable, surtout si votre charge de travail se décrit déjà confortablement dans un fichier Compose.
• Si vous prévoyez de dépasser une poignée de services, avez besoin d'isolation multi-tenant, voulez une réconciliation de type GitOps, ou anticipez de finir un jour sur du Kubernetes managé ailleurs, investissez dans K3s (ou Kubernetes complet) plus tôt que tard. L'outillage que vous voudrez éventuellement (cert-manager, sealed-secrets, ingress-nginx, Flux ou Argo) est construit d'abord pour Kubernetes, et souvent uniquement pour lui.
• Résistez à l'idée de partir sur Kubernetes dès le premier jour au motif qu'« on en aura peut-être besoin un jour ». Le coût opérationnel est concentré au début : payez-le quand le besoin multi-machines ou multi-tenant est réel, pas hypothétique.

En résumé

Compose pour une machine, Swarm si vous voulez un petit cluster multi-machines avec peu de cérémonie et que vous savez ne pas devoir grandir beaucoup plus loin, K3s (ou Kubernetes) si vous anticipez une vraie croissance, avez besoin de multi-tenant, ou voulez que vos compétences et vos choix d'outillage s'accumulent au lieu de finir en impasse. Aucun des trois n'est obsolète. Choisissez selon la forme du problème que vous avez réellement ce trimestre, pas celui que vous pourriez avoir dans deux ans.