Bedrock est un squelette de projet développé par Roots qui réorganise la structure d’un site WordPress pour le rendre plus sécurisé, plus maintenable et plus professionnel. Ce n’est pas un autre CMS : c’est le même WordPress, mais rangé autrement.
Dans une installation WordPress classique, tous les fichiers – le moteur, les thèmes, les plugins, la configuration – cohabitent dans le même dossier, accessible depuis le navigateur. Bedrock sépare ces éléments : le code spécifique au projet d’un côté, le moteur WordPress de l’autre, et les fichiers sensibles hors de portée du serveur web. C’est exactement la même logique qu’un projet Laravel, où le framework et le code métier ne se mélangent jamais.
Pour le client, rien ne change au quotidien : l’interface d’administration reste identique. Mais en coulisses, l’architecture est nettement plus robuste face aux attaques et aux erreurs de manipulation.
Une installation WordPress standard place l’intégralité des fichiers dans un seul dossier exposé au serveur web. Le fichier wp-config.php, qui contient les identifiants de base de données et les clés de sécurité, est accessible au même niveau que les pages publiques. Les scripts malveillants connaissent cette structure par cœur : ils savent exactement où chercher pour exploiter une faille.
Bedrock inverse cette logique. Le dossier public (web/) ne contient que le strict minimum nécessaire à l’affichage du site. Le fichier de configuration, les dépendances et le cœur de WordPress sont placés au-dessus de la racine web, dans des dossiers inaccessibles depuis un navigateur. Les plugins et le thème sont isolés dans un répertoire dédié (app/), géré indépendamment du moteur. La configuration passe par un fichier .env – un standard du développement moderne qui permet de séparer les réglages selon l’environnement (développement, test, production) sans toucher au code. Résultat : même si un attaquant accède au serveur web, les fichiers critiques ne sont tout simplement pas là où il les attend.
Sites professionnels exposés aux attaques – WordPress propulse plus de 40 % du web, ce qui en fait la cible privilégiée des robots malveillants. Un site vitrine, un site e-commerce ou un espace client contient des données sensibles. Bedrock réduit drastiquement la surface d’attaque en rendant les fichiers critiques invisibles depuis l’extérieur. Ce n’est pas un pare-feu : c’est une architecture qui rend les attaques classiques inopérantes.
Agences qui gèrent un parc de sites – quand une agence maintient des dizaines de sites WordPress, la standardisation de l’architecture devient indispensable. Bedrock impose une structure identique à chaque projet : mêmes conventions, même organisation, même workflow de déploiement. Chez MozArtsduWeb, nous utilisons Bedrock sur nos projets WordPress pour garantir un niveau de sécurité et de maintenabilité constant.
Projets qui évoluent dans la durée – grâce à Composer, chaque plugin et chaque dépendance sont verrouillés à une version précise. Les mises à jour sont testées en environnement de développement avant d’être appliquées en production. Fini les mises à jour surprises qui cassent le site un vendredi soir.
Équipes de développeurs – le dépôt Git ne contient que le code spécifique au projet, pas les milliers de fichiers du moteur WordPress. Le travail collaboratif est propre, les conflits de version sont rares, et chaque modification est traçable.
Intégrer Bedrock dès le départ – c’est un choix d’architecture qui se fait au lancement du projet, pas une migration après coup. Convertir un site WordPress existant vers Bedrock est possible mais demande un travail de réorganisation significatif. Le meilleur moment pour en bénéficier, c’est la création du site.
Choisir un hébergement adapté – Bedrock nécessite un serveur avec un accès SSH et le support de Composer. Un hébergement mutualisé basique ne convient pas. C’est un point à vérifier avec votre prestataire – et c’est aussi la raison pour laquelle une offre d’hébergement professionnel adaptée fait partie intégrante de la solution.
Ne pas toucher au moteur – tout l’intérêt de Bedrock repose sur la séparation stricte entre le code métier et le cœur de WordPress. Modifier des fichiers du moteur revient à casser cette isolation. Les personnalisations passent par le thème et les plugins, jamais par le core.
Confier la maintenance à un prestataire formé – Bedrock est transparent pour le client au quotidien, mais sa gestion technique demande des compétences spécifiques. Les mises à jour passent par Composer et la ligne de commande, pas par le bouton « Mettre à jour » du tableau de bord. C’est un gage de fiabilité, à condition que le prestataire maîtrise l’outil.
Bedrock n’est pas un pare-feu – il sécurise l’architecture, pas le trafic. Il ne remplace pas un certificat SSL, une politique de mots de passe solide ou une stratégie de sécurité globale. C’est une couche de protection structurelle qui s’ajoute aux autres, pas qui les remplace.
Certains plugins posent problème – des plugins qui codent des chemins en dur (par exemple vers wp-content/) peuvent ne pas fonctionner correctement avec Bedrock, qui renomme ce dossier en app/. La grande majorité des plugins sont compatibles, mais c’est un point à vérifier lors de la sélection des extensions.
La dépendance au prestataire – un site sous Bedrock ne se gère pas comme un WordPress classique. Si vous changez de prestataire, le suivant doit connaître cette architecture. C’est un argument pour choisir dès le départ un partenaire solide et s’inscrire dans une relation de long terme.
Pas adapté à tous les contextes – pour un blog personnel ou un site géré directement par un non-technicien sans prestataire, Bedrock ajoute une complexité inutile. Sa valeur se révèle pleinement sur des projets professionnels maintenus par une équipe technique.
