Dependabot automatise la gestion des dépendances

Dependabot est le service de GitHub qui surveille les dépendances de votre dépôt et ouvre une pull request dès qu'une version plus récente, ou un correctif de sécurité, existe. Il vous évite de suivre à la main chaque bibliothèque, et laisse l'humain décider de ce qui est fusionné. Ce guide s'adresse aux développeurs et aux Ops qui hébergent leur code sur GitHub. Il explique ce que Dependabot fait, l'active par le fichier dependabot.yml, montre comment examiner et fusionner ses pull requests, puis comment lui donner accès à un registre privé.

Ce que vous allez apprendre

• Distinguer les alertes, les mises à jour de sécurité et les mises à jour de versions
• Activer Dependabot sur un dépôt avec un fichier dependabot.yml
• Examiner une pull request de Dependabot et la fusionner
• Automatiser la fusion des mises à jour à faible risque
• Donner à Dependabot l'accès à un registre privé sans exposer de secret

Prérequis

Il vous faut un dépôt GitHub sur lequel vous avez le droit d'écrire, et un projet qui déclare ses dépendances dans un fichier reconnu par un gestionnaire de paquets (package.json pour npm, requirements.txt pour pip, pom.xml pour Maven, etc.). Vous devez savoir ce qu'est une pull request (PR) : une demande de fusion d'une branche dans une autre, relue avant d'être acceptée. Le format YAML sert à la configuration, mais aucun outil n'est à installer : Dependabot tourne chez GitHub.

Qu'est-ce que Dependabot ?

Dependabot est né comme un outil indépendant, conçu pour maintenir les dépendances à jour sans effort, un travail fastidieux que beaucoup de projets négligent. GitHub l'a acquis en 2019 et l'a intégré à sa plateforme, où il est gratuit pour les dépôts publics comme pour les dépôts privés. Son principe n'a pas changé : il compare vos dépendances aux versions publiées et propose les écarts sous forme de pull requests.

Une dépendance obsolète est un risque concret : les failles connues de vos bibliothèques sont publiques et exploitées. Les garder à jour réduit cette exposition, et toute la chaîne d'approvisionnement de votre code en profite (voir la gestion des dépendances).

Quelles sont les trois fonctions de Dependabot ?

Dependabot regroupe trois fonctions qu'on confond souvent, car elles s'activent à des endroits différents. Les distinguer évite de chercher dans dependabot.yml un réglage qui se trouve ailleurs.

Fonction	Ce qu'elle fait	Où l'activer
Dependabot alerts	Vous prévient qu'une dépendance porte une faille connue	Paramètres du dépôt, section Advanced Security
Dependabot security updates	Ouvre une PR qui corrige une dépendance vulnérable	Paramètres du dépôt, section Advanced Security
Dependabot version updates	Ouvre une PR à chaque nouvelle version, vulnérable ou non	Fichier .github/dependabot.yml

Glissez pour voir

Les mises à jour de sécurité n'ont donc pas besoin de dependabot.yml : elles répondent à une alerte. Les mises à jour de versions sont celles que ce fichier pilote, et c'est l'objet des sections suivantes.

Comment activer les mises à jour de versions ?

Il suffit d'ajouter un fichier nommé dependabot.yml dans le dossier .github à la racine du dépôt. Il déclare, pour chaque gestionnaire de paquets, où chercher les dépendances et à quelle fréquence vérifier. Voici une configuration minimale pour un projet npm :

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"

Chaque clé répond à une question précise :

• package-ecosystem : le type de gestionnaire de paquets (npm pour JavaScript, pip pour Python, maven pour Java, docker pour les Dockerfiles, github-actions pour les workflows, etc.).
• directory : le dossier qui contient le fichier de dépendances ; "/" désigne la racine du dépôt.
• schedule.interval : la fréquence de vérification, "daily", "weekly" ou "monthly".

Après avoir validé et poussé le fichier, Dependabot analyse le dépôt et ouvre ses premières pull requests. Pour vérifier qu'il a bien démarré, ouvrez l'onglet Insights du dépôt, puis Dependency graph et Dependabot : la liste des vérifications effectuées s'y affiche, avec leurs erreurs éventuelles.

Faut-il surveiller aussi les actions GitHub ?

Oui : un workflow dépend d'actions, qui sont des dépendances comme les autres. Il suffit d'ajouter une entrée github-actions à la liste updates. Dependabot met alors à jour les actions épinglées sur un SHA de commit, comme le détaille Épingler les actions par SHA :

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "weekly"

Comment limiter le bruit des pull requests ?

Trois options calibrent ce que Dependabot vous propose. ignore exclut une dépendance ou une plage de versions, par exemple quand une migration est planifiée mais pas encore faite. open-pull-requests-limit plafonne le nombre de PR ouvertes en même temps, ce qui évite de noyer l'équipe. target-branch choisit la branche visée par les PR, par exemple develop si l'équipe y intègre avant la mise en production.

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    open-pull-requests-limit: 5
    target-branch: "develop"
    ignore:
      - dependency-name: "express"
        versions: ["5.x"]

Ici, Dependabot ouvre au plus cinq PR sur la branche develop et ne propose aucune version 5.x d'express. Utilisez ignore avec parcimonie : une version ignorée est une version dont vous ne suivez plus les correctifs.

Comment examiner et fusionner une pull request de Dependabot ?

Quand une dépendance doit changer, Dependabot ouvre une pull request qui modifie le fichier de dépendances. Elle contient de quoi décider sans aller chercher ailleurs.

Chaque PR de Dependabot inclut :

• Description de la mise à jour : la version actuelle et la version proposée de la dépendance.
• Motif : si la mise à jour corrige une vulnérabilité, la PR cite la faille, avec un lien vers l'avis de sécurité GitHub (GitHub Security Advisories) ou la CVE.
• Notes de version : un lien vers le changelog de la dépendance, pour mesurer l'impact avant de fusionner.
• Résultat de vos tests : si le dépôt a un workflow de CI, GitHub l'exécute sur la PR comme sur n'importe quelle autre.

Sans CI, la dernière ligne est vide : la PR ne vous dit alors rien de la compatibilité, et c'est à vous de tester.

Comment juger la pertinence de la mise à jour ?

Regardez d'abord le numéro de version. Une mise à jour mineure ou de correctif (2.4.1 vers 2.4.2 ou 2.5.0) ajoute peu de risque. Une mise à jour majeure (2.x vers 3.x) peut changer le comportement de la bibliothèque et demander des ajustements dans votre code. Lisez ensuite le changelog : pour une dépendance critique, vérifiez quelles méthodes ou quels paramètres ont été ajoutés ou retirés.

Quand tester la mise à jour en local ?

Pour une mise à jour critique ou majeure, ou quand le dépôt n'a pas de tests automatisés complets, testez avant de fusionner :

1. Récupérez la branche de la PR créée par Dependabot.
2. Lancez vos tests locaux pour repérer une régression.
3. Vérifiez le comportement fonctionnel attendu de l'application.

Que faire en cas de conflit ?

Si le dépôt a changé entre-temps, notamment sur le même fichier de dépendances, la PR peut entrer en conflit. Le plus simple est de commenter @dependabot rebase dans la PR : Dependabot la reconstruit sur l'état actuel de la branche. À défaut, résolvez le conflit avec l'éditeur de GitHub ou en local, comme pour toute autre PR.

Comment fusionner la pull request ?

Une fois la PR vérifiée, GitHub propose, selon les réglages du dépôt, les trois modes de fusion habituels. Merge commit garde un historique détaillé avec un commit de fusion. Squash and merge réduit la PR à un seul commit, pour un historique plus lisible. Rebase and merge rejoue les commits sur la branche cible et donne un historique linéaire. Choisissez celui de votre équipe ; la dépendance est mise à jour dès la fusion.

Comment fusionner automatiquement les mises à jour à faible risque ?

Dependabot ne fusionne rien tout seul, et dependabot.yml n'a aucune option d'auto-merge. La fusion automatique se règle côté GitHub, en trois temps. Dans les paramètres du dépôt, activez Allow auto-merge. Protégez ensuite la branche en exigeant des vérifications obligatoires : l'auto-merge attend qu'elles soient vertes. Enfin, un petit workflow active l'auto-merge sur les PR de Dependabot qui ne sont pas des mises à jour majeures :

name: Auto-merge Dependabot
on: pull_request

permissions: {}

jobs:
  automerge:
    if: github.event.pull_request.user.login == 'dependabot[bot]'
    runs-on: ubuntu-24.04
    permissions:
      contents: write
      pull-requests: write
    steps:
      - name: Lire les métadonnées de la mise à jour
        id: metadata
        uses: dependabot/fetch-metadata@25dd0e34f4fe68f24cc83900b1fe3fe149efef98 # v3.1.0
        with:
          github-token: ${{ secrets.GITHUB_TOKEN }}

      - name: Activer l'auto-merge des correctifs et des mises à jour mineures
        if: contains(fromJSON('["version-update:semver-minor","version-update:semver-patch"]'), steps.metadata.outputs.update-type)
        run: gh pr merge --auto --squash "$PR_URL"
        env:
          PR_URL: ${{ github.event.pull_request.html_url }}
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}

L'action dependabot/fetch-metadata lit le type de mise à jour dans sa sortie update-type, qui vaut version-update:semver-patch, version-update:semver-minor ou version-update:semver-major. Le second pas n'agit que sur les deux premiers, et la PR est fusionnée quand vos vérifications obligatoires passent. Réservez ce mode aux dépendances bien couvertes par des tests : une fusion automatique sans tests transforme Dependabot en risque. L'action de ce workflow est épinglée sur un SHA, comme l'explique Maintenir des actions épinglées par SHA.

Comment donner à Dependabot l'accès à un registre privé ?

Si vos paquets viennent d'un registre privé (npm, Docker, Maven, etc.), Dependabot doit s'y authentifier. Les informations d'accès se déclarent dans la section registries de dependabot.yml, puis chaque entrée de updates cite les registres qu'elle utilise. L'exemple suivant donne accès à un Artifactory pour un projet Gradle :

version: 2
registries:
  gradle-artifactory:
    type: maven-repository
    url: https://acme.jfrog.io/artifactory/my-gradle-registry
    username: octocat
    password: ${{secrets.MY_ARTIFACTORY_PASSWORD}}
updates:
  - package-ecosystem: "gradle"
    directory: "/"
    registries: "*"
    schedule:
      interval: "monthly"

• type : le type de registre, par exemple maven-repository, npm-registry ou docker-registry.
• url : l'adresse du registre privé.
• username, password ou token : les identifiants, selon ce que le type de registre accepte. Ils ne s'écrivent jamais en clair : la syntaxe ${{secrets.NOM}} les lit dans les secrets de Dependabot.
• registries: "*" : autorise cette entrée à utiliser tous les registres déclarés ; vous pouvez aussi les lister un par un.

Le secret MY_ARTIFACTORY_PASSWORD doit exister, et à un endroit précis : Dependabot lit ses propres secrets, distincts de ceux de GitHub Actions. Un secret créé seulement côté Actions reste invisible pour lui.

1. Dans les paramètres du dépôt, ouvrez Secrets and variables, puis Dependabot.
2. Cliquez sur New repository secret.
3. Créez un secret par identifiant nécessaire, avec le nom cité dans dependabot.yml (ici MY_ARTIFACTORY_PASSWORD).

Pour un registre de production, utilisez un compte de lecture seule, dédié à Dependabot : si le secret fuit, il ne permet de rien publier.

Que faire quand Dependabot ne fait pas ce qu'on attend ?

Quand rien ne se passe, l'onglet Insights, Dependency graph, Dependabot est le premier endroit à regarder : il affiche le journal de chaque vérification. Le tableau ci-dessous couvre les cas les plus fréquents.

Symptôme	Cause probable	Solution
Aucune PR après l'ajout du fichier	dependabot.yml invalide ou mal placé	Vérifier le chemin .github/dependabot.yml et lire l'erreur dans l'onglet Dependabot
Les PR s'arrêtent à un certain nombre	open-pull-requests-limit atteint (5 par défaut pour les versions)	Fusionner ou fermer des PR ouvertes, ou relever la limite
Le registre privé répond 401 ou 403	Secret créé côté Actions, ou mauvais nom	Le recréer dans Secrets and variables, Dependabot avec le nom exact
Une PR est en conflit	La branche a avancé depuis son ouverture	Commenter @dependabot rebase

Glissez pour voir

À retenir

• Dependabot ouvre des pull requests pour mettre à jour vos dépendances ; vous gardez la décision de fusionner.
• Trois fonctions distinctes : les alertes, les mises à jour de sécurité (réglées dans les paramètres du dépôt) et les mises à jour de versions (pilotées par dependabot.yml).
• Le fichier se place dans .github/dependabot.yml ; la clé package-ecosystem accepte aussi github-actions pour les workflows.
• ignore, open-pull-requests-limit et target-branch limitent le bruit, mais une version ignorée n'est plus suivie.
• L'auto-merge ne se règle pas dans dependabot.yml : il passe par les paramètres du dépôt, des vérifications obligatoires et un workflow.
• Pour un registre privé, les identifiants vivent dans les secrets Dependabot, jamais dans le fichier ni dans les secrets Actions.

Prochaines étapes

Renovate L'alternative qui fonctionne sur GitHub, GitLab et ailleurs, avec plus de règles.

Maintenir des actions épinglées par SHA Trier la file de mises à jour sans revenir aux tags mutables.

OpenSSF Scorecard Mesurer la posture de sécurité de votre dépôt, dépendances comprises.

Gestion des vulnérabilités CVE Du triage au patch : que faire d'une alerte une fois reçue.

×

📖 Voir la documentation →