Comparons deux chiffres : plus de deux heures pour préparer un nouveau VPS de démonstration avant, six minutes pour lancer un conteneur WordPress prêt à présenter aujourd’hui. Cet écart résume à lui seul pourquoi une agence qui multiplie les environnements de démonstration pour ses prospects a fini par abandonner le VPS dédié par démo au profit d’une flotte de conteneurs Docker sur une infrastructure mutualisée en interne.
Chaque commercial demandait auparavant un environnement propre pour chaque rendez-vous prospect : un thème pré-installé, quelques contenus de démonstration, parfois une extension spécifique au secteur d’activité du prospect. Multiplier les VPS pour répondre à ce rythme devenait ingérable, tant en coût qu’en administration système.
Le problème du VPS par démo
Chaque VPS dédié impliquait un provisionnement complet : installation du serveur web, de PHP, de MySQL, configuration TLS, puis installation de WordPress et import du contenu de démonstration. Même scripté, ce processus prenait un temps incompressible et laissait, une fois la démo terminée, un serveur entier à surveiller, mettre à jour et sécuriser pour un usage qui ne durait parfois que quelques jours.
Le coût cumulé de dizaines de VPS actifs en permanence, la plupart largement sous-utilisés en dehors des créneaux de démo, a fini par peser lourd dans le budget infrastructure, sans bénéfice proportionnel.
Le passage à Docker
La bascule s’est faite vers une image Docker WordPress standard, associée à un conteneur MariaDB par démo, orchestrés via Docker Compose sur un serveur hôte suffisamment dimensionné pour accueillir plusieurs dizaines de conteneurs en parallèle.
services:
wordpress:
image: wordpress:5.7-php7.4
environment:
WORDPRESS_DB_HOST: db
WORDPRESS_DB_NAME: demo_client
ports:
- "8421:80"
volumes:
- ./contenu-demo:/var/www/html/wp-content
db:
image: mariadb:10.5
environment:
MYSQL_DATABASE: demo_client
MYSQL_ROOT_PASSWORD: ${DB_ROOT_PASSWORD}
Un script interne génère ce fichier à partir d’un modèle, attribue un port disponible, importe un jeu de contenu de démonstration adapté au secteur du prospect, puis expose le tout derrière un sous-domaine dédié via un reverse proxy nginx unique pour l’ensemble du parc.
Ce que cela a changé concrètement
- Création d’une démo en quelques minutes, contre plusieurs heures avec un VPS complet
- Suppression immédiate du conteneur en fin de démo, sans trace résiduelle à nettoyer
- Un seul serveur hôte à maintenir à jour, plutôt qu’une flotte de VPS disparates
- Des démos reproductibles à l’identique, utile pour comparer deux configurations devant un prospect
Les limites rencontrées en production
La contrepartie est apparue lors des périodes de forte activité commerciale, avec plusieurs dizaines de démos actives simultanément lors d’un salon professionnel : la charge mémoire cumulée de tous les conteneurs MariaDB actifs en parallèle a fini par saturer le serveur hôte, chaque instance de base de données réservant sa propre mémoire tampon sans mutualisation possible entre conteneurs.
Un ajustement a consisté à limiter explicitement la mémoire allouée à chaque conteneur MariaDB via les options de Docker, au prix d’une légère perte de réactivité sur les démos les plus chargées en contenu.
docker run --memory="256m" --memory-swap="256m" mariadb:10.5
Un conteneur Docker n’est pas gratuit en ressources : c’est un environnement isolé, pas un processus léger. Sous-dimensionner la mémoire du serveur hôte revient exactement au même problème que multiplier les VPS, en pire, car les limites deviennent moins visibles individuellement.
Ce que Docker ne remplace pas
Cette approche reste limitée aux environnements de démonstration et de test : aucun de ces conteneurs n’est destiné à héberger un site client en production dans cette organisation. Un déploiement de production continue de suivre un provisionnement classique sur VPS ou hébergement infogéré, avec les garanties de sauvegarde et de supervision que la conteneurisation légère de démos ne cherche pas à offrir.
En résumé
Conteneuriser le parc de démonstrations WordPress a fait gagner un temps considérable sur la préparation de chaque rendez-vous commercial et réduit le nombre de serveurs à administrer au quotidien. La limite rencontrée, la charge mémoire cumulée en cas de forte activité simultanée, se gère par un dimensionnement prudent du serveur hôte et des quotas de mémoire par conteneur, sans remettre en cause l’intérêt global de l’approche pour ce cas d’usage précis.
