La boucle d'agent qui a remplacé mon samedi

Chaque samedi matin, je passais deux heures à faire un travail que je détestais : vérifier les liens cassés du site, mettre à jour les dépendances mineures, lancer les évals sur les derniers posts, nettoyer les branches mortes. Aucune de ces tâches n’était difficile. Aucune n’était intéressante. Et toutes revenaient, religieusement, chaque semaine.

En mars, j’ai construit un petit agent pour les faire à ma place. Pas un agent général, un agent à mission unique, avec un périmètre défini, une boucle d’exécution simple, et un mécanisme de rapport qui me dit ce qu’il a fait sans me demander de le superviser en direct. Ça m’a pris un après-midi à construire. Trois mois plus tard, je n’ai plus touché à ce samedi matin.

L’agent, pas le framework

Je n’ai pas utilisé LangChain, CrewAI ou un framework « agentique ». J’ai écrit un script shell de 80 lignes qui appelle Claude Code avec un prompt structuré et un périmètre de fichiers restreint. La sophistication est dans le cadrage, pas dans la stack.

Le prompt suit un format strict :

Tu es un agent de maintenance. Exécute ces tâches dans l'ordre.
Pour chaque tâche : exécute, puis rapporte le résultat (ok / problème trouvé / échec).
Ne corrige rien qui n'est pas dans cette liste. Ne modifie aucun fichier de contenu.

Tâches :
1. Lancer `pnpm blog:lint` et rapporter les erreurs.
2. Vérifier les liens internes cassés dans src/content/blog/*.md.
3. Lister les dépendances avec des mises à jour mineures disponibles.
4. Lister les branches Git mergées non supprimées.
5. Rapporter la taille du build par rapport à la semaine dernière.

L’agent exécute, rapporte, et s’arrête. Il ne corrige pas les liens cassés, il les liste. Il ne met pas à jour les dépendances, il les signale. La décision d’agir reste à moi. L’agent me donne le diagnostic ; je décide de la thérapie.

Pourquoi ça marche : les trois propriétés

1. Périmètre fermé

L’agent ne peut pas toucher les articles de blog (lecture seule sur src/content/). Il ne peut pas pousser de code. Il ne peut pas modifier les fichiers de config. Son périmètre est « lire, analyser, rapporter ». Rien de ce qu’il fait n’est irréversible, donc rien de ce qu’il fait ne nécessite ma confiance totale.

2. Sortie vérifiable en 30 secondes

Le rapport qu’il génère est un fichier markdown avec cinq sections, chacune avec un statut (✓ / ⚠ / ✗). Je le lis en trente secondes le samedi matin avec mon café. Si tout est vert, ma semaine de maintenance est terminée. Si quelque chose est orange, j’ai un problème précis à résoudre, pas un samedi matin entier à sacrifier.

3. Exécution déterministe

L’agent fait les mêmes cinq tâches dans le même ordre à chaque exécution. Il n’improvise pas. Il n’ajoute pas de tâches. Il ne décide pas qu’il serait « utile » de faire un refactoring pendant qu’il est là. C’est un cron job intelligent, pas un collègue autonome.

Ce que j’ai appris

L’agent ne remplace pas la décision, il remplace la collecte

La partie ennuyeuse du samedi matin n’était pas de décider quoi faire des liens cassés. C’était de les trouver. Pas de décider quelles dépendances mettre à jour. C’était de lister celles qui avaient bougé. L’agent a éliminé la collecte, la partie chronophage et sans valeur, et m’a laissé la décision, la partie qui prend trente secondes et qui nécessite du jugement.

Le rapport est le produit

J’ai itéré trois fois sur le format du rapport avant de trouver le bon. La première version était trop verbeuse (l’agent racontait son raisonnement). La deuxième était trop concise (juste « ok » sans contexte). La troisième, un tableau avec statut, détail en une ligne, et action suggérée, est celle que je lis sans effort.

Le rapport n’est pas un sous-produit de l’agent. C’est le produit. Un agent dont le rapport est illisible est un agent inutile, même s’il fait un travail parfait en interne.

La fréquence crée la confiance

Les premières semaines, je vérifiait les résultats de l’agent manuellement. Je relançais les commandes moi-même pour voir s’il avait raison. Au bout d’un mois, j’ai cessé de vérifier les résultats « verts », ils étaient toujours corrects. La confiance s’est construite par la répétition, pas par la sophistication du système.

Quand cette approche casse

L’agent-boucle marche pour les tâches qui sont :

• Récurrentes (au moins hebdomadaires)
• Non-créatives (diagnostic, pas résolution)
• Vérifiables (le résultat est vrai/faux, pas subjectif)
• À faible rayon d’impact (une erreur de l’agent ne casse rien)

Il ne marche pas pour les tâches qui nécessitent du jugement contextuel (« est-ce que ce post est prêt à publier ? »), de l’interaction avec des tiers (emails, PRs), ou des actions irréversibles (déploiement, suppression).

Pour celles-là, l’agent reste un assistant, pas un remplaçant.

---

Si cela vous a parlé, vous aimerez Les petites automatisations qui se cumulent sur un trimestre et Écrire des skills que votre agent de code utilisera vraiment. Abonnez-vous ci-dessous pour recevoir le billet de vendredi prochain.