La fiabilité d'un agent IA n'est pas une moyenne : Sisyphe et l'autocorrection

Six rapports pour rien

La semaine dernière, j'ai laissé tourner un agent chargé de rédiger une synthèse de marché. Je lui avais glissé une consigne qui semblait vertueuse : relis-toi, critique ta production, améliore-la, recommence jusqu'à satisfaction.

Six itérations plus tard, j'avais six versions du même rapport. Chacune subtilement différente, aucune objectivement meilleure. Un paragraphe reformulé ici, un adjectif déplacé là, une transition « renforcée » qui alourdissait le propos.

L'agent était persuadé de progresser. À chaque passe, il produisait une critique élogieuse de sa propre amélioration. Le coût : environ quatre fois les tokens d'une génération unique, une latence multipliée, et une confiance affichée qui n'avait aucun fondement mesurable.

J'avais sous les yeux un rocher qui remontait, puis retombait.

Sisyphe, ou l'effort sans terminaison

Le mythe est connu : condamné par les dieux à rouler un rocher jusqu'au sommet d'une montagne, Sisyphe voit la pierre redescendre chaque fois qu'il touche au but. Un châtiment pensé comme l'horreur absolue — le travail inutile, infiniment répété.

En 1942, dans Le Mythe de Sisyphe, Albert Camus retourne la condamnation. Il imagine Sisyphe redescendant vers son rocher, conscient de l'absurde, et conclut par une phrase célèbre : « Il faut imaginer Sisyphe heureux. » Le sens ne vient pas de la tâche — il vient de la lucidité du héros sur sa condition.

C'est exactement le piège de la boucle d'autocorrection mal conçue. Un agent qu'on force à se relire indéfiniment ressemble à Sisyphe heureux : il travaille, il produit, il semble consciencieux. Mais sa « satisfaction » est une fiction générée par le même modèle qui a produit l'erreur initiale.

Camus tirait du rocher une leçon de dignité humaine. L'agent, lui, n'a aucune lucidité à opposer à l'absurde. Son « bonheur » n'est qu'une métrique interne décorrélée du réel. Il remonte la pierre pour de mauvaises raisons.

Deux autocorrections qu'il faut cesser de confondre

Le cœur du problème est une distinction que la plupart des prompts ignorent. Il existe deux familles d'autocorrection, et elles n'ont rien à voir.

La première est introspective : l'agent se relit et se juge avec le même modèle qui a généré la réponse. Aucune information nouvelle n'entre dans le système. Le juge et le prévenu partagent exactement les mêmes biais.

La seconde est ancrée : la critique reçoit un signal externe vérifiable. Un test unitaire qui passe ou échoue, un compilateur qui refuse le code, une API qui confirme une donnée, un schéma JSON qui valide — ou non — la structure.

La revue critique de référence sur le sujet, When Can LLMs Actually Correct Their Own Mistakes? de Kamoi et ses coauteurs (TACL, 2024), est sans ambiguïté. Le point faible n'est pas la capacité à réécrire — c'est la capacité à produire un feedback fiable sur sa propre réponse.

Les auteurs rapportent que l'autocorrection purement intrinsèque peut ne rien améliorer, voire dégrader les performances : raisonnement arithmétique, questions-réponses sans document, génération de code, planification. Les résultats positifs apparaissent quand le système dispose d'un interpréteur, d'un moteur de recherche, d'un solveur symbolique — bref, d'un oracle indépendant.

J'ai déjà exploré pourquoi la vérification socratique d'un agent sur lui-même ne suffit pas à le rendre fiable. La boucle d'autocorrection en est le prolongement direct : se critiquer n'est utile que si la critique apprend quelque chose de neuf.

Les trois pièges du rocher

Premier piège : la boucle infinie déguisée en robustesse. On présente les itérations supplémentaires comme un gage de sérieux. En réalité, rien ne garantit qu'une passe de plus améliore quoi que ce soit — elle ajoute du coût et de l'illusion.

Deuxième piège : la sur-correction. Un préprint récent, Self-Correction as Feedback Control (arXiv, 2026), analyse l'autocorrection comme un problème de contrôle en boucle de rétroaction. Sur GSM8K, MATH et StrategyQA, les auteurs observent une frontière proche de la neutralité : certains modèles perdent plusieurs points de précision après correction, transformant une bonne réponse en mauvaise.

Fait notable du même travail : une instruction de type verify first — vérifier avant de modifier — peut transformer une dégradation en léger gain. La séquence compte autant que la boucle.

Troisième piège : la fausse métrique. C'est le plus insidieux. On mesure le nombre de corrections, la richesse des critiques, le volume de réflexion produit. Jamais le taux de succès final vérifiable. Un agent qui génère six critiques détaillées paraît plus rigoureux qu'un agent qui répond juste du premier coup — et il l'est moins.

Transformer l'introspection en vérification

La bonne nouvelle : l'autocorrection n'est pas condamnée. Elle devient productive dès qu'on remplace le miroir par un instrument.

L'étude ProgCo (ACL 2025) en donne l'illustration la plus nette. Plutôt que « relis ta réponse et améliore-la », le système fait générer au modèle des pseudo-programmes de vérification, les exécute, puis révise en fonction du résultat. Les gains progressent encore quand on branche de vrais outils programmatiques.

La différence est structurelle. « Améliore-toi » est une invitation à l'introspection circulaire. « Soumets ta réponse à cette procédure, puis corrige selon ce qu'elle renvoie » injecte un signal exogène. Le rocher trouve enfin un cran où se caler.

Quatre gestes que j'applique sur mes propres agents

Quand je conçois un agent autocorrectif pour un client — ce qui fait partie du cœur des solutions sur mesure que je déploie, je m'impose quatre règles.

Je définis un critère d'arrêt fondé sur un oracle externe. La boucle ne se termine pas quand l'agent se déclare satisfait, mais quand un test passe, un schéma valide, une API confirme. Pas d'oracle disponible ? Je n'active pas de boucle introspective — je préfère une génération unique soignée.

Je plafonne deux budgets simultanément : le nombre d'itérations et les tokens. Trois passes maximum, un plafond de coût explicite. La « robustesse » infinie est une dette déguisée.

Je mesure le delta de qualité réel entre itérations. Si la vérification externe ne bouge plus, je coupe — même si les critiques de l'agent deviennent plus éloquentes. L'éloquence de la critique n'est pas un signal de progrès.

Je réserve l'autocorrection aux tâches où un vérificateur indépendant existe. Code, extraction structurée, calculs, requêtes — oui. Rédaction de ton éditorial, jugement stylistique, synthèse ouverte — non. Là, la boucle n'est que du théâtre.

Cette discipline de l'arrêt rejoint une question que j'ai creusée ailleurs sous un autre angle : savoir quand un agent doit cesser son travail, à la manière d'une cellule qui programme sa propre mort. Mais là où l'apoptose relève du garde-fou de sécurité, l'autocorrection relève de la qualité de la boucle d'amélioration.

Imaginer l'agent lucide

La fiabilité d'un agent IA n'est pas une moyenne de ses tentatives, ni le volume de son introspection. Elle se joue sur un point d'ancrage dans le réel — un signal que l'agent ne peut pas fabriquer lui-même.

Camus voulait qu'on imagine Sisyphe heureux parce qu'il était lucide. Un agent qui se corrige sans signal externe est un Sisyphe heureux pour de mauvaises raisons : il travaille, il se félicite, et le rocher retombe.

La seule lucidité que je puisse lui donner, c'est un oracle. Sans quoi l'autocorrection n'est pas de la rigueur — c'est un rituel coûteux qui confond l'effort avec le résultat.