Agents qui tournent seuls : automatiser une tâche récurrente avec un agent planifié

La différence entre un agent qu'on invoque et un agent qui tourne seul n'est pas technique, elle est psychologique. Tant que je suis devant l'écran à lire chaque réponse, une erreur se corrige en quelques secondes. Dès qu'un agent tourne sans moi, la question change : ce n'est plus « est-ce que ça marche », c'est « qu'est-ce qui se passe le jour où ça ne marche pas ».

Trois façons de faire tourner un agent sans y penser#

Je distingue trois mécanismes, qui répondent à des besoins différents et qu'on confond facilement.

Mécanisme	Tourne quand	Survit à la fermeture de session
Boucle (/loop)	À intervalle fixe ou au rythme choisi par l'agent	Non
Agent planifié (cron)	À une heure ou une fréquence fixée à l'avance	Oui
Hook	Sur un événement précis (avant un outil, à l'échec)	N'a de sens que pendant une session

Le hook n'est pas vraiment « autonome » au sens où je l'entends ici : il réagit, il ne planifie rien. La boucle est pratique pour une tâche bornée dans le temps, une veille pendant que je travaille sur autre chose. L'agent planifié est le seul des trois qui continue d'exister quand je ferme mon ordinateur, et c'est aussi celui qui demande le plus de rigueur en amont.

Concevoir un agent planifié qui ne casse rien#

Trois règles que j'applique systématiquement, après avoir vu ce qui se passe quand je ne les suis pas.

1. Toujours un mode dry-run avant l'action réelle#

Mon agent de synchronisation de todo-list vers mon calendrier accepte un --dry-run qui affiche le plan sans rien modifier. Je l'ai utilisé systématiquement la première semaine, avant de laisser l'agent écrire directement. Sans ce mode, la première erreur de parsing aurait créé une dizaine d'événements mal formés dans un calendrier partagé.

2. Un périmètre d'écriture strictement limité#

Un agent qui lit largement mais n'écrit que dans un périmètre étroit et explicite tolère mieux ses propres erreurs qu'un agent à qui on a donné un accès large « au cas où ». Mon agent de veille sur mes dépôts est en lecture seule : il résume, il ne modifie jamais rien. Celui qui écrit dans mon calendrier ne touche qu'à des événements qu'il a lui-même créés, identifiables par un marqueur, jamais aux événements existants.

3. Un canal de retour visible en cas d'échec silencieux#

Un agent planifié qui échoue sans le signaler est pire que l'absence d'automatisation : on croit la tâche faite, elle ne l'est pas. Je préfère un agent qui notifie systématiquement, même en cas de succès, plutôt qu'un agent silencieux dont je découvre l'échec trois semaines plus tard.

Ce que je fais tourner aujourd'hui#

Trois agents planifiés, avec des niveaux de confiance très différents :

• Une synchronisation quotidienne de ma todo-list vers Google Calendar, avec confirmation explicite avant toute modification destructive.
• Un résumé hebdomadaire de l'activité git sur tous mes projets, en lecture seule, pour ne pas rouvrir chaque repo un par un.
• Un audit périodique des dépendances obsolètes ou vulnérables sur l'ensemble de mes projets, avec un résumé priorisé plutôt qu'une simple liste brute.

Le point commun des trois : aucun n'a démarré planifié. Chacun a d'abord tourné plusieurs fois en mode manuel, invoqué à la demande, avant que je lui fasse confiance pour tourner sans supervision.

Le piège principal : la confiance excessive#

La tentation, une fois qu'un agent planifié tourne correctement quelques fois, est d'arrêter de vérifier ses résultats. C'est exactement le moment où une dérive silencieuse peut s'installer, une mise à jour d'API qui casse un appel, un format de données qui change légèrement. Je garde le résumé hebdomadaire comme filet de sécurité : même les agents en pilote automatique produisent une trace que je relis, au minimum une fois par semaine.

Un agent qui tourne seul n'est pas un agent à qui on fait plus confiance, mais un agent conçu pour qu'une erreur reste visible et réversible, même quand personne ne regarde au moment où elle se produit.