Deux commandes, deux philosophies : wp-env start lance un environnement WordPress minimal en quelques secondes à partir de la configuration officielle du projet Gutenberg, tandis que ddev start démarre une stack complète, plus proche d’un hébergement mutualisé classique, avec son propre serveur web configurable. Pour valider un correctif touchant au fichier robots.txt généré dynamiquement ou au sitemap natif de WordPress, ce choix d’outil n’est pas neutre.
Le point de départ de ce comparatif est un cas précis : un correctif consistant à filtrer certaines URL du sitemap natif via wp_sitemaps_posts_query_args, et à modifier dynamiquement le contenu du robots.txt via le filtre robots_txt. La question posée était simple : quel environnement local permet de valider ce correctif dans des conditions les plus proches possible de la production, avant de le déployer ?
Présentation rapide des deux outils
wp-env est l’outil officiel maintenu dans le dépôt de Gutenberg sur GitHub, pensé avant tout pour le développement d’extensions et de thèmes en environnement standardisé et reproductible entre plusieurs machines. Il repose sur Docker en arrière-plan mais masque presque entièrement sa configuration, via un simple fichier .wp-env.json à la racine du projet.
DDEV est un outil plus généraliste, pensé pour reproduire des environnements web variés, pas uniquement WordPress. Il permet de configurer plus finement le serveur web utilisé (Apache ou Nginx), la version de PHP, et d’ajouter des règles de réécriture personnalisées proches de celles utilisées en production.
Comparatif sur les quatre critères qui comptent pour ce correctif
| Critère | wp-env | DDEV |
|---|---|---|
| Fidélité au cœur WordPress | Élevée, mise à jour suit directement le dépôt officiel | Élevée, dépend de l’image WordPress choisie |
| Configuration du serveur web | Limitée, peu de contrôle sur les règles de réécriture | Fine, règles Nginx ou Apache personnalisables |
| Reproduction d’un htaccess de production | Difficile sans configuration additionnelle | Directe, via l’ajout du fichier de configuration réel |
| Rapidité de démarrage | Très rapide, quelques secondes | Un peu plus longue au premier démarrage |
Ce que ça change concrètement pour robots.txt
Le fichier robots.txt généré dynamiquement par WordPress dépend d’une règle de réécriture qui intercepte la requête avant de la faire passer par le cœur PHP. Sur un hébergement mutualisé de production, cette règle est souvent définie au niveau du serveur web lui-même, avec des particularités propres à l’hébergeur. wp-env, qui masque la configuration du serveur, ne permet pas de reproduire fidèlement ce genre de règle spécifique sans modification manuelle de sa configuration interne, ce qui va à l’encontre de sa philosophie de simplicité.
curl http://localhost/robots.txt
# wp-env : dépend du serveur interne fourni par Docker, générique
# DDEV : peut refléter une règle de réécriture copiée du .htaccess de production
Ce que ça change concrètement pour le sitemap natif
Le sitemap natif de WordPress, disponible depuis la version 5.5, repose entièrement sur le cœur PHP et les routes REST, sans dépendre d’une configuration serveur particulière. Sur ce point précis, les deux outils se comportent de façon équivalente : un filtre comme wp_sitemaps_posts_query_args se comporte identiquement sur wp-env et sur DDEV, puisque la logique reste entièrement gérée par WordPress lui-même.
add_filter( 'wp_sitemaps_posts_query_args', function( $args, $post_type ) {
if ( 'produit' === $post_type ) {
$args['meta_query'] = array(
array( 'key' => 'archive', 'value' => '1', 'compare' => '!=' ),
);
}
return $args;
}, 10, 2 );
Verdict argumenté
Pour un correctif limité au comportement interne de WordPress, comme un filtre sur le sitemap natif, wp-env suffit largement et se montre plus rapide à mettre en place pour un test ponctuel. Dès que le correctif touche à une règle de réécriture serveur, à un fichier .htaccess réel ou à un comportement lié à la configuration Nginx ou Apache de l’hébergement de production, DDEV devient le choix le plus fiable, au prix d’une configuration initiale un peu plus longue.
La règle qu’on applique sur ce type de choix : si le correctif peut se résumer à un filtre ou une fonction du cœur, l’outil le plus léger suffit ; s’il touche la couche serveur, mieux vaut reproduire cette couche fidèlement plutôt que de tester à l’aveugle directement en production.
En résumé
Aucun des deux outils n’est strictement supérieur à l’autre pour valider un correctif de référencement technique : le choix dépend de la couche touchée par le correctif. Un filtre interne au cœur se teste aussi bien sur wp-env que sur DDEV, tandis qu’une règle de réécriture serveur ou un comportement lié au fichier .htaccess de production réclame la configuration plus fine offerte par DDEV.
