# Un Makefile pour piloter tout un projet WordPress en une seule commande

> install, build, db-pull, deploy, lint : standardiser les commandes d'équipe avec Make, pour que personne n'ait à retenir dix scripts différents.

- Auteur : Clément Hadrot
- Publié le : 2021-02-03
- Mis à jour le : 2021-02-03
- Catégorie : Outils & workflow
- URL : https://wpmoderne.dev.wordpress-developpement.fr/outils/makefile-projet-wordpress-une-commande/

## L’essentiel

- Cibles install, build, db-pull, deploy et lint centralisées
- Make comme dénominateur commun, déjà présent partout
- Documentation vivante : le Makefile explique le projet

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

> L'essentiel à retenir : Cibles install, build, db-pull, deploy et lint centralisées ; Make comme dénominateur commun, déjà présent partout ; Documentation vivante : le Makefile explique le projet

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.