Ratchet Pattern — comment forcer un agent à aller jusqu'au bout

Ratchet Pattern

Si votre agent IA dit « c’est fait » alors que ce n’est pas vraiment termine, si l’agent saute les taches difficiles, si vous voulez que ce soit une machine – et non un humain – qui determine l’achevement – cet article explique cette structure.

« C’est fait »

J’ai demandé à un agent AI d’écrire les tests de 527 fonctions. L’agent a terminé son travail et a rendu son rapport :

« Terminé. »

En réalité, des tests avaient été écrits pour 40 fonctions.

Il n’a pas menti. Après 40 fonctions, il a simplement jugé que c’était suffisant. Face à une fonction difficile, il la saute, en traite quelques autres, puis conclut : « Le reste suit le même schéma, ça ira. »

Le LLM excelle à générer. Mais son évaluation de l’achèvement n’est pas fiable. Huang et al. ont démontré expérimentalement que l’autocorrection du LLM sans feedback externe peut en réalité dégrader les performances[1].

Le cliquet

La clé à cliquet possède des dents qui ne s’engagent que dans un sens. On tourne : ça avance. On relâche : ça s’arrête, mais ça ne recule jamais.

Le Ratchet Pattern applique ce mécanisme au contrôle d’un agent. Le code de vérification écrit selon ce pattern s’appelle ratchet code — du code qui ne permet jamais de régression en dessous d’un niveau de vérification précédemment atteint.

Élément 1 : vérification mécanique → PASS → suivant
Élément 2 : vérification mécanique → FAIL → nouvel essai (avec feedback)
Élément 2 : vérification mécanique → PASS → suivant
...
Élément N : PASS → terminé. Arrêt.

Trois règles :

Ne montrer qu’un seul élément à la fois.
Le suivant ne s’ouvre qu’après validation du précédent.
Quand tout est validé, on s’arrête.

Implémentez ces règles dans un CLI, et l’agent n’a besoin de connaître qu’une seule commande : next. Le reste, c’est la machine qui décide.

L’agent s’arrête à 40, le cliquet va jusqu’à 527

Même modèle. Même projet. Mêmes 527 fonctions.

Agent autonome :  40 / 527  (7.6%)  — l'agent a déclaré "terminé"
Ratchet CLI :    527 / 527 (100%)  — la machine a déclaré "encore 487 à faire"

La différence ne tient pas à la performance du modèle. Elle tient à qui décide de la fin.

En mode autonome, c’est le LLM qui décide quand s’arrêter. Le LLM est optimiste. Après 40 éléments, il « sent » que c’est assez. Dans l’analyse de traces de 1 600 exécutions d’agents par Cemri et al., la terminaison prématurée — déclarer l’objectif atteint avant qu’il ne le soit réellement — représentait 6,2 % de tous les modes de défaillance[2]. Avec le cliquet, c’est la machine qui décide. La machine ne ressent rien. Elle déclare « pas encore » tant que le nombre d’éléments restants n’est pas zéro.

Définition en une phrase

Placer un agent probabiliste à l’intérieur d’une machine à états déterministe.

Rôle	Responsable
Génération	LLM
Jugement	verifier
Gestion de la progression	ratchet

Beaucoup de systèmes confient la génération, le jugement et la décision d’arrêt au LLM. Ratchet sépare ces responsabilités.

Cinq principes

1. La condition d’arrêt est mécanique

pass/fail. Pas « looks good ». go test passe : PASS. coverage à 100% : PASS. Aucune place pour le jugement subjectif.

2. Un PASS est immuable

Un élément validé ne se rouvre pas. On ne revient pas en arrière. Le nombre d’éléments restants décroît de façon monotone.

remaining_work(t+1) ≤ remaining_work(t)

Ce qui est fait aujourd’hui n’est pas défait demain. On ne va que vers l’avant. C’est la différence fondamentale avec un « agent 24 heures ». Un agent sans condition d’arrêt ajoute une abstraction aujourd’hui, la supprime demain, la rajoute après-demain. Le cliquet interdit ces oscillations.

3. Le LLM ne fait que générer

Générer du code, écrire des tests, proposer des corrections — voilà le rôle du LLM. Quoi corriger, est-ce validé, quelle est la suite, est-ce fini — tout cela, c’est la machine qui en décide. Le LLM n’est pas un planner, c’est un constrained generator.

4. On retire à l’agent le droit de décider de la fin

Quand c’est le LLM qui dit « c’est fait », on s’arrête à 40. Quand c’est la machine qui dit « c’est fait », on s’arrête à 527. La raison d’être du cliquet tient en cette seule ligne.

5. Le Verifier doit être déterministe

Tout ne peut pas servir de verifier.

Peut l’être	Ne peut pas l’être
`go test`	“looks cleaner”
mesure de coverage	“seems better”
AST validation	“more scalable”
schema diff	“clean architecture”

Conditions d’un Verifier : deterministic, machine-checkable, resumable, localized feedback. Si l’une de ces quatre conditions n’est pas remplie, les dents du cliquet ne s’engagent pas.

Le feedback comme gradient signal

Si le cliquet ne renvoie que « pass/fail », le LLM corrige à l’aveugle. Plus le feedback est précis, plus la correction du LLM est exacte.

Feedback faible :  "test échoué"              → le LLM corrige sans direction
Feedback moyen :   "coverage 65%"             → le LLM renforce approximativement
Feedback fort :    "line 41, 44, 70 non couvertes" → le LLM couvre exactement ces branches

Chiffres vérifiés sur un projet réel :

Sans feedback :  60-70% de coverage puis stagnation
Avec feedback :  100% atteint (pour les fonctions atteignables)

Même modèle. Une seule ligne — « line 41 not covered » — joue le rôle de gradient signal. La recherche Self-Debug de Chen et al. a prouvé que le débogage itératif en renvoyant les messages d’erreur du compilateur/runtime au modèle améliore considérablement la précision du code[3].

Plus la résolution du feedback augmente, plus la précision des corrections du LLM s’améliore, plus le nombre d’itérations diminue, plus le coût baisse.

L’agent meurt. La progression survit.

Un agent finit toujours par tomber. Limite de tokens, erreur réseau, coupure de session. Si le cliquet persiste l’état de progression, l’agent suivant reprend là où le précédent s’est arrêté.

Agent A : fonctions 1-200 traitées → arrêt
Agent B : next → reprise à partir de 201
Agent C : next → reprise à partir de 401

L’agent est jetable. La progression s’accumule.

Changez le Verifier, vous obtenez un autre outil

Le cliquet n’est lié à aucun vérificateur en particulier. Changez le vérificateur et vous obtenez un outil différent.

Cliquet + vérificateur	Usage
Cliquet + `go test` + coverage	Génération de tests par fonction
Cliquet + validator de règles structurelles	Refactoring de la structure du code
Cliquet + hurl pass/fail	Vérification d’endpoints API
Cliquet + vérification croisée de spécifications	Garantie de cohérence SSOT
Cliquet + Toulmin verdict	Application de règles personnalisées

Le pattern est unique. Le vérificateur détermine le domaine.

Question

Combien d’éléments votre agent a-t-il traités avant de dire « c’est fait » ?

Était-ce vraiment fini ?

Qui a décidé de la fin — l’agent ou la machine ?

Sources

[1] 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. arXiv:2310.01798

[2] Mert Cemri, Melissa Z. Pan, Shuyi Yang, Lakshya A. Agrawal, Tanay Chopra, Aditya Tiwari, Kurt Keutzer, Aditya Parameswaran, et al. “Why Do Multi-Agent LLM Systems Fail?” NeurIPS 2025 Datasets and Benchmarks Track. arXiv:2503.13657

[3] Xinyun Chen, Maxwell Lin, Nathanael Scharli, Denny Zhou. “Teaching Large Language Models to Self-Debug.” ICLR 2024. arXiv:2304.05128

[4] Noah Shinn, Federico Cassano, Ashwin Gopinath, Karthik Narasimhan, Shunyu Yao. “Reflexion: Language Agents with Verbal Reinforcement Learning.” NeurIPS 2023. arXiv:2303.11366

[5] Aman Madaan, Niket Tandon, Prakhar Gupta, Skyler Hallinan, Luyu Gao, Sarah Wiegreffe, Uri Alon, Nouha Dziri, Shrimai Prabhumoye, Yiming Yang, et al. “Self-Refine: Iterative Refinement with Self-Feedback.” NeurIPS 2023. arXiv:2303.17651

[6] 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. DOI:10.1126/science.abq1158

[7] Carlos E. Jimenez, John Yang, Alexander Wettig, Shunyu Yao, Kexin Pei, Ofir Press, Karthik R. Narasimhan. “SWE-bench: Can Language Models Resolve Real-World GitHub Issues?” ICLR 2024. arXiv:2310.06770