Sur un thème WordPress classique, sans blocs personnalisés ni build JavaScript complexe, installer Webpack juste pour obtenir un rechargement automatique du navigateur relève du sur-dimensionnement. Le thème contient quelques fichiers PHP, une feuille de style, un peu de jQuery : la mise en place d’un bundler complet pour ce périmètre ajoute de la configuration sans apporter de valeur proportionnelle.
Deux outils plus modestes suffisent largement à ce besoin : Watchman, développé par Facebook pour surveiller des arborescences de fichiers à grande échelle, et BrowserSync, qui synchronise le rechargement entre le navigateur et les modifications détectées. Ensemble, ils reproduisent l’expérience de rechargement en direct sans jamais toucher à un fichier de configuration de bundler.
Le rôle de chaque outil
Watchman observe le système de fichiers en continu et déclenche des commandes lorsqu’un motif de fichiers correspond à un changement : un fichier .css modifié, un fichier .php sauvegardé. Il ne connaît rien au navigateur ni à WordPress, il se contente de surveiller et d’exécuter une commande arbitraire.
BrowserSync, de son côté, agit comme un proxy entre le navigateur et le serveur WordPress local. Il injecte un petit script dans les pages servies, qui reste en écoute d’un signal de rechargement. Quand ce signal arrive, il recharge la page, ou injecte directement le nouveau CSS sans recharger si seul le style a changé.
Installation de Watchman

Sur macOS, Watchman s’installe via Homebrew ; sur Linux, une compilation depuis les sources ou un paquet de la distribution fait l’affaire :
brew install watchman
La configuration se fait par un fichier .watchmanconfig à la racine du thème, puis par une déclaration de triggers :
watchman watch .
watchman -- trigger . reload-css '*.css' -- echo "css changed"
Ce déclencheur seul ne suffit pas : il faut le relier à BrowserSync pour que le navigateur réagisse réellement.
Mettre en place BrowserSync
BrowserSync s’installe comme un paquet npm classique, sans configuration de bundler associée :
npm install --save-dev browser-sync
Un petit script Node démarre le proxy en pointant vers l’URL locale du site WordPress (via Local, MAMP ou un serveur PHP intégré) :
const browserSync = require('browser-sync').create();
browserSync.init({
proxy: 'monprojet.test',
files: ['**/*.css', '**/*.php'],
open: false
});
Dans cette configuration minimale, BrowserSync surveille lui-même les fichiers via son propre watcher interne, ce qui peut suffire pour de petits thèmes. Watchman entre en jeu quand le projet grossit et que le watcher par défaut de Node devient trop gourmand en ressources sur de grosses arborescences, ou quand des règles de déclenchement plus fines sont nécessaires (ignorer certains dossiers, réagir différemment selon le type de fichier).
Un exemple de configuration combinée
Pour aller plus loin, un fichier de triggers Watchman peut appeler directement l’API de rechargement de BrowserSync via son endpoint HTTP, ce qui découple totalement les deux outils :
watchman -- trigger . php-reload '*.php' -- \
curl -s http://localhost:3001/__browser_sync__?method=reload
Cette approche évite de dépendre du watcher interne de BrowserSync pour les fichiers PHP, ce qui, sur un thème volumineux avec de nombreux templates, réduit sensiblement la charge CPU du processus Node en développement.
Sur les petits thèmes clients sans build JS, on préfère toujours cette combinaison légère à l’installation d’un Webpack qui ne servirait qu’à recharger une page.
Limites de cette approche
- Aucune transformation de code n’est effectuée : pas de Sass compilé, pas de minification, pas de bundling de modules JS.
- Pour un thème utilisant Sass ou des blocs personnalisés avec JSX, cette solution devient vite insuffisante et un outil comme Vite ou
@wordpress/scriptsreprend tout son sens. - BrowserSync ajoute un script de synchronisation dans les pages ; il faut veiller à ne jamais l’activer sur un environnement de production.
Notre verdict
Pour un thème WordPress classique, sans étape de compilation, la paire Watchman et BrowserSync couvre l’essentiel du besoin de rechargement en direct avec une configuration qui tient en quelques lignes. C’est un choix pragmatique tant que le projet reste simple ; dès que la complexité front grandit, mieux vaut basculer vers un outillage de build complet plutôt que d’empiler des scripts de surveillance maison.