Pourquoi développer son site WordPress avec Docker ?

Pendant des années, monter un site WordPress en local voulait dire lancer WAMP, croiser les doigts et bricoler une config Apache. Pour nos nouveaux projets, on a rangé WAMP au placard. Aujourd’hui, chaque site qu’on développe tourne dans Docker, avec un environnement identique pour toute l’équipe et reproductible à la commande près.

Ce changement n’est pas un caprice de développeur. Au contraire, il répond à un problème très concret. Un site marche parfaitement sur le poste d’un développeur, puis il casse à la mise en ligne. Résultat : du temps, de l’argent et des nerfs en moins. Docker supprime une bonne partie de ces mauvaises surprises. Voici donc pourquoi il change la donne, ce qu’il apporte face à WAMP, et à quoi ressemble une configuration concrète pour un projet Bedrock et Sage.

 Ce qui nous a fait ranger WAMP

Les outils classiques d’environnement local (WAMP, MAMP, XAMPP) ont longtemps rendu service. Cependant, sur des projets WordPress modernes, à plusieurs développeurs, ils montrent vite leurs limites.

• Une seule version de PHP pour tous vos projets. Un site demande PHP 8.1, un autre PHP 8.3 ? Avec WAMP, vous jonglez ou vous cassez quelque chose. Chaque changement de version est une corvée.
• Le fameux « ça marche chez moi ». La config d’un poste n’est jamais tout à fait celle d’un autre, ni celle du serveur final. Résultat : des bugs qui apparaissent uniquement à la mise en ligne, un grand classique des erreurs de conception de sites web.
• Une installation à refaire à la main. Nouveau développeur dans l’équipe, nouvel ordinateur, et c’est reparti pour des heures de configuration avant d’écrire la première ligne de code.
• Rien de reproductible. La configuration vit dans des fichiers éparpillés sur la machine, pas dans le projet. Impossible de la partager proprement.

Sur une stack exigeante comme Bedrock + Sage, ces limites deviennent vite bloquantes. En effet, cette stack sépare la configuration du code, gère les extensions via Composer et compile le thème avec un bundler.

Docker, en deux mots et sans jargon

Un conteneur Docker, c’est une boîte. Elle embarque tout ce dont votre site a besoin : la bonne version de PHP, le serveur web, la base de données, les bons réglages. Surtout, cette boîte se comporte exactement pareil sur n’importe quelle machine.

Toute la recette tient dans un seul fichier, le docker-compose.yml, versionné avec le projet. Concrètement, un développeur récupère le code, puis lance une commande. Il obtient alors le même environnement que tous les autres, sans rien installer d’autre sur son poste. C’est finalement le même principe de rigueur que le contrôle de version avec Git, appliqué cette fois à l’environnement de travail lui-même.

À quoi ressemble une stack Docker pour Bedrock et Sage

Concrètement, un projet WordPress moderne a besoin de quelques briques qui tournent ensemble. On les décrit une fois, dans le docker-compose.yml.

Voici un exemple simplifié du fichier

# Exemple illustratif 
services:
  php:
    build: .                  # image PHP 8.2 + Apache, racine sur web/
    volumes:
      - .:/var/www
    working_dir: /var/www/web
    depends_on:
      - db

  db:
    image: mariadb:10.6
    environment:
      MYSQL_DATABASE: ${DB_NAME}
      MYSQL_USER: ${DB_USER}
      MYSQL_PASSWORD: ${DB_PASSWORD}
    volumes:
      - db_data:/var/lib/mysql

  phpmyadmin:
    image: phpmyadmin/phpmyadmin
    environment:
      PMA_HOST: db
    depends_on:
      - db

volumes:
  db_data:

Trois services suffisent à tout faire tourner. Le service php part d’une image PHP 8.2 + Apache. On l’étend avec ce dont le projet a besoin : les extensions pour dialoguer avec la base, la réécriture d’URL pour les permaliens WordPress, et la racine d’Apache déplacée sur web/. Le service db fait tourner MariaDB. Le service phpmyadmin ajoute une interface web pour explorer la base sans logiciel tiers. Les identifiants de base de données restent dans un fichier .env, jamais versionné. Le docker-compose.yml devient donc un modèle réutilisable d’un projet à l’autre.

Deux pièges classiques attendent sur Bedrock. Le premier concerne le serveur web. Il doit pointer sur web/, pas sur la racine du projet. On le règle une fois pour toutes dans l’image. Sans ça, le site renvoie une page blanche. Le second se joue dans le fichier .env. L’adresse de la base de données n’est plus localhost, mais le nom du service Docker, soit DB_HOST='db'. Une fois ces deux points réglés, le quotidien tient en quelques commandes. docker compose up pour démarrer. composer install pour les extensions PHP. yarn pour compiler le thème Sage.

Le vrai gain : un développeur opérationnel en une commande

C’est là que le bénéfice devient évident. Quand un développeur rejoint un projet, il clone le dépôt, lance docker compose up, et il travaille dans le même environnement que tout le monde, en quelques minutes au lieu d’une demi-journée de configuration.

• Une version de PHP par projet, sans conflit entre les sites.
• Le même environnement pour toute l’équipe, du premier au dernier développeur.
• Un environnement proche de la production, donc beaucoup moins de surprises au lancement et de meilleures bases pour la performance du site.
• Rien qui traîne sur le poste : on supprime le conteneur, il ne reste rien.

Côté confort, on conseille de remplacer l’outil officiel Docker Desktop par une alternative plus légère et plus rapide comme Orbstack, qui gère en bonus les adresses locales en HTTPS automatiquement. Le démarrage est quasi instantané, ce qui change le quotidien.

Docker ne fait pas tout, soyons honnêtes

Docker n’est pas une baguette magique. Il y a une courbe d’apprentissage réelle au départ, et il faut prendre le temps de bien construire son image PHP la première fois. Ce n’est pas non plus un sujet d’hébergement : un bon environnement local ne remplace pas un serveur de production correctement configuré et sécurisé. C’est d’ailleurs la même logique qui guide notre approche de la cybersécurité, la rigueur en amont évite les mauvaises surprises en aval.

Pour nous, ce n’est pas un argument à mettre en avant auprès d’un client, c’est une discipline d’atelier. Mais cette discipline a un effet direct sur ce que vous recevez : des sites plus fiables, livrés avec moins d’allers-retours, et une équipe qui passe son temps à créer plutôt qu’à réparer des problèmes d’environnement.

Ce que ça change pour vos projets

Le passage de WAMP à Docker, c’est invisible pour vous, mais c’est exactement le genre de détail qui sépare un site qui tient la route d’un site qui multiplie les bugs au lancement. En travaillant sur des environnements identiques, reproductibles et proches de la production, on réduit les imprévus et on tient mieux les délais.

C’est la même logique d’exigence qu’on applique à l’ensemble de nos projets, du premier échange à la mise en ligne. Si vous avez un projet de création ou de refonte de site internet, parlons-en : nos équipes à Reims, Troyes, Ajaccio et Genève sont là pour en discuter avec vous.