Les modèles plus intelligents résoudront-ils tout ?
Le récit dominant autour des outils de codage IA est le suivant : quand le modèle sera assez bon, il écrira du code, écrira des tests et refactorisera tout seul. Si GPT-4 n’a pas pu, GPT-5 le fera. Si Claude est insuffisant, un Claude plus grand s’en chargera.
Est-ce vraiment vrai ?
J’ai confié à Claude Opus 4.7 un refactoring filefunc. Il a terminé en une heure sans revue humaine. validate passé, pytest passé, couverture maintenue. En surface, cela correspond au récit « il suffit d’avoir un meilleur modèle ».
Mais que se passe-t-il si vous donnez au même modèle le même refactoring sans les règles filefunc ? Sans validate ? Sans feedback de couverture ? Le résultat est entièrement différent. Il tombe dans un doom loop — corriger un bug en casse un autre, corriger celui-ci en casse encore un autre.
Le même modèle. Ce qui a changé, c’est l’environnement.
« Terminé » — L’instinct de terminaison prématurée de l’agent
Une autre expérience avec le même modèle. J’ai lâché un agent sur un projet de 527 fonctions. « Écris des tests pour chaque fonction. » L’agent a fini et a rapporté : « Terminé. »
Fonctions ayant effectivement reçu des tests : 40. 40 sur 527.
L’agent n’a pas menti. Il en a fait 40 et a décidé « ça suffit ». La disposition par défaut d’un LLM est la terminaison prématurée optimiste. Face à une fonction difficile, il la saute, en fait quelques autres, puis conclut « le reste suit le même schéma, donc c’est bon ».
Après avoir forcé une boucle avec un outil CLI :
Agent autonome : 40 / 527 (7.6%) — l'agent déclare « terminé »
Boucle CLI : 527 / 527 (100%) — la machine déclare « il en reste 487 »
Le même modèle. Le même projet. La différence est qui décide quand c’est « terminé ».
L’environnement façonne le modèle
Les deux expériences pointent vers la même conclusion. Opus 4.7 n’a pas terminé parce qu’il était intelligent. Il a terminé parce que la surface de spécification était vérifiable par machine.
filefunc validate → La structure du code satisfait-elle les règles ?
pytest → Le comportement existant est-il préservé ?
coverage → Quelles branches manquent ?
Ces trois outils ont donné un feedback immédiat à chaque modification. Le modèle a reçu le feedback, a fait des corrections, a reçu du feedback à nouveau, a corrigé à nouveau. Une boucle autocorrective.
Voici l’insight clé :
La topologie du feedback détermine les résultats plus que le QI du modèle.
Les LLMs sont forts en génération mais faibles pour garantir la correction. Huang et al. (2024) ont démontré expérimentalement que quand les LLMs tentent d’autocorriger leur raisonnement sans feedback externe (oracle feedback), la performance peut en fait se dégrader. Cependant, en présence d’un vérificateur déterministe, la performance se stabilise drastiquement. lint, typecheck, test, coverage — ceux-ci deviennent le signal de gradient qui corrige la sortie du modèle.
« Ça se résoudra quand les modèles seront assez intelligents » est une proposition fausse. L’affirmation exacte est : « Si le feedback est assez rapide, les modèles actuels peuvent déjà le résoudre. »
broad exploration vs local correction
La force des LLMs n’est pas la broad exploration — c’est la local correction.
« Écris des tests pour ce projet » — c’est de la broad exploration. Le LLM perd sa direction.
« La ligne 41 n’est pas couverte » — c’est de la local correction. Le LLM écrit un test qui couvre exactement cette ligne.
Chiffres vérifiés sur des projets réels :
Sans feedback : s'arrête à 60–70% de couverture
Avec feedback : atteint 100% (pour les fonctions accessibles)
Le même modèle. La simple ligne « line 41 not covered » agit comme signal de gradient. Ce feedback guide les corrections du LLM exactement dans la bonne direction.
Symbolic Feedback Loop
Une structure traverse toutes ces observations.
Le LLM génère → un outil déterministe juge → le résultat est renvoyé au LLM → répéter
J’appelle cela un Symbolic Feedback Loop.
Le mainstream de l’industrie aujourd’hui est le LLM Feedback Loop — l’IA vérifiant l’IA. C’est comme un ivrogne demandant à un ami ivre : « Je suis saoul ? » Les deux sont probabilistes, donc les erreurs s’accumulent.
Le Symbolic Feedback Loop est différent. Chen et al. (2023) ont prouvé que le débogage itératif — renvoyer les messages d’erreur du compilateur et d’exécution au modèle — améliore drastiquement la précision du code. pytest n’hallucine pas. go test n’est jamais ivre. La mesure de couverture ne ment pas. La vérification de spécification ne dérive pas.
Cette structure fonctionne dans les domaines où la correction peut être jugée mécaniquement — code, tests, spécifications, types. L’élégance du design d’API ou le naturel de l’UX ne peuvent pas encore être jugés par des outils symboliques. Élargir cette frontière est le prochain défi. Je crois qu’une voie existe pour amener même le langage naturel dans des limites vérifiables.
Ce qu’AlphaCode (Li et al., 2022) a démontré en programmation compétitive suit le même principe. Ce n’est pas la capacité de génération du modèle en soi, mais la conception de l’environnement — générer des millions de candidats puis filtrer par les tests — qui a déterminé la performance. Plutôt que de rendre le modèle plus intelligent, il est plus efficace de rendre plus précis le feedback retourné au modèle.
Déléguer les décisions
Il est évident que les décisions ne doivent pas être déléguées à l’IA. Mais que les humains vérifient et décident de tout est épuisant. Certaines décisions répétitives et structurées peuvent être effectuées par des outils symboliques au nom des humains.
« Ces tests couvrent-ils toutes les branches ? » — aucun humain n’a besoin de les lire. Un outil de couverture juge. « Ce code satisfait-il les règles structurelles ? » — aucun humain n’a besoin de le revoir. validate juge. « Reste-t-il des fonctions non traitées ? » — aucun humain n’a besoin de compter. Le CLI déclare.
Les décisions qui ne peuvent pas être déléguées à l’IA peuvent être déléguées à des outils symboliques — car ils sont déterministes, pas probabilistes. C’est la raison d’être du Symbolic Feedback Loop.
Il est plus important de poser les rails que de rendre le train plus rapide.
Beaucoup de gens construisent des trains. Presque personne ne pose de rails.
Références
- Jie Huang, Xinyun Chen, Swaroop Mishra, Huaixiu Steven Zheng, Adams Wei Yu, Xinying Song, Denny Zhou. “Large Language Models Cannot Self-Correct Reasoning Yet.” ICLR 2024.
- Xinyun Chen, Maxwell Lin, Nathanael Scharli, Denny Zhou. “Teaching Large Language Models to Self-Debug.” arXiv:2304.05128, 2023.
- Yujia Li, David Choi, Junyoung Chung, Nate Kushman, Julian Schrittwieser, Remi Leblond, Tom Eccles, et al. “Competition-Level Code Generation with AlphaCode.” Science 378(6624): 1092-1097, 2022.
- Noah Shinn, Federico Cassano, Ashwin Gopinath, Karthik Narasimhan, Shunyu Yao. “Reflexion: Language Agents with Verbal Reinforcement Learning.” NeurIPS 2023.
- Aman Madaan, Niket Tandon, Prakhar Gupta, et al. “Self-Refine: Iterative Refinement with Self-Feedback.” NeurIPS 2023.
- Timo Schick, Jane Dwivedi-Yu, Roberto Dessi, et al. “Toolformer: Language Models Can Teach Themselves to Use Tools.” NeurIPS 2023.
- Mert Cemri, Melissa Z. Pan, Shuyi Yang, et al. “Why Do Multi-Agent LLM Systems Fail?” NeurIPS 2025 Datasets and Benchmarks Track.
- Carlos E. Jimenez, John Yang, Alexander Wettig, et al. “SWE-bench: Can Language Models Resolve Real-World GitHub Issues?” ICLR 2024.
Article lié : Ratchet Pattern — Comment faire terminer le travail à un agent — L’implémentation pratique de cette théorie. Un pattern qui force les agents à converger.
Outil lié : tsma — Un exemple fonctionnel du Ratchet Pattern. 527 fonctions, zéro TODO.
Journal des modifications
- 2026-05-14: Version initiale