WordPress Multisite : quand l’utiliser, et quand l’éviter

par Francis Rozange | Oct 2, 2026 | WordPress

A glowing glass trunk branching into many identical translucent rooms

Au Royaume-Uni, plus de cent quarante blogs gouvernementaux tournent sur une seule installation WordPress. Le blog du service numérique de l’État, celui consacré à la technologie au sein du gouvernement, ceux des ministères : chacun a son adresse, son équipe et ses articles, mais tous partagent le même cœur, le même thème et les mêmes plugins. Le réseau fonctionne ainsi depuis 2013.

C’est la promesse de WordPress Multisite : gérer des dizaines, voire des centaines de sites comme un seul. La documentation officielle commence pourtant par une mise en garde. Pour des sites étroitement liés, qui partagent des données ou des utilisateurs, le multisite n’est peut-être pas la meilleure solution.

Ce guide vous aide à trancher. Il explique ce qu’est réellement un réseau, comment l’activer, le choix entre sous-domaines et sous-répertoires, ce qui est partagé, ce que cela coûte en performances, en sauvegarde et en migration, et les alternatives. Il se termine par une grille de décision.

Ce qu’est vraiment un réseau multisite

Un cœur, des sites, des tables séparées

Un réseau multisite est un ensemble de sites qui partagent les mêmes fichiers du cœur de WordPress. Les sites n’ont pas de dossier propre sur le disque : ils ont chacun leur dossier de médias, dans wp-content/uploads/sites/ suivi de leur numéro (le site principal garde wp-content/uploads/), et leurs propres tables dans la base de données.

Chaque nouveau site reçoit dix tables : articles, commentaires, liens, options, termes et taxonomies, avec leurs métadonnées. Le premier site garde les tables habituelles, comme wp_posts ; le deuxième utilise wp_2_posts, et ainsi de suite. D’autres tables restent communes à tout le réseau : les utilisateurs et leurs métadonnées, la liste des sites, les inscriptions et les réglages du réseau.

La documentation officielle décrit l’usage type : des sites d’entreprise qui partagent certaines ressources, comme le thème ou les plugins, avec des contenus différents selon les régions. Un réseau peut aussi laisser les visiteurs créer leur propre site, comme sur WordPress.com, ou réserver la création à l’administrateur.

Le super administrateur, et ce que perd l’administrateur de site

Un réseau ajoute un rôle au-dessus de tous les autres : le super administrateur, « Super-admin » dans l’interface française. C’est lui qui installe les plugins et les thèmes, met à jour le cœur, crée les sites et gère les comptes. Sa liste est enregistrée dans une option du réseau, pas dans les rôles habituels.

Sous le super administrateur, l’administrateur d’un site perd une bonne partie de ses pouvoirs. Il ne peut ni installer de plugin ou de thème, ni modifier les profils des utilisateurs de son site, ni publier du HTML non filtré. Par défaut, il n’a même pas accès au menu des plugins. Notre guide des rôles et capacités WordPress détaille ces différences.

Activer un réseau : les étapes

Préparer le terrain

La documentation officielle pose quatre préalables : sauvegarder la base et les fichiers, vérifier que les permaliens personnalisés fonctionnent, désactiver tous les plugins, et, si vous comptez installer WordPress dans son propre dossier, le faire avant d’activer le réseau. Sur un site en production, faites l’essai sur une copie avant tout.

Le menu de création du réseau n’apparaît qu’après l’ajout d’une ligne dans wp-config.php, au-dessus du commentaire qui demande d’arrêter les modifications :

define( 'WP_ALLOW_MULTISITE', true );

Créer le réseau

Une nouvelle entrée, « Création du réseau », apparaît alors dans le menu Outils. Vous y choisissez le modèle d’adresses, le titre du réseau et l’adresse de son administrateur. WordPress génère ensuite deux blocs à copier : les constantes à ajouter à wp-config.php, dont MULTISITE et SUBDOMAIN_INSTALL, et les règles de réécriture pour le fichier .htaccess. Après une nouvelle connexion, le menu d’administration du réseau est disponible.

Les réglages par défaut du réseau

Un réseau neuf est prudent par défaut. Les inscriptions sont fermées, le menu des plugins est masqué aux administrateurs de sites, et un quota de 100 Mo par site est prérempli, mais il ne s’applique qu’une fois cochée la case « Espace de stockage du site ».

Certains noms de sites sont réservés, comme « www », « admin » ou « files ». Ces réglages se modifient dans l’écran des réglages du réseau. Ouvrir les inscriptions ou le menu des plugins mérite réflexion : la version 7.0.3 a justement corrigé une faille qui touchait les réseaux ouverts aux inscriptions.

Sous-domaines ou sous-répertoires : le choix qui engage

Ce que chaque modèle exige

À la création du réseau, il faut choisir entre deux modèles d’adresses : les sous-domaines, comme site1.example.com, ou les sous-répertoires, comme example.com/site1. La documentation est claire : c’est l’un ou l’autre, et changer plus tard n’est pas simple.

Les sous-domaines demandent un peu plus de travail côté serveur. Un DNS joker n’est nécessaire que si des sites doivent être créés à la demande, malgré l’avertissement affiché par l’installateur. En HTTPS, il faut un certificat joker ou un certificat par sous-domaine ; avec les sous-répertoires, tous les sites partagent le même domaine et le même certificat.

Quelques restrictions s’appliquent. Un réseau en sous-domaines est impossible si l’adresse du site comporte un chemin, comme example.com/blog, ou si elle utilise localhost ou une adresse IP. Un réseau, quel qu’il soit, ne fonctionne pas sur un port autre que 80 ou 443. Et WordPress génère les règles de réécriture pour Apache et IIS, pas pour Nginx : sur Nginx, la configuration vous revient.

La règle du mois, telle que le code l’applique

WordPress refuse de créer un réseau en sous-répertoires sur un site existant dans un cas précis : si la table des contenus contient un élément publié, article, page ou autre type, daté de plus d’un mois. La raison est le risque de collision entre les adresses des articles existants et celles des futurs sites. Une constante, ALLOW_SUBDIRECTORY_INSTALL, permet de lever cette restriction en connaissance de cause.

Sur un réseau en sous-répertoires, le site principal reçoit aussi un préfixe /blog/ dans l’adresse de ses articles, pour la même raison. Les pages statiques n’en ont pas : une page et un futur site portant le même nom entreraient donc en collision.

Changer d’avis plus tard

Depuis septembre 2026, la documentation officielle le précise noir sur blanc : changer la constante SUBDOMAIN_INSTALL et les règles de réécriture ne migre ni les adresses des sites existants, ni le DNS, ni les certificats, ni les redirections, ni les cookies. C’est une migration complète.

WordCamp.org l’a fait en 2020. Le réseau des sites de conférences WordPress utilisait des adresses comme 2020.torino.wordcamp.org. Joost de Valk et Jono Alderson avaient signalé que certains de ces sites n’étaient même pas indexés, Google traitant selon eux chaque sous-domaine comme un site distinct. L’équipe est passée à torino.wordcamp.org/2020, en restant en multisite. À notre connaissance, aucun chiffre sur l’effet en référencement n’a été publié depuis.

Revenir d’un réseau à un site unique est encore plus délicat. L’hébergeur Pantheon qualifie le choix entre site unique et multisite de permanent, et ne prend pas en charge le retour en arrière.

Domaines personnalisés : le mapping natif

Depuis WordPress 4.5, attribuer un domaine propre à un site du réseau ne demande plus de plugin. Il suffit de faire pointer le domaine vers le serveur, d’installer un certificat pour ce domaine, puis de modifier l’adresse du site dans l’administration du réseau, écran Sites. Cela fonctionne avec les deux modèles d’adresses.

Si les connexions posent problème sur un domaine attribué, la documentation donne une ligne à ajouter au fichier de configuration :

define( 'COOKIE_DOMAIN', $_SERVER['HTTP_HOST'] );

Le fichier sunrise.php, longtemps indispensable, ne sert plus qu’à des cas avancés, par exemple WPML pour servir chaque langue sur son propre domaine dans un réseau. Une page de la documentation suggère encore un plugin de mapping : elle est simplement en retard sur les autres.

Utilisateurs, plugins et thèmes partagés

Un seul annuaire d’utilisateurs

Tous les comptes du réseau vivent dans les mêmes tables. Un compte n’accède à un site que si on lui y donne un rôle, mais une fois connecté sur un site, il l’est sur tous les sites du même domaine. Les rôles sont enregistrés site par site, sous une clé numérotée comme wp_2_capabilities.

La suppression d’un compte demande de l’attention. Avec WP-CLI, wp user delete retire seulement le compte du site en cours ; il faut l’option --network pour le supprimer du réseau, après avoir réattribué ses contenus. WordPress 7.1 a même introduit une régression qui vidait, dans l’administration du réseau, le menu de réattribution quand les membres du site ne figuraient pas sur le site principal : les contenus pouvaient alors être supprimés sans avertissement, jusqu’au correctif de la 7.1.1, le 17 septembre 2026.

WordPress 7.0 a aussi changé la gestion des indésirables : marquer un compte comme indésirable ne marque plus automatiquement ses sites. Un filtre permet de rétablir l’ancien comportement.

Plugins : par site ou pour tout le réseau

Les plugins s’installent une fois, depuis l’administration du réseau. Elles peuvent ensuite être activées site par site, ou pour tout le réseau ; dans ce cas, aucun administrateur de site ne peut les désactiver. Les extensions indispensables, placées dans mu-plugins, se chargent partout.

Un plugin peut exiger une activation sur tout le réseau avec l’en-tête Network: true. Cet en-tête compte : la version 7.1.1 a corrigé une faille qui permettait à un administrateur de site d’activer pour tout le réseau un plugin réservé au réseau. En août, la 7.0.3 avait déjà corrigé une élévation de privilèges qui permettait à un utilisateur inscrit de créer un site.

Tous les plugins ne fonctionnent pas en multisite, et le répertoire officiel n’a aucun champ pour le signaler. Il faut lire la FAQ de chaque plugin, ou interroger son auteur.

Thèmes : un code pour tous, des styles par site

Les thèmes sont installés pour tout le réseau, puis autorisés pour tous les sites ou site par site. Modifier le code d’un thème le modifie pour tous les sites qui l’utilisent ; les styles réglés dans l’éditeur de site restent propres à chaque site.

Côté licences, la prudence s’impose. Comme le rappelle WP Engine, beaucoup de plugins et de thèmes premium comptent chaque sous-site comme une activation. Un réseau de cinquante sites peut donc consommer cinquante activations.

Un anneau de lumière qui ouvre un long couloir de portes de verre identiques

Le cas GOV.UK : un réseau gouvernemental depuis 2013

La plateforme de blogs du gouvernement britannique est l’un des rares réseaux multisite dont l’histoire est documentée de 2013 à 2020, par son propriétaire, le Government Digital Service, et par son prestataire, l’agence dxw, qui l’a construite et l’héberge. Elle illustre à la fois quand le multisite a du sens et ce qu’il coûte.

Pourquoi un réseau plutôt que des blogs séparés

En septembre 2013, le Government Digital Service présente la plateforme, lancée au printemps avec un premier blog consacré à l’histoire du gouvernement. Toutes les administrations n’étaient pas aussi bien équipées pour bloguer, et mutualiser cette capacité présentait des avantages économiques évidents. La plateforme est alors gratuite pour toute administration qui respecte quelques critères, fixés dès mai 2013 : publier régulièrement, proposer un contenu distinct et unique, suivre la charte de style.

La plateforme commune sert un objectif précis : une expérience cohérente avec le reste de GOV.UK. Tous les blogs partagent l’apparence de GOV.UK et le même système d’abonnement par courriel. Une douzaine de blogs sont déjà en ligne début septembre 2013, chacun sur un sous-domaine de blog.gov.uk.

Ce que la mutualisation a coûté

Entrer dans le réseau a un prix. En janvier 2014, quand le blog du service numérique lui-même y migre, l’équipe prévient que la plupart des commentaires des dernières semaines ne seront pas transférés, et que les courriels reçus par les abonnés vont changer.

La sécurité des comptes devient l’une des priorités. En 2015, dxw et le service numérique développent un plugin de double authentification pour toute la plateforme, avec un repli par SMS, parce que tous les agents n’avaient pas de smartphone. Fin 2016, le réseau compte plus de cent blogs et deux mille utilisateurs.

Un audit de sécurité révèle alors un grand nombre de comptes inactifs, et d’utilisateurs ayant quitté leur poste au gouvernement. dxw développe des outils pour désactiver ces comptes et marquer comme inactifs ceux qui ne se connectent plus. La question posée par l’audit résume le multisite : comment exploiter en sécurité une plateforme commune quand la publication est déléguée à des dizaines d’équipes.

Ce qu’elle a rapporté

En contrepartie, le réseau offre un avantage décisif : chaque correctif profite à tous les blogs d’un coup. La double authentification de 2015 a été développée une seule fois, puis proposée aux utilisateurs de toute la plateforme. En 2020, après un audit d’accessibilité, dxw a consacré quatre semaines à corriger les éléments non conformes de la plateforme de blogs et de celle des campagnes gouvernementales. La plateforme comptait alors un million d’utilisateurs actifs par mois.

Fermer un blog ne veut pas dire le supprimer. En octobre 2018, le blog de la place de marché numérique de l’État annonce sa fermeture, ses actualités passant sur le blog principal. Tout son contenu reste en ligne pour référence, toujours consultable aujourd’hui.

Au moment où nous écrivons, la page d’accueil de blog.gov.uk affiche cent quarante-trois blogs, les adresses des images suivent le schéma propre au multisite, et de nouveaux articles y paraissaient le jour même de notre relevé, le 1er octobre 2026.

Ce qu’il faut en retenir

Le cas GOV.UK coche toutes les cases d’un bon usage du multisite : de nombreux petits sites, une même marque, un même gabarit, des règles communes et une équipe centrale qui maintient tout. À l’inverse, il montre que l’annuaire commun d’utilisateurs devient le principal chantier de sécurité, et qu’entrer dans le réseau a un coût. Gardez en tête que dxw, prestataire rémunéré, raconte ici son propre travail, et qu’aucun chiffre de coût n’a été publié.

Performances et base de données

Le compte des tables et les limites des hébergeurs

Le calcul est simple : mille sites représentent dix mille tables du cœur, avant le moindre plugin. Les plugins qui créent leurs propres tables les créent le plus souvent pour chaque site : WooCommerce en déclare plusieurs dizaines. Un réseau de boutiques multiplie donc très vite les tables.

Les hébergeurs fixent des limites en conséquence. WP Engine plafonne le nombre de sous-sites selon l’offre et le nombre de tables à cent mille par environnement, en expliquant qu’un excès de tables pose des problèmes de montée en charge et allonge les redémarrages de maintenance.

Le cache d’objets : ce qui est commun, ce qui est par site

Avec un cache d’objets persistant, certains groupes de données sont communs à tout le réseau, comme les utilisateurs, les options du réseau et la liste des sites ; les autres sont séparés par site. Autre point pratique : vider le cache avec WP-CLI vide généralement celui de tous les sites. Notre guide du cache d’objets Redis détaille sa mise en place.

Les très grands réseaux

WordPress considère lui-même un réseau comme « grand » au-delà de dix mille sites ou de dix mille utilisateurs : certains écrans d’administration changent alors de comportement. À l’extrême, WordPress.com répartit des millions de tables sur des milliers de bases avec le plugin HyperDB, selon la documentation du plugin, dont cette phrase n’a pas changé depuis au moins 2011. À ces échelles, la répartition de la base devient un projet à part entière.

Sauvegarde et migration : là où le multisite se paie

Déplacer tout le réseau

Déplacer un réseau sur le même domaine revient à copier les fichiers et la base, comme pour un site unique. Changer de domaine est plus délicat : la base contient de nombreuses références à l’adresse du serveur, dans les tables de chaque site comme dans celles du réseau. Avec l’option --network, WP-CLI parcourt les tables de tous les sites. L’exemple officiel ci-dessous se limite aux tables d’options, à wp_blogs et à wp_site ; retirez ces noms pour traiter aussi les contenus :

wp search-replace --url=example.com example.com example.test 'wp_*options' wp_blogs wp_site --network

Pour préparer la bascule elle-même, notre guide pour migrer un site WordPress sans interruption reste valable.

Extraire un seul site

Sortir un site d’un réseau est un travail manuel. WP-CLI sait exporter ses seules tables :

wp db export --tables=$(wp db tables --scope=blog --url=sub.example.com --format=csv)

Mais les utilisateurs ne sont pas dans ces tables, les médias sont dans un dossier numéroté, les plugins activés pour le réseau et les extensions indispensables n’apparaissent pas dans l’export, et le préfixe des tables doit être renommé. Un praticien qui a extrait un site en 2022 raconte ainsi avoir reçu un export, probablement réalisé avec un plugin de sauvegarde, où manquaient plus de cinq gigaoctets de médias.

Ce que font les plugins de sauvegarde

La prise en charge complète du multisite est souvent une option payante. UpdraftPlus la réserve à sa version premium, Duplicator à sa version Pro, All-in-One WP Migration à un plugin dédié, capable aussi d’extraire un seul sous-site. Jetpack VaultPress Backup ne prend pas en charge le multisite. Notre comparatif des plugins de sauvegarde WordPress donne le détail.

Multisite et multilingue

Un réseau permet de consacrer un site à chaque langue. C’est l’approche de MultilingualPress, qui ne fonctionne qu’en multisite, à partir de 149 euros par an pour deux langues en octobre 2026, ou du plugin gratuit Multisite Language Switcher. Chaque site peut alors avoir ses propres contenus, ses plugins et son équipe.

Ce modèle a du sens quand les langues sont gérées par des équipes séparées, avec des contenus ou des contraintes différents. Quand une seule équipe publie les mêmes contenus dans chaque langue, un plugin comme Polylang ou WPML dans un site unique est bien plus simple. Notre comparatif des plugins multilingues WordPress raconte le cas d’un média suisse qui a fait le choix du réseau.

Les alternatives

La documentation officielle propose elle-même la première : si vous voulez seulement une apparence différente par rubrique ou des niveaux d’accès distincts, un site unique avec un plugin suffit.

La seconde consiste à garder des installations séparées et à les piloter depuis un tableau de bord commun. MainWP, auto-hébergé, est gratuit dans sa version de base, avec une offre Pro à 199 dollars par an en octobre 2026. ManageWP propose ses fonctions de base gratuitement, avec des modules payants par site. Chaque site garde alors ses plugins, sa version de PHP et son calendrier de mises à jour, et peut être cédé ou déplacé sans chirurgie.

Enfin, certains hébergeurs proposent leurs propres outils de gestion de parc. Pantheon, par exemple, ne prend pas en charge une agence qui héberge plusieurs clients sur une même installation multisite : il l’oriente vers un Custom Upstream, une base de code commune à partir de laquelle chaque client reçoit son propre site.

La grille de décision

Le multisite convient quand la plupart de ces conditions sont réunies :

De nombreux sites partagent la même famille de thèmes et le même jeu de plugins.
Une équipe centrale gère les mises à jour, la sécurité et les comptes, et les responsables de sites se contentent de publier.
Vous devez créer rapidement de nouveaux sites sur la même base.
La connexion unique entre les sites est un avantage, pas un risque.
Votre hébergeur prend en charge le multisite, et vous maîtrisez le DNS et les certificats du modèle choisi.

Évitez-le si l’une de ces situations s’applique :

Les sites appartiennent à des clients différents ou demandent des plugins, des versions de PHP ou des calendriers différents.
Des équipes de développement distinctes ne doivent pas voir le code des autres.
Un site devra un jour être déplacé, vendu ou confié à quelqu’un d’autre.
Un plugin essentiel n’est pas compatible, ou se facture par sous-site.
Vous voulez seulement une apparence ou des accès différents par rubrique.

Besoin	Site unique	Multisite	Installations séparées et tableau de bord
Comptes partagés	Oui, un seul site	Oui, avec connexion unique	Non
Mises à jour communes	Sans objet	Une fois pour tous	Groupées depuis le tableau de bord
Plugins propres à chaque site	Sans objet	Limités au catalogue du réseau	Libres
Sauvegarder ou sortir un site	Simple	Manuel, souvent payant	Simple
Hébergement	Standard	Offre compatible, limites de tables	Standard, par site
Coûts à surveiller	Faibles	Licences par sous-site	Hébergement multiplié

Questions fréquentes

Peut-on revenir d’un réseau à un site unique ?

Pas avec un réglage. Il faut extraire les sites un par un, avec leurs tables, leurs médias et leurs comptes, ou repartir d’une installation neuve et importer les contenus. Certains hébergeurs, comme Pantheon, ne prennent pas en charge ce retour en arrière.

Faut-il un DNS joker ?

Seulement pour un réseau en sous-domaines où les sites sont créés à la demande. Si l’administrateur crée lui-même chaque site, des sous-domaines déclarés un par un suffisent.

WooCommerce fonctionne-t-il en multisite ?

Oui, boutique par boutique : chaque site a ses tables, ses réglages et ses commandes. Certains plugins de paiement imposent un compte par site, comme WooPayments, qui ne peut pas servir plusieurs adresses avec un seul compte.

Le multisite est-il plus rapide que des sites séparés ?

Aucune mesure neutre ne le montre dans un sens ou dans l’autre. Ce qui est documenté : le nombre de tables, les limites des hébergeurs et le partage du cache d’objets. Un réseau mal dimensionné peut ralentir tous ses sites à la fois.

Comment sauvegarder un seul site du réseau ?

Avec WP-CLI, listez ses seules tables avec wp db tables --scope=blog, exportez-les avec wp db export, et copiez son dossier de médias. Avec un plugin, vérifiez que la sauvegarde par sous-site est incluse dans votre offre : c’est rarement le cas des versions gratuites.

Conclusion

Le multisite est un outil de mutualisation. Il excelle quand de nombreux sites se ressemblent et qu’une seule équipe les gouverne, comme les blogs du gouvernement britannique. Il devient un piège quand les sites divergent, changent de mains ou dépendent de plugins qui le gèrent mal.

Posez-vous une question avant de l’activer : ces sites resteront-ils ensemble dans cinq ans ? Si la réponse est oui, le réseau vous fera gagner du temps à chaque mise à jour. Si elle est incertaine, des installations séparées pilotées depuis un tableau de bord vous laisseront toutes les portes ouvertes.

Sources

LaFactory conçoit, développe et maintient des sites WordPress et WooCommerce, et développe ses propres plugins. Parlons de votre projet WordPress.

Francis Rozange

Ancien chef de rubrique à Libération, il dirige LaFactory, agence web internationale depuis 1996.