Cron Hermes : choisir une sortie locale ou un canal de messagerie avant de planifier
Quand tu crées un cron dans Hermes, la première question n’est pas la fréquence. Ce n’est pas non plus le prompt. La première question, c’est : qui a besoin de voir le résultat, et où.
La réponse détermine la destination de sortie. Et cette destination change tout : le bruit que tu génères, la vitesse à laquelle tu réagis, et la confiance que ton équipe accorde au système.
Si tu envoies chaque rapport dans un canal Slack partagé sans réfléchir, tu satures. Si tu gardes tout en local sans que personne ne voie jamais rien, tu perds la moitié de l’intérêt. Le bon réglage est entre les deux, et il se décide avant la première exécution.
Le vrai sujet n’est pas d’ajouter un agent de plus.
Si tu veux construire un système d’agents utile, il te faut surtout une structure claire, de bons arbitrages et des retours terrain. C’est exactement ce qu’on partage dans Kavyro.
Arbitrages utiles
Questions réelles
Accès gratuit
Tu arrives avec ton sujet, tu repars avec plus de clarté.
Le bruit commence par une sortie mal choisie
Le piège classique : tu actives un cron, tu mets all comme destination, et tu passes à autre chose. Trois semaines plus tard, ton canal Telegram reçoit 40 messages par jour que personne ne lit. Le pire, c’est que ça marche techniquement. Le cron tourne, les messages arrivent. Mais l’effet réel, c’est que les gens finissent par mute le canal.
Le problème n’est pas le volume. C’est l’absence de tri. Quand tout arrive au même endroit, rien n’est important.
La destination de sortie d’un cron Hermes n’est pas un paramètre cosmétique. C’est une décision de travail. Elle répond à une question simple : qui doit voir ce résultat, et dans quel contexte cette personne pourra agir.
Sortie locale : quand le fichier suffit
La sortie local écrit le résultat dans ~/.hermes/cron/output/. Pas de notification. Pas de message. Juste un fichier.
C’est le bon choix quand le cron produit un résultat que tu consultes à la demande : un rapport hebdomadaire que tu ouvres le lundi matin, un log de vérification que tu regardes seulement si quelque chose cloche, une extraction de données que tu reprends dans un autre outil.
L’avantage, c’est le silence. Tu ne déranges personne. Tu ne crées pas de notification parasite. Le fichier est là quand tu en as besoin, invisible le reste du temps.
L’inconvénient, c’est que personne ne sait si le cron a tourné sans aller vérifier. Si le job échoue un dimanche soir, tu le découvres peut-être le lundi midi. Pour un cron de surveillance, c’est un risque. Pour un cron de compilation de données, c’est acceptable.
Sortie messagerie : quand le canal fait partie du workflow
La sortie telegram, discord, slack, ou n’importe quel canal connecté au gateway Hermes, c’est le choix inverse. Le résultat arrive directement là où les gens travaillent.
C’est utile quand le cron produit une information qui déclenche une action rapide : une alerte de panne, un résumé quotidien que l’équipe commente, un rappel de deadline. Le message arrive dans le flux existant, et la réaction peut être immédiate.
Le gateway Hermes gère cette distribution. C’est un processus unique qui connecte les plateformes, gère les sessions, exécute les crons et délivre les messages. Tu ne configures pas une intégration par canal. Tu choisis la destination, et le gateway route.
La règle que j’applique : un canal de messagerie se justifie quand le délai entre la production du résultat et l’action attendue est court. Si la personne peut agir dans l’heure, le message a sa place dans son canal de travail. Si l’action peut attendre le lendemain, un fichier local suffit.
Le tableau des destinations : quand choisir quoi
| Destination | Quand l’utiliser | Quand l’éviter |
|---|---|---|
local |
Consultation à la demande, extraction de données, rapports hebdomadaires | Alerte critique, information qui déclenche une action immédiate |
origin |
Tu veux recevoir le résultat là où tu as créé le cron | Le cron a été créé par quelqu’un qui n’est pas le destinataire final |
telegram / discord / slack |
L’équipe doit voir et réagir vite, le canal existe déjà | Le volume est élevé et le signal utile est noyé |
all |
Annonce rare et importante, changement de statut critique | Tout le reste. Sature tous les canaux sans tri. |
origin,all |
Tu veux ta copie + diffusion large pour un événement ponctuel | Usage quotidien. Trop de bruit. |
Tester avant de brancher tout le monde
Avant d’activer une sortie messagerie pour un cron, teste en local. C’est une étape que je saute encore parfois, et je le regrette à chaque fois.
Voici la séquence que j’utilise maintenant :
- Créer le cron avec la sortie
local. - Le laisser tourner deux ou trois cycles.
- Vérifier le format du résultat : est-ce lisible ? Est-ce que le message donne envie d’agir ou juste de scroller ?
- Si le résultat est propre, basculer vers le canal choisi.
- Prévenir la personne ou l’équipe concernée avant le premier message.
Ce n’est pas de la prudence excessive. C’est du respect pour l’attention des gens. Un message de cron mal formaté dans un canal Slack, c’est une notification de trop qui entraîne un mute. Et un mute, c’est difficile à rattraper.
Qui reçoit quoi : la revue destinataire
La dernière étape avant de valider un cron, c’est la revue des destinataires. Elle prend trente secondes et évite des semaines de bruit.
Pour chaque cron actif, pose-toi ces trois questions :
- Qui reçoit ce résultat aujourd’hui ?
- Est-ce que cette personne a besoin de le voir à cette fréquence ?
- Est-ce que le format lui permet d’agir sans effort supplémentaire ?
Si la réponse à la deuxième question est « non », change la fréquence ou la destination. Si la réponse à la troisième est « non », retravaille le format avant de changer la destination.
Cette revue n’est pas un audit trimestriel. C’est un réflexe à chaque création de cron. Tu le fais une fois, et le système reste propre.
Définir la destination avant le prompt
L’ordre compte. Quand tu crées un cron, définis d’abord qui reçoit le résultat et dans quel canal. Ensuite seulement, écris le prompt et choisis la fréquence.
Pourquoi ? Parce que la destination change le format. Un message Telegram doit être court, lisible sur mobile, avec une action claire. Un fichier local peut être dense, structuré, fait pour être ouvert sur un écran. Si tu écris le prompt avant de savoir où il atterrit, tu produis un format inadapté.
C’est la même logique que pour un email : tu n’écris pas de la même façon selon que tu t’adresses à une personne ou à une liste de diffusion. La destination façonne le message.
Si tu veux aller plus loin sur la configuration des agents connectés aux canaux de messagerie, j’ai détaillé le sujet dans l’article sur la centralisation des demandes via Discord et Telegram. Et si tu te demandes pourquoi un cron silencieux peut être plus dangereux qu’un cron bruyant, l’article sur la routine bombe silencieuse couvre ce risque.
Le choix de la destination n’est pas une option technique parmi d’autres. C’est la première décision éditoriale de ton cron. Fais-la avant le prompt, teste en local, et revois les destinataires une fois par mois. Ton système restera utile sans devenir bruyant.
Pour configurer tes premiers crons avec la bonne destination, tu peux faire une demande d’accès à Hermes et tester les sorties une par une avant de les brancher sur tes canaux d’équipe.
