ddev config --project-type=wordpress : la commande qui démarre tout, pour un développeur freelance qui jonglait jusque-là entre un serveur local classique et un serveur Node lancé manuellement dans un second terminal, sans grande cohérence entre les deux environnements d’un projet headless.
DDEV encapsule chaque projet dans ses propres conteneurs Docker, ce qui évite les conflits de version de PHP ou de Node entre plusieurs projets hébergés sur la même machine. Ce tutoriel détaille comment faire cohabiter, dans un même environnement local, l’API WordPress et le front qui la consomme.
Étape 1 : initialiser le projet WordPress
$ mkdir mon-projet-api && cd mon-projet-api
$ ddev config --project-type=wordpress --docroot=web
$ ddev startCette séquence crée les fichiers de configuration DDEV, démarre les conteneurs nécessaires (PHP, base de données, serveur web) et rend le site accessible via une URL locale du type https://mon-projet-api.ddev.site, sans configuration réseau manuelle.
Étape 2 : créer un second projet DDEV pour le front
Plutôt que de lancer le serveur de développement du front en dehors de tout conteneur, un second projet DDEV, de type générique cette fois, permet d’héberger le front dans le même écosystème :
$ mkdir mon-projet-front && cd mon-projet-front
$ ddev config --project-type=nodejs
$ ddev start
Étape 3 : faire communiquer les deux services
DDEV attribue à chaque projet un nom d’hôte interne résolu automatiquement dans le réseau Docker partagé, ce qui permet au front d’appeler l’API sans passer par une adresse IP fixe ni une configuration réseau complexe :
# Dans le fichier de configuration du front
API_URL=https://mon-projet-api.ddev.site/wp-jsonLe front, lancé via ddev npm run dev depuis son propre projet, consomme cette variable exactement comme il le ferait en production, avec pour seule différence l’URL cible de l’API.
Étape 4 : automatiser le démarrage des deux services
Un script shell simple, placé à la racine d’un dossier parent contenant les deux projets, évite d’oublier de démarrer l’un des deux services avant de commencer une session de travail :
#!/bin/bash
cd mon-projet-api && ddev start
cd ../mon-projet-front && ddev startLe piège du certificat local à ne pas oublier
DDEV génère automatiquement un certificat local de confiance pour chaque projet, via mkcert, ce qui permet d’utiliser HTTPS dès le premier démarrage. Ce détail, facile à négliger, évite un écueil fréquent avec un front qui vérifie strictement l’origine des requêtes ou qui refuse de fonctionner correctement en HTTP simple, notamment pour tester certains comportements liés aux cookies.
Un développeur qui recrée son environnement sur une nouvelle machine doit simplement relancer mkcert -install une fois avant le premier ddev start, sans quoi le navigateur affichera un avertissement de certificat non reconnu, sans gravité mais gênant au quotidien.
Ce que cette organisation apporte concrètement
- Isolation complète entre les versions de PHP et de Node utilisées par chaque projet client
- Aucune dépendance à une installation locale de PHP ou de Node en dehors de Docker
- Un environnement reproductible à l’identique sur une autre machine, via les fichiers de configuration versionnés
Un environnement local qui dépend de versions installées manuellement sur la machine finit toujours par diverger d’un poste à l’autre, surtout quand plusieurs projets clients se succèdent.
Un projet, un fichier de configuration versionné
Chaque projet DDEV génère un dossier .ddev contenant sa configuration, versionnable dans le même dépôt Git que le code du projet. Un développeur qui rejoint ce projet freelance sur une nouvelle mission n’a besoin que de cloner le dépôt puis de lancer ddev start pour retrouver un environnement identique, sans documentation supplémentaire à rédiger ni installation manuelle à reproduire de mémoire.
En résumé
DDEV permet de faire cohabiter proprement l’API WordPress et le front d’un projet headless sur une même machine de développement, avec une isolation complète entre projets et une communication réseau interne qui ne nécessite aucune configuration manuelle. Ce tutoriel ne couvre pas la mise en place de l’intégration continue, qui reprendrait une logique différente une fois le code poussé vers un dépôt partagé.
