# Passer une équipe de Local à DDEV : ce que la migration nous a appris

> Retour d'expérience sur le changement d'environnement local pour huit développeurs : configuration commune, pièges rencontrés et gains mesurés après la transition.

- Auteur : Clément Hadrot
- Publié le : 2025-01-29
- Mis à jour le : 2025-01-29
- Catégorie : Outils & workflow
- URL : https://wpmoderne.dev.wordpress-developpement.fr/outils/passer-equipe-local-ddev-retour-experience/

## L’essentiel

- La configuration versionnée a éliminé les divergences entre postes
- Le passage a pris deux semaines pour huit développeurs
- Les habitudes graphiques de Local ont le plus manqué au début

Huit développeurs, chacun avec sa propre installation de Local, ses propres versions de PHP configurées à la main, et un fichier de configuration jamais versionné : c'était la situation de départ dans l'équipe que nous accompagnons depuis deux ans. Le déclencheur du changement n'a pas été une insatisfaction envers Local en tant que tel, mais un incident précis — un développeur qui travaillait sur PHP 8.0 alors que le serveur de production venait de passer en 8.2, avec un bug de compatibilité découvert seulement en recette.

DDEV a été choisi pour une raison simple : sa configuration se versionne entièrement dans un dossier `.ddev/` commité avec le projet, ce qui garantit que chaque développeur démarre exactement le même environnement, à la même version de PHP, sans réglage manuel.

## Ce qui a changé concrètement

Avec Local, chaque développeur configurait sa version de PHP dans l'interface graphique, indépendamment des autres. Avec DDEV, la version est déclarée une seule fois dans le fichier de configuration du projet, lu automatiquement par chaque poste :

```
# .ddev/config.yaml
name: site-client-restaurant
type: wordpress
docroot: ""
php_version: "8.2"
webserver_type: nginx-fpm
database:
  type: mariadb
  version: "10.11"
```

Ce fichier, une fois commité, élimine mécaniquement la classe d'incidents qui avait déclenché la migration : impossible pour un développeur de travailler sur une version de PHP différente de celle déclarée par le projet, puisque DDEV la lit automatiquement au démarrage.

## Le calendrier réel de la migration

Deux semaines, pour huit développeurs, réparties ainsi :

1. Première semaine : un développeur pilote configure et teste `.ddev/config.yaml` sur un projet représentatif, avec import de la base et des médias existants ;
2. Milieu de semaine deux : configuration généralisée aux projets restants, avec un script d'import commun pour la base de données ;
3. Fin de semaine deux : désinstallation progressive de Local, poste par poste, une fois chaque développeur confirmé opérationnel sous DDEV sur tous ses projets actifs.

> L'essentiel à retenir : La configuration versionnée a éliminé les divergences entre postes ; Le passage a pris deux semaines pour huit développeurs ; Les habitudes graphiques de Local ont le plus manqué au début

## Ce qui a le plus manqué : l'interface graphique

Local propose une interface graphique complète — démarrage des sites, gestion des versions de PHP, ouverture directe d'un terminal ou d'un éditeur de code — accessible sans taper une seule commande. DDEV fonctionne entièrement en ligne de commande, ce qui a représenté une vraie marche à franchir pour les profils les moins à l'aise avec le terminal.

```
ddev start
ddev ssh
ddev import-db --file=backup.sql.gz
ddev launch
```

La formation interne s'est concentrée sur une dizaine de commandes de base, documentées dans un mémo d'une page, ce qui a suffi à rendre l'équipe autonome en quelques jours. Le confort perdu de l'interface graphique a été largement compensé par la garantie de configuration identique entre postes.

## Un piège rencontré : les hooks post-démarrage

DDEV permet de déclarer des hooks exécutés automatiquement après certaines actions, comme l'import de base de données — utile pour lancer un `search-replace` automatique des URL. Le premier essai a oublié de rendre ce hook idempotent, ce qui provoquait une double réécriture des URL sur un import répété :

```
# .ddev/config.yaml
hooks:
  post-import-db:
    - exec: wp search-replace "https://exemple.test" "https://site-client-restaurant.ddev.site" --all-tables
```

Comme `wp search-replace` remplace toute occurrence trouvée, relancer l'import une seconde fois sans réinitialiser la base au préalable ne posait pas de problème réel, mais l'équipe a mis quelques jours à comprendre pourquoi certaines URL apparaissaient temporairement incohérentes après un import partiel interrompu. La leçon retenue : toujours documenter clairement ce qu'un hook fait, pour qu'un développeur qui l'interrompt en cours sache dans quel état la base se trouve.

## Les gains mesurés après la transition

- Zéro incident de version de PHP divergente entre développeurs depuis la migration ;
- Le temps d'intégration d'un nouveau développeur sur un projet existant est passé de la journée (installation manuelle de Local, configuration de la version de PHP, import de base) à moins d'une heure (clonage du dépôt, `ddev start`, import de base) ;
- La configuration versionnée sert aussi de documentation vivante : consulter `.ddev/config.yaml` suffit à savoir quelle version de PHP et de MariaDB un projet attend, sans poser la question à un collègue.

> Le vrai gain n'était pas la vitesse de démarrage des conteneurs, à peu près comparable entre les deux outils sur nos machines. C'est la disparition complète des « ça marche chez moi » qui a justifié les deux semaines de transition.

## En résumé

Changer d'environnement local pour toute une équipe a un coût réel en formation et en habitudes à réapprendre, en particulier pour les profils habitués à une interface graphique. Sur cette équipe précise, le gain de configuration versionnée et partagée a rapidement dépassé ce coût initial, et aucun développeur n'a exprimé le souhait de revenir à la situation précédente une fois la transition terminée.