Un projet WordPress accumule vite des dizaines de dépendances Composer et npm, chacune susceptible de recevoir un correctif de sécurité à tout moment. Vérifier manuellement chaque mise à jour disponible relève vite de l’illusion, surtout sur plusieurs projets clients en parallèle. Dependabot et Renovate automatisent cette veille en ouvrant eux-mêmes des pull requests de mise à jour, mais avec des philosophies de configuration sensiblement différentes. L’audit de vulnérabilités en tant que tel, distinct de la simple mise à jour de version, ne fait pas partie de cette comparaison.
Dependabot : la solution native GitHub
Intégré directement à GitHub, Dependabot se configure via un unique fichier .github/dependabot.yml :
version: 2
updates:
- package-ecosystem: "composer"
directory: "/"
schedule:
interval: "weekly"
open-pull-requests-limit: 10
- package-ecosystem: "npm"
directory: "/"
schedule:
interval: "weekly"
groups:
dev-dependencies:
dependency-type: "development"
Cette configuration reste volontairement simple : un intervalle de vérification, une limite de pull requests ouvertes simultanément, et un regroupement basique par type de dépendance. Dependabot fonctionne sans installation supplémentaire, entièrement hébergé par GitHub, ce qui en fait un choix pertinent pour démarrer rapidement sans configuration lourde.
Renovate : configuration fine et regroupement intelligent
Renovate, disponible en application GitHub ou en action CI auto-hébergée, propose un niveau de contrôle nettement supérieur via renovate.json :
{
"extends": ["config:recommended"],
"packageRules": [
{
"matchManagers": ["composer"],
"matchPackagePatterns": ["wpackagist-plugin/*"],
"groupName": "extensions WordPress",
"schedule": ["before 6am on monday"]
},
{
"matchDepTypes": ["devDependencies"],
"matchManagers": ["npm"],
"groupName": "dépendances de développement npm",
"automerge": true
},
{
"matchPackagePatterns": ["^wordpress/"],
"enabled": false
}
],
"vulnerabilityAlerts": {
"labels": ["sécurité"]
}
}
Ce niveau de granularité permet, par exemple, de regrouper toutes les extensions WordPress dans une seule pull request hebdomadaire (plutôt que dix pull requests séparées difficiles à suivre), tout en excluant délibérément le cœur WordPress lui-même, mis à jour selon un processus manuel distinct sur ce projet.
Comparatif
| Critère | Dependabot | Renovate |
|---|---|---|
| Intégration | Native GitHub, zéro installation | Application GitHub ou self-hosted |
| Regroupement de pull requests | Basique (par type de dépendance) | Très fin (par pattern, écosystème, planning) |
| Compatibilité GitLab / Bitbucket | Non (spécifique GitHub) | Oui |
| Alertes de sécurité | Intégrées nativement (GitHub Advisory Database) | Intégrées, configurables plus finement |
| Courbe de configuration | Faible | Moyenne à élevée selon les besoins |
Auto-merge : automatiser sans perdre le contrôle
Fusionner automatiquement une mise à jour de dépendance sans aucune vérification serait imprudent, en particulier sur un projet WordPress où une mise à jour majeure d’une extension peut casser silencieusement une fonctionnalité métier. L’auto-merge ne devrait être activé que sous condition explicite de succès des tests :
name: Auto-merge Renovate
on: pull_request
jobs:
automerge:
if: github.actor == 'renovate[bot]'
runs-on: ubuntu-latest
steps:
- name: Attendre les checks CI
uses: fountainhead/action-wait-for-check@v1
with:
checkName: tests
ref: ${{ github.event.pull_request.head.sha }}
- name: Fusionner si les checks passent
if: steps.wait.outputs.conclusion == 'success'
run: gh pr merge --auto --squash "${{ github.event.pull_request.number }}"
env:
GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
Une pratique raisonnable, largement répandue, consiste à limiter l’auto-merge aux seules mises à jour de correctif (patch) et de dépendances de développement, en laissant les montées de version mineure ou majeure à une revue humaine explicite.
Gérer les mises à jour d’extensions WordPress spécifiquement
Le point souvent sous-estimé sur un projet WordPress : une mise à jour d’extension gérée par Composer peut modifier un comportement testé nulle part dans la suite de tests automatisés, contrairement à une bibliothèque PHP générique bien couverte. La prudence sur l’auto-merge doit être plus grande ici que sur un projet purement applicatif.
Pour les extensions premium installées via un dépôt Composer privé (ACF Pro, Gravity Forms), Renovate et Dependabot fonctionnent de la même façon dès lors que l’authentification est correctement configurée dans les secrets du dépôt — aucune différence de traitement par rapport aux dépendances publiques de Packagist ou wpackagist.
Notre verdict
Pour un projet simple ou une équipe qui découvre ce type d’automatisation, Dependabot suffit largement et ne demande aucune configuration lourde. Dès que le projet grossit — plusieurs écosystèmes de dépendances, besoin de regrouper intelligemment les pull requests, ou hébergement hors GitHub — Renovate devient le choix le plus rentable malgré sa configuration initiale plus exigeante. Dans les deux cas, l’auto-merge ne doit jamais être une fonctionnalité activée par défaut sans condition de tests réels associée.
