# « Kubernetes est toujours excessif pour WordPress » : à nuancer vraiment > L'argument tient pour un site vitrine isolé, beaucoup moins pour un parc de centaines de sites avec des pics de charge coordonnés. Des critères de décision plutôt qu'un verdict universel. - Auteur : Clément Hadrot - Publié le : 2023-07-14 - Mis à jour le : 2023-07-14 - Catégorie : Outils & workflow - URL : https://wpmoderne.dev.wordpress-developpement.fr/outils/kubernetes-toujours-excessif-nuance/ ## L’essentiel - L'argument anti-Kubernetes vaut surtout pour un site isolé à trafic stable - Un parc nombreux avec des pics coordonnés change complètement le calcul - Trois critères objectifs remplacent avantageusement un verdict tranché « Kubernetes, c'est trop pour un site WordPress » revient dans presque toute discussion technique sur l'hébergement WordPress dès que Kubernetes est mentionné. L'affirmation n'est pas fausse, mais elle est incomplète : elle est vraie pour un cas précis — celui du site isolé — et devient contestable dès que le contexte change d'échelle. Cette nuance mérite d'être posée explicitement plutôt que balayée par une formule définitive, parce que la décision d'adopter ou de refuser Kubernetes engage des mois de travail d'infrastructure et des choix difficiles à défaire ensuite. Un raisonnement fondé sur des critères objectifs sert mieux la décision qu'une opinion tranchée, quel que soit le sens de cette opinion. ## Ce que dit l'argument, et pourquoi il tient dans un cas précis L'argument anti-Kubernetes repose sur un constat juste : la complexité opérationnelle d'un cluster Kubernetes — configuration des ressources, gestion des volumes persistants, mise à jour du cluster lui-même, courbe d'apprentissage de l'équipe — dépasse largement les besoins d'un site WordPress isolé à trafic stable et prévisible. Pour ce cas, un serveur unique correctement dimensionné, avec une sauvegarde automatisée et une surveillance basique, répond au besoin avec une fraction de l'effort d'exploitation d'un cluster. Le raisonnement reste valable tant que l'unité de décision est « un site ». Il cesse d'être pertinent dès que l'unité de décision devient « un parc de sites », parce que les problèmes à résoudre changent de nature : ce n'est plus la disponibilité d'un site isolé qui compte, mais la capacité à répartir dynamiquement des ressources entre des centaines de sites dont la charge varie indépendamment les uns des autres. ## Ce qui change à l'échelle d'un parc de centaines de sites Sur un parc de trois cents sites hébergés pour le compte de collectivités locales, la charge de chaque site pris isolément est souvent faible, mais la somme des pics — une mise en ligne d'annonce municipale relayée localement, un afflux de candidatures pour un poste, une alerte météo qui pousse les habitants vers le site d'une commune — devient significative et surtout imprévisible à l'échelle individuelle. Provisionner chaque site pour son pic théorique individuellement gaspillerait des ressources considérables la plupart du temps ; Kubernetes, via son ordonnanceur et ses mécanismes de mise à l'échelle automatique, permet de mutualiser cette marge entre l'ensemble des sites plutôt que de la dupliquer autant de fois qu'il y a de sites. > L'essentiel à retenir : L'argument anti-Kubernetes vaut surtout pour un site isolé à trafic stable ; Un parc nombreux avec des pics coordonnés change complètement le calcul ; Trois critères objectifs remplacent avantageusement un verdict tranché ## Trois critères pour trancher, plutôt qu'un verdict Trois questions permettent de situer un projet sur ce spectre sans se fier à une opinion générale : 1. **Combien de sites indépendants faut-il opérer simultanément ?** En dessous d'une dizaine, la mutualisation de ressources apporte peu ; au-delà de plusieurs dizaines, elle devient significative. 2. **Les pics de charge sont-ils corrélés ou indépendants ?** Des pics indépendants entre sites se compensent statistiquement mieux dans un cluster mutualisé qu'un pic unique et prévisible sur un site isolé. 3. **L'équipe dispose-t-elle déjà de la compétence Kubernetes, ou faut-il l'acquérir spécifiquement pour ce projet ?** Le coût d'apprentissage compte autant que le coût d'exploitation une fois le cluster en place. ## Un contre-exemple qui confirme la règle Un site vitrine isolé migré vers Kubernetes « par principe d'architecture moderne », sans second projet à mutualiser derrière lui, a effectivement représenté un surcoût d'exploitation net par rapport à un serveur classique, sans bénéfice mesurable en disponibilité ni en performance. Ce cas confirme que l'argument initial reste valide dans son contexte d'origine : c'est bien l'échelle du parc, et non une préférence esthétique pour telle ou telle technologie, qui doit motiver la décision. ## Ce que Kubernetes ne résout pas non plus à cette échelle Même sur un parc de plusieurs centaines de sites, Kubernetes ne dispense pas de repenser certains aspects spécifiques à WordPress : la gestion des médias uploadés doit s'appuyer sur un stockage partagé plutôt que sur le système de fichiers local d'un pod éphémère, et la base de données de chaque site reste généralement hébergée en dehors du cluster, sur un service géré dédié. Adopter Kubernetes sans traiter ces deux points reproduit, à l'intérieur du cluster, les mêmes limites qu'un hébergement classique mal conçu. ## Notre verdict L'argument « Kubernetes est excessif pour WordPress » n'est ni vrai ni faux dans l'absolu : il dépend entièrement de l'unité de décision considérée. Vrai pour un site isolé, il s'inverse progressivement à mesure que le nombre de sites gérés simultanément augmente et que leurs pics de charge deviennent statistiquement indépendants. Les trois critères présentés ici remplacent utilement un débat d'opinion par une décision fondée sur la réalité du parc à opérer.