Pourquoi votre agent ne s’arrête jamais Image: AI generated

La fierté du 24/7

« Je fais tourner mon agent 24 heures sur 24. »

C’est une phrase que l’on voit souvent sur X. Comme si plus un agent tournait longtemps, plus il accomplissait de travail. Comme si une personne qui ne dort pas était plus productive.

Mais devant cette phrase, le sentiment qui surgit n’est pas l’admiration, c’est l’interrogation.

« Pourquoi n’a-t-il pas encore fini ? »

Un système sain est un système capable de s’arrêter

J’ai confié à un agent la tâche d’écrire des tests pour 527 fonctions. Résultat :

Agent autonome :  40 / 527 terminées, puis déclare « C'est fait »
Boucle CLI :      527 / 527 menées à terme, puis arrêt

La boucle CLI a pris une heure. Pas vingt-quatre. Elle traite une fonction, la vérifie, passe à la suivante si elle réussit, et s’arrête quand tout est terminé. Le cœur de cette boucle n’est pas la vitesse, c’est que la condition d’arrêt est définie mécaniquement.

TODO → écriture du test → mesure de couverture → PASS/DONE → suivante → ... → tout terminé → arrêt

finite. measurable. monotonic. C’est pourquoi elle converge. C’est pourquoi elle s’arrête.

Pouvoir s’arrêter n’est pas une faiblesse. C’est un signe de santé.

Les trois raisons de ne pas s’arrêter

Quand un agent tourne longtemps, c’est généralement pour l’une de ces trois raisons.

1. Le vérificateur est faible

"looks good"
"seems better"
"more scalable"
"clean architecture"

Ce ne sont pas des critères de convergence. Ce sont des jugements subjectifs. go test renvoie pass/fail, mais « clean architecture », qui en décide ? Un autre LLM ? C’est comme demander à un ami ivre : « Est-ce que je suis ivre ? »

Les données empiriques le confirment. Les juges LLM employés pour évaluer du code se laissent biaiser par des variations superficielles de code sémantiquement équivalent, gonflant ou rabaissant injustement les scores (Moon et al. 2025), et les modèles fléchissent leur propre réponse pour s’aligner dans 58,19 % des cas (SycEval, Fanous et al. 2025). « looks good » n’a aucun rapport avec la justesse. De plus, un critère faible ne se contente pas de ne pas s’arrêter — quand la mesure devient l’objectif, la mesure se corrompt (loi de Goodhart ; Manheim & Garrabrant 2018), et les modèles de raisonnement compétents, au lieu d’attaquer la tâche de front, piratent la procédure de vérification elle-même (Bondarenko et al. 2025).

Sans critère de convergence, il n’y a pas de fin.

2. Il n’y a pas de frontière de tâche

"améliore la base de code"
"rends l'architecture plus propre"
"continue à optimiser"

Ce sont des tâches sans condition d’arrêt. Même un développeur humain s’égare sans fin avec de tels objectifs. Un agent n’y échappe pas. « Améliorer » est une direction, pas une destination.

3. L’entropie dépasse la vitesse de correction

C’est le schéma le plus fréquent et le plus insidieux.

L’agent, en modifiant, ajoute des abstractions. Il introduit des indirections. Il crée des généralisations inutiles. Le code semble « s’améliorer », mais en réalité la nouvelle entropie croît plus vite que le vérificateur ne l’élimine.

l'abstraction créée aujourd'hui → est retirée demain → puis rajoutée après-demain

C’est de l’optimisation non monotone (non-monotonic optimization). On a l’impression d’avancer, mais on fait du surplace. Cela ressemble à une machine à mouvement perpétuel, mais cela ne fait que consommer de l’énergie. Et ici, l’énergie, ce sont les tokens.

De vastes études empiriques captent cette dérive. L’adoption de Cursor a accru la vitesse à court terme, mais les avertissements d’analyse statique et la complexité du code n’ont cessé d’augmenter, et cette accumulation a été la cause principale du ralentissement à long terme (He et al. 2025, 807 dépôts open source). Sur plus de 300 000 commits écrits par l’IA, 22,7 % des problèmes introduits ont survécu jusqu’à la dernière version sous forme de dette technique (Liu et al. 2026). La correction ne rattrape pas l’entropie.

Ce n’est pas un problème de recherche, mais de satisfaction de contraintes

C’est ici qu’apparaît une différence de perspective fondamentale.

« Faire tourner un agent longtemps donne de meilleurs résultats » est un regard qui voit l’ingénierie logicielle comme un problème de recherche (search problem). L’attente qu’en explorant longtemps un vaste espace, on trouvera une meilleure solution.

Mais l’ingénierie logicielle est par essence un problème de satisfaction de contraintes (constraint satisfaction problem).

  • les types doivent correspondre
  • les tests doivent passer
  • la couverture doit être atteinte
  • le schéma doit concorder
  • les règles de lint doivent être respectées

Une fois toutes ces contraintes satisfaites, c’est fini. Il n’y a pas besoin de « chercher davantage ». Définir les contraintes, les satisfaire, et s’arrêter. C’est tout.

Le code est déjà un domaine vérifiable mécaniquement (machine-checkable domain). Compilateur, type-checker, tests, couverture, linter, validation de schéma — tout cela est un vérificateur déterministe. Puisque ces vérificateurs existent, pourquoi faire chercher un agent sans fin ?

La recherche sur l’apprentissage pointe dans la même direction. Utiliser un vérificateur déterministe comme les tests unitaires en guise de récompense — une récompense vérifiable (verifiable reward) — donne une justesse de code supérieure à la génération ouverte (CodeRL, Le et al. 2022 ; RLTF, Liu et al. 2023). Le vérificateur n’est pas un outil pour réduire la recherche. C’est la preuve que ce problème n’a jamais été de la recherche, mais de la satisfaction.

Les conditions d’une bonne boucle

Une bonne boucle d’agent se referme en cinq étapes :

1. Définir la tâche    — qu'est-ce qui doit être accompli (objectif jugeable mécaniquement)
2. Limiter la portée   — une seule unité à la fois (fonction, endpoint, fichier)
3. Vérifier symboliquement — un outil déterministe rend un verdict pass/fail
4. Converger           — si ça passe, on continue ; si ça échoue, on réessaie avec retour
5. Terminer            — s'il ne reste plus rien, on s'arrête

Dans cette structure, le LLM ne se charge que de l’étape 3 (la génération). Tout le reste est fait par la machine. En particulier, le point clé est que c’est la machine qui décide de la « fin ». Si l’on confie au LLM le jugement d’arrêt, on s’entend dire « C’est fait » à 40/527.

L’expérimentation va dans le même sens. Ajouter une auto-critique (self-critique) à un LLM fait au contraire s’effondrer ses performances sur les tâches de raisonnement et de planification, et celles-ci ne s’améliorent fortement que lorsqu’on lui adjoint un vérificateur externe sain (Stechly et al. 2024). L’auto-correction intrinsèque, sans retour externe, échoue, et parfois aggrave les choses après correction (Huang et al. 2023). Il y a une raison de ne pas confier l’arrêt au LLM.

creative writing et code, ce n’est pas pareil

Il y a une exception. Tous les domaines ne sont pas ainsi.

L’écriture, le marketing, le design — dans ces domaines, le vérificateur est faible. On ne peut pas juger mécaniquement « cette phrase est-elle bonne ? ». Dans ces domaines, une longue exploration peut avoir du sens. L’agent génère plusieurs variantes, et l’humain choisit.

Mais le code, c’est différent. Le code est déjà un monde rempli de vérificateurs déterministes. Dans ce monde, l’errance prolongée (wandering) n’est pas de la recherche, c’est de la dérive (drift).

La question

Depuis combien d’heures votre agent tourne-t-il en ce moment ?

Est-il en train de converger, ou de dériver ?

Peut-il s’arrêter ?

Et s’il le peut, pourquoi ne s’est-il pas encore arrêté ?

Articles liés

Pour aller plus loin (sources externes)

  • Designing agentic loops — Simon Willison. Une boucle d’agent ne se vérifie elle-même et ne s’arrête que s’il existe des critères de succès clairs et une suite de tests qui passe — le pendant constructif de cet article.
  • Building Effective Agents — Anthropic. Si le codage est idéal pour les agents, c’est parce que la solution est vérifiable par des tests automatisés — le vérificateur déterministe devient le signal d’arrêt.
  • Termination logic is the underrated design problem in agentic AI systems — Glen Rhodes. La décision de conception clé n’est pas un meilleur modèle mais une condition d’arrêt mesurable, et il met en garde contre le « confidence laundering » où une sortie fluide masque la non-convergence.
  • Harness engineering for coding agent users — Birgitta Böckeler, Thoughtworks. La fiabilité ne vient pas du modèle mais du harnais d’outils déterministes (computational controls) — à distinguer du contrôle inférentiel piloté par l’IA.
  • Reward Hacking in Reinforcement Learning — Lilian Weng. « Quand la mesure devient l’objectif, elle cesse d’être une bonne mesure » — une synthèse technique du mécanisme par lequel un vérificateur faible utilisé comme récompense se fait gamer par le proxy.
  • Context Rot: How Increasing Input Tokens Impacts LLM Performance — Chroma. Plus les tokens d’entrée s’accumulent, plus la sortie se dégrade — la cause mécanique pour laquelle une boucle qui ajoute, retire et rajoute sans cesse devient de l’auto-renforcement plutôt que de l’auto-correction.
  • Vibe Coding Will Destroy Your Codebase (But You’re Probably Not Doing It) — Ariel Perez. L’IA amplifie la rigueur existante — avec une faible rigueur, elle accélère le chaos : une perspective de terrain sur le phénomène où l’entropie devance la correction.

Sources

Jugement d’arrêt · limites de l’auto-vérification

  • Stechly et al. “On the Self-Verification Limitations of Large Language Models on Reasoning and Planning Tasks” (2024, arXiv:2402.08115)
  • Huang et al. “Large Language Models Cannot Self-Correct Reasoning Yet” (2023, arXiv:2310.01798)

LLM-as-judge · manque de fiabilité de l’auto-critique

  • Gu et al. “A Survey on LLM-as-a-Judge” (2024, arXiv:2411.15594)
  • Moon et al. “Don’t Judge Code by Its Cover: Exploring Biases in LLM Judges for Code Evaluation” (2025, arXiv:2505.16222)
  • Fanous et al. “SycEval: Evaluating LLM Sycophancy” (2025, arXiv:2502.08177)

Dérive · augmentation de la complexité du code IA

  • He et al. “Speed at the Cost of Quality: How Cursor AI Increases Short-Term Velocity and Long-Term Complexity in Open-Source Projects” (2025, arXiv:2511.04427)
  • Liu et al. “Debt Behind the AI Boom: A Large-Scale Empirical Study of AI-Generated Code in the Wild” (2026, arXiv:2603.28592)

Récompense vérifiable · génération de code fondée sur un vérificateur

  • Le et al. “CodeRL: Mastering Code Generation through Pretrained Models and Deep Reinforcement Learning” (2022, arXiv:2207.01780)
  • Liu et al. “RLTF: Reinforcement Learning from Unit Test Feedback” (2023, arXiv:2307.04349)

Reward hacking · specification gaming

  • Bondarenko et al. “Demonstrating Specification Gaming in Reasoning Models” (2025, arXiv:2502.13295)
  • McKee-Reid et al. “Honesty to Subterfuge: In-Context Reinforcement Learning Can Make Honest Models Reward Hack” (2024, arXiv:2410.06491)
  • Manheim & Garrabrant. “Categorizing Variants of Goodhart’s Law” (2018, arXiv:1803.04585)
  • Amodei et al. “Concrete Problems in AI Safety” (2016, arXiv:1606.06565)