Un conteneur qui démarre en douze secondes d’un côté, un cluster de conteneurs facturé au trafic de l’autre. Entre les deux, le même dépôt Git, le même contenu de base de données exporté chaque matin, et pourtant deux façons de faire tourner WordPress qui n’ont presque rien en commun côté infrastructure.
Une agence qui gère une dizaine de sites clients affronte ce grand écart tous les jours. DDEV encapsule PHP, la base et le serveur web dans des conteneurs jetables sur le poste du développeur. Kinsta, à l’autre bout, orchestre l’hébergement de production sur sa propre couche Google Cloud, avec des règles Nginx et des limites PHP-FPM imposées par le fournisseur. Le défi n’est pas de faire tourner WordPress deux fois : c’est de faire en sorte que ce qui fonctionne en local fonctionne aussi une fois déployé, sans surprise.
Ce que DDEV impose comme structure
DDEV part d’un fichier .ddev/config.yaml qui décrit la version de PHP, le type de projet et la configuration de la base. Ce fichier vit dans le dépôt Git du site, ce qui signifie que chaque développeur qui clone le projet obtient un environnement identique en une commande :
ddev config --project-type=wordpress --php-version=8.3
ddev start
ddev import-db --file=dump-production.sql.gz
Le point important : DDEV ne connaît rien de Kinsta. Il ignore les règles de cache, les restrictions sur wp-config.php ou les particularités du système de fichiers en lecture seule que Kinsta applique en production. Toute la configuration spécifique à l’hébergeur doit donc être isolée ailleurs pour ne pas polluer l’environnement local.
Ce que Kinsta impose côté production
Kinsta fournit un accès SSH restreint, un cache de page géré à un niveau qui échappe à WordPress lui-même, et une politique stricte sur les extensions de cache concurrentes. Le fichier wp-config.php livré en production contient des constantes propres à la plateforme, notamment celles liées au cache d’objet Redis fourni en standard sur les offres supérieures.
La solution qui fonctionne dans la durée consiste à séparer strictement trois couches : le code applicatif du thème et des extensions, qui est identique partout ; les constantes d’environnement, qui changent d’un contexte à l’autre ; et les réglages propres à l’infrastructure d’accueil, qui ne doivent jamais remonter dans le dépôt versionné.
Un wp-config.php qui détecte son contexte
La méthode la plus robuste consiste à faire porter la bascule par une variable d’environnement plutôt que par une détection de nom de domaine, fragile dès qu’un nom de domaine de prévisualisation change :
if ( getenv( 'IS_DDEV_PROJECT' ) === 'true' ) {
define( 'WP_ENVIRONMENT_TYPE', 'local' );
define( 'WP_DEBUG', true );
} else {
define( 'WP_ENVIRONMENT_TYPE', 'production' );
define( 'WP_DEBUG', false );
}
DDEV positionne automatiquement la variable IS_DDEV_PROJECT dans ses conteneurs, ce qui évite d’avoir à la déclarer manuellement. La fonction wp_get_environment_type(), disponible depuis WordPress 5.5, permet ensuite à n’importe quelle extension de s’adapter au contexte sans avoir à réinventer sa propre détection.
Synchroniser les contenus sans casser la structure
Le flux qui fonctionne le mieux dans la pratique repose sur WP-CLI des deux côtés :
- Export de la base de production via
wp db exportexécuté par SSH sur Kinsta ; - Rapatriement du fichier compressé et import en local via
ddev import-db; - Remplacement des URL avec
wp search-replace, en conservant systématiquement l’option--dry-runavant l’exécution réelle ; - Synchronisation des médias avec
rsyncplutôt qu’un export complet, pour ne pas rapatrier des gigaoctets inutiles à chaque cycle.
Le déploiement comme dernier maillon
Kinsta accepte les déploiements par Git directement depuis son tableau de bord, ce qui élimine le besoin d’un serveur de build intermédiaire pour une agence de cette taille. Le point de vigilance porte sur le fichier .gitignore : il doit exclure les répertoires spécifiques à DDEV (.ddev/ ne pose pas de problème s’il reste dans le dépôt, mais les fichiers de configuration générés localement, eux, doivent rester hors du suivi de version.
Une règle qui a évité plusieurs incidents sur nos projets : jamais de fichier de configuration généré automatiquement dans le dépôt principal. Ce qui est généré doit rester généré, sur chaque machine, à chaque fois.
En résumé
Faire cohabiter DDEV et Kinsta ne demande pas d’outil supplémentaire, mais une discipline claire : un seul dépôt de code, une détection d’environnement fiable via wp_get_environment_type(), et un flux de synchronisation de données scripté plutôt qu’improvisé à chaque nouvelle mise à jour. Le gain se mesure au nombre de fois où un développeur peut dire, sans y penser, que ce qui marche chez lui marchera aussi une fois en ligne.
