# Notre bascule de Kubernetes vers des VPS pour six sites e-learning stables

> Six sites e-learning au trafic parfaitement stable tournaient sur un cluster Kubernetes surdimensionné. Pourquoi nous sommes revenus à de simples VPS.

- Auteur : Clément Hadrot
- Publié le : 2026-01-27
- Mis à jour le : 2026-01-27
- Catégorie : Outils & workflow
- URL : https://wpmoderne.dev.wordpress-developpement.fr/outils/bascule-kubernetes-vps-six-sites-elearning-stables/

## L’essentiel

- Un trafic stable ne justifie pas une orchestration pensée pour l'élasticité
- Le cluster coûtait trois fois le prix des VPS pour un service équivalent
- La simplicité opérationnelle a plus de valeur qu'un savoir-faire Kubernetes inutilisé

Six sites WordPress d'e-learning, un trafic parfaitement prévisible d'une session de formation à l'autre, et pourtant un cluster Kubernetes complet derrière, avec ses nœuds redondants, son ingress controller et son autoscaler configuré pour absorber des pics qui ne se sont jamais produits en deux ans d'exploitation. Ce texte documente pourquoi cette infrastructure, choisie initialement par anticipation d'une croissance qui n'a jamais eu lieu, a fini par coûter davantage qu'elle n'apportait, et ce qui l'a remplacée.

Il ne s'agit pas d'un procès de Kubernetes en tant que tel, mais d'un retour honnête sur un choix de dimensionnement fait trop tôt, pour un usage qui ne le justifiait pas.

## Pourquoi Kubernetes avait été choisi au départ

Au lancement de ces six plateformes e-learning pour un client du secteur de la formation professionnelle, l'hypothèse de départ prévoyait une croissance rapide du nombre d'apprenants inscrits, avec des pics de charge lors des sessions de formation en direct. Kubernetes semblait alors un choix raisonnable pour absorber cette élasticité anticipée, avec un autoscaler capable d'ajouter des ressources à la demande sans intervention manuelle.

## Ce que deux ans d'exploitation réelle ont révélé

> L'essentiel à retenir : Un trafic stable ne justifie pas une orchestration pensée pour l'élasticité ; Le cluster coûtait trois fois le prix des VPS pour un service équivalent ; La simplicité opérationnelle a plus de valeur qu'un savoir-faire Kubernetes inutilisé

En pratique, le trafic de ces six plateformes s'est révélé remarquablement stable d'une session à l'autre : les sessions de formation étant planifiées et le nombre d'apprenants par cohorte connu à l'avance, aucun pic imprévu n'est jamais survenu sur la période observée. L'autoscaler configuré pour ce cluster n'a déclenché un ajustement à la hausse qu'à deux reprises en deux ans, dans les deux cas pour un gain marginal rapidement redescendu à la normale.

Pendant ce temps, le coût mensuel du cluster — trois nœuds redondants, le coût de gestion du plan de contrôle chez le fournisseur cloud, l'ingress controller dédié — représentait environ trois fois ce qu'aurait coûté une infrastructure de VPS classiques dimensionnée pour le même trafic réel observé.

## La bascule vers des VPS classiques

La nouvelle architecture retenue repose sur deux VPS dédiés : un serveur principal hébergeant l'ensemble des six sites via Docker Compose, avec Nginx en reverse proxy, et un second serveur de secours prêt à prendre le relais en cas d'incident, synchronisé par une réplication de base de données régulière. Cette configuration, bien plus simple à comprendre pour l'ensemble de l'équipe, ne nécessite plus de connaissance approfondie de Kubernetes pour être maintenue au quotidien.

```
services:
  site-formation-a:
    image: wordpress:6.8-php8.3
    restart: unless-stopped
    volumes:
      - ./sites/formation-a:/var/www/html
  site-formation-b:
    image: wordpress:6.8-php8.3
    restart: unless-stopped
    volumes:
      - ./sites/formation-b:/var/www/html
```

## Ce que cette simplification a coûté malgré tout

La disponibilité garantie par Kubernetes en cas de panne d'un nœud n'a pas d'équivalent aussi automatique sur une architecture à deux VPS : en cas d'incident sur le serveur principal, un basculement manuel reste nécessaire vers le serveur de secours, avec une interruption de service de quelques minutes plutôt qu'une bascule transparente. Pour ce client, dont les sessions de formation sont planifiées à des horaires connus à l'avance, ce compromis a été jugé acceptable au regard de l'économie réalisée.

- Coût mensuel divisé par trois par rapport au cluster Kubernetes
- Temps de formation de l'équipe pour maintenir l'infrastructure réduit de plusieurs semaines à quelques jours
- Basculement en cas d'incident désormais manuel, avec une interruption de quelques minutes acceptée par le client

> Une infrastructure pensée pour l'élasticité qui ne connaît jamais de pic ne protège de rien, elle coûte simplement plus cher chaque mois.

## En résumé

Kubernetes n'était pas un mauvais choix technique en soi, il était disproportionné pour un trafic aussi stable que celui de ces six plateformes e-learning. Revenir à des VPS classiques a réduit le coût d'exploitation par trois et simplifié la maintenance quotidienne, au prix d'un basculement manuel en cas d'incident que le contexte de ce client rendait acceptable.