Kubernetes
Kubernetes en production : ce que les projets DevOps et data nous ont appris
82 % des utilisateurs de conteneurs font tourner Kubernetes en production en 2026, contre 66 % en 2023 (CNCF Annual Survey 2025). En trois ans, Kubernetes est passé d’un outil réservé aux équipes cloud avancées à une infrastructure standard dans les grandes organisations. 84 % des entreprises prévoient de construire au moins la moitié de leurs nouvelles applications sur Kubernetes dans les cinq prochaines années (Voice of Kubernetes Report 2026).
Mais derrière ces chiffres se cache une réalité plus nuancée. Kubernetes résout des problèmes réels : portabilité, scalabilité, résilience. Il en crée d’autres, moins souvent documentés : complexité opérationnelle, courbe d’apprentissage élevée, défis organisationnels entre équipes Dev et Ops.
Cet article ne présente pas Kubernetes comme une solution universelle. Il décrit ce qu’on observe sur le terrain, dans des projets DevOps industriels et des stacks data complexes, et ce que ça change concrètement pour les équipes qui le déploient.
- I) Kubernetes : définition et rôle réel dans une architecture cloud native
- II) Kubernetes en production : les deux cas d'usage qui reviennent le plus
- III) Kubernetes : les 3 bénéfices concrets et les 3 pièges à éviter
- IV) Kubernetes et IaC : comment les faire travailler ensemble ?
- V) Kubernetes en 2026 : ce qui change
- En résumé
Ce que Kubernetes fait vraiment
Kubernetes est un orchestrateur de conteneurs open source, développé à l’origine par Google et maintenu aujourd’hui par la Cloud Native Computing Foundation (CNCF). Son rôle est de gérer le cycle de vie des conteneurs : les déployer, les surveiller, les redémarrer en cas de panne, les scaler automatiquement en fonction de la charge.
Un conteneur est un paquet autonome qui regroupe une application et tout ce dont elle a besoin pour fonctionner : bibliothèques, dépendances, configuration. L’analogie la plus juste est celle d’un container maritime : peu importe le navire qui le transporte, le contenu reste identique et fonctionne de la même façon à destination.
Kubernetes, c’est le système qui gère la flotte de ces containers : il décide sur quel « navire » (serveur) chaque container est déployé, s’assure qu’il tourne, en lance d’autres si la demande augmente, et en supprime si elle baisse.
Ce que Kubernetes n’est pas
Kubernetes n’est pas un outil de déploiement d’infrastructure : c’est le rôle de Terraform. Il n’est pas non plus un outil de configuration des systèmes : c’est le rôle d’Ansible. Kubernetes intervient une fois que l’infrastructure est provisionnée et configurée : il orchestre ce qui tourne dessus.
Cette distinction est importante. Beaucoup d’organisations qui peinent avec Kubernetes ont en réalité un problème en amont : une infrastructure mal provisionnée, des images de conteneurs mal construites, ou une absence de stratégie IaC cohérente.
1. Dans les projets DevOps : portabilité et déploiement continu
Dans le contexte d’une mission DevOps longue durée que l’on a pu mener dans le secteur ferroviaire, Kubernetes a été utilisé comme cible de déploiement dans le pipeline CI/CD, aux côtés de Terraform pour l’infrastructure et Jenkins pour l’orchestration des pipelines. Le schéma est classique : Terraform provisionne l’infrastructure sur AWS, Jenkins déclenche les pipelines, Kubernetes reçoit et orchestre les applications conteneurisées.
Ce qui change concrètement avec Kubernetes dans ce contexte : l’application devient portable. Le même code peut être exécuté sur AWS, sur Azure, ou sur un environnement on-premise, sans modification. C’est un avantage structurant sur des projets longue durée où le fournisseur cloud peut changer, ou sur des architectures multi-cloud.
La scalabilité automatique est le second bénéfice direct. Quand la charge augmente, par exemple un pic de trafic sur une application de supervision de flotte, Kubernetes lance automatiquement des instances supplémentaires. Quand la charge redescend, il les supprime. Sans intervention manuelle.
2.Dans les projets data : orchestration de workloads intensifs
Les stacks data modernes utilisent Kubernetes différemment. Sur des projets de plateforme data en mode PaaS, comme ceux qu’on accompagne dans le secteur des transports, Kubernetes est utilisé pour orchestrer des workloads de traitement de données à grande échelle : jobs Spark, pipelines Airflow, services d’ingestion en continu.
L’infrastructure cloud native devient le socle minimum pour faire tourner de l’IA en production avec de vraies garanties. L’IA pousse à son tour la complexité de l’infrastructure vers l’extérieur : edge, données en temps réel, nouveaux patterns de monitoring et de sécurité.
Dans ce contexte data, Kubernetes apporte deux avantages concrets : l’isolation des workloads (chaque job tourne dans son propre conteneur, sans interférence avec les autres) et la résilience (si un job échoue, Kubernetes le relance automatiquement selon les règles définies).
Les 3 bénéfices concrets
Avant d’évaluer Kubernetes, trois bénéfices structurants reviennent systématiquement sur le terrain :
- Portabilité multi-cloud : un workload conteneurisé n’est pas lié à un fournisseur cloud spécifique
- Scalabilité automatique : la montée en charge est gérée sans intervention humaine
- Résilience native : les conteneurs défaillants sont redémarrés automatiquement, les workloads redistribués
Les 3 pièges les plus fréquents sur le terrain
De la provision de l’infrastructure jusqu’au déploiement des conteneurs, chaque outil à sa place dans le pipeline.
Le flux naturel : Terraform → Kubernetes → Ansible
Dans une stack DevOps mature, les trois outils s’articulent en séquence. Terraform provisionne le cluster Kubernetes sur le fournisseur cloud : il crée les nœuds, configure le réseau, gère les permissions IAM. Kubernetes orchestre ensuite les workloads qui tournent sur ce cluster. Ansible peut intervenir pour la configuration fine des nœuds ou l’installation de composants système.
Ce flux n’est pas une obligation : il existe d’autres architectures valides. Mais c’est le schéma qu’on observe le plus souvent sur les projets bien structurés, notamment dans des environnements AWS où Terraform gère l’infrastructure EKS et Jenkins ou GitLab CI déclenche les déploiements Kubernetes.
GitOps appliqué à Kubernetes
L’approche GitOps, où tout l’état de l’infrastructure et des applications est décrit dans Git, s’applique naturellement à Kubernetes. Des outils comme ArgoCD ou Flux permettent de synchroniser automatiquement l’état du cluster avec ce qui est décrit dans le repository Git. Quand un développeur fait un commit, le cluster se met à jour automatiquement.
C’est la convergence entre IaC et Kubernetes qui produit les environnements les plus fiables : chaque changement est tracé, réversible, et soumis au même processus de revue que le code applicatif.
Portabilité, scalabilité, résilience d’un côté — complexité opérationnelle, qualité des images et tensions Dev/Ops de l’autre. Ce que le terrain confirme.
Les dernières
ACTUALITÉS
- Data Marketing : définition et mise en oeuvre 2026Le data marketing ne s’arrête pas à la technologie. Il requiert un alignement sincère entre les équipes marketing, data et IT. L’écart entre les organisations qui investissent dans la data et celles qui en tirent vraiment de la valeur n’est pas technologique : il est organisationnel et culturel.
- Kubernetes en production : retours terrain 2026Kubernetes est devenu l’infrastructure par défaut des grandes organisations. 82 % des utilisateurs de conteneurs le font tourner en production. Mais derrière les chiffres, le terrain révèle une réalité plus nuancée : Kubernetes résout des problèmes réels, et en crée d’autres. Ce qu’on observe sur nos missions DevOps et data.
- AIOps : l’IA au cœur des opérations DevOpsL’AIOps ne remplace pas les ingénieurs Ops. Il amplifie leur capacité d’action. Là où un Ops humain analyse quelques centaines d’alertes par heure, un système AIOps en traite des milliers, corrèle les signaux, filtre le bruit et ne remonte que les incidents réels avec leur contexte. La réduction du MTTR de 40 % documentée sur le terrain n’est pas un chiffre marketing — c’est une réalité opérationnelle.
- Usine logicielle DevSecOps : un cas d’usage concret, dupilote à la généralisationDes applications utiles, mais livrées au rythme des disponibilités de chacun. Découvrez comment un établissement public de recherche a posé un socle DevSecOps commun, validé sur un pilote avant d’être généralisé.
- Terraform vs Ansible, comment choisir en 2026 ?Ce n’est pas une question de préférence personnelle. Terraform et Ansible ne font pas le même travail : l’un provisionne l’infrastructure et en garde la mémoire, l’autre configure ce qui tourne dessus. Choisir l’un pour faire le travail de l’autre est la source de la plupart des complications IaC sur le terrain.