Les mises à jour de version de Dependabot prennent en charge Agent Package Manager : seulement les dépendances git avec référence dans apm.yml, pas de mises à jour de sécurité, et GHES attend la 3.24

Le 3 novembre 2026, le journal des modifications de GitHub a annoncé que les mises à jour de version de Dependabot prennent désormais en charge Agent Package Manager (APM), afin de maintenir à jour les compétences, invites et instructions des agents d’IA. Dependabot ouvre des demandes de tirage pour mettre à jour les dépendances git prises en charge déclarées dans apm.yml, et régénère apm.lock.yaml lorsqu’il existe. Le journal précise que cette prise en charge couvre les mises à jour de version, pas les mises à jour de sécurité. Cette prise en charge d’APM ne crée pas de demande de mise à jour de sécurité ; les sources ne permettent pas de conclure si des alertes de sécurité sont possibles pour les dépendances APM. Dependabot vérifie les nouvelles versions des dépendances prises en charge selon le calendrier choisi.

L’activation est simple : ajouter une entrée apm à .github/dependabot.yml, indiquer le répertoire qui contient apm.yml et choisir un calendrier de mise à jour. Côté disponibilité, la prise en charge d’APM est généralement disponible sur github.com pour tous les forfaits GitHub et le sera dans GitHub Enterprise Server 3.24. Les entreprises auto-hébergées ne peuvent donc pas encore l’utiliser, et le moment dépend de leur rythme de mise à niveau.

Le journal tient en quelques phrases ; le détail se trouve dans la section APM de la documentation GitHub, plus stricte. Dependabot met à jour les entrées sous dependencies.apm et devDependencies.apm, et la manière dépend de l’épinglage. Une dépendance épinglée sur une balise SemVer passe à la dernière balise SemVer, balises simples ou balises portant le nom du paquet, ces dernières devant commencer par le nom du paquet, c’est-à-dire le nom du dépôt ou le dernier composant du chemin d’un paquet virtuel. Une dépendance épinglée sur un SHA de commit passe au commit de la dernière balise de version annotée et non préliminaire, et le nom de la balise est ajouté en commentaire. Une dépendance épinglée sur une branche passe au dernier commit de la branche ; seul apm.lock.yaml change alors, car le manifeste nomme toujours la branche, et un apm.lock.yaml existant est requis. Si le dépôt a un apm.lock.yaml, Dependabot le régénère en exécutant apm lock, mais n’en crée pas s’il n’existe pas.

La documentation donne des exemples concrets qui facilitent la vérification des règles. Une dépendance écrite octo-org/octo-skills#v1.0.0 passe à la dernière balise SemVer. Une balise portant le nom du paquet ressemble à octo-org/octo-skills/skills/review#review-v1.4.0, où la balise commence par le nom du paquet review. Une dépendance écrite octo-org/octo-skills# suivie d’un SHA de 40 caractères passe au commit de la dernière balise de version annotée et reçoit un commentaire du type # v1.4.0. Une dépendance écrite octo-org/octo-skills#main passe au dernier commit de main. À l’inverse, octo-org/octo-skills sans référence, ./my-package comme chemin local et une entrée avec une URL de clonage http:// figurent toutes dans la liste des exclusions. Comparer chaque forme utilisée dans votre manifeste à cette liste est plus fiable que de se fier aux quelques phrases du journal.

Voici notre lecture, pas celle de la documentation : le style d’épinglage décide de la facilité de relecture d’une mise à jour. Une balise SemVer produit un changement lisible dans apm.yml que le relecteur peut comparer aux notes de version. Un SHA de commit apporte la reproductibilité, et le commentaire de balise ajouté par Dependabot indique au relecteur à quelle version correspond le commit. Une équipe qui veut des mises à jour automatiques d’instructions d’agents peut donc préférer ces deux styles, et réserver l’épinglage sur branche aux dépendances auxquelles elle fait déjà pleinement confiance, car le relecteur n’en tire presque aucun signal. Si les règles de l’équipe exigent un numéro de version traçable pour chaque changement, les balises de version annotées conviennent mieux.

La documentation liste aussi ce que Dependabot ne met pas à jour, et c’est là qu’il faut vérifier. Les entrées sous forme d’objet (tables avec git, registry, id ou path) et les entrées mcp sont ignorées. Le sont aussi les entrées sans référence, comme un simple nom de dépôt, les chemins locaux, les entrées hébergées sur Azure DevOps, celles qui utilisent une URL de clonage http:// ou git://, celles écrites en scalaires de bloc YAML ou en chaînes entre guillemets avec séquences d’échappement, et les SHA de commit abrégés. Les entrées abrégées sont ignorées lorsque le manifeste définit registries.default, mais celles qui ont une URL de clonage explicite restent mises à jour. Les dépôts privés sont pris en charge par des registres git configurés dans dependabot.yml.

En pratique, toutes les dépendances APM ne seront pas suivies automatiquement. Beaucoup d’équipes n’écrivent que le nom du dépôt sans référence, ou citent des paquets de compétences partagés par chemin local ; ces entrées sont ignorées sans qu’aucune demande de tirage n’apparaisse. Après activation, consultez une fois le journal d’exécution de Dependabot pour confirmer que les dépendances importantes sont reconnues, au lieu de croire qu’une entrée configurée signifie une couverture complète.

Un dernier point relève de notre jugement, pas du journal. Compétences, invites et instructions sont du texte que les agents exécutent, donc les mettre à jour change leur comportement. Le journal ne parle ni de revue ni de contrôles de confiance : il est prudent de relire ces demandes de tirage à la main comme des changements de code, surtout pour les dépendances épinglées sur une branche, car la mise à jour ne change que le fichier de verrouillage et le manifeste ne montre aucune différence.