Hermes Agent : quand automatiser dans le temps avec cron
Le cron ne change pas l’interface d’Hermes.
Il change son rapport au temps.
Jusqu’ici, Hermes faisait quelque chose quand tu le lançais. Avec le cron, il revient tout seul à l’heure prévue, ou selon le rythme que tu as défini.
C’est une bascule simple à formuler, mais très différente à assumer : l’agent agit hors de ta présence.
Ce que tu auras à la fin
Une vision claire de ce que le cron change vraiment, des cas où ça vaut le coup, des commandes concrètes pour démarrer, et surtout une idée nette de ce qu’il faut avoir stabilisé avant de laisser quoi que ce soit tourner sans toi.
Ce que change vraiment le scheduling
Le cron intégré à Hermes permet de planifier une tâche récurrente avec un prompt, un rythme et une destination de livraison. La tâche tourne dans une session isolée, sans mémoire de tes conversations précédentes, et livre son résultat dans le canal que tu as défini.
Concrètement, tu passes d’un agent réactif à un agent qui revient tout seul au bon moment.
C’est une bascule importante.
Un Hermes sans cron, c’est un outil que tu ouvres quand tu y penses. Un Hermes avec cron, c’est un outil qui produit quelque chose pendant que tu n’y penses pas.
Le gain est réel : certaines tâches répétitives, courtes et bien bornées n’ont aucune raison de dépendre de ta mémoire ou de ta disponibilité. Les relancer à la main chaque jour, c’est une friction inutile.
Mais le risque l’est aussi : un cron mal pensé tourne en boucle sans toi, répète une erreur sans toi, consomme des tokens sans toi, et envoie de la lourdeur dans un canal sans que personne n’ait demandé quoi que ce soit.
Pourquoi ce sujet arrive seulement maintenant
Parce qu’un job planifié répète aussi bien tes bonnes idées que tes mauvaises.
En interactif, un prompt flou se corrige avec une relance. En cron, il repasse demain, puis le lendemain, puis la semaine suivante si tu l’as mal cadré.
Et il y a une contrainte simple : pour qu’un cron tourne vraiment tout seul en fond, le gateway doit tourner lui aussi. C’est lui qui porte le scheduler en continu et exécute les tâches dues. La CLI Hermes permet bien de créer, lister, inspecter et déclencher des jobs, mais une routine autonome a besoin d’un gateway actif.
Autrement dit, le sujet n’arrive pas “plus tard” pour faire joli. Il arrive quand tu es prêt à laisser quelque chose tourner sans toi.
Dans quels cas ça vaut vraiment le coup
Le cron commence à être rentable dans des cas très précis.
Quand la tâche est courte, cadrée et répétitive. Pas un raisonnement complexe. Pas une analyse de fond. Une vérification, un résumé, un état rapide. Quelque chose que tu relancerais toi-même si tu y pensais, et qui peut tenir en un prompt bien écrit.
Quand le résultat a un bon moment pour arriver. Un briefing le matin. Un rappel avant une deadline. Un état en fin de journée. Le cron prend tout son sens quand le timing fait partie de la valeur.
Quand tu as un canal de livraison défini. Le cron peut livrer dans Telegram, Discord, Slack, Signal, e-mail, ou simplement dans des fichiers locaux si tu restes en mode terminal. Si tu ne sais pas où le résultat doit atterrir, c’est probablement trop tôt pour planifier.
En revanche, le cron n’a rien à faire sur des tâches ambiguës, des prompts ouverts, des raisonnements qui demandent du contexte conversationnel ou des actions qui nécessitent ta validation avant d’être exécutées.
Cas 1 — Une vérification simple qui revient
La situation de départ
Tu as un petit truc à vérifier régulièrement. Rien de critique, mais assez utile pour que tu le fasses “quand tu y penses” — sauf que tu y penses une fois sur trois.
Par exemple : vérifier si un dépôt GitHub que tu suis a eu de l’activité récente. Ou vérifier l’état d’un service. Ou consulter un endpoint public pour voir si une donnée a changé.
Ce qu’on planifie
Une commande comme celle-ci suffit :
/cron add "every 6h" "Vérifie si le repo X a de nouvelles issues ou PR dans les 6 dernières heures. Si rien de neuf, réponds [SILENT]." --name "Veille repo"
Le prompt est court, la fréquence raisonnable, et le [SILENT] évite de recevoir un message toutes les six heures pour dire “rien à signaler”.
Ce qu’on gagne
Tu n’y penses plus. Et quand il y a quelque chose, tu le sais.
C’est exactement le bon profil pour un cron : tâche répétitive, résultat court, pertinence conditionnelle.
Ce qu’il faut surveiller
Que le prompt reste explicite. L’agent dans un cron n’a aucune mémoire de tes conversations. Il ne sait pas quel repo tu suis, quel format tu préfères, ni ce que tu considères comme important. Tout doit être dans le prompt, à chaque exécution.
Si tu laisses le prompt vague, tu recevras un résultat vague. Six fois par jour.
Cas 2 — Un briefing programmé au bon moment
La situation de départ
Tu veux recevoir un petit résumé chaque matin. Pas une analyse de fond. Juste un état rapide sur un sujet que tu suis, livré dans le bon canal, à l’heure où tu commences ta journée.
Ce qu’on planifie
En langage naturel dans une session :
Planifie une tâche tous les matins à 8h : fais un résumé des 5 dernières actus IA de la journée précédente, en 5 points courts.
Hermes crée alors le job automatiquement. Tu peux aussi passer par la CLI :
hermes cron create "0 8 * * *" "Résume les 5 dernières actus IA de la veille en 5 points courts" --name "Briefing matin"
Si le gateway est connecté à un canal, le résultat peut y atterrir directement. Sinon, il est enregistré localement dans ~/.hermes/cron/output/.
Ce qu’on gagne
Le bon résultat, au bon moment, au bon endroit. C’est le trio que le cron permet et que le lancement manuel ne garantit jamais.
Ce qu’il faut surveiller
La qualité du résultat dépend entièrement du prompt et du modèle. Un résumé d’actus demande un accès web. Si ton Hermes n’a pas les bons tools activés, le résultat sera vide ou bancal, et il reviendra quand même tous les matins.
Teste toujours un cron avant de le laisser tourner. La commande /cron run <job_id> ou hermes cron run <job_id> te permet de le déclencher manuellement pour vérifier son comportement.
Cas 3 — Pourquoi un mauvais cron devient vite un problème
La situation de départ
Tu as vu que le cron marchait. Alors tu en crées un deuxième. Puis un troisième. Les prompts sont vagues. Les fréquences sont courtes. Les résultats ne sont pas relus.
Ce qu’on perd
Un cron toutes les 30 minutes avec un prompt ouvert comme “regarde s’il y a quelque chose d’intéressant” va produire de la lourdeur pure. L’agent va chercher, improviser, formuler, et te livrer un résultat sans vraie valeur toutes les demi-heures.
Multiplie ça par trois jobs. Tu reçois des dizaines de messages par jour que tu ne lis plus.
Le cron est devenu une machine à spam que tu as toi-même construite.
Pourquoi ça dérape
Parce qu’un cron ne se corrige pas tout seul. Un prompt flou reste flou à chaque exécution. Une fréquence trop courte reste trop courte. Un résultat inutile reste inutile, mais il revient à l’heure.
C’est la différence entre une erreur ponctuelle et une erreur récurrente. Et dans un cron, toute erreur est récurrente par construction.
Ce qu’il faut retenir
Avant de créer un cron, pose-toi trois questions. Est-ce que le prompt est assez précis pour produire un bon résultat sans contexte conversationnel ? Est-ce que la fréquence correspond à un vrai besoin ? Est-ce que je lirai réellement le résultat ?
Si une seule réponse est non, le cron n’est pas mûr.
Les premières commandes vraiment utiles
Tu n’as pas besoin de connaître vingt commandes pour démarrer. Il t’en faut cinq.
Créer un job depuis une session :
/cron add "every 2h" "Ta tâche ici" --name "Nom lisible"
Lister les jobs actifs :
/cron list
Déclencher un job manuellement pour le vérifier :
/cron run <job_id>
Mettre en pause sans supprimer :
/cron pause <job_id>
Supprimer un job définitivement :
/cron remove <job_id>
Et depuis la CLI directement :
hermes cron create "0 9 * * 1-5" "Ta tâche" --name "Nom"
hermes cron list
hermes cron status
C’est largement suffisant pour couvrir un usage réel. Le reste, tu iras le chercher quand tu en auras besoin.
Ce que le cron ajoute comme contraintes
Le cron ajoute au moins trois contraintes qu’il faut accepter avant de l’utiliser.
La première, c’est l’absence de contexte conversationnel. Chaque exécution cron tourne dans une session isolée. L’agent ne sait rien de ce que tu lui as dit avant. Tout ce qu’il connaît, c’est le prompt du job. Si le prompt est incomplet, le résultat le sera aussi, sans que personne ne le corrige.
La deuxième, c’est la consommation silencieuse. Un cron qui tourne consomme des tokens, du temps d’exécution et parfois des appels vers des tools ou des services externes. Si tu as cinq jobs toutes les heures, la charge se construit en silence.
La troisième, c’est la discipline de maintenance. Un cron oublié reste actif. Il continue de tourner, de produire, de livrer. Si tu ne vérifies pas régulièrement tes jobs, tu risques de retrouver des tâches fantômes qui consomment sans servir.
Ce qu’il vaut mieux avoir déjà stabilisé avant
Avant de créer un job, il vaut mieux avoir quatre repères clairs.
D’abord, une tâche que tu as déjà validée en interactif. Si elle n’est pas utile à la main, elle ne devient pas utile parce qu’elle tourne seule.
Ensuite, un gateway actif si tu vises une vraie routine en fond. Sans lui, tu peux encore manipuler tes jobs depuis la CLI, mais pas tenir la même logique de service continu.
Troisièmement, un canal de livraison défini. Il faut savoir où le résultat atterrit avant de lui donner un horaire.
Enfin, un prompt autonome. Le job doit contenir la tâche exacte, les outils autorisés, le format attendu, et l’instruction [SILENT] si tu veux éviter de faire remonter du bruit quand il n’y a rien à dire.
Les erreurs fréquentes
L’erreur la plus classique, c’est de créer un cron pour une tâche qu’on ne faisait même pas à la main. Si tu n’avais pas déjà le réflexe de vérifier quelque chose régulièrement, le planifier ne le rendra pas utile. Ça le rendra juste automatique, et automatique n’est pas un synonyme d’utile.
La deuxième, c’est de sous-estimer le coût d’un prompt vague. En interactif, un prompt flou se rattrape en une relance. En cron, un prompt flou produit un mauvais résultat à chaque exécution sans que personne n’intervienne.
La troisième, c’est de ne jamais tester avant de planifier. La commande /cron run existe pour ça. Si tu ne vérifies pas le résultat d’un job au moins une fois avant de le mettre en rotation, tu planifies à l’aveugle.
La quatrième, c’est de ne jamais relire ses jobs. Un /cron list de temps en temps, c’est de l’hygiène de base. Exactement comme vérifier les services qui tournent sur une machine.
Ce que tu ne dois pas faire
- Ne planifie pas un prompt que tu n’as jamais testé en session normale.
- Ne mets pas une fréquence de 15 minutes sur un job de synthèse. Le résultat ne sera pas meilleur. Il sera juste plus fréquent.
- Ne laisse pas un cron tourner sans canal de livraison clair. Un résultat qui atterrit nulle part est un résultat qui consomme pour rien.
- Ne confonds pas cron et workflow. Si ta tâche demande plusieurs étapes conditionnelles, des décisions intermédiaires, ou un enchaînement complexe, c’est Python qui doit piloter, pas un prompt planifié.
- Ne fais pas du cron un substitut à une vraie routine. Si tu dois relire, filtrer, arbitrer ou valider le résultat à chaque fois, le cron ne t’a rien épargné. Il t’a juste ajouté une notification.
La suite logique
Le bon usage du cron n’a rien de spectaculaire.
Un job court, un bon moment, une sortie utile, et c’est tout.
Dès que tu cherches à en faire un pseudo-workflow, tu sors du sujet.
Une fois ce rapport au temps propre, la question suivante n’est plus “quand Hermes agit ?” mais “quel Hermes doit porter quoi ?”. C’est là que les profiles deviennent utiles.