Il y a deux ans, on a pris la décision de faire basculer nos nouveaux projets sur Bedrock, le squelette de projet WordPress maintenu par l’équipe de Roots. L’idée de départ était simple : arrêter de gérer WordPress comme un CMS à part et le traiter comme n’importe quel projet PHP moderne, avec Composer pour les dépendances et une structure de dossiers plus proche des standards de l’écosystème PHP.
Deux ans et une dizaine de projets plus tard, le bilan est largement positif, mais pas sans grincements. Voici ce qu’on a vraiment gagné, et ce qui continue de demander un effort d’adaptation à chaque nouvelle recrue.
Ce que Bedrock change concrètement
La structure de dossiers est la première différence visible. WordPress n’est plus à la racine du projet, mais dans un sous-dossier web/wp, entièrement géré par Composer : on ne le touche jamais à la main, on ne le versionne pas, une simple mise à jour du fichier composer.json suffit.
{
"require": {
"php": ">=7.1",
"composer/installers": "^1.9",
"roots/wordpress": "5.4.2",
"roots/wp-config": "1.0.0",
"roots/bedrock-autoloader": "1.0.4",
"vlucas/phpdotenv": "^3.6.6"
}
}Les plugins suivent la même logique, via le dépôt WPackagist qui miroite l’intégralité du répertoire officiel de WordPress.org sous forme de paquets Composer :
composer require wpackagist-plugin/advanced-custom-fields
composer require wpackagist-theme/twentytwentyLa fin de wp-config.php en dur
Bedrock remplace le classique wp-config.php rempli de constantes par un fichier .env non versionné, lu grâce à phpdotenv. Chaque environnement (local, staging, production) a son propre fichier, jamais commité :
DB_NAME=nom_de_la_base
DB_USER=utilisateur
DB_PASSWORD=mot_de_passe
WP_ENV=development
WP_HOME=http://site.local
WP_SITEURL=${WP_HOME}/wp
C’est un vrai confort : plus aucun risque de commiter un mot de passe de production par erreur, et le passage d’un environnement à l’autre se résume à changer de fichier .env. On perd en revanche l’habitude, très ancrée chez beaucoup de développeurs WordPress, de tout retrouver dans un seul fichier familier.
Ce qui reste pénible
La courbe d’apprentissage
Pour un développeur venu du WordPress « classique », Bedrock demande un vrai temps d’adaptation : comprendre Composer, accepter de ne plus toucher au dossier wp, apprendre à structurer un fichier .env par environnement. Sur les deux stagiaires qu’on a formés depuis, il a fallu compter une bonne semaine avant l’aisance complète.
Les plugins premium sans miroir Composer
Tous les plugins n’ont pas d’équivalent WPackagist, en particulier les extensions premium (ACF Pro, certains plugins de e-commerce). Il faut alors soit les déclarer via un dépôt privé dans composer.json, soit les gérer hors Composer — ce qui casse un peu la cohérence de l’approche.
{
"repositories": [
{
"type": "composer",
"url": "https://connect.advancedcustomfields.com"
}
]
}L’impact sur le déploiement
Le vrai bénéfice, au quotidien, se voit au déploiement. Plus besoin de synchroniser manuellement des dossiers de plugins : un composer install --no-dev --optimize-autoloader sur le serveur (ou en amont, dans un pipeline) reconstruit l’environnement exact décrit par composer.lock. C’est reproductible, versionné, et ça élimine la fameuse question « quelle version du plugin tourne réellement en prod ? ».
- Le fichier
composer.lockversionné garantit que tous les environnements utilisent exactement les mêmes versions - Un simple
composer installreconstruit l’intégralité de l’installation WordPress et des plugins - Les montées de version majeures de WordPress se testent d’abord en local via
composer update roots/wordpress
Sur un projet Bedrock, la question « pourquoi ce plugin est activé en prod mais pas en local » n’existe quasiment plus. C’est peut-être le gain le plus sous-estimé de cette approche.
Est-ce fait pour tous les projets ?
Honnêtement, non. Pour un site vitrine simple, sans équipe technique derrière pour le maintenir, la structure classique de WordPress reste plus accessible — n’importe quel hébergeur mutualisé la comprend nativement, et n’importe quel développeur WordPress peut reprendre le projet sans formation. Bedrock prend tout son sens sur des projets suivis dans la durée, avec une équipe technique stable et un besoin réel de reproductibilité entre environnements.
En résumé
Deux ans après notre bascule, on ne reviendrait pas en arrière sur nos projets d’agence suivis dans la durée. Bedrock impose une discipline qui paraît lourde au début, mais qui élimine une bonne partie des incidents de déploiement liés à des divergences entre environnements. Le vrai coût, ce n’est pas la technique, c’est la formation de l’équipe — à prévoir avant de se lancer, pas après.
