Une agence veut héberger quinze microsites clients sur une seule installation WordPress. Le développeur active le multisite un vendredi après-midi. Lundi, le premier client demande son propre domaine, un plugin e-commerce incompatible et une restauration « seulement de son site ». Trois problèmes que le multisite peut résoudre — mais seulement si les décisions sont prises avant la mise en ligne, pas après.
Multisite n'est pas « plusieurs WordPress en un ». C'est une base, un code, des tables partagées — avec des conséquences sur SSL, performance et responsabilité.
Architecture : sous-domaines, sous-dossiers ou domaines mappés
| Mode | Exemple | Avantages | Contraintes |
|---|---|---|---|
| Sous-domaines | client1.agence.fr | Branding clair | Wildcard DNS + SSL |
| Sous-dossiers | agence.fr/client1 | Setup rapide | URLs moins propres |
| Domaines mappés | client1.com | SEO client | Plugin mapping, certificats |
Le choix est difficile à inverser sans migration lourde. Tranchez selon le contrat client : est-ce votre marque ou la leur qui domine l'URL ?
Activer multisite sans stratégie domaine, c'est construire un immeuble sans ascenseur — ça tient, jusqu'au troisième étage.
Hébergement : ce que l'offre doit accepter
Avant installation, vérifiez :
- Multisite autorisé (certaines offres mutualisées l'interdisent).
- Wildcard SSL ou gestion multi-certificats (Let's Encrypt SAN).
- Limites PHP : mémoire, max execution time — une panne réseau affecte tous les sites.
- Cron fiable : tâches réseau + sites enfants.
- Staging : tester activation réseau sans toucher prod.
Un VPS ou une offre WordPress managée « réseau » est souvent plus adapté qu'un mutualisé basique.
Plugins, thèmes et rôles : ce qui change
- Activation réseau vs activation par site : certains plugins ne supportent que l'un des modes.
- Thèmes : un thème enfant par site est possible ; builder lourd sur tous les sites multiplie la charge.
- Rôles super admin : qui peut créer des sites, installer des plugins, voir les données de tous les clients ?
- Quotas upload : éviter qu'un site enfant sature le disque commun.
Documentez une liste blanche plugins avant d'ouvrir le réseau aux rédacteurs ou clients.
Sauvegardes et restauration : le piège silencieux
Une base wp_blogs + tables partagées signifie :
- backup complet = tout le réseau ;
- restore d'un site seul = procédure manuelle ou outil spécialisé ;
- export client = risque de fuites de tables voisines si mal filtré.
Testez une restauration partielle avant la mise en ligne. Beaucoup de projets multisite découvrent cette limite le jour d'un incident.
Le sommet : multisite centralise le pouvoir — et la panne
Multisite brille pour réseaux éditoriaux, franchises, intranets ou microsites d'une même marque. Il devient un fardeau quand l'agence l'utilise comme raccourci billing sans accepter la responsabilité réseau.
Décider et avancer sans angle mort
- Choisissez le modèle d'URL (sous-domaine vs domaine mappé) avec les clients.
- Validez compatibilité hébergeur et SSL wildcard.
- Testez plugins critiques en staging réseau.
- Définissez rôles et liste blanche extensions.
- Documentez backup/restore par site et global.
Consultez notre annuaire pour filtrer offres compatibles multisite et Mettre WordPress à jour pour la stratégie de mises à jour réseau.
Questions fréquentes
Multisite convient-il à des sites clients séparés ?
Oui pour franchise ou sites internes homogènes. Non si isolation, facturation ou plugins divergents sont requis.
Sous-domaines ou sous-dossiers pour démarrer ?
Sous-domaines = wildcard DNS + SSL. Sous-dossiers = plus simple au départ, moins propre en URL.
Tous les plugins fonctionnent-ils en multisite ?
Non. Testez activation réseau et stockage options en staging.
Comment sauvegarder un multisite ?
Base et wp-content partagés : restauration par site plus complexe — testez avant prod.
Multisite récompense ceux qui décident des règles avant le premier site enfant — pas ceux qui activent le mode réseau pour « gagner du temps » un vendredi.