Maîtriser l'automatisation Hermes avec les Cron Jobs : Des briefings quotidiens aux surveillances personnalisées

Si vous utilisez Hermes Agent et n’avez jamais touché à son planificateur cron, vous passez à côté de l’une de ses fonctionnalités les plus puissantes. Le Cron dans Hermes n’est pas un simple utilitaire « exécute ce script toutes les heures » — c’est un framework d’automatisation complet qui couvre la planification en langage naturel, les agents appuyés par des skills, les pipelines multi-jobs et les surveillances par script sans coût de token.

Dans ce guide, vous apprendrez à :

  • Planifier des tâches récurrentes et ponctuelles en langage naturel ou avec des expressions cron
  • Attacher des skills à un job pour qu’il hérite de workflows experts
  • Chaîner plusieurs jobs pour que l’un alimente le suivant (le pattern pipeline)
  • Exécuter des surveillances par script uniquement qui consomment zéro token LLM
  • Mettre en place des briefings quotidiens, des moniteurs GitHub et des vérifications de santé web prêts pour la production

Commençons par les bases.

Qu’est-ce qui rend le Cron d’Hermes différent ?

La plupart des implémentations de cron exécutent un seul script sur un minuteur. Le cron d’Hermes exécute une session complète d’agent sur un minuteur — votre prompt devient la tâche, l’agent a accès à tous ses outils (terminal, fichier, web, navigateur, délégation), et le résultat est livré sur la plateforme de chat de votre choix.

L’idée clé : Un job cron dans Hermes est « une session Hermes planifiée ». Tout ce que vous pouvez demander à Hermes dans le chat, vous pouvez le planifier pour qu’il le fasse de manière autonome.

En plus de cela, le cron d’Hermes ajoute :

  • Injection de skills — chargez un ou plusieurs skills dans la session avant l’exécution du prompt
  • Chaînage en pipeline — la sortie d’un job devient le contexte du job suivant
  • Mode sans agent — exécutez un script simple planifié, zéro token LLM, stdout livré tel quel
  • Livraison multi-plateforme — envoyez les résultats vers Telegram, Discord, Slack, email, SMS, Feishu ou toute plateforme configurée
  • Gestion complète du cycle de vie — pause, reprise, édition, déclenchement à la demande, le tout depuis le chat ou la CLI

Le planificateur s’exécute dans le démon gateway d’Hermes, avec un tick toutes les 60 secondes. Les jobs sont stockés dans ~/.hermes/cron/jobs.json et utilisent un verrou de fichier (~/.hermes/cron/.tick.lock) pour éviter les ticks superposés.

Planification de base : Trois façons de créer un job

Vous pouvez créer un job cron de trois manières. Tous les chemins mènent au même planificateur.

1. Depuis le chat avec /cron

Le moyen le plus rapide — tapez la commande slash /cron pendant une session de chat :

/cron add "every 2h" "Check server status and report any issues"
/cron add "0 9 * * *" "Summarize yesterday's commits from the project repo"
/cron add "30m" "Remind me to stand up and stretch"

Avec un skill attaché :

/cron add "every 1h" "Check feeds for new posts" --skill blogwatcher

2. Depuis la CLI autonome

La version CLI fonctionne de manière identique et est scriptable :

hermes cron create "every 2h" "Check server status"
hermes cron create "0 9 * * *" "Summarize yesterday's commits" --name "daily-summary"

Avec plusieurs skills :

hermes cron create "every 1h" "Monitor feeds and maps" \
  --skill blogwatcher \
  --skill maps \
  --name "Multi-skill watcher"

3. Par conversation naturelle

Dites simplement à Hermes ce que vous voulez :

“Every morning at 9am, check Hacker News for AI news and send me a summary on Telegram.”

Hermes utilise l’outil cronjob en interne pour tout configurer — pas de CLI, pas de syntaxe à retenir.

Référence des formats de planification

Hermes accepte quatre formats de planification :

Format Exemple Comportement
Délai relatif 30m, 2h, 1d Ponctuel, s’exécute une fois après le délai
Intervalle every 30m, every 2h, every 1d Récurrent jusqu’à suppression
Expression cron 0 9 * * * (quotidien), 0 9 * * 1-5 (jours ouvrés), 0 */6 * * * (toutes les 6h) Récurrent sur horaire fixe
Timestamp ISO 2026-12-25T09:00:00 Ponctuel à un moment futur spécifique

Vous pouvez remplacer le nombre de répétitions par défaut :

cronjob(
    action="create",
    prompt="Check mailbox for urgent messages",
    schedule="every 2h",
    repeat=5,        # exécuter 5 fois seulement, puis suppression automatique
)

Jobs Cron appuyés par des Skills

La véritable puissance commence lorsque vous attachez des skills. Un skill encode un workflow réutilisable — quand un job cron le charge, l’agent hérite de cette expertise sans que vous ayez à entasser des instructions dans le prompt.

Skill unique

cronjob(
    action="create",
    skill="blogwatcher",
    prompt="Check the configured feeds and summarize anything new.",
    schedule="0 9 * * *",
    name="Morning feeds",
)

Plusieurs skills

Les skills se chargent dans l’ordre. Le prompt devient l’instruction finale par-dessus tous les skills chargés :

cronjob(
    action="create",
    skills=["blogwatcher", "maps"],
    prompt="Look for new local events and interesting nearby places, then combine them into one short brief.",
    schedule="every 6h",
    name="Local brief",
)

Conseil pratique : Utilisez les skills pour séparer les préoccupations. Un skill « collecteur de données » récupère les données brutes ; un skill « formateur » les embellit ; un skill « livraison » les achemine. Mélangez et combinez-les sur différents jobs.

Exécution dans un répertoire de projet

Par défaut, les jobs cron s’exécutent en mode détaché — aucun CLAUDE.md ou AGENTS.md n’est chargé. Passez --workdir (CLI) ou workdir= (appel d’outil) pour faire tourner le job dans un dépôt spécifique :

hermes cron create "every 1d at 09:00" \
  "Audit open PRs, summarize CI health, and post to #eng" \
  --workdir /home/me/projects/acme

Quand workdir est défini, les fichiers de contexte du projet de ce répertoire sont injectés dans le prompt système, et tous les outils fichier/terminal utilisent ce répertoire comme base de travail.

Note de sérialisation : Les jobs avec workdir s’exécutent séquentiellement (pas dans le pool parallèle) car ils modifient l’état global du terminal du processus. Les jobs sans workdir continuent de s’exécuter en parallèle.

Avancé : Pipelines multi-jobs avec context_from

Les jobs cron s’exécutent dans des sessions isolées sans mémoire des exécutions précédentes. Mais parfois, la sortie d’un job est exactement ce dont le job suivant a besoin. Le paramètre context_from établit cette connexion automatiquement.

Le pattern Pipeline

Voici un pipeline d’actualités IA en 3 étapes — collecte, triage et livraison :

# Étape 1 : Trouver l'ID du job collecteur
cronjob(action="list")

# Étape 2 : Créer un job de triage qui reçoit la sortie du collecteur
cronjob(
    action="create",
    prompt="Read ~/.hermes/data/briefs/raw.md. Score each story 1-10 for engagement and novelty. Output top 5 to ~/.hermes/data/briefs/ranked.md.",
    schedule="30 7 * * *",
    context_from="<collector_job_id>",
    name="AI News Triage",
)

# Étape 3 : Créer un expéditeur qui reçoit la sortie du triage
cronjob(
    action="create",
    prompt="Read ~/.hermes/data/briefs/ranked.md. Write 3 tweet drafts (hook + body + hashtags).",
    schedule="0 8 * * *",
    context_from="<triage_job_id>",
    deliver="telegram:7976161601",
    name="AI News Brief",
)

Comment context_from fonctionne :

  • Quand le Job B se déclenche, Hermes lit la sortie la plus récente du Job A depuis ~/.hermes/cron/output/{job_a_id}/*.md
  • Cette sortie est automatiquement préfixée au prompt du Job B
  • La chaîne peut avoir n’importe quelle longueur : A → B → C → …
  • Vous pouvez passer un seul ID (chaîne) ou une liste d’IDs pour les patterns fan-in

Quand utiliser les pipelines :

  • Traitement multi-étapes (collecter → filtrer → formater → livrer)
  • Tâches dépendantes où l’étape N a besoin des résultats de l’étape N−1
  • Fan-out/fan-in : un job agrégateur collecte les résultats de plusieurs collecteurs

Mode sans agent : Surveillances par script uniquement

Pour les tâches récurrentes qui n’ont pas besoin d’un LLM — surveillances système classiques, alertes disque/mémoire, heartbeats, pings CI — passez no_agent=True. Le planificateur exécute votre script planifié et livre stdout directement, zéro token, zéro appel d’inférence.

Configuration CLI

hermes cron create "every 5m" \
  --no-agent \
  --script memory-watchdog.sh \
  --deliver telegram \
  --name "memory-watchdog"

Configuration pilotée par l’agent

Dites simplement à Hermes dans le chat :

“Ping me on Telegram if RAM is over 85%, every 5 minutes.”

Hermes écrit le script de vérification dans ~/.hermes/scripts/ et configure le job cron automatiquement.

Sémantique du mode sans agent

Condition Comportement
Script stdout (non vide) Livré tel quel comme message
stdout vide Tick silencieux — rien n’est envoyé (le pattern watchdog)
Sortie non nulle ou timeout Alerte d’erreur livrée (pour que les watchdogs cassés ne puissent pas échouer silencieusement)
Dernière ligne {"wakeAgent": false} Tick silencieux (même porte que les jobs LLM utilisent)

Fichiers de script :

  • .sh / .bash → s’exécute sous /bin/bash
  • Tout autre → s’exécute sous l’interpréteur Python actuel (sys.executable)
  • Doivent résider dans ~/.hermes/scripts/

Exemple concret — un script watchdog mémoire :

#!/bin/bash
# ~/.hermes/scripts/memory-watchdog.sh
THRESHOLD=85
USAGE=$(free | awk '/^Mem:/ {printf "%.0f", $3/$2 * 100}')
if [ "$USAGE" -gt "$THRESHOLD" ]; then
    echo "⚠️  RAM alert: ${USAGE}% used (threshold: ${THRESHOLD}%)"
    echo "Top processes:"
    ps aux --sort=-%mem | head -6
fi
# Si en dessous du seuil, le script ne produit pas de stdout → tick silencieux

Ce script ne produit une sortie que lorsque la mémoire dépasse 85%. Les jours calmes, il n’envoie rien — pas de spam, pas d’attention gaspillée.

Gestion du cycle de vie

Chaque job cron a un cycle de vie complet. Vous gérez tout depuis la CLI ou le chat.

Commandes CLI

hermes cron list              # Lister tous les jobs (--all pour les désactivés)
hermes cron pause my-digest   # Mettre en pause par nom ou ID
hermes cron resume my-digest  # Réactiver
hermes cron run my-digest     # Déclencher au prochain tick du planificateur
hermes cron edit my-digest --schedule "every 4h"  # Changer la planification
hermes cron edit my-digest --prompt "Revised task"
hermes cron edit my-digest --add-skill maps       # Ajouter un skill
hermes cron edit my-digest --remove-skill maps    # Supprimer un skill
hermes cron edit my-digest --clear-skills          # Supprimer tous les skills
hermes cron remove my-digest  # Supprimer complètement
hermes cron status            # Statut du planificateur
hermes cron runs my-digest --limit 20  # Historique d'exécution

Depuis le chat

/cron list
/cron pause <job_id>
/cron resume <job_id>
/cron run <job_id>
/cron edit <job_id> --schedule "every 4h"
/cron remove <job_id>

Recherche par nom : Toutes les commandes acceptent soit l’ID hexadécimal du job, soit le nom du job (insensible à la casse). Si un nom correspond à plusieurs jobs, la commande affiche les candidats pour que vous puissiez lever l’ambiguïté.

Historique d’exécution

Hermes enregistre chaque exécution cron dans ~/.hermes/cron/executions.db. Chaque tentative passe par claimed → running → l’un des statuts completed, failed ou unknown (après redémarrage du processus). Inspectez avec hermes cron runs [job-id] --limit 20.

Récupération de fournisseur et épinglage de modèle

Les jobs cron héritent de vos fournisseurs de secours configurés et de la rotation du pool de credentials. Si la clé API principale est limitée en débit, le job bascule automatiquement vers un fournisseur alternatif ou tourne vers le credential suivant du pool.

Important — comportement d’épinglage de modèle : Lorsque vous créez un job cron sans spécifier de fournisseur/modèle, Hermes capture un instantané de votre valeur par défaut globale actuelle sur le job. Si vous modifiez ultérieurement la valeur par défaut globale, le job échoue de manière sécurisée — il saute l’exécution et vous alerte pour épingler explicitement le fournisseur/modèle. Cela empêche les jobs non surveillés de basculer silencieusement vers un fournisseur payant ou un modèle différent :

# Épingler un modèle spécifique à un job
cronjob(
    action="update",
    job_id="<job_id>",
    provider="openrouter",
    model="anthropic/claude-sonnet-4",
)

Pour les exécutions non surveillées, hermes setup --portal (Nous Portal OAuth) est l’option la plus fluide — le rafraîchissement OAuth est automatique.

Règle de sécurité : Les sessions exécutées par cron ne peuvent pas créer de nouveaux jobs cron. Hermes désactive les outils de gestion de cron pendant les exécutions cron pour éviter les boucles de planification incontrôlées.

Configuration de livraison

Ciblage par plateforme

Lors de la planification d’un job, spécifiez où le résultat doit aller via le paramètre deliver :

# Livrer vers Telegram
cronjob(action="create", ..., deliver="telegram")

# Livrer vers un canal Discord spécifique
cronjob(action="create", ..., deliver="discord:#engineering")

# Livrer vers plusieurs plateformes
cronjob(action="create", ..., deliver="telegram,discord")

# Diffuser vers tous les canaux principaux connectés
cronjob(action="create", ..., deliver="all")

# Livrer vers l'origine plus tous les canaux
cronjob(action="create", ..., deliver="origin,all")

Les cibles supportées incluent Telegram, Discord, Slack, WhatsApp, Signal, SMS, email, Feishu, DingTalk, WeCom, Matrix et d’autres.

Le pattern silencieux

Si la réponse finale de l’agent contient [SILENT], la livraison est entièrement supprimée. La sortie est toujours sauvegardée localement pour audit, mais aucun message n’est envoyé :

# Texte du prompt :
"Check if nginx is running. If everything is healthy, respond with only [SILENT]. Otherwise, report the issue."

Les jobs échoués sont toujours livrés, indépendamment du silencieux — seules les exécutions réussies peuvent être réduites au silence.

Encapsulage de réponse

Par défaut, la sortie cron livrée est encapsulée avec un en-tête/pied de page :

Cronjob Response: Morning feeds
-------------

<sortie de l'agent ici>

Note: The agent cannot see this message, and therefore cannot respond to it.

Pour livrer la sortie brute sans l’encapsulage :

# ~/.hermes/config.yaml
cron:
  wrap_response: false

Jobs continuables (Répondre à un Cron)

Par défaut, une livraison cron est de type tire-et-oublie. Définissez un job continuable (via attach_to_session=True) et vous pourrez y répondre — le brief devient une conversation :

# ~/.hermes/config.yaml
cron:
  mirror_delivery: true

Ou par job via l’outil :

cronjob(
    action="create",
    ...,
    attach_to_session=True,
)

Sur les plateformes compatibles avec les fils (topics Telegram, threads Discord), chaque livraison ouvre un fil dédié. Sur les plateformes DM uniquement (WhatsApp, Signal), le brief est reflété dans la session DM.

Playbook de production : Trois configurations éprouvées

1. Briefing quotidien personnel

Un briefing matinal qui collecte l’activité GitHub, la météo et les éléments du calendrier :

hermes cron create "0 8 * * 1-5" \
  "1. Check my GitHub notifications for any PRs requesting my review
   2. Check the weather forecast for today
   3. Summarize anything from my calendar that needs attention
   4. Format everything into a clean morning brief" \
  --deliver telegram \
  --name "daily-briefing"

Pourquoi cela fonctionne : Il ne s’exécute que les jours ouvrés (1-5), utilise les outils intégrés de recherche web et de fichiers d’Hermes, et livre directement sur Telegram où vous pouvez le lire en prenant votre café.

2. Watchdog de dépôt GitHub

Un script sans agent qui vous prévient quand la dernière release d’un dépôt change :

#!/bin/bash
# ~/.hermes/scripts/github-watchdog.sh
REPO="NousResearch/hermes-agent"
CACHE_FILE="$HOME/.hermes/cron/output/latest_release.txt"
LATEST=$(curl -s "https://api.github.com/repos/$REPO/releases/latest" | grep -o '"tag_name": *"[^"]*"' | head -1)

if [ ! -f "$CACHE_FILE" ]; then
    echo "$LATEST" > "$CACHE_FILE"
    echo "📦 Initialized watcher for $REPO — latest: $LATEST"
    exit 0
fi

PREVIOUS=$(cat "$CACHE_FILE")
if [ "$LATEST" != "$PREVIOUS" ]; then
    echo "$LATEST" > "$CACHE_FILE"
    echo "🚀 New release detected for $REPO!"
    echo "   Previous: $PREVIOUS"
    echo "   Latest:   $LATEST"
    echo "   View: https://github.com/$REPO/releases/tag/$LATEST"
fi

Configurez-le :

hermes cron create "every 6h" \
  --no-agent \
  --script github-watchdog.sh \
  --deliver telegram \
  --name "github-release-watchdog"

Coût zéro token. Le script s’exécute toutes les 6 heures, n’envoie un message que lorsqu’une release change réellement.

3. Vérificateur de santé de site web

Un pipeline multi-étapes : vérification web → analyse des logs → livraison d’alerte.

Étape 1 — Collecteur (script sans agent) :

#!/bin/bash
# ~/.hermes/scripts/health-check.sh
URL="https://hermes-agent-lab.com"
STATUS=$(curl -s -o /dev/null -w "%{http_code}" --max-time 10 "$URL")
TIME=$(curl -s -o /dev/null -w "%{time_total}" --max-time 10 "$URL")
TIMESTAMP=$(date '+%Y-%m-%d %H:%M:%S')
echo "[$TIMESTAMP] $URL → HTTP $STATUS (${TIME}s)"
hermes cron create "every 30m" \
  --no-agent \
  --script health-check.sh \
  --name "site-health-collector"

Étape 2 — Analyse (pilotée par LLM, chaînée depuis le collecteur) :

hermes cron create "0 */2 * * *" \
  "Review the last 4 health checks for hermes-agent-lab.com.
   Are any failures or slow responses apparent?
   If everything is healthy, respond with only [SILENT].
   If there is an issue, write a summary of the problem and deliver it." \
  --context_from "<collector_job_id>" \
  --name "site-health-analyst"

Le collecteur s’exécute toutes les 30 minutes (gratuit, sans token). L’analyste s’exécute toutes les 2 heures, reçoit la sortie du collecteur comme contexte et n’envoie un message que lorsque quelque chose ne va pas.

Pièges courants et comment les éviter

1. Oublier que le Gateway doit être en cours d’exécution

L’exécution du cron est gérée par le démon gateway. Si le gateway n’est pas en cours d’exécution, vos jobs ne se déclencheront pas :

hermes gateway install     # Installer en tant que service utilisateur
hermes gateway status      # Vérifier qu'il est en cours d'exécution
hermes gateway run         # Ou exécuter au premier plan pour les tests

2. Confusion entre délai relatif et intervalle

  • 30m = ponctuel dans 30 minutes
  • every 30m = récurrent toutes les 30 minutes

C’est une erreur courante. Utilisez every explicitement quand vous voulez une récurrence.

3. Jobs silencieux qui ne parlent jamais

Si votre job s’exécute mais que vous ne voyez jamais de sortie, l’agent a probablement répondu avec [SILENT] (cas de succès) ou le script n’a pas produit de stdout (cas sans agent). Vérifiez la sortie locale :

ls ~/.hermes/cron/output/
cat ~/.hermes/cron/output/<job_id>/*.md

4. Modèle/Fournisseur qui ne fonctionne soudainement plus

Les jobs non épinglés capturent un instantané de la valeur par défaut actuelle à la création. Si vous avez changé de fournisseur (hermes model), le job vous alerte pour épingler explicitement. Épinglez toujours les jobs de production :

hermes cron edit my-job --provider openrouter --model anthropic/claude-sonnet-4

5. Chevauchement des horaires de pipeline

Lors du chaînage de jobs avec context_from, assurez-vous que le job amont se termine avant que le job aval ne démarre. Si le Job A s’exécute à 0 7 * * * (7:00) et le Job B à 0 7 * * * (également 7:00), le Job B obtient la sortie du Job A du jour précédent — ou un fichier vide s’il s’agit de la première exécution. Décalez-les d’au moins 15–30 minutes.

6. Jobs Workdir qui se bloquent mutuellement

Les jobs avec workdir défini s’exécutent séquentiellement. Concevez vos pipelines pour que les jobs workdir ne deviennent pas un goulot d’étranglement — gardez-les courts ou utilisez des jobs intermédiaires sans workdir pour le traitement lourd.

Résumé

Le cron d’Hermes vous transforme d’opérateur manuel en quelqu’un qui configure et oublie. Voici l’antisèche :

Tâche Approche Coût LLM
Briefing quotidien personnel Job LLM unique avec recherche web Faible
Moniteur de releases GitHub Script sans agent Zéro
Vérification de santé web + alerte Pipeline : collecteur sans agent → analyste LLM Faible (toutes les 2 heures)
Pipeline d’actualités IA Chaîne multi-job avec context_from Modéré
Watchdog disque/mémoire Script sans agent Zéro
Diffusion multi-plateforme Job unique avec deliver="all" Faible

La combinaison de sessions d’agent complètes, d’injection de skills, de mode script sans agent et de pipelines multi-jobs fait du cron d’Hermes l’un des outils d’automatisation les plus polyvalents disponibles dans tout framework d’agents IA.

Commandes de démarrage rapide

# Intégration en 1 minute : planifiez votre premier job
hermes cron create "every 1d at 09:00" "Give me a 3-sentence summary of what happened on GitHub with NousResearch/hermes-agent since yesterday" --deliver telegram

# Lister et vérifier
hermes cron list
hermes cron status

# Le voir s'exécuter en temps réel
hermes cron run my-job-name

Pour en savoir plus sur l’automatisation Hermes, consultez la documentation officielle du cron, notre guide d’installation et la comparaison des fonctionnalités.