Lancer l’agent tout seul

Un agent tourne tout seul quand un planificateur le lance, avec une routine écrite, à heure fixe. Cette partie-là est facile. Ce qui permet de le laisser sans surveillance, ce sont trois habitudes : la routine vérifie chaque outil dont elle a besoin avant de faire quoi que ce soit, elle propose au lieu de publier, et quelque chose d’extérieur à la routine vérifie qu’elle a bien tourné. Sans la troisième, une routine morte le mois dernier ressemble trait pour trait à une routine qui n’avait rien à signaler.

Le planificateur compte moins qu’on ne le croit. Une tâche cron sur un serveur, une tâche planifiée dans votre client d’agent, un scénario Make ou n8n qui déclenche l’agent : tous font l’affaire, et le chapitre sur les outils dit lequel convient à quel cas. Ce qui suit vaut pour tous.

Choisir ce qui mérite d’être planifié

Toutes les tâches d’un agent ne doivent pas tourner sans surveillance. Une routine mérite son créneau quand l’entrée arrive à son propre rythme et que la sortie peut attendre un humain.

Bon candidat	Mauvais candidat
Revue hebdomadaire des données de recherche, avec les pages à corriger proposées	Tout ce qui envoie quelque chose à un client ou à un prospect
Brouillon quotidien d’un post à partir d’un brief écrit à l’avance	Les tâches dont l’entrée est une conversation
Synthèse du lundi des réponses à l’outbound de la semaine	Les analyses ponctuelles lancées deux fois par an
Contrôle nocturne de la cohérence entre faits produit et pages publiées	Tout ce dont une erreur ne peut pas être annulée

Les routines derrière le marketing de Derrick suivent ce partage (j’ai cofondé Derrick). Elles lisent, analysent et rédigent selon un planning ; publier et envoyer restent l’affaire d’un humain, ou d’une exception étroite et écrite.

Écrire la routine comme un prompt numéroté avec une étape 0

Une routine est un prompt que le planificateur envoie à l’agent sans personne pour regarder. Écrivez-la en étapes numérotées, chacune avec une sortie claire, et commencez par une étape qui ne produit rien du tout.

ROUTINE weekly-seo-review   (Monday 07:00)

STEP 0. Check tools. Call each one once with a harmless read:
  - analytics: last 7 days, 1 row
  - pages sheet: read 1 row
  - drafts folder: list files
  If any call fails or the tool is missing:
    write "BLOCKED weekly-seo-review: <tool> <error>" to the alerts channel and STOP.
  Do not use another tool in its place. Do not estimate the missing data.

STEP 1. Pull last week's clicks and impressions per page. Compare with the
        previous 4 weeks. Keep pages that dropped by more than 30%.
STEP 2. For each kept page, read it and write one proposed fix with the reason.
STEP 3. Save proposals to drafts/seo-review-<date>.md. Do not edit any live page.
STEP 4. Append a run record to runs.jsonl:
        {"routine", "started_at", "finished_at", "status", "items_in", "items_out", "blockers"}

L’étape 0 existe à cause de ce que fait un agent quand un outil manque : il improvise. Il trouve un autre moyen d’obtenir quelque chose qui ressemble aux données, ou il comble le trou de mémoire, et le rapport a l’air normal. Une routine qui s’arrête en disant « bloquée » vous coûte une alerte. Une routine qui a improvisé vous coûte une semaine de décisions prises sur des chiffres que personne n’a mesurés.

Deux autres règles vivent dans le prompt lui-même. « Do not use another tool in its place » ferme explicitement la porte au plan B, que le modèle prendrait sinon pour de la serviabilité. Et l’étape 4 écrit un enregistrement même en cas de succès : c’est ce qui rend la surveillance possible ensuite.

Proposer, jamais publier, sauf exception écrite

Un agent planifié a les mêmes droits à 7 h un dimanche que lorsque vous le regardez, et aucun de vos réflexes. Par défaut, une routine écrit donc dans un dossier de brouillons, une branche, une pull request ou une file de relecture, et un humain tranche.

Des exceptions existent, et elles doivent être écrites là où la routine les lit, pas convenues dans une conversation.

routine: weekly-seo-review
may_do_alone:
  - read analytics and pages
  - write files in drafts/
needs_a_person:
  - publish or edit a live page
  - send any email or message
  - delete anything
  - spend credits above the run budget
exceptions:
  - action: fix an internal link that returns 404
    scope: pages listed in pages sheet only
    approved_by: owner
    review_after: 4 weeks

Chaque exception a un périmètre et une date de revue. À cette date, soit elle a fait ses preuves et reste, soit elle disparaît. Le chapitre sécurité traite le volet des droits : quelles clés la routine détient, et ce à quoi elle ne doit jamais toucher.

Lancer chaque nouvelle routine une fois à la main

Avant de planifier quoi que ce soit, lancez la routine vous-même, dans l’environnement qu’utilisera le planificateur, et suivez-la de l’étape 0 jusqu’à l’enregistrement final. Beaucoup de clients d’agent demandent une autorisation la première fois qu’un outil est appelé. En planifié, cette demande s’affiche sur un écran que personne ne regarde, et la routine reste là, bloquée, sans jamais atteindre l’étape qui l’aurait signalé. Elle ne plante pas, donc rien ne vous alerte.

Le lancement manuel montre aussi ce que la routine lit et écrit vraiment, souvent un peu différent de ce que vous aviez écrit. Corrigez le prompt, relancez, et seulement ensuite mettez-la au planning.

Vérifier de l’extérieur que les routines sont vivantes

Une routine ne peut pas signaler qu’elle n’a pas démarré. Le contrôle doit donc vivre ailleurs : un petit script, lui-même planifié, qui lit les enregistrements d’exécution et les compare à ce qui aurait dû se passer.

import json, time

EXPECTED_HOURS = {"weekly-seo-review": 7 * 24, "daily-post-draft": 24}

last = {}
for line in open("runs.jsonl", encoding="utf-8"):
    run = json.loads(line)
    last[run["routine"]] = run

now = time.time()
for name, hours in EXPECTED_HOURS.items():
    run = last.get(name)
    if run is None or now - run["finished_at"] > hours * 3600 * 1.5:
        print(f"STALE {name}: no finished run in the expected window")
    elif run["status"] != "ok":
        print(f"FAILED {name}: {run['status']} {run.get('blockers')}")

Je fais tourner un script de ce genre parce qu’une routine figée et une routine au repos se ressemblent de l’extérieur. Aucune des deux ne produit rien de neuf.

Le même raisonnement s’applique aux services dont dépend une routine. En novembre 2026, un service de données derrière l’un de mes agents passait son contrôle de santé alors que toutes les vraies requêtes échouaient : le contrôle interrogeait le service sans jamais toucher la base, et le projet cloud était sur une offre gratuite qui supprime les tables au bout de 60 jours. Un contrôle de santé doit emprunter le vrai chemin : faites-lui exécuter une vraie requête et comparez la réponse à une valeur connue.

Dernier point faible, l’installation elle-même : la même semaine, toute l’organisation d’agents existait encore en un seul exemplaire, sur un seul ordinateur portable, un cas que traite le chapitre sécurité.

La checklist avant de planifier une routine

Contrôle	Validé quand
L’étape 0 liste tous les outils	Retirer n’importe quel outil arrête la routine avec une alerte claire
Le plan B est interdit par écrit	Le prompt dit quoi ne pas faire quand un outil manque
La sortie va dans un endroit relisible	Brouillons, branche, file d’attente, jamais en ligne par défaut
Les exceptions sont écrites avec périmètre et date de revue	La routine les lit dans un fichier
Un lancement manuel a abouti	Enregistrement écrit, aucune demande d’autorisation en attente
Le contrôle de vitalité la couvre	La routine figure dans la liste attendue avec son intervalle
La sortie passe les mêmes portes que le travail manuel	Lint et juge du chapitre sur le contrôle qualité

Votre prochaine étape : prenez la tâche d’agent que vous lancez déjà à la main chaque semaine, écrivez-la comme une routine avec une étape 0 et un enregistrement d’exécution, lancez-la une fois vous-même, et ajoutez-la à un contrôle de vitalité avant de lui donner un créneau.