Aller au contenu
TypeNouvelle primitiveÉtapeProductionDifficultéModéréTravailAutomatiser une tâchePourConstructeurs d'IAPourDevs backendServicesCronServicesAgentPourquoi HoodyNatif IAPourquoi HoodyHTTP-natif
TypeNouvelle primitiveÉtapeProductionDifficultéModéréTravailAutomatiser une tâchePourConstructeurs d'IAPourDevs backendServicesCronServicesAgentPourquoi HoodyNatif IAPourquoi HoodyHTTP-natif
TypeNouvelle primitiveÉtapeProductionDifficultéModéréTravailAutomatiser une tâchePourConstructeurs d'IAPourDevs backendServicesCronServicesAgentPourquoi HoodyNatif IAPourquoi HoodyHTTP-natif
TypeNouvelle primitiveÉtapeProductionDifficultéModéréTravailAutomatiser une tâchePourConstructeurs d'IAPourDevs backendServicesCronServicesAgentPourquoi HoodyNatif IAPourquoi HoodyHTTP-natif
Retour aux cas d'utilisation
use-cases / schedule-the-agent / hero
CRON · AGENT · 0 7 * * *

Planifiez l'agent, pas le script

Une ligne cron classique exécute reconcile.sh à 2h. Une ligne cron Hoody envoie un prompt en POST à hoody-agent. Le planning est figé. Le travail ne l'est pas. Les cas particuliers ne sont plus des branches que vous maintenez — ils deviennent du contexte sur lequel l'agent raisonne.

Lire la doc cron + agent
use-cases / schedule-the-agent / mechanism

Deux URLs, un prompt

Hoody Cron est un crontab géré sur chaque conteneur. Hoody Agent est un agent autonome intégré sur le même conteneur. L'entrée cron envoie un curl à l'agent. L'agent lit la date, lit les données, et décide ce que la journée demande. Les deux surfaces sont HTTP — le cron vit à /api/v1/cron/users/me/entries, l'agent à /api/v1/agent/tasks. Il n'y a pas de code de glue entre eux.

cron-1.containers.hoody.com · entry
POST · cron/users/me/entries
# POST /api/v1/cron/users/me/entries
{
  "schedule": "0 7 * * *",
  "command": "curl -X POST $AGENT/api/v1/agent/tasks \
     -d @prompt.json",
  "comment": "morning-reports"
}
agent-1.containers.hoody.com · task
POST · agent/tasks
# prompt.json — the body of the POST
{
  "description": "Réconcilie les commandes d'hier. Remappe si le schéma a dérivé. Arrête-toi et bipe l'astreinte si le score d'anomalie > 3. Si aujourd'hui est le dernier jour du mois, inclus la clôture mensuelle sur le grand livre ajusté à la fiscalité.",
  "mode": "code"
}

Deux POST et c'est terminé. La ligne crontab ne change plus jamais — le seul fichier que vous maintenez est le prompt. Nouveau cas particulier ? Ajoutez une phrase. Nouvelle règle d'anomalie ? Ajoutez une phrase. Le planning continue de se déclencher ; l'agent comprend ce que chaque déclenchement signifie.

use-cases / schedule-the-agent / powers

Trois choses qu'un prompt fait qu'un script ne peut pas

La forme du travail que l'agent reçoit est toujours la même — une date, un dataset, un objectif. Ce qui change, c'est ce que l'agent décide d'en faire.

RAISONNEMENT

Lit la date, lit les données, décide

L'agent s'exécute après le déclenchement du cron. Il vérifie le calendrier — fin de mois, jour férié, clôture fiscale. Il échantillonne le dataset — schéma, volume, score d'anomalie. Il choisit l'action suivante avec ce contexte, pas depuis un arbre if statique que vous avez écrit il y a six mois.

ADAPTATION

Nouvelles colonnes ? Nouvelles devises ? Même prompt.

Quand l'export d'hier ajoute une colonne refund_reason, un script casse et vous bipe. L'agent lit le schéma, le mappe au champ historique, et note le changement dans le résumé d'exécution. La ligne crontab n'a jamais eu à le savoir.

OBSERVABILITÉ

Chaque exécution est un paragraphe, pas un code de retour

Chaque exécution renvoie ce que l'agent a décidé et pourquoi. L'historique est en français clair — "ignoré : pas de nouvelles données", "adapté : colonne refund ajoutée", "anomalie : pic de remboursements +412%, astreinte bipée" — pas exit code 0 / exit code 1. Les logs du cron deviennent un journal.

use-cases / schedule-the-agent / flow

Du planning à la décision

Trois étapes — le cron se déclenche, l'agent raisonne, la décision atterrit. L'étape du milieu est celle que vous écriviez vous-même dans un script shell de 400 lignes avec dix-sept branches de cas particuliers. Maintenant c'est un prompt.

Boucle quotidienne en trois étapesUN PROMPT · UNE INFINITÉ DE CAS PARTICULIERS
07:00

Le cron se déclenche

Hoody Cron exécute l'entrée. La ligne crontab est un curl : POST /api/v1/agent/tasks avec le corps du prompt. Pas de retries écrits par vous, pas de plomberie de logs — le service cron injecte l'entrée dans le crontab système et suit l'exécution.

07:00 + ε

L'agent raisonne

L'agent reçoit la description, ouvre ses outils — terminal, fichiers, sqlite, navigateur, exec — et choisit un plan d'action. Il peut exécuter, ignorer, adapter ou biper. Les choix changent au quotidien. Les instructions, non.

07:00 — 07:04

La décision atterrit

L'exécution se termine. L'agent renvoie une ligne de résumé : rapports régénérés, ignoré car pas de nouvelles données, arrêté sur anomalie. Vous le lisez sur votre téléphone au petit-déjeuner.

Le planning n'a pas changé. Le script n'a pas changé. Ce qui a changé, c'est si vous, l'humain, deviez vous lever pour gérer ça. Avec l'agent dans la boucle, la réponse est presque toujours non — et l'historique d'exécution vous dit pourquoi.

use-cases / schedule-the-agent / capacity

Ce que vous obtenez de la paire cron + agent

Hoody Cron et Hoody Agent sont deux services sur le même conteneur, tous deux accessibles en HTTP. Les chiffres viennent des surfaces documentées — pas de benchmarks inventés.

  1. TAILLE DU CRONTAB1 ligne

    Un curl dans le crontab, pour toujours. Le corps du prompt est la seule chose que vous réécrirez — et vous le faites dans un fichier JSON, pas en lançant crontab -e.

  2. ENDPOINTS DE L'AGENT100+

    hoody-agent expose toute la surface — exec terminal, lecture/écriture de fichiers, requêtes sqlite, automatisation navigateur, contrôle de démon — à la tâche de l'agent comme de simples appels HTTP.

  3. LIGNES DE GLUE0

    Pas de SDK entre le cron et l'agent. POST sur une URL, lecture d'une autre. Les deux services vivent sur le même conteneur, donc l'appel est rapide en réseau local.

Hoody Cron supporte les expressions standards à 5 champs (* * * * *) et les macros (@hourly, @daily, @weekly, @monthly, @yearly). La création de tâche Hoody Agent est un POST /api/v1/agent/tasks ; les mises à jour live streament via /api/v1/agent/ws.

use-cases / schedule-the-agent / punchline

L'entrée cron n'exécute pas le job — elle demande à un agent de comprendre le job.

avant · script à branchesaprès · prompt à branches
CE VERS QUOI POINTAIT L'ANCIENNE ENTRÉE CRON0 2 * * * /usr/local/bin/reconcile.sh # 412 lignes · 17 cas particulierschaque nouvelle règle de fin de mois signifiait éditer le script et prier
CE VERS QUOI ELLE POINTE MAINTENANT0 7 * * * curl POST agent/tasks -d @prompt.jsonune ligne, pour toujours — le prompt est le seul artefact que vous maintenez
Lire la spec de tâche agent
use-cases / schedule-the-agent / replaces

Ce que cela remplace

L'ensemble de choses que vous écriviez dans reconcile.sh parce que cron ne savait qu'exécuter des fichiers. Chacune est une branche, un drapeau, une config — dont le planning n'a pas vraiment besoin de connaître. L'agent lit le jour et décide.

  • jobs cron scriptés fragilesBranches Bash qui plantent quand une colonne d'entrée bouge
  • maintenance manuelle des schémas changeantsÉditer reconcile.sh chaque fois que l'export amont gagne un champ
  • scripts ETL écrits à la mainUn dossier de fichiers .sh que seule une personne dans l'équipe comprend
  • logique cron if X then Y else ZFin de mois, jour férié, anomalie — trois drapeaux câblés dans un script
  • scripts de polling pour changementsUn cron séparé qui surveille la sortie du premier cron et décide
  • planificateurs if-else codés à la mainUn dispatcher de 200 lignes dont le seul rôle est de choisir quel script exécuter
use-cases / schedule-the-agent / cta

Arrêtez de maintenir des scripts cron. Commencez à maintenir des prompts. Le planning se déclenche ; l'agent comprend.

Lire la doc cron + agent
use-cases / schedule-the-agent / related

Découvrez les autres