Une dépendance jamais mise à jour n’est pas un problème visible : elle ne casse rien, elle continue simplement d’exister, jusqu’à ce qu’une CVE publiée révèle qu’elle traînait depuis dix-huit mois de retard. Renovate et Dependabot automatisent la détection et la proposition de mise à jour, mais avec des philosophies de configuration très différentes.
Le problème que les deux outils résolvent
Sans automatisation, mettre à jour une dépendance demande une action humaine délibérée : vérifier le changelog, tester, ouvrir une PR, un effort qui n’est presque jamais prioritaire face aux fonctionnalités attendues par le produit. Le résultat typique, sans outil dédié : des dépendances qui accumulent des mois voire des années de retard, jusqu’à ce qu’une migration majeure devienne un projet à part entière plutôt qu’une succession de petits pas.
Dependabot : natif GitHub, configuration minimale
Dependabot est intégré nativement à GitHub, sans service externe à connecter, et se configure en quelques lignes YAML directement dans le dépôt :
# .github/dependabot.yml
version: 2
updates:
- package-ecosystem: "npm"
directory: "/"
schedule:
interval: "weekly"Cette simplicité a une contrepartie : Dependabot ouvre une PR par dépendance mise à jour par défaut, ce qui peut rapidement submerger un dépôt actif de dizaines de PR distinctes, chacune nécessitant sa propre vérification CI. Le regroupement de mises à jour existe mais reste plus limité que ce que propose Renovate.
Renovate : configuration exhaustive, groupement natif
Renovate (disponible en GitHub App ou en self-hosted) expose une surface de configuration bien plus large, avec un point fort concret : le regroupement de mises à jour liées en une seule PR plutôt qu’une par dépendance.
{
"extends": ["config:recommended"],
"packageRules": [
{
"matchPackagePatterns": ["^@testing-library"],
"groupName": "testing-library packages"
}
]
}Ce regroupement réduit le bruit de façon significative sur un monorepo avec de nombreuses dépendances liées (voir l’article sur le cache de build en monorepo), au prix d’une configuration plus longue à écrire et à maintenir que le fichier YAML minimal de Dependabot.
Le vrai différenciateur : la planification et l’auto-merge
Les deux outils permettent de planifier les mises à jour (éviter le vendredi après-midi, grouper en une fenêtre hebdomadaire), mais Renovate va plus loin sur l’auto-merge conditionnel : fusionner automatiquement une mise à jour de version mineure ou de patch si la CI passe, sans intervention humaine, tout en gardant les montées de version majeure soumises à review.
{
"packageRules": [
{
"matchUpdateTypes": ["patch", "minor"],
"automerge": true
}
]
}Cette automatisation partielle est ce qui rend la maintenance des dépendances réellement soutenable à l’échelle : sans elle, même un outil qui détecte tout finit par générer une pile de PR jamais traitées, ce qui revient au même problème que l’absence totale d’outillage.
La sécurité, le vrai enjeu derrière l’automatisation
Une mise à jour de dépendance en retard n’est pas qu’une question de fraîcheur : c’est une fenêtre d’exposition à une vulnérabilité déjà corrigée en amont mais jamais intégrée localement. Les deux outils intègrent une détection de vulnérabilités connues (via GitHub Advisory Database) et peuvent prioriser ces mises à jour de sécurité au-dessus des mises à jour de routine, un signal à traiter différemment d’une simple montée de version mineure.
À retenir
Dependabot offre une intégration native GitHub et une configuration minimale, au prix d’un volume de PR potentiellement élevé sur un dépôt actif. Renovate expose une configuration plus riche (regroupement, auto-merge conditionnel par type de mise à jour) qui rend l’automatisation soutenable à plus grande échelle, au prix d’un investissement de configuration initial plus lourd. Le choix dépend surtout du volume de dépendances et de la tolérance à gérer plusieurs PR distinctes, un arbitrage qui s’inscrit dans la même logique que l’industrialisation d’une chaîne CI/CD.