L'art de créer des boucles pour vos agents IA

Il y a quelques semaines, Peter Steinberger a posté un tweet qui a explosé : « Arrêtez de faire des prompts à vos agents de code. Créez des boucles qui les pilotent. » Pendant ce temps, Boris Cherny—le créateur de Claude Code—disait peu ou prou la même chose sur Acquired Unplugged : « Je ne fais plus de prompts à Claude. J'ai des boucles qui tournent. Ce sont elles qui interrogent Claude. »

Vous savez ce qui s'est passé ensuite. Le classique : tout le monde a débattu, personne n'a vraiment compris ce qu'était une boucle, et la discussion est devenue un joyeux bordel d'abstractions.

Moi, je fais tourner de vraies boucles depuis plusieurs mois. Pas pour être引领潮流—j'étais juste écoeuré de tout ce travail de tri manuel. Et ce que j'ai découvert m'a surpris : la mentalité « boucle » n'est pas une technique avancée réservée aux power users. C'est une évolution naturelle dès qu'on cesse de voir les agents IA comme des copieurs-colliers sophistiqués et qu'on les considère comme des systèmes capables de surveiller, décider et agir à notre place.

Les trois types de « boucle » sur lesquels personne ne s'entend

Voilà pourquoi cette conversation part dans tous les sens : quand les gens disent « boucle », ils peuvent parler de trois choses complètement différentes.

La boucle de tâche autonome. C'est le classique « continue jusqu'à ce que ce soit fini ». Pensez au script Ralph de Geoffrey Huntley (while :; do cat PROMPT.md | claude-code; done) ou à la commande /goal intégrée dans Codex et Claude Code. Le mode « configure et oublie ».

La boucle planifiée ou événementielle. Du travail qui tourne pendant que vous n'êtes pas devant votre écran. Le fichier HEARTEBEAT.md de Peter Steinberger dans OpenClaw est l'exemple canonique : une checklist que l'agent reconsidère toutes les 30 minutes. Les automations Codex et les routines planifiées de Claude Code descendent de ce pattern.

L'orchestration distribuée. Des workflows dynamiques avec plusieurs agents qui travaillent en parallèle. Les opérations style map/reduce de Claude Code rentrent dans cette catégorie. On est plus proche du modèle acteur ici que d'une simple boucle.

Mon avis ? Steinberger et Cherny décrivent le deuxième type, câblé dans le premier. Les boucles que je fais tourner sont planifiées et événementielles à l'extérieur, et plusieurs d'entre elles exécutent des boucles internes de type expérimental une fois déclenchées. C'est dans cette combinaison que réside le vrai levier.

Le baby-sitter de PR : ma porte d'entrée dans le design de boucles

J'avais déjà du review de code par IA sur chaque pull request. Claude faisait une première passe, puis Codex avec son propre review, puis une GitHub Action personnalisée où je contrôlais exactement ce que le modèle voyait—contexte complet de la conversation加上 le diff du patch.

Mon workflow réel était ridicule. Je soumettais une PR, j'attendais les retours, puis je copiais-collais les commentaires dans l'agent. Des fois j'envoyais des screenshots. Manuel, répétitif, et terriblement ennuyeux.

Un jour, j'ai demandé à mon agent : « Tu ne peux pas utiliser le client gh pour vérifier l'état des reviews ? »

Il pouvait.

Alors naturellement : « Tu ne peux pas vérifier en continu et me prévenir quand c'est prêt ? »

Cette simple demande a transformé mon workflow. L'agent surveille maintenant les changements d'état des reviews, récupère le nouveau contexte, analyse les retours, et fait le vrai travail pour y répondre. La boucle se termine quand elle arrive à une décision de tri : accepter le retour, pousserback, ou m'escalader.

Le pattern se généralise parfaitement : surveiller les changements d'état dans des systèmes externes, se réveiller quand ils se produisent, récupérer le contexte frais, analyser, agir, trier. Une fois que vous voyez cette forme, vous commencez à la repérer partout. L'équipe Codex livre son propre skill babysit-pr, et les docs de Claude Code mentionnent le baby-sitting de PR comme cas d'usage principal pour leur commande /loop.

Les boucles internes : faire tourner ses propres expériences

Il y a un autre pattern de boucle que j'ai mis plus longtemps à apprécier : la boucle d'expérience. Le concept d'autoresearch d'Andrej Karpathy m'a fait réfléchir à ça—lancer de nombreuses itérations, mesurer les résultats, garder ce qui fonctionne. Je l'ai appliqué à un chemin Python lent et j'ai lancé 49 expériences en une heure, faisant passer le p95 de 339ms à 34ms pour environ 24 dollars.

Le même pattern s'applique à des problèmes plus difficiles : débugger le comportement d'un agent en production. Quand quelque chose se passe mal—une trace bizarre dans Braintrust, du feedback utilisateur dans Slack, ou quelque chose que je rencontre moi-même—je crée un worktree, j'y colle la trace, et j'invoque la boucle de test.

Ce qui rend cette boucle différente : elle impose une discipline à laquelle l'intuition naïve du modèle résiste. Si on le laisse faire, un modèle va hardcoder « ne jamais faire X, Y, Z » dans le system prompt et surajuster à la trace qu'on lui a montrée. Les références du skill distillent la recherche sur pourquoi cette approche échoue, et le contrat de la boucle exige une hypothèse et une matrice de test.

J'ai besoin de trois cas : le cas original qui échoue, un positif adjacent qui devrait prendre le même chemin, et un contre-exemple qui devrait prendre un chemin différent. Trois ou quatre probes tournent en concurrence contre le dev local, reconstituant le contexte utilisateur exact depuis la trace. Chaque run est noté sur les appels d'outils, la latence, le delta de tokens d'entrée, et la correction. Le modèle ne peut pas tricher en mémorisant—il doit vraiment comprendre.

Ce qui change vraiment quand on construit des boucles

Le plus grand changement n'est pas technique—il est conceptuel. Quand vous faites des prompts à un agent, vous êtes toujours celui qui conduit. Vous êtes l'accélérateur, le navigateur, le contrôleur qualité. Les boucles inversent ça. Vous devenez l'architecte de systèmes qui se pilotent eux-mêmes.

Ça ne veut pas dire que l'autonomie totale est l'objectif. Je suis toujours à la porte de tri sur tout ce qui compte. Les boucles gèrent la corvée, la surveillance, la répétition. Je gère les appels de jugement qui comptent vraiment.

Le deuxième changement, c'est que les boucles vous forcent à être explicite sur les critères de succès. Une bonne boucle a des conditions de sortie claires, des points de décision clairs, des chemins d'escalade clairs. Vous ne pouvez pas construire une boucle sans définir ce que « fait » veut dire. Cette discipline déteint sur tout le reste.

Troisième point : les boucles sont composables. Le baby-sitter de PR fonctionne aux côtés de la boucle d'expérience. Les vérifications planifiées déclenchent des réponses on-call. Vous commencez à construire une bibliothèque de comportements qui travaillent ensemble plutôt qu'un tas de prompts uniques et jetables.

Par où commencer concrètement

Si vous voulez expérimenter avec les boucles, commencez par quelque chose que vous avez déjà automatisé de manière bancale. Vous avez probablement une GitHub Action qui fait quelque chose sur un planning, ou une session Claude Code que vous ré-exécutez manuellement, ou un processus de review qui implique de copier-coller des résultats entre outils.

Prenez le plus agaçant. Demandez-vous : quel changement d'état est-ce que j'attends vraiment ? Quel contexte est-ce que l'agent besoin quand ce changement se produit ? Quelle décision est-ce qu'il besoin de prendre ?

Puis construisez la boucle. Elle n'a pas besoin d'être élégante. Elle a besoin de fonctionner, et de vous remettre aux commandes de votre propre temps.

Les configs complètes, les skills, et le workflow CI derrière les boucles que je fais tourner sont dans un repo snapshot public : camwest/agent-skills. Ce n'est pas un produit poli—c'est un système fonctionnel qui évolue au fil de mes apprentissages. C'est tout le propos. Les boucles ne sont pas une destination ; c'est une pratique.

Le discours autour des agents IA se noie dans l'abstraction. Voici la version concrète : arrêtez de faire des prompts, commencez à construire des boucles, et voyez ce qui se passe quand vous laissez la machine gérer la surveillance pendant que vous gérez le sens.