Pourquoi Multisite plutôt que N instances WordPress séparées
Une agence qui gère quinze sites WordPress sur quinze installations distinctes fait face à un problème d'échelle : quinze tableaux de bord à surveiller, quinze cycles de mise à jour à coordonner, quinze configurations de serveur web à maintenir. Si un plugin critique publie un correctif de sécurité, il faut l'appliquer quinze fois — une par une, manuellement ou via des outils d'orchestration tiers.
WordPress Multisite résout ce problème à la racine. Une seule installation WordPress fait tourner un réseau de sites (en anglais : network). Chaque client dispose de son propre sous-domaine (client1.mondomaine.com, client2.mondomaine.com), de ses propres contenus, de ses propres utilisateurs et de sa propre configuration de thème. Mais les fichiers WordPress core, les plugins et les thèmes sont partagés et gérés centralement par le super administrateur du réseau.
Sur un VPS dédié, ce modèle prend tout son sens : l'isolation réseau contient la surface d'attaque, et vous gardez la main sur PHP, MariaDB et Nginx sans passer par un panneau de contrôle tiers.
Ce que vous gagnez concrètement
- Une seule mise à jour pour WordPress core, les plugins et les thèmes réseau — appliquée simultanément à tous les sites du parc.
- Un seul point d'entrée d'administration : le super admin du réseau supervise tous les sites depuis
/wp-admin/network/. - Stockage partagé des médias optionnel par site — mutualisez ou isolez selon vos contrats clients.
- Économie de ressources serveur : un seul processus PHP-FPM, une seule instance de cache d'objet, une seule connexion MariaDB à tuner.
- Onboarding accéléré : créer un sous-site revient à remplir un formulaire dans le réseau, pas à provisionner un serveur.
- Sauvegardes centralisées : un seul dump MariaDB couvre tous les sites, planifiable en une règle cron.
Prérequis : ressources VPS recommandées pour 5 à 15 sites actifs
Les ressources à prévoir dépendent du trafic et de la complexité des sites — pas du nombre d'installations. Pour un réseau de 5 à 15 sites WordPress actifs (sites vitrines ou blogs à trafic modéré, sans WooCommerce intensif), la recommandation éditoriale issue de la documentation WordPress et des bonnes pratiques Nginx/MariaDB est la suivante :
- CPU : 2 vCPU au minimum ; 4 vCPU dès que vous combinez caching de pages et trafic simultané.
- RAM : 4 Go comme plancher ; 8 Go recommandés si vous activez un cache d'objet Redis en plus de PHP-FPM.
- Stockage : SSD NVMe, 40 Go minimum pour les fichiers WordPress + médias + journaux MariaDB ; à ajuster selon le volume de médias clients.
- PHP : PHP 8.2 ou 8.3 (PHP 8.1 est en fin de support actif depuis fin 2024).
- MariaDB : 10.6 LTS ou 10.11 LTS.
- Serveur web : Nginx avec blocs server par sous-domaine et DNS wildcard.
Si votre parc dépasse 15 sites ou inclut des boutiques WooCommerce, envisagez de séparer le réseau Multisite en deux partitions ou de monter à 8 Go / 4 vCPU d'entrée.
Activer WordPress Multisite et configurer Nginx pour les sous-domaines
Préparer le DNS wildcard
Avant toute modification WordPress, ajoutez un enregistrement DNS wildcard sur votre domaine principal :
*.mondomaine.com A <IP_DE_VOTRE_VPS>Cette entrée délègue tous les sous-domaines vers votre VPS. Sans elle, les sous-sites du réseau resteront inaccessibles au navigateur, même si WordPress les crée correctement.
Autoriser le mode réseau dans wp-config.php
Éditez
wp-config.phpà la racine de votre installation WordPress et ajoutez la ligne suivante avant/* That's all, stop editing! */:define( 'WP_ALLOW_MULTISITE', true );Cette constante est la condition documentée dans la documentation officielle WordPress pour activer l'assistant d'installation réseau.
Créer le réseau depuis le tableau de bord
Connectez-vous à
/wp-admin/, rendez-vous dans Outils → Installation du réseau. Choisissez Sous-domaines (wildcard DNS obligatoire). Renseignez le titre du réseau et l'adresse e-mail d'administration, puis cliquez sur Installer.WordPress vous fournit deux blocs de code à insérer respectivement dans
wp-config.phpet dans.htaccess(Apache) ou dans votre fichier Nginx. Copiez-les exactement.Adapter la configuration Nginx pour les sous-domaines wildcard
Sur Nginx, le bloc
.htaccessfourni par WordPress n'est pas lu. Remplacez-le par un blocserverdédié. Voici la configuration minimale pour un réseau en sous-domaines :server { listen 80; server_name mondomaine.com *.mondomaine.com; root /var/www/wordpress; index index.php; # Multisite subdomain rewrite if (!-e $request_filename) { rewrite /wp-admin$ $scheme://$host/wp-admin/ permanent; rewrite ^(/[^/]+)?(/wp-.*) $2 last; rewrite ^(/[^/]+)?(/.*\.php) $2 last; } location / { try_files $uri $uri/ /index.php?$args; } location ~ \.php$ { fastcgi_pass unix:/run/php/php8.3-fpm.sock; fastcgi_index index.php; include fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; } }Rechargez Nginx :
systemctl reload nginx. Passez ensuite à HTTPS en générant un certificat wildcard avec Certbot et le challenge DNS-01 — un certificat SAN*.mondomaine.comcouvre tous les sous-sites du réseau.Finaliser la configuration WordPress Multisite dans wp-config.php
Ajoutez dans
wp-config.phples constantes fournies par l'assistant (adaptez les valeurs à votre installation) :define( 'MULTISITE', true ); define( 'SUBDOMAIN_INSTALL', true ); define( 'DOMAIN_CURRENT_SITE', 'mondomaine.com' ); define( 'PATH_CURRENT_SITE', '/' ); define( 'SITE_ID_CURRENT_SITE', 1 ); define( 'BLOG_ID_CURRENT_SITE', 1 );Déconnectez-vous puis reconnectez-vous. Le tableau de bord affiche désormais le menu Réseau en barre d'administration. Depuis Réseau → Sites → Ajouter, créez votre premier sous-site client :
client1.mondomaine.com.Activer les plugins réseau et assigner les thèmes
Dans Réseau → Extensions, activez les plugins pour l'ensemble du réseau (
Activer sur le réseau) ou laissez les administrateurs de sous-sites les activer eux-mêmes. Les thèmes fonctionnent de la même façon : le super admin les rend disponibles, chaque sous-site choisit le sien.Note importante : certains plugins ne supportent pas le mode réseau. Vérifiez la compatibilité dans la documentation du plugin avant de l'activer sur le réseau — un plugin incompatible peut bloquer le tableau de bord de tous les sous-sites simultanément.
Multisite vs instances WordPress séparées : tableau comparatif
Faites défiler le tableau
| Critère | WordPress Multisite | Instances séparées |
|---|---|---|
| Mise à jour WordPress core | 1 opération pour N sites | N opérations manuelles |
| Mise à jour d'un plugin | 1 opération réseau | N opérations, risque de désynchronisation |
| Isolation des données client | Partielle (même base MariaDB, préfixes distincts) | Totale (bases distinctes, processus PHP distincts) |
| Stockage médias | Partagé par défaut, isolable par plugin | Isolé nativement |
| Ressources serveur | Mutualisées — économie de RAM et CPU | Additives — chaque instance consomme sa part |
| Plugin incompatible réseau | Bloque potentiellement tous les sites | N'affecte qu'une instance |
| Onboarding d'un nouveau site | Formulaire dans le réseau — secondes | Provisionnement complet — minutes à heures |
| Certificat SSL wildcard | 1 certificat `*.mondomaine.com` | 1 certificat par domaine client |
Sécurité Multisite sur VPS : contenir l'impact d'une faille
L'objection la plus courante sur WordPress Multisite est juste : si un plugin vulnérable est compromis, la surface d'attaque potentielle couvre l'ensemble du réseau, pas un seul site. Sur un VPS dédié, plusieurs mesures contiennent cet impact :
Sauvegardes quotidiennes automatisées. Un dump MariaDB planifié chaque nuit (cron + mysqldump ou mariabackup) vous donne un point de restauration récent pour chaque sous-site. Stockez les dumps hors du VPS — sur un bucket S3 compatible ou un volume distant.
Firewall applicatif. Un WAF Nginx (ModSecurity ou règles OWASP) filtre les requêtes malveillantes avant qu'elles atteignent PHP. Combinez-le avec fail2ban pour bannir les IP qui tentent des force-brute sur /wp-login.php.
Mises à jour sans délai. La force de Multisite — une mise à jour pour tout le parc — est aussi votre principale défense : appliquez les correctifs de sécurité WordPress et des plugins le jour de leur publication. Sans Multisite, le délai de mise à jour d'une instance oubliée est la faille la plus exploitée.
Super admin limité. Le compte super administrateur du réseau a des droits sur tous les sites. Utilisez une authentification à deux facteurs sur ce compte et créez des comptes administrateurs de sous-site distincts pour chaque client.
Dépannage : trois erreurs fréquentes sur un réseau WordPress Multisite
1. Plugin signalé comme « incompatible avec le mode réseau ».
Certains plugins vérifient explicitement si WordPress tourne en mode Multisite et refusent de s'activer sur le réseau. La cause est souvent une utilisation de $wpdb->blogid ou d'options stockées de façon incompatible avec les tables préfixées de chaque sous-site. Solution : vérifiez les issues GitHub du plugin, cherchez une alternative compatible, ou activez le plugin uniquement sur les sous-sites qui en ont besoin (si le plugin le permet) plutôt qu'au niveau réseau.
2. Page d'administration réseau inaccessible (/wp-admin/network/ redirige vers le tableau de bord standard).
Le super admin n'est pas le même utilisateur que l'administrateur du site principal. Lors de la création du réseau, WordPress ajoute un flag super_admin à l'utilisateur actif. Si vous avez créé le réseau avec un compte, puis vous connectez avec un autre, ce second compte ne voit pas le menu réseau. Vérifiez dans MariaDB :
SELECT meta_value FROM wp_usermeta
WHERE meta_key = 'wp_user_level'
AND user_id = <ID_DE_VOTRE_COMPTE>;Pour élever un utilisateur au rang de super admin : UPDATE wp_sitemeta SET meta_value = ... ou utilisez la fonction grant_super_admin( $user_id ) depuis un fichier mu-plugins.
3. Sous-domaines inaccessibles : le DNS wildcard ne se propage pas immédiatement.
Après avoir ajouté *.mondomaine.com A <IP>, le TTL de l'enregistrement détermine la durée avant propagation. Pendant ce délai, les sous-sites créés dans le réseau répondent avec une erreur DNS côté navigateur — WordPress les a bien créés, mais le résolveur ne connaît pas encore le sous-domaine. Si vous travaillez en local avec un VPS de développement, ajoutez une entrée dans /etc/hosts sur votre poste pour chaque sous-domaine à tester : <IP_VPS> client1.mondomaine.com.
Un quatrième cas survient avec les configurations mixtes www / sans-www : si mondomaine.com et www.mondomaine.com pointent tous deux vers le VPS, assurez-vous que DOMAIN_CURRENT_SITE dans wp-config.php correspond exactement au domaine principal sans préfixe www, et que Nginx redirige la forme www vers la forme canonique avant de passer la requête à WordPress.
Migrer des sites existants vers un réseau Multisite
Si vous gérez déjà des sites WordPress séparés et souhaitez les regrouper dans un réseau Multisite, l'outil WordPress Importer (greffon officiel) exporte les contenus, commentaires et utilisateurs depuis chaque instance source, puis les importe dans un sous-site du réseau.
Trois points de vigilance avant de migrer :
- Les uploads ne migrent pas automatiquement. Copiez le dossier wp-content/uploads/ de chaque site source vers wp-content/uploads/sites/<ID>/ dans le réseau (l'ID est assigné par WordPress à la création du sous-site).
- Vérifiez la compatibilité des plugins réseau avant la bascule : un plugin actif sur l'ancien site peut ne pas fonctionner en mode réseau. Listez les plugins de chaque site source et croisez avec la liste des plugins réseau disponibles.
- Testez les redirections de domaine. Si le site migré avait son propre domaine (www.client1.com), configurez le module WordPress MU Domain Mapping ou la fonctionnalité native de domaine personnalisé pour que client1.mondomaine.com redirige vers www.client1.com — ou inversement selon votre choix.
Mise en production : étapes de validation avant d'ouvrir à vos clients
Avant de migrer vos premiers sites clients sur le réseau, passez en revue ces points :
- Testez la création d'un sous-site depuis client1.mondomaine.com et vérifiez qu'il est accessible depuis un navigateur externe.
- Vérifiez que le certificat wildcard couvre bien *.mondomaine.com : openssl s_client -connect client1.mondomaine.com:443 -servername client1.mondomaine.com | grep subject.
- Simulez une mise à jour de plugin réseau et vérifiez que tous les sous-sites restent fonctionnels.
- Planifiez et testez la restauration d'un sous-site à partir d'un dump MariaDB : la restauration non testée n'est pas une sauvegarde.
- Documentez la procédure d'onboarding à destination de vos clients : URL d'administration, identifiants, droits accordés à leur compte administrateur de sous-site.
Un VPS ServOrbit dimensionné pour votre parc WordPress vous donne la main sur toute la pile — PHP, MariaDB, Nginx, sauvegardes — sans couche d'abstraction qui cache les erreurs.
