Orchestration de Conteneurs en 2026 : Quand Choisir Kubernetes vs Docker Compose

1. Le coût opérationnel réel du plan de contrôle Kubernetes

Kubernetes n’est pas coûteux à cause des conteneurs qu’il exécute, mais à cause de tout ce qui les entoure : l’API server, etcd, le scheduler, le controller manager, le kubelet sur chaque nœud, et une couche réseau (CNI) qui doit réconcilier en permanence les IP de pods, les services et les politiques réseau sur l’ensemble du cluster. Même une offre managée comme EKS, GKE ou AKS ne retire que la charge opérationnelle du plan de contrôle, pas sa charge conceptuelle. Il faut toujours comprendre les boucles de réconciliation, les admission controllers et la cohérence éventuelle pour déboguer un déploiement bloqué à 3/5 réplicas prêts.

Pour une équipe de deux à cinq ingénieurs, cette surcharge se traduit par du temps passé à lire du YAML plutôt qu’à livrer des fonctionnalités. Un cluster de production minimal nécessite un ingress controller, cert-manager pour le TLS, un pipeline de métriques, des politiques RBAC, des network policies, et généralement un gestionnaire de secrets comme External Secrets Operator ou Sealed Secrets. Chacun de ces composants est lui-même un petit système distribué avec ses propres modes de défaillance, son propre cycle de mise à jour et ses propres CRD à apprendre. Rien de tout cela n’est optionnel si vous voulez un cluster réellement sûr en production, et non une démo qui fonctionne jusqu’au premier redémarrage de nœud.

Le coût financier accentue ce constat. Les plans de contrôle managés facturent par cluster (EKS coûte environ 0,10 $/heure, ce qui est négligeable), mais le vrai coût réside dans le compute : il faut généralement au moins trois nœuds workers pour une haute disponibilité réelle, plus de la marge pour les mises à jour progressives, plus un pool de nœuds séparé pour les charges système. Un cluster qui fait tourner confortablement cinq services via Docker Compose sur un seul VPS à 40 $/mois peut facilement nécessiter 300 à 600 $/mois sous Kubernetes pour une redondance équivalente, sans même compter les heures d’ingénierie passées à l’opérer.

2. La simplicité déclarative de Docker Compose

Docker Compose offre 80 % de ce dont les petites équipes ont réellement besoin en orchestration — définitions déclaratives de services, ordre de dépendances, politiques de redémarrage, health checks et réseau partagé — sans la surface opérationnelle d’un scheduler réparti sur plusieurs machines. Un fichier `docker-compose.yml` se lit de bout en bout par un nouvel ingénieur en moins de dix minutes ; un chart Helm Kubernetes avec des overlays de valeurs pour trois environnements, généralement pas.

Le compromis est honnête : Compose tourne sur une seule machine (ou, avec son mode swarm, un petit ensemble fixe de machines) et n’offre aucune auto-réparation native en cas de panne matérielle, aucun autoscaling horizontal, aucun service mesh natif. Si la machine hébergeant votre conteneur Postgres redémarre, rien ne le replanifie sur une autre machine — parce qu’il n’y en a pas d’autre. Pour les équipes qui font tourner une architecture monolithe-plus-quelques-services sur une ou deux VPS costaudes, ce n’est presque jamais le vrai goulet d’étranglement ; des volumes persistants et `restart: unless-stopped` couvrent les modes de défaillance qui se produisent réellement en pratique (crash de processus, OOM kill, rollback de déploiement).

Compose s’intègre aussi bien avec le reste d’une stack d’ops légère : Watchtower ou un simple job CI pour les mises à jour d’images, Caddy ou Traefik pour la terminaison TLS automatique, et un script de sauvegarde cron pour le volume de base de données. C’est la stack que font effectivement tourner la plupart des SaaS bootstrappés en 2026, et c’est un choix défendable, pas un raccourci dont il faut s’excuser.

3. Le seuil de bascule vers le cluster

La décision d’adopter Kubernetes doit reposer sur des signaux opérationnels concrets, pas sur la construction de CV ou sur ce que l’industrie considère comme le choix « sérieux ». Le signal le plus net est la nécessité multi-nœuds : quand les besoins en ressources d’un service dépassent ce qu’une seule machine peut offrir, ou quand vous avez besoin de répartir les charges sur plusieurs zones de disponibilité pour une réelle tolérance aux pannes, il faut un scheduler qui couvre plusieurs machines. Le mode swarm de Compose le permet techniquement aussi, mais son écosystème a stagné face à Kubernetes, et vous vous battrez constamment contre ce manque d’outillage.

Le deuxième signal concerne la topologie des équipes. Dès que plusieurs équipes déploient indépendamment sur une infrastructure partagée, l’isolation par namespace, le RBAC et les quotas de ressources de Kubernetes résolvent de vrais problèmes de coordination auxquels Compose n’a aucune réponse. Une équipe plateforme qui maintient l’infrastructure de cluster partagée pendant que les équipes produit se déploient en self-service via des charts Helm ou du GitOps (Argo CD, Flux) est un pattern qui passe à l’échelle bien au-delà de ce qu’un seul fichier Compose peut exprimer.

Le troisième signal est l’autoscaling sous charge variable. Si votre trafic double ou décuple réellement pendant les heures ouvrées et que vous avez besoin que les pods passent automatiquement de 3 à 30 réplicas selon le CPU ou des métriques personnalisées, le HPA (Horizontal Pod Autoscaler) de Kubernetes est conçu précisément pour cela. Compose n’a aucun équivalent ; il faudrait écrire votre propre logique de scaling contre l’API du Docker Engine, ce qui représente plus de travail que d’adopter proprement Kubernetes.

Méfiez-vous aussi du signal inverse : les équipes qui adoptent Kubernetes parce que « c’est ce qu’utilisent les entreprises de notre taille cible », sans qu’aucune de ces trois pressions ne soit réelle. C’est la raison la plus courante pour laquelle des petites équipes se retrouvent avec un cluster que personne ne comprend vraiment, faisant tourner trois services qui tiendraient confortablement dans Compose, avec une rotation d’astreinte dédiée à maintenir etcd en bonne santé.

4. Une voie intermédiaire : Nomad et Kubernetes allégé

Entre Compose et Kubernetes complet existe un palier intermédiaire qui mérite d’être connu. HashiCorp Nomad offre une planification multi-nœuds, des déploiements progressifs et de la découverte de services avec une fraction de la surface conceptuelle de Kubernetes — un binaire unique, un format de job simplifié, et aucune couche d’abstraction réseau séparée à apprendre, sauf si vous optez pour Consul Connect. Les équipes qui ont besoin d’une réelle orchestration multi-nœuds mais pas de tout l’écosystème Kubernetes (opérateurs, CRD, admission webhooks) trouvent souvent Nomad plus adapté que les deux extrêmes.

Côté Kubernetes, des distributions comme k3s réduisent le plan de contrôle à un unique binaire léger, adapté à 2 ou 3 petites instances VPS, ce qui abaisse sensiblement le coût d’entrée tout en gardant une compatibilité API complète avec l’écosystème Kubernetes standard (les charts Helm, kubectl, ingress-nginx fonctionnent sans modification). C’est une bonne rampe d’accès pour une équipe qui veut de l’outillage natif Kubernetes sans payer, dès le premier jour, la surcharge de compute d’un cluster EKS.

5. Synthèse pragmatique

Par défaut, choisissez Docker Compose (éventuellement complété d’un script de déploiement simple) jusqu’à pouvoir nommer une exigence opérationnelle précise que Compose ne peut pas satisfaire : planification multi-nœuds pour la tolérance aux pannes, autoscaling piloté par la charge, ou isolation multi-équipes par namespace. Nommer précisément le besoin compte, car cela indique exactement quelle fonctionnalité de Kubernetes vous est réellement nécessaire, ce qui permet ensuite de savoir si une alternative plus légère comme Nomad ou k3s la résout à moindre coût qu’un cluster managé complet.

Si vous migrez, faites-le de façon incrémentale : gardez vos services à état (bases de données, files de messages) hors du cluster, sur des services managés ou des VM dédiées, aussi longtemps que possible, et ne mettez dans Kubernetes que vos services sans état, horizontalement scalables, en premier. Cela limite le rayon d’impact des erreurs d’apprentissage du plan de contrôle aux parties du système les moins coûteuses à mal gérer, et évite le classique piège consistant à faire tourner un Postgres géré par StatefulSet dans Kubernetes avant que l’équipe n’ait la maturité opérationnelle nécessaire.

La règle qui tient la route en pratique : la complexité d’orchestration doit suivre vos véritables domaines de défaillance et les frontières de vos équipes, pas vos ambitions. Une équipe de deux personnes faisant tourner Compose sur deux VPS avec de bonnes sauvegardes et du monitoring solide est plus sûre en production que la même équipe gérant un cluster Kubernetes sous-dimensionné et à moitié compris — et elle livre plus vite en attendant.