Pendant un temps, j’ai utilisé un service SaaS pour centraliser la maintenance de mes sites clients. Ce type d’outil rend un vrai service : tableau de bord unifié, alertes de sécurité, mises à jour en un clic. Mais à mesure que le nombre de sites augmente, les limites du modèle pèsent plus que ses avantages. Voici comment j’ai reconstruit ce flux avec des outils open source, sur ma propre infrastructure, sans abonnement.
Le constat
Un service SaaS de maintenance WordPress, c’est un abonnement qui grimpe avec le nombre de sites, des quotas d’API au-delà desquels certaines fonctions se dégradent, et des informations sur les sites clients (versions installées, extensions actives) qui transitent chez un tiers. Ce n’est pas une critique de l’outil : WP Umbrella fait ce qu’il promet. Le sujet, c’est l’approche.
Une mise à jour lancée depuis un tableau de bord SaaS modifie le serveur directement, en dehors du code versionné. Le composer.lock ne reflète plus ce qui tourne en production, et le prochain déploiement peut annuler la mise à jour ou créer un état incohérent. Sur des sites gérés par Composer, c’est une friction permanente.
Le principe : une mise à jour est un changement de code
Les sites que je maintiens sont construits sur Bedrock. WordPress, les extensions et les bibliothèques PHP sont déclarés dans composer.json et figés dans composer.lock. Mettre à jour une extension, c’est modifier ce fichier, le valider dans le dépôt, le tester, puis le déployer comme n’importe quelle évolution du projet.
Conséquence directe : chaque mise à jour est traçable et passe par les mêmes étapes que le reste du code. Aucune mise à jour n’est faite directement sur le serveur.
Le flux de la semaine
L’automatisation repose sur Renovate, un outil open source qui tourne sur mon propre runner GitLab. Une semaine type :
Lundi matin
└── Renovate ouvre une MR « composer update » par site
└── La CI construit et vérifie le site
CI verte
└── Merge automatique → déploiement en préproduction
Jeudi (préproduction inchangée depuis 3 jours, CI verte)
└── MR de mise en production préparée automatiquement
└── Liste des paquets mis à jour et des changements
Je relis et je valide
└── Mise en production, reprise dans le rapport mensuel du client
Cas particuliers
├── Mise à jour majeure → sur approbation
└── Version problématique connue → bloquée par une règleLa préproduction est toujours à jour. La production ne reçoit une mise à jour qu’après trois jours sans changement en préproduction, et après relecture. Les mises à jour majeures, susceptibles de changer une API ou un comportement, ne passent jamais d’elles-mêmes : elles attendent une approbation. Les versions connues pour poser problème sont bloquées par une règle de configuration, une fois pour tous les sites.
Les extensions premium
Les extensions commerciales posent un problème particulier dans un flux Composer : leurs mises à jour ne sont pas publiées sur un registre public. Les licences sont achetées auprès de chaque éditeur et rattachées à un dépôt Composer privé, hébergé sur ma propre infrastructure. C’est lui qui télécharge les nouvelles versions avec ces licences, puis les expose aux sites comme n’importe quel paquet. Renovate les suit comme les autres. Les clés restent dans ce dépôt privé, au lieu d’être copiées dans chaque projet.
La surveillance des vulnérabilités
Toutes les quatre heures, un scan compare l’inventaire exact de chaque site en production (les versions réellement déployées, lues dans le composer.lock, plus les extensions versionnées dans le dépôt) aux bases publiques de vulnérabilités WordPress et PHP. Les bases sont téléchargées, la comparaison se fait en local : aucune donnée de site n’est envoyée à un tiers, et il n’y a pas de quota par site.
Quand une vulnérabilité est trouvée et qu’un correctif existe, la MR de mise à jour est marquée « sécurité », ou Renovate est relancé immédiatement pour la créer. Sans correctif, un ticket est ouvert pour le suivi. Dans tous les cas, l’information déclenche une action : elle ne reste pas dans un tableau de bord.
Ce que ça change
Le bénéfice le plus direct : chaque changement en production est traçable. On sait ce qui a changé, quand et pourquoi. Si une mise à jour pose problème, revenir en arrière se fait dans le code puis par un déploiement, avec la même relecture que le reste.
Une préproduction toujours à jour devient vraiment utile : elle montre ce qui sera en production après la prochaine validation, pas un état figé depuis six mois.
Le coût de fonctionnement se limite au runner GitLab et au dépôt Composer privé, deux briques déjà présentes dans l’infrastructure. Pas d’abonnement en plus, pas de quota à surveiller, et aucune donnée envoyée à un service de maintenance tiers.
Le vrai point de friction par rapport à un SaaS, c’est la mise en place : configurer Renovate, brancher le dépôt privé, écrire le scan des vulnérabilités. C’est un investissement qui s’amortit avec le temps et le nombre de sites. Pour un site isolé maintenu ponctuellement, un SaaS reste sans doute plus pragmatique.
Pour des sites sur Bedrock, avec un pipeline de déploiement et une préproduction déjà en place, ce flux s’intègre naturellement et rend l’ensemble plus cohérent.
Vous souhaitez une maintenance structurée pour votre site WordPress, ou simplement faire le point sur ce qui est installé et dans quel état ? Parlons-en : contact@juzed.dev.
Stack : Bedrock · Composer · Renovate · SatisPress · GitLab CI/CD · Docker · WordPress FSE