Vous gérez 50 sites WordPress. Vous avez installé MainWP (ou ManageWP) pour tous les voir dans un seul tableau de bord. Vous pouvez mettre à jour les extensions sur les 50 sites avec un seul clic. Vous pouvez sauvegarder les 50 sites. Vous pouvez surveiller la disponibilité sur les 50 sites. MainWP est un bon outil pour gérer les sites WordPress. Mais mieux gérer les sites WordPress n'est pas la même chose que résoudre le problème du multi-site. Vous exécutez toujours 50 installations WordPress distinctes. 50 bases de données distinctes. 50 piles d'extensions distinctes. 50 violations de sécurité potentielles distinctes. MainWP vous aide à gérer la douleur. Il n'élimine pas la douleur.

J'ai été des deux côtés. J'ai passé des années à aider les agences à gérer des flottes de sites WordPress, et j'ai aussi construit les applications multi-locataires qui les ont remplacées. Cet article ne vise pas à critiquer WordPress ou MainWP. Il s'agit de faire honnêtement les calculs et de reconnaître quand un outil de gestion masque un problème structurel.

Table des matières

Managing 50 WordPress Sites: MainWP Cannot Fix Your Real Problem

Les mathématiques inconfortables derrière 50 sites WordPress

Commençons par les chiffres car ce sont ceux que personne ne veut regarder.

50 sites WordPress. Chacun exécutant en moyenne 20 extensions. C'est 1 000 instances d'extension sur votre réseau. Pas 20 extensions — 1 000.

L'extension WordPress moyenne pousse environ 3 mises à jour par semaine par site. Sur 50 sites, c'est à peu près 150 mises à jour d'extension chaque semaine. Certaines semaines plus, d'autres moins, mais la moyenne tient.

Maintenant, la plupart de ces mises à jour se passent bien. Vous cliquez sur le bouton dans MainWP, elles se déploient, rien ne casse. Parfait. Mais « la plupart » n'est pas « tout ». Chaque mise à jour comporte la possibilité d'un problème de compatibilité. Une mise à jour d'extension qui entre en conflit avec votre thème. Une incompatibilité de version PHP. Une migration de base de données qui corrompt un type de publication personnalisé. Une mise à jour WooCommerce qui casse le flux de paiement sur 12 de vos 50 sites parce qu'ils exécutent tous le même plugin de passerelle de paiement qui n'a pas encore été mis à jour.

Chaque problème de compatibilité devient un ticket d'assistance. Chaque ticket d'assistance signifie dépannage, test, et possiblement annulation de la mise à jour. Le temps estimé sur un réseau de 50 sites : 20 à 40 heures par mois juste pour gérer les mises à jour d'extension et leurs retombées.

À un taux de 100 $/heure pour les développeurs (ce qui est modeste pour les développeurs WordPress expérimentés en 2025), c'est 2 000 à 4 000 $ par mois en travail de maintenance. Juste pour maintenir les lumières allumées. Pas de création de nouvelles fonctionnalités. Pas d'amélioration des performances. Juste de la maintenance.

Puis ajoutez l'hébergement. Même sur un hébergement bon marché, vous regardez 20–50 $ par site par mois pour tout ce qui est vaguement prêt pour la production. Multipliez par 50 : 1 000 à 2 500 $ par mois en coûts d'hébergement.

Le total annuel ? 36 000 à 78 000 $ par an en maintenance et hébergement. Pour 50 sites qui font à peu près la même chose.

Laissez ce chiffre s'installer pendant une seconde.

Ce que MainWP fait vraiment (et bien)

Je veux être juste ici. MainWP, ManageWP, InfiniteWP, WP Remote — ces outils existent pour une raison, et ils résolvent de vrais problèmes.

MainWP spécifiquement vous donne :

  • Tableau de bord centralisé — voir les 50 sites en un seul endroit
  • Mises à jour groupées des extensions et thèmes — déployer les mises à jour sur tous les sites avec un seul clic
  • Sauvegardes programmées — automatiser les sauvegardes sur toute votre flotte
  • Surveillance de la disponibilité — recevoir des alertes quand les sites s'arrêtent
  • Analyse de sécurité — rechercher les vulnérabilités connues sur tous les sites
  • Rapports clients — générer des rapports montrant les travaux de maintenance que vous avez effectués

ManageWP offre un ensemble de fonctionnalités similaire avec un modèle SaaS au lieu d'auto-hébergé. InfiniteWP cible les agences avec sa propre saveur du même concept.

Ce sont genuinely des outils utiles. Si vous êtes engagé à exécuter plusieurs sites WordPress, vous devriez absolument en utiliser un. Exécuter 50 sites WordPress sans outil de gestion est juste de la négligence.

Mais voici la chose à laquelle je reviens sans cesse : le meilleur service d'ambulance du monde ne rend pas la route moins dangereuse.

MainWP optimise la gestion d'une situation fondamentalement complexe. Il ne réduit pas la complexité elle-même.

Les quatre problèmes que MainWP ne peut pas résoudre

Problème 1 : Les conflits d'extension sont inhérents, non gérables

MainWP peut pousser les mises à jour d'extension. Il peut même auto-mettre à jour les extensions selon un calendrier. Ce qu'il ne peut pas faire est de prévenir le conflit qui se produit quand l'Extension A version 4.2 rompt la compatibilité avec l'Extension B version 3.7.

Quand vous exécutez 20 extensions par site, vous gérez un graphique de dépendances qu'aucun humain — et aucun outil de tableau de bord — ne peut pleinement prévoir. Les extensions WordPress ne déclarent pas les dépendances formelles comme le font les packages npm. Il n'y a pas de fichier de verrouillage. Il n'y a pas d'algorithme de résolution des dépendances. C'est juste des fichiers PHP chargés en séquence, en espérant qu'ils ne se marchent pas dessus.

Avec 1 000 instances d'extension, vous rencontrerez environ 2-5 conflits significatifs par mois sur votre flotte. Chacun nécessite qu'un développeur diagnostique, teste et résout. MainWP peut vous montrer qu'un site est cassé. Il ne peut pas prévenir le casse.

Problème 2 : Les vulnérabilités partagées sur 50 surfaces d'attaque

Supposons que l'une de vos 20 extensions ait une vulnérabilité critique divulguée. C'est arrivé à Elementor (affectant 5 millions de sites +) en 2024. C'est arrivé à WPForms, à All in One SEO, à des dizaines d'extensions populaires.

MainWP vous permet de pousser le correctif de sécurité sur les 50 sites rapidement. C'est bien. Mais voici ce qu'il ne peut pas corriger : les 50 sites étaient vulnérables simultanément. La fenêtre entre la divulgation et votre déploiement de correctif est la fenêtre où les 50 sites sont exposés.

Et c'est en supposant que le correctif existe. Pour les vulnérabilités de type zero-day — où l'exploit est connu avant le correctif — MainWP ne peut absolument rien faire. Vous avez 50 surfaces d'attaque distinctes, chacune exécutant le même code vulnérable.

Une application sans extensions WordPress n'a zéro vulnérabilité d'extension. Ce n'est pas une amélioration de la gestion. C'est une élimination de catégorie.

Problème 3 : 50 points de défaillance distincts

MainWP peut surveiller la disponibilité sur vos 50 sites. Il peut vous alerter quand le Site #37 s'arrête. Ce qu'il ne peut pas faire est de prévenir la réalité fondamentale que 50 environnements serveur distincts, 50 bases de données distinctes, et 50 processus PHP distincts créent 50 points de défaillance indépendants.

Le Site #12 s'arrête parce que le fournisseur d'hébergement a fait maintenance. Le Site #28 s'arrête parce qu'une extension a causé une fuite mémoire. Le Site #41 s'arrête parce que le renouvellement automatique du certificat SSL a échoué. Le Site #7 s'arrête parce qu'une table de base de données s'est verrouillée pendant un travail cron.

Ce sont des défaillances non liées qui arrivent à des sites connexes. MainWP vous en informe. Il ne les prévient pas. Et le temps que vous passez à répondre à des défaillances aléatoires sur 50 environnements est du temps que vous ne dépensez pas sur quelque chose de productif.

Problème 4 : L'optimisation des performances est par site, non par flotte

Voulez-vous améliorer les Core Web Vitals sur les 50 sites ? MainWP ne peut pas vous aider là. Chaque site a son propre thème, son propre balisage généré par extension, sa propre gestion d'image, sa propre configuration de mise en cache. Optimiser un site n'optimise pas les autres.

J'ai vu des agences passer 4-8 heures par site sur l'optimisation des performances. Sur 50 sites, c'est 200-400 heures de travail unique, plus maintenance en cours à mesure que les extensions et le contenu changent. MainWP ne rend pas cela plus rapide. Chaque site est son propre flocon de neige.

Managing 50 WordPress Sites: MainWP Cannot Fix Your Real Problem - architecture

L'alternative : une application, 50 locataires

Voici à quoi ressemble l'alternative en pratique.

Au lieu de 50 installations WordPress, vous construisez une application Next.js avec une architecture multi-locataires. Chacun de vos 50 « sites » devient un locataire — une configuration dans une base de données qui détermine la marque, le contenu et le routage pour ce domaine particulier.

L'architecture ressemble à ceci :

┌─────────────────────────────────────────┐
│      Une application Next.js             │
│  ┌─────────┐  ┌─────────┐  ┌─────────┐ │
│  │Locataire 1│ │Locataire 2│ │Locataire 50│ │
│  │ site1.com │ │site2.com │ │site50.com │ │
│  └─────────┘  └─────────┘  └─────────┘ │
│    Base de code partagée + composants   │
│    Une base de données (Supabase)       │
│    Un déploiement (Vercel)              │
└─────────────────────────────────────────┘

Chaque locataire obtient :

  • Son propre domaine
  • Sa propre marque (logo, couleurs, polices)
  • Son propre contenu (pages, articles de blog, médias)
  • Sa propre configuration (fonctionnalités activées/désactivées)

Mais ils partagent tous :

  • Une base de code (mettre à jour une fois, déployer partout)
  • Une base de données avec sécurité au niveau des lignes par locataire
  • Un environnement d'hébergement
  • Une posture de sécurité
  • Un profil de performance

Voici à quoi ressemble une configuration de locataire en pratique :

// lib/tenants.ts
export interface TenantConfig {
  id: string;
  domain: string;
  name: string;
  theme: {
    primaryColor: string;
    logo: string;
    font: string;
  };
  features: {
    blog: boolean;
    contactForm: boolean;
    locations: boolean;
    ecommerce: boolean;
  };
  metadata: {
    googleAnalyticsId?: string;
    defaultLocale: string;
  };
}

// Le middleware résout le locataire à partir du nom d'hôte
// middleware.ts
import { NextRequest, NextResponse } from 'next/server';

export async function middleware(request: NextRequest) {
  const hostname = request.headers.get('host') || '';
  const tenant = await getTenantByDomain(hostname);
  
  if (!tenant) {
    return NextResponse.redirect(new URL('/not-found', request.url));
  }
  
  // Injecter l'ID du locataire dans les en-têtes pour une utilisation en aval
  const response = NextResponse.next();
  response.headers.set('x-tenant-id', tenant.id);
  return response;
}

Mises à jour d'extension ? Zéro. Il n'y a pas d'extensions. Chaque fonctionnalité est intégrée dans l'application ou consommée via API.

Hébergement ? 45 $ par mois au total. Le plan Pro de Vercel à 20 $/mois gère l'application. Le plan Pro de Supabase à 25 $/mois gère la base de données. Les deux évoluent automatiquement. Les deux gèrent les 50 locataires à partir d'un seul déploiement.

Maintenance ? 2-5 heures par mois. Les mises à jour du framework se font trimestriellement, pas hebdomadairement. Il n'y a pas de conflits d'extension parce qu'il n'y a pas d'extensions. Les correctifs de sécurité pour Next.js ou ses dépendances viennent via npm audit fix — une commande, un déploiement, les 50 locataires corrigés simultanément.

Si vous avez besoin d'un CMS headless pour les éditeurs de contenu, des outils comme Sanity, Contentful ou Payload CMS s'intègrent proprement et prennent en charge les modèles de contenu multi-locataires de manière native. Nous avons construit plusieurs d'entre eux chez Social Animal — consultez nos solutions de développement de CMS headless si vous voulez des détails sur la façon dont nous gérons le côté gestion de contenu.

Comparaison des coûts : flotte WordPress vs application multi-locataires

Voici la comparaison sur cinq ans. Ces chiffres supposent 50 sites, et j'utilise le point médian des gammes de coûts WordPress.

Catégorie de coût 50 sites WordPress (annuel) Next.js multi-locataires (annuel)
Hébergement 22 500 $ (37,50 $ par site × 50 × 12) 540 $ (45 $/mois × 12)
Licences d'extension 3 000 – 6 000 $ (extensions premium × 50) 0 $
Travail de maintenance 36 000 $ (3 000 $/mois × 12) 4 200 $ (350 $/mois × 12)
Surveillance de sécurité 1 200 – 3 000 $ (Sucuri/Wordfence × 50) 0 $ (intégré)
Certificats SSL 0 – 2 500 $ (si non gratuit via l'hôte) 0 $ (SSL auto Vercel)
Total annuel 57 000 $ (point médian) 4 740 $

Maintenant, projetons sur plusieurs années, y compris le coût unique de migration :

Période 50 sites WordPress Next.js multi-locataires Différence
Année 1 57 000 $ 104 740 $ (migration 100 K + ops 4 740 $) WordPress moins cher de 47 740 $
Année 2 114 000 $ 109 480 $ Équilibre
Année 3 171 000 $ 114 220 $ Économisez 56 780 $
Année 5 285 000 $ 123 700 $ Économisez 161 300 $
Année 10 570 000 $ 147 400 $ Économisez 422 600 $

La migration se rembourse quelque part entre le mois 18 et le mois 24. Après cela, vous économisez 50 000 $ + par an. Chaque année. L'écart s'élargit parce que les coûts de maintenance WordPress ont tendance à augmenter au fil du temps (plus d'extensions, plus de complexité, plus de problèmes de sécurité), tandis que les coûts de l'application multi-locataires restent plats ou diminuent à mesure que l'outillage s'améliore.

Ce ne sont pas des chiffres théoriques. Nous avons construit ces migrations pour les agences et les opérations en franchise chez Social Animal. La page de tarification a plus de détails sur la façon dont nous évaluons les constructions multi-locataires, et notre équipe de développement Next.js a fait ce type de projet plusieurs fois.

La question de la migration

La plus grande objection que j'entends : « Nous ne pouvons pas nous permettre un projet de migration de 60 K – 150 K $ ».

Juste. Mais reformulons-le. Vous dépensez déjà 57 K $ par an en maintenance et hébergement. La migration n'est pas un coût — c'est un remboursement de dette. Vous remboursez la dette technique d'exécuter 50 installations WordPress distinctes, et une fois que c'est remboursé, vos coûts courants diminuent de 90 %.

La migration n'a pas non plus besoin de se faire en une seule fois. Voici une approche par étapes qui fonctionne :

Phase 1 : Construire la plateforme multi-locataires (Semaines 1-8)

Construire l'application Next.js avec routage multi-locataires, une bibliothèque de composants partagée et l'intégration CMS. Migrer 5 sites comme preuve de concept. Coût : 30 K – 50 K $.

Phase 2 : Migration par lots (Semaines 9-16)

Migrer les 45 sites restants par lots de 10-15. Chaque lot devient plus rapide parce que la plateforme existe déjà — vous configurez juste de nouveaux locataires et migrez le contenu. Coût : 20 K – 50 K $.

Phase 3 : Arrêter WordPress (Semaines 17-20)

Arrêter les anciennes installations WordPress. Annuler l'hébergement. Annuler les licences d'extension. Annuler l'abonnement MainWP. Rediriger tous les DNS. Coût : 5 K – 10 K $.

Chronologie totale : 4-5 mois. Coût total : 55 K – 110 K $ selon la complexité du site.

Pendant la migration, vous payez toujours pour WordPress. Donc ajoutez approximativement 19 K – 24 K $ en coûts de chevauchement. Mais une fois que c'est fait, c'est fait. Vous ne toucherez plus jamais WordPress.

Qu'en est-il des éditeurs de contenu ?

C'est l'autre grande objection. « Nos clients/éditeurs connaissent WordPress. Ils ne veulent pas apprendre quelque chose de nouveau. »

Deux réponses. Premièrement, les plates-formes CMS headless modernes comme Sanity Studio et Payload CMS sont arguablement plus faciles à utiliser que WordPress pour l'édition de contenu. Elles n'ont pas la jungle d'extensions. Elles n'ont pas la barre latérale admin avec 47 éléments de menu. Elles ont des interfaces d'édition propres et spécialisées.

Deuxièmement, vous pouvez en fait garder WordPress comme CMS headless — enlever complètement le frontend et utiliser WordPress uniquement comme une API de contenu via l'API REST ou WPGraphQL. Vos éditeurs conservent leur interface familière. Votre frontend est toujours une application Next.js. Vous avez éliminé le problème du plugin-as-frontend tout en préservant le flux de travail d'édition.

Cela dit, si vous allez dans cette direction, vous exécutez toujours des instances WordPress pour la gestion du contenu — bien qu'avec beaucoup moins d'extensions, beaucoup moins de surface d'attaque, et beaucoup moins de frais de maintenance.

Quand vous devriez garder WordPress (sérieusement)

Je ne vais pas prétendre que le Next.js multi-locataires est la réponse pour tous. Gardez WordPress si :

  • Vos sites sont vraiment différents. Si chacun de vos 50 sites a fondamentalement des fonctionnalités différentes — l'un est un magasin de commerce électronique, l'un est un site d'adhésion, l'un est un système de gestion de l'apprentissage — une approche multi-locataires ne fonctionne pas bien. Le multi-locataires brille quand les sites sont structurellement similaires.
  • Vous avez moins de 10 sites. Les mathématiques ne fonctionnent pas à plus petite échelle. MainWP ou ManageWP est l'appel juste pour 5-10 sites.
  • Vos sites dépendent fortement d'extensions WordPress spécifiques sans équivalent API. Certaines extensions WordPress (comme certains LMS ou systèmes de réservation) n'ont pas d'alternatives propres dans le monde headless. Vérifiez avant de vous engager.
  • Votre équipe est 100 % WordPress et n'a pas d'expérience JavaScript. La migration comprend un changement de technologie. Si votre équipe entière doit se recycler, facteur ce coût honnêtement.

Pour tout le reste — en particulier les sites de franchise, les entreprises multi-sites, les sites de clients d'agence qui suivent un modèle, et les sites marketing SaaS — l'approche multi-locataires est meilleure sur tous les axes qui importent.

Si vous explorez Astro comme alternative à Next.js pour les configurations multi-locataires riches en contenu, c'est une autre voie viable. L'architecture en île d'Astro fonctionne particulièrement bien quand la plupart de vos pages de locataires sont du contenu statique avec une interactivité minimale.

Comment commencer la transition

Si les mathématiques de cet article vous mettent mal à l'aise (elles devraient), voici comment commencer à penser à une transition sans vous engager dans une migration complète.

  1. Auditez vos 50 sites. Combien sont structurellement identiques ? Combien partagent le même thème ? La même pile d'extension ? Plus le chevauchement est élevé, plus solide est le cas pour le multi-locataires.

  2. Calculez vos vrais coûts. N'utilisez pas mes estimations — utilisez les vôtres. Suivez les heures réelles dépensées en maintenance pendant un mois. Multipliez par 12. Ajoutez l'hébergement. Ajoutez les licences d'extension. Obtenez le nombre annuel réel.

  3. Identifiez votre locataire MVP. Choisissez les 5 sites les plus simples. Qu'est-ce qu'il faudrait pour les reconstruire en tant que locataires dans une seule application ? C'est votre preuve de concept.

  4. Obtenez un devis réel. Contactez une équipe qui a fait cela avant. Pas une agence WordPress qui fait aussi « un peu de React » — une équipe qui se spécialise dans l'architecture headless. Nous avons fait cette migration spécifique plusieurs fois, et nous pouvons vous donner une portée réaliste basée sur vos sites réels.

  5. Exécutez les nombres côte à côte. Coût de migration + 3 ans d'hébergement et maintenance multi-locataires vs. 3 ans de maintenance WordPress. Si l'option multi-locataires économise de l'argent — et pour 50+ sites c'est presque toujours le cas — vous avez votre réponse.

Plus vous attendez, plus vous dépensez. Chaque mois à 4 750 $ en maintenance WordPress est un mois où cet argent aurait pu payer les coûts de migration au lieu de juste maintenir les lumières allumées.

FAQ

MainWP peut-il gérer efficacement 50 sites WordPress ? Oui, MainWP peut techniquement gérer 50 ou même 100+ sites WordPress à partir d'un seul tableau de bord. Il gère bien les mises à jour groupées, les sauvegardes et la surveillance. Le problème n'est pas la capacité de MainWP — c'est que gérer 50 installations WordPress distinctes est une proposition fondamentalement coûteuse et risquée quel que soit l'outil de gestion que vous utilisez. MainWP la rend tolérable. Il ne la rend pas bon marché ou sûre.

Quelle est la meilleure alternative à MainWP pour gérer plusieurs sites WordPress ? ManageWP (propriété de GoDaddy) et InfiniteWP sont les alternatives MainWP les plus populaires. ManageWP a une interface SaaS plus soignée et un niveau gratuit généreux. InfiniteWP est auto-hébergé comme MainWP. WP Remote est une autre option pour les besoins plus simples. Mais si vous posez cette question parce que vous êtes frustré de gérer plusieurs sites WordPress, la véritable alternative n'est pas un meilleur outil de gestion — c'est de consolider ces sites dans une seule application multi-locataires.

Combien coûte la gestion de 50 sites WordPress par an ? En fonction de notre expérience et de la tarification 2025, attendez-vous à 36 000 – 78 000 $ par an pour 50 sites WordPress quand vous facteur dans l'hébergement (20 – 50 $ par site par mois), le travail de maintenance (20 – 40 heures par mois à 100 $/heure), les licences d'extension, et la surveillance de sécurité. Le nombre exact dépend de la complexité du site, du fournisseur d'hébergement et du nombre d'extensions premium que vous exécutez.

Une application Next.js multi-locataires est-elle vraiment moins chère que 50 sites WordPress ? Après le coût de migration initial, oui — considérablement moins cher. Les coûts d'exploitation annuels pour une application Next.js multi-locataires sur Vercel + Supabase s'élèvent à environ 4 000 – 7 000 $ par an par rapport à 36 000 – 78 000 $ pour la flotte WordPress équivalente. Le coût de migration (60 K – 150 K $) est significatif, mais il se rembourse en 18 – 24 mois par le biais de frais d'exploitation réduits.

Puis-je migrer de WordPress vers Next.js sans perdre les classements SEO ? Oui, mais cela nécessite une planification soignée. Vous devez maintenir les structures d'URL (ou configurer les redirections 301 appropriées), préserver les balises meta et les données structurées, maintenir votre sitemap à jour, et assurer que la vitesse des pages s'améliore (ce qui se passe généralement). Google ne se soucie pas de la technologie qui génère votre HTML — il se soucie du contenu, de la performance et des redirections appropriées. Nous avons géré des migrations où le trafic organique a augmenté de 20 à 40 % après la migration en raison de Core Web Vitals améliorés.

Que deviennent mes contenus WordPress quand je migre vers une configuration headless ? Votre contenu migre vers quel que soit le CMS ou la base de données que vous choisissez pour la nouvelle plateforme. Les cibles courantes incluent Sanity, Contentful, Payload CMS, ou même une instance WordPress headless (où WordPress serve uniquement comme une API de contenu). La migration de contenu implique de déplacer des articles, des pages, des fichiers médias et des métadonnées. Pour 50 sites avec des structures similaires, cela peut être largement automatisée avec des scripts de migration.

Dois-je migrer tous les 50 sites à la fois ? Absolument pas. Une approche par étapes est standard. Commencez par 3-5 sites comme preuve de concept, validez que la plateforme fonctionne pour vos besoins, puis migrez le reste par lots. Pendant la période de transition, vous exécutez les deux systèmes en parallèle. Cela ajoute un chevauchement de coûts temporaire mais réduit considérablement le risque.

Que se passe-t-il si mes clients ont besoin d'éditer du contenu sans connaître le code ? Les plates-formes CMS headless modernes fournissent des interfaces d'édition visuelle qui sont souvent plus simples que WordPress pour l'édition de contenu. Sanity Studio, par exemple, vous permet de construire des tableaux de bord d'édition personnalisés adaptés exactement à ce dont chaque client a besoin — pas de jungle d'extension, pas de barre latérale admin confuse avec 47 éléments de menu, pas de scénario « vous pouvez éditer n'importe quoi et casser n'importe quoi ». Les éditeurs de contenu obtiennent une expérience plus propre et plus ciblée.