Bedrock WordPress : pourquoi adopter une architecture moderne pour vos projets

Crée le 1 avril 2026 par Mathieu Marteau - Développeur Web Freelance à Lille

Vous développez sur WordPress et votre workflow ressemble encore à un FTP + copier-coller de fichiers ? On est en 2026, il est temps d’en parler sérieusement 😅 Bedrock, c’est exactement ce qui m’a fait passer d’un développement WordPress un peu artisanal à quelque chose de vraiment professionnel — et croyez-moi, une fois qu’on y a goûté, impossible de revenir en arrière.

Ça fait maintenant plusieurs années que j’utilise Bedrock sur la quasi-totalité de mes projets WordPress. Et quand je vois encore des sites en production avec le wp-config.php à la racine, les identifiants de base de données en clair et un dossier wp-content qui ressemble à un champ de bataille… je me dis qu’il y a un vrai sujet à vulgariser 😬

Bedrock WordPress, c’est quoi exactement ? 🎯

Bedrock, c’est un boilerplate WordPress créé par l’équipe de Roots.io. En gros, c’est WordPress… mais repensé avec les bonnes pratiques du développement moderne. Là où une installation WordPress classique met tout en vrac à la racine (le core, vos thèmes, vos plugins, votre config), Bedrock impose une structure propre et organisée.

Concrètement, Bedrock apporte :

Composer pour gérer WordPress et tous vos plugins comme des dépendances PHP
Un fichier .env pour la configuration par environnement (fini le wp-config.php qu’on bidouille)
Une structure de dossiers logique qui sépare le core WordPress de votre code
Le web root isolé dans un sous-dossier — le reste de votre projet n’est pas accessible depuis le navigateur
Le support multi-environnement natif (dev, staging, production)

Si vous êtes développeur et que vous venez du monde Symfony, Laravel ou même Node.js, Bedrock va vous parler immédiatement. C’est WordPress qui se met enfin au niveau des frameworks modernes en termes de structure projet.

Le problème avec WordPress vanilla 🤦

Avant de parler des solutions, parlons du problème. J’ai récupéré des dizaines de sites WordPress « classiques » au fil de mes missions en tant que développeur freelance WordPress, et les mêmes galères reviennent systématiquement :

Pas de gestion de versions propre : le core WordPress, les plugins, les thèmes, les uploads — tout est dans le même repo Git (quand il y a un repo…). Résultat : des commits de 50 000 fichiers à chaque mise à jour de plugin.
Configuration en dur : les identifiants de BDD, les clés API, les URLs du site — tout est dans le wp-config.php. Bon courage pour faire tourner le même projet en local, en staging et en prod sans tout casser.
Sécurité approximative : le wp-config.php est à la racine du serveur web. Le dossier wp-content aussi. Tout est exposé.
Déploiement manuel : SFTP, écrasement de fichiers, prière pour que rien ne pète. On a tous connu ça 😰

C’est un peu comme construire une maison sans plan d’architecte : ça tient debout, mais dès qu’il faut agrandir ou rénover, c’est le chaos. Bedrock, c’est le plan d’architecte qui manquait à WordPress.

La structure Bedrock en détail 📁

Voici à quoi ressemble un projet Bedrock typique :

mon-projet/
├── config/
│   ├── application.php    # Config principale
│   └── environments/
│       ├── development.php
│       ├── staging.php
│       └── production.php
├── web/                   # Web root (seul dossier accessible)
│   ├── app/               # = wp-content
│   │   ├── plugins/
│   │   ├── themes/
│   │   ├── mu-plugins/
│   │   └── uploads/
│   ├── wp/                # WordPress core (via Composer)
│   └── index.php
├── vendor/                # Dépendances PHP
├── .env                   # Variables d'environnement
├── composer.json          # Déclaration des dépendances
└── composer.lock

Ce qui saute aux yeux immédiatement : WordPress n’est plus à la racine. Le core se trouve dans web/wp/, géré comme une simple dépendance Composer. Votre code custom (thèmes, plugins) est dans web/app/. Et toute la configuration est externalisée dans config/ + le fichier .env.

En pratique, ça change tout. Quand je clone un projet Bedrock, un simple composer install suffit à installer WordPress ET tous les plugins. Pas besoin de télécharger quoi que ce soit manuellement, pas besoin de fouiller dans des ZIP sur wordpress.org. Tout est déclaratif, versionné, reproductible 💪

Composer : le game changer pour WordPress 🔧

Si je devais retenir un seul avantage de Bedrock, ce serait Composer. Pour ceux qui ne connaissent pas, Composer c’est le gestionnaire de dépendances de PHP — l’équivalent de npm pour JavaScript ou pip pour Python.

Avec Bedrock, vous déclarez vos plugins dans le composer.json :

{
  "require": {
    "roots/wordpress": "6.7.*",
    "wpackagist-plugin/advanced-custom-fields-pro": "^6.0",
    "wpackagist-plugin/wordpress-seo": "^23.0",
    "wpackagist-plugin/woocommerce": "^9.0"
  }
}

Un composer update et tout se met à jour proprement, avec un composer.lock qui verrouille les versions exactes. Plus de surprises en production, plus de « ça marchait en local mais pas en prod ». C’est du déterminisme pur, et ça fait un bien fou quand on gère plusieurs sites WordPress en parallèle.

J’ai déjà vu des projets où un développeur avait mis à jour un plugin directement depuis le dashboard WordPress en production, sans prévenir personne. Résultat : le site a planté un vendredi soir 😬 Avec Bedrock + Composer, ce scénario est tout simplement impossible. Les plugins ne se mettent pas à jour « tout seuls » — tout passe par le code, le versionning, et le déploiement.

Le fichier .env : fini les secrets dans le code 🔐

C’est un point qui me tenait particulièrement à cœur. Sur un WordPress classique, le wp-config.php contient tout : identifiants de base de données, clés de sécurité, URL du site, mode debug… Et ce fichier est souvent versionné dans Git (oui, j’ai vu ça en production chez des clients).

Bedrock utilise un fichier .env à la racine du projet, ignoré par Git. Chaque environnement a son propre .env :

# .env (développement local)
DB_NAME=monsite_dev
DB_USER=root
DB_PASSWORD=root
DB_HOST=localhost

WP_ENV=development
WP_HOME=https://monsite.local
WP_SITEURL=${WP_HOME}/wp

AUTH_KEY='votre-clé-unique'
# ... autres clés de sécurité

Les avantages sont énormes :

Sécurité : vos secrets ne sont jamais dans le dépôt Git
Flexibilité : chaque environnement a sa propre configuration sans modifier le code
Collaboration : un nouveau développeur clone le repo, copie le .env.example, ajuste ses valeurs locales et c’est parti
CI/CD : les variables d’environnement s’injectent facilement dans les pipelines de déploiement

Quand je configure un projet Bedrock pour un client, je fournis toujours un .env.example documenté avec toutes les variables nécessaires. C’est un petit détail qui fait gagner des heures quand quelqu’un reprend le projet plus tard.

Sécurité renforcée : le web root isolé 🛡️

Sur un WordPress standard, tout est accessible depuis le navigateur : le core, les plugins, les thèmes, le wp-config.php… Même avec des règles .htaccess, c’est une surface d’attaque considérable.

Bedrock change la donne : seul le dossier web/ est exposé au serveur web. Tout le reste (la config, les dépendances Composer, le fichier .env, vos scripts de déploiement) est physiquement inaccessible depuis Internet.

C’est un principe fondamental en sécurité web — la réduction de la surface d’attaque — et c’est quelque chose que WordPress vanilla ne fait tout simplement pas. En combinant ça avec un hébergement bien configuré et un plugin comme Defender Pro, on arrive à un niveau de sécurité vraiment solide.

Pour ma part, cette isolation du web root m’a déjà évité des sueurs froides. Sur un projet où un plugin avait une faille de traversée de répertoire (path traversal), l’attaquant n’a pas pu remonter au-delà du dossier web/. Les secrets dans le .env ? Intouchables. Avec un WordPress classique, le wp-config.php aurait été exposé 😰

Bedrock + Sage : le combo ultime 🚀

Bedrock gère la structure du projet. Mais pour le thème, c’est Sage (aussi par Roots.io) qui prend le relais. Sage 11, la version actuelle, c’est un starter theme WordPress basé sur Laravel Blade pour le templating et Bud pour le build des assets.

Le combo Bedrock + Sage, c’est ce que j’utilise sur la majorité de mes projets. Ça donne :

Bedrock pour la structure projet, les dépendances et la config
Sage 11 pour le thème avec un templating moderne (Blade)
Bud pour la compilation des assets (CSS/JS) avec hot reload
Composer pour les dépendances PHP
Git pour le versionning avec des commits propres

Le résultat : un environnement de développement WordPress qui n’a rien à envier à un projet Laravel ou Symfony. On code avec un vrai IDE, on a du hot reload, on push sur Git, et le déploiement est automatisé. Terminé le Far West du développement WordPress d’il y a 10 ans 🔥

D’ailleurs, si le sujet du déploiement automatisé vous intéresse, j’ai écrit un guide complet sur le CI/CD WordPress qui détaille comment mettre en place un pipeline avec Bedrock.

Multi-environnement : dev, staging, prod sans galère 🌍

Un des gros points noirs de WordPress classique, c’est la gestion des environnements. On a tous connu le « je copie la prod en local, je change les URLs dans la BDD, je croise les doigts ». Avec Bedrock, chaque environnement a son propre fichier de config :

config/
├── application.php          # Config commune
└── environments/
    ├── development.php      # Debug activé, erreurs affichées
    ├── staging.php          # Debug en log, pas d'affichage
    └── production.php       # Tout optimisé, zéro debug

Le fichier .env définit WP_ENV=development ou WP_ENV=production, et Bedrock charge automatiquement la bonne config. Pas de conditions if dans le wp-config, pas de commentaires « décommenter en prod ». C’est propre, c’est lisible, c’est maintenable.

Pour mes clients, ça se traduit par des mises en production beaucoup plus sereines. Je peux tester une mise à jour en staging (même environnement que la prod, mais avec ses propres données) avant de la pousser en production. Quand on gère un site WooCommerce avec des centaines de commandes par jour, ce genre de workflow n’est pas un luxe — c’est une nécessité.

Migration vers Bedrock : comment s’y prendre ? 🔄

OK, vous êtes convaincu mais votre site tourne déjà sur un WordPress classique. Pas de panique, la migration est tout à fait faisable. Voici les grandes étapes que je suis quand j’accompagne un client dans cette transition :

Audit du site existant : lister tous les plugins, vérifier leur disponibilité sur WordPress Packagist (le miroir Composer du répertoire WordPress)
Initialiser le projet Bedrock : composer create-project roots/bedrock
Migrer les plugins : les ajouter un par un via Composer. Les plugins premium (ACF Pro, WooCommerce extensions) nécessitent parfois un repo privé ou un token d’authentification
Migrer le thème : copier votre thème dans web/app/themes/ — ou mieux, en profiter pour passer sur Sage
Configurer le .env : reporter les infos de l’ancien wp-config.php
Adapter le serveur : le document root doit pointer vers web/ et non vers la racine du projet
Tester, tester, tester : vérifier que tout fonctionne en staging avant de basculer la prod

Le point d’attention principal, c’est les plugins premium. Certains éditeurs (comme ACF Pro) proposent maintenant un accès Composer natif, mais d’autres nécessitent un peu de configuration supplémentaire. Rien d’insurmontable, mais il faut le prévoir.

Si vous avez un site qui tourne bien et que vous ne voulez pas tout casser, je recommande de faire la migration sur un environnement de staging dédié, de valider que tout est OK, puis de basculer. J’ai détaillé les bonnes pratiques de migration dans mon article sur la migration de site WordPress.

Bedrock en production : retours d’expérience terrain 💼

Après plusieurs années à utiliser Bedrock en production, voici ce que j’ai observé concrètement :

Les gains mesurables

Temps de setup d’un nouveau projet : de 2-3 heures à 15 minutes. Un composer create-project, un .env configuré, et c’est parti.
Onboarding d’un nouveau dev : de « lis le wiki de 40 pages » à « clone le repo, copie le .env.example, lance composer install ». Dix minutes chrono.
Incidents de déploiement : quasi-zéro. Plus de fichiers oubliés en FTP, plus de versions de plugins incohérentes entre les environnements.
Sécurité : surface d’attaque réduite drastiquement. Le .env, les fichiers de config, rien de ça n’est accessible depuis le web.

Les limites à connaître

Soyons honnêtes, Bedrock n’est pas pour tout le monde :

Courbe d’apprentissage : si vous ne connaissez pas Composer ni la ligne de commande, il y a un cap à passer. Pour un intégrateur junior habitué au dashboard WordPress, c’est un changement de paradigme.
Hébergement : tous les hébergeurs ne supportent pas bien Bedrock. Il faut pouvoir configurer le document root, avoir SSH et Composer installé. Les hébergements mutualisés bas de gamme ne font pas l’affaire.
Plugins « mal élevés » : certains plugins WordPress écrivent dans leur propre dossier ou font des suppositions sur la structure des fichiers. Avec Bedrock, ça peut créer des conflits. Rien d’insurmontable, mais il faut le gérer.
Pas adapté aux tout petits projets : un blog personnel avec 3 plugins n’a probablement pas besoin de toute cette infrastructure. Bedrock brille sur les projets professionnels, les sites WooCommerce, les projets multi-développeurs.

Bedrock vs WordPress classique : le comparatif 📊

Pour vous aider à y voir clair, voici un comparatif direct :

Gestion des dépendances — WordPress classique : manuelle (ZIP, FTP, dashboard) | Bedrock : Composer (déclaratif, versionné)
Configuration — WordPress classique : wp-config.php unique | Bedrock : .env + config par environnement
Sécurité du web root — WordPress classique : tout est exposé | Bedrock : seul web/ est accessible
Versionning Git — WordPress classique : compliqué (core + plugins dans le repo) | Bedrock : propre (seul votre code est versionné)
Déploiement — WordPress classique : manuel ou semi-automatisé | Bedrock : pipeline CI/CD natif
Multi-environnement — WordPress classique : bricolage | Bedrock : natif et élégant
Courbe d’apprentissage — WordPress classique : faible | Bedrock : modérée (Composer, CLI)

Le verdict est assez clair : pour tout projet professionnel, Bedrock est supérieur sur quasiment tous les critères. La seule concession, c’est la courbe d’apprentissage — mais c’est un investissement qui se rentabilise dès le deuxième projet.

Pourquoi faire appel à un développeur qui maîtrise Bedrock ? 🤝

Si vous êtes chef de projet, responsable digital ou dirigeant d’entreprise, vous vous demandez peut-être : « OK, mais en quoi ça me concerne ? ». La réponse est simple : un site construit sur Bedrock est plus sécurisé, plus maintenable et moins cher à faire évoluer sur le long terme.

Un développeur qui utilise Bedrock, c’est un développeur qui :

Applique les bonnes pratiques du développement moderne
Peut mettre en place un workflow de déploiement automatisé
Livre un projet que n’importe quel autre développeur compétent pourra reprendre
Réduit les risques de sécurité et les incidents en production

C’est d’ailleurs un critère de choix que je recommande quand vous cherchez un prestataire WordPress. Si quelqu’un vous propose encore de travailler en FTP avec un WordPress vanilla en 2026, ça en dit long sur ses pratiques 😊 En tant que développeur freelance WordPress, c’est une base non négociable dans mon workflow — et mes clients en voient les bénéfices au quotidien.

Comment démarrer avec Bedrock aujourd’hui ⚡

Si vous êtes développeur et que vous voulez tester, voici le minimum pour démarrer :

# Installer Bedrock
composer create-project roots/bedrock mon-projet

# Configurer l'environnement
cd mon-projet
cp .env.example .env
# Éditer .env avec vos infos locales (BDD, URL, etc.)

# Installer les dépendances
composer install

# Configurer le serveur local pour pointer vers web/
# (Valet, DDEV, Local by Flywheel...)

Pour ajouter un plugin via Composer :

# Plugin gratuit depuis WordPress Packagist
composer require wpackagist-plugin/wordpress-seo

# Plugin premium avec token (exemple ACF Pro)
composer require wpengine/advanced-custom-fields-pro

En 10 minutes, vous avez un projet WordPress moderne, versionnable, déployable. La documentation de Roots.io est excellente et la communauté est très active sur GitHub et Discord. Pas besoin de tout maîtriser d’entrée — commencez par un petit projet test et vous verrez vite la différence.

Et si vous êtes un décideur qui cherche quelqu’un pour mettre en place cette architecture sur votre projet, n’hésitez pas à me contacter. Que vous partiez de zéro ou que vous ayez un site existant à migrer, c’est typiquement le genre de mission que j’adore — transformer un WordPress « bricolé » en un projet solide et pérenne 💪

FAQ — Bedrock WordPress

Bedrock est-il gratuit ?

Oui, Bedrock est entièrement open source et gratuit. C'est un projet maintenu par l'équipe Roots.io, disponible sur GitHub. Vous pouvez l'utiliser librement sur vos projets personnels et professionnels sans aucune licence à payer.

Bedrock est-il compatible avec tous les plugins WordPress ?

La grande majorité des plugins fonctionnent sans problème avec Bedrock. Les plugins du répertoire officiel sont disponibles via WordPress Packagist. Certains plugins premium nécessitent une configuration Composer spécifique, mais les éditeurs majeurs (ACF, Yoast, WooCommerce) proposent désormais un accès Composer natif.

Faut-il Bedrock pour utiliser Sage ?

Non, Sage peut fonctionner sur un WordPress classique. Mais Bedrock + Sage forment un duo pensé pour fonctionner ensemble, et c'est dans cette combinaison que vous tirerez le meilleur parti des deux outils. En pratique, utiliser Sage sans Bedrock revient à se priver de la moitié des avantages.

Mon hébergeur supporte-t-il Bedrock ?

Il faut un hébergement qui permet de configurer le document root (pointer vers le dossier web/) et qui dispose de SSH + Composer. Les hébergements managés type Kinsta, SpinupWP, Cloudways ou un VPS fonctionnent très bien. Les mutualisés basiques (OVH perso, etc.) peuvent poser problème.

Bedrock ralentit-il WordPress ?

Non, Bedrock n'a aucun impact sur les performances de WordPress en production. C'est uniquement une question d'organisation du code et de workflow de développement. Le site généré est identique en termes de rendu et de performance — c'est en coulisses que tout change.