# Bedrock et Trellis pour structurer un projet WordPress d’agence : notre retour

> Adoptés sur plusieurs projets, Bedrock et Trellis changent la façon d'organiser un dépôt et de déployer un site. Ce que cela apporte vraiment, et ce que cela n'apporte pas.

- Auteur : WordPress Développement
- Publié le : 2021-10-25
- Mis à jour le : 2021-10-25
- Catégorie : Extensions
- URL : https://www.wpmoderne.fr/extensions/bedrock-trellis-structurer-projet-wordpress-agence/

## L’essentiel

- Bedrock déplace le cœur WordPress hors du contrôle de version
- wp-config.php devient un fichier .env classique
- Trellis structure le provisionnement plutôt que le simple déploiement

Face à une installation WordPress classique, où le cœur, les extensions et le thème cohabitent dans une même arborescence versionnée sans distinction claire, Bedrock propose une organisation radicalement différente, héritée des habitudes de développement PHP plus larges : séparer ce qui appartient au projet de ce qui appartient à des dépendances gérées par Composer.

Après plusieurs projets d'agence menés avec cette structure, associée à Trellis pour le provisionnement des serveurs, certains apports se confirment clairement, tandis que d'autres promesses méritent d'être nuancées selon la taille de l'équipe et la nature des clients accompagnés.

## Ce que change Bedrock dans l'arborescence

```
projet/
├── config/
│   ├── application.php
│   └── environments/
│       ├── development.php
│       └── production.php
├── web/
│   ├── app/
│   │   ├── plugins/
│   │   ├── themes/
│   │   └── uploads/
│   └── wp/          (cœur WordPress, géré par Composer)
├── composer.json
└── .env
```

Le cœur WordPress se retrouve dans `web/wp`, installé via Composer plutôt que téléchargé manuellement, et surtout absent du dépôt versionné grâce à un `.gitignore` adapté. Seul ce qui appartient réellement au projet - thème, extensions maison, configuration - reste suivi par Git.

## Un .env plutôt qu'un wp-config.php dispersé

Les identifiants de base de données, les clés de sécurité et les constantes d'environnement migrent vers un fichier `.env`, chargé via la bibliothèque `vlucas/phpdotenv` que Bedrock intègre par défaut :

```
DB_NAME='projet_client'
DB_USER='projet_client'
DB_PASSWORD='motdepasse'
WP_ENV='production'
WP_HOME='https://www.client.fr'
WP_SITEURL="${WP_HOME}/wp"
```

Ce fichier n'entre jamais dans le contrôle de version, ce qui réduit le risque de fuite d'identifiants dans l'historique Git, un incident classique sur les installations traditionnelles où `wp-config.php` finit parfois commité par erreur en début de projet.

> L'essentiel à retenir : Bedrock déplace le cœur WordPress hors du contrôle de version ; wp-config.php devient un fichier .env classique ; Trellis structure le provisionnement plutôt que le simple déploiement

## Trellis : le provisionnement plutôt que le simple déploiement

Là où Bedrock structure le code, Trellis s'attaque à la couche serveur, via des rôles Ansible qui installent et configurent Nginx, PHP-FPM, MariaDB et les outils associés de façon reproductible. Un même jeu de rôles provisionne aussi bien un environnement de développement local via Vagrant qu'un serveur de production distant.

### Ce que cela apporte concrètement

- Une configuration serveur versionnée et documentée, plutôt que des réglages appliqués manuellement et oubliés
- Un environnement de développement qui reproduit fidèlement la production, réduisant les surprises au déploiement
- Un déploiement scripté qui limite les étapes manuelles source d'erreurs humaines

### Ce que cela n'apporte pas automatiquement

- Une courbe d'apprentissage réelle pour une équipe habituée à un hébergement mutualisé classique
- Une compatibilité immédiate avec certains hébergeurs qui imposent leur propre structure de dossiers
- Un allègement de la maintenance : Ansible et les rôles Trellis demandent eux-mêmes une veille technique

## Où cette organisation atteint ses limites

Sur un projet ponctuel confié à un client qui reprendra la maintenance seul avec des compétences limitées, cette structure ajoute une complexité difficile à transmettre : un hébergeur mutualisé classique ne sait pas exécuter `composer install` ni interpréter la structure de dossiers de Bedrock sans adaptation.

| Contexte projet | Bedrock + Trellis pertinent |
| --- | --- |
| Agence avec plusieurs projets similaires | Oui |
| Équipe habituée à Composer et Ansible | Oui |
| Client reprenant seul la maintenance | À évaluer au cas par cas |
| Hébergement mutualisé imposé | Non recommandé sans adaptation |

> Notre conseil interne : adopter cette structure quand elle sert plusieurs projets similaires dans la durée, pas pour un site isolé où la charge d'apprentissage dépasserait le bénéfice.

## Notre verdict

Bedrock et Trellis tiennent leurs promesses sur la structuration du code et la reproductibilité du provisionnement, à condition que l'équipe qui les adopte investisse le temps nécessaire pour maîtriser Composer et Ansible. Cette approche reste un choix d'agence assumé, pas une recette universelle à appliquer sans discernement à tout projet WordPress, quel que soit son contexte de maintenance future.