WordPress Multisite n'est pas Multi-Site : Architecture 500 Locations Qui Scale
Votre client franchise lance le subsite 247. WordPress crée wp_247_posts, wp_247_postmeta, wp_247_options — les mêmes 12 tables qu'il a créées pour les subsites 1 à 246. Maintenant vous avez 2 964 tables dans une seule base de données. Une mise à jour de plugin les touche toutes. Une requête sur le site 118 entre en concurrence avec les requêtes sur les sites 12, 95 et 203. Votre tableau de bord de monitoring montre l'épuisement du pool de connexions à 11h00 tous les mardis. Ce n'est pas une architecture multi-site. C'est une installation WordPress avec des copies numérotées du même schéma, et elle a sept conséquences d'échelle qui se cassent à des seuils prévisibles — la première arrive vers le site 40.
J'ai migré des réseaux avec 15, 40 et une fois 87 subsites en dehors de WordPress Multisite. Chaque fois, le client pensait qu'il obtenait des sites indépendants. Chaque fois, ils ont découvert de la manière difficile que ce n'était pas le cas. Si vous exploitez une franchise, une entreprise multi-localisation ou un réseau de département universitaire sur WordPress Multisite, cet article va faire un peu mal. Mais c'est mieux de savoir maintenant qu'après que le subsite #47 ait pris tous les 46 autres.
Table des matières
- Ce que WordPress Multisite fait réellement sous le capot
- Les 7 conséquences de l'architecture fausse multi-site
- Quand WordPress Multisite fonctionne (honnêtement)
- L'architecture qui scale réellement à 500 locations
- Comparaison d'architecture : Tables préfixées vs Sécurité au niveau des lignes
- Implémentation : Next.js + Supabase pour les sites multi-locations
- Chemin de migration : Quitter WordPress Multisite
- Chiffres réels : Comparaison de performance et de coûts
- FAQ
Ce que WordPress Multisite fait réellement sous le capot
Voyons ce qui se passe quand vous activez Multisite dans WordPress. Vous ajoutez quelques lignes à wp-config.php :
define('WP_ALLOW_MULTISITE', true);
define('MULTISITE', true);
define('SUBDOMAIN_INSTALL', false);
define('DOMAIN_CURRENT_SITE', 'example.com');
define('PATH_CURRENT_SITE', '/');
define('SITE_ID_CURRENT_SITE', 1);
define('BLOG_ID_CURRENT_SITE', 1);
WordPress crée alors quelques tables au niveau du réseau (wp_blogs, wp_site, wp_sitemeta, wp_registration_log, wp_signups) et commence à dupliquer votre structure de table principale pour chaque nouveau subsite.
Voici à quoi ressemble la base de données après seulement 5 subsites :
wp_posts (site principal)
wp_postmeta (site principal)
wp_options (site principal)
wp_users (partagé - tous les sites)
wp_usermeta (partagé - tous les sites)
wp_2_posts (subsite 2)
wp_2_postmeta (subsite 2)
wp_2_options (subsite 2)
wp_3_posts (subsite 3)
wp_3_postmeta (subsite 3)
wp_3_options (subsite 3)
...
wp_5_posts (subsite 5)
wp_5_postmeta (subsite 5)
wp_5_options (subsite 5)
Cinq subsites et vous avez déjà ~55 tables. Cinquante subsites ? Vous regardez plus de 500 tables dans une seule base de données MySQL. Cinq cents locations ? Au nord de 5 000 tables. Dans une base de données. Partageant un pool de connexions.
Chaque table a ses propres index. Chaque requête cible une table préfixée spécifique. Le planificateur de requêtes doit gérer tout cela. Et chacune de ces tables est accessible à n'importe quel processus PHP s'exécutant sur ce serveur, car elles sont toutes dans la même base de données avec les mêmes credentials.
Ce n'est pas une architecture multi-site. C'est une convention de nommage se faisant passer pour une isolation.
Les 7 conséquences de l'architecture fausse multi-site
1. Surface de vulnérabilité partagée
Chaque subsite dans un réseau WordPress Multisite exécute le même noyau WordPress, les mêmes plugins et les mêmes thèmes. Une exploitation de plugin compromise tous les subsites car ils partagent la même base de code.
Ce n'est pas théorique. En février 2025, WPVivid — un plugin de sauvegarde avec plus de 900 000 installations actives — a eu une vulnérabilité RCE (Remote Code Execution) de sévérité 9.8 divulguée. Sévérité 9.8 sur 10. C'est du territoire « un attaquant non authentifié peut exécuter du code arbitraire sur votre serveur ».
Sur un site WordPress autonome, c'est un site compromis. Sur un réseau Multisite avec 30 subsites ? C'est 30 sites compromis. Même serveur. Même base de données. Même système de fichiers. Une exploitation, compromission totale du réseau.
Vous ne pouvez pas installer une version différente d'un plugin sur le subsite #12 que sur le subsite #13. Vous ne pouvez pas isoler les plugins d'une location loin des autres. Chaque site obtient la même surface d'attaque.
2. Multiplication des conflits de plugin
Sur un site WordPress unique, un conflit de plugin casse un site. Vous désactivez le plugin, diagnostiquez, continuez. Ennuyeux mais gérable.
Sur Multisite, un conflit de plugin activé au réseau casse chaque site simultanément. J'ai vu une mise à jour WooCommerce sur un réseau Multisite prendre 23 pages de location à la fois car un plugin de cache activé au réseau n'avait pas été mis à jour pour les nouveaux hooks WooCommerce. Vingt-trois locations avec des pages cassées. Une cause racine, vingt-trois gestionnaires de location en colère appelant la même personne.
Et voici le problème — les administrateurs de site individuels ne peuvent généralement pas désactiver les plugins activés au réseau. Ils doivent attendre que le Super Admin le corrige.
3. Dégradation de performance
Cinquante subsites partageant une instance MySQL. Chaque chargement de page sur le subsite #47 exécute des requêtes comme :
SELECT * FROM wp_47_posts WHERE post_type = 'page' AND post_status = 'publish';
SELECT option_value FROM wp_47_options WHERE option_name = 'active_plugins';
SELECT * FROM wp_47_postmeta WHERE post_id IN (142, 143, 144, 145);
Pendant ce temps, le subsite #12 exécute son propre ensemble de requêtes contre wp_12_posts, wp_12_options et wp_12_postmeta. Et chaque autre subsite aussi, tous frappant la même instance MySQL.
Le planificateur de requêtes MySQL est confus. Le cache de tables se remplit. Chaque table préfixée maintient ses propres index, mais le pool de buffer est partagé. Les performances se dégradent non-linéairement à mesure que vous ajoutez des subsites. Passer de 10 à 20 subsites n'est pas deux fois la charge — cela peut être trois ou quatre fois la charge selon les modèles de trafic, à cause de la contention de verrous et du battage du pool de buffer.
J'ai un jour testé un réseau de 40 subsites. Le temps de requête moyen sur le subsite #1 était 45ms. Au moment où nous avons testé le subsite #38, le temps de requête moyen avait grimpé à 380ms. Même structure de requête. Même volume de données par site. La base de données était juste étouffée par les tables.
4. La migration est un cauchemar
Essayez d'extraire le subsite #23 d'un réseau de 50 sites dans sa propre installation WordPress autonome. Voici ce que vous devez faire :
- Exporter tous les tableaux préfixés
wp_23_ - Remappe chaque tableau du préfixe
wp_23_àwp_ - Ressérialiser toutes les options et les données de widget (WordPress stocke du PHP sérialisé dans la base de données, et les longueurs de chaîne changent quand vous changez les préfixes)
- Remapper les chemins de médias de
/uploads/sites/23/à/uploads/ - Recherche et remplacement de toutes les URL internes
- Remapper les capacités utilisateur de
wp_23_capabilitiesàwp_capabilitiesdanswp_usermeta - Extraire les utilisateurs du tableau
wp_userspartagé (seulement ceux qui appartiennent au subsite #23) - Recréer les relations utilisateur-à-site
Une erreur de sérialisation et vous obtenez des données corrompues. Les paramètres de widget disparaissent. Les options du customizeur de thème se cassent. Les structures de menu s'évanouissent. J'ai fait ce processus d'extraction des douzaines de fois, et cela prend 4-8 heures par subsite même avec des outils comme WP Migrate DB Pro. Multipliez cela par 50 subsites si vous désactivez un réseau.
L'écosystème WordPress a des outils pour cela, bien sûr. Mais le fait que ces outils aient besoin d'exister vous dit quelque chose sur l'architecture.
5. Pas d'isolation de données véritablement
C'est celui qui devrait vous terrifier si vous vous souciez de la sécurité ou de la conformité.
Une vulnérabilité d'injection SQL sur le subsite #2 n'expose pas seulement wp_2_posts. L'utilisateur de base de données se connectant à MySQL a accès à chaque table de la base de données. Cela signifie wp_posts (site principal), wp_3_posts (subsite 3), wp_users (tous les utilisateurs sur tous les sites) et chaque autre table.
Il n'y a pas d'isolation au niveau de la base de données. Pas de sécurité au niveau des lignes. Pas de séparation de schéma. WordPress Multisite est une base de données, un ensemble de credentials, et une convention de nommage. C'est tout.
Pour les entreprises traitant les données des clients sur les locations — cabinets médicaux, cabinets juridiques, services financiers — c'est un problème de conformité. HIPAA, SOC 2 et PCI DSS ont tous des exigences autour de l'isolation des données. « Nous avons utilisé des préfixes de table différents » ne va pas satisfaire un auditeur.
6. Goulot d'étranglement du Super Admin
WordPress Multisite a un rôle appelé Super Admin. Seul le Super Admin peut :
- Installer ou supprimer des plugins
- Installer ou supprimer des thèmes
- Activer les plugins au réseau
- Ajouter de nouveaux sites au réseau
- Gérer les paramètres du réseau
Les administrateurs de site individuels ont des capacités restreintes. Ils ne peuvent pas installer leurs propres plugins. Ils ne peuvent pas ajouter leurs propres thèmes. Chaque changement qui touche l'infrastructure partagée route via une personne (ou une petite équipe).
Pour un réseau de 3 sites, c'est bien. Pour une franchise de 50 locations où chaque gestionnaire de location veut ajouter son propre widget de réservation ou plugin menu PDF ? C'est un goulot qui engendre du ressentiment et de l'ombre IT.
7. Fragilité de la cartographie de domaine
Voulez-vous que chaque location ait son propre domaine ? denver.yourbrand.com ou yourbrand-denver.com ? WordPress Multisite ne le gère pas nativement de manière fiable. Vous avez besoin d'une solution de cartographie de domaine, et l'approche sunrise.php dropin intégrée est notoirement capricieuse.
Les certificats SSL pour les domaines cartographiés ajoutent une autre couche. La configuration DNS ajoute une autre. Chaque domaine cartographié est un autre point potentiel de défaillance que votre Super Admin doit gérer. Un changement DNS, un certificat expiré, une entrée de cartographie mal configurée, et le site d'une location est hors ligne.
Quand WordPress Multisite fonctionne (honnêtement)
Je ne vais pas prétendre que c'est inutile. WordPress Multisite fonctionne bien dans des scénarios spécifiques :
- Petits réseaux (moins de 10 sites) où tous les sites sont gérés par la même équipe
- Sites de département universitaire où le contrôle centralisé est réellement souhaité
- Miroirs de dev/staging/production pour le même projet
- Réseaux de blog où l'isolation du contenu n'est pas critique
Si vous avez 5-8 sites, un sysadmin compétent, et vous n'avez pas besoin d'isolation des données entre les sites — Multisite est bien. Les problèmes commencent quand vous essayez de le scaler à des douzaines ou des centaines de locations.
L'architecture qui scale réellement à 500 locations
Voici l'approche alternative que nous utilisons chez Social Animal pour les entreprises multi-locations : une architecture headless avec Next.js en frontend et Supabase (PostgreSQL) en backend, utilisant Row-Level Security (RLS) pour la véritable isolation des données.
L'idée centrale : au lieu de dupliquer les tables pour chaque location, vous avez un ensemble de tables avec une colonne location_id. Les politiques de sécurité au niveau de la base de données garantissent que les requêtes ne retournent des données que pour la location autorisée. Et au lieu de 500 installations WordPress séparées prétendant être indépendantes, vous avez un déploiement d'application unique où /locations/[slug] affiche dynamiquement la page de chaque location à partir d'une ligne de base de données.
Comment Row-Level Security fonctionne réellement
-- Créer la table des locations
CREATE TABLE locations (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
slug TEXT UNIQUE NOT NULL,
name TEXT NOT NULL,
address TEXT,
phone TEXT,
hours JSONB,
metadata JSONB,
created_at TIMESTAMPTZ DEFAULT now()
);
-- Créer la table des pages avec isolation de location
CREATE TABLE pages (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
location_id UUID REFERENCES locations(id),
title TEXT NOT NULL,
content JSONB,
slug TEXT NOT NULL,
published BOOLEAN DEFAULT false,
created_at TIMESTAMPTZ DEFAULT now()
);
-- Activer RLS
ALTER TABLE pages ENABLE ROW LEVEL SECURITY;
-- Politique : les gestionnaires de location ne peuvent voir que les pages de leur location
CREATE POLICY "location_isolation" ON pages
FOR ALL
USING (location_id = (SELECT location_id FROM user_locations WHERE user_id = auth.uid()));
-- Politique : le public peut lire les pages publiées pour n'importe quelle location
CREATE POLICY "public_read" ON pages
FOR SELECT
USING (published = true);
Avec cette configuration, un gestionnaire de location à Denver qui parvient d'une manière ou d'une autre à fabriquer une requête malveillante ne peut physiquement pas accéder aux données d'Austin. La base de données l'applique. Pas la couche application. Pas une convention de nommage. La base de données elle-même.
Comparaison d'architecture : Tables préfixées vs Sécurité au niveau des lignes
Voici une représentation visuelle des deux architectures :
Architecture WordPress Multisite :
┌─────────────────────────────────────────────┐
│ Base de données MySQL unique │
│ │
│ wp_posts (site principal) │
│ wp_options (site principal) │
│ wp_2_posts (Denver) │
│ wp_2_options (Denver) │
│ wp_3_posts (Austin) │
│ wp_3_options (Austin) │
│ wp_4_posts (Seattle) │
│ wp_4_options (Seattle) │
│ ... x 500 locations = 5 000+ tables │
│ │
│ ⚠️ UN ensemble de credentials DB │
│ ⚠️ UN processus PHP accède TOUTES tables │
│ ⚠️ ZERO isolation au niveau DB │
└─────────────────────────────────────────────┘
Architecture Next.js + Supabase :
┌─────────────────────────────────────────────┐
│ Base de données PostgreSQL unique │
│ │
│ locations (500 lignes, une par location) │
│ pages (contenu par location) │
│ media (images par location) │
│ staff (équipe par location) │
│ reviews (avis par location) │
│ │
│ ✅ Politiques RLS appliquent l'isolation │
│ ✅ L'utilisateur Denver NE PEUT PAS │
│ interroger les données d'Austin │
│ ✅ 5 tables total, pas 5 000 │
│ ✅ Index standards, plans requête optimaux│
└─────────────────────────────────────────────┘
Une base de données dans les deux cas. Mais le modèle d'isolation est fondamentalement différent. RLS est appliqué au niveau du moteur PostgreSQL — ce n'est pas quelque chose que l'application peut contourner.
| Facteur | WordPress Multisite | Next.js + Supabase |
|---|---|---|
| Tables à 500 locations | ~5 500+ | ~5-15 |
| Isolation des données | Aucune (convention nommage seule) | RLS appliquée par DB |
| Surface vulnérabilité | Une exploit = tous sites | Isolation auth par location |
| Conflits de plugin | Panne au réseau | N/A (pas architecture plugin) |
| Ajouter une location | Créer subsite + configurer | Insérer ligne DB |
| Supprimer une location | Processus extraction complexe | Supprimer lignes avec CASCADE |
| Cartographie de domaine | Plugin requis, fragile | Middleware rewrite, natif |
| Temps build/déployer | N/A (PHP runtime) | ~30s build incrémental |
| TTFB (moy, uncached) | 800ms-2s+ | 50-150ms (edge) |
| Hosting mensuel (500 sites) | $200-800/mo (WP géré) | $25-75/mo (Supabase + Vercel) |
| Récupération de compromise | Remédiation réseau complet | Rotation keys, redéployer |
Implémentation : Next.js + Supabase pour les sites multi-locations
Voici comment fonctionne le routing en pratique avec Next.js :
// app/locations/[slug]/page.tsx
import { createClient } from '@/lib/supabase/server';
import { notFound } from 'next/navigation';
export async function generateStaticParams() {
const supabase = createClient();
const { data: locations } = await supabase
.from('locations')
.select('slug');
return locations?.map(({ slug }) => ({ slug })) ?? [];
}
export default async function LocationPage({
params
}: {
params: { slug: string }
}) {
const supabase = createClient();
const { data: location } = await supabase
.from('locations')
.select(`
*,
pages(*),
staff(*),
reviews(*, rating)
`)
.eq('slug', params.slug)
.single();
if (!location) notFound();
return (
<div>
<h1>{location.name}</h1>
<LocationHero location={location} />
<LocationServices pages={location.pages} />
<LocationTeam staff={location.staff} />
<LocationReviews reviews={location.reviews} />
</div>
);
}
Ajouter une nouvelle location ? Insérer une ligne :
INSERT INTO locations (slug, name, address, phone, hours)
VALUES (
'portland-or',
'Portland, OR',
'123 Burnside St, Portland, OR 97209',
'(503) 555-0142',
'{"mon": "9-5", "tue": "9-5", "wed": "9-5"}'
);
C'est tout. Le prochain build le récupère. Ou si vous utilisez ISR (Incremental Static Regeneration), il apparaît dans votre fenêtre de revalidation sans build du tout.
Supprimer une location ? DELETE FROM locations WHERE slug = 'portland-or'; Les suppressions en cascade gèrent le reste. Pas de processus d'extraction de 4-8 heures.
Pour les domaines personnalisés par location, le middleware Next.js le gère proprement :
// middleware.ts
import { NextResponse } from 'next/server';
const DOMAIN_MAP: Record<string, string> = {
'yourbrand-denver.com': '/locations/denver-co',
'yourbrand-austin.com': '/locations/austin-tx',
// ... chargé depuis edge config en production
};
export function middleware(request: Request) {
const hostname = new URL(request.url).hostname;
const rewritePath = DOMAIN_MAP[hostname];
if (rewritePath) {
return NextResponse.rewrite(new URL(rewritePath, request.url));
}
return NextResponse.next();
}
Pas de plugins. Pas de sunrise.php dropin. Pas de fragile tableau de cartographie. Juste une règle rewrite à l'edge.
Chemin de migration : Quitter WordPress Multisite
Si vous êtes actuellement sur WordPress Multisite avec 20+ locations, voici le chemin de migration réaliste :
Phase 1 : Extraction de données (1-2 semaines)
Extraire le contenu de chaque subsite en utilisant l'API REST WordPress ou WP-CLI. N'essayez pas de remapper manuellement les tables préfixées. Utilisez l'API — elle abstrait le cauchemar du préfixe.
# Exporter tous les articles du subsite 23
wp post list --url=example.com/location-23 --format=json > location-23-posts.json
# Exporter tous les médias
wp media list --url=example.com/location-23 --format=json > location-23-media.json
Phase 2 : Conception de schéma (1 semaine)
Concevez votre schéma Supabase autour de votre modèle de contenu réel, pas le modèle post/postmeta de WordPress. C'est le moment de corriger des années de dette de modèle de données accumulée.
Phase 3 : Migration de contenu (1-2 semaines)
Écrire des scripts de migration qui transforment le contenu WordPress dans votre nouveau schéma. Gérer les données sérialisées, les shortcodes et les blocs Gutenberg.
Phase 4 : Construction du frontend (3-4 semaines)
Constituez le frontend Next.js. C'est où vous voyez les gains réels de performance. Les pages qui prenaient 1,5 secondes sur WordPress se chargent maintenant en moins de 200ms.
Phase 5 : Basculement DNS (1 jour)
Pointer vos domaines vers la nouvelle infrastructure. Gardez l'ancien réseau en lecture seule pendant 30 jours comme sauvegarde.
Pour les entreprises qui ont besoin d'aide avec ce processus de migration, nous avons documenté notre approche sur notre page de développement headless CMS. Nous avons fait suffisamment de ces migrations pour savoir où se trouvent les corps.
Chiffres réels : Comparaison de performance et de coûts
Voici les données d'une migration réelle que nous avons complétée au Q1 2025 — un réseau de cabinet dentaire avec 34 locations :
| Métrique | WordPress Multisite (Avant) | Next.js + Supabase (Après) |
|---|---|---|
| TTFB moyen | 1 240ms | 89ms |
| Largest Contentful Paint | 3,8s | 1,1s |
| Coût hosting mensuel | $347/mo (WP Engine) | $45/mo (Vercel Pro + Supabase Pro) |
| Temps ajouter nouvelle location | 2-3 heures (setup manuel) | 15 minutes (insérer ligne + contenu) |
| Temps mettre à jour toutes locations | Mise à jour plugin + prière | git push |
| Taux de passage Core Web Vitals | 12 de 34 locations | 34 de 34 locations |
| Incidents de sécurité (12 mois) | 3 | 0 |
La réduction seule du coût hosting a payé la migration en 8 mois. Les améliorations de performance ont conduit à des augmentations mesurables du classement de recherche locale pour 28 des 34 locations en 90 jours.
Si vous évaluez les coûts de votre propre réseau, notre page de tarification a des répartitions transparentes pour les projets multi-locations.
FAQ
WordPress Multisite est-il bon pour gérer plusieurs locations ?
Pour un petit nombre de locations (moins de 10) avec une gestion centralisée, WordPress Multisite peut fonctionner. Mais il n'a pas été conçu pour les entreprises multi-locations qui ont besoin d'une exploitation indépendante, d'une isolation des données ou d'une haute performance à grande échelle. L'architecture de base de données partagée crée des problèmes de sécurité, de performance et opérationnels qui se composent à chaque location que vous ajoutez.
Quels sont les plus gros problèmes avec WordPress Multisite ?
Les sept principaux problèmes sont : surface de vulnérabilité partagée (une exploit frappe tous les sites), multiplication de conflits de plugin (un conflit prend tous les sites), dégradation de performance non-linéaire, processus de migration/extraction cauchemardesque, zéro isolation des données au niveau DB, goulot d'étranglement du Super Admin pour tous les changements administratifs, et cartographie de domaine fragile. Ces problèmes sont architecturaux — ils ne peuvent pas être corrigés avec des plugins ou un meilleur hosting.
WordPress Multisite peut-il gérer 100+ sites ?
Techniquement, oui. Pratiquement, cela devient très douloureux au-delà de 30-50 sites. À 100 sites vous gérez 1 100+ tables de base de données dans une instance MySQL unique, une dégradation grave du planificateur de requêtes, et une complexité opérationnelle qui nécessite une équipe DevOps dédiée. À 500 sites, c'est un non-starter pour la plupart des environnements d'hosting.
Quelle est la meilleure alternative à WordPress Multisite pour plusieurs locations ?
Une architecture headless utilisant Next.js ou Astro pour le frontend avec une base de données PostgreSQL (telle que Supabase) utilisant Row-Level Security fournit une véritable isolation des données, une performance dramatiquement meilleure, des coûts d'hosting inférieur et une gestion de location triviale. Chaque location est une ligne de base de données, pas une installation WordPress entière.
Comment migrez-vous de WordPress Multisite vers une architecture headless ?
L'approche la plus sûre est d'extraire le contenu via l'API REST WordPress ou WP-CLI plutôt que d'essayer de remapper manuellement les tables de base de données préfixées. Exporter le contenu par subsite, concevoir un schéma propre dans votre base de données cible, écrire des scripts de transformation, construire le nouveau frontend et basculer DNS. Prévoyez 6-10 semaines total pour un réseau avec 20+ sites.
WordPress Multisite affecte-t-il le SEO ?
Indirectement, oui. La dégradation de performance de WordPress Multisite conduit à des chargements de page plus lents, ce qui nuit aux scores Core Web Vitals. Google a confirmé que les signaux d'expérience de page influencent les classements. Dans nos données de migration, 82% des locations ont vu des classements de recherche locale améliorés en 90 jours après avoir migré vers une architecture headless avec TTFB sub-200ms.
WordPress Multisite est-il sécurisé pour les données commerciales ?
Non, si vous définissez la sécurité comme incluant l'isolation des données entre les locations. WordPress Multisite utilise une base de données avec un ensemble de credentials. Une injection SQL sur n'importe quel subsite peut accéder aux données de chaque autre subsite. Pour les entreprises soumises à HIPAA, SOC 2, PCI DSS ou des exigences de conformité similaires, le manque d'isolation au niveau DB est une responsabilité importante.
Combien coûte d'exécuter WordPress Multisite vs une alternative headless ?
L'hosting WordPress géré pour Multisite tourne généralement à $200-800/mois selon le nombre de sites et les niveaux de trafic (les plans Multisite de WP Engine commencent à $240/mo pour leur tier Growth en 2026). Une configuration headless comparable sur Vercel Pro ($20/mo) plus Supabase Pro ($25/mo) gère le même trafic pour une fraction du coût. L'investissement de build initial est plus élevé pour l'approche headless, mais les coûts opérationnels mensuels sont significativement inférieur. N'hésitez pas à nous contacter si vous voulez une comparaison de coûts spécifique pour la taille de votre réseau.