Comparer Kubernetes et Docker est une erreur. C'est pourtant la première comparaison que fait presque chaque équipe. Docker encapsule votre application dans un conteneur ; Kubernetes exécute des milliers de ces conteneurs sur un parc de machines et décide de leur emplacement. Il s'agit de deux technologies fondamentales de la conteneurisation, situées à deux niveaux différents de la pile technique.
La vraie question n'est donc pas de savoir lequel choisir, mais si le second justifie déjà son coût opérationnel.
Imaginez un port de commerce. Docker est le conteneur : dimensions standard, scellé, empilable, et peu importe que son contenu soit du café ou des pièces automobiles. Kubernetes est l'autorité portuaire : les grues, la planification, le manifeste qui indique quel conteneur va sur quel navire, et l'équipe qui recharge le conteneur si une grue le fait tomber. Vous pouvez gérer un petit quai avec quelques conteneurs et un presse-papiers. Rotterdam, en revanche, a besoin d'une autorité portuaire.
Cet article explique ce qu'est la conteneurisation, le rôle respectif de Docker et de Kubernetes, où se situe réellement la comparaison pertinente, et comment déterminer quand l'orchestration devient rentable.
En résumé :
Docker est une plateforme de conteneurisation. Il prend votre application et ses dépendances pour les empaqueter dans une image qui s'exécute de manière identique partout. Kubernetes est un orchestrateur de conteneurs : il prend ces images et décide quelle machine les exécute, combien de copies doivent exister, ce qui se passe en cas de défaillance et comment le trafic les atteint.
Peut-on utiliser Docker sans Kubernetes ? Oui, et c'est exactement par là que commencent la plupart des équipes. L'inverse n'est pas vraiment vrai. Kubernetes a besoin d'un outil pour créer des images de conteneurs, et pour la plupart des organisations, cet outil reste Docker.
| Docker | Kubernetes | |
|---|---|---|
| Objectif | Construit et exécute des conteneurs individuels | Exécute et gère des conteneurs au sein d'un cluster |
| Portée | Une machine, une application à la fois | Plusieurs machines, plusieurs services, un seul plan de contrôle |
| Mise à l'échelle | Manuelle, ou via Docker Compose et Docker Swarm | Automatique, déclarative, basée sur la charge et la politique |
| Gestion des pannes | Le conteneur s'arrête | Auto-guérison : les charges de travail en échec sont replanifiées |
| Courbe d'apprentissage | Quelques jours pour être productif | Des semaines à des mois, et cela ne s'arrête pas là |
| Coût opérationnel | Négligeable au-delà de la machine du développeur | Une capacité de plateforme financée : cluster, mises à niveau, astreinte |
| Qui le gère | Chaque développeur | Une équipe plateforme ou DevOps |
Deux noms dans ce tableau méritent une définition préalable. Docker Compose est l'outil permettant de définir et d'exécuter une configuration multi-conteneurs sur une seule machine. Docker Swarm est l'orchestrateur propre à Docker, sur lequel nous reviendrons plus loin.
Analysons les différentes couches.
La conteneurisation permet aux développeurs de regrouper le code logiciel et tout ce dont il a besoin pour s'exécuter (frameworks, bibliothèques et autres dépendances) dans un conteneur unique et isolé. Une fois mis en boîte, le logiciel devient mobile. Toute application contenue peut être déplacée vers une infrastructure différente et continuer à fonctionner, quel que soit le système d'exploitation ou l'environnement sous-jacent.
Cette portabilité est l'objectif même de la technologie, et la sécurité en découle naturellement, car une même version se comporte de manière identique sur toutes les machines où elle est déployée. Attention toutefois, tout ne doit pas être mis en boîte. Les applications de bureau gourmandes en graphismes sont généralement virtualisées au niveau de l'hyperviseur — la couche qui exécute des machines virtuelles complètes avec leur propre système d'exploitation, à l'aide d'outils comme Vagrant — car elles nécessitent un accès matériel qu'un conteneur ne peut leur offrir.
Avant l'avènement des conteneurs, les développeurs écrivaient du code dans un environnement informatique donné pour rencontrer des problèmes dès son transfert. Passer de Linux à Windows rendait le code vulnérable aux bugs et aux erreurs spécifiques à l'environnement. Les conteneurs résolvent ce problème en isolant le logiciel du système d'exploitation hôte, garantissant ainsi une stabilité totale.
Les applications évoluent dans des environnements indépendants et encapsulés. Évolutivité, déploiement plus rapide et meilleure cohérence entre les environnements : tels sont les avantages principaux, et leur adoption en témoigne. L'utilisation des conteneurs parmi les développeurs backend dépassait déjà les 60 % en 2020 (SlashData, State of Cloud Native Development), et cette tendance n'a fait que s'accentuer depuis : la plus récente étude de la CNCF, Annual Cloud Native Survey, publiée en janvier 2026, révèle que 82 % des organisations utilisant des conteneurs exploitent désormais Kubernetes en production, contre 66 % deux ans auparavant.
Soit dit en passant, le concept est antérieur à Docker. Les Linux Containers (LXC) proposaient déjà cette technologie bien avant 2013. Ce que Docker a révolutionné avec sa version open-source cette année-là, c'est l'expérience développeur, ce qui lui a permis de devenir le format de conteneur par défaut. C'est toujours le cas aujourd'hui : l'enquête annuelle Stack Overflow Developer Survey continue de classer Docker parmi les outils de développement les plus utilisés, loin devant tous les autres outils de conteneurisation.
Docker est une plateforme de conteneurisation utilisée pour développer, distribuer et exécuter des applications sous forme de conteneurs portables et autonomes. Ordinateurs portables, environnements cloud, centres de données : il fonctionne pratiquement partout.
Au fil des ans, Docker a bâti une vaste plateforme autour de ce cœur. Cela ne fait pas pour autant de chaque outil Docker le choix évident. Le secteur est concurrentiel et plusieurs de ses couches disposent d'alternatives solides.
Un conteneur Docker est une instance en cours d'exécution d'une image Docker : votre application accompagnée de tout ce dont elle a besoin, isolée de l'hôte et de tous les autres conteneurs. Il emprunte le noyau du système d'exploitation de l'hôte plutôt que d'embarquer le sien. C'est pourquoi un conteneur démarre en quelques secondes là où une machine virtuelle prend plusieurs minutes.
Trois éléments permettent d'y parvenir :
Vous n'avez pas toujours besoin d'un Dockerfile. Les développeurs peuvent récupérer une image prête à l'emploi depuis un registre tel que Docker Hub ou Azure Container Registry pour gagner du temps — le choix est vaste. Ainsi, pour exécuter un conteneur Docker, vous pouvez soit extraire une image d'un registre public, soit créer la vôtre à l'aide d'un Dockerfile.
C'est dans la création de vos propres images que la rigueur fait la différence. Un Dockerfile jetable et un Dockerfile destiné à la production ne se ressemblent en rien. Voici le modèle que nous utilisons : une construction multi-étapes qui exclut les dépendances de développement de l'image finale, s'exécute avec un utilisateur non privilégié et produit un artefact léger et reproductible :
# syntax=docker/dockerfile:1
# IC house-standard Node/TypeScript service image.
# Multi-stage: deterministic prod dependencies, minimal non-root runtime.
ARG NODE_VERSION=22.11.0 # IC: pin by digest in production
ARG APP_PORT=3000
# ---- Stage 1: install everything and build ----
FROM node:${NODE_VERSION}-bookworm-slim AS build
WORKDIR /app
ENV NODE_ENV=development
COPY package.json package-lock.json ./
RUN --mount=type=cache,target=/root/.npm npm ci
COPY . .
RUN npm run build # IC: expects a build script emitting to ./dist
# ---- Stage 2: production dependencies only ----
FROM node:${NODE_VERSION}-bookworm-slim AS prod-deps
WORKDIR /app
ENV NODE_ENV=production
COPY package.json package-lock.json ./
RUN --mount=type=cache,target=/root/.npm npm ci --omit=dev
# ---- Stage 3: runtime ----
FROM node:${NODE_VERSION}-bookworm-slim AS runtime
ARG APP_PORT
# tini gives us correct signal handling and zombie reaping as PID 1.
RUN apt-get update \
&& apt-get install -y --no-install-recommends tini \
&& rm -rf /var/lib/apt/lists/*
WORKDIR /app
ENV NODE_ENV=production PORT=${APP_PORT}
# Copy only what runtime needs, owned by the image's built-in non-root user.
COPY --chown=node:node --from=prod-deps /app/node_modules ./node_modules
COPY --chown=node:node --from=build /app/dist ./dist
COPY --chown=node:node package.json ./
# OCI provenance labels (IC: wire GIT_SHA / BUILD_DATE from CI).
ARG GIT_SHA=unknown
ARG BUILD_DATE=unknown
LABEL org.opencontainers.image.vendor="Imaginary Cloud" \
org.opencontainers.image.revision="${GIT_SHA}" \
org.opencontainers.image.created="${BUILD_DATE}"
USER node
EXPOSE ${APP_PORT}
# Docker-level healthcheck. In Kubernetes, prefer liveness/readiness probes.
HEALTHCHECK --interval=30s --timeout=3s --start-period=10s --retries=3 \
CMD node -e "fetch('http://localhost:'+process.env.PORT+'/health').then(r=>process.exit(r.ok?0:1)).catch(()=>process.exit(1))"
ENTRYPOINT ["tini", "--"]
CMD ["node", "dist/main.js"]Cette ligne HEALTHCHECK est une petite démonstration miniature de la thèse de cet article : cela fonctionne, mais dès que vous exécutez cette image sous Kubernetes, vous confiez cette tâche à une sonde de vivacité (liveness probe). La construction reste identique ; seule la couche qui l'entoure change.
Docker est utilisé pour garantir qu'un logiciel se comporte de la même manière partout où il est exécuté. En pratique, cela couvre quatre aspects :
Puis les boîtes se multiplient. À mesure que le nombre de conteneurs augmente, la complexité de leur gestion croît également, et une série de problèmes familiers apparaît, qui relèvent tous de l'orchestration :
La réponse de Docker a été Docker Swarm, sa propre technologie d'orchestration de conteneurs. Et c'est le détail que la plupart des comparaisons omettent : Swarm, et non la plateforme Docker dans son ensemble, est le composant qui se compare réellement à Kubernetes.
Kubernetes est une technologie d'orchestration de conteneurs, au même titre qu'OpenShift ou Amazon ECS. Introduit par Google en 2014, un an après la sortie de Docker, il est désormais géré par la CNCF, la Cloud Native Computing Foundation.
Il a été conçu pour planifier, gérer, automatiser le déploiement et mettre à l'échelle des applications conteneurisées. En d'autres termes, il prend en charge la complexité liée à l'exécution d'un grand nombre de conteneurs sur de multiples serveurs, sans qu'un humain n'ait à intervenir manuellement pour décider de l'emplacement de chaque élément.
Il y parvient grâce à une API open source qui régule la manière dont les conteneurs s'exécutent et leur emplacement. Les conteneurs sont regroupés en pods, l'unité opérationnelle de base dans Kubernetes. Les pods s'exécutent sur des nœuds, les machines du cluster, et le plan de contrôle est l'ensemble des composants qui décide de ce qui doit être exécuté et où, tout en corrigeant discrètement le cluster dès que la réalité s'écarte de l'état souhaité. Une fois regroupés, les pods peuvent être mis à l'échelle et leur cycle de vie est contrôlé de manière déclarative.
Ainsi, Kubernetes orchestre les machines et y planifie les conteneurs en fonction des ressources de calcul disponibles et des besoins de chaque conteneur. Votre équipe déclare l'état souhaité du cluster ; la plateforme gère la planification, la gestion des connexions et la récupération. Le projet évolue rapidement — Kubernetes a atteint la version 1.36 en 2026 — mais ce cœur déclaratif est stable depuis des années.
Kubernetes prend en charge une large gamme d'outils de conteneurisation, dont les images Docker, ce qui nous ramène à la comparaison initiale.
Pour comparer Docker et Kubernetes correctement, il faut mettre en opposition Docker Swarm et Kubernetes, car ce sont deux technologies d'orchestration de conteneurs. Docker domine le marché de la conteneurisation, mais pas celui de l'orchestration. C'est Kubernetes qui l'a emporté, et de manière décisive : le dépôt Kubernetes compte environ 115 000 étoiles sur GitHub en 2026, contre quelques milliers pour la bibliothèque derrière Docker Swarm, qui est pratiquement à l'abandon depuis des années. L'écart en matière de support commercial est encore plus grand, tous les principaux fournisseurs de cloud proposant un service Kubernetes managé.
Docker et Kubernetes sont des technologies complémentaires. Leurs rôles se confondent dans l'imaginaire collectif, mais se chevauchent à peine dans la pratique. Docker fabrique les conteneurs. Kubernetes gère le port.
Kubernetes apporte également un ensemble de fonctionnalités qui deviennent essentielles dès lors que vous gérez plus qu'une poignée de services : équilibrage de charge, politiques réseau, gestion des secrets, isolation des charges de travail, auto-réparation et capacité de mise à l'échelle sur tous les nœuds du cluster.
Pour tirer le meilleur parti de Docker et Kubernetes ensemble, il faut être honnête sur l'utilité réelle de chacun. Toutes les organisations utilisant des conteneurs n'ont pas besoin d'un orchestrateur. Les équipes gérant de petites applications avec un nombre réduit et contrôlable de conteneurs n'en ont généralement pas besoin, et l'ajout d'un tel outil leur coûte plus cher qu'il ne leur rapporte.
À mesure que les besoins logiciels augmentent, les applications sous-jacentes doivent également évoluer. Pour bénéficier d'une architecture de microservices, les prérequis doivent être en place. Sinon, la conteneurisation devient un fardeau pour votre pile technologique plutôt qu'un avantage.
Kubernetes, ou un outil similaire, n'est donc pas obligatoire. Il est fortement recommandé pour les infrastructures qui doivent monter en charge et gérer un grand nombre de conteneurs au sein de systèmes distribués. À une échelle significative, l'orchestration est désormais la norme plutôt que l'exception : le sondage 2026 de la CNCF indique que 82 % des organisations interrogées utilisent Kubernetes en production, et qu'une partie supplémentaire est en phase de test ou d'évaluation. La tendance est clairement orientée vers Kubernetes managé, et non vers l'abandon de l'orchestration.
Les avantages rapportés par ces organisations sont constants :
Cette question a suscité une réelle inquiétude lorsque Kubernetes 1.20 a annoncé que le support de Docker dans le kubelet était obsolète et serait supprimé dans une version ultérieure. De nombreux développeurs y ont vu la fin de Docker, et par extension, la fin de la combinaison Docker et Kubernetes. Kubernetes a publié une clarification le 2 décembre 2020, Pas de panique : Kubernetes et Docker, expliquant que la situation était moins dramatique qu'il n'y paraissait.
Voici ce qui se passait réellement. Au sein d'un cluster Kubernetes, un composant appelé « container runtime » récupère et exécute les images de conteneurs, tandis que le kubelet est l'agent présent sur chaque nœud qui communique avec lui. Docker était l'environnement d'exécution le plus populaire pour cette tâche, mais il n'a jamais été conçu pour être intégré à Kubernetes. Il est fait pour être piloté par des humains via une ligne de commande, et non par un autre logiciel. Kubernetes avait donc besoin d'une interface intermédiaire, Dockershim, pour faire le lien entre le kubelet et Docker — alors que, sous le capot, Docker sollicitait en réalité containerd, l'environnement d'exécution de bas niveau qu'il utilise lui-même. Une couche supplémentaire à maintenir, sans aucun gain fonctionnel.
La suppression a bien eu lieu. Dockershim a été retiré du kubelet dans Kubernetes 1.24, publié en mai 2022, et containerd est désormais l'environnement d'exécution par défaut sur la plupart des clusters gérés, avec CRI-O — un environnement léger conçu exclusivement pour Kubernetes — comme alternative principale. Ce qui n'est pas arrivé, c'est une quelconque rupture de compatibilité. Les images créées avec Docker respectent la Open Container Initiative et s'exécutent sur Kubernetes exactement comme avant : la FAQ sur la suppression de dockershim contient tous les détails. Alors, est-ce la fin de Docker ? Non. Kubernetes a cessé d'utiliser Docker comme environnement d'exécution. Il n'a jamais cessé d'exécuter des images Docker. Et quatre ans plus tard, il les exécute toujours sans aucune modification.
Chaque article sur ce mot-clé compare les fonctionnalités. Très peu abordent le coût réel de la décision, ce que le CTO doit pourtant valider.
Kubernetes n'est pas un outil que l'on adopte. C'est une capacité de plateforme que l'on finance. Le cluster en lui-même ne coûte pas cher. Ce qui coûte cher, ce sont les personnes chargées de le maintenir à jour, la cadence des mises à jour, les astreintes, la gestion des politiques de sécurité et de réseau, ainsi que les mois de ralentissement de la production pendant la phase d'apprentissage de l'équipe. Les services managés des principaux fournisseurs cloud éliminent une grande partie de la charge opérationnelle. Mais pas la responsabilité.
Nous utilisons un test simple avec nos clients, que nous appelons le seuil d'orchestration. Kubernetes justifie son coût lorsque trois au moins de ces cinq affirmations sont vraies :
Moins de trois ? Dans ce cas, la recommandation honnête est généralement d'utiliser Docker avec un service de conteneurs managé comme ECS, Cloud Run ou App Service, et de noter dans votre agenda de réévaluer la question dans un an.
Nous appliquons nos propres recommandations. Pour une récente plateforme de communication maritime (Sedna), nous avons pris le contre-pied de l'orchestration : plutôt que de déployer un cluster, nous avons migré les flux d'intégration du client vers des services sur mesure sur AWS — infrastructure définie par Terraform, pipelines CI/CD et fonctions Lambda — réduisant ainsi leurs coûts d'outillage de 80 %. En dessous de ce seuil, c'est généralement le compromis le plus rentable.
Dans nos projets de livraison, le constat est le même : les équipes qui adoptent Kubernetes en dessous de ce seuil consacrent plus de temps d'ingénierie à la plateforme qu'au produit durant les deux premiers trimestres, tandis que celles qui l'adoptent au-dessus de ce seuil cessent de considérer le déploiement comme un événement majeur dans le même laps de temps.
Il existe ensuite un risque que personne ne budgétise : le cluster sans responsable. Une installation Kubernetes dont la maintenance n'est financée par personne finit par devenir obsolète, accumule des composants non corrigés et devient plus difficile à abandonner qu'elle ne l'a été à adopter. C'est comme un navire que personne n'est payé pour décharger. Il s'agit d'un problème de gouvernance bien avant d'être un problème technique.
La conteneurisation n'est pas la solution adaptée à toutes les charges de travail, mais ses avantages justifient l'intérêt qu'on lui porte : une meilleure qualité des applications, une productivité accrue, une réduction des temps d'arrêt et une plus grande réactivité face au changement.
Comment Docker et Kubernetes collaborent-ils pour y parvenir ?
Le conteneur et le port. Ils sont complémentaires, et leur association avec les pratiques DevOps vous offre une base de microservices qui favorise une livraison rapide et des applications cloud-native évolutives. La question n'a donc jamais été de savoir lequel choisir. Il s'agit de déterminer si votre organisation a franchi le cap de l'orchestration. Et si ce n'est pas encore le cas, quand elle le fera.
Pas du runtime Docker, mais très certainement des outils Docker. Kubernetes exécute les conteneurs via containerd ou CRI-O, et non via Docker. Vous avez toujours besoin d'un outil pour créer des images de conteneurs, et Docker reste le choix le plus courant pour cela, ainsi que la méthode standard utilisée par les développeurs pour exécuter des conteneurs localement.
Non. Kubernetes a remplacé Docker en tant que runtime de conteneur au sein de ses propres nœuds dans la version 1.24, en mai 2022. Il n'a pas remplacé Docker en tant que format d'image ou outil de build, et les images créées avec Docker fonctionnent sur Kubernetes sans modification.
Un conteneur Docker est une instance en cours d'exécution d'une image Docker : une application packagée avec ses dépendances, isolée de la machine hôte. Il partage le noyau du système d'exploitation de l'hôte, ce qui lui permet de démarrer en quelques secondes et d'utiliser une fraction des ressources d'une machine virtuelle.
Docker est utilisé pour packager des applications afin qu'elles s'exécutent de manière identique partout : sur l'ordinateur d'un développeur, dans un pipeline d'intégration continue et en production. Il constitue la base des architectures de microservices, élimine les bugs liés à l'environnement et fournit aux pipelines de déploiement un artefact unique à promouvoir.
Docker Swarm convient aux petits clusters avec des charges de travail simples, en particulier lorsqu'une équipe connaît déjà Docker Compose et souhaite bénéficier de l'ordonnancement sans avoir à apprendre un nouveau modèle opérationnel. Il est plus simple et plus rapide à prendre en main que Kubernetes. La contrepartie est un écosystème beaucoup plus restreint, un hébergement managé limité et un nombre décroissant d'ingénieurs l'ayant utilisé.
Oui, et beaucoup d'organisations devraient le faire. Un service de conteneurs managé tel qu'AWS ECS, Google Cloud Run ou Azure Container Apps exécute des conteneurs en production avec beaucoup moins de charge opérationnelle que Kubernetes. La contrepartie est un contrôle moindre et un couplage plus étroit avec un fournisseur cloud spécifique.
Vous vous demandez si Kubernetes est pertinent pour votre organisation ? Des plateformes de communication à l'échelle maritime aux migrations serverless sur AWS, nous concevons et exploitons des plateformes cloud-native que les équipes peuvent réellement maintenir — et nous sommes tout aussi disposés à vous dire quand vous n'en avez pas besoin. Discutez avec notre équipe de l'évolution de votre infrastructure.
Stagiaire en marketing avec un intérêt particulier pour la technologie et la recherche. Pendant mon temps libre, je joue au volley-ball et je gâte mon chien autant que possible.
Expert en sécurité et opérations cloud. Expérience dans les transports publics, les finances et le gouvernement. Négociez généralement des pièces sur des bourses décentralisées:)
People who read this post, also found these interesting:
.webp)
