Hermes Agent + GitHub Actions : automatisez vos dépôts

Vos Dépôts Ont Besoin d'un Assistant, Pas d'un Tableau de Bord de Plus

Si vous maintenez ne serait-ce que deux ou trois dépôts GitHub, vous avez sans doute remarqué le même schéma : l'essentiel du travail n'est pas d'écrire du code. C'est trier les échecs de CI, jeter un œil aux diffs de PR que vous avez ouverts hier, fermer les issues dormantes que personne ne touchera et vous envoyer un résumé du lundi matin sur ce qui s'est passé pendant le week-end.

C'est la partie de la maintenance de dépôt où l'IA est vraiment bonne. Pas le code créatif, mais le travail routinier d'entretien. Et Hermes Agent, avec son ordonnanceur cron, son écouteur de webhooks et son accès natif à la CLI GitHub, a été conçu exactement pour ça.

Ce guide montre trois recettes concrètes que vous pouvez copier dans votre installation Hermes dès aujourd'hui. Chacune résout un problème réel que vous ressentez probablement chaque semaine.

• Un agent de triage des échecs de CI qui publie un diagnostic sur la PR quelques minutes après le passage au rouge
• Un digest nocturne des PR qui arrive sur votre Telegram ou Discord à 21h
• Un triage hebdomadaire des issues dormantes qui rédige un commentaire de fermeture pour les issues que personne n'a touchées depuis 60 jours

À la fin, vous devriez pouvoir mettre en place n'importe laquelle de ces recettes en une seule session. Si ce n'est pas encore fait, Lancez-vous avec Hermify vous donne une instance Hermes gérée avec toute la plomberie GitHub déjà câblée.

Pourquoi Hermes Pour l'Automatisation de Dépôts

Il existe énormément de GitHub Actions et de bots du Marketplace préfabriqués qui font des tâches unitaires : un pour la revue de code, un pour les issues dormantes, un pour les notes de version. Le problème quand on les assemble, c'est qu'aucun ne se souvient de rien. Chaque exécution part de zéro. Chacun a besoin de sa propre configuration. Chacun parle à un service externe différent.

Hermes est différent sur trois points utiles :

• Un agent, plusieurs skills. Une seule instance Hermes peut relire les PR, trier les issues, exécuter des cron jobs et répondre à des questions ponctuelles via Telegram. Vous le configurez une fois, vous le formez une fois, il s'améliore une fois.
• Mémoire persistante. Quand Hermes a signalé un test instable sur la PR #312 la semaine dernière, il s'en souvient quand le même test échoue sur la PR #340 aujourd'hui. Ce type de contexte, la plupart des Actions du Marketplace ne peuvent pas le garder.
• Cron en français courant. Vous n'écrivez pas 0 9 * * 1-5. Vous écrivez "chaque jour ouvré à 9h envoie-moi un digest des PR" et Hermes génère la skill et la planification pour vous.

Pour une vue plus profonde des primitives sous-jacentes, lisez notre article sur la mémoire et les skills de Hermes.

Recette 1 : Agent de Triage des Échecs de CI

Problème. Un test échoue sur une PR. Vous voyez la croix rouge. Vous cliquez dans Actions, faites défiler le log, comprenez quel step a explosé, décidez si c'est un faux positif ou une vraie régression, et vous écrivez un commentaire. Ce va-et-vient prend de 5 à 15 minutes à chaque fois. Sur une semaine chargée avec plusieurs dépôts, ça fait des heures.

Ce que fait Hermes. Un webhook se déclenche quand check_run se termine avec conclusion: failure. Hermes récupère le log du job en échec via la CLI GitHub, identifie le step en échec et la cause racine la plus plausible, et publie un commentaire sur la PR associée avec un diagnostic d'un paragraphe et une prochaine étape suggérée (relancer, corriger localement, marquer comme instabilité connue).

Plan d'installation.

1. Dans la config Hermes, ajoutez un abonnement au webhook check_run.completed pour les dépôts qui comptent.
2. Ajoutez une skill nommée github-ci-triage avec un prompt du genre : "Récupère le log du job en échec avec gh run view --log-failed. Identifie le step en échec et la première ligne de stack trace ou d'erreur. Si l'erreur correspond à un motif d'instabilité connu en mémoire, étiquette le commentaire comme 'probablement instable'. Sinon, résume la cause racine en un paragraphe et propose la plus petite correction possible."
3. Pointez le handler du webhook vers cette skill et dites-lui de livrer le résultat comme un commentaire sur la PR via gh pr comment.

À la première exécution, lisez le commentaire rapidement et donnez-lui un pouce vers le haut (Hermes le stocke en mémoire comme un bon diagnostic confirmé) ou corrigez-le. Au bout de quelques cycles les diagnostics s'affinent parce que Hermes apprend votre codebase, les particularités de votre CI et quels fichiers de test sont chroniquement instables.

Recette 2 : Digest Nocturne des PR

Problème. Vous avez entre 3 et 15 PR ouvertes à tout moment, entre projets personnels, dépôts pro et projets OSS que vous maintenez. Le vendredi après-midi, vous n'avez aucune idée de celles qui ont bougé, celles qui sont bloquées sur vous et celles qui sont bloquées sur quelqu'un d'autre.

Ce que fait Hermes. Chaque jour ouvré à 21h, heure de Madrid (ou le fuseau que vous configurez), Hermes lance la CLI GitHub pour lister les PR ouvertes, les regroupe par état (en attente de revue, en attente de CI, brouillon, mergeable) et livre un digest formaté sur votre Telegram ou Discord.

Un digest ressemble à ça :

Digest PR - 18 mai 2026

EN ATTENTE DE VOUS (3) :
- albertoaquinodev/hermes-up #421 "fix: revalidate blog index" - revue demandée il y a 4j
- albertoaquinodev/hermes-up #418 "feat: BYOK provider snapshot" - votre revue est le dernier blocage
- nousresearch/hermes-agent #2104 "docs: add cron examples" - petite PR docs

EN ATTENTE D'AUTRES (2) :
- albertoaquinodev/hermes-up #420 - bloquée sur le reviewer depuis 2j
- nousresearch/hermes-agent #2099 - CI rouge, l'auteur est dessus

MERGEABLES MAINTENANT (1) :
- albertoaquinodev/hermes-up #422 - tout vert, prêt à merger

Plan d'installation.

1. Créez un cron job avec le prompt : "Chaque jour ouvré à 21:00 liste les PR ouvertes dans albertoaquinodev/* et nousresearch/* avec gh pr list. Regroupe-les par statut. Envoie sur mon Telegram."
2. Hermes traduit la planification en langage naturel vers l'expression cron 0 21 * * 1-5 et enregistre la skill.
3. Connectez une cible de livraison Telegram ou Discord si ce n'est pas déjà fait.

L'ensemble prend environ 10 minutes. Une fois en route, ça coûte entre 0,02 $ et 0,05 $ par exécution nocturne sur Sonnet, selon le nombre de PR ouvertes.

À titre de comparaison, l'équivalent monté avec des Actions et des apps Slack cousues ensemble prend un week-end et casse à chaque changement d'API GitHub.

Recette 3 : Triage Hebdomadaire des Issues Dormantes

Problème. Les issues s'accumulent. Certaines sont corrigées dans une PR parallèle et personne ne les ferme. Certaines sont signalées, l'utilisateur disparaît et l'issue reste ouverte indéfiniment. Certaines sont des doublons. Faire le tour du backlog à la main est le genre de tâche que personne ne fait.

Ce que fait Hermes. Chaque lundi matin, Hermes liste toutes les issues sans activité depuis 60 jours, lit le corps et les commentaires, choisit l'une des quatre actions, et (selon l'autonomie que vous lui donnez) rédige un commentaire à approuver ou publie directement.

Les quatre actions :

• Fermer comme résolu. Le bug référencé semble corrigé dans un commit ou une version récente. Hermes publie un commentaire de fermeture poli avec le commit en lien.
• Fermer comme dormant. On a demandé à l'auteur plus d'infos il y a plus de 30 jours et il n'a jamais répondu.
• Monter la priorité. L'issue reste pertinente, a des pouces levés d'autres utilisateurs et mérite un changement de label.
• Convertir en discussion. L'issue est une demande de fonctionnalité qui appartient à Discussions, pas à Issues.

Plan d'installation.

1. Créez un cron job : "Chaque lundi à 10h, fais le triage des issues dormantes dans mes dépôts. Rédige les commentaires mais ne les publie pas encore."
2. Hermes génère une skill qui exécute gh issue list --state open --search 'updated:<2026-03-18' (la date est calculée à l'exécution), lit chaque issue et décide de l'action.
3. Les brouillons arrivent dans un seul message Telegram ou, si vous préférez, sous forme de résumé style PR à relire.

Après quelques semaines d'exécutions supervisées, vous pouvez basculer en mode auto-publication (Hermes agit directement) ou rester en mode brouillon indéfiniment. Dans tous les cas, votre backlog cesse de grossir.

Où Hermes S'Arrête Et Où Vous Reprenez

La version honnête de cette histoire est que Hermes est excellent pour les 80 % routiniers de la maintenance de dépôt, et vous voulez toujours un humain pour les 20 % qui demandent du jugement : décider si un test instable est en fait un vrai bug, annoncer une rupture d'API, dire à un utilisateur que sa demande de fonctionnalité est hors périmètre.

Tout l'intérêt de l'installation ci-dessus est de vous libérer des 80 % pour vous laisser le temps des 20 %. Pour une autre déclinaison de la même idée, lisez notre article sur l'auto-hébergement d'un agent IA avec Docker, qui couvre la partie infrastructure pour faire tourner Hermes sur la durée.

Essayez Cette Semaine

Si vous auto-hébergez déjà Hermes, les trois recettes ci-dessus représentent environ une soirée de travail. Sinon, le chemin le plus court est Lancez-vous avec Hermify - une instance Hermes gérée arrive avec la CLI GitHub, l'écouteur de webhooks et l'ordonnanceur cron déjà configurés. Vous ajoutez votre token de dépôt et vous écrivez la phrase cron en langage naturel.

L'installation type baby-sitter de dépôts est le genre de chose qui vous fait dire qu'on aurait dû la construire plus tôt. Puis vous vous rappelez : l'essentiel de l'outillage "IA pour les devs" est pensé pour les 20 % de code à écrire, pas pour les 80 % d'entretien. Hermes vise les 80 %.

Sources

• Hermes Agent GitHub Integration
• How to Use Hermes Agent with GitHub Repositories
• Tutorial: GitHub PR Review Agent
• Automated GitHub PR Comments with Webhooks
• Hermes Agent Cron Jobs in Plain English: GitHub Backup
• Scheduled Tasks (Cron)
• GitHub Agentic Workflows Technical Preview