# Bedrock (WordPress)

> Bedrock : boilerplate WordPress moderne développé par Roots qui réorganise l'arborescence du projet, gère les dépendances via Composer et sépare strictement le code du contenu — base favorite pour déployer WordPress comme une application PHP professionnelle.

- **Catégorie** : Technique
- **URL** : https://www.romaindelfosse.fr/glossary/bedrock/

---

**Bedrock** est un boilerplate WordPress développé et maintenu par **Roots**, un collectif américain spécialisé dans l'outillage moderne pour WordPress. Sa proposition est simple et radicale : plutôt que d'accepter la structure historique de WordPress — qui mélange le core, les plugins, les uploads et la configuration à la racine du projet — Bedrock réorganise tout pour que WordPress soit gérable comme une application PHP professionnelle, avec Composer, des variables d'environnement et une séparation stricte entre le code et le contenu.

## Définition technique

### La structure Bedrock

Un projet Bedrock ressemble à ceci :

```
project/
├── composer.json          # Dépendances : core WordPress + plugins + thèmes
├── composer.lock          # Versions figées
├── config/
│   ├── application.php    # Configuration globale
│   └── environments/
│       ├── development.php
│       ├── staging.php
│       └── production.php
├── .env.example           # Variables d'environnement attendues
└── web/
    ├── app/               # Remplace wp-content
    │   ├── plugins/
    │   ├── themes/
    │   ├── mu-plugins/
    │   └── uploads/       # Monté en volume sur PaaS
    ├── wp/                # Core WordPress (géré par Composer)
    ├── wp-config.php      # Charge la config depuis config/
    └── index.php
```

La racine du projet n'expose pas le core WordPress — c'est `web/` qui est le document root servi par le serveur web. Cette structure évite toute une classe de fuites d'information liées à l'accès direct à `/wp-config.php`, `/readme.html`, ou `/license.txt`.

### Composer comme gestionnaire de paquets

Le changement le plus fondamental de Bedrock, c'est que **tout est une dépendance Composer** : le core WordPress, chaque plugin (via le proxy WPackagist qui expose le répertoire WordPress.org comme des paquets Composer), et chaque thème. Installer un plugin, c'est éditer `composer.json` et relancer `composer install` — pas cliquer dans un dashboard. Mettre à jour WordPress, c'est `composer update roots/wordpress` — avec un `composer.lock` qui garantit la reproductibilité exacte entre environnements.

Cette approche débloque aussi l'audit de dépendances : `composer audit --locked` vérifie chaque paquet contre la base de données des CVE publiques. Sur un WordPress classique, aucun outil équivalent ne couvre les plugins installés via le dashboard.

## Enjeux actuels

### Les limites de l'approche

Bedrock n'est pas la solution universelle à WordPress. Il impose une discipline de développement que toutes les équipes n'ont pas : on ne peut plus installer un plugin en un clic, le workflow passe par Git et Composer, les développeurs doivent maîtriser l'environnement de ligne de commande. Pour une équipe éditoriale qui veut juste ajouter un plugin Yoast, c'est une friction réelle. Bedrock s'adresse aux équipes techniques qui veulent traiter WordPress comme un projet de développement sérieux, pas aux équipes qui veulent garder l'agilité du dashboard.

Par ailleurs, Bedrock ne modifie pas WordPress à l'exécution : c'est toujours le même moteur, avec les mêmes bugs, les mêmes vulnérabilités potentielles, la même dépendance à l'écosystème des plugins. Bedrock améliore l'ingénierie *autour* de WordPress, pas WordPress lui-même.

## Applications pratiques

Sur un PaaS comme Upsun, Fly.io ou Platform.sh, Bedrock est quasiment la structure par défaut : sans Composer, sans séparation code/contenu, sans variables d'environnement, le déploiement reproductible n'est pas réalisable. J'utilise Bedrock dans [mon expérimentation de sécurisation de WordPress via Infrastructure as Code](/blog/securiser-wordpress-sans-plugins-infrastructure-as-code/), qui s'appuie sur cette structure pour découpler la configuration de sécurité du code applicatif.



## Questions fréquentes

### Quelle est la différence entre un WordPress classique et un WordPress Bedrock ?

Un WordPress classique mélange tout à la racine du projet : le core WordPress, les plugins, les thèmes, les uploads, la configuration. C'est pratique à installer mais difficile à versionner — qu'est-ce qu'on met dans Git ? Uniquement les plugins custom ? Tout ? Rien ? Bedrock règle le problème en réorganisant : le core WordPress vit dans web/wp/, les plugins et thèmes dans web/app/, les uploads sont isolés, la configuration est décomposée en fichiers PHP par environnement (development, staging, production), et toutes les dépendances — y compris le core et les plugins — sont gérées via Composer.

### Bedrock est-il compatible avec tous les plugins WordPress ?

Oui, à 99%. Bedrock reste un WordPress standard à l'exécution : les plugins et thèmes du répertoire WordPress.org fonctionnent sans modification. Le seul point de vigilance concerne les plugins qui écrivent en dur dans leur propre répertoire (certains plugins de cache ou de sécurité) — sur un filesystem immuable, ces écritures échouent, et il faut soit reconfigurer le plugin, soit monter un volume spécifique.

### Pourquoi Bedrock est-il populaire dans les stacks PaaS ?

Parce qu'il traite WordPress comme une application PHP normale : avec un composer.lock, des variables d'environnement, une séparation claire entre code et contenu, et un wp-config.php qui lit la configuration depuis getenv() plutôt que des constantes en dur. Cette structure est exactement ce qu'attend un PaaS moderne (Upsun, Fly.io, Platform.sh) : build reproductible, déploiement via Git, pas d'écriture sur le filesystem applicatif en runtime.



## Ressources

- [Bedrock — Documentation officielle](https://roots.io/bedrock/?utm_source=romaindelfosse&utm_medium=glossaire&utm_campaign=bedrock) — Roots

- [Bedrock — Repository GitHub](https://github.com/roots/bedrock?utm_source=romaindelfosse&utm_medium=glossaire&utm_campaign=bedrock) — Roots

- [WordPress Packagist — Dépôt Composer pour plugins WordPress](https://wpackagist.org/?utm_source=romaindelfosse&utm_medium=glossaire&utm_campaign=bedrock) — WP Packagist