Comment cloner un site WordPress en local

Quand tu commences à toucher sérieusement à un site — sous WordPress ou n’importe quel autre système — tu dois intégrer une règle de base avant de commencer : ne fais pas d’expériences en production.

Pour plusieurs raisons :

1. Parce que les résultats peuvent être catastrophiques si tu ne sais pas bien ce que tu touches ou si tu n’as pas de sauvegarde.
2. Parce qu’à cause de ça, pendant que tu restaures tout, tu peux te prendre un pic de stress franchement évitable.
3. Et parce que monter une copie en local ne te prendra qu’une demi-heure et que tu m’en remercieras éternellement.

Je répète :

D’abord tu montes une copie locale. Ensuite tu touches. Pas l’inverse.

Ces derniers jours, comme je suis en train de modifier mon site en profondeur, j’ai dû le faire ; j’en ai donc profité pour créer ce tutoriel.

Mon site avait plusieurs années de contenu, 250 articles, des images accumulées depuis 2013 et une taille suffisante pour que Duplicator reste bloqué à mi-chemin deux fois avant de fonctionner.

C’est aussi ici. Les erreurs — et leurs solutions — incluses.

À quoi sert un clone local de WordPress

Une copie locale te permet de travailler sur ton ordinateur sans toucher au vrai site.

Utile pour : tester des plugins, changer de thème, vérifier la base de données, préparer une migration, faire un audit technique, installer Polylang, modifier du CSS ou casser des choses sans que Google, tes utilisateurs ou ton client ne s’en rendent compte.

Dans mon cas, l’objectif était double :

1. Changer complètement le design, en passant d’un site de capture de leads à un magazine numérique.
2. Préparer le site à la traduction assistée par IA. Un développement maison avec un certain niveau de risque, puisqu’il implique de toucher à plusieurs choses en même temps.

Dans tous les cas, le processus est le même si tu veux recatégoriser automatiquement, changer de thème, ajouter un gros plugin du type WooCommerce ou simplement disposer d’un environnement de test avant de toucher à quelque chose de sérieux.

Les outils que j’ai utilisés

• LocalWP: pour créer l’environnement WordPress local.
• Duplicator: pour exporter le site de production.
• cPanel: le panneau de contrôle de l’hébergement pour télécharger manuellement le dossier des images.
• WP-CLI: inclus dans LocalWP, pour corriger des options internes de WordPress.

Tout est gratuit.

Guide pas à pas pour cloner ton WordPress en local

Maintenant que tu connais les outils, passons au pas à pas, qui est un peu plus long que d’habitude.

Quoi qu’il en soit, pour que tu te fasses une idée, en 30 minutes environ tu auras tout prêt, selon les problèmes qui se présenteront. Parce que si ton site est petit et ne renvoie aucune erreur, il est possible que tu aies terminé en moins de dix minutes.

Peu d’investissements sont plus rentables que celui-là.

Étape 1 : installer LocalWP

LocalWP crée des installations WordPress en local sans avoir à configurer Apache, MySQL et PHP à la main. Tu n’as pas besoin de XAMPP, ni de WAMP, ni de LAMP.

Tu l’installes, tu crées un nouveau site et, en deux minutes, tu as un WordPress propre qui tourne sur ton ordinateur.

Dans mon cas, je l’ai appelé yg, donc LocalWP lui a attribué le domaine local https://yg.local avec cet environnement :

Champ	Valeur
Serveur	nginx
PHP	8.2
Base de données	MySQL
WordPress	Installation propre

Avec ça, c’est suffisant pour commencer.

Étape 2 : vérifier que le WordPress local s’ouvre

Avant d’importer quoi que ce soit, ouvre le site local et connecte-toi au panneau :

• https://yg.local
• https://yg.local/wp-admin

S’il charge et que tu peux te connecter, l’environnement est prêt. N’installe rien pour l’instant. Ne touche pas aux réglages. Vérifie seulement que ça fonctionne.

Étape 3 : installer Duplicator sur le vrai site

Connecte-toi au WordPress de production (pas au local) et installe Duplicator :

Extensions > Ajouter > Duplicator

Installe-le et active-le.

Important : Duplicator s’installe en production. L’idée est de générer un paquet du vrai site pour l’importer ensuite dans LocalWP.

Étape 4 : créer une copie avec Duplicator

Depuis le panneau de production, va dans :

Duplicator > Packages

Crée un nouveau paquet avec un nom qui indique à quoi il sert. Moi, j’ai utilisé :

yagogonzalez-copia-local-fase0

L’analyse initiale a signalé que le site était volumineux. Rien d’étrange pour des sites avec des années de contenu.

Le problème est arrivé au moment de construire le paquet :

Couldn't close zip archive

Le serveur n’a pas pu fermer l’archive ZIP.

Ça ne veut pas dire que le site s’est cassé. Ça veut dire que l’hébergement n’a pas pu terminer l’opération, probablement à cause de la taille, du temps d’exécution ou des limites de mémoire.

Premier problème à résoudre.

Étape 5 : essayer DupArchive si le ZIP échoue

Duplicator propose une alternative quand le ZIP échoue : DupArchive.

Pour cela, il faut changer le moteur d’archive de ZIP à DupArchive. Le paquet est alors généré en .daf au lieu de .zip.

Le changement se fait depuis :

Duplicator > Réglages > Sauvegardes > Archive

Là, cherche Archive Engine et remplace ZipArchive par DupArchive.

Ensuite, enregistre les changements.

Tout est prêt ?

Eh bien non. Nouvelle erreur :

La taille totale des fichiers et de la base de données dépasse la limite de 500 Mo

La copie pesait environ 1,33 Go. Tout changer comme ça ne servait pas non plus.

La solution : ne pas tout mettre dans le paquet.

Étape 6 : créer le paquet sans le dossier uploads

Le dossier qui fait exploser le poids de n’importe quel WordPress ayant quelques années de vie est wp-content/uploads/. 

C’est là que se trouvent les images, PDF, miniatures, fichiers WebP et tout ce qui a été mis en ligne depuis le premier jour.

Pour réduire le paquet à télécharger, dans Duplicator j’ai activé les filtres de fichiers et exclu :

• wp-content/uploads/
• wp-content/cache/
• wp-content/upgrade/
• wp-content/backups-dup-lite/
• wp-content/plugins/duplicator/backups/

Avec ça, le paquet inclut l’essentiel pour reconstruire le site : base de données, WordPress, thème, plugins, configuration, articles, pages, taxonomies, ACF, Yoast et réglages internes.

Les images, on les télécharge à part. Je t’explique comment à l’étape 8.

Étape 7 : télécharger les fichiers de Duplicator

Une fois le paquet généré, Duplicator crée deux fichiers :

• installer.php
• fichier .zip ou .daf

Télécharge les deux.  

Ce sont eux qui permettent de reconstruire le site en local. L’installateur se charge d’extraire le paquet, d’importer la base de données, de remplacer les URL et d’ajuster les chemins.

Étape 8 : télécharger le dossier uploads

Comme uploads n’était pas inclus dans le paquet, il faut le télécharger manuellement depuis l’hébergement.

Le chemin habituel dans WordPress est :

/public_html/tudominio.com/wp-content/uploads/

Si tu as un hébergement classique, tu peux le télécharger depuis les options du gestionnaire de fichiers de cPanel. C’est ce que j’ai fait.

Si ce n’est pas possible par cette voie, il faudra le faire à l’ancienne, en le téléchargeant par FTP ou SFTP directement sur l’ordinateur avec FileZilla ou un outil similaire.

Conseil: ne compresse pas le dossier sur le serveur. Cela remettrait de la charge sur l’hébergement et pourrait échouer comme Duplicator. Le téléchargement direct est plus lent, mais plus sûr.

Étape 9 : préparer LocalWP pour importer la copie

Avec les deux fichiers de Duplicator téléchargés, retourne dans LocalWP :

1. Pour le site local : clique sur Stop site.
2. Ouvre le dossier du site : clique sur Site folder.
3. Entre dans app > public.
4. Supprime le contenu de public (le WordPress propre créé par LocalWP).
5. Copie-y les deux fichiers de Duplicator.

Important: il faut supprimer le contenu de public, pas le dossier public.

Le dossier doit exister et ne contenir que les deux fichiers téléchargés :

• installer.php
• copia-local.daf

Ensuite, démarre le site : clique sur Start site.

Étape 10 : exécuter l’installateur de Duplicator en local

Ouvre l’installateur dans le navigateur :

https://yg.local/installer.php

L’installateur détecte le paquet et lance le processus.

Pour se connecter à la base de données locale, utilise les données de LocalWP :

Champ	Valeur
Database Host	localhost
Database Name	local
User	root
Password	root

Comme il s’agissait d’une installation locale vide (celle que le programme te crée par défaut au début), indique que tu acceptes que Duplicator efface la base de données précédente. 

Pas de souci : il ne faisait qu’effacer le WordPress propre de LocalWP, pas le vrai site.

Ensuite, Duplicator effectue le remplacement des URL :

• Old URL: https://yagogonzalez.com
• New URL: https://yg.local

Une fois terminé, tu peux déjà entrer dans le WordPress local.

Important: après l’import de la base de données, l’utilisateur et le mot de passe sont ceux du vrai site, pas ceux créés au départ dans LocalWP.

Étape 11 : nettoyer les fichiers d’installation

Duplicator supprime normalement les fichiers de l’installateur à la fin :

• installer.php
• fichier .daf
• dossier dup-installer
• logs d’installation

En production, c’est important pour la sécurité. En local, c’est moins critique, mais mieux vaut laisser ça propre.

Vérifie qu’ils n’existent plus après l’installation avant de continuer.

Étape 12 : copier uploads dans le WordPress local

Avec le site arrêté (Stop site) dans LocalWP, entre dans app > public > wp-content et copie là le dossier uploads que tu as téléchargé.

La structure correcte :

<em>wp-content/</em>
├── plugins/

├── themes/

└── uploads/

    ├── 2013/

    ├── 2014/

    ...

    └── 2026/

Ce qui ne doit pas arriver :

wp-content/uploads/uploads/2026/

Ce double uploads/uploads est une erreur classique quand on compresse en zip avant de télécharger, et ça casse tous les chemins des images.

Étape 13 : corriger le problème des images cassées

Dans mon cas, c’est là qu’est arrivé le plus gros problème (parce qu’inattendu) : le site chargeait, mais les images ne s’affichaient pas. Et ce n’était pas à cause du chemin avec le double upload.

Le problème venait de l’URL que WordPress générait pour les images :

https://yg.local/C:/Users/pcadmin/Local Sites/yg/app/public/wp-content/uploads/2026/06/imagen.webp

Tout ce qui était en gras était en trop. La bonne URL devait être :

https://yg.local/wp-content/uploads/2026/06/imagen.webp

WordPress avait enregistré dans l’option upload_path un chemin absolu Windows :

C:/Users/pcadmin/Local Sites/yg/app/public/wp-content/uploads

Pour corriger ça, ouvre Site shell dans LocalWP et exécute ces trois commandes l’une après l’autre :

wp --url=https://yg.local option delete upload_path

wp --url=https://yg.local option delete upload_url_path 

wp --url=https://yg.local cache flush

Une fois fait, au rechargement, les images apparaissaient bien.

Le problème, c’est que plusieurs Warnings (avertissements) apparaissaient aussi.

Étape 14 : corriger les warnings visibles

Comme je te le disais, ce warning apparaissait sur le site local :

Constant WP_POST_REVISIONS already defined

Ici, j’ai demandé à ChatGPT, parce que je n’avais aucune idée de la façon de résoudre ça.

Le problème venait de functions.php du thème, qui définissait WP_POST_REVISIONS sans vérifier si elle était déjà définie ailleurs.

La correction :

<em>if ( ! defined( 'WP_POST_REVISIONS' ) ) {</em>
<em>    define( 'WP_POST_REVISIONS', false );</em>
<em>}</em>

Si dans ton cas la valeur est différente, respecte simplement la tienne :

<em>if ( ! defined( 'WP_POST_REVISIONS' ) ) {</em>
<em>    define( 'WP_POST_REVISIONS', <strong>5</strong> );</em>
<em>}</em>

Je l’ai modifié depuis l’éditeur de fichiers du thème WordPress (Apparence > Éditeur de fichiers de thèmes), j’ai enregistré le fichier et voilà.

Étape 15 : nettoyer la production

Une fois la copie locale fonctionnelle, retourne sur le vrai site et supprime les traces de Duplicator:

1. Duplicator > Packages :  supprime les paquets créés.
2. Extensions > Extensions installées : désinstalle Duplicator.

Ça n’affecte pas la copie locale. Ça évite seulement de laisser en production de gros paquets et des installateurs inutiles.

Ce n’est pas obligatoire, mais c’est recommandé.

Étape 16 : tester le clone local

Vérifie plusieurs URL avant de continuer.  

Dans mon cas, j’ai vérifié :

• La page d’accueil.
• Un article.
• Une catégorie.
• Une sous-catégorie.
• Une étiquette.

Je l’ai fait ainsi parce que chacune utilise un modèle différent :

• https://yg.local
• https://yg.local/ruta-de-escape
• https://yg.local/tecnologia
• https://yg.local/ocio/series
• https://yg.local/negocio

Quatre choses à vérifier :

1. Le site charge.
2. Les images s’affichent.
3. Le design est identique à celui de la production.
4. Les liens internes pointent vers yg.local, pas vers yagogonzalez.com.

Ce dernier point est essentiel. Si tu cliques sur un article et qu’il t’envoie en production, tu as encore des URL mal remplacées.

Étape 17 : créer un point de restauration avant de continuer

Cette étape est, elle aussi, optionnelle, mais recommandée.

Avant de te mettre à faire les changements dont tu as besoin en local, ou à toucher à quelque chose de sérieux, crée un point de restauration.

Dans LocalWP, tu peux cloner le site :

Clone site

Dans mon cas, j’ai créé une copie appelée yg-pre-polylang.

La logique :

• yg = site local de travail.
• yg-pre-polylang = copie propre avant de toucher à quoi que ce soit.

Si quelque chose part en vrille, il n’y a pas besoin de refaire toute la migration de production depuis zéro : je prends cette copie propre et je travaille dessus. Pas sans l’avoir de nouveau clonée avant, évidemment.

Problèmes courants dans ce processus

Les migrations locales ne sortent presque jamais parfaites du premier coup. Je regroupe ici ceux qui sont apparus dans ce cas.

Le ZIP de Duplicator a échoué

Erreur : Couldn't close zip archive

Cause : limites du serveur (taille, temps d’exécution, mémoire).

Solution : essayer DupArchive ou exclure les dossiers lourds du paquet.

DupArchive avait une limite de taille

Erreur : le paquet dépassait 500 Mo.

Solution : exclure wp-content/uploads/ et télécharger ce dossier à part.

Les images ne chargeaient pas

Cause : WordPress utilisait un chemin absolu Windows comme s’il s’agissait d’une URL publique.

Solution :

wp option delete upload_path

wp option delete upload_url_path

Warning PHP pour constante déjà définie

Cause : WP_POST_REVISIONS définie deux fois dans functions.php.

Solution : envelopper la définition avec if ( ! defined(…) ).

Conclusion

Si ton site pèse peu, Duplicator fait tout tout seul. Mais s’il a des années de contenu et des images accumulées, le plus courant est de diviser le processus en deux :

• Duplicator = base de données + WordPress + thème + plugins
• FTP/SFTP = dossier uploads

Et ensuite vérifier les chemins, les images, les warnings et les liens internes avant de toucher à quoi que ce soit de sérieux.

La copie locale ne sert à rien si elle ne fonctionne pas vraiment.

Et si tu vas toucher à quelque chose de délicat — multilingue, refonte, gros plugins, migrations SEO — le faire directement en production, c’est prendre des risques inutiles.

Tu as les outils. Ils sont gratuits. Et le processus, même s’il n’est pas automatique, se fait en une demi-heure.

Souviens-toi :

D’abord le local. Ensuite les tests. Puis la production. Dans cet ordre.

Comme Bale et le golf, mais appliqué à WordPress.

Au passage, je te laisse ici la suite de cet article : comment optimiser la vitesse de WPLocal.