CI/CD WordPress : automatiser le déploiement de votre site sans stress
Vous développez votre site WordPress, vous faites vos modifs en local, vous testez, tout roule… et là, c’est le moment de mettre en production. Alors vous ouvrez FileZilla, vous glissez-déposez vos fichiers, vous priez pour ne rien casser, et vous rafraîchissez la page en croisant les doigts 🤞
Ça vous parle ? Moi aussi, ça m’a parlé pendant longtemps. Trop longtemps. En tant que développeur freelance WordPress, j’ai déployé des centaines de sites. Et croyez-moi, le jour où j’ai mis en place ma première pipeline CI/CD, c’est comme si j’étais passé du vélo à la fusée 🚀
Le CI/CD (Continuous Integration / Continuous Deployment), c’est l’art d’automatiser tout ce qui se passe entre votre commit Git et la mise en ligne. Plus de FTP, plus de manips manuelles, plus de « oups j’ai écrasé le mauvais fichier ». Juste un git push et votre site se déploie tout seul, après avoir vérifié que tout fonctionne.
Dans cet article, je vous explique concrètement comment ça marche pour WordPress, pourquoi c’est un game-changer pour votre projet, et comment je mets ça en place pour mes clients — du freelance lillois au grand groupe national.
Le déploiement WordPress « classique » : un nid à problèmes 😰
Avant de parler de CI/CD, mettons-nous d’accord sur ce qu’on cherche à remplacer. Le workflow classique WordPress, celui que 90% des agences et freelances utilisent encore, ressemble à ça :
- Développement en local (MAMP, Local WP, Docker…)
- Tests manuels « ça a l’air de marcher »
- Transfert des fichiers en FTP/SFTP sur le serveur
- Prière silencieuse 🙏
- Rafraîchissement frénétique du navigateur
- Appel en panique au collègue quand ça plante
J’exagère à peine. Le problème fondamental de cette approche, c’est qu’elle repose entièrement sur l’humain. Et l’humain, aussi compétent soit-il, fait des erreurs. Surtout à 18h un vendredi quand le client veut sa modif « pour hier » 😅
Les risques concrets :
- Écrasement de fichiers : vous uploadez une version qui écrase des modifs faites en production
- Oubli de fichiers : vous transférez le thème mais oubliez le plugin custom
- Pas de rollback : si ça plante, bonne chance pour revenir en arrière sans Git
- Temps perdu : chaque déploiement prend 15-30 minutes de manips manuelles
- Zéro traçabilité : impossible de savoir qui a déployé quoi et quand
J’ai travaillé avec des clients qui avaient vécu des incidents de production catastrophiques à cause de déploiements FTP ratés. Un fichier wp-config.php écrasé par la version locale, et c’est tout le site qui tombe. J’ai déjà vu ça chez un client e-commerce — 4 heures de downtime, des commandes perdues, un stress monumental. Tout ça parce que le process de déploiement était… du bricolage.
CI/CD pour WordPress : le principe expliqué simplement 🎯
Le CI/CD, c’est deux concepts complémentaires :
CI — Continuous Integration (Intégration Continue) : à chaque fois que vous poussez du code sur votre dépôt Git, un serveur automatisé récupère ce code, lance une batterie de vérifications (tests, linting, compilation des assets…) et vous dit si tout est OK ou pas. C’est votre filet de sécurité.
CD — Continuous Deployment (Déploiement Continu) : si la CI passe au vert, le code est automatiquement déployé sur votre serveur. Pas de FTP, pas de manip manuelle. Le serveur de CI se connecte à votre hébergement et met à jour les fichiers tout seul.
Pour faire une analogie, pensez à une chaîne de montage automobile. Dans l’ancien monde, chaque pièce était posée à la main, vérifiée à l’œil nu, avec un risque d’erreur à chaque étape. Le CI/CD, c’est la chaîne automatisée : chaque pièce est testée par des capteurs, assemblée par des robots, et le contrôle qualité est intégré dans le process lui-même. Le résultat ? Moins d’erreurs, plus de vitesse, et une qualité constante.
Ma stack CI/CD pour WordPress : Bedrock + Git + pipeline automatisé ⚙️
Il y a plein d’outils de CI/CD sur le marché (GitHub Actions, GitLab CI, Jenkins, CircleCI…), mais pour mes projets WordPress, j’utilise un outil de CI/CD visuel et performant. L’avantage ? La configuration est intuitive, pas besoin de se battre avec des fichiers YAML à rallonge. En quelques clics, vous avez un pipeline complet qui gère build, tests et déploiement.
Ma stack type pour un projet WordPress professionnel :
- Bedrock (par Roots.io) : la structure WordPress moderne et professionnelle
- Sage 11 : le starter theme avec Blade templating et Bud pour le build front
- Git : versioning de tout le code (thème, plugins custom, config)
- Un outil de CI/CD performant qui orchestre tests et déploiement
- Déploiement SSH intégré à Buddy : push automatique sur le serveur
L’avantage de Bedrock, c’est que WordPress est géré comme un vrai projet logiciel. La config est propre, le .gitignore est déjà configuré pour ne versionner que ce qui doit l’être, et combiné avec un bon outil de CI/CD, on obtient un pipeline de déploiement fiable et reproductible.
Le workflow concret : du commit à la production
Voici ce qui se passe quand je pousse du code sur un projet :
- Git push sur la branche
main(ou merge d’une pull request) - Le pipeline CI/CD se déclenche automatiquement
- Installation des dépendances :
yarn installpour le front - Build des assets : compilation Sass/PostCSS, bundling JS avec Bud
- Vérifications : linting PHP (PHPCS), linting JS (ESLint), éventuellement tests unitaires
- Si tout est vert ✅ : déploiement automatique sur le serveur via SSH
- Si quelque chose échoue ❌ : notification immédiate, rien n’est déployé
Tout ça prend environ 2-3 minutes. Contre 15-30 minutes de manips manuelles. Et surtout : c’est reproductible. Chaque déploiement suit exactement le même process, sans oubli possible.
Les environnements : staging, production, et les branches Git 🌿
Un des gros avantages du CI/CD, c’est la gestion des environnements. Sur mes projets, j’ai systématiquement :
- Local : mon environnement de développement (Docker ou Valet)
- Staging : un serveur de pré-production accessible au client pour validation
- Production : le site en ligne, celui que tout le monde voit
Le CI/CD gère tout ça via les branches Git. Concrètement :
- Un push sur
develop→ déploiement automatique sur staging - Un push sur
main→ déploiement automatique en production
Le client peut ainsi valider les modifications sur le staging avant qu’elles partent en production. C’est un workflow que j’utilise sur chaque projet, que ce soit pour un site vitrine à Lille ou un e-commerce national. La rigueur est la même, parce que c’est automatisé — pas besoin de se rappeler des étapes à suivre 💪
Ce que le CI/CD vérifie automatiquement sur votre site WordPress 🔍
La partie « Continuous Integration » (CI), c’est là que la magie opère côté qualité. Voici ce que je configure systématiquement :
Linting et standards de code
PHPCS (PHP CodeSniffer) avec les WordPress Coding Standards vérifie que le code PHP respecte les conventions. Ça attrape les erreurs de syntaxe, les failles de sécurité basiques, et les mauvaises pratiques. ESLint fait la même chose côté JavaScript.
Pour le CSS, que ce soit en BEM custom (mon approche préférée pour les gros projets — plus performant et maintenable) ou en Tailwind (idéal quand le budget est serré et qu’il faut aller vite), le linting vérifie la cohérence et les erreurs. Deux approches différentes, chacune avec ses forces selon le contexte du projet.
Build des assets front-end
La compilation des fichiers front (Sass → CSS, ES6 → JS compatible navigateurs, minification, tree-shaking…) est faite par le CI. Si le build échoue — par exemple une erreur de syntaxe dans un fichier Sass — le déploiement est bloqué. Vous ne déploierez jamais un site cassé visuellement.
Vérification des dépendances
Les dépendances front (Yarn/npm) sont installées dans un environnement propre par le pipeline. Si un package a une incompatibilité, on le sait immédiatement, pas après le déploiement quand le client appelle en panique 😬
Sécurité et CI/CD : le duo gagnant 🔐
Un aspect souvent négligé du CI/CD, c’est la sécurité. Et pourtant, c’est un avantage énorme :
- Plus de credentials FTP qui traînent : les accès au serveur sont stockés dans des variables chiffrées côté CI/CD, jamais exposés dans le code
- Audit des dépendances : Le pipeline peut vérifier automatiquement si vos packages ont des vulnérabilités connues
- Traçabilité totale : chaque déploiement est lié à un commit Git, avec l’auteur, la date, et le contenu exact des modifications
- Rollback en un clic : un problème en production ? Il suffit de reverter le commit et le CI/CD redéploie automatiquement la version précédente
C’est un sujet que j’aborde systématiquement avec mes clients, en complément de la maintenance WordPress classique. La sécurité, ce n’est pas juste mettre un plugin de firewall — c’est aussi sécuriser tout le process de déploiement.
Cas concret : comment j’ai mis en place le CI/CD pour un site e-commerce 🛒
Pour illustrer concrètement, voici comment s’est passé la mise en place du CI/CD sur un projet WooCommerce récent.
Le contexte : un site e-commerce avec un thème Sage 11 custom, une dizaine de plugins (dont ACF Pro, WooCommerce, et des plugins custom), et un hébergement infogéré. Le client avait déjà vécu un incident de production suite à un déploiement FTP raté — motivation maximale pour changer de méthode 😅
Étape 1 — Mise en place de Bedrock : migration de la structure WordPress classique vers Bedrock. Ça prend environ une demi-journée et ça transforme la gestion du projet.
Étape 2 — Versioning Git : tout le code (thème, plugins custom, config Bedrock) est versionné sur Git. Les plugins sont gérés proprement dans le projet.
Étape 3 — Pipeline CI/CD : configuration du pipeline qui orchestre build, tests et déploiement — tout automatisé.
Étape 4 — Environnement staging : mise en place d’un sous-domaine staging avec déploiement automatique depuis la branche develop.
Résultat : temps de déploiement passé de 25 minutes (avec stress) à 3 minutes (sans stress). Plus aucun incident de production en 6 mois. Et le client peut valider chaque modification sur staging avant la mise en ligne 🎉
CI/CD et WordPress : les pièges à éviter ⚠️
Tout n’est pas rose dans le monde du CI/CD WordPress. Voici les écueils que j’ai rencontrés (et comment je les gère) :
La base de données n’est pas dans Git
C’est LA spécificité de WordPress. Le contenu est en base de données, pas dans des fichiers. Le CI/CD gère le code (thème, plugins, config), mais pas le contenu. Pour la synchronisation de base entre environnements, j’utilise WP-CLI avec des scripts dédiés — mais ça reste un point d’attention permanent.
Les plugins qui modifient des fichiers
Certains plugins WordPress écrivent des fichiers directement sur le serveur (cache, logs, config…). Il faut s’assurer que le déploiement ne les écrase pas. La solution : un .gitignore bien configuré et des règles de déploiement qui excluent ces répertoires.
Le client qui modifie le thème en production
Si quelqu’un modifie des fichiers directement sur le serveur de production (via l’éditeur de thème WordPress par exemple), le prochain déploiement écrasera ces modifications. Solution : désactiver l’éditeur de fichiers en production (DISALLOW_FILE_EDIT) et former le client à passer par le process Git.
Combien ça coûte de mettre en place du CI/CD sur WordPress ? 💰
Bonne nouvelle : Les outils de CI/CD modernes proposent des offres accessibles qui couvrent largement les besoins d’un projet WordPress. L’investissement est minime par rapport au temps gagné et aux erreurs évitées.
Le vrai coût, c’est le temps de mise en place initiale. Comptez environ une journée de développement pour :
- Migrer vers Bedrock (si ce n’est pas déjà fait)
- Configurer le dépôt Git
- Configurer le pipeline CI/CD
- Configurer les environnements (staging + production)
- Tester le pipeline de bout en bout
C’est un investissement qui se rentabilise en quelques semaines. Rien qu’en temps gagné sur les déploiements (15-30 min économisées à chaque fois), sans compter les incidents évités. Pour mes clients en contrat de maintenance, c’est inclus dans la mise en place — parce que ça me fait aussi gagner du temps au quotidien 😊
Pourquoi votre développeur WordPress devrait maîtriser le CI/CD 🏆
Si vous cherchez un développeur web à Lille ou ailleurs en France (je travaille en full remote avec des clients partout), la maîtrise du CI/CD est un indicateur de maturité technique. Un développeur qui déploie encore en FTP en 2026, c’est comme un mécanicien qui n’utilise pas de pont élévateur — ça marche, mais c’est pas professionnel.
Le CI/CD, c’est la garantie que :
- Votre site est déployé de manière fiable et reproductible
- Chaque modification est traçable et réversible
- Les erreurs sont détectées avant d’arriver en production
- Les mises à jour sont plus fréquentes (et donc plus petites, moins risquées)
- Votre développeur passe son temps à coder, pas à transférer des fichiers
C’est aussi un signe que le développeur travaille avec des outils modernes (Git, Bedrock, CI/CD automatisé…) plutôt qu’avec des méthodes datant de 2010. Et ça, pour la pérennité de votre projet, ça fait toute la différence.
Aller plus loin : tests automatisés et monitoring 📊
Une fois le CI/CD en place, on peut aller encore plus loin :
- Tests end-to-end : avec des outils comme Cypress ou Playwright, on simule un utilisateur qui navigue sur le site. Le formulaire de contact fonctionne ? Le panier WooCommerce est OK ? Le CI vérifie automatiquement.
- Tests de performance : Lighthouse CI peut être intégré à la pipeline pour vérifier que les performances ne se dégradent pas à chaque déploiement.
- Monitoring post-déploiement : des outils de monitoring (UptimeRobot, Datadog…) vérifient que le site répond correctement après chaque mise en production.
- Notifications : Slack, email, ou Discord — le CI/CD notifie l’équipe en cas de succès ou d’échec du déploiement.
C’est cette approche globale — du commit au monitoring — qui fait la différence entre un site WordPress « artisanal » et un site WordPress professionnel. Et c’est exactement ce que je mets en place pour mes clients, qu’ils soient dans la métropole lilloise ou n’importe où en France 🇫🇷
Questions fréquentes sur le CI/CD WordPress
Le CI/CD (Continuous Integration / Continuous Deployment) c'est un système qui automatise les tests et le déploiement de votre site. Concrètement, quand un développeur pousse du code, un serveur vérifie automatiquement que tout fonctionne et déploie les modifications sur votre site sans intervention manuelle. Plus besoin de transférer des fichiers à la main via FTP.
La plupart des hébergements modernes supportent le déploiement via SSH, ce qui est suffisant pour le CI/CD. Les hébergements mutualisés bas de gamme peuvent poser problème (pas d'accès SSH, pas de Composer). C'est une des raisons pour lesquelles je recommande des hébergements infogérés de qualité pour les projets professionnels.
Comptez environ une journée de développement pour la mise en place complète : migration vers Bedrock si nécessaire, configuration du dépôt Git, écriture du workflow CI/CD, et tests du pipeline. C'est un investissement initial qui se rentabilise rapidement grâce au temps gagné sur chaque déploiement.
Le CI/CD gère le code (thème, plugins, configuration), mais pas directement la base de données WordPress qui contient votre contenu. Pour la synchronisation de base entre environnements, on utilise des outils complémentaires comme WP-CLI. C'est un point d'attention spécifique à WordPress que votre développeur doit maîtriser.
Absolument. Les outils de CI/CD modernes s'intègrent parfaitement avec WordPress. Un déploiement prend 2-3 minutes et c'est devenu indispensable dans mon workflow quotidien pour tous mes projets clients.
Ce n'est pas strictement obligatoire, mais c'est très fortement recommandé. Bedrock structure WordPress comme un vrai projet logiciel, ce qui rend le CI/CD beaucoup plus simple à configurer proprement. Sans Bedrock, c'est possible mais plus complexe. C'est pourquoi j'utilise Bedrock sur tous mes projets professionnels.