Sur un dépôt d’extension WordPress qui mélange PHP via Composer, JavaScript via npm pour les blocs Gutenberg, et parfois une image Docker pour l’environnement de développement, Renovate configuré par défaut produit vite un flux de pull requests illisible. Une mise à jour de phpunit, une autre de @wordpress/scripts, une troisième d’une image de base Docker : tout arrive mélangé, dans l’ordre chronologique de détection plutôt que par pertinence logique.
Le choix de l’outil, Renovate plutôt que Dependabot, a déjà été tranché sur ce blog. La question qui reste, une fois l’outil en place, est différente : comment organiser le flux de propositions pour qu’il reste exploitable au quotidien plutôt que de finir ignoré dans un coin du dépôt ?
Le problème du preset par défaut
La configuration minimale de Renovate, un fichier renovate.json qui étend seulement config:base, traite chaque dépendance indépendamment. Sur un projet avec une trentaine de paquets Composer et une vingtaine de paquets npm, cela génère facilement dix à quinze pull requests distinctes après le premier scan, puis un flux continu de nouvelles PR au fil des sorties amont.
Le développeur chargé de la revue se retrouve à ouvrir, fermer, tester et fusionner des PR une par une, sans distinction entre une mise à jour de patch sans risque et une montée de version majeure d’un framework de test. Le temps passé à trier dépasse vite le temps gagné à automatiser.
Construire des groupes qui ont un sens
La bonne approche consiste à regrouper les dépendances par ce qu’elles représentent dans le projet plutôt que par leur écosystème technique. Un groupe pour les outils de qualité, un autre pour les dépendances de build front, un troisième pour le cœur applicatif, un dernier pour tout le reste. Voici la configuration qui tourne aujourd’hui sur plusieurs dépôts d’extensions de l’agence :
{
"extends": ["config:recommended"],
"timezone": "Europe/Paris",
"schedule": ["before 8am on monday"],
"packageRules": [
{
"groupName": "outils de qualité PHP",
"matchPackageNames": [
"phpunit/phpunit",
"squizlabs/php_codesniffer",
"wp-coding-standards/wpcs",
"phpstan/phpstan"
],
"automerge": true,
"matchUpdateTypes": ["minor", "patch"]
},
{
"groupName": "build front Gutenberg",
"matchPackagePatterns": ["^@wordpress/"],
"matchUpdateTypes": ["minor", "patch"]
},
{
"groupName": "dépendances majeures",
"matchUpdateTypes": ["major"],
"automerge": false,
"dependencyDashboardApproval": true
},
{
"groupName": "autres dépendances patch",
"matchUpdateTypes": ["patch"],
"excludePackagePatterns": ["^@wordpress/"]
}
]
}
Pourquoi isoler les montées majeures
La règle dependencyDashboardApproval appliquée aux versions majeures mérite une explication : plutôt que de laisser Renovate ouvrir automatiquement une PR pour, disons, le passage de PHPUnit 9 à 10, l’outil se contente de lister la mise à jour disponible dans le tableau de bord des dépendances, un fichier Markdown maintenu automatiquement dans une issue épinglée. Le développeur coche la case quand il est prêt à traiter la migration, souvent accompagnée d’un changelog à lire et de tests à adapter.
Cette distinction change tout dans la pratique : les mises à jour mineures et de patch, à faible risque, fusionnent automatiquement après passage de la CI. Les montées majeures, qui demandent une vraie attention, restent visibles sans polluer la liste des pull requests ouvertes.
Le planning, un détail qui change l’ambiance
Le champ schedule fixé à un seul créneau hebdomadaire, le lundi avant 8 heures, évite un autre écueil classique : Renovate qui scanne en continu et ouvre des PR à toute heure, y compris le vendredi soir. Recevoir un lot groupé de propositions le lundi matin, à traiter en une session dédiée, change complètement le rapport à l’outil. Ce n’est plus une interruption permanente mais un rendez-vous prévisible.
Adapter les groupes selon le type de projet
Cette configuration ne convient pas telle quelle à tous les dépôts. Sur un thème plutôt qu’une extension, le groupe front prendra plus de place, avec les dépendances liées à un éventuel bundler. Sur un projet Bedrock, un groupe supplémentaire dédié à roots/wordpress et aux extensions premium gérées par Composer se justifie, car leur cadence de sortie diffère de celle des paquets de développement.
| Groupe | Automerge | Fréquence typique |
|---|---|---|
| Qualité PHP (mineur/patch) | Oui | Hebdomadaire |
| Build Gutenberg (mineur/patch) | Non, revue rapide | Hebdomadaire |
| Dépendances majeures | Non, sur demande | Ponctuelle |
| Reste, patch uniquement | Oui | Hebdomadaire |
Un preset Renovate qui ne reflète pas la réalité du projet finit toujours par se transformer en source de bruit qu’on désactive au bout de quelques mois.
En résumé
Le choix de Renovate contre Dependabot ne règle qu’une partie du problème. La vraie valeur apparaît quand la configuration reflète la structure réelle du projet : séparer ce qui peut fusionner sans supervision de ce qui mérite un vrai regard humain, et fixer un rythme de revue plutôt que de subir un flux continu. Sur les dépôts de l’agence, ce réglage a fait passer le nombre de PR ouvertes en permanence d’une quinzaine à trois ou quatre, sans perdre en réactivité sur les correctifs de sécurité.
