guides

Les deux outils font la même chose visible : ils surveillent vos dépendances, repèrent une nouvelle version et ouvrent une pull request. Si c'était tout, le choix serait sans importance. Il compte à cause de ce qui se passe après, quand vingt de ces pull requests sont ouvertes, et les deux outils prennent des positions opposées sur ce problème.

Dependabot est celui que vous avez déjà. Il est intégré à GitHub, ne coûte rien, et l'activer tient en un fichier `.github/dependabot.yml` d'environ six lignes. Pas de compte à créer, pas d'application à installer, pas de runner à héberger. Pour un dépôt qui n'a aujourd'hui aucune automatisation, c'est le chemin le plus court pour en avoir une.

Renovate est celui vers lequel on passe quand les pull requests deviennent le problème. Il est open source, tourne comme application hébergée, auto-hébergée ou dans votre propre CI, et fonctionne sur GitLab, Bitbucket et Azure DevOps autant que sur GitHub. Sa configuration est un moteur de règles plutôt qu'un fichier de réglages, et c'est à la fois son avantage et son coût.

La vraie ligne de partage, c'est le regroupement et le bruit. Un projet de quarante dépendances produit beaucoup de montées de version individuelles, et les relire une par une est un travail qui ressemble à de la maintenance sans en être. Dependabot a ajouté les mises à jour groupées, et elles aident. Les `packageRules` de Renovate restent nettement plus expressives : regrouper par motif de paquet, par type de mise à jour, par dossier, appliquer des calendriers différents à chaque groupe, fusionner automatiquement les correctifs des dépendances de développement tout en gardant les versions majeures pour relecture. Si votre plainte porte sur le *volume*, c'est cette expressivité que vous achetez.

La planification est la deuxième différence qu'on ressent. Renovate permet de dire quand les mises à jour peuvent apparaître (hors heures de bureau, un jour précis, au plus tant de fois) avec des règles différentes par groupe. Le calendrier de Dependabot est plus simple. Sur un petit dépôt, la simplicité est une qualité ; sur un dépôt actif, elle signifie que les PR arrivent quand elles arrivent.

Le Dependency Dashboard est la fonctionnalité sous-estimée de Renovate. Il ouvre dans le dépôt une seule issue qui liste tout ce qu'il veut faire, y compris ce pour quoi il n'a volontairement pas ouvert de PR. Vous voyez l'état de votre dette de dépendances sur une page au lieu de le deviner depuis une boîte de réception. Rien ne lui correspond dans Dependabot.

Là où Dependabot a vraiment l'avantage : les alertes de sécurité. Sa partie mises à jour de version n'est que la moitié du produit. L'autre moitié est branchée sur la base d'avis de sécurité de GitHub et signale les dépendances vulnérables sous forme d'alertes, avec des mises à jour de sécurité activables indépendamment des mises à jour de version. Renovate sait aussi agir sur les vulnérabilités, mais si votre priorité est *la posture de sécurité dans GitHub*, Dependabot est la voie native et elle prend quelques minutes.

La plateforme est la réponse quand elle est la réponse. Si votre code n'est pas sur GitHub, la comparaison s'arrête là : Renovate est l'outil qui tourne là où vous êtes. Et si vous voulez des mises à jour pilotées depuis votre propre infrastructure plutôt que par une application tierce, Renovate s'auto-héberge ; cette option n'existe pas de l'autre côté.

Le coût de configuration est réel et mérite d'être dit clairement. La souplesse de Renovate vient d'un schéma assez vaste pour que la plupart des gens partent d'un preset et l'ajustent. Comptez un après-midi pour qu'il se comporte comme vous le voulez, et comptez y revenir. Dependabot, on le configure correctement du premier coup parce qu'il y a moins à rater. C'est un vrai argument en sa faveur, pas un lot de consolation.

Un choix par défaut raisonnable : commencez par Dependabot, surtout pour les mises à jour de sécurité. Passez à Renovate quand vous pouvez nommer précisément ce qui vous gêne : trop de PR, mauvais moment, pas de regroupement, pas sur GitHub, besoin de règles de fusion automatique. Migrer plus tard coûte peu. Configurer un moteur de règles avant d'avoir le problème qu'il résout, c'est finir par maintenir votre automatisation de dépendances au lieu de votre projet.

Quel que soit votre choix, l'outil ne fait que proposer. Ce qui vous protège vraiment, c'est ce qui a rendu ces outils possibles : un lockfile commité, pour que la version proposée par le robot soit celle que votre CI a installée, et une suite de tests assez bonne pour qu'une pull request verte veuille dire quelque chose.