Le scheduler cron de Hermes Agent, c'est la troisième forme de travail d'agent, après le chat tour-par-tour et les boucles /goal. En mode cron, l'agent tourne sans surveillance sur un horaire, avec les résultats livrés sur la plateforme de messagerie que tu veux — ou sur toutes d'un coup via deliver=all (#21495).
Ce guide construit un job précis — un rapport du matin — et s'en sert pour expliquer comment le scheduler marche en vrai. Le même schéma sait gérer les sauvegardes nocturnes, les audits de sécurité hebdo, les pings de tour de garde, ou n'importe quoi d'autre que tu câblerais aujourd'hui avec un bash + cron fragile.
Ce qu'on construit
Chaque jour ouvré à 8 h :
- 1.Lire les mails de la nuit (depuis 17 h hier)
- 2.Tirer les notifications GitHub (issues, reviews de PR, mentions)
- 3.Vérifier l'agenda du jour sur les 4 premières heures
- 4.Résumer les trois en un seul message Telegram
S'il s'est passé quelque chose d'important, le message est détaillé. Si rien ne s'est passé, le message tient en une phrase : « Nuit calme. Agenda léger jusqu'à 11 h. »
Étape 1 : définir le job
hermes cron add te fait passer par toutes les étapes. La CLI te demande : un nom, un horaire, la description du job (langage naturel), et les cibles de livraison.
$ hermes cron add
Name: daily-morning-report
Schedule (cron expression or natural language): 0 8 * * MON-FRI
Description: |
Read overnight email (since 5 PM yesterday).
Pull GitHub notifications via the github skill.
Check today's calendar via google-calendar for the first 4 hours.
Summarize all three into one Telegram message.
Be brief when nothing important happened.
Delivery: telegram
0 8 <em class="italic text-slate-200"> </em> MON-FRI est de la syntaxe cron standard : minute 0, heure 8, n'importe quel jour du mois, n'importe quel mois, lundi à vendredi. Hermes accepte la syntaxe cron mais aussi des tournures en langage naturel plus libres, du genre « every weekday at 8 AM ».
Étape 2 : ce qui tourne à 8 h
Au prochain jour ouvré à 8 h, Hermes lance une session d'agent isolée avec :
- •La description du job comme message utilisateur d'ouverture
- •Les skills que l'agent décide d'appeler (
email,github,google-calendar) - •Un hook de livraison qui pipe la réponse finale vers Telegram
Pas de contexte persistant, pas d'utilisateur qui tape. L'agent lit la description, appelle les skills, rédige un message, l'envoie. Typiquement bouclé en 15–30 secondes.
La sortie apparaît dans Telegram comme un message de ton bot Hermes. Si le job a pris plus de temps que d'habitude ou s'est cogné à une erreur, tu reçois aussi un message d'erreur sur le même canal.
Étape 3 : deliver=all — éclatement vers toutes les plateformes
Par défaut, la livraison va vers une seule plateforme — celle que tu as précisée à cron add. Si tu veux que le rapport atterrisse partout où tu peux te trouver, tu mets :
hermes cron edit daily-morning-report --deliver all
Maintenant le message va vers toutes les plateformes de messagerie connectées en même temps — Telegram, Discord, Slack, WhatsApp, Signal, LINE, SimpleX, ce que tu as configuré. v0.14.0 a câblé la livraison par plateforme pour cron explicitement (#21495).
Quand c'est utile : tu veux la garantie de voir le message peu importe l'app dans laquelle tu te trouves.
Quand c'est exagéré : tu ne regardes qu'une seule plateforme le matin. Prends celle-là.
Étape 4 : voir ce qui est planifié
hermes cron list
Affiche tout ce qui est planifié, la prochaine exécution, le statut de la dernière. v0.14.0 a ajouté la recherche par nom pour les opérations sur les jobs (#26231), donc tu peux référencer les jobs par nom plutôt que par ID :
hermes cron logs daily-morning-report --last 5
hermes cron disable daily-morning-report
hermes cron run-now daily-morning-report # déclencher maintenant, hors planning
Ce qui se passe quand un job tombe
Les jobs cron tournent dans leur propre session sandbox (mêmes backends que le Hermes interactif — voir l'article sur les backends de sandbox). Si un appel de skill rate, l'agent reçoit l'erreur et soit réessaie, soit la remonte.
Si le job entier crashe (l'agent lui-même tombe en erreur), Hermes te notifie sur ta plateforme de messagerie par défaut avec l'erreur et un lien vers les logs. Le travail de durabilité de session de v0.13.0 fait qu'un redémarrage de gateway ne perd pas les livraisons cron en attente — la déduplication se fait via claim atomique avec rewind en cas d'échec (#23401).
Quelques vrais jobs utiles
Voilà des patterns que des gens lancent vraiment :
Vérification de sauvegarde nocturne. Cron à 3 h : lister les snapshots de backup, vérifier que celui d'aujourd'hui existe et n'est pas vide, échouer bruyamment s'il manque. deliver=all pour te réveiller avec l'échec s'il y en a un.
Audit hebdomadaire de sécurité. Cron dimanche 22 h : tirer les advisories de dépendances, scanner les CVE connus dans tes lockfiles, résumer les nouvelles vulnérabilités. Le vérificateur d'advisories de chaîne d'approvisionnement de v0.14.0 (#24220) rend ça plus propre que des scripts maison.
Passage de garde. Cron vendredi 17 h : lire les pages de la semaine, écrire un paragraphe de passage à la garde de la semaine suivante. Livraison vers le canal Slack partagé.
Watchers (le skill v0.14.0, #21881). Polling sur un flux RSS, un endpoint HTTP JSON, ou un repo GitHub pour les changements ; ne notifie que quand quelque chose a changé. Combiné avec cron, ça devient « préviens-moi quand X change », une des primitives d'automatisation les plus sous-utilisées.
Où vont les logs
hermes cron logs daily-morning-report
Par défaut, les 10 dernières exécutions. Chacune affiche : timestamp, durée, skills appelés, ce qui a été livré, ce qui a raté s'il y a eu un raté. Les logs vivent sous ~/.hermes/cron/logs/ et tournent automatiquement.
Pourquoi ça bat un script shell
Tu peux écrire le même rapport quotidien en bash + cron + curl vers Telegram + peut-être un petit appel LLM. Beaucoup de gens l'ont fait.
Pourquoi cron-sur-un-agent est intéressant :
- 1.La description du job est la spec. Pas de code à maintenir. Tu changes « 4 premières heures » en « 6 premières heures » — tu édites la description, pas de redéploiement.
- 2.Les skills se composent. Ajouter « regarde aussi Linear pour de nouveaux tickets » est une phrase dans la description. Avec un script shell, c'est un nouveau client API.
- 3.La livraison est découplée.
deliver=allveut dire que tu n'écris pas 5 webhooks différents pour 5 apps de chat différentes. La gateway parle déjà les 22. - 4.Les erreurs sont debuggables. Quand un job échoue, l'agent te dit ce qu'il a essayé et pourquoi ça n'a pas marché, en français. Les scripts bash te donnent un exit code 1.
Ça ne fait pas du cron-sur-agent la bonne réponse partout — pour des jobs qui doivent être déterministes à 100 % et boucler en 30 ms, un script shell reste meilleur. Mais pour « fais quelque chose de réfléchi à cette heure et raconte-moi », cron-sur-Hermes est l'outil le plus propre de la boîte.