Composer et Bedrock : industrialiser WordPress sans complexité inutile

Tu veux gagner en sérénité sur ton site sans te noyer dans la technique ? Bonne nouvelle : moderniser WordPress ne rime pas avec usine à gaz. Avec un duo éprouvé — composer wordpress et bedrock wordpress — tu peux structurer ton projet, fiabiliser la gestion dependances plugins, sécuriser les environnements et poser un workflow deploiement wordpress solide. L’objectif de ce guide : te montrer comment moderniser wordpress avec des outils standards, sans complexité inutile, et te proposer un plan de migration progressive pour éviter la casse. Chez WP Builders, on met en place ces architectures au quotidien : ce qui suit est donc un condensé de retours de terrain et de bonnes pratiques applicables dès aujourd’hui.

Si tu as déjà vécu des mises à jour qui cassent un plugin, des versions différentes entre ton site de préprod et la prod, ou des déploiements à la main en FTP… tu sais à quel point l’approximation coûte cher. Composer et Bedrock permettent de verrouiller les versions, de séparer proprement le code applicatif du core WordPress, et d’industrialiser les déploiements. Résultat : des sites plus rapides à maintenir, plus faciles à faire évoluer, et nettement plus sûrs. On va voir ensemble pourquoi ce couple d’outils est si efficace, comment le mettre en place sans friction, et comment migrer étape par étape, même si ton site tourne déjà en production.

Pourquoi moderniser WordPress avec Composer + Bedrock

WordPress a longtemps été géré « à la main » : on télécharge, on installe des plugins via l’admin, on met à jour quand on a le temps. Ce modèle fonctionne pour un blog perso, mais devient risqué dès que le site soutient une activité pro. Composer apporte une gestion des dépendances claire, versionnée et reproductible. Bedrock, de son côté, restructure l’application : core séparé, configuration par environnement, autoloading et organisation en dossiers lisibles. Ensemble, ils transforment WordPress en projet logiciel maîtrisé.

• Versions prévisibles et verrouillées avec composer.lock.
• Arborescence propre : le core n’est plus mélangé à ton code.
• Déploiements automatisables et rollback rapide.
• Sécurité renforcée (fichiers sensibles hors webroot, config .env).
• Onboarding simplifié : cloner, composer install, ça tourne.

Composer et Bedrock en clair (sans jargon)

Composer est le gestionnaire de dépendances standard du monde PHP. Tu listes les plugins, thèmes ou librairies dont ton projet a besoin, Composer les installe exactement dans les versions déclarées et conserve un verrou d’assemblage. Si tu veux creuser, la doc officielle est excellente : documentation Composer.

Bedrock est une « structure » de projet créée par Roots. Elle apporte une arborescence moderne, la config par variables d’environnement, et l’installation du core WordPress en tant que dépendance. C’est simple, propre, et documenté ici : Roots Bedrock.

Structurer le projet : arborescence, webroot et config

Bedrock réorganise WordPress de manière explicite :

• web/ contient les fichiers exposés au web (index.php, wp/ pour le core).
• web/app/ regroupe thèmes, plugins, mu-plugins, uploads.
• config/ stocke la configuration PHP par environnement.
• vendor/ garde les dépendances installées par Composer.

Concrètement, ça facilite la sécurité (pas de fichiers sensibles sous la racine publique), la maintenance (on sait où est quoi) et le déploiement (on ne pousse que le nécessaire). C’est aussi plus simple pour travailler en équipe : tout est dans Git, sauf les fichiers générés (uploads, cache).

Gérer les dépendances de plugins et thèmes avec Composer

Tu peux installer la plupart des plugins du répertoire officiel via WPackagist (un miroir Packagist). L’idée : on ne clique plus « Ajouter une extension » dans l’admin, on déclare tout dans composer.json. Ça garantit des versions reproductibles sur tous les environnements.

Exemple minimal de composer.json

{  "name": "acme/site",  "type": "project",  "repositories": [    {"type": "composer", "url": "https://wpackagist.org"}  ],  "require": {    "php": "^8.1",    "composer/installers": "^2.2",    "roots/wordpress": "^6.5",    "oscarotero/env": "^2.1",    "wpackagist-plugin/wordpress-seo": "^22.0",    "wpackagist-plugin/advanced-custom-fields": "^6.3"  },  "extra": {    "wordpress-install-dir": "web/wp",    "installer-paths": {      "web/app/mu-plugins/{$name}/": ["type:wordpress-muplugin"],      "web/app/plugins/{$name}/": ["type:wordpress-plugin"],      "web/app/themes/{$name}/": ["type:wordpress-theme"]    }  }}

Ensuite, un simple composer install en dev (ou composer install --no-dev en prod) reconstruit exactement le même ensemble de versions que celui verrouillé dans ton composer.lock. Tu sais ce que tu déploies, et tu peux revenir en arrière si nécessaire.

Environnements séparés avec .env (dev, staging, prod)

Autre bénéfice majeur de Bedrock : la configuration par environnement. Plus de copier-coller approximatif d’un wp-config.php. Tu poses tes variables dans un fichier .env (non versionné) et le tour est joué.

Exemple de .env

WP_ENV=stagingWP_HOME=https://staging.example.comWP_SITEURL=${WP_HOME}/wpDB_NAME=example_stagingDB_USER=exampleDB_PASSWORD=********DB_HOST=127.0.0.1AUTH_KEY=generate_meSECURE_AUTH_KEY=generate_meLOGGED_IN_KEY=generate_meNONCE_KEY=generate_me

Tu disposes ainsi d’une séparation nette entre la logique de l’application (versionnée) et les secrets (non versionnés). Et quand tu passes en production, tu changes uniquement le .env, pas le code. Pratique, sûr et compatible avec n’importe quel hébergeur moderne.

Scripts Composer et WP-CLI pour automatiser le quotidien

Composer te permet aussi de définir des scripts pour enchaîner plusieurs actions : cache flush, build d’assets, génération d’autoload, etc. Couplé à WP-CLI, tu peux industrialiser l’entretien et réduire les interventions manuelles.

Exemple de scripts utiles

{  "scripts": {    "post-install-cmd": [      "wp core update-db --path=web/wp || true",      "wp cache flush || true"    ],    "post-update-cmd": [      "wp plugin update --all || true"    ]  }}

Ces scripts s’exécutent automatiquement après un composer install ou composer update. En prime, WP-CLI rend tes opérations idempotentes (répéter n’abîme pas) et scriptables en CI/CD.

Besoin d’un setup propre et fiable ?

On structure, automatise et sécurise ton workflow WordPress en moins d’une semaine, sans interrompre ton business.

Parler à un expert

Workflow de déploiement WordPress reproductible

Passons au cœur de l’industrialisation : un pipeline de build et de déploiement qui sort toujours le même résultat, quelle que soit la machine. L’idée :

• On versionne le code applicatif et composer.lock dans Git.
• On compile (composer install) en CI pour produire un artefact.
• On déploie l’artefact sur le serveur (rsync/SSH), sans exécuter Composer en prod.
• On garde la base de données et les uploads hors Git, avec sauvegardes/restore.

Exemple de pipeline GitHub Actions

name: deployon:  push:    branches: ["main"]jobs:  build:    runs-on: ubuntu-latest    steps:      - uses: actions/checkout@v4      - uses: shivammathur/setup-php@v2        with:          php-version: '8.2'      - run: composer install --no-dev --prefer-dist --no-interaction      - run: tar -czf build.tgz web vendor config composer.lock      - uses: actions/upload-artifact@v4        with:          name: build          path: build.tgz  deploy:    needs: build    runs-on: ubuntu-latest    steps:      - uses: actions/download-artifact@v4        with:          name: build      - run: |          tar -xzf build.tgz          rsync -az --delete web/ user@server:/var/www/site/web          rsync -az --delete vendor/ user@server:/var/www/site/vendor

Ce modèle est simple et robuste : on maîtrise exactement ce qui part en production, on peut archiver les artefacts, et on évite les surprises liées aux environnements.

Sauvegardes, search-replace et migrations de base de données

Un déploiement propre n’oublie jamais la base de données. Avant toute montée de version majeure, prends un dump SQL et une sauvegarde des uploads. Pour synchroniser staging et prod, couple un export/import SQL à un wp search-replace (pour mettre à jour les URLs). Et si tu déploies fréquemment, envisage des outils de migration différentielle ou un process de « contenu figé » pendant la fenêtre de déploiement.

Côté médias, stocke-les hors Git (S3, Object Storage, ou simplement sur le serveur), avec une politique de sauvegardes régulières. Evite de réécrire l’historique Git avec des fichiers lourds : tu veux des déploiements rapides, pas des clones qui pèsent 5 Go.

Sécurité et performance au passage

La séparation du webroot, la configuration par .env, et le verrouillage des versions via Composer renforcent mécaniquement la sécurité. Ajoute à cela des headers HTTP, un WAF si nécessaire, des mises à jour régulières orchestrées (Composer + tests), et tu réduis l’attaque de surface. Côté performance, un build propre, un cache serveur (OPcache, page caching), et une politique d’assets maîtrisés t’évitent les dérives au fil du temps.

Chez WP Builders, on aime commencer par un audit rapide : architecture, plugins chargés, lenteurs et points de friction de déploiement. En général, la simple migration vers Composer/Bedrock et un pipeline propre font gagner des heures chaque mois.

Plan de migration progressive sans tout casser

Tu as déjà un WordPress en production ? Pas besoin de « big bang ». Voici une séquence en 5 étapes qui marche dans 80% des cas.

Étape 1 — Inventaire et gel des versions

• Récupère la liste des plugins/thèmes actifs, leurs versions, et le core.
• Gèle les mises à jour en prod le temps de la transition.
• Crée un dépôt Git propre avec un .gitignore adapté (uploads exclus).

Étape 2 — Mise en place de Bedrock en parallèle

• Crée un nouveau repo Bedrock « vierge » en local.
• Ajoute les dépendances équivalentes (via WPackagist et Composer).
• Copie ton thème personnalisé dans web/app/themes/ et ajuste le namespace si besoin.

Étape 3 — Import du contenu et configuration .env

• Exporte la base prod, importe-la dans l’environnement Bedrock local.
• Renseigne WP_HOME, WP_SITEURL et les clés salts dans .env.
• Teste l’admin, les pages clés et les fonctionnalités e-commerce si présentes.

Étape 4 — Pipeline de build et staging

• Ajoute un pipeline CI (build + artefact) et déploie sur un staging.
• Fais une revue fonctionnelle avec l’équipe (paiement, formulaires, recherches, emails).
• Prépare le plan de bascule (fenêtre, sauvegarde, plan de secours/rollback).

Étape 5 — Bascule contrôlée en production

• Gèle temporairement le contenu (ou communique la plage à faible trafic).
• Backup DB + uploads, déploiement de l’artefact, wp search-replace si nécessaire.
• Tests de fumée, monitoring renforcé, et rollback prêt en un clic si besoin.

Erreurs courantes et comment les éviter

• Installer des plugins à la main après la migration. Interdit. Tout doit passer par Composer pour rester reproductible.
• Exécuter Composer en production sans contrôle. Préfère construire l’artefact en CI et déployer le résultat.
• Oublier la base de données et les URLs. Anticipe le search-replace et les sérialisations.
• Mélanger uploads et Git. Garde les médias hors du dépôt et sauvegarde-les correctement.
• Sous-estimer le temps de test. Prévois une checklist fonctionnelle (paiements, emails, formulaires, SEO).

Aller plus loin sans complexité inutile

Tu peux enrichir progressivement : mu-plugins pour la logique transversale, autoload PHP pour ton code métier, politiques de mises à jour (rénovation mensuelle), et tests basiques de non-régression. Pas besoin de tout faire le jour 1. L’essentiel est de verrouiller ton socle et d’installer un rythme fiable.

Dans certains cas, on ajoute une étape de build front (bundler, purge CSS) pour optimiser les assets. Là encore, c’est piloté par Composer et orchestré en CI. Transparence et répétabilité avant tout.

Combien de temps ça prend ? Quel ROI ?

Sur un site vitrine classique, l’adoption de Composer/Bedrock et du pipeline prend souvent 1 à 3 jours ouvrés selon la dette technique. Sur un e-commerce plus touffu, compte 3 à 7 jours pour embarquer proprement les extensions critiques et solidifier le processus. Le ROI est quasi immédiat : moins de régressions, des mises à jour maîtrisées, une capacité à réagir vite en cas de bug, et une meilleure sécurité globale.

Chez WP Builders, on intervient rapidement, on documente tout et on forme l’équipe interne pour la suite. Tu gardes la main, on enlève la friction.

Checklist express pour t’y mettre dès aujourd’hui

• Crée un dépôt Git propre et ajoute un .gitignore adapté.
• Initialise un projet Bedrock et renseigne les variables .env.
• Déclare tous tes plugins/thèmes via Composer (versions explicites).
• Monte un staging et un pipeline de build + déploiement.
• Écris un plan de rollback (sauvegardes, artefact n-1).
• Programme une fenêtre de bascule, puis teste minutieusement.

Conclusion : industrialiser WordPress, simplement

Composer et Bedrock ne transforment pas WordPress en framework « réservé aux devs ». Ils posent des garde-fous sains pour un site pro : architecture claire, dépendances maîtrisées, environnements propres et déploiements fiables. En adoptant ce duo, tu modernises la base de ton site sans le surcharger d’outils. Et si tu veux accélérer, éviter les pièges et sécuriser ta bascule, on peut t’accompagner pas à pas, du diagnostic à la mise en prod.