Sur un projet repris d’une autre agence, la documentation tenait en une phrase dans le README : « voir avec Julien pour le déploiement ». Julien avait quitté l’entreprise depuis huit mois. Ce genre de situation, plus fréquent qu’on ne le pense, pousse à standardiser les commandes d’un projet dans un format que n’importe qui peut lire et exécuter sans connaître l’historique du projet : un Makefile.
Make n’a rien de spécifique à WordPress — c’est un outil vieux de plusieurs décennies, présent par défaut sur macOS et la quasi-totalité des distributions Linux. Son intérêt ici n’est pas la compilation, mais l’orchestration : chaque cible devient une commande mémorisable, documentée, et surtout identique pour toute l’équipe.
Structure de base d’un Makefile WordPress
Un Makefile se compose de cibles (les mots avant les deux-points) et de leurs commandes associées, indentées par une tabulation — jamais des espaces, c’est la source d’erreur numéro un chez qui découvre l’outil :
.PHONY: install build db-pull deploy lint
install:
composer install
npm install
wp core install --url=mon-site.test --title="Mon Site" \
--admin_user=admin --admin_email=dev@agence.fr --allow-root
build:
npm run build
lint:
vendor/bin/phpcs --standard=phpcs.xml .
npm run lint:js
La directive .PHONY précise que ces noms ne correspondent pas à des fichiers réels à produire — un détail qui évite un bug classique si un fichier nommé build existait par hasard dans le dossier.
Cible db-pull : récupérer la base de production en local
La cible la plus utilisée au quotidien reste généralement celle qui synchronise la base de données depuis la production :
db-pull:
ssh prod "wp db export - --allow-root" > /tmp/prod.sql
wp db import /tmp/prod.sql
wp search-replace 'https://mon-site.fr' 'https://mon-site.test' --all-tables
rm /tmp/prod.sql
Ce qui prenait auparavant cinq commandes à retaper (souvent mal, souvent avec une URL oubliée) devient make db-pull, exécutable par n’importe quel membre de l’équipe sans connaître le détail de l’infrastructure.
Cible deploy : encapsuler le pipeline de mise en production
deploy:
@echo "Déploiement en cours vers production..."
git push production main
ssh prod "cd /var/www/mon-site && wp cache flush --allow-root"
@echo "Déploiement terminé."
Le @ en début de ligne supprime l’affichage de la commande elle-même dans le terminal, pour ne garder que sa sortie — un détail de lisibilité appréciable quand la cible s’allonge.
Variables et paramètres
Make accepte des variables, ce qui évite de dupliquer des chemins ou des noms d’environnement dans chaque cible :
ENV ?= staging
HOST_staging = user@staging.mon-site.fr
HOST_production = user@prod.mon-site.fr
deploy:
git push $(HOST_$(ENV)) main
Avec cette structure, make deploy cible le staging par défaut, tandis que make deploy ENV=production bascule explicitement vers la production — une friction volontaire qui évite un déploiement accidentel.
Make ou Taskfile : lequel choisir
| Critère | Make | Taskfile (go-task) |
|---|---|---|
| Disponibilité | Préinstallé sur macOS et Linux | Binaire à installer séparément |
| Syntaxe | Tabulations obligatoires, historique daté | YAML, plus lisible pour les non-initiés |
| Gestion multiplateforme | Limité nativement sous Windows | Fonctionne identique sur Windows, macOS, Linux |
| Dépendances entre cibles | Natif et robuste | Natif, avec variables plus lisibles |
Pour une équipe entièrement sur macOS ou Linux, Make reste le choix par défaut : zéro installation, zéro dépendance supplémentaire à maintenir. Sur une équipe mixte avec des développeurs Windows non habitués à WSL, Taskfile évite des frictions d’installation.
Documenter les cibles directement dans le fichier
Une astuce répandue consiste à ajouter une cible help qui liste automatiquement les cibles disponibles à partir de commentaires spéciaux :
help: ## Affiche cette aide
@grep -E '^[a-zA-Z_-]+:.*##' $(MAKEFILE_LIST) | \
awk 'BEGIN {FS = ":.*##"}; {printf "%-15s %s\n", $$1, $$2}'
install: ## Installe les dépendances et configure WordPress
composer install
Le Makefile devient alors sa propre documentation : make help affiche la liste des commandes disponibles, sans avoir besoin d’un README séparé qui finit toujours par se désynchroniser du code réel.
Notre verdict
Un Makefile ne remplace pas une intégration continue — il ne traite ni les tests automatisés ni les déploiements déclenchés par un événement Git, qui relèvent d’un autre sujet. Ce qu’il apporte, c’est un vocabulaire commun pour les tâches manuelles d’un projet : make install, make db-pull, make deploy fonctionnent identiquement pour chaque développeur, sur chaque projet de l’agence, sans dépendre de la mémoire de qui que ce soit.
