# Kubernetes abandonné pour six sites WordPress : pourquoi nous sommes revenus

> Retour d'expérience sur les coûts opérationnels réels qui ont fini par dépasser le bénéfice attendu pour une charge finalement modeste.

- Auteur : Clément Hadrot
- Publié le : 2026-06-14
- Mis à jour le : 2026-06-14
- Catégorie : Outils & workflow
- URL : https://wpmoderne.dev.wordpress-developpement.fr/outils/kubernetes-abandonne-six-sites-wordpress/

## L’essentiel

- Le cluster coûtait plus cher en temps humain qu'en facture d'hébergement
- Aucun des six sites ne justifiait réellement l'auto-scaling promis
- Le retour vers des VPS classiques a divisé le temps d'administration par quatre

Ce texte n'est pas un procès de Kubernetes en général, dont la pertinence a déjà été discutée ailleurs sur ce blog dans un cadre plus large. Il s'agit d'un retour d'expérience précis, sur un cluster monté pour héberger six sites WordPress de clients de taille moyenne, avec un trafic cumulé qui n'a jamais justifié, a posteriori, la complexité opérationnelle assumée pendant dix-huit mois.

La décision initiale de migrer ces six sites vers un cluster Kubernetes managé reposait sur une promesse séduisante : une infrastructure capable d'absorber automatiquement des pics de trafic imprévisibles, avec une isolation propre entre les sites via des namespaces distincts, et une supervision unifiée. Dix-huit mois plus tard, l'agence est revenue à des VPS traditionnels pour ces six sites précis.

## Ce que le cluster devait apporter

Sur le papier, l'architecture retenue distribuait chaque site dans son propre namespace, avec des ressources dimensionnées individuellement et une capacité d'auto-scaling horizontal en cas de pic de trafic, par exemple lors d'une campagne publicitaire ponctuelle pour l'un des clients concernés. La promesse : ne plus jamais avoir à intervenir manuellement pour absorber un pic, et optimiser l'utilisation globale des ressources en mutualisant la capacité du cluster entre les six sites.

## Ce qui s'est réellement passé

Sur les dix-huit mois d'exploitation, l'auto-scaling horizontal ne s'est déclenché réellement que trois fois, à chaque fois pour un pic de trafic largement absorbable par un VPS correctement dimensionné dès le départ. Le trafic cumulé des six sites, en dehors de ces pics ponctuels, restait modeste : quelques milliers de visites quotidiennes au total, un volume qu'un unique VPS de taille moyenne aurait géré sans effort particulier.

### Le coût caché : la maintenance du cluster lui-même

La charge de travail réelle ne venait pas des sites eux-mêmes, mais du cluster qui les hébergeait. Les mises à jour de version de Kubernetes, à effectuer régulièrement pour rester dans une fenêtre de support, demandaient une planification et des tests de non-régression à chaque fois. La configuration des Ingress, des certificats TLS gérés par cert-manager, des politiques réseau entre namespaces, chacun de ces éléments représentait une surface de configuration supplémentaire à comprendre et à maintenir, sans rapport direct avec les besoins réels de six sites WordPress somme toute classiques.

> L'essentiel à retenir : Le cluster coûtait plus cher en temps humain qu'en facture d'hébergement ; Aucun des six sites ne justifiait réellement l'auto-scaling promis ; Le retour vers des VPS classiques a divisé le temps d'administration par quatre

## Chiffrer le temps d'administration

| Période | Temps d'administration mensuel moyen |
| --- | --- |
| Sur Kubernetes (18 mois) | Environ 9 heures |
| Sur VPS classiques (depuis le retour) | Environ 2 heures |

Ce chiffre de neuf heures mensuelles sur Kubernetes inclut la veille de sécurité sur les composants du cluster lui-même (kubelet, etcd, les contrôleurs d'ingress), la gestion des montées de version, et le temps de diagnostic disproportionné lors des rares incidents, où la complexité de la stack rendait l'identification de la cause racine nettement plus longue que sur une infrastructure plus simple.

## L'incident qui a précipité la décision

Un incident de mémoire insuffisante sur un pod WordPress, dû à une extension mal optimisée sur l'un des six sites, a déclenché une cascade d'évictions de pods par le contrôleur Kubernetes, affectant temporairement les autres sites du même nœud alors qu'ils n'avaient strictement rien à voir avec le problème d'origine. Sur une architecture VPS traditionnelle, avec une isolation stricte par machine, cet incident serait resté cantonné au site fautif. Cet épisode a mis en lumière un couplage inattendu entre les sites, contraire à l'objectif initial d'isolation propre par namespace.

## Le retour aux VPS

La migration retour a réparti les six sites sur deux VPS dédiés, dimensionnés confortablement au regard du trafic réel observé, avec un déploiement classique via un pipeline GitHub Actions et un serveur Nginx configuré manuellement pour chaque site. Cette architecture, nettement plus simple à comprendre pour n'importe quel membre de l'équipe, a immédiatement réduit le temps de maintenance mensuel, sans dégradation perceptible pour les clients concernés.

> Une infrastructure capable d'absorber une charge que le site ne connaîtra jamais ne rapporte rien, elle coûte simplement le temps qu'il faut pour la comprendre et la maintenir.

## Ce que ce retour d'expérience ne dit pas

Ce retour en arrière ne condamne pas Kubernetes pour tout usage : sur d'autres charges de l'agence, notamment les environnements de preview éphémères par pull request qui bénéficient réellement de la flexibilité d'un cluster déjà en place pour d'autres besoins, l'orchestrateur reste pertinent. La leçon retenue porte spécifiquement sur l'adéquation entre la complexité d'une infrastructure et le besoin réel qu'elle doit couvrir, pas sur une condamnation générale de l'outil.

## Notre verdict

Pour six sites WordPress à trafic modeste et prévisible, la promesse d'auto-scaling de Kubernetes ne s'est jamais matérialisée en bénéfice concret, alors que son coût opérationnel réel, en temps humain plutôt qu'en facture d'hébergement, s'est révélé disproportionné dès les premiers mois. Le retour à des VPS classiques a divisé par quatre le temps d'administration mensuel, sans aucune perte perceptible de disponibilité pour les sites concernés.