Pourquoi les agents de code fonctionnent et pourquoi ils s'effondrent

Pourquoi les agents de code fonctionnent et pourquoi ils s’effondrent

Le même modèle. Celui qui hallucinait dans le chat web livre une fonctionnalité de 200 lignes dans Claude Code en un seul coup. Le /goal de Codex résout un issue entier. Le modèle n’est pas soudainement devenu plus intelligent. Ce qui a changé, c’est la structure.

Pourquoi ils fonctionnent

La boucle de l’IA conversationnelle ressemble à ceci :

LLM → humain → LLM → humain

Tout le feedback est en langage naturel. Génération probabiliste suivie d’évaluation probabiliste. La précision se dégrade en produit.

La boucle des agents de code est différente :

LLM → génération de code → sauvegarde de fichier → exécution de test → pass/fail → LLM
LLM → modification de code → build → succès/échec → LLM
LLM → vérification de types → message d'erreur → LLM

Des portes déterministes sont intégrées dans la boucle. Le système de fichiers sauvegarde exactement ce qui a été écrit. Un test est pass ou fail. Le compilateur dit faux quand c’est faux. Ceux-ci servent involontairement de ratchets.

Un LLM est un composant non fiable. Mais construire un protocole fiable sur des composants non fiables est un fondamental de l’ingénierie. Von Neumann a prouvé mathématiquement en 1956 que le vote majoritaire seul peut faire en sorte que des composants bruités effectuent des calculs fiables (Von Neumann, 1956). TCP construit une livraison fiable sur un réseau non fiable. RAID construit un stockage fiable sur des disques non fiables. ECC construit un calcul fiable sur une mémoire non fiable.

La raison pour laquelle les agents de code fonctionnent est la même. Un LLM non fiable est complété par des vérificateurs déterministes (tests, builds, linters, vérificateurs de types). L’étude SWE-agent a démontré que même le même modèle montre des performances radicalement différentes selon la conception de l’Agent-Computer Interface (Yang et al., NeurIPS 2024). C’est la topologie, pas la capacité du modèle, qui cause le succès.

Mais pourquoi s’effondrent-ils ?

Ils fonctionnent, ai-je dit. Mais ils s’effondrent parfois. Pourquoi ?

Parce que les ratchets présents par accident et les ratchets consciemment conçus sont deux choses différentes.

Des zones sans ratchet existent

Quand un agent modifie du code sans tests ? Le build passe, le lint passe, mais la fonctionnalité est cassée. Dans les zones sans portes déterministes, le LLM juge de manière probabiliste, et les jugements probabilistes se dégradent en produit.

Sur 200 endpoints, 180 ont des tests et 20 n’en ont pas. L’agent gère parfaitement les 180 et plante silencieusement des bugs dans les 20. C’est pourquoi on obtient « presque fini, mais quelque chose cloche ».

L’information du feedback est insuffisante

J’ai fait une expérience de tri avec 1 000 mots. CPU : 0,08ms à 100%. LLM : 438 secondes à 97,7%. C’est déjà remarquable — 97,7% par cognition pure. Mais la vraie découverte était ailleurs.

J’ai seulement varié le niveau de feedback sur le même résultat :

Feedback	Résultat
Aucun	6 erreurs (99,4%)
« Il y a des erreurs »	10 erreurs (99,0%) — pire
« Il y a 23 erreurs »	1 erreur (99,9%)
« 6 erreurs, les voici »	0 erreurs (100%)

Dire seulement « tu as tort » cause une sur-correction et empire les choses. Donner un décompte crée un objectif à atteindre. Donner les emplacements atteint la perfection.

La plupart des agents aujourd’hui opèrent au deuxième niveau. Quand un test échoue, ils savent « quelque chose ne va pas », mais ne transmettent pas la raison structurelle. Les messages d’erreur existent, mais ce sont des symptômes, pas des causes.

Les angles morts existent et la répétition ne les corrige pas

Dans l’expérience de tri, le LLM a laissé 6 erreurs au R2. Au R3, il a rapporté « aucune erreur ». Au R4b, il a de nouveau rapporté « aucune erreur ». Il a manqué les mêmes 6 de la même manière.

Sans indice, peu importe le nombre de répétitions, il convergeait à 99,4%. C’est seulement quand on lui a dit « il en reste 6 » qu’il a finalement atteint 100%.

La même chose se passe avec les agents de code. L’agent crée un bug, fait une auto-revue avec « ça a l’air bien », et quand on lui demande de corriger à nouveau, rate le même endroit. Huang et al. (2024) ont montré que sans feedback externe, l’auto-correction des erreurs de raisonnement par les LLMs dégrade en fait les performances (Huang et al., ICLR 2024). C’est pourquoi retry n’est pas la réponse. Les angles morts sont une limitation structurelle de la nature probabiliste du modèle, pas un manque d’effort.

La multiplication fonctionne à l’échelle

97,7% de précision enchaînée deux fois : 0,977² = 95,4%. Trois fois : 93,2%. Dix fois : 79,2%.

Un agent modifiant un seul fichier s’en sort bien. Mais demandez-lui de refactoriser 100 fichiers ? Même à 97% par étape, 100 étapes donnent 0,97¹⁰⁰ = 4,8%. L’échec est virtuellement garanti.

C’est l’explication mathématique de « le vibe coding s’effondre à 200 endpoints ». Dans les petits projets, le nombre de chaînages est assez bas pour que la probabilité tienne. Dans les grands projets, la multiplication devient catastrophique.

Ce qui est nécessaire

Les raisons du fonctionnement et les raisons de l’effondrement pointent vers le même endroit : la présence ou l’absence de portes de vérification déterministe.

Les agents actuels dépendent de ratchets présents par accident (tests, builds, linters). Les concevoir consciemment les rend plus forts.

Ce que signifie concevoir des ratchets consciemment :

Premièrement, identifier les zones sans ratchet. Du code sans tests, des API sans schémas, des données sans types. Chaque endroit où l’agent juge de manière probabiliste est une vulnérabilité.

Deuxièmement, augmenter le contenu informationnel du feedback. Ne retourner que pass/fail induit une sur-correction. « Où, pourquoi et en quoi le réel diffère de l’attendu » doit être communiqué de manière structurée.

Troisièmement, insérer des portes déterministes entre les étapes de chaînage. Exécuter 10 étapes d’un coup rend la multiplication catastrophique, mais verrouiller avec un ratchet à chaque étape réinitialise la dégradation.

Les LLMs sont des générateurs remarquables. Ils trient 1 000 mots à 97,7% de précision par cognition pure. Les humains ne peuvent pas faire cela. Mais tout ce qui est en dessous de 100% s’effondre sous la répétition. 0,977 au carré fait 0,954.

Les agents de code fonctionnent non pas parce que le modèle est intelligent. Ils fonctionnent parce que des portes déterministes sont intégrées dans la boucle. Ils s’effondrent parce que ces portes sont absentes.

La génération peut être probabiliste. La vérification doit être déterministe.

Références

Von Neumann, J. (1956). “Probabilistic Logics and the Synthesis of Reliable Organisms from Unreliable Components.” In Shannon, C.E. & McCarthy, J. (Eds.), Automata Studies, Annals of Mathematical Studies, No. 34, Princeton University Press, pp. 43-98.
Saltzer, J.H., Reed, D.P., & Clark, D.D. (1984). “End-to-End Arguments in System Design.” ACM Transactions on Computer Systems, 2(4), 277-288.
Patterson, D.A., Gibson, G., & Katz, R.H. (1988). “A Case for Redundant Arrays of Inexpensive Disks (RAID).” Proceedings of the 1988 ACM SIGMOD International Conference on Management of Data, pp. 109-116.
Hamming, R.W. (1950). “Error Detecting and Error Correcting Codes.” The Bell System Technical Journal, 29(2), 147-160.
Yao, S. et al. (2023). “ReAct: Synergizing Reasoning and Acting in Language Models.” ICLR 2023.
Shinn, N. et al. (2023). “Reflexion: Language Agents with Verbal Reinforcement Learning.” NeurIPS 2023.
Jimenez, C.E. et al. (2024). “SWE-bench: Can Language Models Resolve Real-World GitHub Issues?” ICLR 2024.
Yang, J. et al. (2024). “SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering.” NeurIPS 2024.
Huang, J. et al. (2024). “Large Language Models Cannot Self-Correct Reasoning Yet.” ICLR 2024.
Kamoi, R. et al. (2024). “When Can LLMs Actually Correct Their Own Mistakes? A Critical Survey of Self-Correction of LLMs.” TACL, 12, 1298-1318.
Cemri, M. et al. (2025). “Why Do Multi-Agent LLM Systems Fail?” arXiv:2503.13657.
Arbuzov, M.L., Shvets, A.A., & Beir, S. (2025). “Beyond Exponential Decay: Rethinking Error Accumulation in Large Language Models.” arXiv:2505.24187.