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
└── .envLe 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.
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.
