Travailler à plusieurs sur un projet WordPress, c’est souvent le début des ennuis : « ça marche sur ma machine » est sans doute la phrase la plus redoutée de tout dev en équipe. Les Dev Containers VS Code règlent ce problème à la racine en partageant un environnement de développement identique pour tout le monde, directement dans le dépôt Git. Dans cet article, on va voir comment mettre ça en place concrètement pour WordPress, de la configuration initiale jusqu’aux outils du quotidien comme WP-CLI et Xdebug.
Pourquoi adopter les Dev Containers pour WordPress ?
On va se dire les choses franchement : développer WordPress en équipe, c’est souvent une source de friction énorme. Chacun a sa config locale, ses versions de PHP, son MySQL installé à la va-vite… et inévitablement, un bug apparaît chez l’un mais pas chez l’autre. Le fameux syndrome du « ça marche sur ma machine ».
Le problème du « ça marche sur ma machine »
Bon, si vous avez déjà travaillé à plusieurs sur un projet WordPress, vous connaissez le scénario : Pierre tourne sous PHP 8.1, Julie sous PHP 7.4, et le serveur de production est en 8.2. Résultat ? Des comportements différents, des warnings qui n’apparaissent pas partout, et un onboarding de nouveau développeur qui prend facilement une demi-journée (voire plus).
Et ce n’est pas juste une question de PHP. La version de MySQL, les extensions activées, les variables d’environnement, le fait que macOS gère les chemins différemment de Windows… tout ça s’accumule. Chaque poste devient une petite configuration unique, fragile, difficile à reproduire.
C’est un problème réel, qui coûte du temps et génère de la frustration. Et plus l’équipe grandit, plus ça devient critique.
Ce que les Dev Containers changent concrètement
Un Dev Container, c’est simple à définir : un environnement de développement entièrement décrit par du code, embarqué dans un conteneur Docker et piloté directement depuis VS Code.
Concrètement, ça veut dire quoi ? Que l’environnement — PHP, MySQL, WordPress, les extensions VS Code, les outils CLI — est défini dans des fichiers versionnés dans votre repo Git. Quand un nouveau développeur rejoint l’équipe, il clone le projet, ouvre VS Code, clique sur « Reopen in Container », et c’est parti. Une commande. Rien d’autre.
Les bénéfices sont vraiment concrets :
- Reproductibilité totale : tout le monde tourne exactement sur la même stack, que ce soit sur macOS, Windows ou Linux.
- Onboarding ultra-rapide : fini les longues doc d’installation. Le container fait le travail.
- Extensions VS Code partagées : chaque développeur a automatiquement les mêmes outils (PHP Intelephense, phpcs, etc.) sans configuration manuelle.
- Isolation propre : le projet n’interfère pas avec le reste du système.
C’est ce dernier point qui est souvent sous-estimé. Ne plus avoir de conflits entre les projets, c’est une vraie liberté.
Comparaison avec les autres approches (XAMPP, Lando, Docker Compose seul)
Evidemment, les Dev Containers ne sont pas les seuls outils du marché. XAMPP, LocalWP, Lando, ou même un simple docker-compose.yml maison — chacun a ses avantages. Mais dans un contexte multi-développeurs, certaines limites deviennent vite gênantes.
Voici une comparaison rapide sur les critères qui comptent le plus en équipe :
| Critère | LocalWP | Lando | Docker Compose seul | Dev Containers |
|---|---|---|---|---|
| Reproductibilité | ⚠️ Partielle | ✅ Bonne | ✅ Bonne | ✅ Totale |
| Partage en équipe | ❌ Difficile | ✅ Possible | ⚠️ Manuel | ✅ Natif (Git) |
| Intégration VS Code | ❌ Aucune | ❌ Aucune | ⚠️ Limitée | ✅ Native |
| Courbe d’apprentissage | ✅ Très faible | ⚠️ Moyenne | ⚠️ Moyenne | ⚠️ Moyenne |
LocalWP est excellent pour un développeur solo qui veut démarrer vite. Lando est une bonne option pour les équipes qui veulent plus de contrôle. Mais aucun des deux n’intègre nativement VS Code ni ne partage les outils et extensions automatiquement via le repo.
Docker Compose seul, par contre, c’est puissant — mais vous devez tout configurer vous-même, y compris l’environnement VS Code. Les Dev Containers viennent justement combler ce manque : ils s’appuient sur Docker, mais ajoutent cette couche d’intégration IDE qui change vraiment l’expérience au quotidien.
Mettre en place le Dev Container WordPress pas à pas
On rentre maintenant dans le vif du sujet. Cette section est vraiment le cœur de l’article : on va tout configurer de zéro, étape par étape, pour avoir un environnement WordPress fonctionnel dans un Dev Container. Prenez le temps de suivre chaque étape — ça peut sembler un peu long au premier abord, mais une fois en place, vous ne reviendrez pas en arrière.
Prérequis : Docker Desktop et l’extension Dev Containers
Avant de toucher au moindre fichier de config, il faut s’assurer que les outils de base sont bien installés sur votre machine.
Voici ce dont vous avez besoin :
- Docker Desktop : téléchargeable sur docker.com/products/docker-desktop. Disponible sur Windows, macOS et Linux.
- VS Code avec l’extension Dev Containers (
ms-vscode-remote.remote-containers) — installez-la directement depuis le marketplace VS Code. - Git : indispensable pour versionner vos fichiers de configuration et les partager avec l’équipe.
Côté configuration minimale recommandée : 8 Go de RAM sur votre machine. WordPress + MariaDB + Apache dans des containers, ça tourne bien, mais en dessous de 8 Go vous risquez de sentir les limites assez vite (surtout si vous avez d’autres apps ouvertes en parallèle).
Une fois Docker Desktop lancé et l’extension installée dans VS Code, vous devriez voir apparaître une petite icône verte >< en bas à gauche de l’éditeur. C’est le signe que tout est prêt.
Structure des fichiers de configuration (.devcontainer)
L’idée centrale des Dev Containers, c’est que toute la configuration de l’environnement vit dans le code source lui-même. Concrètement, on crée un dossier .devcontainer/ à la racine du projet, et c’est là que tout se passe.
Voici l’arborescence type qu’on va mettre en place :
mon-projet-wordpress/
├── .devcontainer/
│ ├── devcontainer.json
│ └── docker-compose.yml
├── wp-content/
│ ├── plugins/
│ ├── themes/
│ └── uploads/
└── .gitignore
Le dossier wp-content/ est celui que vous versionnez — vos thèmes, vos plugins custom, tout ce qui constitue vraiment votre projet. WordPress lui-même (le core) est géré par l’image Docker : pas besoin de le committer. C’est une séparation propre et logique.
Et bien sûr, ce dossier .devcontainer/ est committé dans Git. C’est ce qui permet à tous les devs de l’équipe de récupérer exactement le même environnement avec un simple git clone.
Configurer le docker-compose.yml pour WordPress + MariaDB
C’est ici que l’on définit les services qui font tourner l’environnement. On a besoin de deux containers : un pour WordPress (Apache + PHP) et un pour la base de données (MariaDB).
Voici un exemple complet et commenté :
version: '3.8'
services:
wordpress:
image: wordpress:php8.2-apache
restart: unless-stopped
ports:
- "8080:80" # Accès via http://localhost:8080
environment:
WORDPRESS_DB_HOST: db
WORDPRESS_DB_USER: wpuser
WORDPRESS_DB_PASSWORD: wppassword
WORDPRESS_DB_NAME: wordpress
volumes:
# On monte wp-content pour travailler sur nos thèmes/plugins
- ../wp-content:/var/www/html/wp-content
# Volume nommé pour persister wp-content entre les rebuilds
- wp_content_data:/var/www/html/wp-content
depends_on:
- db
db:
image: mariadb:10.11
restart: unless-stopped
environment:
MYSQL_ROOT_PASSWORD: rootpassword
MYSQL_DATABASE: wordpress
MYSQL_USER: wpuser
MYSQL_PASSWORD: wppassword
volumes:
# Volume nommé pour persister la BDD entre les sessions
- db_data:/var/lib/mysql
volumes:
db_data:
wp_content_data:
Quelques points importants à noter :
- On utilise
wordpress:php8.2-apache: une image officielle stable avec PHP 8.2 et Apache intégrés. Pratique, pas besoin de gérer un Dockerfile custom pour débuter. - Le port mapping
8080:80permet d’accéder à WordPress viahttp://localhost:8080sans conflit avec d’autres services locaux. - Les volumes nommés (
db_data,wp_content_data) sont cruciaux : ils permettent de persister les données entre les redémarrages du container. Sans ça, vous perdez votre base de données à chaquedocker compose down. Pas idéal ! - Le montage de
../wp-contentvers/var/www/html/wp-contentest ce qui permet à tous les développeurs de partager les mêmes plugins et thèmes via Git. C’est le point central du workflow multi-devs.
Personnaliser devcontainer.json : extensions, settings, forwardPorts
Le fichier devcontainer.json, c’est la pièce maîtresse. C’est lui qui dit à VS Code comment ouvrir le projet dans le container, quelles extensions installer automatiquement, et comment configurer l’éditeur.
Voici un exemple complet :
{
"name": "WordPress Dev",
"dockerComposeFile": "docker-compose.yml",
"service": "wordpress",
"workspaceFolder": "/var/www/html",
"customizations": {
"vscode": {
"extensions": [
"bmewburn.vscode-intelephense-client", // Autocomplétion PHP
"esbenp.prettier-vscode", // Formatage du code
"eamodio.gitlens", // Git avancé dans VS Code
"ms-azuretools.vscode-docker", // Gestion des containers
"wongjn.php-sniffer" // PHPCS / WordPress Coding Standards
],
"settings": {
"php.validate.executablePath": "/usr/local/bin/php",
"editor.formatOnSave": true,
"editor.defaultFormatter": "esbenp.prettier-vscode",
"[php]": {
"editor.defaultFormatter": "bmewburn.vscode-intelephense-client"
}
}
}
},
"forwardPorts": [8080, 3306],
"postCreateCommand": "curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar && chmod +x wp-cli.phar && mv wp-cli.phar /usr/local/bin/wp"
}
Décortiquons les parties importantes :
service: "wordpress": indique à VS Code dans quel container il doit « entrer ». C’est le container principal où vous écrirez votre code.workspaceFolder: "/var/www/html": le dossier qui s’ouvre par défaut dans VS Code — la racine WordPress dans le container.- Les extensions sont installées automatiquement pour tout le monde à l’ouverture du Dev Container. Plus de « ah mais moi j’ai pas Intelephense d’installé » dans l’équipe !
forwardPorts: [8080, 3306]: VS Code va automatiquement forwarder ces ports depuis le container vers votre machine locale. Le port 3306 est particulièrement utile pour se connecter à MariaDB avec un client comme TablePlus ou DBeaver.postCreateCommand: cette commande s’exécute une seule fois à la création du container. Ici, on installe WP-CLI directement — un outil en ligne de commande indispensable pour gérer WordPress (installer des plugins, créer des utilisateurs, vider le cache, etc.).
Bon, c’est un peu dense tout ça, je vous l’accorde. Mais c’est exactement ce que vous devrez configurer une seule fois. Après, vous committez ces fichiers, et chaque nouveau développeur qui rejoint l’équipe n’aura qu’à ouvrir le projet dans VS Code pour avoir exactement le même environnement. C’est là toute la puissance du système.
Travailler en équipe efficacement avec ce setup
On a vu comment mettre en place le Dev Container, c’est bien. Mais la vraie valeur ajoutée de cette approche, c’est ce qui se passe quand plusieurs développeurs travaillent sur le même projet. Voilà comment tirer le meilleur parti de ce setup en équipe.
Partager la configuration avec Git et le .gitignore adapté
La règle d’or : tout ce qui est dans .devcontainer/ doit être commité. Le devcontainer.json, le docker-compose.yml, les éventuels Dockerfile custom — tout ça doit vivre dans le repo Git. C’est précisément ce qui permet à un nouveau développeur de cloner le projet, d’ouvrir VS Code et de cliquer sur « Reopen in Container » pour avoir un environnement identique au vôtre en quelques minutes. Pas de documentation à lire, pas de dépendances à installer manuellement. Ça, c’est le gain concret.
Par contre, certains fichiers n’ont rien à faire dans Git. Votre .gitignore doit contenir au minimum :
# WordPress
wp-config.php
wp-content/uploads/
# Docker local data
.docker/
mysql_data/
# Variables d'environnement
.env
Le wp-config.php peut contenir des identifiants sensibles selon votre setup — mieux vaut le générer automatiquement (on y revient avec les scripts d’initialisation). Le dossier uploads/ peut rapidement peser plusieurs gigaoctets, inutile de le versionner. Et les volumes Docker locaux (mysql_data/ ou autre) sont propres à chaque machine, ils ne doivent surtout pas se retrouver dans le repo.
Aller plus loin : WP-CLI, Xdebug et scripts d’initialisation
C’est là que le setup devient vraiment puissant. Ces trois outils transforment un simple environnement Docker en véritable station de développement professionnelle.
WP-CLI dans le conteneur
Si vous avez suivi la section précédente, WP-CLI est déjà intégré via le postCreateCommand. Sinon, vous pouvez l’ajouter dans un Dockerfile custom basé sur wordpress:php8.2-apache :
FROM wordpress:php8.2-apache
RUN curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar \
&& chmod +x wp-cli.phar \
&& mv wp-cli.phar /usr/local/bin/wp
Une fois en place, les commandes WP-CLI permettent de prépopuler l’environnement en quelques secondes :
wp core install --url="http://localhost:8080" --title="Mon Projet" --admin_user=admin --admin_password=admin --admin_email=dev@exemple.fr
wp plugin install woocommerce --activate
wp user create dev dev@dev.fr --role=editor --user_pass=dev
Plus besoin de passer par l’interface d’installation WordPress à chaque git clone. C’est un gain de temps réel, surtout quand on onboarde un nouveau développeur.
Xdebug : enfin du vrai débogage PHP
Soyons honnêtes : déboguer avec var_dump() ou même Query Monitor seul, c’est limité. Xdebug change vraiment la donne — points d’arrêt, inspection des variables, pile d’appels… on travaille enfin comme sur n’importe quel autre langage.
Pour l’ajouter, on étend le Dockerfile :
RUN pecl install xdebug \
&& docker-php-ext-enable xdebug
RUN echo "xdebug.mode=debug" >> /usr/local/etc/php/conf.d/xdebug.ini \
&& echo "xdebug.start_with_request=yes" >> /usr/local/etc/php/conf.d/xdebug.ini \
&& echo "xdebug.client_host=host.docker.internal" >> /usr/local/etc/php/conf.d/xdebug.ini \
&& echo "xdebug.client_port=9003" >> /usr/local/etc/php/conf.d/xdebug.ini
L’option host.docker.internal est importante : c’est ce qui permet au conteneur de joindre VS Code sur votre machine hôte. Côté éditeur, ajoutez un fichier .vscode/launch.json :
{
"version": "0.2.0",
"configurations": [
{
"name": "Listen for Xdebug",
"type": "php",
"request": "launch",
"port": 9003,
"pathMappings": {
"/var/www/html/wp-content/themes/mon-theme": "${workspaceFolder}/wp-content/themes/mon-theme"
}
}
]
}
Pensez bien à adapter le pathMappings : il fait le lien entre le chemin dans le conteneur et votre dossier local. Sans ça, les points d’arrêt ne fonctionneront pas.
Scripts d’initialisation avec init.sh
L’idée est simple : un script shell appelé par le postCreateCommand dans votre devcontainer.json qui automatise tout le setup initial.
"postCreateCommand": "bash .devcontainer/init.sh"
Et le script init.sh ressemble à ça :
#!/bin/bash
set -e
echo "⏳ Installation de WordPress..."
wp core install \
--url="http://localhost:8080" \
--title="Dev Project" \
--admin_user=admin \
--admin_password=admin \
--admin_email=admin@dev.local \
--skip-email
echo "🔌 Activation des plugins de développement..."
wp plugin install query-monitor debug-bar --activate
echo "✅ Environnement prêt !"
Résultat : dès l’ouverture du Dev Container, WordPress est installé, les plugins de debug sont actifs, et le développeur peut coder immédiatement. Pas de friction, pas d’étapes oubliées. C’est exactement ce qu’on cherche dans un workflow multi-développeurs efficace.