Installer WordPress en local avec Local : guide débutant

Si votre site casse après une mise à jour de plugin ou un test de code, le local vous évite de “réparer en direct” devant vos visiteurs. Local by Flywheel (souvent appelé “Local”) fait partie des outils les plus simples pour lancer un WordPress complet sur votre ordinateur, sans toucher à votre hébergement.

Ce qu’on va construire

Vous allez installer un environnement WordPress local prêt à développer et à tester, basé sur WordPress 6.9.4 (ou plus récent) et PHP 8.1+.

À la fin, vous saurez :

Créer un nouveau site local en quelques minutes (URL locale propre, base de données, admin WordPress).
Activer SSL en local pour tester des plugins qui l’exigent (paiement, API, OAuth, etc.).
Importer un site existant (depuis un hébergeur) pour le tester sans risque.
Mettre en place un petit socle “pro” : thème enfant, mu-plugin, et configuration de debug.

C’est destiné aux blogueurs (débutants à avancés), aux indépendants, et à toute personne qui veut tester des thèmes, des extensions ou du code sans stress.

Résumé rapide

Installez Local, puis créez un site avec PHP 8.1+ et une URL locale stable.
Vérifiez immédiatement : permaliens, mises à jour, langue, et options de debug.
Activez SSL local si vous testez des formulaires, paiements ou connexions sociales.
Pour migrer un site existant : export “propre” (fichiers + base) et correction des URLs.
Ne déployez jamais vers la production sans sauvegarde et sans vérifier les URLs / la base.

Quand utiliser cette solution

Vous voulez tester un thème, un plugin, ou une mise à jour WordPress 6.9.4 sans risque.
Vous apprenez WordPress et vous voulez manipuler l’admin, Gutenberg, les réglages, les permaliens.
Vous développez (même un peu) : snippets, CSS, thème enfant, hooks.
Vous préparez une refonte avant de la pousser sur votre hébergement.
Vous devez reproduire un bug client sans toucher au site en ligne.

Dans mon expérience, c’est la meilleure façon d’éviter les “j’ai cassé le site en modifiant functions.php” (ça arrive vite, surtout au début).

Quand ne PAS utiliser cette solution

Vous devez tester des performances réelles serveur (cache serveur, CDN, HTTP/2/3, latence). Le local ne simule pas fidèlement un hébergement.
Vous dépendez d’un service externe qui bloque les domaines locaux (certaines API n’aiment pas .local ou les certificats auto-signés).
Vous devez tester des emails sortants en conditions réelles (le local nécessite un outil de capture type MailHog/Mailpit, ou un SMTP tiers).
Vous travaillez en équipe sur le même site : préférez un environnement de staging partagé + Git.

Avant de commencer (prérequis)

Ce que vous allez éviter (et pourquoi)

Ne modifiez jamais le core WordPress (les fichiers de WordPress). Les modifications seront écrasées à la prochaine mise à jour, et c’est un risque de sécurité.

Avant toute manipulation, gardez en tête : un site local, c’est un bac à sable. Sur un site en ligne, on sauvegarde d’abord.

Prérequis

WordPress : 6.9.4 (ou plus récent).
PHP : 8.1 minimum recommandé (8.2/8.3/8.4 selon compatibilités plugins).
Accès FTP/cPanel : utile si vous importez un site existant depuis un hébergeur (récupération des fichiers et de la base).
Thème enfant activé : utile si vous testez des modifications (sinon, vos changements seront perdus au changement de thème ou à une mise à jour).

Définitions rapides (sans jargon inutile)

Local : application qui installe un serveur web (Nginx ou Apache), PHP et une base (MySQL/MariaDB) sur votre ordinateur, pour faire tourner WordPress.
Base de données : endroit où WordPress stocke vos contenus (articles, pages) et réglages.
Staging : copie de votre site en ligne, mais non publique, pour tester avant déploiement.
Hook : “point d’accroche” dans WordPress. Une action exécute du code à un moment donné ; un filtre modifie une valeur avant qu’elle soit utilisée.
mu-plugin : plugin “must-use” chargé automatiquement, placé dans wp-content/mu-plugins/. Pratique pour des réglages techniques qui ne doivent pas être désactivés par erreur.

Résultat attendu (capture textuelle)

À la fin des prérequis, vous devez pouvoir dire :

“Je sais sur quel WordPress et quel PHP je suis.”
“J’ai un plan de sauvegarde si j’importe un site existant.”

Étape 1 : Installer Local by Flywheel et préparer votre machine

1) Télécharger Local

Rendez-vous sur le site officiel de Local (éditeur WP Engine). Téléchargez la version pour votre OS (Windows/macOS/Linux) :

Local (LocalWP) – site officiel

2) Installer l’application

Windows : exécutez l’installateur, acceptez les droits admin si demandés.
macOS : glissez l’app dans Applications, puis ouvrez-la (autorisez dans Sécurité si macOS bloque).
Linux : suivez la procédure du paquet fourni (AppImage ou équivalent selon version).

3) Premier lancement : permissions et réseau

Local peut demander :

Des droits pour modifier le fichier hosts (pour créer des domaines locaux).
Des droits réseau (pare-feu) pour écouter sur des ports (HTTP/HTTPS).

Acceptez si vous voulez des URLs propres du type mon-site.local. Refuser n’est pas “grave”, mais vous aurez parfois des URLs moins propres ou des blocages SSL.

Résultat attendu

Vous voyez l’interface Local avec un écran listant vos sites (probablement vide au début) et un bouton pour en créer un.

Étape 2 : Créer un site WordPress local (WordPress 6.9.4 + PHP 8.1+)

1) Créer un nouveau site

Cliquez sur Create a new site.
Donnez un nom clair : blog-test-wp694 (vous vous remercierez plus tard).
Choisissez l’environnement (Local propose généralement des “Preferred” ou “Custom”). Prenez Custom si vous voulez contrôler PHP.

2) Choisir PHP et le serveur

Objectif : PHP 8.1 minimum. Si Local vous propose PHP 8.2/8.3/8.4, c’est souvent une bonne idée, mais restez cohérent avec votre hébergement (pour éviter les surprises au déploiement).

PHP : 8.1+
Web server : Nginx ou Apache (les deux conviennent). Si vous débutez, gardez le choix par défaut.
Database : MySQL/MariaDB (par défaut)

3) Configurer l’admin WordPress

Définissez un utilisateur admin (évitez admin).
Choisissez un mot de passe solide (même en local : vous finirez par exporter).
Ajoutez votre email.

4) Vérifier la version WordPress installée

Local installe généralement la dernière stable. En avril 2026, vous ciblez WordPress 6.9.4. Une fois le site créé :

Cliquez sur WP Admin.
Allez dans Tableau de bord → Mises à jour.
Vérifiez la version affichée.

Si ce n’est pas 6.9.4 (ou plus récent), faites la mise à jour depuis cet écran.

Résultat attendu

Vous pouvez ouvrir :

Le site en front (page “Hello world” ou thème par défaut).
L’admin WordPress (vous êtes connecté).

Étape 3 : Vérifications WordPress indispensables après l’installation

Cette étape évite des bugs “fantômes” plus tard (liens cassés, médias qui ne s’affichent pas, REST API qui refuse).

1) Régler les permaliens

Allez dans Réglages → Permaliens.
Sélectionnez Titre de la publication.
Cliquez Enregistrer les modifications.

Pourquoi : beaucoup de plugins et de page builders supposent des permaliens “propres”.

Résultat attendu : vos URLs ressemblent à /mon-article/ et pas à /?p=123.

2) Vérifier la santé du site

Allez dans Outils → Santé du site.
Regardez les onglets État et Infos.

Vous y verrez notamment la version PHP active. Si vous voyez PHP 7.x, vous n’êtes pas sur une config compatible avec les recommandations actuelles.

Documentation officielle : Site Health (Santé du site) – Developer Resources

3) Activer les mises à jour automatiques (optionnel en local)

En local, je préfère souvent désactiver les mises à jour automatiques pour garder un environnement stable pendant un debug. Mais si vous utilisez le local comme “bac à sable de test”, activez-les.

Doc officielle : Automatic Updates – Developer Resources

Résultat attendu

Permaliens configurés.
Santé du site sans alertes critiques.
Version PHP confirmée (8.1+).

Étape 4 : Activer SSL local et choisir un domaine propre

Vous n’avez pas “besoin” de SSL pour WordPress en local, mais j’ai souvent vu des plugins refuser de fonctionner sans HTTPS (paiement, callbacks, éditeurs, iframes).

1) Choisir un domaine local stable

Dans Local, chaque site a un domaine. Évitez les noms qui changent ou trop génériques.

Bon : blog-test.local
Moins bon : test.local (vous en aurez 10)

2) Activer SSL dans Local

Sélectionnez votre site dans Local.
Allez dans l’onglet SSL (ou équivalent selon version).
Cliquez Trust / Enable SSL.

Sur macOS/Windows, Local installe un certificat local de confiance. Si votre OS demande un mot de passe admin, c’est normal.

3) Vérifier WordPress côté URLs

Dans l’admin WordPress :

Allez dans Réglages → Général.
Vérifiez Adresse web de WordPress (URL) et Adresse web du site (URL).

Elles doivent correspondre à votre domaine local, idéalement en https:// si SSL est activé.

Résultat attendu

Votre site s’ouvre en https:// sans alerte navigateur.
Les URLs WordPress pointent vers le bon domaine.

Étape 5 : Importer un site existant (migration vers le local)

Le piège classique : importer “les fichiers” sans la base, ou importer la base sans remplacer les URLs. Résultat : admin inaccessible, images cassées, redirections en boucle.

Méthode recommandée (débutant) : plugin de migration

Pour un premier import, utilisez un plugin de migration reconnu. Je ne vous donne pas un “plugin magique universel”, parce que ça dépend des tailles et des hébergeurs, mais le principe reste le même :

Exporter depuis le site en ligne.
Importer dans le site Local.
Corriger les URLs si nécessaire.

Si vous préférez une méthode officielle “sans plugin”, passez à la sous-section suivante.

Méthode manuelle (fiable) : fichiers + base + remplacement d’URLs

1) Récupérer les fichiers du site

Via FTP/cPanel : téléchargez tout le dossier WordPress (ou au minimum wp-content si vous repartez d’un WordPress vierge).
Gardez une copie du fichier wp-config.php (utile pour vérifier le préfixe de tables).

2) Exporter la base de données

Depuis phpMyAdmin (ou l’outil de votre hébergeur), exportez la base en .sql.

3) Importer dans Local

Local fournit souvent un accès base (Adminer/phpMyAdmin) ou une commande. Si vous avez un bouton “Open Adminer”/“Database”, utilisez-le, puis importez le .sql.

4) Remplacer les URLs dans la base (étape critique)

WordPress stocke l’URL du site dans la base. Après import, vous devez remplacer :

https://votresite.com → https://votresite.local
et parfois http:// → https:// si vous activez SSL en local

Le remplacement doit respecter les données sérialisées. Évitez un “Rechercher/Remplacer” brut dans un éditeur de texte.

Option sûre (WP-CLI) : si Local vous donne un terminal avec WP-CLI, utilisez search-replace.

# Remplacez l'URL de production par l'URL locale en respectant la sérialisation
# Exécutez cette commande à la racine du site WordPress (là où se trouve wp-config.php)
wp search-replace 'https://www.votresite.com' 'https://votresite.local' --all-tables --precise

# Si votre site était en http et que vous passez en https en local
wp search-replace 'http://votresite.local' 'https://votresite.local' --all-tables --precise

WP-CLI est documenté ici : WP-CLI search-replace – Developer Resources

5) Forcer les URLs si vous ne pouvez pas accéder à l’admin

Si vous êtes bloqué (redirections, écran blanc), vous pouvez temporairement forcer l’URL dans wp-config.php. Dans Local, ouvrez le fichier wp-config.php du site et ajoutez (ou modifiez) :

<?php
// Forçage temporaire des URLs du site pour débloquer une migration locale
// À retirer une fois l'accès à l'admin rétabli et les URLs corrigées en base.
define( 'WP_HOME', 'https://votresite.local' );
define( 'WP_SITEURL', 'https://votresite.local' );

Référence : wp-config.php – Developer Resources

Résultat attendu

Vous vous connectez à l’admin en local avec les comptes existants.
Les pages s’affichent sans redirection vers le domaine de production.
Les médias se chargent (ou au pire, il ne reste que quelques chemins à corriger).

Étape 6 : Exporter / déployer vers un hébergement (avec prudence)

Le déploiement (local → production) est l’étape où les erreurs coûtent le plus cher. Même si votre site est “juste un blog”, une mauvaise URL en base ou un plugin de cache mal réglé peut rendre le site inaccessible.

1) Sauvegarde avant tout

Sauvegardez fichiers + base sur l’hébergement.
Si votre hébergeur propose un point de restauration, créez-en un.

2) Méthode simple : plugin de migration

Pour débuter, c’est souvent le plus fiable : export depuis Local, import sur le serveur. Les bons outils gèrent les remplacements d’URL et la sérialisation.

3) Méthode manuelle : fichiers + base + search-replace

Si vous déployez manuellement :

Uploadez les fichiers (ou au minimum wp-content).
Importez la base sur le serveur.
Faites un search-replace inverse (local → production).

# Exemple : passage de l'URL locale vers l'URL de production
wp search-replace 'https://votresite.local' 'https://www.votresite.com' --all-tables --precise

Résultat attendu

Le site en ligne pointe sur le bon domaine.
Les liens internes et médias sont corrects.
L’admin est accessible et les permaliens fonctionnent.

Étape 7 : Mettre en place un mini-workflow pro (thème enfant, mu-plugin, debug)

Cette étape est volontairement “petite”, mais elle change tout pour éviter les erreurs de débutant : code collé au mauvais endroit, snippets perdus, debug impossible.

1) Créer un thème enfant (si vous modifiez l’apparence)

Un thème enfant hérite du thème parent. Vous y mettez vos modifications pour ne pas les perdre lors des mises à jour.

Créez un dossier dans wp-content/themes/mon-theme-enfant/ avec un style.css minimal :

/*
Theme Name: Mon Thème Enfant
Template: twentytwentyfive
Version: 1.0.0
*/

/* Vos styles ici */

À adapter : la valeur Template doit être le dossier du thème parent (ex. astra, generatepress, etc.).

2) Créer un mu-plugin pour les réglages techniques

Je recommande un mu-plugin pour tout ce qui est “environnement” (debug, logs, petits ajustements). Vous évitez de dépendre d’un plugin de snippets qui peut être désactivé.

Créez le dossier wp-content/mu-plugins/ (s’il n’existe pas), puis un fichier :

wp-content/mu-plugins/local-dev-tools.php

<?php
/**
 * Plugin Name: Local Dev Tools (MU)
 * Description: Petits réglages utiles uniquement en environnement local.
 * Author: Vous
 * Version: 1.0.0
 */

// Sécurité : empêche l'accès direct au fichier.
if ( ! defined( 'ABSPATH' ) ) {
	exit;
}

/**
 * Détecte un environnement local de façon simple.
 * Ici : si l'URL contient ".local" ou si on est en 127.0.0.1.
 */
function bpcab_is_local_env(): bool {
	$home = (string) get_option( 'home' );

	if ( str_contains( $home, '.local' ) ) {
		return true;
	}

	$server_addr = $_SERVER['SERVER_ADDR'] ?? '';
	return in_array( $server_addr, array( '127.0.0.1', '::1' ), true );
}

/**
 * Active des réglages de debug en local uniquement.
 * Hook (action) : un point où WordPress exécute votre code.
 * Ici, on attend "init" car WordPress a chargé l'essentiel.
 */
add_action( 'init', function () {
	if ( ! bpcab_is_local_env() ) {
		return;
	}

	// Désactive l'indexation (évite de publier une URL locale par erreur).
	update_option( 'blog_public', '0' );

	// Petit indicateur dans l'admin bar.
	add_action( 'admin_bar_menu', function ( $wp_admin_bar ) {
		if ( ! is_admin_bar_showing() ) {
			return;
		}

		$wp_admin_bar->add_node(
			array(
				'id'    => 'bpcab-local-env',
				'title' => 'Local',
				'href'  => '#',
				'meta'  => array( 'title' => 'Environnement local (LocalWP)' ),
			)
		);
	}, 100 );
} );

Ce code ne remplace pas WP_DEBUG (qui se règle plutôt dans wp-config.php), mais il vous donne un filet de sécurité et un repère visuel.

3) Activer le debug proprement (wp-config.php)

En local, activez le debug et loggez dans un fichier. Ouvrez wp-config.php et ajoutez/ajustez :

<?php
// Debug WordPress (recommandé en local)
// Affiche les erreurs : utile en dev, à éviter en production.
define( 'WP_DEBUG', true );

// Écrit les erreurs dans wp-content/debug.log
define( 'WP_DEBUG_LOG', true );

// N'affiche pas les erreurs à l'écran (évite de casser l'HTML et les requêtes AJAX)
define( 'WP_DEBUG_DISPLAY', false );

// Pour être sûr que l'affichage est bien coupé
@ini_set( 'display_errors', '0' );

Référence : Debug WordPress – Developer Resources

Résultat attendu

Un thème enfant activable (si besoin).
Un mu-plugin chargé automatiquement.
Un fichier wp-content/debug.log qui se remplit quand une erreur PHP se produit.

Le résultat complet

Si vous voulez tout “copier d’un bloc”, voici le minimum utile côté code pour un environnement local propre :

1) mu-plugin complet

<?php
/**
 * Plugin Name: Local Dev Tools (MU)
 * Description: Petits réglages utiles uniquement en environnement local.
 * Author: Vous
 * Version: 1.0.0
 */

if ( ! defined( 'ABSPATH' ) ) {
	exit;
}

function bpcab_is_local_env(): bool {
	$home = (string) get_option( 'home' );

	if ( str_contains( $home, '.local' ) ) {
		return true;
	}

	$server_addr = $_SERVER['SERVER_ADDR'] ?? '';
	return in_array( $server_addr, array( '127.0.0.1', '::1' ), true );
}

add_action( 'init', function () {
	if ( ! bpcab_is_local_env() ) {
		return;
	}

	// Empêche l'indexation (utile si vous partagez des URLs locales par erreur).
	update_option( 'blog_public', '0' );

	// Ajoute un badge "Local" dans la barre d'admin.
	add_action( 'admin_bar_menu', function ( $wp_admin_bar ) {
		if ( ! is_admin_bar_showing() ) {
			return;
		}

		$wp_admin_bar->add_node(
			array(
				'id'    => 'bpcab-local-env',
				'title' => 'Local',
				'href'  => '#',
				'meta'  => array( 'title' => 'Environnement local (LocalWP)' ),
			)
		);
	}, 100 );
} );

2) Extrait wp-config.php (debug local)

<?php
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', '0' );

Personnalisation utile

Si votre domaine local n’est pas en .local, adaptez bpcab_is_local_env() (ex. .test).
Si vous clonez des sites clients, ajoutez un préfixe au nom du site local (ex. clientx-staging.local).

Adapter pour Divi 5 / Elementor / Avada

Local marche très bien avec Divi 5, Elementor et Avada. Les soucis viennent rarement de Local lui-même, mais plutôt de SSL, de permaliens, ou de cache.

Divi 5

Activez SSL local si vous utilisez des intégrations qui exigent HTTPS.
Après import/migration : allez dans Divi → Options du thème (ou équivalent Divi 5) et vérifiez les URLs si Divi stocke des liens internes.
Si vous voyez des styles qui “disparaissent” : regénérez les CSS/ressources depuis les options Divi (selon votre config).

Elementor

Après migration : faites Elementor → Outils → Régénérer les fichiers CSS & données.
Vérifiez que les permaliens sont en “Titre de la publication”. Elementor dépend souvent de règles de réécriture propres.
Si l’éditeur charge en blanc : regardez wp-content/debug.log et la console navigateur (souvent un conflit de plugin ou une URL mixte http/https).

Avada (Fusion Builder)

Après import : utilisez les outils Avada pour reconstruire le cache CSS si nécessaire.
Vérifiez les “Performance” options : certaines optimisations (minification/combinaison) masquent des erreurs en local.

Résultat attendu

Votre builder s’ouvre, vos pages s’éditent, et les styles sont cohérents. Si ce n’est pas le cas, la section “dépannage” plus bas cible les causes les plus fréquentes.

Vérification finale

Ouvrez le site en front : page d’accueil OK, pas de redirection vers l’URL de prod.
Connectez-vous à WP Admin : pas d’erreur 500, pas d’écran blanc.
Allez dans Réglages → Permaliens et cliquez “Enregistrer” une fois (ça régénère les règles).
Allez dans Outils → Santé du site → Infos et confirmez PHP 8.1+.
Si SSL activé : vérifiez que l’URL est en https:// et que le navigateur n’affiche pas d’alerte.
Si vous avez importé un site : vérifiez 3 pages au hasard + 3 images + un formulaire.

Si le résultat n’est pas celui attendu

Voici les problèmes que je vois le plus souvent avec Local, surtout après une migration.

Tableau de diagnostic

Symptôme	Cause probable	Vérification	Solution
Redirection en boucle vers le domaine de production	URLs en base non remplacées	Regardez `Réglages → Général` (si accessible) ou la table `wp_options` (home/siteurl)	WP-CLI `search-replace` ou forcer `WP_HOME/WP_SITEURL` temporairement
Erreur 500 / écran blanc	Plugin incompatible PHP 8.1+ ou fatal error	Consultez `wp-content/debug.log`	Désactivez les plugins (renommer `wp-content/plugins`), puis réactivez un par un
Images cassées / médias en 404	URLs des médias pointent encore vers l’ancien domaine	Inspectez l’HTML d’une image (src)	`search-replace` + régénération miniatures si nécessaire
Elementor/Divi charge mal l’éditeur	Mix http/https, cache builder, permaliens	Console navigateur + permaliens	Activer SSL, régénérer CSS, ré-enregistrer permaliens
Impossible d’ouvrir le site en https (alerte certificat)	Certificat non “trusted” par l’OS	Le navigateur affiche “connexion non privée”	Dans Local : SSL → Trust / réinstaller le certificat

Actions rapides (dans l’ordre)

Videz le cache navigateur (oui, ça règle parfois des soucis d’assets).
Ré-enregistrez les permaliens.
Ouvrez wp-content/debug.log et cherchez “Fatal error”.
Désactivez tous les plugins, testez, puis réactivez un par un.
Si migration : faites un search-replace propre.

Pièges et erreurs courantes

Erreur	Cause	Solution
Coller du code dans le mauvais fichier	Vous modifiez un thème parent au lieu du thème enfant	Créez/activez un thème enfant, ou utilisez un mu-plugin
Oublier un point-virgule dans `wp-config.php`	Erreur de syntaxe PHP	Restaurez le fichier, puis réappliquez les lignes une par une
Tester un snippet “d’un vieux tuto”	Code obsolète / incompatible WordPress 6.9.4 ou PHP 8.1+	Vérifiez la doc Developer Resources et testez en local avec `WP_DEBUG`
Confusion action vs filtre	Vous utilisez `add_filter` au lieu de `add_action` (ou l’inverse)	Relisez la doc des hooks et vérifiez la signature de la fonction
Le CSS/JS ne se charge pas	Mauvais enqueue, cache, ou URL mixte	Vérifiez la console navigateur + régénérez les assets du builder
Vous déployez en prod sans sauvegarde	Excès de confiance	Sauvegarde fichiers + base, puis seulement après migration
Erreur liée à PHP trop ancien sur l’hébergement	Local est en PHP 8.2, prod en PHP 7.4	Alignez les versions : mettez l’hébergement à niveau (8.1+) ou baissez la version locale temporairement

Variante / alternative

Alternative 1 : WordPress Playground (sans installer Local)

Si votre besoin est juste de “tester vite fait un plugin” ou d’explorer l’admin, WordPress Playground peut suffire. Ça tourne dans le navigateur, sans serveur local classique.

WordPress Playground – Developer Resources

Limites : pas idéal pour de gros sites, pas parfait pour simuler un hébergement, et certaines intégrations externes sont plus compliquées.

Alternative 2 : DevKinsta / Docker (plus avancé)

Si vous voulez un environnement plus “proche prod” ou reproductible en équipe, Docker est souvent le standard. C’est plus technique, mais très solide.

Pour démarrer côté PHP : Versions supportées de PHP – php.net

Conseils sécurité, performance et maintenance

Ne réutilisez pas en production un wp-config.php de local avec WP_DEBUG activé. Risque : fuite d’informations (chemins, requêtes, erreurs).
Évitez “admin/admin” même en local : vous finirez par cloner/déployer, et les mauvaises habitudes voyagent.
Gardez Local à jour : les mises à jour corrigent souvent des soucis SSL, de certificats, et de compatibilité OS.
Alignez les versions : si votre hébergement est en PHP 8.1, travaillez en local en PHP 8.1 aussi. C’est la cause n°1 des “ça marche en local mais pas en ligne”.
Nettoyez vos sites locaux : au bout de 6 mois, on a 20 copies. Archivez (export) et supprimez ce qui ne sert plus.

Pour aller plus loin

Ajouter WP-CLI à votre routine (search-replace, export DB, gestion plugins). Doc : WP-CLI Commands – Developer Resources
Mettre en place Git pour versionner votre thème enfant ou votre plugin custom.
Créer un plugin “site-specific” (au lieu de coller du code dans functions.php) pour vos fonctionnalités.
Tester les mises à jour WordPress en local avant prod. Notes officielles : WordPress Releases – wordpress.org/news
Comprendre les hooks : Hooks (actions & filtres) – Developer Resources

Ressources

FAQ

Local by Flywheel est-il gratuit ?

Local propose une version gratuite suffisante pour la majorité des usages (créer des sites, gérer PHP, SSL local). Certaines fonctionnalités avancées peuvent dépendre des offres/éditions au moment où vous l’utilisez.

Dois-je choisir Apache ou Nginx dans Local ?

Pour un blog classique, les deux fonctionnent. Si vous débutez, gardez le choix par défaut. Si votre hébergement est en Nginx, choisir Nginx en local peut réduire les surprises, mais ce n’est pas obligatoire.

Pourquoi mon site importé me renvoie vers l’URL de production ?

Parce que l’URL est stockée en base (et parfois dans des contenus). La solution la plus propre est un wp search-replace qui respecte la sérialisation.

Où trouver le fichier debug.log ?

Dans wp-content/debug.log, si WP_DEBUG_LOG est à true. Si le fichier n’apparaît pas, déclenchez une erreur (ou visitez une page qui plante) et vérifiez les droits d’écriture du dossier wp-content.

Est-ce que Local ralentit mon ordinateur ?

Quand vos sites sont arrêtés, l’impact est faible. Quand un site tourne, il consomme des ressources (PHP + base). Si vous avez plusieurs sites, arrêtez ceux que vous n’utilisez pas.

Puis-je utiliser Local avec WooCommerce ?

Oui. Pensez à activer SSL en local, surtout si vous testez des moyens de paiement ou des callbacks. Pour des tests réalistes (webhooks externes), vous aurez parfois besoin d’un tunnel (type ngrok) ou d’un staging public.

Comment être sûr de respecter WordPress 6.9.4 ?

Après création du site, vérifiez Tableau de bord → Mises à jour. Si Local n’a pas installé la dernière stable, mettez à jour depuis cet écran.

Je vois une erreur “PHP version too low” sur mon hébergement, mais pas en local

Votre local est en PHP 8.1+ et votre serveur est trop ancien. Alignez les versions. Aujourd’hui, viser PHP 8.1 minimum est un plancher raisonnable (et souvent nécessaire pour les plugins récents).

Dois-je modifier functions.php pour ajouter du code ?

Évitez si vous débutez. Un mu-plugin (ou un petit plugin custom) est plus sûr : vous limitez les risques de perdre du code en changeant de thème, et vous savez exactement où se trouve votre logique.

Pourquoi mon builder (Elementor/Divi/Avada) n’affiche pas les styles après migration ?

Souvent : cache, permaliens, ou CSS généré à régénérer. Commencez par ré-enregistrer les permaliens, puis régénérez les fichiers CSS via l’outil du builder.

Est-ce que je peux partager mon site Local à un client ?

Pas directement comme un site public. Pour montrer à un client, exportez et déployez sur un staging en ligne, ou utilisez un tunnel temporaire si vous maîtrisez la sécurité (attention : vous exposez potentiellement un WordPress non durci).