Les loops : pourquoi tu ne devrais bientôt plus prompter tes agents IA

TL;DR :

• Une loop, c'est une boucle qui prompte ton agent à ta place. Au lieu de lui donner des instructions une par une, tu conçois un système qui se relance seul jusqu'à atteindre un objectif.
• Il faut 4 ingrédients : un objectif, du contexte, une évaluation, et un agent. Enlève l'un des quatre et ta boucle part en vrille.
• Des exemples concrets : un agent qui fait passer une pull request au vert, qui traque un bug jusqu'à ce que les tests passent, qui chasse les tests instables.
• Le "pourquoi maintenant" n'est pas un effet de mode : les modèles tiennent des tâches de plusieurs heures, les loops sont intégrées aux outils, et les sous-agents évitent que le contexte pourrisse.
• Le code n'a jamais été le problème. Ce qui reste à toi : le goût, la direction, l'empathie produit.

---

Salut 👋

Il y a un tweet de Peter Steinberger, une voix très suivie de l'écosystème des agents de code, qui a fait le tour de X récemment et qui résume mieux que moi ce qui est en train de changer :

En français : tu ne devrais plus prompter tes agents de code, tu devrais concevoir des boucles qui promptent tes agents.

Au début, ça ressemble à une phrase pour faire le malin. Puis tu réalises que c'est exactement là qu'on en est. Depuis un an, le réflexe c'était d'ouvrir Claude Code ou Cursor, de décrire une tâche, de valider, puis de recommencer. Tu étais le moteur. À chaque tour, il fallait que tu relances.

Le changement de 2026, ce n'est pas que l'IA code mieux. C'est qu'on peut désormais lui retirer ce rôle de relanceur. Au lieu de prompter l'agent, tu construis une loop : une boucle qui se prompte elle-même jusqu'à ce que le travail soit fait. Tu passes de "je pilote chaque étape" à "je conçois le système et je le regarde tourner".

C'est un vrai saut, et je te le décompose ici.

C'est quoi une loop, concrètement

Une loop, c'est un agent placé dans une boucle qui se relance tant qu'un objectif n'est pas atteint. La version la plus bête, c'est un while true autour de Claude Code avec une consigne du type "continue jusqu'à ce que les tests passent". La version sérieuse, c'est un système qui va chercher son propre travail, l'exécute, vérifie son résultat, et recommence.

La différence fondamentale avec le prompting classique tient en une phrase : c'est l'agent qui fait la vérification, plus toi. Tu ne relis pas chaque diff. Tu définis comment le travail est jugé correct, et la boucle s'auto-corrige jusqu'à y arriver.

C'est la suite logique de ce que j'appelais l'infrastructure qui compte plus que le modèle. Le modèle est le moteur, la loop est le véhicule.

Les 4 ingrédients d'une bonne loop

Une boucle qui tourne, ce n'est pas magique, c'est mécanique. Il te faut quatre choses, et si tu en oublies une, ça déraille.

1. Un objectif

L'agent est capable, mais il faut cadrer la boucle pour qu'il sache ce que tu veux atteindre. Une loop sans objectif, c'est un canon à slop : elle produit de l'activité sans direction, du volume sans valeur. L'objectif doit être vérifiable, pas vague. "Améliore le code" ne marche pas. "Fais passer la CI au vert" marche.

2. Du contexte

Le contexte, c'est le carburant, et les boucles en manquent presque toujours. Ça inclut les outils, les Skills, les données d'analytics, les erreurs, les logs, la mémoire du projet. Tout ce qui aide l'agent à trouver du travail et à le finir.

Le piège du débutant, c'est de tout balancer d'un coup au démarrage. La bonne approche, c'est de doser le contexte et de le nourrir au fil de la boucle. L'agent doit pouvoir aller chercher de nouvelles infos et réagir à ce qu'il trouve, pas digérer un bloc de 200 fichiers au premier tour. C'est là que des mécanismes comme le protocole MCP et les Skills deviennent centraux : ils donnent à l'agent les moyens d'aller chercher son contexte lui-même.

3. Une évaluation

C'est la façon dont l'agent se contrôle. Des tests, des évals, des métriques, un modèle qui joue le rôle de juge, un environnement de test. Le développement piloté par les tests fait un retour en force, ou peut-être qu'il n'était jamais parti.

C'est le point qui sépare une vraie loop d'un simple prompt en boucle : la vérification est faite par l'agent, pas par l'ingénieur. Sans évaluation, ta boucle ne sait pas quand elle a réussi, donc elle ne s'arrête jamais ou elle s'arrête n'importe quand.

4. Un agent

Évidemment. Le plus simple, c'est Claude Code avec un while true (la technique surnommée "Ralph") ou une commande dédiée. Le plus élaboré, c'est un harnais sur mesure : un agent sur un cron qui récupère des signaux dans tes données produit et distribue le travail à des sous-agents, ou une boucle qui génère son propre jeu de tests pour se vérifier.

Des exemples de loops qui marchent

Le concept devient limpide dès qu'on regarde des cas réels.

Le dernier est le plus impressionnant. C'est le principe de l'autoresearcher, une boucle qui itère seule pour battre une métrique. J'en ai parlé en détail dans mon article sur le pattern d'itération de Karpathy. Ce genre de loop a déjà servi à corriger des bugs qui traînaient depuis des années dans des moteurs de requête, en améliorant la performance au passage. Un humain n'aurait jamais eu la patience de tester autant d'hypothèses.

Pourquoi tout le monde en parle maintenant

La question légitime, c'est : pourquoi cette idée explose en 2026 et pas avant ? Parce que ce n'est pas né de deux tweets. C'est l'expression d'un progrès réel sur cinq fronts.

1. Les modèles tiennent des tâches longues. Il y a un an, un agent perdait le fil au bout de quelques minutes de travail autonome. Aujourd'hui, les meilleurs modèles enchaînent des tâches qui durent des heures sans dérailler. Une boucle n'a d'intérêt que si l'agent peut travailler longtemps sans supervision : c'est enfin le cas.

2. Des tâches énormes bouclées d'un coup. On voit passer des histoires de migrations de codebase entières faites en une journée, là où une équipe aurait mis deux mois à la main. Ou des apps sorties en un seul passage alors qu'avant il fallait des centaines d'allers-retours.

3. Les loops sont intégrées aux outils. Claude Code a une commande /loop, il existe des automatisations natives, et même un plugin qui industrialise la technique "Ralph". Tu n'as plus à bricoler ta boucle à la main, l'outillage est là.

4. Les sous-agents séparent la boucle du travail. La boucle principale peut lancer des sous-agents qui font le gros du travail et reviennent avec un rapport. Ça économise des tokens et ça empêche le contexte principal de se dégrader. C'est ce qui rend les boucles longues tenables.

5. Les harnais mûrissent. La compaction empêche la fenêtre de contexte de se remplir, les Skills et le MCP donnent aux agents plus d'outils, et l'exécution dans le cloud te permet de lancer une loop et de partir faire autre chose.

Les loops ne se sont pas matérialisées à partir de quelques tweets. Elles sont l'aboutissement d'un progrès qui touche toute l'industrie en même temps.

Ce n'est pas juste un truc d'IA de plus

Les sceptiques y voient une manœuvre des éditeurs de modèles pour te faire cramer des tokens. Je pense qu'il y a un objectif plus grand derrière : le produit qui s'améliore tout seul.

Plutôt qu'un humain qui doit prompter un agent pour faire avancer un projet, l'agent se prompte lui-même. Le produit s'améliore sans intervention, les problèmes utilisateurs se résolvent plus vite, et les chiffres montent.

Et voici ce qui devrait te parler si tu construis en solo : cette boucle, tu la fais déjà à la main. Tu :

1. Collectes de la donnée via ton analytics et en parlant à tes utilisateurs.
2. Construis et livres des améliorations basées sur cette donnée.
3. Évalues comment l'amélioration a performé, pour guider la suite.
4. Recommences, en continu.

C'est exactement la boucle du solo builder. La bascule qui arrive, c'est de faire tourner une partie de cette boucle en autonomie. Il y a des limites, bien sûr : les loops ne vont pas éliminer tout le travail d'ingénierie. Mais elles peuvent mettre les gains de 1% en pilote automatique : les bugs, les frictions UX, les micro-irritants, les petits réglages de conversion. Ces choses qui bouffent des heures mais qui ne demandent presque jamais de réflexion stratégique.

Plus tu automatises ces tâches, plus tu passes de temps sur le travail qui compte vraiment. Le "self" dans "self-driving" ne veut pas dire autonome vis-à-vis de toi. Il veut dire autonome vis-à-vis de l'instruction utilisateur comme point de départ.

Le code n'a jamais été le problème

L'opposition aux loops est facile à comprendre. C'est encore un changement dans la façon de construire du logiciel. S'entendre dire qu'on devrait "concevoir des boucles" donne l'impression d'être remplacé. Le travail s'éloigne de plus en plus de l'écriture de code.

Mais la montée du product engineer avait déjà montré une chose : écrire du code n'a toujours été qu'une petite partie du travail. La direction, le goût, l'empathie de celui qui construit restent critiques dans un futur piloté par des loops.

C'est précisément ce que je répète depuis le début sur ce blog. L'IA écrit le code. Toi, tu décides quoi construire, pour qui, et à quoi ressemble le "bien". Ça, aucune boucle ne le fera à ta place.

Questions fréquentes

C'est quoi une loop en IA, simplement ?

Une loop (ou boucle) est un agent IA placé dans une boucle qui se relance seule jusqu'à atteindre un objectif défini. Au lieu de prompter l'agent à chaque étape, tu conçois un système qui se prompte lui-même, va chercher son travail, vérifie son résultat et recommence. La vérification est faite par l'agent, pas par toi.

Quelle est la différence entre prompter un agent et concevoir une loop ?

Prompter, c'est donner des instructions une par une, en étant le moteur qui relance à chaque tour. Concevoir une loop, c'est construire un système qui se relance seul : tu définis l'objectif, le contexte, la méthode d'évaluation, et la boucle s'auto-corrige jusqu'à réussir. Tu passes de pilote à concepteur.

De quoi a-t-on besoin pour construire une loop ?

De quatre choses : un objectif vérifiable (sinon la boucle produit du slop), du contexte dosé et nourri en continu (outils, Skills, données, erreurs), une évaluation qui permet à l'agent de se contrôler (tests, évals, métriques), et un agent qui exécute. Enlève l'un des quatre et la boucle déraille.

Est-ce que les loops vont remplacer les développeurs ?

Non. Les loops automatisent les tâches répétitives et à faible enjeu stratégique : bugs, frictions UX, petits réglages. Elles ne remplacent pas la direction produit, le goût, ni la compréhension des utilisateurs. Elles libèrent du temps pour ce travail-là, qui reste humain.

Comment lancer sa première loop sans usine à gaz ?

Le plus simple est d'utiliser la commande /loop de Claude Code, ou un while true autour d'un agent avec un objectif clair et une évaluation automatique (par exemple : "corrige jusqu'à ce que les tests passent"). Commence sur une tâche bornée et vérifiable, comme faire passer une pull request au vert, avant de construire des harnais plus complexes.

Pour finir

Le passage du prompt à la loop, c'est le même genre de bascule que le passage du code écrit à la main au vibe coding. Au début ça déstabilise, puis ça devient la façon normale de travailler.

Si tu construis en solo, c'est une bonne nouvelle. Chaque boucle que tu mets en place, c'est une catégorie de travail répétitif que tu ne fais plus toi-même. Et le temps que tu récupères, tu le remets là où tu as un avantage que l'IA n'a pas : savoir quoi construire.

Commence petit. Une seule loop, sur une tâche que tu détestes faire et qui se vérifie toute seule. Tu verras vite si le futur te plaît.

À très vite,

Guillaume 👋