WordPress est souvent apprécié pour sa simplicité d’installation. Quelques fichiers déposés sur un serveur, une base de données configurée et le site peut commencer à prendre forme.
Cette simplicité possède toutefois une contrepartie. À mesure qu’un projet grandit, sa configuration peut devenir difficile à maintenir. Les dépendances sont parfois installées manuellement, les environnements ne sont plus identiques et certaines informations sensibles peuvent se retrouver dans les fichiers du projet.
C’est précisément à ces problématiques que répond Bedrock, une architecture WordPress proposée par l’écosystème Roots.
Bedrock ne remplace pas WordPress. Il modifie la manière dont un projet WordPress est organisé, configuré et déployé. Son objectif est de rapprocher WordPress des standards utilisés dans les applications web modernes.
Mais cette approche est-elle adaptée à tous les projets ? Quels bénéfices apporte-t-elle réellement ? Et quelles contraintes faut-il anticiper avant de l’adopter ?
Qu’est-ce que WordPress Bedrock ?
Bedrock est un socle de projet, aussi appelé boilerplate, permettant de structurer une installation WordPress de manière plus professionnelle.
Dans une installation classique, le cœur de WordPress, les extensions, les thèmes, les fichiers de configuration et les contenus envoyés par les utilisateurs se trouvent généralement dans une même arborescence.
Bedrock propose une organisation différente. Il sépare plus clairement le cœur de WordPress, le code propre au projet, les dépendances externes, les fichiers publics et les paramètres liés à chaque environnement.
Cette organisation facilite le travail en équipe, le versionnement du code et l’automatisation des déploiements.
Bedrock s’appuie notamment sur Composer, un gestionnaire de dépendances largement utilisé dans l’écosystème PHP. WordPress, les extensions et certains composants peuvent ainsi être déclarés dans un fichier de configuration, puis installés de manière reproductible.
Comment fonctionne une installation Bedrock ?
Un projet Bedrock conserve le fonctionnement général de WordPress. L’interface d’administration, les thèmes, les extensions et la base de données restent familiers.
La différence se situe principalement dans la structure technique du projet.
Une racine web mieux isolée
Avec Bedrock, le dossier accessible publiquement par le serveur web est généralement limité au répertoire web.
Les fichiers de configuration, les dépendances et d’autres éléments techniques sont placés en dehors de cette racine publique.
Cette séparation réduit l’exposition de fichiers qui n’ont pas besoin d’être accessibles depuis un navigateur.
Une configuration basée sur l’environnement
Bedrock utilise un fichier d’environnement pour stocker les informations qui varient selon le contexte d’exécution.
Il peut notamment contenir :
- Les accès à la base de données
- L’URL du site
- L’environnement actif
- Les clés de sécurité
- Certains paramètres propres au serveur
Le même code peut ainsi être utilisé en local, en préproduction et en production sans modifier manuellement plusieurs fichiers de configuration.
Les informations sensibles ne doivent bien entendu jamais être ajoutées au dépôt Git.
Des dépendances gérées avec Composer
Composer permet de déclarer les versions utilisées par le projet.
Au lieu d’installer une extension manuellement sur chaque environnement, l’équipe peut l’ajouter aux dépendances du projet. Composer se charge ensuite d’installer la version prévue.
Cette approche améliore la cohérence entre les postes de développement et les serveurs.
Les principaux avantages de WordPress Bedrock
1. Une architecture plus claire
Le premier avantage de Bedrock est la lisibilité du projet.
Le cœur de WordPress n’est plus mélangé avec le code réellement développé pour le site. Les thèmes personnalisés, les extensions spécifiques et les fichiers de configuration sont plus faciles à identifier.
Cette séparation est particulièrement utile lorsqu’un projet doit être repris par une autre équipe ou maintenu pendant plusieurs années.
Elle limite également les modifications directes du cœur de WordPress, une pratique risquée qui complique les mises à jour.
2. Une meilleure gestion des environnements
Un site professionnel passe rarement directement du poste d’un développeur à la production.
Il existe généralement plusieurs environnements :
- Développement local
- Intégration
- Préproduction
- Production
Chacun peut utiliser une URL, une base de données, des identifiants et des réglages différents.
Bedrock facilite cette séparation grâce aux variables d’environnement. Le code reste commun tandis que les paramètres propres à chaque serveur sont configurés séparément.
Cela réduit les erreurs liées aux changements manuels avant une mise en production.
3. Des installations reproductibles
Avec Composer et un fichier de verrouillage des versions, chaque membre de l’équipe peut installer les mêmes dépendances.
Cette reproductibilité est essentielle dans un processus de développement fiable.
Sans gestionnaire de dépendances, deux environnements peuvent utiliser des versions différentes d’une même extension. Une fonctionnalité peut alors fonctionner en local, mais provoquer une erreur en production.
Bedrock limite ce type d’écart en rendant les dépendances explicites.
4. Une meilleure intégration avec Git
Dans un projet Bedrock, le dépôt Git peut se concentrer sur les éléments réellement utiles comme le thème sur mesure, les extensions spécifiques, les fichiers de configuration, la liste des dépendances et les scripts de déploiement.
Le cœur de WordPress et les extensions tierces n’ont pas besoin d’être stockés directement dans le dépôt lorsqu’ils sont installés par Composer.
Le projet devient ainsi plus léger, plus lisible et plus simple à auditer.
5. Des déploiements plus fiables
Bedrock se prête bien aux déploiements automatisés.
Une procédure peut récupérer la version validée du code, installer les dépendances, compiler les ressources du thème et publier la nouvelle version.
Cette méthode réduit la dépendance aux transferts manuels par FTP et améliore la traçabilité des mises en production.
En cas de problème, il devient aussi plus simple d’identifier la version déployée ou de revenir à une version précédente.
6. Une base adaptée au travail en équipe
Sur un petit site géré par une seule personne, une architecture classique peut suffire.
En revanche, lorsqu’un projet implique plusieurs développeurs, un intégrateur, une agence, un hébergeur et une équipe interne, la standardisation devient beaucoup plus importante.
Bedrock fournit un cadre commun. Chaque intervenant comprend plus rapidement où se trouvent les fichiers, comment installer le projet et comment gérer la configuration.
7. Une sécurité structurelle améliorée
Bedrock ne rend pas automatiquement un site WordPress invulnérable. La sécurité dépend toujours de la qualité du code, des mises à jour, de l’hébergement, des droits d’accès, des sauvegardes et de la surveillance.
Son architecture apporte néanmoins plusieurs bonnes pratiques :
- Une séparation entre les fichiers publics et les fichiers techniques
- Le stockage des secrets dans des variables d’environnement
- Une gestion plus rigoureuse des versions
- Une réduction des modifications manuelles non tracées
Il s’agit donc d’une amélioration structurelle et non d’un remplacement des mesures de sécurité habituelles.
Les limites de WordPress Bedrock
Bedrock offre de nombreux avantages, mais son adoption ajoute aussi de la complexité.
1. Une courbe d’apprentissage plus importante
Un utilisateur habitué à une installation WordPress classique peut être désorienté.
L’arborescence change, les extensions peuvent être gérées avec Composer et certains réglages doivent être définis dans des fichiers d’environnement.
L’équipe doit donc maîtriser Composer, Git, les variables d’environnement, la ligne de commande et certaines notions liées à la configuration serveur.
Cette courbe d’apprentissage est acceptable pour une équipe technique, mais elle peut devenir un frein lorsque le projet est administré sans accompagnement spécialisé.
2. Des exigences particulières côté hébergement
Tous les hébergements mutualisés ne sont pas conçus pour accueillir facilement une architecture Bedrock.
Le serveur doit notamment permettre de définir correctement la racine publique, de gérer les variables d’environnement et d’utiliser une version compatible de PHP.
Il doit également être possible d’exécuter Composer ou de déployer les dépendances déjà installées.
Il est donc nécessaire de vérifier les possibilités offertes par l’hébergeur avant de choisir cette architecture.
3. Une compatibilité variable avec certains outils
Certains services, extensions ou outils d’hébergement supposent que WordPress utilise son arborescence traditionnelle.
Ils peuvent rechercher wp-config.php, wp-content ou le cœur de WordPress à des emplacements précis.
La majorité des extensions WordPress fonctionne normalement avec Bedrock, car le comportement général de WordPress reste identique. Toutefois, certains outils de sauvegarde, de sécurité, de déploiement ou de maintenance peuvent nécessiter une configuration spécifique.
4. Une gestion des extensions différente
Dans une installation traditionnelle, un administrateur peut installer une extension directement depuis l’interface WordPress.
Dans un projet Bedrock bien encadré, l’équipe peut décider que les extensions doivent être ajoutées via Composer, testées puis validées dans Git.
Cette pratique améliore la gouvernance technique, mais elle réduit l’autonomie immédiate des utilisateurs non techniques.
Il faut donc définir clairement qui peut installer une extension, comment elle doit être testée et de quelle manière elle sera déployée.
5. Une complexité parfois inutile
Bedrock n’est pas obligatoire pour créer un site WordPress de qualité.
Pour un site vitrine simple, sans développement spécifique, avec peu d’intervenants et un hébergement standard, l’architecture classique peut être plus rapide à mettre en place et plus facile à administrer.
Utiliser Bedrock uniquement parce qu’il paraît plus moderne peut conduire à une architecture inutilement complexe.
Le choix doit répondre à des besoins concrets et non à une préférence technique isolée.
Bedrock est-il plus performant qu’un WordPress classique ?
Bedrock n’améliore pas directement le temps de chargement des pages.
Les performances d’un site dépendent surtout de la qualité du thème, du poids des médias, des requêtes en base de données, de la stratégie de cache, du serveur et des extensions installées.
Bedrock peut toutefois améliorer indirectement les performances en facilitant une meilleure maîtrise du projet.
Une équipe peut contrôler plus précisément les versions, limiter les extensions inutiles, automatiser les tests et déployer des configurations cohérentes.
Bedrock constitue donc une meilleure fondation de développement, mais ce n’est pas un outil d’optimisation des performances à lui seul.
Bedrock est-il plus sécurisé ?
La réponse doit également être nuancée.
Bedrock apporte une organisation favorable à la sécurité, notamment grâce à la séparation de la racine publique et à l’utilisation de variables d’environnement.
Cependant, un site Bedrock mal maintenu peut rester vulnérable.
La sécurité exige toujours :
- Des mises à jour régulières
- Des sauvegardes testées
- Des accès protégés
- Des permissions correctement configurées
- Un hébergement fiable
- Une surveillance des erreurs et des activités suspectes
- Des extensions sélectionnées avec soin
Bedrock facilite une démarche professionnelle, mais ne remplace pas cette démarche.
Dans quels cas choisir WordPress Bedrock ?
Bedrock est particulièrement pertinent pour les projets qui utilisent Git, plusieurs environnements, des développements sur mesure ou des déploiements fréquents.
Il convient aussi aux équipes qui ont besoin d’une bonne traçabilité, d’une maintenance à long terme ou d’une intégration dans une chaîne CI/CD.
Cette architecture est souvent adaptée aux sites institutionnels complexes, aux plateformes éditoriales, aux sites de marque, aux projets multilingues importants et aux applications qui reposent fortement sur WordPress.
Dans quels cas conserver une installation classique ?
Une installation WordPress traditionnelle peut être préférable lorsque le projet est simple, que le budget technique est limité ou que le site repose essentiellement sur un thème et des extensions standards.
Elle peut aussi être plus adaptée lorsque les utilisateurs doivent installer eux-mêmes leurs extensions, que l’hébergement ne permet pas de configurer Bedrock correctement ou qu’aucune équipe technique n’est disponible pour assurer la maintenance.
La meilleure architecture n’est pas nécessairement la plus sophistiquée. C’est celle qui reste compréhensible, maintenable et proportionnée aux enjeux du projet.
WordPress classique ou Bedrock : tableau comparatif
| Critère | WordPress classique | WordPress Bedrock |
|---|---|---|
| Installation initiale | Rapide et accessible | Plus technique |
| Organisation des fichiers | Structure standard | Structure séparée et modernisée |
| Gestion des dépendances | Souvent manuelle | Composer |
| Gestion des environnements | Configuration à adapter | Variables d’environnement |
| Versionnement Git | Possible, mais parfois encombrant | Plus naturel |
| Déploiement automatisé | Possible avec adaptation | Bien adapté |
| Compatibilité avec les hébergements | Très large | À vérifier |
| Prise en main non technique | Plus simple | Plus exigeante |
| Travail en équipe | Correct | Particulièrement adapté |
| Maintenance de projets complexes | Peut devenir difficile | Plus structurée |
Notre avis chez LRCrea
Chez LRCrea, nous considérons Bedrock comme un choix d’architecture et non comme une solution à appliquer systématiquement.
Son intérêt apparaît surtout lorsqu’un projet WordPress doit être maintenu, déployé et fait évoluer avec la rigueur attendue d’une application web professionnelle.
Pour les projets complexes, Bedrock apporte une base plus propre, plus cohérente et plus facile à industrialiser. Il améliore la collaboration entre les intervenants et réduit les écarts entre les environnements.
Pour les projets plus simples, une installation classique correctement configurée peut rester le meilleur choix.
Notre rôle consiste donc à évaluer les contraintes réelles du projet avant de recommander une architecture. Nous prenons notamment en compte les objectifs métier, l’hébergement, le budget, les compétences internes, la fréquence des mises à jour et la durée de vie prévue du site.
Conclusion
WordPress Bedrock modernise la structure d’un projet WordPress en introduisant une gestion plus rigoureuse de la configuration, des dépendances et des déploiements.
Ses principaux avantages sont la clarté de l’architecture, la reproductibilité des installations, la gestion des environnements et la meilleure intégration avec les méthodes de développement modernes.
Ses limites résident surtout dans sa complexité, ses prérequis techniques et les contraintes qu’il peut imposer à certains hébergements ou utilisateurs.
Bedrock est donc particulièrement adapté aux projets WordPress professionnels, sur mesure ou maintenus par une équipe technique. Pour un site simple, son adoption doit être évaluée avec prudence afin d’éviter une complexité inutile.
Vous envisagez une refonte WordPress ou souhaitez fiabiliser l’architecture d’un projet existant ? LRCrea vous accompagne dans l’audit, le développement, la migration et la maintenance d’une installation WordPress adaptée à vos besoins.