ddev config --project-type=wordpress --php-version=8.1 : cette seule ligne suffit à démarrer un environnement WordPress local, mais elle ne suffit pas à reproduire fidèlement un hébergement mutualisé réel. Une équipe préparant la migration d’un site vers un nouvel hébergeur cible s’est heurtée à ce problème : tester une migration sur un DDEV configuré par défaut donnait des résultats trop optimistes, qui ne se reproduisaient pas ensuite sur le serveur réel.
Ce n’est pas ici une comparaison générale entre DDEV et Lando, déjà traitée par ailleurs : il s’agit d’une recette précise pour transformer un environnement local générique en copie suffisamment fidèle d’un hébergement mutualisé cible, avant d’y répéter la migration autant de fois que nécessaire sans risque.
Le problème : un environnement local trop généreux
Par défaut, DDEV configure des limites PHP confortables — mémoire, temps d’exécution, taille d’upload — largement supérieures à celles d’un hébergement mutualisé réel. Une migration qui semble se dérouler sans accroc en local peut donc échouer sur le serveur cible, simplement parce que ce dernier applique des limites plus strictes que celles testées.
Étape 1 : extraire les paramètres exacts de l’hébergeur cible
Avant toute configuration de l’environnement local, un script phpinfo() temporaire a été déposé sur le nouvel hébergement cible, consulté une seule fois puis immédiatement supprimé, pour en extraire les réglages précis à reproduire.
<?php phpinfo(); ?>
# Valeurs relevées sur l'hébergeur cible :
# memory_limit = 256M
# max_execution_time = 30
# upload_max_filesize = 32M
# post_max_size = 32M
# max_input_vars = 1500
# mysql version = MariaDB 10.6Étape 2 : configurer DDEV avec ces valeurs exactes
DDEV permet de surcharger la configuration PHP par défaut via un fichier .ddev/php/php.ini personnalisé, chargé après la configuration standard du conteneur.
# .ddev/config.yaml
php_version: "8.1"
database:
type: mariadb
version: "10.6"
webserver_type: nginx-fpm# .ddev/php/php.ini
memory_limit = 256M
max_execution_time = 30
upload_max_filesize = 32M
post_max_size = 32M
max_input_vars = 1500Six paramètres au total se sont révélés divergents entre la configuration par défaut de DDEV et celle de l’hébergeur cible, dont deux — max_input_vars et max_execution_time — n’auraient jamais été suspectés sans cette extraction préalable via phpinfo().
Étape 3 : reproduire les extensions PHP activées
Au-delà des réglages numériques, la liste exacte des extensions PHP actives compte tout autant. Un hébergeur mutualisé peut par exemple ne pas activer imagick par défaut, forçant certains plugins de traitement d’image à basculer silencieusement sur GD, avec un rendu visuel légèrement différent qu’il vaut mieux découvrir en local qu’en production.
ddev exec php -m > extensions-local.txt
diff extensions-local.txt extensions-hebergeur-cible.txtÉtape 4 : rejouer la migration entière en local
Une fois l’environnement local aligné, la migration complète — copie de fichiers, import de base, recherche-remplacement d’URL — a été rejouée intégralement dans ce DDEV configuré à l’identique, avant toute tentative sur le serveur réel.
- Import de la base de production dans le DDEV configuré.
- Exécution du script de migration complet, avec journalisation détaillée de chaque étape.
- Vérification manuelle des pages sensibles : formulaires, galeries, export PDF, avec les limites PHP restrictives réellement actives.
- Correction des points de blocage identifiés directement dans le code de migration, avant de le rejouer une seconde fois en local pour confirmer la correction.
Variantes utiles
Cette recette se décline selon les besoins : un service dédié à la génération de vignettes peut être ajouté au fichier .ddev/docker-compose.imagick.yaml si l’hébergeur cible en dépend fortement ; une version de MariaDB antérieure peut être forcée si l’hébergeur n’a pas encore basculé vers une version plus récente ; un proxy limitant artificiellement la bande passante peut même être ajouté pour simuler un lien réseau plus lent, utile pour évaluer le temps réel d’un import volumineux.
Un repère qu’on retient de cette méthode : un environnement local qui ne reproduit pas les limites de l’hébergeur cible ne teste rien d’utile, il ne fait que rassurer à tort avant la vraie migration.
En résumé
Reproduire fidèlement un hébergement mutualisé cible avec DDEV demande d’extraire ses paramètres réels avant toute configuration, plutôt que de se contenter des valeurs par défaut confortables de l’outil. Cette rigueur, coûteuse en temps de préparation, évite ensuite des heures de diagnostic en production le jour de la vraie migration.
