wp-env start : cette commande, lancée depuis le dépôt d’une extension, démarre en quelques secondes deux conteneurs, un WordPress et une base MySQL, prêts à recevoir du code. C’est l’un des grands mérites de l’environnement officiel proposé par l’équipe des outils de développement de WordPress. Mais un piège guette les équipes pressées : mutualiser une seule instance de ces conteneurs entre plusieurs développeurs, sur un serveur de développement partagé, pour économiser du temps de configuration. Le résultat est presque toujours le même, une accumulation de conflits qui coûte largement plus cher que l’installation individuelle qu’on voulait éviter.
Cet article recense les antipatterns observés sur ce genre de montage, indépendamment de la question réseau (exposition du port, nom de domaine partagé) qui mériterait un traitement à part entière. Il s’agit ici de ce qui se passe à l’intérieur des conteneurs quand plusieurs personnes y travaillent en même temps.
Ce qu’on voit : des tests qui passent chez l’un et échouent chez l’autre
Le symptôme le plus fréquent d’un wp-env mutualisé, c’est le test qui échoue de façon aléatoire sans changement de code apparent. Un développeur exécute la suite de tests PHPUnit fournie par wp-env run tests-cli et obtient un échec sur une fonctionnalité qu’il n’a pas touchée. En creusant, on découvre qu’un collègue a laissé une option activée dans wp_options, ou qu’un plugin tiers installé pour un autre besoin modifie un comportement global du site de test.
Pourquoi c’est un problème
La base de données d’un wp-env n’est pas réinitialisée entre deux sessions de travail de personnes différentes. Chaque commande wp exécutée à l’intérieur, chaque plugin activé pour vérifier un comportement, chaque contenu de démonstration ajouté reste présent pour la personne suivante. L’environnement cesse alors de représenter un état connu et devient un empilement de décisions individuelles, invisibles pour qui n’était pas là au moment où elles ont été prises.
Ce qu’on voit : des ports qui se battent entre deux projets
Deuxième antipattern classique : deux personnes travaillent sur deux extensions différentes mais partagent le même environnement, pensant simplifier la maintenance. L’une modifie le fichier .wp-env.json pour monter un volume supplémentaire nécessaire à son projet, l’autre voit son propre montage de volume disparaître au redémarrage suivant. Le fichier de configuration devient un champ de bataille silencieux, chacun écrasant sans le savoir les réglages du précédent.
- Des mappages de ports incohérents d’un jour à l’autre, sans qu’aucune modification volontaire n’ait été faite.
- Des variables d’environnement PHP (
WP_DEBUG, limites de mémoire) qui changent silencieusement selon qui a redémarré le conteneur en dernier. - Des extensions tierces installées pour un test ponctuel, jamais désinstallées, qui polluent les résultats des suivants.
- Une base de données qui grossit indéfiniment, ralentissant les imports et les exports que tout le monde utilise.
Pourquoi l’isolation individuelle coûte moins cher qu’elle n’y paraît
L’argument en faveur du partage est presque toujours le même : économiser les ressources machine et le temps de configuration initiale. En pratique, wp-env repose sur Docker et démarre un environnement complet en une commande à partir d’un simple fichier .wp-env.json versionné dans le dépôt. Le coût réel d’une instance individuelle par développeur se limite à quelques centaines de mégaoctets de RAM allouée le temps de la session de travail, largement compensés par les heures non perdues à comprendre pourquoi « ça marche chez moi mais pas chez toi ».
{
"core": "WordPress/WordPress#6.5",
"plugins": [ "." ],
"config": {
"WP_DEBUG": true,
"WP_DEBUG_LOG": true
},
"port": 8888,
"testsPort": 8889
}
Ce fichier, propre à chaque projet et versionné avec lui, permet à n’importe quel membre de l’équipe de reconstruire un environnement identique en local avec wp-env start, sans dépendre d’un serveur partagé ni d’un état hérité de la veille.
Ce qu’il faut mettre en place à la place
La bonne pratique consiste à faire de chaque poste de développement le point de départ d’un wp-env propre, réinitialisé à volonté par wp-env destroy suivi d’un wp-env start. Trois habitudes suffisent à installer cette discipline durablement dans une équipe :
- Versionner le fichier
.wp-env.jsonet le fichier.wp-env.override.jsonpour les réglages personnels, ce dernier étant ignoré par Git. - Documenter dans le fichier
READMEdu dépôt la commande exacte de réinitialisation à exécuter en cas de comportement suspect. - Interdire, par convention d’équipe, toute installation manuelle de plugin de test sans passer par la configuration versionnée.
Sur nos projets, la règle qui a le plus réduit les signalements de bogues fantômes tient en une phrase : un environnement de développement suspect se détruit, il ne se débogue pas.
Notre verdict
Un wp-env partagé donne l’illusion d’un gain de temps à l’installation, mais transfère ce coût vers chaque session de débogage ultérieure, où personne ne sait plus vraiment quel état a produit quel comportement. L’isolation par personne, rendue triviale par la légèreté de Docker et par la simplicité du fichier de configuration officiel, reste la seule approche qui garde l’environnement de développement fidèle à ce qu’il est censé représenter : un état reproductible, identique pour tout le monde, à volonté.
