Combien de clubs sportifs amateurs peuvent partager le même serveur sans se marcher dessus ? Six associations sans budget individuel pour de l’hébergement dédié, chacune avec son propre site vitrine, ses propres inscriptions et son propre calendrier de matchs, tiennent sur un unique VPS d’entrée de gamme si l’architecture est pensée dès le départ pour l’isolation plutôt que pour la facilité d’installation.
Cette situation est fréquente pour un développeur sollicité bénévolement ou à tarif réduit par plusieurs structures amateures d’une même région. Aucune de ces associations ne peut financer seule un hébergement individuel, mais la somme de leurs besoins réels tient largement sur une machine modeste, à condition d’organiser correctement la cohabitation.
Le choix : plusieurs installations plutôt qu’un multisite
Le réseau multisite de WordPress, souvent proposé par réflexe pour héberger plusieurs sites sur une seule installation, ne convient pas bien ici : les clubs n’ont aucun lien entre eux, chacun doit pouvoir changer d’hébergeur ou de responsable technique de façon indépendante, sans dépendre de la survie des cinq autres associations. Six installations WordPress séparées, isolées les unes des autres, offrent cette indépendance tout en partageant la même machine physique.
Arborescence du serveur
Chaque club dispose de son propre répertoire, de son propre utilisateur système et de sa propre configuration PHP-FPM, ce qui limite l’impact d’un incident sur un site aux autres sites hébergés :
/var/www/
├── club-foot-nord/
│ ├── web/ (installation WordPress complète)
│ └── logs/
├── club-basket-est/
│ ├── web/
│ └── logs/
├── club-tennis-sud/
│ ├── web/
│ └── logs/
├── club-natation-ouest/
│ ├── web/
│ └── logs/
├── club-rugby-centre/
│ ├── web/
│ └── logs/
└── club-handball-vallee/
├── web/
└── logs/Une base de données partagée, des préfixes distincts
Faire tourner six instances MySQL séparées gaspillerait la mémoire disponible sur un VPS d’entrée de gamme. Une seule instance MySQL suffit, avec une base par club et un utilisateur MySQL dédié disposant de droits strictement limités à sa propre base, jamais un compte administrateur partagé entre tous les sites.
- Un utilisateur MySQL par club, avec des droits restreints à sa seule base de données.
- Une configuration PHP-FPM par club, avec ses propres limites de mémoire, pour qu’un pic de trafic sur un site n’affame pas les autres.
- Un virtual host Nginx distinct par domaine, chacun pointant vers son propre répertoire racine.
Sauvegardes centralisées, restauration indépendante
La sauvegarde profite en revanche de la mutualisation : un script unique, exécuté une fois par nuit via une tâche planifiée, exporte successivement chaque base de données avec wp db export lancé dans le contexte de chaque installation, puis archive l’ensemble vers un espace de stockage externe. La restauration reste indépendante club par club, chaque archive étant nommée et datée séparément.
Ce que cette architecture ne couvre pas
Cette organisation ne dit rien de la façon dont les clubs se partagent le coût du serveur entre eux, une question purement organisationnelle qui dépasse le champ technique de cet article. Elle suppose aussi que le développeur qui la met en place reste disponible en cas d’incident : la mutualisation réduit le coût, elle ne réduit pas le besoin de maintenance.
Mutualiser un serveur, ce n’est pas économiser sur l’isolation entre projets : c’est économiser sur ce qui peut vraiment être partagé sans risque.
En résumé
Pour des clubs sportifs amateurs sans budget individuel, une infrastructure mutualisée légère tient sur un seul VPS à condition de séparer clairement ce qui doit rester isolé (fichiers, comptes système, configuration PHP) de ce qui peut raisonnablement être partagé (l’instance de base de données, la tâche de sauvegarde). Cette architecture a tourné sans incident majeur sur plusieurs saisons sportives consécutives, avec un coût mensuel réparti qui reste accessible à des structures sans budget informatique dédié.
