- Site WordPress
Local (ex Local by Flywheel) : le guide complet
Article publié par Kévin
ÉvidenceWP accompagne les entreprises qui souhaitent faire de leur présence en ligne un véritable levier commercial.
Découvrez les offres de conception de site WordPress professionnel, les forfaits de maintenance WordPress et l’accompagnement SEO sur mesure, et bénéficiez d’un site conçu pour générer des demandes, des réservations ou des ventes de façon pérenne.
Réservez un appel découverte gratuit pour échanger sur votre projet et identifier la solution la plus adaptée.
Vous avez entendu parler de Local by Flywheel, ou peut être déjà croisé son nouveau nom, Local, en cherchant comment installer WordPress en local sur votre ordinateur ?
Vous êtes au bon endroit. Ce guide complet vous accompagne du téléchargement du logiciel jusqu’au déploiement de votre site vers un hébergement en ligne, en passant par la création de votre premier site WordPress, l’import d’un site déjà existant, et tous les réglages qui font vraiment la différence dans votre environnement local au quotidien.
Que vous découvriez le développement local pour la première fois, ou que vous cherchiez à professionnaliser une pratique déjà installée, vous trouverez ici des réponses concrètes, vérifiées sur source officielle, et surtout utilisables tout de suite pour développer vos sites WordPress avec cet outil de développement gratuit.
L’essentiel à retenir sur le logiciel Local
Avant de vous lancer, un test à faire en deux minutes
Local, autrefois Local by Flywheel, une confusion fréquente à clarifier
Si vous cherchez encore « Local by Flywheel », je comprends la confusion. Ce nom continue de circuler dans les recherches alors qu’il a disparu depuis plusieurs années.
Avant d’aller plus loin, un petit retour en arrière s’impose pour que tout soit clair.
L’outil a changé deux fois de main :
Voilà pourquoi je vous parle de Local tout au long de cet article, même si le mot clé « local by flywheel » continue de faire du volume dans les recherches Google.
Si vous tapez cette expression dans votre moteur de recherche, c’est bien de ce logiciel qu’il est question, seulement sous son identité actuelle. Ce n’est pas un détail anecdotique.
Il me semble essentiel de le souligner, car chercher un support technique ou une extension sous une marque qui n’existe plus vous fait perdre du temps sur des pages obsolètes, souvent écrites avant même le rachat par WP Engine.
Développer en local, pour ceux qui découvrent l’expression, cela signifie simplement faire tourner un site WordPress complet sur votre propre ordinateur, sans connexion internet et sans qu’il soit visible par qui que ce soit d’autre.
C’est exactement ce que permet Local en quelques clics, sans toucher une seule ligne de configuration serveur (et sans y laisser des cheveux blancs, contrairement à certaines installations manuelles).
C’est tout l’objet de cet article : vous montrer comment l’installer, le configurer, l’utiliser au quotidien, et déployer votre travail vers un hébergement en ligne une fois qu’il est prêt.
Pourquoi installer WordPress en local avant de le mettre en ligne
Avant de vous montrer comment installer et configurer Local, il me semble important de vous expliquer pourquoi ce détour par votre ordinateur en vaut la peine.
Ce n’est pas une étape technique de plus qui complique votre travail, c’est au contraire ce qui vous évite le plus de mauvaises surprises une fois le site en ligne.
Voici les six raisons qui font de cette habitude un vrai réflexe professionnel.
Travailler sans risque sur son site en production
Je conçois et je refonds les sites de mes clients dans Local, dans un environnement totalement sécurisé. Rien de ce qui se passe pendant cette phase de travail n’est visible en ligne, ce qui m’évite de casser quoi que ce soit sur un site déjà visité par de vrais internautes.
Ce cloisonnement protège de plusieurs types de mauvaises surprises :
Tant que le travail reste dans Local, vous pouvez avancer, corriger, recommencer si besoin, sans la moindre pression ni le moindre risque pour le site final.
Se prémunir en cas de piratage ou de panne serveur
Ce même réflexe rend service dans un scénario plus grave. Si votre site en ligne est piraté ou tombe en panne suite à un problème serveur, disposer d’une copie de travail sur votre ordinateur, isolée d’internet, vous permet de :
IMPORTANT : cette copie locale ne remplace jamais une vraie stratégie de sauvegarde automatisée et régulière de votre site en ligne, elle vient seulement en complément.
Travailler sans connexion internet
WordPress tourne entièrement sur votre machine avec Local, ce qui veut dire que vous n’avez besoin d’aucune connexion internet pour avancer sur un projet.
Un trajet en train, une coupure de box, une salle de réunion sans wifi chez un client, rien de tout cela ne vous empêche de travailler.
Vous n’êtes pas non plus dépendant de la qualité de la connexion sur place.
Si vous intervenez chez un client dont le wifi est lent ou instable, cela ne ralentit en rien votre travail puisque tout se passe sur votre ordinateur.
Tester thèmes, extensions et mises à jour sans stress
Si vous gérez vous même l’intégralité de votre site, sans passer par un prestataire ou un outil de supervision dédié, installer une copie de votre site dans Local avant chaque mise à jour importante vous permet de vérifier que :
Vous gagnez ainsi en tranquillité d’esprit avant de reproduire la même mise à jour sur votre site en ligne.
Cette méthode reste confortable pour un site unique, mais devient vite pénible à maintenir dès que vous gérez plusieurs sites en parallèle, puisqu’il faut alors dupliquer et tenir à jour autant de copies locales que de sites en ligne.
Local prend aussi tout son sens en amont d’un changement plus structurant, par exemple :
Avant de vous lancer sur votre site en ligne, installez une copie de votre site dans Local et faites-y vos essais.
Vous mesurez ainsi l’ampleur du changement et les difficultés à surmonter, sans le moindre risque pour le site réel, avant de vous engager sur le site en production.
Un chargement plus rapide qu’en ligne
Ce n’est pas qu’une impression. Quand vous naviguez sur un site hébergé en ligne, chaque clic dans l’administration WordPress envoie une requête qui voyage jusqu’au serveur de votre hébergeur, puis revient jusqu’à votre navigateur.
En local, cet aller retour disparaît puisque le serveur tourne directement sur votre ordinateur.
C’est un point que je remarque à chaque fois que je bascule d’un site en ligne vers un projet en local : le tableau de bord répond presque instantanément, sans le moindre temps de chargement perceptible entre deux pages.
Sur un projet où vous enchaînez des dizaines d’allers retours entre les réglages d’une extension et le rendu visuel du site, chaque seconde gagnée sur le chargement s’additionne et change réellement le rythme de travail.
Un environnement cloisonné, une configuration par site
Chaque site créé dans Local dispose de son propre environnement, complètement indépendant des autres sites installés sur votre ordinateur.
Vous choisissez, pour chaque projet, sans que ce choix n’affecte les autres sites en cours :
Autrement dit, vous pouvez faire tourner un vieux site client encore bloqué sur une version de PHP ancienne pour des raisons de compatibilité, pendant que vous développez en parallèle un nouveau projet sur la dernière version disponible, sans le moindre conflit entre les deux.
Imaginez plusieurs boîtes fermées côte à côte sur votre bureau, chacune avec ses propres réglages, plutôt qu’un seul établi partagé où tout le monde doit utiliser les mêmes outils. C’est exactement le principe.
Cette configuration se fait dès la création du site, avec le choix entre un environnement « Preferred », préconfiguré et recommandé pour la majorité des projets, et un environnement « Custom », où vous choisissez précisément chaque brique technique.
Local est-il gratuit ?
Oui, Local est entièrement gratuit, sans version d’essai limitée dans le temps ni fonctionnalité verrouillée derrière un abonnement. C’est écrit noir sur blanc sur la page de téléchargement officielle du logiciel, qui promet la gratuité de façon permanente avec cette phrase « C’est gratuit et le sera toujours ».
Ce n’est pas toujours resté aussi simple. L’histoire de la gratuité de Local mérite d’être racontée, elle éclaire aussi certains éléments que vous croiserez encore en ligne :
Si vous tombez encore sur d’anciens articles ou d’anciennes captures mentionnant Local Pro comme une offre séparée, c’est justement pour ça, ils datent d’avant cette bascule.
Aujourd’hui, il n’existe plus qu’une seule version de Local, et elle réunit tout ce que le logiciel sait faire.
À SAVOIR : la gratuité de Local ne concerne que le logiciel de développement en local. Elle n’inclut ni l’hébergement de votre site une fois en ligne, ni un nom de domaine, ni les extensions premium que vous pourriez installer dessus. Local reste un outil de travail sur votre ordinateur, pas une offre d’hébergement.
Comment installer WordPress en local avec Local ?
Avant de créer votre premier site, il faut d’abord installer le logiciel lui même sur votre ordinateur.
Voici la marche à suivre, captures à l’appui.
Télécharger et installer le logiciel (Mac, Windows, Linux)
Local se télécharge gratuitement depuis le site officiel du logiciel, édité par WP Engine.
Le logiciel est compatible avec Mac (Intel et Apple Silicon), Windows et les principales distributions Linux, Debian comme RPM.
Le téléchargement se déroule en quatre étapes :
Si je devais vous donner un conseil sur cette première étape, c’est de ne pas vous inquiéter de la longueur du formulaire : il ne sert qu’à personnaliser votre installation, aucune carte bancaire n’est demandée puisque l’outil est entièrement gratuit.
Au premier lancement du logiciel, trois écrans s’affichent l’un après l’autre :
À SAVOIR : quand on a connu MAMP ou XAMPP, cette simplicité surprend. Le gain de confort est réel dès cette première prise en main, sans ligne de commande ni configuration serveur à toucher.
Comment créer un site WordPress avec Local ?
Une fois Local installé, la création d’un site ne prend que quelques minutes.
Depuis l’écran d’accueil, vous avez deux façon d’ouvrir l’assistant de création :
Ces deux chemins ouvrent l’assistant de création, avec quatre points de départ possibles :
Je vous montre d’abord la marche à suivre pour un site vierge, puis comment gagner du temps sur les suivants grâce aux Blueprints, avant de faire le tour complet de la fiche qui s’affiche une fois votre site créé.
Les deux dernières options, elles, servent à récupérer un site qui existe déjà ailleurs, on les couvre en détail juste après dans un chapitre dédié à l’import.
Créer son premier site WordPress en quelques clics
Pour partir d’un site vierge, sélectionnez « Create a new site », puis laissez vous guider en trois temps :
Créer et enregistrer un Blueprint pour démarrer plus vite
Si vous construisez régulièrement le même type de site, un thème et des extensions qui reviennent systématiquement d’un projet à l’autre, un Blueprint vous évite de tout réinstaller à chaque fois.
Le nom « Blueprint » n’est pas choisi au hasard, car il désigne en anglais le plan bleu d’un architecte, ce document technique qui sert de référence pour construire un bâtiment à l’identique.
Vous configurez donc un site une seule fois, puis vous l’enregistrez comme modèle réutilisable.
Pour transformer un site existant en Blueprint, il doit d’abord être démarré.
Faites un clic droit sur son nom dans la liste, ou ouvrez le menu « … » à côté du nom du site, puis sélectionnez « Save as Blueprint ».
Une fenêtre vous demande de nommer votre Blueprint, et propose un champ « File exclusion filter ».
Ce filtre exclut certains fichiers de la copie qui sera enregistrée, en se basant sur leur extension.
Concrètement, quand vous cliquez sur « Save Blueprint », Local copie tout le dossier du site, wp-content, base de données et réglages compris, vers un nouvel emplacement dédié sur votre ordinateur, celui qui stocke tous vos Blueprints.
Le filtre agit pendant cette copie : tout fichier dont le nom correspond à l’un des motifs indiqués, comme *.zip, n’est simplement jamais copié dans le modèle final.
Rien n’est supprimé de votre site original, seule la copie destinée au Blueprint est concernée.
À SAVOIR : Le préréglage par défaut, *.zip, *.tar.gz, *.bz2, *.tgz, cible les formats d’archives compressées.
C’est utile dans un cas précis : si vous avez utilisé une extension de sauvegarde comme UpdraftPlus sur ce site, ses archives sont stockées dans le dossier wp-content/updraft, même quand un stockage distant est configuré, sauf si l’option « Supprimer la sauvegarde locale » dans les réglages avancés d’UpdraftPlus a bien été cochée pour supprimer la copie locale une fois l’envoi distant confirmé.
Concrètement, un site sur lequel vous avez fait trois sauvegardes automatiques hebdomadaires sans avoir vérifié ce réglage se retrouve avec trois archives zip qui pèsent parfois plusieurs centaines de mégaoctets, cachées dans ce dossier.
Sans le filtre d’exclusion, ces trois fichiers seraient copiés tels quels dans votre Blueprint, alourdissant inutilement chaque futur site créé à partir de ce modèle, alors qu’ils ne contiennent que d’anciennes sauvegardes sans aucune utilité pour un site qui démarre de zéro.
Cette copie prend quelques instants, Local traite chaque fichier un par un.
Une fois la compression terminée, une notification confirme la création du Blueprint, et vous le retrouvez dans la liste « My Blueprints », accessible depuis l’icône dédiée dans la barre latérale de Local
Une fois la compression terminée, une notification confirme la création du Blueprint, et vous le retrouvez dans la liste « My Blueprints », accessible depuis l’icône dédiée dans la barre latérale de Local.
IMPORTANT : un Blueprint ne peut plus être modifié une fois enregistré.
Si vous voulez le mettre à jour plus tard, par exemple pour changer de thème, créez un nouveau site à partir de ce Blueprint, faites vos modifications dessus, puis enregistrez le résultat comme un tout nouveau Blueprint.
Cette contrainte m’a fait pencher pour une autre approche sur mes propres modèles. Je préfère garder un site témoin actif dans Local, que je duplique à chaque nouveau projet plutôt que de le figer en Blueprint.
L’avantage, c’est que je peux continuer à faire évoluer ce site témoin dans le temps, mettre à jour WordPress, le thème ou les extensions, sans jamais avoir à recommencer un modèle de zéro.
Si je devais vous donner un conseil, le Blueprint reste parfait pour un point de départ que vous ne comptez pas faire évoluer souvent, mais si vous voulez garder la main sur votre modèle et le voir progresser avec le temps, dupliquer un site actif garde plus de souplesse.
À SAVOIR : un site plus volumineux peut aussi mettre un temps anormalement long à se transformer en Blueprint, voire rester bloqué en cours de route, et ce même sur un ordinateur puissant.
L’origine semble donc venir du traitement effectué par le logiciel lui même plutôt que d’un manque de ressources de ma machine.
C’est pourquoi j’ai créé un site de test plus léger pour gagner du temps sur cette phase et pouvoir vous présenter la suite du processus sans attendre indéfiniment.
Je détaille ce cas et ce que j’ai pu en tirer dans la section sur les problèmes fréquents, un peu plus loin dans cet article.
Une fois votre Blueprint enregistré, l’utiliser pour un nouveau projet suit exactement le même chemin que la création d’un site classique. Depuis l’écran d’accueil ou le menu « File », ouvrez l’assistant de création, puis sélectionnez « Create from a Blueprint » plutôt que « Create a new site ».
Vous n’avez plus qu’à nommer votre nouveau site, puis cliquer sur « Create site from Blueprint ». Contrairement à la création d’un site vierge, aucune étape séparée pour l’environnement technique ou les identifiants WordPress, tout est déjà hérité du Blueprint.
IMPORTANT : Le système vous demande ensuite le mot de passe administrateur de votre ordinateur, Mac, Windows ou Linux, peu importe le système.
Cette demande n’a rien d’inhabituel, elle est vraisemblablement liée à la modification du fichier hosts nécessaire pour enregistrer le nouveau domaine local du site, la même mécanique système qu’on retrouve à la création de n’importe quel site sur Local.
Une fois validé, Local crée le nouveau site avec l’intégralité du contenu du Blueprint déjà en place, thème, extensions et réglages compris, prêt à être personnalisé pour ce projet précis.
La fiche d’un site Local, un tour du propriétaire
Une fois le site créé, sa fiche complète s’ouvre automatiquement. Voici à quoi sert chaque élément :
Deux boutons permettent ensuite d’accéder au site :
Pour éviter de ressaisir vos identifiants à chaque connexion, l’option « One-click admin » vous connecte automatiquement à l’administration en un seul clic. Elle se trouve dans la fiche du site, désactivée par défaut.
Une fois activée, il suffit de sélectionner le compte administrateur concerné dans le menu déroulant qui apparaît.
Les réglages à faire juste après la création
Une fois le site créé, WordPress propose de nombreux réglages, mais trois d’entre eux méritent une vérification immédiate avant de commencer à travailler dessus :
Comment importer un site WordPress déjà existant dans Local ?
Vous avez déjà un site WordPress en ligne, chez un client ou pour vous même, et vous voulez le retravailler tranquillement sur votre ordinateur avant de toucher à la version publique ?
Trois situations différentes se présentent, chacune avec sa propre méthode :
Je vous détaille les trois, en commençant par la plus courante, l’import via une archive ZIP.
Importer par archive ZIP
La structure attendue du dossier compressé
Avant de vous lancer, une bonne nouvelle. Local se montre bien plus souple qu’on pourrait le croire sur l’organisation exacte du contenu de votre archive.
Ce qui est réellement indispensable, selon la documentation officielle de Local, se résume à deux éléments, présents quelque part dans votre zip :
C’est tout. Pas besoin d’inclure les fichiers du cœur de WordPress, wp-admin, wp-includes, wp-config.php et compagnie.
Ces fichiers sont strictement identiques d’une installation WordPress à l’autre, un peu comme le moteur qui sort d’usine sur un modèle de voiture, seule la carrosserie et les réglages propres à chaque site changent. Local les régénère lui même automatiquement à partir de sa propre copie de WordPress au moment de l’import, vous n’avez donc rien à fournir de ce côté là.
Sur l’organisation précise, plusieurs structures fonctionnent. Si je vous le dis avec autant d’assurance, c’est que j’ai pris le temps de toutes les tester moi même avant d’écrire ces lignes, plutôt que de vous donner une réponse purement théorique :
Les trois fonctionnent aussi bien avec des fichiers récupérés à la main par FTP qu’avec un export généré par une extension.
Si vous tombez malgré tout sur le message « Please try again with a compatible Zip file » à l’import, la piste confirmée par le support officiel de Local consiste à réduire votre zip au strict minimum, seulement wp-content et le fichier ou dossier sql, avant de retenter.
Une fois vos éléments réunis dans un même dossier, il reste une étape avant de le glisser dans Local, le transformer en archive .zip.
Sur Mac, pas besoin d’installer quoi que ce soit, la fonction est intégrée à Finder :
La compression se lance, avec une barre de progression qui affiche l’avancement selon le poids de votre site.
Une fois terminée, vous obtenez votre fichier .zip, prêt à être glissé dans Local.
Sur Windows, la fonction native fonctionne aussi, clic droit sur le dossier, « Envoyer vers », puis « Dossier compressé ». Si vous préférez un outil dédié, plus complet pour gérer de gros volumes, 7-Zip reste la référence, gratuit et open source.
Récupérer les fichiers et la base par FTP
Cette méthode consiste à aller chercher vous même, directement sur votre hébergement, les deux éléments dont Local a besoin. C’est plus manuel que les deux autres méthodes, mais elle fonctionne avec n’importe quel hébergeur, sans dépendre d’une extension particulière.
Récupérer le dossier wp-content, avec un client FTP, autrement dit un logiciel qui vous connecte à votre hébergement pour en télécharger les fichiers :
Pour ce client FTP, plusieurs outils solides existent selon votre système :
Exporter la base de données, depuis phpMyAdmin, l’outil de gestion de base de données proposé par la grande majorité des hébergeurs dans leur espace client :
Si vous voulez en savoir plus sur la façon d’exporter votre base de données sur phpMyAdmin, j’en parle justement dans mon article sur la base de données de WordPress.
Une fois les deux éléments sur votre ordinateur, rassemblez les dans un même dossier et compressez le en zip, exactement comme expliqué juste avant.
Cette méthode reste volontairement présentée ici dans les grandes lignes. Si vous voulez creuser chaque étape en détail, avec les spécificités selon votre hébergeur, je lui consacrerai un article dédié au FTP et à WordPress, vers lequel je renverrai depuis ce passage.
Une dernière chose à savoir avant de continuer, contrairement à un export réalisé avec certains outils, cette méthode manuelle ne corrige pas automatiquement l’adresse de votre site dans la base de données. C’est l’objet du chercher remplacer, que je vous détaille juste après l’import.
Récupérer les fichiers et la base avec WP Migrate Lite
Si vous cherchez une méthode plus rapide que le FTP manuel, l’extension WP Migrate Lite, développée par WP Engine, s’installe gratuitement depuis votre tableau de bord WordPress.
Avant l’export, un passage rapide par l’onglet Settings. Vous y trouverez un « Compatibility Mode », qui décide quelles extensions s’exécutent pendant l’export, sans aucun effet sur ce que contient le zip final.
La méthode la plus simple pour un débutant, ne rien cocher au premier essai. Si l’export échoue avec un message qui nomme précisément une extension, revenez cocher celle là, puis relancez.
Lancer l’export, depuis l’onglet Migrate :
Plusieurs panneaux s’affichent alors, chacun avec ses propres réglages. J’ai testé l’export en les laissant tous cochés, sans rien exclure, et l’import dans Local a fonctionné sans le moindre problème, c’est donc ce que je vous recommande pour rester simple :
Le point le plus important se trouve dans le panneau Database, la section « Standard Find & Replace ».
C’est ici, et c’est un vrai atout de cette méthode, que le chercher remplacer se fait, directement à l’export plutôt qu’après l’import comme avec une récupération manuelle.
Deux lignes apparaissent déjà pré-remplies avec votre domaine et le chemin actuels du site, il ne reste qu’à renseigner leur remplacement dans les champs « Replace » :
Ce qui veut dire une chose importante à anticiper, il vous faut décider et fixer le nom exact que vous donnerez à votre site dans Local avant même de lancer cet export, puisque c’est ce nom qui détermine à la fois le domaine et le chemin à renseigner ici.
Une fois ces deux champs correctement remplis, votre base de données exportée contiendra déjà la bonne adresse, sans manipulation supplémentaire à faire après l’import.
Une fois tous les panneaux passés en revue, cliquez sur « Export » pour lancer l’opération. La progression s’affiche en direct, avec le détail de ce qui est en cours de transfert.
Selon le poids de votre site, ça prend de quelques secondes à quelques minutes.
Réaliser l’import dans Local
Une fois votre archive prête, l’import à proprement parler se fait en quelques clics.
Lancer l’import, depuis l’écran de création de site de Local :
Local vous demande un « Local site name », à partir duquel il génère automatiquement le « Local site domain » et le « Local site path », visibles en dépliant « Advanced options ».
C’est exactement ce nom que vous devez avoir anticipé si vous avez utilisé WP Migrate Lite pour votre chercher remplacer à l’export. Cliquez ensuite sur « Continue ».
Choisir l’environnement, entre « Preferred », la configuration standard recommandée pour la plupart des projets, et « Custom », qui vous laisse choisir précisément votre version de PHP, votre serveur web et votre base de données.
Je détaille ce choix plus loin dans l’article, dans la partie configuration. Cliquez ensuite sur « Import site ».
L’extraction se lance, avec le nombre de fichiers restants affiché en direct. Selon le poids de votre site, ça peut prendre plusieurs minutes.
Une demande de mot de passe peut apparaître, celui de votre session sur votre ordinateur, pas celui de WordPress. C’est normal, Local a besoin de cette autorisation pour configurer certains réglages système liés à votre nouveau site, comme son entrée dans le fichier hosts de votre machine. Renseignez le et validez.
Votre site apparaît dans la liste, avec son domaine et son certificat SSL. Si votre navigateur affiche une alerte de sécurité en ouvrant le site, c’est ce certificat qu’il faut valider, je vous explique comment faire un peu plus loin, dans la partie consacrée à la configuration de Local.
Un point de vigilance avant de continuer. À l’ouverture, la page d’accueil de votre site s’affiche généralement sans problème apparent sous votre nouveau domaine local.
Mais dès que vous cliquez sur un lien du site, comme un espace client ou une page de connexion, l’ancien domaine de production refait surface dans la barre d’adresse.
J’ai pu le constater très concrètement sur l’un de mes propres imports, la page d’accueil s’affichait bien sous le nouveau domaine local, mais un simple clic vers l’espace client m’a renvoyé vers l’ancienne adresse en ligne du site.
Vérifier que le domaine a bien été mis à jour
Une fois votre site importé, une question mérite d’être posée avant de continuer, votre base de données contient elle encore l’ancienne adresse de votre site en ligne ?
Bonne nouvelle, Local s’en occupe déjà pour vous. En creusant dans le fonctionnement interne de Local, j’ai pu confirmer, à partir de ses propres journaux techniques rendus publics sur le forum officiel, qu’une étape nommée « SearchReplacerWPDatabaseDomain » s’exécute automatiquement pendant l’import d’une archive zip, juste après l’import de votre base. C’est elle qui remplace l’ancienne adresse par votre nouveau domaine local, sans que vous ayez quoi que ce soit à faire.
Si je devais vous donner un conseil, ne sautez pourtant pas cette section. Je n’ai trouvé aucune source qui détaille précisément l’étendue de ce remplacement automatique, ni s’il couvre bien toutes les tables, y compris celles ajoutées par vos extensions. Une vérification rapide reste donc une précaution que je vous recommande, plutôt qu’une étape à effectuer les yeux fermés.
Deux façons de vérifier, au choix, soit avec WP-CLI (1ère option), soit avec l’extension WP Search Replace (2ème option) :
Le bloc de code juste en dessous vous donne les deux commandes à taper, une première en simple vérification, une seconde pour appliquer un correctif si jamais elle en trouve un.
Prenons un exemple concret pour que ce soit parlant. Imaginons que votre site vivait en ligne à l’adresse https://aria-restaurant.evidencewp.fr, et que vous venez de l’importer dans Local sous le nom aria-restaurant, ce qui lui donne automatiquement le domaine local https://aria-restaurant.local.
Voici comment vérifier qu’il ne reste aucune trace de l’ancienne adresse dans votre base de données.
Ce que fait chaque partie de la commande :
Pour adapter cette commande à votre propre site, remplacez uniquement les deux adresses par les vôtres. La première correspond à l’ancien domaine en ligne de votre site avant l’import, la seconde à son nouveau domaine local, visible dans la fiche de votre site sous « Site domain ».
1wp search-replace 'https://aria-restaurant.evidencewp.fr' 'https://aria-restaurant.local' --skip-columns=guid --all-tables-with-prefix --dry-runSi le tableau affiché montre des remplacements à faire, un nombre différent de 0 quelque part, il ne reste plus qu’à relancer exactement la même commande, sans l’option –dry-run, pour l’appliquer réellement cette fois. Reprenez à nouveau vos deux propres domaines à la place de l’exemple.
1wp search-replace 'https://aria-restaurant.evidencewp.fr' 'https://aria-restaurant.local' --skip-columns=guid --all-tables-with-prefixRestaurer depuis une sauvegarde Cloud Backups
Cette méthode ne répond pas au même besoin que l’import par archive ZIP qu’on vient de voir.
Cloud Backups sert à assurer la continuité d’un site déjà connu de Local, pas à récupérer pour la première fois un site qui vit uniquement en ligne chez un hébergeur.
Concrètement, vous vous en servez dans deux situations, retrouver votre travail sur un autre ordinateur, ou reconstruire un site après une panne, un changement de machine ou une réinstallation de Local.
Si vous partez d’un site hébergé ailleurs sans être jamais passé par Local auparavant, c’est la méthode d’import par archive zip vue plus haut qu’il vous faut, pas celle ci.
Connecter votre stockage distant, la première étape avant toute sauvegarde. Local fonctionne avec « Google Drive » et « Dropbox », deux services de stockage cloud gratuits dans leur version de base, où vos fichiers et votre base de données seront conservés en sécurité entre vos différentes machines.
Pour Google Drive, la connexion s’ouvre dans votre navigateur :
La connexion se confirme alors dans une nouvelle fenêtre.
Pour Dropbox, le principe est similaire, avec quelques étapes supplémentaires si vous n’avez pas encore de compte :
Dropbox vous proposera ensuite deux écrans commerciaux, un essai gratuit de trente jours sur ses forfaits payants, et une offre de trois mois de forfait supérieur offerts.
Vous pouvez refuser les deux sans que ça bloque quoi que ce soit, en cliquant sur « Conserver le forfait Dropbox Basic de 2 Go ».
Puis vous pouvez ensuite cliquer sur « Continuer avec Basic ».
La connexion se confirme de la même façon que pour Google Drive.
À SAVOIR : méfiez vous de votre navigateur si la connexion échoue sans raison apparente.
J’ai personnellement rencontré ce problème avec Brave, dont le bouclier de protection intégré bloque par défaut la redirection technique dont Local a besoin pour finaliser l’autorisation.
Le navigateur affiche alors une page d’erreur générique, « Ce site est inaccessible », avec le code ERR_CONNECTION_REFUSED.
Désactiver temporairement ce bouclier, ou passer par un autre navigateur le temps de la connexion, a suffi à régler le problème chez moi.
Si cela vous arrive et que la navigateur ne semble pas être en cause, pensez également à vérifier si vous n’utiliser pas un antivirus provoquant la même situation.
Créer une sauvegarde, une fois votre stockage connecté, directement depuis la fiche d’un site dans Local :
À SAVOIR : Une erreur peut survenir à ce moment précis, un message mentionnant des autorisations insuffisantes sur votre compte Google.
Je suis moi même tombé sur ce cas de figure, et la solution s’est révélée simple, retourner dans les « Connected accounts », déconnecter puis reconnecter le stockage concerné.
Ça force l’obtention d’une nouvelle autorisation avec les bons droits, et ça a réglé le problème immédiatement.
Restaurer depuis une sauvegarde, sur le même ordinateur ou sur une autre machine, à condition d’y être connecté au même compte Google Drive ou Dropbox :
La restauration des fichiers se lance, avec une barre de progression.
Comme pour un import par archive ZIP, une demande du mot de passe administrateur de votre ordinateur peut apparaître, il s’agit de la même autorisation système déjà vue plus haut dans cet article.
Une fois la restauration terminée, votre site apparaît normalement dans la liste et fonctionne parfaitement.
Contrairement à un import par archive zip, aucun chercher remplacer n’est nécessaire ici. Vous restaurez un site qui a déjà existé dans Local, avec son propre domaine local d’origine, il n’y a donc structurellement aucun changement d’adresse à corriger.
Restaurer avec une extension de sauvegarde et migration
Si votre site en ligne repose déjà sur une extension de sauvegarde, pas besoin de passer par une archive zip ou par Cloud Backups. Vous pouvez restaurer votre site dans Local directement avec ce même outil, exactement comme pour une migration classique vers un nouvel hébergeur.
La démarche reste la même quel que soit l’outil choisi :
On pourrait se demander comment un outil pensé pour un hébergement web classique peut fonctionner sur votre propre ordinateur.
La réponse est tout simplement que ces solutions sont indifférentes à l’endroit où elles tournent. Une extension de sauvegarde reste avant tout un morceau de code PHP, autrement dit le langage dans lequel WordPress lui même est écrit, qui s’exécute à l’intérieur de WordPress et communique avec sa base de données.
Peu importe que ce PHP tourne sur un serveur loué à l’autre bout de la France ou sur votre ordinateur, il ne voit dans les deux cas qu’une seule chose, une installation WordPress fonctionnelle avec une base de données à disposition.
C’est un peu comme un déménageur qui livre vos cartons. Il ne se soucie pas de savoir si votre nouveau logement se trouve en plein centre ville ou à la campagne, il lui faut juste une porte d’entrée et des pièces où poser les affaires. Local joue exactement ce rôle, il vous fournit une installation WordPress complète, avec son propre PHP et sa propre base de données, en tout point semblable à ce que proposerait un hébergeur classique.
Votre outil de sauvegarde s’y sent donc comme chez lui, et la restauration se déroule sans aucune différence avec ce que vous connaissez déjà sur un site en ligne.
Trois solutions se distinguent par leur fiabilité :
Comme pour un site fraîchement importé, votre navigateur peut afficher une alerte de sécurité liée au certificat SSL à l’ouverture, exactement le même cas de figure que celui abordé plus loin dans cet article. Et même si l’outil gère le chercher remplacer à votre place, une vérification rapide reste une bonne habitude. La commande de contrôle donnée plus haut fonctionne quelle que soit la méthode d’import utilisée pour votre site.
IMPORTANT : évitez tout stockage distant situé hors de l’Union européenne, ou dont la sécurité n’est pas clairement établie. Vos sauvegardes contiennent l’intégralité de votre site, ce n’est pas un détail à prendre à la légère.
Comment configurer un site WordPress local sur Local ?
Une fois votre site créé ou importé, quelques réglages méritent d’être ajustés avant de vous lancer dans le développement à proprement parler.
Certains se décident site par site, comme l’environnement technique à reproduire.
D’autres se règlent une bonne fois pour toutes dans les préférences de Local, et s’appliquent ensuite à l’ensemble de vos projets.
Je vous détaille les principaux, du choix de votre environnement jusqu’à l’activation du SSL, en passant par les réglages qui rendent Local plus confortable au quotidien.
Choisir son environnement
Au moment de créer ou d’importer un site, Local vous propose deux options, « Preferred », la configuration standard recommandée dans la majorité des cas, ou « Custom », qui vous laisse choisir précisément trois éléments, votre version de PHP, votre serveur web et votre version de MySQL.
C’est particulièrement bien pensé pour reconstituer à l’identique l’environnement de votre hébergement en ligne, et tester votre site dans des conditions quasiment réelles avant de le mettre en ligne.
Si votre hébergeur utilise PHP 8.1 et un serveur nginx, vous pouvez reproduire exactement cette configuration en local, plutôt que de développer sur une version différente et de découvrir des incompatibilités seulement une fois le site en ligne.
Régler les préférences par défaut de Local
L’onglet « New site defaults », dans les « Preferences » de Local, définit ce qui s’applique automatiquement à chaque nouveau site que vous créez, pour vous éviter de tout ressaisir à chaque fois.
Un autre onglet des « Preferences », « Connected accounts », vous est déjà familier pour sa section « Cloud storage », vue plus haut dans cet article au sujet de Cloud Backups. Il contient aussi une section « Hosting platforms », avec deux services appartenant au même éditeur que Local, « WP Engine » et « Flywheel ».
Se connecter à l’un de ces comptes permet de pousser ou de récupérer un site en un clic entre votre ordinateur et votre hébergement, sans passer par un export puis un import manuel. Ça ne vous concerne concrètement que si votre site est hébergé chez l’un de ces deux prestataires. Si vous hébergez ailleurs, les méthodes d’import détaillées plus haut dans cet article restent la voie à suivre.
Un dernier onglet mérite une mention rapide, il s’agit de « Exporting ». Il ne contient qu’un seul réglage, « File exclusion filter », qui exclut certains types de fichiers de vos exports Local, avec quatre extensions déjà exclues par défaut, .zip, .tar.gz, .bz2 et .tgz.
Ce réglage est utile si votre site contient déjà des archives que vous ne souhaitez pas dupliquer inutilement à chaque export.
Personnaliser l’apparence et le comportement de Local
L’onglet « Appearance & behavior » ajuste l’apparence de Local lui même, ainsi que les applications qu’il utilise pour certaines actions.
Activer le SSL en local
Le SSL, autrement dit le protocole qui permet à votre site de s’afficher en HTTPS plutôt qu’en HTTP, n’est pas activé automatiquement à la création d’un site. Vous le repérez facilement, un bouton « Trust » reste actif à côté du certificat, sur la fiche de votre site.
À SAVOIR : En cliquant sur « Trust », il est fréquent qu’un message s’affiche en haut de Local, « Heads-up! We ran into an issue trusting the Local SSL certificate ».
Ne vous inquiétez pas, ce message n’indique pas un échec, c’est simplement le signe qu’une manipulation manuelle supplémentaire est nécessaire, différente selon votre système d’exploitation.
Sur Mac
IMPORTANT : Il est possible que le certificat n’affiche pas immédiatement « Trusted ». Fermez et rouvrez Local, ou passez sur un autre site avant de revenir sur le vôtre, pour que l’information se rafraîchisse correctement.
Un dernier point indispensable, quel que soit votre système. Le certificat ne s’applique réellement qu’après avoir arrêté puis redémarré votre site. Sans cette étape, le SSL reste configuré sans être actif.
Sur Windows
Windows gère la confiance des certificats différemment de macOS, via son propre magasin de certificats système plutôt que par une application comme Trousseaux d’accès.
Je ne dispose pas d’un environnement Windows pour vous détailler la procédure exacte étape par étape, et je préfère rester honnête plutôt que de vous donner une marche à suivre non vérifiée sur un point aussi sensible.
IMPORTANT : si vous utilisez Local sur Windows et connaissez la procédure précise, n’hésitez pas à la partager dans les commentaires de cet article, ça aidera directement les autres lecteurs dans votre situation.
Et si vous rencontrez vous même un blocage à cette étape, dites le également en commentaire, je me ferai un plaisir de vous orienter au mieux.
Enfin, si l’écran affiche une erreur mentionnant un conflit de port plutôt qu’un problème de certificat, ce n’est pas lié au SSL, je vous explique comment la résoudre plus loin dans cet article.
Le Router Mode
Toujours dans l’onglet « Advanced » des « Preferences », le « Router mode » détermine comment Local rend vos sites accessibles depuis votre navigateur.
Ce choix a un lien direct avec le SSL que vous venez d’activer, et j’y reviendrai également plus loin dans l’article au sujet du multisite WordPress, qui impose l’un de ces deux modes selon votre configuration.
Ce même onglet regroupe aussi trois réglages plus techniques, que vous pouvez laisser tels quels dans la grande majorité des cas, « Show Develop menu », qui ajoute un menu réservé au débogage des Add-ons Local, « Usage reporting » et « Error reporting », deux options de partage de données anonymisées avec l’éditeur de Local pour améliorer le logiciel.
Comment utiliser Local au quotidien pour développer un site WordPress ?
Une fois votre site créé, importé et configuré selon vos besoins, l’essentiel commence, le travailler au quotidien.
Local propose alors une série de fonctionnalités pensées pour un usage régulier, que vous jongliez entre plusieurs projets clients ou que vous développiez un site pour votre propre compte.
Gérer plusieurs sites en parallèle, accéder directement à votre base de données, tester vos emails transactionnels sans risquer d’en envoyer un vrai, ou encore montrer votre travail à un client avant même la mise en ligne.
Voici les usages qui reviennent le plus souvent une fois passée la phase d’installation.
Gérer plusieurs sites en parallèle
Si vous avez déjà utilisé MAMP ou XAMPP pour du développement local, vous savez à quel point jongler entre plusieurs projets peut vite devenir confus. Local règle ce problème avec une organisation que je trouve nettement plus aboutie.
Concrètement, voici ce qui change au quotidien :
Si je devais vous donner un conseil, ne vous inquiétez pas outre mesure pour les performances de votre ordinateur. Il faut vraiment un usage intensif pour ressentir un ralentissement, sauf si votre machine est déjà sous dimensionnée au départ. Je n’ai personnellement jamais constaté de bug ni de lenteur, même avec plusieurs sites actifs simultanément.
Cela dit, il reste rare de travailler sur plus de deux sites en même temps dans la pratique, et le bon réflexe consiste à arrêter les sites que vous n’utilisez pas sur le moment, pour limiter l’usage des ressources de votre ordinateur.
Chaque site conserve sa propre configuration, totalement indépendante des autres, exactement ce qu’on a vu plus haut dans l’article. C’est cette combinaison de simplicité d’utilisation et d’organisation qui fait de Local, à mon sens, l’outil le plus abouti pour développer plusieurs sites WordPress en local.
Utiliser Blueprint pour gagner du temps et augmenter sa rentabilité
Blueprint répond à un vrai besoin, séparer clairement votre espace de travail de vos modèles réutilisables. Préparer les fondations d’un nouveau site, la configuration de WordPress, l’installation et le réglage du thème, les extensions minimales qui reviennent presque à chaque projet, peut facilement prendre plusieurs heures.
Enregistrer tout ça une bonne fois pour toutes dans un Blueprint vous évite de recommencer ce travail à chaque nouveau client.
Vous pouvez préparer plusieurs Blueprint différents selon vos besoins, un thème et des extensions propres à chaque type de projet, avec ou sans WooCommerce par exemple. Si je devais vous donner un conseil, je vous le recommande sans hésiter, créer un nouveau site à partir d’un Blueprint n’a rien de compliqué, et le gain de rentabilité est réel sur la durée.
Un vrai bémol cependant, confirmé par la documentation officielle de Local, un Blueprint enregistré ne peut plus être modifié par la suite. Impossible donc de mettre à jour son contenu ou d’ajuster sa configuration directement.
Deux façons de contourner cette limite, selon votre préférence d’organisation :
Dans les deux cas, l’objectif reste le même, vous libérer de la charge mentale que représente la préparation systématique d’un nouveau projet ou d’une refonte.
Accéder à la base de données locale
Chaque site Local embarque son propre outil de gestion de base de données, AdminNeo, l’équivalent local de phpMyAdmin que vous connaissez peut être déjà côté hébergement. Depuis l’onglet « Database » de votre site, cliquez sur « Open AdminNeo » pour y accéder directement, sans avoir à ressaisir le moindre identifiant.
Vous retrouvez toutes vos tables listées sur la gauche, avec les fonctions classiques d’un outil de ce type, requête SQL, import, export, ou encore création d’une nouvelle table.
Si je devais vous donner un conseil, sachez que c’est vraiment un outil abouti, en quelques clics vous accédez à votre base avec une organisation soignée. J’ai personnellement toujours une petite préférence pour phpMyAdmin, mais c’est vraiment une histoire de goût plus qu’un vrai reproche fait à AdminNeo.
Dans ma pratique, je m’en sers surtout à deux moments. À la création d’un site, pour vérifier que le changement du préfixe des tables s’est bien effectué, un point que je détaille dans mon article sur le préfixe de la base de données WordPress. Et plus régulièrement lors d’une refonte, où j’ai davantage besoin d’aller consulter ou ajuster des données directement en base.
Consulter les emails transactionnels envoyés localement
Un site en local ne peut techniquement pas envoyer de vrais emails vers l’extérieur, ce qui est logique puisqu’il n’est connecté à aucun serveur de messagerie réel.
Local règle ce problème avec Mailpit, un outil qui intercepte chaque email transactionnel envoyé par votre site pour le faire atterrir dans une boîte de réception locale, plutôt que de le perdre silencieusement.
Pour y accéder, direction l’onglet « Tools » de votre site, puis cliquez sur « Open Mailpit ».
L’interface reste volontairement simple, une boîte de réception classique où s’affichent tous les emails générés par votre site, confirmation de commande, réinitialisation de mot de passe, ou formulaire de contact.
Si je devais vous donner un conseil pour les mails transactionnels, ne soyez pas surpris si cette logique vous déroute un peu au départ, surtout si vous avez l’habitude de travailler directement sur un site en ligne. C’est pourtant vraiment un luxe à mes yeux, pouvoir vérifier en un coup d’œil que vos emails transactionnels partent correctement, sans attendre d’être en ligne pour le découvrir.
Si un email atterrit bien dans Mailpit, vous avez un premier aperçu fiable de son contenu et de sa mise en forme. Une fois votre site en ligne, avec une extension SMTP correctement configurée et une délivrabilité travaillée, ces mêmes emails arriveront normalement dans les vraies boîtes de réception de vos visiteurs, sans mauvaise surprise.
Utiliser WP-CLI via le terminal intégré
WP-CLI est l’interface en ligne de commande officielle de WordPress. Autrement dit, un outil qui permet d’accomplir presque tout ce que vous feriez normalement depuis votre tableau de bord WordPress, mais en tapant des commandes plutôt qu’en cliquant sur des boutons.
Local l’intègre nativement, accessible depuis le terminal « Site shell » déjà évoqué plus haut dans cet article.
IMPORTANT : je dois être honnête avec vous, cet outil s’adresse avant tout à un profil technique ou déjà à l’aise avec la ligne de commande. Rien d’accessible en un clic ici, chaque action demande de connaître la bonne commande et sa syntaxe exacte.
Si vous débutez, rien ne vous empêche de vous en passer complètement, l’interface WordPress classique reste toujours disponible pour les mêmes actions.
Ce que ça permet concrètement au quotidien, une fois à l’aise avec l’outil :
C’est aussi l’outil qui permet le chercher remplacer en base de données, que je vous détaille plus haut dans cet article, avec la commande wp search-replace.
Les modules complémentaires utiles
Local propose ses propres Add-ons, accessibles depuis la barre latérale de l’application. Attention à ne pas les confondre avec les extensions WordPress, ces modules ajoutent des fonctionnalités à Local lui même, pas à vos sites.
Voici ceux qui reviennent le plus utile au quotidien :
Deux autres modules s’adressent à des besoins plus spécifiques, Xdebug + VS Code, qui configure en un clic l’outil de débogage Xdebug pour l’éditeur VS Code, et WP Engine Headless Platform, pour découvrir le fonctionnement d’un WordPress headless, autrement dit un WordPress utilisé uniquement comme back office sans thème classique affiché.
Développer une boutique WooCommerce en local avant la mise en ligne
Construire une boutique WooCommerce en local suit la même logique qu’un site vitrine, avec quelques particularités propres à l’e-commerce.
Il faut accepter une chose dès le départ, travailler en local ne donne aucune certitude absolue sur le comportement de certaines fonctionnalités une fois le site réellement en ligne.
Rien d’inquiétant pour autant, il s’agit simplement de bien répartir ce qui se teste en local et ce qui se vérifie uniquement à la mise en ligne.
Ce que vous pouvez tester sereinement en local :
Ce que je garde systématiquement pour la mise en ligne, la connexion réelle aux plateformes de paiement comme Stripe ou PayPal. Le principe reste de dégrossir un maximum en local, et de réserver les vérifications qui ont un impact direct sur le fonctionnement réel de la boutique pour le moment où le site passe en production.
Un dernier point à ne pas négliger une fois en ligne, la délivrabilité de vos emails transactionnels. Une bonne configuration SMTP, associée à un travail sérieux sur vos enregistrements DNS, garantit que les confirmations de commande et autres notifications arrivent bien dans les boîtes de réception de vos clients, pas dans leurs spams.
Le multisite WordPress avec Local
Local prend en charge le multisite WordPress, autrement dit la possibilité de gérer plusieurs sites depuis une seule installation WordPress, mais avec deux contraintes à connaître avant de vous lancer.
Le Router Mode doit impérativement être réglé sur « Site domains », ce réglage vu plus haut dans cet article. Un multisite ne fonctionne tout simplement pas si Local est configuré sur « localhost ».
Local Connect n’est pas compatible avec le multisite, et le mappage de domaine n’est pas disponible non plus. Concrètement, ça signifie que déployer un multisite créé en local vers un hébergement en ligne demande une démarche manuelle, sans le raccourci en un clic que Local propose pour un site classique.
Selon la documentation officielle, deux pistes existent pour cette migration, un export manuel suivi d’une migration vers votre hébergeur, ou l’utilisation d’une extension comme WP Migrate, qui propose plusieurs options dédiées au multisite selon que vous migrez un réseau complet ou seulement certains sous-sites.
Pour la création elle même, rien de complexe, vous retrouvez les mêmes étapes qu’un site classique, nommage, choix de l’environnement, identifiants administrateur, avec une case supplémentaire dans les options avancées pour sélectionner le type de multisite souhaité.
Partager son site en local à un client avec Live Links
Live Links répond à un besoin très concret, montrer l’avancement d’un site encore en développement, sans attendre une mise en ligne prématurée ni organiser un rendez vous pour partager votre écran.
La mise en place se fait en quelques étapes :
De l’autre côté, la personne qui reçoit le lien doit simplement renseigner l’identifiant et le mot de passe fournis.
Une fois connectée, elle parcourt votre site exactement comme s’il était déjà en ligne, sans savoir qu’il tourne en réalité sur votre ordinateur.
Si je devais vous donner un conseil, n’hésitez pas à vous en servir largement, c’est un vrai atout gratuit pour la relation client.
Rien ne renforce autant la confiance et la transparence dans une collaboration qu’un client qui peut suivre concrètement l’avancement de son projet, plutôt que d’attendre une livraison finale sans nouvelles entre temps.
Un dernier réflexe à prendre, pensez à désactiver Live Links une fois votre échange terminé, pour continuer à travailler sereinement sur votre site sans laisser un accès actif inutilement.
Les problèmes fréquents avec Local et comment les résoudre
Même un logiciel aussi abouti que Local n’échappe pas à quelques blocages occasionnels.
Rien d’alarmant dans la plupart des cas, ces problèmes reviennent régulièrement et se résolvent en quelques minutes une fois qu’on sait où regarder.
Voici les quatre situations les plus fréquentes que vous pourriez rencontrer, avec la marche à suivre pour chacune.
Les erreurs de mémoire PHP
Deux symptômes différents peuvent survenir autour de la mémoire allouée à PHP, avec chacun sa propre cause et sa propre solution. Voici comment reconnaître le vôtre.
Premier symptôme, la page reste blanche ou affiche une erreur fatale :
Fatal error : Allowed memory size of 268435456 bytes exhausted (tried to allocate X bytes) in [chemin du fichier] on line [numéro]
Ce que ça signifie : la mémoire réellement allouée par PHP est insuffisante pour ce que la page essaie de faire.
La solution, en modifiant directement le réglage de Local :
Le second symptôme survient si vous tentez d’augmenter la mémoire par la méthode classique, celle qui fonctionne sur un hébergement en ligne, en ajoutant une ligne dans wp-config.php. À noter qu’il peut arriver que cette ligne soit aussi présente dans votre fichier wp-config.php sans que vous ayez cherché préalablement à augmenter la mémoire allouée à PHP.
Sur Local, ça déclenche un avertissement plutôt que de régler le problème :
Warning : Constant WP_MEMORY_LIMIT already defined in wp-config.php on line [numéro]
Ce que ça signifie : contrairement à un hébergement classique, Local gère lui même cette limite en amont, directement dans sa propre configuration PHP. Ajouter la ligne WP_MEMORY_LIMIT dans wp-config.php entre alors en conflit avec ce que Local a déjà défini, d’où cet avertissement.
La bonne solution, celle qui fonctionne réellement sur Local :
Le certificat SSL refusé par le navigateur
Votre site s’ouvre, mais votre navigateur affiche une alerte de sécurité, un cadenas barré, ou un message du type « Votre connexion n’est pas privée ».
C’est le symptôme le plus courant d’un certificat SSL pas encore validé, celui là même qu’on retrouve fréquemment juste après un import ou une restauration de site dans Local.
La bonne nouvelle, la procédure complète pour régler ce problème est déjà détaillée plus haut dans cet article, dans la partie consacrée à l’activation du SSL en local, avec la manipulation précise via Trousseaux d’accès sur Mac.
Si le message persiste malgré tout après avoir suivi cette procédure, deux réflexes simples à avoir avant de chercher plus loin :
Un conflit de port
Ce message apparaît en bandeau rouge sur la fiche de votre site, « There is a port conflict with this site’s domain ».
Pour comprendre la cause, il faut savoir qu’un port, c’est un peu comme une porte numérotée sur votre ordinateur, par laquelle un logiciel communique avec l’extérieur.
Local a besoin d’une porte précise, le port 80, pour faire fonctionner son propre routeur en mode « Site Domains ».
Si un autre logiciel occupe déjà cette même porte, Apache, MAMP, XAMPP, ou parfois un VPN, le conflit apparaît, Local ne peut pas s’en servir en même temps.
Il existe deux façons d’y remédier :
La solution rapide, cliquer directement sur le bouton « Use localhost » proposé dans le message d’erreur. Le conflit disparaît immédiatement, avec la contrepartie déjà évoquée plus haut dans cet article, le HTTPS n’est alors plus disponible pour ce site.
La solution qui garde le HTTPS, si vous préférez rester en « Site Domains » plutôt que de perdre cet avantage. Il faut identifier le logiciel qui occupe le port 80, puis le fermer.
1sudo lsof -i:80; sudo lsof -tnP -i:80 | xargs -n 1 ps -p
Comment lire ce résultat, colonne par colonne :
Pour résoudre le conflit, seules deux colonnes comptent vraiment, COMMAND et PID.
Comment interpréter le nom du programme affiché :
Si aucune de ces pistes ne fonctionne, forcez l’arrêt directement depuis le terminal avec le second bloc de code, en remplaçant PID par le numéro identifié à l’étape précédente.
Une fois le programme arrêté, relancez votre site dans Local, le conflit de port devrait avoir disparu.
1sudo kill -9 PIDSi le problème revient régulièrement avec le même logiciel, le plus simple reste souvent de le désinstaller s’il ne vous est plus utile, ou de le lancer après Local pour lui laisser la priorité sur le port.
N’hésitez pas à partager en commentaire le logiciel qui causait votre propre conflit, ça aide souvent d’autres lecteurs à identifier le leur plus rapidement.
Problème sur le Blueprint avec un site consistant et alternative
Créer un Blueprint à partir d’un site conséquent peut parfois traîner en longueur de façon anormale. Sur ma propre expérience, la création est restée bloquée une dizaine de minutes sans afficher la moindre erreur ni progresser visiblement, sur un site construit avec Astra et Elementor. Le résultat, j’ai fini par abandonner sans obtenir de Blueprint fonctionnel.
Je reste honnête sur ce point, une petite latence existe normalement même sur un site vide au moment de créer un Blueprint, donc je ne peux pas affirmer avec certitude qu’il s’agit d’un vrai blocage plutôt que d’un traitement simplement long sur un site volumineux. Ce que je peux en revanche exclure de mon côté, un problème de ressources sur mon ordinateur, largement assez puissant pour ce type de tâche. La cause la plus probable reste donc liée au traitement interne du logiciel face à un site conséquent, sans certitude absolue sur ce point précis.
En attendant d’y voir plus clair, l’alternative reste simple, créer votre modèle directement sur un site plus léger, ou dupliquer un site existant plutôt que de passer par un Blueprint si celui ci refuse de se créer dans un délai raisonnable.
IMPORTANT : avez vous déjà rencontré ce blocage vous même ?
Dites le en commentaire, avec la taille de votre site et le thème utilisé si possible, ça permettra de voir si le problème touche uniquement les gros sites ou une configuration particulière.
Comment déployer un site créé sur Local vers un hébergement en ligne ?
Une fois votre site prêt, reste l’étape finale, le faire passer de votre ordinateur vers votre hébergement en ligne. Plusieurs méthodes existent, chacune avec ses avantages selon votre niveau d’aisance technique et les outils déjà à votre disposition.
Je vous détaille les principales, avec un point de vigilance qui revient systématiquement, quelle que soit la méthode choisie, la même logique de chercher remplacer déjà vue plus haut dans cet article, mais cette fois dans l’autre sens, de votre domaine local vers votre nouveau domaine en ligne.
La méthode UpdraftPlus, sauvegarde et restauration
Si votre site local utilise déjà UpdraftPlus, la méthode reste la même que celle vue plus haut pour une restauration, mais dans le sens inverse.
Vous créez une sauvegarde complète depuis votre site local, vous l’importez ensuite sur votre hébergement en ligne, sur une installation WordPress fraîchement créée chez votre hébergeur.
Le chercher remplacer du domaine se fait directement dans l’interface de restauration d’UpdraftPlus, exactement comme on l’a vu précédemment, sans manipulation technique supplémentaire de votre part.
Le piège Elementor et le chercher remplacer
Si votre site utilise Elementor, une vigilance particulière s’impose au moment du déploiement.
Le constructeur de page stocke une partie de ses réglages dans un format que le chercher remplacer classique ne traite pas toujours correctement, ce qui peut laisser des blocs mal affichés une fois votre site en ligne, malgré un remplacement de domaine apparemment réussi.
J’explique cette particularité en détail, captures à l’appui, dans mon article sur le fonctionnement d’une base de données WordPress.
Sécuriser la vérification avec Better Search Replace
Quelle que soit la méthode de déploiement choisie, une vérification finale avec Better Search Replace reste une bonne habitude, pour confirmer qu’aucune trace de votre ancien domaine local ne subsiste dans votre base de données une fois en ligne.
Je détaille la manipulation complète de cette extension, avec les bons réglages à cocher, dans mon article sur le fonctionnement d’une base de données WordPress.
La méthode FTP manuelle, en dernier recours
Sans extension de sauvegarde, vous pouvez toujours déployer votre site manuellement, avec les mêmes outils déjà vus pour l’import, un client FTP et l’accès à la base de données de votre hébergement.
Les grandes étapes à suivre :
Les alternatives à Local
Local n’est pas le seul outil pour développer un site WordPress en local, même si c’est à mes yeux le plus abouti aujourd’hui.
Deux grandes familles d’alternatives existent, les outils historiques et généralistes comme MAMP et XAMPP, présents bien avant Local, et une alternative plus récente, DevKinsta, pensée spécifiquement pour WordPress sur le même principe que Local.
Voyons ce qu’elles proposent, et pourquoi je continue malgré tout à recommander Local en priorité.
MAMP et XAMPP, les outils historiques
MAMP et XAMPP existaient bien avant Local, et restent aujourd’hui les deux noms les plus connus pour monter un serveur local sur son ordinateur. Contrairement à Local, ce ne sont pas des outils pensés spécifiquement pour WordPress, ils installent simplement une pile technique généraliste, Apache ou nginx, MySQL et PHP, sur laquelle vous installez ensuite WordPress vous même.
J’ai utilisé MAMP sur Mac à une époque, avant l’existence de Local. Ça fait le travail, mais l’interface reste peu intuitive, et la gestion au quotidien demande davantage de manipulations manuelles. Les conflits de port, comme celui qu’on a vu plus haut dans cet article à propos de Local, y sont tout aussi fréquents, voire plus pénibles à résoudre puisque rien n’est aussi bien intégré.
Si je devais vous donner un conseil, maintenant que Local existe et reste entièrement gratuit, je ne vois plus vraiment de raison d’y retourner.
Ce sont des outils qui restent fonctionnels, mais plus artisanaux, adaptés à un profil très technique qui aime mettre les mains directement dans les fichiers de configuration.
Même pour ce genre de profil, l’organisation, les fonctionnalités et des atouts comme le partage d’un site à un client avec Live Link font clairement pencher la balance du côté de Local.
DevKinsta, l’alternative la plus proche de Local
DevKinsta, développé par l’hébergeur Kinsta, se rapproche le plus de Local dans sa philosophie, un outil gratuit et dédié spécifiquement à WordPress, sans configuration technique à gérer soi même.
Il repose sur Docker plutôt que sur une virtualisation classique, avec la prise en charge du HTTPS en local, plusieurs versions de PHP disponibles, et un outil de gestion des emails transactionnels intégré, sur le même principe que Mailpit vu plus haut.
Aucun compte Kinsta n’est nécessaire pour l’utiliser pleinement. Un compte devient utile uniquement si vous êtes déjà hébergé chez eux, pour profiter d’un envoi en un clic entre votre environnement local et votre hébergement, une fonctionnalité comparable à ce que propose Local avec Local Connect pour ses propres partenaires.
Questions fréquentes sur le logiciel Local
Sources :
WP Engine (blog officiel) – Rétrospective sur huit ans de Local et le rachat de Pressmatic par Flywheel
WP Engine (communiqué officiel) – Renommage de Local by Flywheel en Local
Local (site officiel) – Gratuité permanente de Local depuis juin 2021
Local (documentation officielle) – Import d’un site WordPress dans Local
Local (documentation officielle) – Gestion du certificat SSL sur macOS
Delicious Brains, WP Migrate (documentation officielle) – Import d’un site vers Local
Delicious Brains, WP Migrate (documentation officielle) – Exports complets de site
UpdraftPlus (documentation officielle) – Restauration d’un site WordPress
UpdraftPlus (documentation officielle) – Migration d’un site WordPress
Forum officiel Local – Structure attendue du zip d’import
Forum officiel Local – Bug du préfixe de table en majuscules à l’import
Forum officiel Local – Erreur de préfixe de table vide après import
Delicious Brains, WP Migrate (documentation officielle) – Fonctionnement du Compatibility Mode
WordPress.org (documentation officielle WP-CLI) – Commande search-replace
Forum officiel Local – Dépannage d’un zip incompatible à l’import
Forum officiel Local – Réduction d’un zip WP Migrate incompatible à wp-content et sql
Forum officiel Local – Journaux internes confirmant le remplacement automatique du domaine à l’import
Local (documentation officielle) – Fonctionnement du Router Mode
Local (documentation officielle) – Multisite WordPress avec Local
Local (documentation officielle) – Résolution des problèmes de performance et réglages PHP
WooCommerce (documentation officielle) – Fonctionnement des commandes de test
Kinsta (site officiel) – Présentation de DevKinsta
Local (documentation officielle) – Fonctionnement d’un compte Local
Local (documentation officielle) – Foire aux questions de Local
Local (documentation officielle) – Désinstallation de Local
Conclusion sur le logiciel Local pour WordPress
Vous voilà avec toutes les clés en main pour développer vos sites WordPress dans de bonnes conditions, avant de les livrer en ligne.
Local n’est pas qu’un simple outil pratique, c’est aussi une façon de travailler plus sereine, à l’abri des mauvaises surprises qu’un test direct en production peut provoquer.
Si je devais résumer ce que cet outil change vraiment au quotidien, je dirais que c’est avant tout du temps gagné et des erreurs évitées.
Une extension mal codée qui casse votre site, une mise à jour risquée, un thème à essayer avant de trancher, tout ça se teste désormais sans jamais mettre en danger un site déjà en ligne chez un client.
Et c’est bien ça, au fond, qui rejoint ce qui compte le plus à mes yeux dans ce métier. Un site bien construit, avec des bases solides posées dès le départ, reste un site qui continue de rendre service des années plus tard, sans mauvaise surprise à chaque mise à jour.
C’est exactement ce que je m’efforce d’apporter à chaque projet que j’accompagne, que ce soit à la création ou dans le suivi qui vient ensuite.
Laisser un commentaire
Les articles qui pourraient vous intéresser.
Base de données WordPress : le guide complet pour la comprendre et la gérer
Si je vous demande ce qu’il y a dans la base de données de votre site WordPress, il y a…Pourquoi choisir WordPress : 11 raisons honnêtes
Vous souhaitez créer ou refondre votre site internet afin de disposer d’une plateforme solide vous offrant flexibilité et pérennité ? Propulsant…Alternatives à Planity : le comparatif honnête pour les professionnels de la beauté
Vous cherchez une alternative à Planity et vous vous demandez quelles sont les solutions qui peuvent lui tenir tête. Planity…
Besoin d’être accompagné ?
Votre site WordPress mérite un partenaire de confiance, pas un prestataire de plus. Parlons de votre projet lors d’un appel découverte gratuit, sans engagement.
0 commentaires
Aucun commentaire pour le moment. Soyez le premier à réagir.