Skip to Content
WordPressPartie 4 — Installation & environnement de devOptions d'environnement local

Chapitre 4.1 — Options d’environnement local

⏱️ TL;DR — On ne développe jamais en production. Il vous faut un WordPress local. Quatre options courantes : LocalWP (le plus simple, interface graphique), wp-env (officiel, Docker, idéal pour le dev de plugins/thèmes versionnés), Studio (par WordPress.com, moderne et léger), et Docker sur mesure (contrôle total). Pour apprendre, LocalWP ou wp-env couvrent 95 % des besoins. L’important : un environnement jetable, reproductible, en mode développeur.

🎯 Objectifs

  • Comprendre pourquoi un environnement local est indispensable.
  • Comparer LocalWP, wp-env, Studio et Docker.
  • Choisir l’outil adapté à votre usage (apprentissage vs projet versionné).
  • Savoir ce qu’un bon environnement de dev doit fournir.

1. Pourquoi local, et pas en ligne ?

  • Sécurité : casser une install locale n’a aucune conséquence.
  • Vitesse : pas de latence réseau, rechargements instantanés.
  • Outils : Xdebug, logs, WP-CLI, accès direct à la base et aux fichiers.
  • Reproductibilité : recréer un environnement identique à volonté.
  • Isolation : plusieurs sites/projets sans interférence.

💡 Pour un dev React — C’est votre npm run dev du monde WordPress : une instance locale qui tourne pendant que vous codez. La différence : WordPress a besoin de PHP + un serveur web + MySQL (une « stack LAMP/LEMP »). Les outils ci-dessous empaquettent cette stack pour vous — vous n’installez pas Apache/MySQL à la main.

2. Les quatre options

LocalWP (le plus accessible)

Application de bureau (Mac/Windows/Linux) : un clic crée un site (choix de PHP, serveur, base). Fournit un accès à la base (Adminer), aux logs, un shell WP-CLI, des liens de partage. Idéal pour débuter et pour des sites clients.

wp-env (officiel, orienté dev de code)

Fourni par l’équipe WordPress (paquet @wordpress/env, via npm + Docker). On décrit l’environnement dans un fichier .wp-env.json versionné avec le projet, et wp-env start monte tout. Le choix quand vous développez un plugin/thème que vous voulez tester dans un environnement reproductible et partageable (idéal en équipe et en CI).

// .wp-env.json — à la racine d'un plugin/thème
{
  "core": "WordPress/WordPress#6.6",
  "plugins": ["."],
  "config": { "WP_DEBUG": true }
}
npm -g i @wordpress/env
wp-env start      # démarre WordPress sur http://localhost:8888
wp-env run cli wp plugin list   # exécuter WP-CLI dans le conteneur

Studio (par WordPress.com)

Application locale récente, gratuite, légère, sans Docker. Création de sites en quelques secondes, démos partageables. Bonne alternative moderne à LocalWP.

Docker Compose sur mesure

Pour ceux qui veulent tout contrôler (version PHP précise, Nginx, Redis, config MySQL). Plus de travail, mais transparence totale. Recommandé quand vous maîtrisez déjà Docker et voulez coller à une prod spécifique.

3. Comparatif express

CritèreLocalWPwp-envStudioDocker
Facilité⭐⭐⭐⭐⭐⭐⭐⭐⭐
Reproductible/versionné⭐⭐⭐⭐⭐⭐⭐⭐
Dev de plugin/thème⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐
CI (tests automatisés)✖⭐⭐⭐✖⭐⭐⭐
Sans Docker✔✖✔✖

Recommandation pour ce cours : LocalWP pour explorer WordPress sans friction, wp-env dès que vous développez un plugin/thème (il servira aussi pour les tests, Partie 11). Les deux peuvent cohabiter.

⚠️ Piège — Reproduisez au maximum votre prod cible en local : même version de PHP (8.1/8.2/8.3), même version de WordPress, extensions PHP similaires. Un plugin qui marche en local sous PHP 8.3 mais crash en prod sous PHP 7.4 est un classique. wp-env/Docker rendent ce cadrage explicite ; avec LocalWP, choisissez la bonne version PHP à la création.

4. Ce qu’un bon environnement fournit

  • PHP + serveur web + MySQL empaquetés.
  • Mode développeur activable (WP_DEBUG, logs — ch. 4.5).
  • Accès à la base (Adminer/phpMyAdmin) et aux fichiers.
  • WP-CLI disponible (ch. 4.3).
  • Idéalement, HTTPS local et e-mails capturés (Mailpit/Mailhog) pour tester les envois sans spammer.

✏️ Exercices

  1. Pourquoi ne développe-t-on jamais directement en production ?
  2. Vous démarrez un plugin que vous versionnerez sur Git et testerez en CI. Quel outil local privilégiez-vous et pourquoi ?
  3. Un plugin fonctionne en local mais casse chez le client. Quelle cause d’environnement vérifiez-vous en premier ?

✅ Solution

  1. Parce qu’une erreur en prod affecte de vrais visiteurs/données ; en local, casser n’a aucune conséquence, et on dispose d’outils de dev (logs, Xdebug, WP-CLI) qu’on n’a pas en prod.
  2. wp-env : environnement décrit dans un fichier JSON versionné avec le projet, reproductible et utilisable en CI (Partie 11). Idéal pour un plugin/thème partagé.
  3. La version de PHP (et les extensions) : un décalage (ex. 8.3 en local vs 7.4 en prod) provoque des erreurs. Aligner les environnements résout la majorité de ces cas.

🧠 Quiz de révision

1. De quoi WordPress a-t-il besoin pour tourner ?

PHP, un serveur web (Apache/Nginx) et une base MySQL/MariaDB — une stack LAMP/LEMP.

2. Quel outil local est officiel et versionnable ?

wp-env (@wordpress/env), basé sur Docker et un fichier .wp-env.json.

3. Quel outil est le plus simple pour débuter ?

LocalWP (interface graphique, tout inclus, sans configuration).

4. Pourquoi aligner la version PHP locale sur la prod ?

Pour éviter qu’un code fonctionnant en local échoue en prod à cause d’une version PHP différente.

5. Citez deux services de confort d’un bon environnement de dev.

Accès à la base (Adminer/phpMyAdmin), capture d’e-mails (Mailpit), HTTPS local, WP-CLI. (Deux au choix.)

Chapitre suivant : wp-config.php & constantes.

Partie 4 — Installation & environnement de développementwp-config.php & constantes