Multisite de 500 sites d’écoles : l’architecture serveur qui tient la charge

500 établissements, un seul réseau WordPress Multisite, une même base de données MySQL au centre de tout : cette architecture, retenue par un rectorat pour mutualiser l’hébergement de son parc d’écoles, pose une question d’ingénierie précise avant même de penser à la gestion éditoriale du réseau, qui ne fait pas l’objet de cet article. Comment dimensionner un serveur pour que la panne ou le pic de charge d’un seul établissement ne fasse jamais tomber les 499 autres ?

Le multisite natif de WordPress mutualise par défaut une seule base de données et un seul jeu de fichiers pour l’ensemble du réseau, ce qui simplifie la gestion mais concentre aussi tous les risques au même endroit si l’architecture serveur sous-jacente n’est pas pensée pour isoler les ressources entre sous-sites.

Le premier goulot : la base de données partagée

Chaque table WordPress standard est dupliquée par sous-site (wp_2_posts, wp_2_options, et ainsi de suite pour chacun des 500 établissements), mais toutes ces tables résident dans la même base de données MySQL, servie par le même moteur. Une école qui importe massivement du contenu, ou dont un plugin mal codé génère des requêtes lentes, consomme des ressources MySQL qui affectent potentiellement l’ensemble du réseau, tables et écoles confondues.

SHOW TABLE STATUS LIKE 'wp_%_posts';
# Repérer les tables anormalement volumineuses par rapport
# à la moyenne du réseau, signe d'un usage atypique à surveiller

Architecture retenue : isolation par groupe d’établissements

Plutôt qu’un réseau unique de 500 sites sur une seule paire serveur applicatif plus base de données, l’architecture retenue répartit les établissements en dix groupes de cinquante, chaque groupe disposant de son propre pool PHP-FPM dédié et de sa propre instance MariaDB, le tout derrière un répartiteur de charge commun qui route chaque requête vers le bon groupe selon le sous-domaine demandé.

republique-academie/
├── groupe-01/  (écoles 001-050)
│   ├── php-fpm pool dédié (pm.max_children=40)
│   └── mariadb-01 (base isolée)
├── groupe-02/  (écoles 051-100)
│   ├── php-fpm pool dédié
│   └── mariadb-02
├── ...
└── groupe-10/  (écoles 451-500)

Cette répartition limite l’impact d’un incident à cinquante établissements maximum plutôt qu’à l’ensemble du réseau, tout en conservant une gestion mutualisée simple pour l’équipe académique, qui continue de gérer un nombre restreint d’instances plutôt que cinq cents installations totalement indépendantes.

Les limites du multisite à cette échelle

• La table wp_users reste partagée par défaut à l’échelle du réseau entier, ce qui peut poser une question de séparation des comptes enseignants entre établissements si elle n’est pas traitée en amont
• Les mises à jour d’extensions s’appliquent au réseau entier simultanément, ce qui impose de tester chaque mise à jour sur un environnement de préproduction représentatif avant application, la casse d’une extension touchant potentiellement les 500 sites d’un coup
• La sauvegarde d’un réseau aussi large doit être pensée par groupe, pas en un bloc unique, pour limiter la fenêtre de sauvegarde et permettre une restauration ciblée sur un seul groupe en cas de besoin

Le rôle du répartiteur de charge

Le répartiteur de charge en frontal ne se contente pas de distribuer les requêtes : il route chaque sous-domaine vers le bon groupe de serveurs applicatifs, en fonction d’une table de correspondance mise à jour à chaque ajout d’un nouvel établissement au réseau. Cette table de routage constitue un point sensible de l’architecture, qui doit être répliquée et supervisée avec la même rigueur que les serveurs applicatifs eux-mêmes.

Sur un réseau multisite de cette envergure, la vraie question n’est jamais « combien de sites peut supporter WordPress », mais « combien de sites peut supporter la base de données unique sans dégrader les autres » : c’est ce second point qui dimensionne réellement l’architecture.

En résumé

Héberger cinq cents établissements scolaires sur un réseau WordPress Multisite tient la charge à condition de renoncer à l’architecture la plus simple, une seule base de données et un seul pool applicatif pour tout le réseau, au profit d’une répartition en groupes isolés, chacun avec ses propres ressources dédiées. Cette isolation partielle limite l’impact d’un incident localisé à un sous-ensemble d’établissements, sans renoncer aux bénéfices de mutualisation qui justifient le choix du multisite pour un parc de cette taille.