Pendant longtemps, monter un environnement WordPress local voulait dire installer MAMP ou WampServer, configurer un virtual host Apache à la main, éditer le fichier hosts du système, puis croiser les doigts pour que la version de PHP corresponde à celle du serveur de production. Local (anciennement Local by Flywheel) a changé la donne en empaquetant tout ça dans une application de bureau.
On l’utilise depuis plusieurs mois sur les projets qui ne nécessitent pas de configuration Docker sur mesure, et pour former les nouveaux arrivants qui ne connaissent pas encore les subtilités d’un environnement serveur. Voici ce qui nous a convaincus, et ce qui nous a parfois freinés.
L’installation d’un site en pratique
Depuis l’application, créer un nouveau site tient en trois étapes : un nom de site, un choix d’environnement (PHP, serveur web, MySQL), et des identifiants d’administration. En arrière-plan, Local monte des conteneurs (ou des machines virtuelles légères selon la version) et configure automatiquement un domaine local en .local, avec certificat SSL auto-signé si on l’active.
- Choix de la version de PHP par site, pratique pour reproduire l’environnement exact d’un client sous PHP 7.2 pendant qu’un autre projet tourne en PHP 7.4
- Choix entre Nginx et Apache, avec la possibilité de basculer sans réinstaller le site
- Un accès direct au fichier
wp-config.php, aux logs et à un shell SSH local depuis l’interface
Adminer et le tunnel intégrés
Deux fonctionnalités qu’on utilise au quotidien : l’accès direct à Adminer pour inspecter la base sans installer phpMyAdmin, et la fonction « Live Link » qui ouvre un tunnel temporaire pour partager le site local avec un client ou un collègue, sans déployer quoi que ce soit. Pratique pour une validation rapide en cours de développement, sur des projets qui n’ont pas encore d’environnement de staging.
# Exemple de structure générée par Local pour un site
~/Local Sites/mon-site/
├── app/
│ └── public/ # racine WordPress, identique à un hébergement classique
├── conf/
│ ├── nginx/
│ └── php/
└── logs/Cette structure a un avantage sous-estimé : le dossier app/public est un WordPress classique, sans particularité. On peut donc y travailler exactement comme sur n’importe quel hébergement, avec Git, WP-CLI (accessible via le shell intégré) et tous les outils habituels.
Où Local montre ses limites
Les projets Composer et Bedrock
Local part du principe qu’un site WordPress a une structure classique, WordPress à la racine. Sur un projet Bedrock, où WordPress se trouve dans un sous-dossier web/wp, l’intégration native perd de son intérêt : il faut adapter manuellement la configuration du serveur web, ce qui annule une bonne partie du gain de simplicité.
La reproductibilité en équipe
Contrairement à Docker Compose ou à wp-env, la configuration d’un site Local n’est pas facilement versionnable ni partageable entre développeurs sous forme de fichier texte. Chaque membre de l’équipe recrée son site manuellement depuis l’application, avec un risque de divergence de versions PHP ou MySQL entre les postes si personne n’y fait attention.
Local face aux alternatives
| Critère | Local | Docker / wp-env |
|---|---|---|
| Facilité de prise en main | Très élevée, interface graphique | Nécessite de connaître Docker |
| Configuration versionnable en équipe | Limitée | Oui, via des fichiers de configuration |
| Adapté à Bedrock | Difficilement | Oui, nativement |
| Coût | Gratuit (fonctions avancées payantes) | Gratuit |
On recommande Local sans hésiter à un développeur qui débute sur WordPress ou qui travaille seul sur des projets classiques. Dès qu’une équipe grandit ou qu’un projet passe sous Bedrock, on bascule vers une configuration Docker maison.
Un bon choix pour démarrer, pas une fin en soi
Ce qui fait la force de Local, c’est justement de masquer la complexité d’un environnement serveur à quelqu’un qui découvre le développement WordPress. Pour une agence qui forme régulièrement de nouveaux profils, c’est un vrai gain de temps sur l’onboarding : un développeur junior est opérationnel en quelques minutes, sans avoir à comprendre la configuration d’un serveur web.
En résumé
Local reste, à ce jour, l’outil le plus simple pour démarrer un projet WordPress en local sans connaissances système poussées. Ses limites apparaissent sur des structures de projet non standard comme Bedrock, ou dès qu’une équipe a besoin d’une configuration partagée et versionnée. Pour ces cas-là, on se tourne plutôt vers Docker, sujet qu’on détaillera dans un prochain article.
