Kubernetes et ses alternatives : panorama de l'orchestration de conteneurs

Kubernetes (K8s) est devenu le standard de facto de l’orchestration de conteneurs : 82 % des utilisateurs de conteneurs le font tourner en production selon l’enquête annuelle 2025 de la CNCF (Cloud Native Computing Foundation). Source : CNCF Annual Survey 2025

Pourtant, une part significative des équipes qui l’adoptent n’en avaient pas besoin — et une part significative de celles qui l’évitent le font pour de mauvaises raisons. Cet article pose d’abord les bases : pourquoi K8s existe, ce qu’il fait, comment, et le vocabulaire qui va avec. Puis il passe en revue les alternatives réelles, leurs compromis, les profils d’équipe et d’infrastructure auxquels chacune correspond, et leur maturité en 2026.

Cet article complète les précédents sur l’écosystème conteneurs du blog : build et déploiement d’images Docker avec GitHub Actions, images distroless et gestion des logs Docker. Ici, on monte d’un cran : non plus construire et faire tourner un conteneur, mais en coordonner des dizaines ou des milliers sur plusieurs machines.

1. Pourquoi Kubernetes existe : le problème de l’orchestration

Le problème

Docker (et plus largement les conteneurs OCI — Open Container Initiative) résout le problème du packaging : une application et ses dépendances dans une image immuable, exécutable partout. Mais dès qu’on dépasse le stade d’un seul serveur, une série de questions opérationnelles se pose :

Placement : sur quelle machine démarrer ce conteneur ? Celle qui a encore de la RAM ? Celle qui est dans la bonne zone de disponibilité ?
Résilience : que se passe-t-il quand un conteneur crashe ? Quand une machine entière tombe ?
Scaling : comment passer de 3 à 30 instances quand le trafic monte, et redescendre ensuite ?
Réseau : comment le service A trouve-t-il le service B, dont les instances changent d’adresse IP à chaque redémarrage ?
Déploiement : comment mettre à jour 50 instances sans coupure de service, et revenir en arrière si la nouvelle version est cassée ?
Secrets et configuration : comment distribuer credentials et configuration sans les mettre dans l’image ?

Un orchestrateur de conteneurs est le logiciel qui répond à ces questions. Kubernetes est né chez Google en 2014, héritier direct de Borg, le système interne qui orchestrait déjà les workloads de Google depuis le début des années 2000. Google en a fait don à la CNCF en 2015 ; c’est le premier projet « graduated » de la fondation (2018). Source : Borg, the predecessor to Kubernetes — Kubernetes Blog

L’idée centrale : le modèle déclaratif et la réconciliation

Le cœur conceptuel de Kubernetes n’est pas « lancer des conteneurs », c’est la boucle de réconciliation (reconciliation loop) sur un état déclaré :

Vous déclarez un état désiré dans l’API (« je veux 3 réplicas de cette image, avec 512 Mo de RAM chacun, exposés sur le port 8080 »).
Des contrôleurs observent en permanence l’écart entre l’état désiré et l’état réel du cluster.
Quand un écart apparaît (un conteneur crashe, une machine tombe, vous changez la déclaration), le contrôleur agit pour le résorber.

C’est ce qui distingue fondamentalement K8s d’un script de déploiement impératif : on ne dit pas quoi faire, on dit ce qui doit être vrai, et le système converge en continu. C’est aussi ce qui rend le système auto-réparant (self-healing) : le redémarrage d’un pod crashé n’est pas un mécanisme spécial, c’est la même boucle de réconciliation que pour tout le reste. Source : Kubernetes — Controllers

2. Comment Kubernetes fonctionne : l’architecture

Un cluster Kubernetes se divise en deux plans : le control plane (le cerveau) et les worker nodes (les muscles).

                        CONTROL PLANE
┌──────────────────────────────────────────────────────────┐
│  ┌────────────┐   ┌───────────────┐   ┌───────────────┐  │
│  │    etcd    │◀──│  API Server   │──▶│   Scheduler   │  │
│  │ (état du   │   │ (point d'en-  │   └───────────────┘  │
│  │  cluster)  │   │  trée unique) │   ┌───────────────┐  │
│  └────────────┘   │               │──▶│  Controller   │  │
│                   └───────▲───────┘   │   Manager     │  │
└───────────────────────────│───────────└───────────────┘──┘
                            │ (tout passe par l'API server)
        ┌───────────────────┼───────────────────┐
        ▼                   ▼                   ▼
┌───────────────┐   ┌───────────────┐   ┌───────────────┐
│  WORKER NODE  │   │  WORKER NODE  │   │  WORKER NODE  │
│ ┌───────────┐ │   │ ┌───────────┐ │   │ ┌───────────┐ │
│ │  kubelet  │ │   │ │  kubelet  │ │   │ │  kubelet  │ │
│ │kube-proxy │ │   │ │kube-proxy │ │   │ │kube-proxy │ │
│ └───────────┘ │   │ └───────────┘ │   │ └───────────┘ │
│ ┌───┐ ┌───┐   │   │ ┌───┐         │   │ ┌───┐ ┌───┐   │
│ │Pod│ │Pod│   │   │ │Pod│         │   │ │Pod│ │Pod│   │
│ └───┘ └───┘   │   │ └───┘         │   │ └───┘ └───┘   │
└───────────────┘   └───────────────┘   └───────────────┘

Le control plane

API server (kube-apiserver) : le point d’entrée unique. Toute interaction — kubectl, contrôleurs internes, outils externes — passe par lui. Aucun composant ne parle directement à un autre : le scheduler ne parle pas au kubelet, le controller manager ne parle pas à etcd. Tout transite par l’API server.
etcd : la base clé-valeur distribuée (consensus Raft) qui stocke tout l’état du cluster. Chaque objet (Pod, Deployment, Service…) est une entrée dans etcd. C’est la source de vérité unique — et le composant le plus délicat à opérer soi-même (sauvegardes, quorum, latence disque).
Scheduler (kube-scheduler) : observe les pods non encore assignés à une machine et choisit la meilleure en fonction des ressources disponibles, des contraintes d’affinité, des taints/tolerations. Il ne lance rien lui-même : il écrit sa décision dans l’API server.
Controller manager (kube-controller-manager) : exécute la collection de contrôleurs (Deployment, ReplicaSet, Node, Job…) qui font tourner les boucles de réconciliation.

Les worker nodes

kubelet : l’agent présent sur chaque machine. Il observe l’API server, détecte les pods qui lui sont assignés, et demande au container runtime (containerd, CRI-O) de tirer les images et lancer les conteneurs.
kube-proxy : gère les règles réseau locales pour que les Services (adresses virtuelles stables) routent vers les bons pods.

Source : Kubernetes — Cluster Architecture

Les ordres de grandeur

Un cluster Kubernetes est officiellement dimensionné pour supporter jusqu’à 5 000 nodes, 150 000 pods et 300 000 conteneurs au total. Source : Kubernetes — Considerations for large clusters

Le projet publie 3 versions mineures par an, chacune maintenue environ 14 mois ; en mi-2026, les branches supportées sont 1.34, 1.35 et 1.36. Source : Kubernetes — Releases

3. Le jargon Kubernetes décodé

Le vocabulaire est la première barrière d’entrée. Voici l’essentiel, organisé par thème.

Workloads (ce qui tourne)

Terme	Définition
Pod	La plus petite unité déployable : un ou plusieurs conteneurs qui partagent réseau (même IP) et stockage. En pratique, presque toujours 1 conteneur applicatif + éventuels sidecars.
ReplicaSet	Garantit qu’un nombre N de réplicas d’un pod tourne en permanence. Rarement manipulé directement.
Deployment	L’objet du quotidien : gère les ReplicaSets et orchestre les rolling updates (mise à jour progressive sans coupure) et les rollbacks.
StatefulSet	Comme un Deployment, mais pour les applications à état (bases de données) : identité réseau stable, stockage persistant par réplica, ordre de démarrage garanti.
DaemonSet	Un pod par node — typiquement agents de logs, de monitoring, ou de sécurité.
Job / CronJob	Tâches ponctuelles ou planifiées, avec gestion des reprises sur erreur.

Réseau (comment ça communique)

Terme	Définition
Service	Adresse virtuelle stable devant un groupe de pods éphémères. Trois types : `ClusterIP` (interne), `NodePort` (port ouvert sur chaque node), `LoadBalancer` (provisionne un load balancer cloud).
Ingress	Routage HTTP(S) entrant : règles de type « `api.example.com/v1` → tel Service ». Nécessite un Ingress Controller (nginx, Traefik, HAProxy…).
Gateway API	Le successeur d’Ingress, plus expressif (routage L4/L7, multi-tenancy), stable depuis 2023. Source : Gateway API
Service mesh	Couche réseau applicative (Istio, Linkerd, Cilium) : mTLS entre services, télémétrie, circuit breaking. Puissant, mais coût opérationnel et en ressources non négligeable.

Configuration et stockage

Terme	Définition
Namespace	Cloisonnement logique du cluster (par équipe, par environnement).
ConfigMap / Secret	Configuration et données sensibles injectées dans les pods (variables d’environnement ou fichiers montés). Les Secrets ne sont que encodés base64 par défaut — le chiffrement au repos dans etcd doit être activé explicitement. Source : Kubernetes — Encrypting Secret Data at Rest
PV / PVC	PersistentVolume (le volume de stockage) et PersistentVolumeClaim (la demande de stockage faite par un pod). L’abstraction qui découple l’application du fournisseur de stockage, via des drivers CSI (Container Storage Interface).

Scheduling et scaling

Terme	Définition
Taint / Toleration	Un node « teinté » repousse les pods, sauf ceux qui ont la tolérance correspondante. Sert à réserver des machines (GPU, par exemple).
Affinity / Anti-affinity	Règles d’attraction ou de répulsion entre pods et nodes (« étale mes réplicas sur des zones différentes »).
HPA	Horizontal Pod Autoscaler : ajuste le nombre de réplicas selon la charge (CPU, mémoire, métriques custom).
Cluster Autoscaler / Karpenter	Ajuste le nombre de machines du cluster selon les besoins des pods.

Écosystème

Terme	Définition
kubectl	La CLI officielle.
Helm	Le gestionnaire de paquets : un chart Helm est un template paramétrable de manifestes YAML. Source : Helm Docs
CRD	Custom Resource Definition : étendre l’API Kubernetes avec ses propres types d’objets. Le mécanisme d’extension fondamental.
Operator	Un contrôleur custom + des CRD : encode le savoir-faire opérationnel d’une application (ex. l’operator PostgreSQL sait faire un failover).
GitOps	Pattern où un dépôt Git est la source de vérité de l’état désiré, réconcilié en continu par un agent (Argo CD, Flux). Argo CD est l’outil GitOps majoritaire selon la CNCF. Source : CNCF End User Survey

4. Ce que Kubernetes coûte vraiment

Avant de comparer les alternatives, il faut être honnête sur le prix de K8s — pas en euros de facture cloud, mais en charge cognitive et opérationnelle.

Courbe d’apprentissage longue. Le modèle objet (une vingtaine de types de ressources à connaître pour être autonome), le YAML verbeux, le réseau à quatre couches (conteneur → pod → service → ingress) : compter plusieurs mois avant qu’un ingénieur soit réellement productif dessus.
Un système distribué à opérer. Un cluster auto-hébergé, c’est etcd à sauvegarder, des certificats à faire tourner, des upgrades 3 fois par an (chaque version n’étant supportée que ~14 mois), des CNI/CSI/Ingress controllers à maintenir. Le Kubernetes managé (voir §6) élimine une partie de ce fardeau, pas tout : les upgrades de version, la compatibilité des charts et des operators, le dimensionnement restent à votre charge.
L’écosystème est une force et un piège. Le paysage CNCF compte des centaines de projets (CNCF Landscape) ; l’empilement service mesh + GitOps + observabilité + policy engine peut doubler l’empreinte infrastructure d’un cluster avant même d’y déployer la première application métier.
Le défi est devenu organisationnel. Fait notable : dans l’enquête CNCF 2025, le premier obstacle cité à l’adoption cloud native n’est plus technique mais culturel (« cultural changes with the development team », 47 % des répondants). Source : CNCF Annual Survey 2025

En pratique, la question n’est donc pas « Kubernetes est-il bon ? » (il l’est), mais « mon équipe a-t-elle le problème que K8s résout, et les moyens de payer son coût opérationnel ? ». Les alternatives ci-dessous existent précisément parce que la réponse est souvent non.

5. Les familles d’alternatives

Comparer « Kubernetes vs X » sans préciser la famille de X mène à des débats stériles : Cloud Run et Nomad ne jouent pas dans la même catégorie. On peut organiser le paysage en cinq familles, selon deux axes : qui opère la plateforme (vous ou un fournisseur) et le niveau d’abstraction (de la machine au conteneur géré).

        Vous opérez ◀──────────────────────────▶ Le cloud opère

  ┌─────────────────┬──────────────────┬─────────────────────┐
  │ Orchestrateurs  │  K8s allégé /    │  K8s managé         │
  │ auto-hébergés   │  distributions   │  (EKS, GKE, AKS)    │
  │ Nomad, Swarm    │  k3s, k0s, Talos │                     │
  ├─────────────────┼──────────────────┼─────────────────────┤
  │ Outils de déploi│  PaaS            │  Conteneurs         │
  │ simples : Kamal,│  self-hosted     │  serverless : ECS/  │
  │ Compose         │  Coolify, Dokploy│  Fargate, Cloud Run,│
  │                 │                  │  ACA + PaaS cloud   │
  └─────────────────┴──────────────────┴─────────────────────┘

5.1 Les orchestrateurs auto-hébergés concurrents

HashiCorp Nomad

Nomad est le concurrent architectural le plus sérieux. Sa philosophie est inverse de celle de K8s : un seul binaire (client et serveur), un scheduler généraliste, et l’intégration avec le reste de la stack HashiCorp (Consul pour le service discovery, Vault pour les secrets) plutôt qu’un système tout-en-un. Source : What is Nomad? — HashiCorp

Ce qu’il résout que K8s ne résout pas :

Workloads non conteneurisés en natif : Nomad orchestre des conteneurs Docker, mais aussi des binaires bruts (exec), des JVM, des VM QEMU, des jobs batch. Pour un parc mixte legacy + conteneurs, c’est un atout unique.
Simplicité opérationnelle : pas d’etcd séparé (consensus Raft intégré), pas de CNI obligatoire, courbe d’apprentissage en jours plutôt qu’en mois.
Échelle extrême : le challenge C2M de 2020 a planifié 2 millions de conteneurs sur 6 100 hôtes répartis dans 10 régions AWS, en 22 minutes — au-delà des limites documentées de K8s (5 000 nodes / 300 000 conteneurs). Source : HashiCorp — The 2 Million Container Challenge

Les compromis :

Écosystème très inférieur : pas d’équivalent des milliers de charts Helm, d’operators, d’outils GitOps. Beaucoup de choses fournies par K8s (ingress, secrets, service discovery) demandent d’ajouter Consul, Vault, Traefik — on reconstruit à la carte ce que K8s intègre.
Vivier de compétences réduit : recruter un ingénieur Nomad est bien plus difficile que recruter un ingénieur K8s.
Gouvernance et licence : Nomad est passé sous licence BSL (Business Source License, source-available non libre) en 2023, et IBM a finalisé le rachat de HashiCorp en février 2025 (6,4 Md$). Les fonctionnalités entreprise (autoscaling avancé, multi-région) sont payantes. Source : Nomad CE license — HashiCorp, The Register — IBM closes HashiCorp deal

Docker Swarm

Swarm mode est l’orchestration intégrée à Docker Engine : docker swarm init, et votre daemon Docker devient un cluster. La syntaxe est celle de Docker Compose, que toute équipe Docker connaît déjà. Source : Docker Docs — Swarm mode

Ce qu’il résout : le multi-nœud minimal. Réplication de services, rolling updates avec rollback automatique, réseau overlay chiffré (mTLS automatique entre nodes), secrets distribués, mesh routing — sans installer quoi que ce soit d’autre que Docker. Une équipe passe de Compose à un cluster 3 nœuds en quelques heures.

Les compromis :

Développement quasi gelé. Swarm ne reçoit presque plus de nouvelles fonctionnalités depuis des années. Mirantis (qui a racheté Docker Enterprise en 2019) s’est engagé à le supporter jusqu’en 2030 au moins dans Mirantis Kubernetes Engine, avec quelques ajouts (support CSI), mais personne ne prétend que Swarm rattrapera K8s. Source : Mirantis — Long-Term Support for Swarm Through 2030
Pas d’autoscaling natif, RBAC limité sans outils tiers (Portainer), écosystème d’extensions minimal.
Le stockage distribué et les workloads à état restent des points faibles.

5.2 Kubernetes allégé : les distributions légères

Ce ne sont pas des alternatives à Kubernetes, mais des alternatives à la complexité d’installation et d’opération de Kubernetes — l’API reste 100 % K8s, tout l’écosystème (Helm, operators, kubectl) fonctionne.

k3s (SUSE, projet sandbox CNCF) : K8s complet dans un binaire unique de quelques dizaines de Mo, SQLite à la place d’etcd par défaut, composants superflus retirés. La voie royale pour l’edge, les homelabs, le CI, et les petits clusters de production. Source : k3s.io
k0s (Mirantis) : binaire autonome sans dépendance à l’OS hôte, position intermédiaire entre k3s et un K8s vanilla. Source : k0sproject.io
Talos Linux (Sidero Labs) : approche radicale — l’OS est Kubernetes. Système immuable, pas de SSH ni de shell, pilotage intégralement par API. Sécurité et reproductibilité maximales, au prix d’un changement complet de modèle d’administration. Source : talos.dev
Mention : OpenShift (Red Hat) à l’autre extrémité — une distribution K8s enrichie (CI/CD, registry, console, sécurité durcie) pour les grandes entreprises, avec le coût de licence correspondant. Source : Red Hat OpenShift

Le compromis commun : vous opérez toujours un cluster K8s (upgrades, sauvegardes, monitoring). La complexité d’installation baisse drastiquement, la complexité conceptuelle (le modèle objet, le YAML, le réseau) reste entière.

5.3 Kubernetes managé : EKS, GKE, AKS

L’alternative la plus répandue au K8s auto-hébergé n’est pas un autre orchestrateur : c’est le même, opéré par un cloud. Le fournisseur gère le control plane (API server, etcd, haute disponibilité) ; vous gérez les nodes (ou pas, avec les modes « autopilot »).

	EKS (AWS)	GKE (Google)	AKS (Azure)
Prix control plane	0,10 $/h (~73 $/mois)	0,10 $/h, crédit mensuel de 74,40 $ couvrant 1 cluster zonal ou Autopilot	Gratuit (tier Free) ; 0,10 $/h pour le SLA 99,95 % (Standard)
Support étendu	0,60 $/h au-delà de 14 mois sans upgrade	Canal étendu payant	Tier Premium 0,60 $/h (24 mois de support)
Mode « sans nodes »	Fargate pour EKS	Autopilot (facturation au pod)	Virtual nodes / node auto-provisioning

Sources : AWS EKS Pricing, GKE Pricing, AKS Pricing

Ce que ça résout : l’opération du control plane (la partie la plus risquée : etcd, quorum, certificats) et l’intégration cloud native (IAM, load balancers, stockage).

Les compromis : le coût du control plane est marginal ; le vrai coût reste la complexité K8s côté utilisateur (manifestes, upgrades de version à suivre — avec pénalité financière chez AWS en cas de retard —, compatibilité de l’écosystème) et la facture compute qui domine largement.

5.4 Les conteneurs serverless : ECS/Fargate, Cloud Run, Container Apps

Ici, on abandonne l’idée d’un cluster visible : on donne une image de conteneur au cloud, qui la fait tourner. C’est la famille qui a le plus progressé depuis 2020, et pour beaucoup d’équipes c’est elle — pas Nomad ni Swarm — la vraie alternative à K8s.

Amazon ECS (+ Fargate)

ECS (Elastic Container Service) est l’orchestrateur propriétaire d’AWS, antérieur à EKS. Pas de frais de control plane ; on décrit des task definitions (image, CPU, mémoire) et des services, et ECS gère placement, scaling et rolling updates. Avec Fargate, plus aucune instance EC2 à gérer : facturation à la vCPU-seconde et au Go-seconde alloués. Source : AWS ECS Docs, AWS Fargate Pricing

Résout : l’orchestration sans opérer de cluster, avec l’intégration AWS la plus profonde (IAM par tâche, VPC, ALB, CloudWatch).
Compromis : lock-in AWS total, configuration verbeuse (JSON de task definitions, rôles IAM), écosystème d’outillage bien plus petit que K8s. Pas de scale-to-zero natif pour les services web.

Google Cloud Run

Le plus proche du « je donne un conteneur, débrouille-toi » : déploiement en une commande, HTTPS automatique, scale-to-zero et facturation à la requête (ou à l’instance). Basé sur le modèle Knative. Supporte désormais jobs, sidecars et GPU. Source : Cloud Run Docs

Résout : les services HTTP stateless et event-driven avec trafic variable ou intermittent, à coût quasi nul en creux.
Compromis : modèle stateless strict (pas de stockage persistant local), contraintes sur les workloads longs ou non-HTTP, lock-in GCP (atténué par le standard Knative).

Azure Container Apps

Construit sur Kubernetes (AKS), mais le cluster est invisible. Intègre nativement KEDA (autoscaling event-driven, y compris scale-to-zero) et Dapr (patterns microservices). Position médiane : plus riche que Cloud Run, plus simple qu’AKS. Source : Azure Container Apps Docs

Les PaaS cloud : Fly.io, Railway, Render

Un cran d’abstraction au-dessus : le Platform as a Service nouvelle génération. git push ou fly deploy, et la plateforme construit, déploie, route et scale. Fly.io ajoute une spécificité : des microVM Firecracker déployées au plus près des utilisateurs dans des dizaines de régions. Source : Fly.io Docs

Résout : le time-to-production minimal pour des petites équipes produit.
Compromis : vous ne possédez pas l’infrastructure (compliance, données), coûts qui grimpent vite à l’échelle, et dépendance à la santé financière et opérationnelle d’acteurs plus petits que les hyperscalers.

5.5 Le retour au simple : Kamal, Compose et les PaaS self-hosted

La famille qui monte depuis 2023, portée par le mouvement de « désertion du cloud » : des outils qui déploient des conteneurs sur des serveurs que vous louez (VPS Hetzner, Scaleway, OVH…), sans orchestrateur du tout.

Kamal

Développé par 37signals (Basecamp) pour sortir leurs applications du cloud. Kamal déploie des conteneurs Docker via SSH sur n’importe quel serveur : un fichier config/deploy.yml unique, des déploiements sans coupure via kamal-proxy, des secrets, des accessoires (bases de données). Pas de control plane, pas d’agent : rien ne tourne sur vos serveurs à part vos conteneurs et le proxy. Source : kamal-deploy.org

Résout : le déploiement reproductible multi-serveurs pour un monolithe ou quelques services, avec une infrastructure comprise de bout en bout.
Compromis : pas de réconciliation automatique (un serveur qui tombe ne redémarre pas ses conteneurs ailleurs), pas d’autoscaling, placement manuel. La haute disponibilité redevient votre problème (load balancer devant, plusieurs serveurs).

Les PaaS self-hosted : Coolify, Dokploy, CapRover

L’expérience Heroku (interface web, git push → deploy, TLS automatique, provisioning de bases de données, previews) sur votre propre VPS. Coolify est le plus complet et le plus populaire ; Dokploy le plus léger. Source : coolify.io, dokploy.com

Résout : héberger de nombreux petits projets et services à coût fixe minime (un VPS à quelques euros), sans apprendre un orchestrateur.
Compromis : ces outils sont jeunes, portés par de petites équipes ; la haute disponibilité multi-nœuds y est récente ou limitée ; on dépend de la qualité de l’outil pour les mises à jour de sécurité de toute la chaîne.

Docker Compose, tout simplement

Pour un serveur unique, Compose + un reverse proxy (Caddy, Traefik) + des sauvegardes reste une solution parfaitement légitime en production. Ce blog en a déjà documenté plusieurs briques : stack d’observabilité, cache Caddy/Souin. Le compromis est connu : pas de multi-nœud, pas de self-healing au-delà de restart: always, scaling vertical uniquement.

6. Tableau comparatif global

	Kubernetes (managé)	Nomad	Docker Swarm	ECS/Fargate	Cloud Run / ACA	Kamal	PaaS self-hosted (Coolify…)
Problème résolu	Orchestration générale, extensibilité, standard	Orchestration simple, workloads mixtes	Multi-nœud minimal	Orchestration sans cluster (AWS)	Conteneurs à la demande	Déploiement SSH sans orchestrateur	Heroku chez soi
Courbe d’apprentissage	Mois	Jours-semaines	Heures	Jours	Heures	Heures	Heures
Self-healing	Oui, complet	Oui	Oui	Oui	Oui	Non	Partiel
Autoscaling	HPA + cluster autoscaler	Payant (Enterprise) / basique	Non	Oui	Oui, scale-to-zero	Non	Non
Workloads non-conteneurs	Non (VM via KubeVirt)	Oui (exec, JVM, QEMU)	Non	Non	Non	Non	Non
Écosystème	Immense (CNCF)	Restreint	Minimal	Moyen (AWS)	Moyen	Minimal	Minimal
Lock-in	Faible (standard)	Moyen (BSL, IBM)	Faible	Fort (AWS)	Fort (sauf Knative)	Aucun	Faible
Coût plateforme	~73 $/mois + nodes	Serveurs seuls	Serveurs seuls	Compute seul (premium Fargate)	À l’usage, ~0 en creux	Serveurs seuls	Serveurs seuls
Échelle démontrée	5 000 nodes / 300 k conteneurs	2 M conteneurs (C2M)	Milliers de conteneurs	Très grande (AWS)	Très grande (Google)	Dizaines de serveurs	Quelques serveurs
État visible	Déclaratif, réconcilié	Déclaratif, réconcilié	Déclaratif, réconcilié	Déclaratif	Déclaratif	Impératif (push)	Impératif (UI/push)

7. Quelle option pour quelle équipe, quelle infra, quelle charge ?

Les recommandations ci-dessous sont des opinions, mais justifiées par les compromis documentés plus haut.

Par profil d’équipe

Profil	Recommandation	Pourquoi
Solo dev / side projects	Compose ou Coolify/Dokploy sur un VPS	Coût fixe minime, zéro concept nouveau, tout tient dans la tête.
Startup produit, 2-10 devs, pas d’ops dédié	PaaS cloud (Fly.io, Railway) ou Cloud Run	La vélocité produit prime ; toute heure passée sur l’infra est perdue. Migrer plus tard est un bon problème à avoir.
PME, 10-30 devs, 1-2 ops, déjà sur AWS	ECS/Fargate	Orchestration complète sans opérer de cluster, IAM/VPC natifs. K8s seulement si le besoin d’écosystème est avéré.
Équipe avec parc mixte (legacy, VM, batch, conteneurs)	Nomad	Le seul à orchestrer nativement du non-conteneurisé.
Organisation multi-équipes, plateforme interne, >30 devs	Kubernetes managé (EKS/GKE/AKS)	Namespaces, RBAC, quotas, GitOps, operators : c’est le terrain où l’investissement K8s se rentabilise.
Souveraineté / on-premise / edge	k3s ou Talos (ou Swarm pour l’existant Docker)	K8s standard sans dépendance cloud ; Talos si la sécurité prime.
Sortie du cloud, monolithe maîtrisé	Kamal	Le pari 37signals : des serveurs loués + un outil simple, économies substantielles si la charge est prévisible.

Par type de charge

Trafic en pics ou imprévisible → Cloud Run / Container Apps (scale-to-zero natif) ou ECS/Fargate. Kamal et Swarm imposent un scaling manuel.
Charge stable et prévisible → serveurs dédiés/VPS (Kamal, Swarm, Coolify) : le serverless fait payer cher la flexibilité dont vous n’avez pas besoin.
Batch massif, calcul, files de jobs → Nomad excelle ; K8s + Jobs fonctionne ; les jobs Cloud Run/Fargate pour du ponctuel.
Applications à état exigeantes (bases de données) → partout un sujet délicat ; K8s a la réponse la plus mûre (StatefulSets + operators), mais la base managée du cloud reste souvent le meilleur choix, quel que soit l’orchestrateur.
IA / GPU → le centre de gravité est clairement K8s : 66 % des organisations y hébergent déjà des workloads d’IA générative, et l’outillage (scheduling GPU, Kueue, opérateurs d’inférence) s’y concentre. Source : CNCF Annual Survey 2025

8. Maturité et pérennité en 2026

Dernier critère, souvent négligé : sur quoi peut-on construire pour 10 ans ?

Option	Maturité	Signaux
Kubernetes	★★★★★	Projet CNCF graduated, gouvernance multi-vendeurs, 3 releases/an tenues depuis 2015, adoption production à 82 %. Le risque n’est pas la disparition mais la complexité croissante. Source : CNCF
ECS, Cloud Run, ACA	★★★★★	Services cœur des trois hyperscalers, investissement continu. Le risque est le lock-in, pas l’abandon.
Nomad	★★★☆☆	Techniquement mûr (production depuis 2015), mais licence BSL depuis 2023, rachat IBM finalisé en 2025, passage à un versioning et un cycle de support « IBM » (V.M.F, releases printemps/automne) à partir de 2026. La communauté open source s’est refroidie ; l’avenir est celui d’un produit d’entreprise IBM. Source : HashiCorp — CE license & support
Docker Swarm	★★★☆☆	Stable et supporté par Mirantis jusqu’en 2030 au moins, mais en maintenance : y démarrer un nouveau projet en 2026 est un pari sur un outil sans évolution majeure. Source : Mirantis
k3s / Talos / k0s	★★★★☆	Suivent le rythme de K8s (k3s 1.35 disponible un mois après l’upstream), adossés à des éditeurs viables (SUSE, Sidero, Mirantis). Source : k3s blog
Kamal	★★★☆☆	Jeune (2023) mais adossé à 37signals qui l’utilise pour toute sa production ; périmètre volontairement restreint, donc peu de surface de risque.
Coolify / Dokploy	★★☆☆☆	Projets jeunes, petites équipes, itération rapide. Parfaits pour des projets où une migration resterait indolore ; à évaluer prudemment pour du critique.
Fly.io / Railway / Render	★★★☆☆	Produits solides mais entreprises jeunes : le risque est économique (pricing, pivot, rachat) plus que technique.

9. Conclusion

Trois idées à retenir :

Kubernetes a gagné la standardisation, pas l’universalité. L’API K8s est le POSIX de l’infrastructure distribuée : même ses « alternatives » managées (Container Apps) sont parfois construites dessus. Mais un standard d’industrie n’est pas un choix par défaut pour chaque équipe — le coût opérationnel et cognitif est réel, et le premier frein est désormais humain, pas technique.
La vraie concurrence ne vient pas des autres orchestrateurs. Nomad est remarquable mais son avenir s’écrit chez IBM ; Swarm est en fin de partie douce. Les parts de marché se prennent au-dessus (conteneurs serverless, PaaS) et en dessous (Kamal, PaaS self-hosted, retour au VPS) — en contournant le cluster, pas en le remplaçant.
Choisir, c’est situer son équipe sur deux axes : qui opère la plateforme, et quelle abstraction vous sert. Une équipe de 5 sans ops n’a rien à faire sur un cluster auto-hébergé ; une organisation de 100 devs avec une équipe plateforme gaspille son potentiel sur un PaaS. Et le chemin inverse existe : on peut commencer sur Cloud Run ou Coolify et migrer vers K8s quand — et si — le problème d’échelle arrive vraiment.

Pour approfondir : Kubernetes Docs, CNCF Landscape, Nomad Docs, kamal-deploy.org.