À partir de quel nombre de sites clients l’orchestration de conteneurs cesse-t-elle d’être une complexité gratuite pour devenir un vrai levier d’efficacité ? Une agence qui gère une centaine de sites WordPress sur des VPS individuels, chacun administré manuellement, se pose fatalement cette question au moment où la charge d’exploitation devient difficile à absorber avec l’équipe en place, sans pour autant vouloir se lancer dans un projet d’infrastructure disproportionné.
Ce que Docker mono-site ne prépare pas
La conteneurisation Docker d’un site WordPress isolé, déjà largement pratiquée dans l’agence concernée, ne prépare qu’en partie à Kubernetes : gérer un conteneur unique par site reste conceptuellement proche d’un VPS traditionnel, alors que Kubernetes introduit des notions entièrement nouvelles — pods, services, ingress, persistent volumes — qui demandent un apprentissage distinct, non dérivé de la seule pratique Docker.
Le seuil observé
Sur les parcs que nous avons accompagnés vers une migration Kubernetes, le seuil de rentabilité se situe autour de la centaine de sites actifs. En dessous, le temps investi dans la mise en place du cluster (definitions YAML, ingress controller, gestion du stockage persistant pour les médias WordPress) dépasse largement le temps économisé sur l’exploitation quotidienne.
apiVersion: apps/v1
kind: Deployment
metadata:
name: site-client-a
spec:
replicas: 2
template:
spec:
containers:
- name: wordpress
image: registre-agence/wordpress-client-a:6.6
volumeMounts:
- mountPath: /var/www/html/wp-content/uploads
name: medias-persistants

Pièges rencontrés lors de la migration
- Le stockage persistant des médias WordPress (
wp-content/uploads) demande une solution de volume partagé entre les pods, faute de quoi une image téléversée n’apparaît que sur le pod qui l’a reçue - Les sessions PHP, si elles ne sont pas externalisées vers Redis, se comportent de manière incohérente derrière plusieurs répliques d’un même site
- La gestion des certificats TLS par site, automatisée via cert-manager, demande une configuration initiale plus complexe que Certbot sur un VPS classique
- Le coût en temps-ingénieur de la phase de migration elle-même, souvent sous-estimé de moitié dans la planification initiale
Ce que Kubernetes change concrètement
Une fois le cluster en place, la création d’un nouveau site client se réduit à l’application d’un manifeste YAML standardisé, contre une installation manuelle répétée sur un nouveau VPS auparavant. Les mises à jour de version PHP ou WordPress se déploient par vagues contrôlées (rolling updates), avec un retour arrière immédiat en cas de problème détecté sur les premiers pods mis à jour.
Une étape intermédiaire à ne pas sauter
Entre la gestion VPS individuelle et Kubernetes, une étape intermédiaire mérite d’être explorée avant de se lancer dans l’orchestration complète : Docker Compose combiné à un outil d’automatisation comme Ansible pour standardiser le déploiement sur plusieurs serveurs distincts, sans les concepts avancés de Kubernetes. Cette étape permet de gagner une bonne partie des bénéfices de standardisation, à un coût d’apprentissage bien moindre, et convient parfaitement à un parc entre trente et quatre-vingts sites.
- Docker mono-site : convient à moins de trente sites, gestion individuelle acceptable
- Docker Compose plus Ansible : convient entre trente et quatre-vingts sites, standardisation sans orchestrateur
- Kubernetes : devient rentable au-delà de la centaine de sites, avec une équipe formée en amont
Verdict
En dessous d’une cinquantaine de sites, Kubernetes reste une complexité disproportionnée face aux gains attendus, et une gestion VPS traditionnelle, éventuellement outillée par Ansible pour l’automatisation, suffit largement. Au-delà de la centaine de sites, la standardisation apportée par Kubernetes commence à rembourser son coût d’apprentissage initial, à condition d’accepter une phase de migration plus longue que prévu, de former l’équipe en amont plutôt que dans l’urgence, et de ne pas sauter l’étape intermédiaire qui prépare concrètement ce changement d’échelle.