DDEV est un outil de développement local open source basé sur Docker qui te permet de créer un environnement WordPress entièrement configuré avec une seule commande – et associé à l’IA, c’est devenu un élément central de notre façon de travailler chez what.
Voici pourquoi on a fait ce changement et ce qu’il change concrètement au quotidien.
Le problème des environnements locaux incohérents
Avant DDEV, chaque développeur de l’équipe utilisait l’environnement local avec lequel il était à l’aise – MAMP, Local by Flywheel, peu importe.
Les versions PHP différaient d’une machine à l’autre. Les versions MySQL ne correspondaient pas à celles utilisées en production. Les types de serveurs web (Nginx vs Apache) n’étaient pas cohérents.
Résultat : un bug apparaît sur le site en ligne, personne ne peut le reproduire localement, et tout le monde passe une heure à modifier des paramètres avant même de commencer à déboguer.
Intégrer un nouveau développeur ou reprendre un projet existant impliquait à chaque fois entre 30 et 60 minutes de configuration manuelle – installation des dépendances, importation des bases de données, configuration des URL locales.
Comment DDEV standardise l’environnement local
DDEV intègre les conteneurs Docker dans un outil CLI simple. Toute la configuration de l’environnement – version PHP, version MySQL, type de serveur web – se trouve dans un seul fichier .ddev/config.yaml directement intégré au dépôt du projet.
Ce fichier fait beaucoup de boulot. Chaque développeur qui clone le dépôt obtient automatiquement un environnement identique, sans configuration manuelle ni incompatibilité de versions.
Pour démarrer, il suffit littéralement de taper ddev start. Tout se met en place, l’URL locale est prête et reflète exactement la production.
On stocke aussi l’URL du site local dans 1Password, car elle est toujours prévisible. N’importe quel membre de l’équipe peut se lancer dans un projet sans demander d’identifiants à personne.
Quelques modules complémentaires DDEV qu’on utilise dans presque tous les projets :
- Mailpit – intercepte les e-mails PHP localement, ce qui permet de tester les formulaires de contact sans service de messagerie externe
- Xdebug – débogage PHP étape par étape avec des points d’arrêt directement dans l’éditeur de code
- xhgui – profilage des performances et analyse des goulots d’étranglement dans l’environnement local
- phpMyAdmin / Adminer – gestion visuelle de la base de données, aucune configuration supplémentaire requise
IA + DDEV : remplacer les étapes manuelles par des instructions en langage simple
Comme DDEV fonctionne entièrement depuis le terminal, il s’intègre parfaitement aux assistants de codage IA. L’IA peut exécuter des commandes DDEV, lancer WP-CLI, interroger la base de données, exécuter des scripts PHP, gérer des tâches cron – en gros, tout ce que tu ferais manuellement, déclenché par une simple instruction en langage naturel.
Quelques exemples concrets qu’on utilise régulièrement :
- « Vérifie si la base de données est surchargée par un plugin »
- « Installe [nom du plugin] et active-le »
- « Le site a des problèmes de performance – utilise xhgui pour diagnostiquer le problème »
- « Crée 100 articles de blog avec des dates, des titres et des images mises en avant aléatoires provenant de la médiathèque pour que je puisse tester la pagination »
- « Un plugin génère des erreurs PHP et le site ne se charge plus – vérifie le journal des erreurs, corrige le problème et confirme la correction »
Ce dernier exemple illustre bien l’intérêt pratique de cette approche. L’IA vérifie le journal, identifie le problème, applique une correction et exécute un script PHP ou recharge le navigateur pour confirmer que ça a fonctionné – sans que tu aies à changer de contexte.
Les tâches qui nécessitaient généralement entre 10 et 30 minutes de travail manuel ne prennent désormais que quelques secondes à quelques minutes.
Ce que ça change en pratique
Le résultat, c’est un environnement reproductible qui reflète la production, combiné à un workflow où les tâches routinières se font en langage naturel plutôt que manuellement.
Au-delà du gain de temps, ça réduit aussi la charge cognitive. Moins de va-et-vient entre les terminaux, la documentation et les outils de base de données, ça veut dire plus de concentration sur le vrai problème à résoudre.
Pour le développement WordPress en particulier – que ce soit pour des thèmes personnalisés, du débogage de plugins ou des projets de plus grande envergure – cette combinaison augmente concrètement ce qu’un seul développeur peut gérer dans une journée.
Ce qui arrive ensuite
On est en train de créer un script de démarrage qui s’exécutera automatiquement au premier ddev start d’un projet, en récupérant la dernière sauvegarde de production et en l’important dans l’environnement local.
Ça permettrait de réduire le temps de configuration complet d’un projet de 30 à 60 minutes à seulement quelques minutes, selon la vitesse de connexion. L’objectif : minimiser le temps entre « je dois travailler sur ce projet » et le moment où on commence vraiment à bosser dessus.
Tu veux en savoir plus sur notre façon de créer et de gérer des sites WordPress ? Jette un œil à nos services WordPress pour voir comment on aborde les projets de A à Z.
