# Dockeriser WordPress : les pièges qu’on a tous fini par rencontrer

> Volumes qui se vident, permissions cassées, uploads perdus au redémarrage : Docker sous WordPress réserve son lot de surprises. Voici les nôtres, et comment les éviter.

- Auteur : Clément Hadrot
- Publié le : 2022-02-08
- Mis à jour le : 2022-02-08
- Catégorie : Outils & workflow
- URL : https://wpmoderne.dev.wordpress-developpement.fr/outils/dockeriser-wordpress-pieges-frequents/

## L’essentiel

- Les uploads doivent vivre dans un volume nommé, jamais dans le conteneur
- Les permissions de fichiers cassent souvent entre hôte et conteneur
- docker-compose ne remplace pas une vraie stratégie de sauvegarde

Docker promet un environnement identique entre développeurs, sans installation locale de PHP ou de MySQL. Sur le papier, c'est exactement ce qu'il faut pour une équipe qui travaille à plusieurs sur un même projet WordPress. Dans la pratique, on a mis plusieurs projets à essuyer les plâtres avant d'arriver à une configuration vraiment fiable. Voici les pièges qu'on a rencontrés, dans l'ordre où ils nous ont fait perdre du temps.

## Piège n°1 : des uploads perdus au redémarrage

La première erreur, classique, consiste à laisser `wp-content/uploads` dans le système de fichiers du conteneur plutôt que dans un volume Docker nommé. Un conteneur est éphémère par nature : le supprimer (volontairement ou par un `docker-compose down` mal maîtrisé) efface tout ce qui n'est pas explicitement monté en volume.

```
services:
  wordpress:
    image: wordpress:5.9-php8.0
    volumes:
      - ./wp-content:/var/www/html/wp-content
      - wp_uploads:/var/www/html/wp-content/uploads
    depends_on:
      - db

  db:
    image: mysql:5.7
    volumes:
      - db_data:/var/lib/mysql
    environment:
      MYSQL_ROOT_PASSWORD: root

volumes:
  wp_uploads:
  db_data:
```

Le point important ici : `db_data` et `wp_uploads` sont des volumes nommés Docker, pas de simples montages de dossiers locaux. Ils survivent à un `docker-compose down` classique et ne sont supprimés qu'explicitement, via `docker-compose down -v` — une commande qu'on bannit de nos habitudes courantes.

## Piège n°2 : les permissions de fichiers

> L'essentiel à retenir : Les uploads doivent vivre dans un volume nommé, jamais dans le conteneur ; Les permissions de fichiers cassent souvent entre hôte et conteneur ; docker-compose ne remplace pas une vraie stratégie de sauvegarde

Sur Linux en particulier, l'utilisateur à l'intérieur du conteneur (souvent `www-data`, UID 33) ne correspond pas forcément à l'utilisateur de l'hôte qui a créé les fichiers. Résultat : des fichiers créés depuis le conteneur appartiennent à un utilisateur que l'hôte ne reconnaît pas, rendant leur édition ou suppression laborieuse sans `sudo`.

```
# Diagnostic rapide du décalage de permissions
docker-compose exec wordpress id www-data
id $(whoami)

# Correction ponctuelle depuis l'hôte
sudo chown -R $(whoami):$(whoami) wp-content/
```

La solution durable consiste à aligner l'UID du conteneur sur celui de l'hôte au moment du build, via un argument de build dans le `Dockerfile`, plutôt que de corriger les permissions après coup à chaque incident.

## Piège n°3 : confondre volume Docker et sauvegarde

Un volume Docker nommé protège contre la suppression accidentelle d'un conteneur, pas contre la perte du serveur hôte, une erreur humaine (`docker volume rm`) ou une corruption disque. On a vu plus d'un développeur découvrir cette distinction le jour où elle comptait vraiment. Une vraie stratégie de sauvegarde — export régulier de la base, synchronisation des uploads vers un stockage externe — reste indispensable, indépendamment de Docker.

## Piège n°4 : la persistance MySQL entre versions

Changer la version de l'image `mysql` dans `docker-compose.yml` ne met pas à jour les données existantes dans le volume : MySQL peut refuser de démarrer si le format de données du volume est trop ancien pour la nouvelle version de l'image. On documente systématiquement la version de MySQL utilisée par un projet, et on évite de la changer sans une procédure de migration explicite.

| Symptôme | Cause probable |
| --- | --- |
| Le conteneur MySQL ne démarre plus après mise à jour | Incompatibilité de format entre l'ancien volume et la nouvelle version d'image |
| Impossible d'éditer un fichier depuis l'IDE | Décalage d'UID entre l'hôte et le conteneur |
| Les uploads disparaissent après un down | Absence de volume nommé pour wp-content/uploads |

## Ce qui fonctionne bien, malgré tout

- La reproductibilité entre postes de l'équipe : un `docker-compose up` suffit à obtenir un environnement identique, versions de PHP et MySQL comprises
- La possibilité de tester plusieurs versions de PHP en changeant une seule ligne d'image, sans rien installer sur la machine hôte
- L'intégration naturelle dans un pipeline CI/CD, qui peut utiliser exactement les mêmes images que le développement local

> Docker sous WordPress tient ses promesses, à condition de traiter les volumes avec la même rigueur qu'on traiterait une base de données de production. Le confort apparent de la conteneurisation ne dispense d'aucune des bonnes pratiques habituelles.

## En résumé

La majorité des mauvaises surprises avec Docker sous WordPress viennent d'une confusion entre ce qui est éphémère (le conteneur) et ce qui doit persister (les volumes nommés). Une fois cette distinction bien comprise, et les permissions correctement alignées entre hôte et conteneur, Docker devient un vrai gain de cohérence pour une équipe de développement — mais il ne remplace jamais une stratégie de sauvegarde digne de ce nom.