Kubernetes ou Docker : deux technologies de conteneurs à ne pas opposer

La question qu'on se pose encore en 2026

« Kubernetes ou Docker ? » reste une question fréquente, posée par des équipes qui démarrent avec les conteneurs comme par des directions qui arbitrent un budget de plateforme. Elle repose sur un malentendu ancien : les deux technologies appartiennent au même écosystème, mais ne font pas le même travail.

Docker regroupe une application et ses dépendances dans une image portable, puis l'exécute dans un conteneur isolé. Kubernetes décide où et comment ces conteneurs tournent sur un ensemble de serveurs : placement, mise à l'échelle, redémarrage, mise à jour sans interruption. L'un empaquette, l'autre exploite. Les comparer revient à comparer un format de livraison et une chaîne logistique.

Ce qui a changé ces dernières années, c'est la répartition des rôles autour de l'IA. Les agents de code produisent et exécutent du code à grande vitesse, les modèles d'IA générative tournent en production, et chacune des deux technologies a pris position sur ce terrain. La question utile devient donc : qui construit, qui exploite, et qui isole ?

Docker en 2026 : construire, sécuriser, isoler

Docker reste l'outil de la boucle de développement : construire une image reproductible, la tester en local avec Compose, la publier dans un registre. Le moteur en est à sa version 29 (29.9.2, publiée le 20 octobre 2026), et le même conteneur tourne toujours sur le poste du développeur, dans l'intégration continue et en production.

La sécurité de la chaîne d'approvisionnement

Le 17 décembre 2025, Docker a rendu gratuites et open source, sous licence Apache 2.0, plus de 1 000 images durcies (Docker Hardened Images), construites sur Debian et Alpine. Une image de base minimale et maintenue réduit d'autant les vulnérabilités qu'on embarque sans le savoir. Une part décisive de la sécurité d'un déploiement se joue dans le Dockerfile, bien avant le cluster. Nous détaillons ces pratiques dans DevSecOps : 10 bonnes pratiques pour sécuriser la chaîne de livraison.

L'isolation des agents IA

Docker propose aussi des outils pour faire tourner des modèles et des agents en local, et des environnements isolés pour les agents de code. Le 24 septembre 2026, l'éditeur a étendu ces environnements au cloud (Docker Cloud Sandboxes), avec une isolation par micro-machines virtuelles. Son président, Mark Cavage, résume le changement : les conteneurs « n'ont pas été conçus pour le niveau d'isolation qu'exigent les agents IA ». Les risques propres aux agents sont détaillés dans Les agents IA ne doivent pas être un cauchemar de sécurité.

Kubernetes en 2026 : le socle d'exploitation, y compris pour l'IA

Kubernetes automatise le déploiement, la mise à l'échelle et la supervision des conteneurs sur un ensemble de serveurs. Son principe n'a pas changé : on décrit l'état voulu dans des fichiers versionnés, et des boucles de contrôle rapprochent en permanence la réalité de cette description. Un conteneur s'arrête, il est relancé ; un serveur tombe, ses charges sont replacées ailleurs. Pour les notions de base, voir notre introduction à l'orchestration de conteneurs.

Le projet publie trois versions par an et maintient les trois dernières. Au 2 novembre 2026, ce sont les versions 1.35, 1.36 et 1.37 ; la 1.34 n'est plus maintenue depuis le 27 octobre 2026.

Le standard de production

L'enquête annuelle de la CNCF, publiée le 20 janvier 2026, mesure que 82 % des utilisateurs de conteneurs font tourner Kubernetes en production, contre 66 % en 2023. Kubernetes n'est plus une technologie émergente : c'est l'infrastructure par défaut dès qu'il faut faire tourner de nombreux services de façon fiable.

Le socle de l'inférence

La même enquête indique que 66 % des organisations qui hébergent des modèles d'IA générative utilisent Kubernetes pour tout ou partie de leur inférence. L'allocation dynamique de ressources (DRA), stable depuis la version 1.34, permet de partager finement GPU et accélérateurs entre plusieurs charges. L'enquête rappelle aussi la prudence des organisations : seules 7 % déploient des modèles chaque jour.

À lire aussiBonnes pratiques Kubernetes en production : le guide 2026Sondes de santé, requests et limits, autoscaling Karpenter et KEDA, RBAC, politiques réseau, GitOps : les pratiques qui fiabilisent Kubernetes en production.Lire l'article

Le malentendu dockershim, réglé depuis 2022

Une partie de la confusion vient de l'histoire. Kubernetes a longtemps exécuté les conteneurs à travers Docker, via une couche d'adaptation appelée dockershim, retirée avec la version 1.24 en mai 2022. Depuis, les clusters utilisent directement des moteurs conformes à l'interface CRI, comme containerd ou CRI-O. containerd est d'ailleurs un composant que Docker a extrait de son propre moteur et confié à la communauté.

Pour les équipes, rien n'a changé d'essentiel : une image construite avec Docker suit le standard OCI et tourne à l'identique sur containerd, CRI-O ou tout moteur conforme. Le même standard permet d'utiliser d'autres outils, comme Podman ou Buildah, sans fragmenter l'écosystème. On construit avec l'un, on exploite avec l'autre, et le standard assure la continuité.

Ce qui change pour vos clusters en 2026

Trois évolutions demandent une action, quelle que soit la taille de la plateforme.

• Ingress NGINX n'est plus maintenu. Annoncé le 11 novembre 2025 : maintenance au mieux jusqu'en mars 2026, puis plus aucune version ni correctif, y compris de sécurité. Le projet recommande de migrer, notamment vers Gateway API.
• cgroup v1 est en cours de retrait. Depuis la version 1.35, le kubelet refuse par défaut de démarrer sur un nœud qui utilise encore cgroup v1.
• containerd 1.7 est en fin de vie depuis le 30 septembre 2026. Les versions maintenues sont la 2.0 et la 2.3 (support long) et la 2.4.

Les installations existantes d'Ingress NGINX continuent de fonctionner, mais toute faille future restera ouverte. Les nœuds sur d'anciennes distributions Linux sont à identifier avant la prochaine montée de version. À cela s'ajoute la montée de version régulière : un cluster encore en 1.34 ou antérieur ne reçoit plus de correctifs.

Docker et Kubernetes ensemble dans la chaîne de livraison

La répartition des rôles est claire. Le développeur travaille en local avec Docker et Compose ; l'intégration continue construit l'image à partir d'une base durcie, l'analyse et la signe, puis la publie dans un registre ; un outil GitOps déploie la nouvelle version sur les clusters Kubernetes en comparant l'état déclaré dans Git à l'état réel. Les agents IA s'insèrent à chaque étape, dans des environnements isolés et sous des règles explicites. Le rôle de la plateforme interne dans cette chaîne est développé dans Platform Engineering augmenté par l'IA : l'IDP en 2026.

Toutes les organisations n'ont pas besoin de Kubernetes dès le premier jour. Une application au trafic stable peut tourner sur des conteneurs gérés par un service cloud ou une plateforme applicative managée. Kubernetes se justifie quand le besoin d'échelle, de résilience ou de standardisation entre équipes compense sa complexité d'exploitation.

À lire aussiKubernetes est-il adapté à votre besoin ?Kubernetes orchestre les conteneurs à grande échelle mais impose complexité, coûts et courbe d'apprentissage. Architecture, avantages, limites et méthode pour trancher en 2026.Lire l'article

Nos recommandations

Nous recommandons cinq gestes, dans cet ordre.

• Partir des images : adopter des images de base durcies et maintenues, épingler les dépendances, analyser chaque image à la construction.
• Faire l'inventaire des clusters : versions de Kubernetes, contrôleur d'entrée, version de cgroup sur les nœuds, version de containerd.
• Planifier la sortie d'Ingress NGINX si vous l'utilisez, sans attendre une faille.
• Isoler les agents IA qui exécutent du code, avec des environnements dédiés et des droits limités, plutôt que de les lancer dans les conteneurs de l'application.
• Dimensionner avant de choisir : Kubernetes quand le besoin le justifie, une plateforme managée sinon.

Comment Adservio vous accompagne

Collectif d'experts en ingénierie augmentée, Adservio intervient à chaque étape : évaluation du besoin réel, choix entre clusters managés et auto-hébergés, audit des clusters existants (versions, contrôleur d'entrée, cgroup, moteur de conteneurs), migration vers Gateway API, chaîne de livraison sécurisée et GitOps, observabilité et maîtrise des coûts. Nos équipes conçoivent avec vous l'isolation des agents IA dans vos environnements de développement et de production, et pilotent la plateforme à vos côtés dans la durée.

En résumé

Docker construit et empaquette, Kubernetes exploite, et les agents IA demandent désormais une isolation dédiée. Les opposer n'a pas de sens ; les combiner proprement demande en revanche de suivre leurs évolutions : images durcies, inférence sur Kubernetes, fin d'Ingress NGINX, de cgroup v1 et de containerd 1.7.