# Lando ou wp-env pour une équipe qui développe plusieurs sites WordPress

> Deux outils basés sur Docker, deux philosophies opposées pour standardiser l'environnement de développement d'une équipe.

- Auteur : Clément Hadrot
- Publié le : 2025-11-13
- Mis à jour le : 2025-11-13
- Catégorie : Hébergement & serveurs
- URL : https://wpmoderne.dev.wordpress-developpement.fr/hebergement/lando-wp-env-equipe-plusieurs-sites-wordpress/

## L’essentiel

- wp-env vise la simplicité, Lando vise la personnalisation
- Le choix dépend surtout du nombre de services annexes nécessaires
- Une équipe hétérogène a plus à gagner d'un standard strict

Cinq développeurs, huit projets WordPress actifs, et jusqu'ici, cinq façons différentes de faire tourner un environnement local : MAMP pour l'un, un Docker Compose écrit à la main pour l'autre, XAMPP pour un troisième encore équipé d'un poste plus ancien. Standardiser cette base devient une nécessité dès que le nombre de projets partagés dépasse ce que chacun peut retenir de mémoire.

Deux outils dominent aujourd'hui ce choix pour une équipe qui travaille exclusivement sur WordPress : `wp-env`, maintenu par l'équipe cœur du projet et distribué via npm, et Lando, un outil plus généraliste construit lui aussi sur Docker mais capable de gérer des piles bien plus variées.

## wp-env : la simplicité du standard officiel

wp-env s'installe globalement via npm et se configure entièrement dans un unique fichier `.wp-env.json` placé à la racine du projet :

```
{
  "core": "WordPress/WordPress#6.7",
  "plugins": [ "." ],
  "phpVersion": "8.2"
}
```

Une seule commande démarre l'environnement complet, base de données comprise :

```
wp-env start
```

Cette simplicité a une contrepartie : wp-env part du principe que le projet est une extension ou un thème isolé, pensé pour être testé indépendamment. Il gère mal les projets qui nécessitent un service supplémentaire non prévu par défaut, comme un moteur de recherche externe ou un service de file de messages.

## Lando : plus de services, plus de configuration

Lando repose sur un fichier `.lando.yml` nettement plus riche, capable de décrire des services additionnels au-delà de PHP et MySQL :

```
name: projet-client
recipe: wordpress
config:
  php: '8.2'
  webroot: web
services:
  cache:
    type: redis
```

Cette flexibilité permet de reproduire fidèlement une pile de production incluant Redis pour le cache d'objet ou Elasticsearch pour la recherche, ce que wp-env ne propose pas nativement.

> L'essentiel à retenir : wp-env vise la simplicité, Lando vise la personnalisation ; Le choix dépend surtout du nombre de services annexes nécessaires ; Une équipe hétérogène a plus à gagner d'un standard strict

## Tableau comparatif

| Critère | wp-env | Lando |
| --- | --- | --- |
| Installation | npm global, très légère | binaire dédié, plus lourd |
| Configuration | un seul fichier JSON minimal | fichier YAML plus verbeux |
| Services additionnels | limités, extensions officielles surtout | Redis, Elasticsearch, Solr possibles |
| Maintenu par | équipe cœur WordPress | éditeur tiers indépendant |
| Courbe d'apprentissage | faible | modérée |

## Le critère qui tranche pour une équipe

Pour une équipe qui développe principalement des extensions ou des thèmes destinés à être publiés indépendamment, wp-env s'impose par sa proximité directe avec les outils de test officiels : les scripts de test PHPUnit fournis par l'équipe cœur de WordPress s'appuient nativement sur cette configuration.

Pour une équipe qui gère des projets clients complets, avec des services annexes propres à chaque hébergement de production, Lando offre la flexibilité nécessaire pour reproduire fidèlement chaque environnement cible, y compris quand ils diffèrent sensiblement d'un client à l'autre.

### Un point commun décisif : le fichier versionné

Dans les deux cas, la configuration entière de l'environnement vit dans un fichier versionné avec le code, ce qui règle le vrai problème de départ : n'importe quel développeur qui clone un projet obtient un environnement identique, sans dépendre de ce qui est déjà installé sur sa machine.

## Ce que change vraiment l'arrivée d'un nouveau développeur

Le vrai test d'un environnement standardisé ne se joue pas sur les projets déjà en cours, mais sur l'arrivée d'une nouvelle personne dans l'équipe. Avec wp-env comme avec Lando, l'installation se résume à cloner le dépôt, installer les dépendances et lancer une seule commande, sans jamais avoir à ouvrir la moindre documentation interne pour reconstituer une configuration PHP ou MySQL particulière :

```
git clone git@depot:projet-client.git
cd projet-client
npm install
lando start
```

Comparé à une installation manuelle via MAMP ou XAMPP, où chaque écart de version de PHP entre postes finissait tôt ou tard par provoquer un bug impossible à reproduire d'une machine à l'autre, ce gain de fiabilité pèse souvent plus lourd dans la décision que la richesse fonctionnelle de l'outil choisi.

### Migrer d'un outil à l'autre en cours de route

Rien n'empêche une équipe de commencer avec wp-env sur ses premiers projets, puis de basculer vers Lando le jour où un client impose un service annexe non supporté. La migration reste raisonnable : les données de la base et les médias se réexportent via WP-CLI indépendamment de l'outil de conteneurisation utilisé, seule la configuration de l'environnement change de format.

> Un choix qui a simplifié l'intégration des nouveaux arrivants sur nos projets : imposer wp-env par défaut, et ne basculer vers Lando que pour les projets qui ont un besoin explicite et documenté d'un service supplémentaire.

## Verdict

Aucun des deux outils n'est objectivement supérieur : wp-env gagne sur la simplicité et l'alignement avec les outils officiels, Lando gagne sur la richesse des services disponibles. Une équipe hétérogène gagne davantage à imposer un standard unique, quel qu'il soit, qu'à laisser chaque développeur choisir librement son propre environnement.