Premier cron Hermes : automatiser une routine après avoir validé la tâche à la main

Tu as une tâche qui revient tous les jours. Tu l’as faite trois fois à la main, tu sais exactement ce qu’elle demande, et tu commences à te dire qu’un agent pourrait la faire à ta place. C’est le bon moment pour créer ton premier cron Hermes.

Pas avant.

L’erreur classique, c’est de planifier une automatisation sur une tâche qu’on n’a jamais exécutée soi-même. On écrit un prompt vague, on le balance dans un cron, et on découvre trois jours plus tard que l’agent a produit un résultat inutilisable parce qu’il lui manquait une information qu’on n’avait pas pensée à lui donner.

Communauté Kavyro

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.

Cas concrets
Arbitrages utiles
Questions réelles
Accès gratuit

Rejoindre la communauté

Tu arrives avec ton sujet, tu repars avec plus de clarté.

La règle est simple : la routine validée manuellement passe avant la planification. Voici comment faire.

Valider la tâche à la main avant de planifier

Avant d’ouvrir le moindre cron, tu dois pouvoir répondre à trois questions :

• Qu’est-ce que je fais exactement, étape par étape ?
• Quelles informations l’agent doit-il avoir pour produire un résultat correct ?
• À quoi je reconnais que le résultat est bon ?

Tant que tu n’as pas fait la tâche toi-même au moins une fois, tu ne peux pas répondre à ces questions de façon fiable. Tu vas écrire un prompt qui rate une étape, ou qui suppose un contexte que l’agent n’a pas.

Prends un exemple concret. Tu veux qu’un agent vérifie chaque matin si ton site est en ligne et t’envoie un résumé sur Telegram. Avant de planifier quoi que ce soit, fais-le à la main :

1. Ouvre un terminal et lance curl -I https://tonsite.com.
2. Vérifie le code de statut HTTP.
3. Note ce que tu regardes exactement : juste le 200, ou aussi le temps de réponse, ou un contenu spécifique dans la page ?
4. Écris le message que tu t’enverrais à toi-même.

Une fois que tu as fait ça deux ou trois fois, tu sais exactement ce que le cron doit produire. Tu peux passer à l’étape suivante.

Écrire un prompt que l’agent peut exécuter seul

Un cron Hermes tourne dans une session complètement neuve. L’agent n’a aucun contexte de tes conversations précédentes. Il ne sait pas qui tu es, quel est ton serveur, ni ce que tu attends de lui.

Le prompt doit être self-contained : tout ce dont l’agent a besoin doit être dedans.

Un mauvais prompt :

Vérifie le serveur et dis-moi si ça va.

Un bon prompt :

Connecte-toi en SSH sur 192.168.1.100 avec l’utilisateur deploy, vérifie que nginx tourne avec systemctl status nginx, et teste que https://tonsite.com renvoie un code HTTP 200. Si tout est OK, envoie « Site OK » sur Telegram. Si un check échoue, détaille l’erreur.

La différence, c’est que le deuxième prompt ne suppose rien. Il donne l’adresse, la commande, le critère de succès, et le format de réponse attendu.

Quelques règles pour un bon prompt de cron :

• Sois précis sur les actions. Pas « vérifie le serveur », mais « lance systemctl status nginx et vérifie que le statut est active ».
• Donne les accès ou les chemins. L’agent ne devine pas ton adresse IP ni ton nom d’utilisateur SSH.
• Décris le format de sortie attendu. Un message Telegram d’une ligne ? Un fichier markdown ? Un résumé structuré ?
• Prévois le cas d’erreur. Que doit faire l’agent si le check échoue ?

Créer le cron

Une fois le prompt prêt, tu peux planifier le job. Hermes accepte plusieurs formats de schedule :

Format	Exemple	Usage
Durée simple	30m, 2h	Intervalles courts et réguliers
Phrase naturelle	every 2h, every day 9am	Planification lisible
Expression cron	0 9 * * *	Planification précise, tous les jours à 9h
Timestamp ISO	2026-07-16T09:00:00	Exécution unique à une date précise

Depuis le terminal, la commande est directe :

hermes cron create "every day 9am" "Connecte-toi en SSH sur 192.168.1.100 avec l'utilisateur deploy, vérifie que nginx tourne avec systemctl status nginx, et teste que https://tonsite.com renvoie HTTP 200. Si tout est OK, envoie 'Site OK' sur Telegram. Si un check échoue, détaille l'erreur."

Tu peux aussi passer par le chat avec /cron add :

/cron add "every day 9am" "Vérifie le statut du site et envoie un résumé sur Telegram"

Et si tu veux qu’un skill soit chargé automatiquement à chaque exécution :

hermes cron create "every 1h" "Résume les nouveaux articles du flux RSS configuré" --skill blogwatcher

Tester le cron avant de lui faire confiance

Ne pars pas du principe que tout fonctionne. Lance une exécution manuelle immédiate pour vérifier :

hermes cron run <job_id>

Ou depuis le chat :

/cron run <job_id>

Cette commande déclenche le job sur le prochain tick du scheduler (toutes les 60 secondes). Tu vois le résultat arriver là où tu l’as configuré, et tu peux vérifier que le format, le contenu et la pertinence sont bons.

Si le résultat n’est pas bon, ne modifie pas le cron à l’aveugle. Repars de la tâche manuelle : refais-la toi-même, ajuste le prompt, et reteste. C’est le même principe qu’au début : la boucle manuelle valide, le cron exécute.

Observer les premières exécutions

Les premières exécutions automatiques sont une période d’observation. Voici ce que tu dois surveiller :

• Le résultat est-il conforme à ce que tu produisais à la main ? Si l’agent ajoute des informations inutiles ou en omet d’importantes, le prompt n’est pas assez précis.
• Le job s’exécute-t-il bien à l’heure prévue ? Vérifie avec hermes cron status que le scheduler est actif et que le job n’est pas en pause.
• Y a-t-il des échecs silencieux ? Un job peut tourner sans erreur mais produire un résultat vide ou inutile. C’est le pire cas, parce que tu ne le vois pas tout de suite.

Garde un oeil sur les premières 5 à 10 exécutions. Si tout est stable, tu peux laisser tourner.

Deux garde-fous à connaître

Le modèle est snapshoté à la création

Quand tu crées un cron sans préciser de modèle ou de provider, Hermes enregistre le modèle et le provider courants dans le job. Si tu changes plus tard ton modèle global avec hermes model, le cron ne suit pas : il refuse de s’exécuter et t’envoie une alerte pour que tu mettes à jour le job explicitement.

Ce comportement est documenté dans la page Cron de la documentation officielle : le job « fail closed » plutôt que d’hériter silencieusement d’un changement qui pourrait entraîner des coûts imprévus. Pour qu’un job suive délibérément ton modèle global, mets-le à jour après avoir changé de modèle :

hermes cron edit <job_id> --provider <provider> --model <model>

Un cron ne peut pas créer d’autres crons

Les sessions lancées par le scheduler n’ont pas accès aux outils de gestion des crons. Un job planifié ne peut pas, par exemple, créer un nouveau cron qui s’exécuterait ensuite. Cette restriction empêche les boucles de planification involontaires.

C’est un garde-fou important : si ton agent pouvait programmer d’autres agents sans ton intervention, tu perdrais le contrôle de ce qui tourne en arrière-plan. La documentation officielle est claire : « Cron-run sessions cannot recursively create more cron jobs. »

Et après ton premier cron ?

Une fois que tu as un cron qui tourne et que tu as validé son comportement sur plusieurs exécutions, tu peux passer à l’étape suivante : auditer tes crons existants pour vérifier qu’ils ne sont pas devenus des bombes silencieuses. C’est l’objet d’un autre article, mais le principe est le même : ce qui n’est pas vérifié régulièrement finit par dériver.

Tu peux aussi explorer les options avancées : ajouter un script de pré-exécution avec --script, chaîner des jobs avec context_from, ou router les résultats vers plusieurs canaux avec l’option delivery.

L’important, c’est de garder le réflexe que tu as pris ici : tester à la main, planifier, vérifier, ajuster. Dans cet ordre. Toujours.

Si tu veux aller plus loin et découvrir comment Hermes peut transformer ta façon de travailler au quotidien, tu peux faire une demande d’accès à la formation Kavyro. On y voit comment construire des automatisations fiables, les auditer, et les faire évoluer sans perdre le contrôle.