# Reproduire un serveur mutualisé exact avec DDEV avant une migration

> Recette pour construire, avec DDEV, une copie fidèle d'un environnement mutualisé cible et y tester une migration avant de basculer le vrai site en production.

- Auteur : WordPress Développement
- Publié le : 2023-02-13
- Mis à jour le : 2023-02-13
- Catégorie : Hébergement & serveurs
- URL : https://www.wpmoderne.fr/hebergement/reproduire-serveur-mutualise-exact-ddev-avant-migration/

## L’essentiel

- Extraire les versions exactes de l'environnement cible avant de commencer
- Reproduire la configuration PHP, pas seulement sa version
- Valider la migration entière en local avant toute bascule réelle

`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

> L'essentiel à retenir : Extraire les versions exactes de l'environnement cible avant de commencer ; Reproduire la configuration PHP, pas seulement sa version ; Valider la migration entière en local avant toute bascule réelle

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 = 1500
```

Six 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.

1. Import de la base de production dans le DDEV configuré.
2. Exécution du script de migration complet, avec journalisation détaillée de chaque étape.
3. Vérification manuelle des pages sensibles : formulaires, galeries, export PDF, avec les limites PHP restrictives réellement actives.
4. 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.