Comment restaurer un site WordPress multisite (4 méthodes efficaces en 2026)

Quand un site WordPress simple tombe en panne, c'est déjà une mauvaise après-midi. Mais quand c'est tout un réseau multisite qui tombe en panne, tous les clients vous appellent en même temps.

C'est là que réside le risque souvent sous-estimé du multisite WordPress. L'infrastructure partagée permet de gérer efficacement des dizaines de sites à partir d'un seul tableau de bord, mais une seule table de base de données corrompue, une mise à jour de plugin mal exécutée ou une migration qui échoue peut mettre tout le réseau hors ligne.

J'ai déjà dû remettre en état des réseaux multisites dans la plupart des situations qui amènent les gens à consulter cet article : une mise à jour PHP qui a mis l'administrateur réseau dans une impasse, une migration d'hébergeur bâclée qui a laissé la base de données pointer vers le néant, ou encore un conflit entre plugins qui a bloqué tous les sous-sites à cause d'une erreur fatale.

La reprise après sinistre sur plusieurs sites n'est pas aussi compliquée qu'elle en a l'air, mais elle dépend fortement de ce qui continue de fonctionner lorsque les problèmes surviennent.

Dans cet article, je vais vous présenter plusieurs méthodes pour restaurer votre réseau multisite WordPress. Commencez par ce qui est encore accessible, choisissez la méthode qui vous convient le mieux et suivez-la pas à pas. À la fin, votre réseau sera de nouveau opérationnel !

En voici les principaux enseignements :

• Dans la plupart des cas, un réseau multisite défaillant peut être restauré. Les données sont généralement toujours présentes, même lorsque tous les sous-sites sont hors service.
• La méthode de restauration dépend de ce qui est encore accessible : wp-admin, une URL de restauration après sinistre, Duplicator Cloud, ou un accès FTP et phpMyAdmin.
• Duplicator Pro (licence Pro ou Elite) est le moyen le plus rapide de restaurer un réseau multisite. La restauration manuelle est une solution de secours qui fonctionne sans aucun plugin.
• Vous pouvez restaurer un seul sous-site sans toucher au reste du réseau, mais uniquement si la sauvegarde a été personnalisée pour ce sous-site lors de sa création.
• Les mesures qui permettent d'accélérer la restauration future (sauvegardes planifiées, URL de reprise après sinistre et connecteur de restauration configuré) ne prennent que quelques minutes à mettre en place et doivent être effectuées avant que vous n'en ayez besoin.

Table des matières

Quand peut-il être nécessaire de restaurer un réseau WordPress multisite ?

Les pannes multisites ne se présentent pas toutes de la même manière, et c'est la situation dans laquelle vous vous trouvez qui détermine la méthode de reprise la plus appropriée. Voici où vous en êtes peut-être actuellement.

• Échec de la mise à jour du noyau, d'un plugin ou d'un thème. C'est la cause la plus fréquente. Une seule mise à jour incompatible peut provoquer une erreur fatale qui bloque simultanément l'accès à tous les sous-sites. L'administrateur du réseau peut rester accessible, ou bien le site peut être complètement indisponible, selon la nature du problème.
• Corruption de la base de données. Une table MySQL endommagée, une importation qui a échoué ou une erreur d'écriture en cours de mise à jour peut perturber l'ensemble de la couche de données du réseau. Les fichiers sont intacts, mais WordPress ne parvient pas à lire les données dont il a besoin pour fonctionner.
• Réseau piraté ou compromis. Des logiciels malveillants, l'injection de code ou une attaque par force brute peuvent rendre le réseau non fiable. Il est possible de le nettoyer manuellement, mais la restauration à partir d'une sauvegarde intacte est généralement plus rapide et plus fiable.
• Échec de la migration. Le transfert d'un site multisite vers un nouvel hébergeur est plus complexe que celui d'un site unique. Une migration partielle, où les fichiers ont été transférés mais la base de données n'a pas été mise à jour, entraîne des dysfonctionnements du réseau qui ne sont pas toujours évidents tant que l'on n'a pas essayé de charger un sous-site.
• Suppression accidentelle. Un sous-site supprimé par erreur, un plugin essentiel désactivé à l'échelle du réseau, un paramètre de configuration modifié alors qu'il n'aurait pas dû l'être.
• Panne de serveur ou d'hébergement. L'infrastructure tombe en panne, et lorsqu'elle est rétablie, WordPress ne redémarre pas. Les fichiers sont peut-être intacts, mais la base de données ou la configuration a disparu.
• Une panne touchant un seul sous-site. Dans ce cas, une restauration complète du réseau n'est pas toujours nécessaire. Si un seul sous-site est affecté, une restauration sélective de ce sous-site est plus rapide et plus sûre qu'une restauration complète du réseau. La section supplémentaire à la fin de cet article traite précisément de ce sujet.

Ce dont vous avez besoin avant de commencer

La méthode de restauration à choisir dépend de ce qui est encore accessible. Passez en revue cette liste avant de choisir l'une des méthodes ci-dessous.

• Une sauvegarde antérieure à l'apparition du problème. Vérifiez la date et l'heure avant toute autre chose. La restauration d'une sauvegarde qui contient déjà les données corrompues ou la mise à jour défectueuse ne servira à rien.
• Savoir ce qui fonctionne encore. Pouvez-vous accéder à wp-admin ? Le serveur répond-il ? La base de données est-elle opérationnelle ? Vos réponses à ces questions déterminent les méthodes qui s'offrent à vous.
• Duplicator Pro pour les méthodes 1, 2 et 3. La prise en charge multisite nécessite une licence Pro ou Elite. La version Lite ne prend pas en charge le mode multisite. Si vous ne savez pas de quelle licence vous disposez, connectez-vous à votre compte sur duplicator.com.
• Accès d'administrateur réseau pour les méthodes 1 et 2. Duplicator Pro n'apparaît qu'au niveau du réseau. Vous ne le trouverez pas dans le tableau de bord d'un sous-site individuel. Si l'accès d'administrateur réseau est impossible, passez directement à la méthode 2 ou 3.
• Un connecteur de restauration configuré dans Duplicator Cloud pour la méthode 3. Il s'agit d'une configuration unique qui permet de stocker les identifiants FTP/SFTP de votre serveur dans Duplicator Cloud afin que celui-ci puisse enregistrer des fichiers directement sur votre serveur. Si cette configuration n'a pas été effectuée avant l'apparition du problème, la méthode 3 ne vous est pas accessible. Notez-le pour après la restauration.
• Identifiants du serveur pour la méthode 4. Si vous ne disposez pas de Duplicator, vous aurez besoin d'un accès FTP ou SFTP, des identifiants de votre base de données (serveur, nom, nom d'utilisateur, mot de passe) et d'un accès à phpMyAdmin ou à WP-CLI. Consultez le tableau de bord de votre hébergeur ou votre e-mail de bienvenue si vous ne savez pas où les trouver.

Comment restaurer un réseau WordPress multisite

Si vous lisez ces lignes en pleine crise, respirez un bon coup. Une panne du réseau multisite peut sembler catastrophique, surtout lorsque tous les sous-sites sont hors service en même temps, mais dans la plupart des cas, les données sont toujours là.

La méthode à utiliser dépend de ce qui est encore accessible. Certaines des options ci-dessous ne nécessitent que quelques clics. D'autres prennent plus de temps et exigent d'intervenir directement sur le serveur.

Quoi qu'il en soit, à la fin de cet article, vous aurez une feuille de route concrète pour aller de l'avant.

• Méthode 1 : Restauration à partir de la page de sauvegardes de Duplicator Pro: c'est l'option la plus rapide si wp-admin est toujours accessible. En quelques clics depuis le tableau de bord, Duplicator se charge automatiquement de la restauration complète du réseau.
• Méthode 2 : Utiliser l'URL de récupération après sinistre: cette méthode fonctionne même lorsque wp-admin est complètement hors service. Collez une URL pré-générée dans un navigateur, et le programme d'installation autonome de Duplicator s'exécute entièrement en dehors de WordPress.
• Méthode 3 : Restauration via Duplicator Cloud sans wp-admin: la solution de secours en dernier recours. Si les sauvegardes se trouvent dans Duplicator Cloud et qu'un connecteur de restauration a été configuré au préalable, la restauration s'effectue entièrement à distance depuis le tableau de bord du cloud via FTP/SFTP.
• Méthode 4 : Restauration manuelle via FTP et phpMyAdmin: solution de secours lorsque Duplicator n'est pas installé ou que les outils sous forme de plugins ne sont pas envisageables. Cette méthode comporte le plus grand nombre d'étapes et nécessite des identifiants de serveur, mais fonctionne sur n'importe quel hébergeur ne disposant pas d'outils préinstallés.

Méthode 1 : Restaurer à partir de la page des sauvegardes de Duplicator Pro

Si votre tableau de bord wp-admin est toujours accessible, c'est la méthode la plus rapide et la plus fiable pour rétablir le fonctionnement du réseau.

Duplicator Pro est un plugin WordPress dédié à la sauvegarde, à la migration et à la restauration, conçu pour gérer les réseaux multisites de la même manière que les sites individuels : de manière complète, depuis un seul tableau de bord, sans nécessiter d'intervention manuelle sur la base de données ni d'accès FTP.

Il sauvegarde chaque sous-site, stocke automatiquement des copies dans un espace de stockage cloud et, en cas de problème, restaure l'ensemble du réseau en quelques clics.

Pour les agences et les développeurs qui gèrent plusieurs sites sur un même réseau, c'est l'outil qui permet une restauration rapide et facile.

La version Lite ne prend pas en charge le mode multisite. Vous aurez besoin d'une licence Pro ou Elite, qui incluent toutes deux des fonctionnalités complètes de sauvegarde, de restauration, de migration et de reprise après sinistre au niveau du réseau.

Que ce soit pour effectuer une restauration de routine, corriger une mise à jour qui a mal tourné ou revenir en arrière après un test sur environnement de préproduction qui a mal tourné, j'utilise Duplicator.

Étape 1 : Trouver la bonne sauvegarde et la restaurer

Accédez à Mes sites » Administration du réseau » Duplicator Pro » Sauvegardes. Dans une installation multisite, Duplicator Pro n'apparaît qu'au niveau du réseau. Si vous consultez le tableau de bord d'un sous-site individuel, vous ne le trouverez pas là.

Si vos sauvegardes sont stockées dans un espace de stockage en ligne (Google Drive, Amazon S3, Dropbox ou Duplicator Cloud), elles s'afficheront automatiquement sur cette page. Vous n'aurez pas besoin de les télécharger à nouveau.

Recherchez la dernière sauvegarde effectuée avant l'apparition du problème. Vérifiez attentivement la date et l'heure. Si vous restaurez une sauvegarde qui a déjà été affectée par le problème ayant causé la panne du réseau, vous vous retrouverez dans la même situation.

Cliquez sur le bouton « Restaurer » à côté de la sauvegarde. Duplicator lance le programme d'installation dans un nouvel onglet du navigateur.

Avant de cliquer : cette opération écrasera votre installation multisite actuelle. Tout contenu, paramètre ou modification apportée aux sous-sites après la date et l'heure de la sauvegarde sera perdu. Vérifiez bien la date avant de continuer.

Étape 2 : Suivez les instructions du programme d'installation

Vous vous trouvez actuellement dans l'assistant de restauration étape par étape de Duplicator.

Duplicator remplit automatiquement les identifiants de la base de données et l'URL du site à partir de la sauvegarde. Il vous suffit d'accepter les conditions générales et les mentions légales en bas de la page, puis de cliquer sur « Restaurer la sauvegarde ».

Confirmez la restauration dans la fenêtre contextuelle et laissez le programme d'installation s'exécuter.

Une fois l'opération terminée, un écran de confirmation s'affichera, avec un lien pour revenir à votre interface d'administration réseau.

Votre site est de nouveau en ligne !

Méthode 2 : Utiliser l'URL de reprise après sinistre

Si wp-admin ne se charge pas et que vous ne parvenez pas à accéder au tableau de bord, vous pouvez tout de même restaurer votre réseau. Duplicator fonctionne indépendamment de WordPress ; par conséquent, une erreur fatale, un thème défectueux ou un panneau d'administration bloqué ne l'empêchent pas de fonctionner.

Une façon de rétablir votre réseau consiste à utiliser une URL de reprise après sinistre. Espérons que vous en ayez sauvegardé une copie avant que votre site ne subisse un incident.

Vous avez enregistré cet élément lors de la création de la sauvegarde, soit sous forme d'URL copiée, soit sous forme de fichier de lancement téléchargé.

Une chose à noter: l'URL de reprise après sinistre doit exister avant qu'un problème ne survienne. Elle est générée à partir d'une sauvegarde spécifique et conservée en lieu sûr.

Si vous n'en avez jamais créé, passez directement à la méthode 3. Revenez à cette section une fois que vous l'aurez récupéré et configuré.

Je conserve les miens dans un gestionnaire de mots de passe, avec une entrée par site. Si jamais le réseau venait à tomber complètement en panne, c'est la première chose vers laquelle je me tournerais.

Étape 1 : Trouvez votre URL de reprise après sinistre

Si vous ne savez pas si vous disposez d'une URL de reprise après sinistre, vérifiez dans Duplicator Pro, sous « Administration du réseau ». Rendez-vous dans « Sauvegardes » et recherchez l'icône verte de reprise après sinistre.

Si votre interface wp-admin fonctionne, cliquez dessus et copiez le lien de récupération.

Vous l'avez peut-être également enregistré hors site, dans un gestionnaire de mots de passe ou à un autre endroit sûr.

Étape 2 : Collez l'URL dans votre navigateur

Ouvrez un nouvel onglet dans votre navigateur et collez votre URL de restauration. Le programme d'installation autonome de Duplicator se charge directement, en dehors de WordPress. Il ne nécessite absolument pas WordPress pour fonctionner.

Même si votre site affiche une page blanche, une erreur fatale ou une erreur de connexion à la base de données, ce programme d'installation se chargera quand même.

Acceptez les conditions et lancez la restauration. Duplicator s'occupe du reste.

Une fois l'opération terminée, un lien vers votre interface d'administration réseau restaurée s'affichera. Cliquez dessus, vérifiez que vos sous-sites se chargent correctement, puis effectuez les opérations de nettoyage post-restauration indiquées par l'assistant.

Préparez-vous avant d'en avoir à nouveau besoin

Une fois le réseau rétabli, mettez immédiatement en place un plan de reprise après sinistre. Dans Duplicator Pro, rendez-vous dans la section « Sauvegardes » et créez une nouvelle sauvegarde complète du site incluant tous vos sous-sites.

Cliquez sur l'icône bleue en forme de maison située à côté de la sauvegarde terminée.

Poursuivre la mise en place de la reprise après sinistre.

Copiez l'URL. Enregistrez-la dans un endroit qui ne dépende pas de la disponibilité de votre site WordPress : un gestionnaire de mots de passe, un document partagé avec votre équipe, une note sécurisée.

Faites de même pour chaque sous-site du réseau que vous devrez restaurer séparément.

Cela ne prend que deux minutes et pourrait s'avérer essentiel pour une reprise rapide la prochaine fois que votre site sera hors service.

Méthode 3 : Restauration via Duplicator Cloud sans passer par wp-admin

Voici la procédure de récupération à suivre dans le pire des cas. WordPress ne fonctionne pas et wp-admin est inaccessible. Vous devez effectuer une restauration, mais vous ne pouvez pas accéder au tableau de bord pour lancer l'opération.

Si vos sauvegardes sont stockées dans Duplicator Cloud et que vous avez configuré un connecteur de restauration avant l'apparition du problème, la restauration s'effectue entièrement depuis le tableau de bord de Duplicator Cloud.

Votre serveur n'a pas besoin d'exécuter WordPress. Il suffit qu'il soit accessible via FTP ou SFTP.

Le connecteur de restauration est l'élément qui doit être configuré avant la survenue d'un incident. Il s'agit d'un ensemble d'identifiants FTP/SFTP enregistrés que Duplicator Cloud utilise pour écrire des fichiers directement sur votre serveur. S'il n'a pas été configuré au préalable, vous pouvez toujours saisir ces identifiants pendant le processus de restauration, mais vous devrez disposer d'un accès FTP.

Si le FTP est également hors service, contactez votre hébergeur avant de poursuivre, ou passez directement à la méthode 4.

Étape 1 : Connectez-vous à Duplicator Cloud et configurez le connecteur de restauration

Rendez-vous sur duplicator.com et connectez-vous à votre compte Duplicator Cloud. Dans le tableau de bord, sélectionnez le site que vous souhaitez restaurer.

Cliquez sur le bouton jaune « Récupération depuis le cloud » situé dans le coin supérieur droit.

Saisissez vos identifiants FTP/SFTP. Testez la connexion.

Étape 2 : Laissez Duplicator Cloud effectuer la restauration

Parcourez la liste des sauvegardes et repérez la dernière sauvegarde valide datant d'avant l'apparition du problème. Vérifiez attentivement l'horodatage, comme vous le feriez pour n'importe quelle autre méthode.

Cliquez sur « Restaurer la sauvegarde complète ».

Duplicator Cloud se connecte à votre serveur via FTP ou SFTP, transfère les fichiers de sauvegarde et exécute le programme d'installation à distance. Suivez la progression depuis le tableau de bord cloud. Vous n'avez aucune intervention à effectuer de votre côté pendant cette étape.

Une fois la restauration terminée, votre réseau multisite sera de nouveau opérationnel et accessible à son URL d'origine. Connectez-vous à l'administration du réseau, vérifiez que vos sous-sites s'affichent correctement et assurez-vous que les fichiers multimédias et les permaliens fonctionnent correctement.

Configurez le connecteur de récupération dès maintenant si vous ne l'avez pas encore fait

Une fois que votre site est de nouveau opérationnel, configurez cette option avant toute autre chose. Dans votre compte Duplicator Cloud, accédez aux paramètres de votre site et recherchez l'option « Recovery Connector ».

Saisissez vos identifiants FTP ou SFTP et testez la connexion. Duplicator Cloud vous indiquera si la connexion fonctionne.

C'est cette configuration qui garantit une restauration complète dans le cloud hors site dès qu'un problème survient. Associée à une URL de reprise après sinistre, elle vous offre deux moyens de restaurer votre réseau sans que WordPress ait besoin d'être en cours d'exécution.

Méthode 4 : Restauration manuelle via FTP et phpMyAdmin

C'est la méthode la plus difficile de cette liste. Elle nécessite le plus grand nombre d'étapes, le plus de compétences techniques et le plus de temps.

Je n'envisagerais une restauration manuelle que si Duplicator Pro n'est pas installé, si les outils de restauration du plugin ne fonctionnent pas, ou si vous ne disposez pas de sauvegarde et devez vous contenter des fichiers et des exportations de base de données dont vous disposez.

Si vous pouvez recourir aux méthodes 1, 2 ou 3, utilisez-les en premier lieu. Cette solution de secours est prévue pour les cas où celles-ci ne sont pas disponibles.

Étape 1 : Localisez vos fichiers de sauvegarde

Avant d'intervenir sur le serveur, assurez-vous de disposer de deux éléments : une copie des fichiers WordPress (tout ce qui se trouve à la racine du site et dans le répertoire /wp-content/) et une exportation de la base de données au format .sql.

Il faut les deux. Si l'on restaure les fichiers sans la base de données, ou la base de données sans les fichiers, le réseau reste hors service.

Si vous ne disposez pas d'une sauvegarde manuelle, consultez d'abord votre panneau d'hébergement. La plupart des hébergeurs gérés (WP Engine, Kinsta, SiteGround et autres) stockent des instantanés quotidiens automatisés dans le tableau de bord. Recherchez la section « Sauvegardes » ou « Restauration » et téléchargez-la à partir de là.

Étape 2 : Restaurer les fichiers WordPress via FTP

Connectez-vous à votre serveur à l'aide d'un client FTP. FileZilla est gratuit et fonctionne très bien. Accédez au répertoire racine de WordPress, c'est-à-dire au dossier contenant les fichiers wp-config.php, wp-admin/ et wp-content/.

Téléchargez vos fichiers de sauvegarde ; cela écrasera le contenu actuel du serveur.

Un dossier auquel il faut prêter une attention particulière : /wp-content/uploads/sites/. C'est là que le multisite stocke les fichiers multimédias propres à chaque sous-site, classés dans des sous-répertoires numérotés correspondant à chaque site du réseau. On a tendance à l'oublier lors d'une restauration, et c'est souvent là que se situent la plupart des problèmes liés aux fichiers multimédias après la restauration.

Avant de procéder au téléchargement : cette opération écrasera votre installation actuelle. Toutes les modifications apportées après la création de la sauvegarde seront perdues. Si certains éléments du serveur de production méritent d'être conservés, téléchargez-les avant de commencer.

Étape 3 : Importer la base de données via phpMyAdmin

Ouvrez votre panneau d'hébergement et lancez phpMyAdmin. Dans le volet de gauche, sélectionnez votre base de données WordPress. Rendez-vous dans l'onglet « Import », cliquez sur « Choisir un fichier », puis sélectionnez votre fichier de sauvegarde .sql. Cliquez ensuite sur « Go ».

phpMyAdmin est l'outil de gestion de bases de données accessible via un navigateur que la plupart des hébergeurs proposent par défaut. Si vous ne l'avez jamais utilisé auparavant, il peut sembler plus complexe qu'il ne l'est en réalité. Vous n'utiliserez que l'onglet « Importer ».

Avant de procéder à l'importation : les bases de données multisites volumineuses peuvent dépasser la limite de temps d'exécution par défaut de phpMyAdmin. Si votre base de données dépasse quelques centaines de mégaoctets, l'opération risque d'être interrompue avant la fin.

Si cela se produit, utilisez plutôt WP-CLI : exécutez wp db import backup.sql depuis la ligne de commande de votre serveur. Vous pouvez également contacter votre hébergeur et lui demander d'effectuer l'importation. Il s'agit d'une demande courante, et la plupart des équipes d'assistance y répondent rapidement.

Étape 4 : Mettre à jour le fichier wp-config.php si nécessaire

Si vous effectuez la restauration sur le même serveur et dans la même base de données, vous pouvez ignorer cette étape. Si vous effectuez la restauration sur un nouveau serveur ou dans une nouvelle base de données, ouvrez le fichier wp-config.php via FTP et modifiez ces quatre constantes pour les adapter au nouvel environnement :

• DB_HOST
• DB_NAME
• DB_USER
• DB_PASSWORD

Pour les installations multisites, vérifiez également la constante DOMAIN_CURRENT_SITE. Cette constante indique à WordPress sur quel domaine le réseau est hébergé.

Si cela ne correspond pas au nom de domaine réel, vous tomberez dans une boucle de redirection lors du chargement du site. Il doit correspondre aux informations contenues dans les tables wp_site et wp_blogs de votre base de données.

Étape 5 : Vider le cache des règles de réécriture et vérifier le chargement des sous-sites

Connectez-vous à l'interface d'administration. Allez dans Paramètres » Liens permanents, puis cliquez sur « Enregistrer les modifications » sans rien modifier.

Vous n'avez pas besoin de modifier la structure des permaliens. Il suffit d'enregistrer pour que WordPress régénère le fichier .htaccess avec les règles de réécriture multisite appropriées.

Vérifiez ensuite vos sous-sites. Cliquez sur quelques-uns de ceux qui figurent dans la liste des sites de l'administration du réseau. Ils devraient s'afficher correctement.

Si l'une d'entre elles renvoie une erreur 404 ou le message « Page introuvable », il se peut que les règles de réécriture du fichier .htaccess n'aient pas été mises à jour correctement. Reportez-vous à la section « Dépannage » ci-dessous.

Bonus : Restauration d'un seul sous-site (et transfert vers un nouveau serveur)

Toutes les pannes multisites ne nécessitent pas une restauration complète du réseau. Si un seul sous-site est en panne, la restauration de l'ensemble du réseau entraînerait la perte de toutes les modifications apportées aux autres sites du réseau depuis la dernière sauvegarde. Cela n'en vaut généralement pas la peine.

Duplicator Pro vous permet de créer une sauvegarde d'un seul sous-site ou de n'importe quelle combinaison de sites du réseau. Lorsque vous restaurez cette sauvegarde, seuls ces sites sont restaurés. Tout le reste reste inchangé.

Fonctionnement de la restauration sélective par sous-site

Tout réside dans la manière dont la sauvegarde est créée. Lorsque vous créez une nouvelle sauvegarde dans Duplicator Pro, les paramètres de sauvegarde comprennent un sélecteur de sous-site dans la section « Multisite ».

Sélectionnez le sous-site que vous souhaitez sauvegarder. Lancez la sauvegarde. Duplicator n'inclut que le contenu de ce site et les tables de base de données correspondantes.

Lorsque vous effectuez une restauration, Duplicator restaure exactement le contenu de la sauvegarde. Une sauvegarde portant sur un seul sous-site permet de restaurer ce sous-site. Si vous avez sauvegardé l'ensemble du réseau, vous restaurez l'ensemble du réseau.

Pour restaurer, suivez la même procédure que pour la restauration d'un réseau multisite complet. Accédez à la section « Sauvegardes » dans l'administration du réseau et sélectionnez la sauvegarde qui ne contient que le sous-site en question.

Cliquez sur « Restaurer », puis lancez le programme d'installation.

Le réseau reste intact. Seul le sous-site de la sauvegarde est concerné.

Transférer un sous-site vers un serveur autonome

C'est l'une des fonctionnalités les plus utiles de Duplicator que la plupart des gens ignorent. Imaginons que le sous-site d'un client soit devenu trop volumineux pour le réseau et ait besoin de son propre hébergement, ou que vous souhaitiez séparer un sous-site pour le confier à une autre équipe.

Sauvegardez uniquement le sous-site. Sur le serveur de destination, installez Duplicator et téléchargez la sauvegarde sur la page « Importer des sauvegardes ».

Sélectionnez « Convertir le sous-site réseau en site autonome » dans le champ « Type d'installation ». Duplicator convertit alors le sous-site en une installation WordPress autonome à la nouvelle adresse.

Une fois la restauration terminée, vérifiez les points suivants avant de remettre le site : les fichiers multimédias se chargent correctement, les liens permanents fonctionnent et tous les paramètres spécifiques au domaine ont bien été mis à jour pour la nouvelle URL.

Si le sous-site fonctionnait sur un sous-domaine ou un sous-répertoire du réseau, il faudra lui attribuer son propre domaine pointant vers le nouveau serveur. Le protocole SSL devra également être configuré séparément.

Dépannage : lorsque la restauration ne se déroule pas comme prévu

Les restaurations multisites présentent des points de défaillance qui n'apparaissent pas dans les installations sur un seul site. La plupart d'entre eux peuvent être résolus en quelques minutes dès lors que l'on sait à quoi s'en tenir.

Voici à quoi ressemble chacune d'entre elles et comment les aborder.

Les URL des sous-sites renvoient une erreur 404 après la restauration

Ce que vous constatez : le réseau principal se charge, mais lorsque vous cliquez sur un sous-site, vous obtenez une erreur 404 ou un message « Site introuvable ». L'administrateur réseau fonctionne correctement. Ce n'est pas le cas des sous-sites.

Pourquoi cela se produit-il ? WordPress n'a pas régénéré les règles de réécriture après la restauration. Soit le fichier .htaccess n'a pas été mis à jour, soit le bloc de réécriture spécifique au multisite y est tout simplement absent.

Comment y remédier : rendez-vous dans Administration du réseau » Paramètres » Permaliens, puis cliquez sur « Enregistrer les modifications » sans rien modifier. Cela oblige WordPress à réécrire le fichier .htaccess avec les règles de routage multisite correctes. Vérifiez à nouveau vos sous-sites après avoir enregistré.

Si vous obtenez toujours des erreurs 404, ouvrez directement le fichier .htaccess via FTP et vérifiez son contenu.

Un fichier .htaccess standard pour un site unique ne redirigera pas correctement le trafic multisite. Ce fichier doit contenir le bloc de réécriture multisite.

S'il manque, désactivez puis réactivez le réseau pour le régénérer, ou copiez le bloc correspondant à partir de la documentation WordPress pour votre type de réseau (sous-domaine ou sous-répertoire).

Boucle de redirection sur le domaine principal

Ce que vous constatez : le navigateur affiche le message « ERR_TOO_MANY_REDIRECTS » lors du chargement du domaine principal du réseau. Le site ne s'affiche jamais.

Pourquoi cela se produit : la constante DOMAIN_CURRENT_SITE dans le fichier wp-config.php ne correspond pas au domaine enregistré dans les tables wp_site et wp_blogs de votre base de données. Ce décalage est fréquent après une restauration sur un domaine différent ou lorsque le domaine a changé à un moment donné entre la création de la sauvegarde et sa restauration.

Comment y remédier : Ouvrez le fichier wp-config.php via FTP. Recherchez la ligne qui dit define( 'DOMAIN_CURRENT_SITE', 'yourdomain.com' ); et vérifiez que le nom de domaine correspond exactement à celui enregistré dans la table wp_site de votre base de données. Ouvrez phpMyAdmin, sélectionnez la base de données, puis vérifiez la colonne « domaine » dans la table wp_site. Modifiez le fichier wp-config.php en conséquence, enregistrez-le, puis actualisez le site.

Fichiers multimédias manquants sur l'ensemble des sous-sites

Ce que vous constatez : les images ne s'affichent plus sur l'ensemble du site. Les URL des fichiers multimédias renvoient vers des chemins d'accès tels que /wp-content/uploads/sites/2/2025/04/image.png, mais génèrent des erreurs 404.

Pourquoi cela se produit : la sauvegarde n'a pas inclus l'intégralité du répertoire /wp-content/uploads/sites/. Dans un site multisite, les fichiers multimédias de chaque sous-site sont stockés dans un sous-répertoire numéroté situé sous uploads/sites/. Si la restauration n'a concerné que le dossier racine uploads, les fichiers multimédias propres à chaque sous-site ont disparu.

Comment résoudre ce problème : vérifiez si la sauvegarde comprenait le répertoire uploads/sites/. Si vous utilisez Duplicator Pro, vérifiez les paramètres d'archivage de la sauvegarde utilisée. Si ce répertoire a été exclu, vous devrez récupérer les fichiers multimédias à partir d'une autre sauvegarde ou les restaurer manuellement via FTP à partir d'une sauvegarde distincte des fichiers multimédias.

Si vous utilisez Duplicator Cloud, une restauration partielle ciblant uniquement la médiathèque permet de corriger ce problème sans déclencher une restauration complète du réseau.

phpMyAdmin expire pendant l'importation de la base de données

Ce que vous constatez : la barre de progression de l'importation s'arrête. phpMyAdmin renvoie une erreur de délai d'attente avant la fin du fichier .sql.

Pourquoi cela se produit-il ? Les bases de données multisites sont volumineuses, et la durée d'exécution maximale par défaut de phpMyAdmin est trop courte. Le processus d'importation atteint la limite de temps avant d'avoir terminé.

Comment y remédier : Passez à WP-CLI. Depuis la ligne de commande de votre serveur, exécutez wp db import backup.sql à partir du répertoire racine de WordPress. Il prend en charge les bases de données volumineuses sans limite de temps. Si vous n'avez pas accès à la ligne de commande, contactez votre hébergeur et demandez-lui d'effectuer l'importation. Vous pouvez également diviser le fichier .sql en plusieurs parties plus petites et les importer les unes après les autres.

Le programme d'installation affiche une page blanche ou une erreur 500

Ce que vous constatez : lorsque vous accédez à votredomaine.com/installer.php, vous obtenez une page blanche ou un message d'erreur 500 (erreur interne du serveur).

Pourquoi cela se produit-il ? Il y a deux causes courantes. Soit les droits d'accès du fichier installer.php sont incorrects et le serveur refuse de l'exécuter, soit la limite de mémoire PHP sur le serveur de destination est trop faible pour traiter l'archive.

Comment y remédier : Vérifiez que le fichier installer.php dispose des droits d'accès 644. Vous pouvez définir ces droits dans FileZilla en cliquant avec le bouton droit sur le fichier et en sélectionnant « Droits d'accès au fichier ». Vérifiez ensuite votre Limite de mémoire PHP. Pour les archives multisites, 256 Mo constituent le minimum requis. 512 Mo constituent une valeur plus sûre. Si vous ne pouvez pas modifier directement le fichier php.ini, ajoutez php_value memory_limit 512M dans votre fichier .htaccess ou demandez à votre hébergeur de l'augmenter. C'est une demande courante.

Foire aux questions (FAQ)

Votre réseau est de nouveau opérationnel. Voici ce qu'il faut faire avant la prochaine crise.

La partie la plus difficile consiste à rétablir un réseau multisite. En revanche, veiller à ce qu'il reste récupérable est l'étape que la plupart des gens négligent, jusqu'à ce qu'ils se retrouvent dans la même situation six mois plus tard.

Voici quelques choses qu'il serait bon de faire avant de fermer cet onglet. Tout d'abord, si vous n'avez pas encore programmé de sauvegardes automatiques, faites-le dès aujourd'hui.

Duplicator Pro prend en charge les sauvegardes programmées à la fréquence qui convient le mieux à votre réseau : toutes les heures, tous les jours, toutes les semaines ou tous les mois, et les transfère automatiquement vers un espace de stockage dans le cloud. Une sauvegarde qui s'effectue sans que vous ayez à vous en soucier est la seule qui sera réellement disponible lorsque vous en aurez besoin.

Deuxièmement, générez une URL de reprise après sinistre pour chaque site important du réseau. Cela prend deux minutes par site.

Troisièmement, si vous stockez vos sauvegardes dans Duplicator Cloud, configurez dès maintenant le connecteur de restauration. Il doit être en place avant que le problème ne survienne, et non après.

Plus d'1,5 million de professionnels de WordPress utilisent Duplicator Pro pour s'assurer de ne pas perdre leurs sites web. Passez à la version supérieure dès aujourd'hui pour bénéficier de sauvegardes automatisées, d'URL de reprise après sinistre, d'une restauration depuis le cloud sans accès à wp-admin et d'une prise en charge complète de WordPress Multisite.

Si ce tutoriel vous a été utile, n'hésitez pas à ajouter ces guides à vos favoris :

• Comment sauvegarder WordPress Multisite
• Comment migrer WordPress Multisite
• Comment convertir WordPress Multisite en un site unique
• Les meilleurs plugins WordPress de sauvegarde multisite pour la sécurité du réseau
• Comment CodeVidia migre les réseaux multisites en toute sécurité et facilement