Déplacer un site WordPress vers un nouvel hébergement, créer une copie de staging ou préparer une sauvegarde complète devient vite fastidieux lorsque l’on doit manipuler les fichiers et la base de données séparément. Le plugin Duplicator WordPress simplifie ce travail en regroupant le site dans une archive transférable, puis en facilitant sa réinstallation. Voici comment l’utiliser, dans quels cas il est pertinent et quelles précautions prendre pour éviter une migration incomplète.
L’essentiel à retenir avant de cloner un site WordPress
- Duplicator regroupe les fichiers, la base de données, le thème et les extensions dans une archive.
- Il convient surtout aux migrations complètes, aux copies de test et aux changements de domaine.
- Une sauvegarde indépendante reste indispensable avant toute opération de transfert.
- La réussite dépend aussi de l’hébergement cible, de PHP, de la base de données et des limites d’importation.
- Après l’installation, il faut tester les URLs, formulaires, médias, comptes et paiements.
À quoi sert réellement Duplicator pour WordPress
Duplicator est une extension conçue pour copier, migrer et sauvegarder un site WordPress complet. Elle prépare généralement deux éléments principaux : une archive contenant les données du site et un installateur qui permet de restaurer cette archive sur un autre emplacement.
Cette méthode évite de déplacer manuellement les fichiers avec un client FTP, d’exporter la base de données séparément, puis de modifier à la main les paramètres de connexion et les anciennes adresses. D’après la fiche publiée sur WordPress.org, l’extension existe en version gratuite, avec des fonctions supplémentaires selon l’édition choisie et la version disponible.
Ce qui est inclus dans une copie complète
Une archive peut contenir les fichiers de WordPress, les extensions, le thème actif, les médias, les réglages et la base de données. C’est ce qui permet de retrouver un environnement presque identique sur un nouveau serveur ou un sous-domaine.
Je distingue toutefois une copie de site d’une sauvegarde professionnelle. Une copie locale conservée sur le même serveur ne protège pas contre une panne de l’hébergement. Pour une vraie stratégie de sécurité, je conserve au moins une sauvegarde hors du serveur de production et je vérifie périodiquement qu’elle peut être restaurée.
Dans quels cas cette extension fait gagner du temps
Le scénario le plus courant consiste à changer d’hébergeur. On crée l’archive sur l’ancien serveur, on la transfère vers le nouveau, puis on lance l’installation avec les identifiants de la nouvelle base de données. Le domaine peut rester identique, ou être remplacé pendant la migration.
Duplicator est aussi pratique pour créer un site de staging, c’est-à-dire une copie de travail séparée du site public. Je trouve cette approche particulièrement utile avant une refonte graphique, une mise à jour importante du thème ou l’ajout d’une extension qui touche à la base de données.
Les usages les plus pertinents
- Changer d’hébergeur sans reconstruire le site depuis zéro.
- Créer une copie de production sur un sous-domaine de test.
- Dupliquer un site pour lancer un projet proche avec une autre identité visuelle.
- Restaurer un site après une erreur de manipulation ou une panne.
- Préparer une sauvegarde complète avant une opération risquée.
La limite apparaît lorsque l’on veut synchroniser régulièrement deux sites qui évoluent en parallèle. Une duplication complète peut écraser des contenus récents sur la destination. Pour ce type de besoin, il faut une méthode de déploiement ou de synchronisation plus contrôlée, pas seulement une nouvelle archive.
Comment migrer un site avec Duplicator étape par étape
La procédure reste accessible, mais elle demande de la méthode. Une migration réussie ne consiste pas seulement à télécharger un fichier ZIP. Il faut aussi préparer la destination, vérifier les accès et contrôler le site après restauration.
1. Préparer l’ancien et le nouvel environnement
Avant de créer l’archive, je commence par supprimer les extensions inutilisées, vider les caches et vérifier que le site fonctionne correctement. Cela réduit la taille du paquet et évite de transférer des fichiers temporaires inutiles.
Sur le nouvel hébergement, je prépare une base de données vide, un utilisateur associé avec les droits nécessaires et un accès aux fichiers du domaine. Je vérifie également la version de PHP, l’espace disque disponible et les limites d’importation définies par l’hébergeur.
2. Construire l’archive
Dans l’administration WordPress, la création d’un paquet permet généralement de sélectionner les fichiers et les tables à inclure. Pour une première migration, je recommande de conserver la configuration complète, sauf si l’on sait précisément pourquoi un dossier doit être exclu.
Une fois l’analyse terminée, l’extension génère l’archive et le fichier d’installation. Je télécharge les deux éléments sur mon ordinateur ou je les transfère directement vers le serveur cible. Il ne faut pas supprimer la copie originale avant d’avoir validé la nouvelle installation.
3. Restaurer le site sur le serveur cible
Les fichiers sont placés dans le dossier du nouveau domaine ou du sous-domaine. L’installateur est ensuite exécuté depuis ce nouvel emplacement, puis les informations de connexion à la base de données sont renseignées.
Si le domaine change, l’outil peut remplacer les anciennes adresses enregistrées dans la base de données. Cette étape est essentielle pour éviter les liens cassés, les images absentes ou les redirections vers l’ancien site. Les données stockées dans des formats particuliers peuvent toutefois nécessiter une vérification manuelle.
4. Finaliser et nettoyer
Après la restauration, je me connecte à l’administration, j’enregistre à nouveau les permaliens et je vide les caches. Je contrôle ensuite la page d’accueil, plusieurs articles, les médias, les formulaires, les comptes utilisateurs et les éventuels paiements.
Les fichiers d’installation et les archives ne doivent pas rester accessibles publiquement. Leur suppression est une mesure de sécurité obligatoire, surtout si l’archive contient la base de données ou des informations sensibles.
Version gratuite ou offre payante selon le projet
La version gratuite suffit souvent pour une migration classique d’un petit site vitrine ou d’un blog. Elle convient lorsque l’on peut manipuler soi-même les fichiers, créer la base de données et intervenir sur le nouvel hébergement.
Les offres payantes deviennent intéressantes lorsque l’on gère plusieurs sites, des archives volumineuses ou des migrations répétées. Elles peuvent proposer davantage d’automatisation, des sauvegardes planifiées, des stockages externes, des migrations simplifiées ou des fonctions adaptées aux sites plus complexes.
| Besoin | Choix raisonnable | Point de vigilance |
|---|---|---|
| Petit site vitrine | Version gratuite | Vérifier les limites du serveur |
| Copie vers un staging | Version gratuite ou payante | Ne pas envoyer les e-mails de test aux vrais clients |
| Grand site ou boutique | Offre avec automatisation et support | Tester la base de données et les paiements |
| Plusieurs sites clients | Fonctions avancées et stockage externe | Centraliser les sauvegardes hors production |
Je ne choisirais pas une licence uniquement parce qu’elle annonce une migration en un clic. Le vrai critère est le temps gagné sur votre environnement précis. Un petit site peut être transféré sans option avancée, tandis qu’une boutique avec plusieurs gigaoctets de médias et des commandes actives mérite une procédure plus robuste.
Les erreurs qui font échouer une migration
La plupart des problèmes ne viennent pas de l’archive elle-même, mais d’un environnement cible mal préparé. Un manque d’espace disque, une version de PHP incompatible ou une limite d’exécution trop basse peut interrompre l’installation avant sa fin.
Ne pas vérifier la taille du site
Un site avec une médiathèque importante peut produire une archive très lourde. Avant de lancer l’opération, je mesure la taille des fichiers et de la base de données, puis je compare ces valeurs à l’espace disponible sur le serveur cible.
Oublier les données dynamiques
Une boutique, un site de réservation ou un espace membre continue de recevoir des données pendant la migration. Si l’archive est créée plusieurs heures avant le basculement, elle peut ne pas contenir les dernières commandes ou inscriptions. Dans ce cas, je planifie une courte fenêtre de maintenance et je réalise une dernière copie juste avant le changement.
Confondre copie et synchronisation
Restaurer une archive sur un site existant peut remplacer des contenus, des réglages et des utilisateurs. Je considère toujours la destination comme potentiellement écrasée, même lorsque l’opération semble réversible. Une sauvegarde séparée de la destination réduit fortement le risque.
Lire aussi : Polylang vs WPML - Lequel choisir pour votre site multilingue ?
Oublier les réglages externes
Le site peut fonctionner tout en ayant des services mal configurés. Il faut vérifier les clés API, l’envoi d’e-mails, les tâches cron, le certificat SSL, les connexions à un CDN et les webhooks de paiement. Une page qui s’affiche n’est pas une preuve que la migration est terminée.
La checklist à suivre après le transfert
Je réserve toujours quelques minutes à une vérification fonctionnelle. Elle permet de repérer les erreurs invisibles lors d’un simple parcours de la page d’accueil.
- Tester la connexion à l’administration et les rôles utilisateurs.
- Ouvrir plusieurs pages, articles, catégories et fichiers PDF.
- Vérifier les images, les galeries et les liens internes.
- Envoyer un formulaire de contact et contrôler la réception.
- Tester le panier, le paiement et les e-mails sur une boutique.
- Contrôler les réglages de confidentialité et les cookies.
- Régénérer les permaliens et vider les caches.
- Vérifier les redirections, le certificat SSL et le fichier robots.txt.
- Supprimer l’installateur et les archives accessibles depuis le web.
Pour un changement de domaine, je surveille aussi les redirections et les erreurs 404 pendant les premiers jours. Les moteurs de recherche, les outils d’analyse et les services d’e-mail doivent parfois être reconfigurés séparément. Cette phase de contrôle fait souvent la différence entre une migration simplement terminée et une migration réellement propre.
Quand Duplicator est le bon choix pour votre site
Je recommande cette extension lorsque l’objectif est clair : déplacer ou reproduire un site entier avec ses fichiers, sa base de données et ses réglages. Elle apporte un cadre beaucoup plus pratique qu’un transfert manuel, surtout pour les utilisateurs qui ne veulent pas intervenir directement dans chaque table de la base de données.
Elle ne remplace toutefois ni une sauvegarde externe, ni une vérification après migration, ni une stratégie de déploiement pour les projets qui changent chaque jour. Pour un site vitrine simple, la version gratuite peut largement suffire. Pour une boutique, un réseau de sites ou un environnement professionnel, il faut surtout prévoir une procédure testée, une copie de secours et un plan de retour en arrière.
La meilleure méthode reste donc assez simple. Je crée une archive propre, je prépare soigneusement le serveur cible, je teste la copie sur un environnement contrôlé, puis je ne bascule le domaine qu’après avoir vérifié les fonctions importantes. Cette discipline évite que le gain de temps promis par une extension de migration se transforme en longue réparation après coup.
