Qu'est-ce qu'un « turn » dans reins ?

Image : générée par IA

Quiconque a confié un gros travail à un agent IA le sait. La boucle s’effondre toujours au même endroit : au moment où le modèle déclare de lui-même « j’ai terminé » — alors qu’en réalité, ce n’est pas fini.

reins est un framework de Quest CLI qui retire à l’IA cette autorité de déclarer l’achèvement pour la remettre à une machine. Il découpe une liste de travail en items individuels, comme les quêtes d’un jeu, les confie à l’IA un par un, et décide « est-ce terminé ? » non pas sur parole de l’IA mais par inspection machine. Et en son cœur se trouve une petite unité appelée le turn.

Deux mots vont revenir sans cesse ; fixons-les d’abord.

• Gate — un inspecteur qui vérifie mécaniquement une soumission et prononce PASS ou FAIL. Ni l’impression d’un humain, ni l’auto-évaluation de l’IA.
• Ratchet — un engrenage à cliquet qui ne tourne que dans un sens. Nous l’employons pour dire qu’un item verrouillé par un passage ne se rouvre jamais.

Cet article suit un turn du début à la fin, à travers exactement ce qu’il traverse. Le turn paraît petit, mais une fois démonté, c’est reins tout entier en miniature.

Les six éléments fondamentaux du Reins Engineering

Comprimez en une ligne l’ingénierie sur laquelle repose reins, et cela donne : l’ingénierie qui déplace l’autorité de déclarer l’achèvement de l’IA vers un gate machine déterministe. « Déterministe » n’a ici rien de difficile. Cela signifie que la même entrée produit toujours le même résultat. Un test passe ou échoue, et le verdict d’hier ne diffère pas de celui d’aujourd’hui selon l’humeur.

Dans la lignée du prompt engineering (choisir les mots) → context engineering (fournir le contexte) → harness engineering (dresser les clôtures), Reins est la rêne qui fixe la direction. Cette ingénierie s’assemble à partir de six éléments.

Peu importe si les termes du tableau semblent encore étrangers. Le turn est la plus petite unité où ces six se rencontrent au sein d’un même cycle ; suivre un turn jusqu’au bout réunit donc les six éléments, chacun à sa place. Esquissons la carte à l’avance : compose, première étape du turn, assemble le contexte directionnel et le feedback déterministe ; judge rend le verdict machine (la défense anti-cheese est la qualité de conception de ce gate) ; record verrouille le ratchet et rend le progrès persistant.

Qu’est-ce qu’un Reins Turn ?

Un Reins Turn est la plus petite unité d’exécution de reins, dans laquelle une tentative sur un item de quête se conclut en génération → jugement → enregistrement. Une boucle n’est que la répétition de turns, et le progrès d’une quête n’est que l’accumulation de turns. La définition tient donc en une ligne.

Turn N = le N-ième Attempt enregistré. Ce qui n’est pas enregistré n’est pas un turn.

Un Attempt est « un enregistrement d’un essai ». Ici se cache un point subtil — un turn n’est pas « le LLM a été appelé une fois ». La condition d’existence d’un turn n’est pas l’appel mais l’enregistrement. Si le LLM a été appelé mais que le résultat n’a jamais été enregistré dans le ratchet, ce turn n’a jamais eu lieu. Inversement, un résultat soumis à la main par un humain, une fois enregistré, est un turn. Même sans LLM. Celui qui compte les turns n’est pas le modèle mais le ratchet.

Cette seule définition est la racine de toutes les propriétés à venir — indépendance du driver, résilience au redémarrage, auditabilité. Pour l’instant, laissons ces noms passer. Nous retrouverons chacun à sa juste place.

Un turn, c’est exactement quatre étapes

Un turn traverse quatre étapes dans l’ordre. Les étapes portent des noms anglais, mais ce qu’elles font est simple — assembler (compose), générer (generate), juger (judge), enregistrer (record).

« Fonction pure » signifie que la même entrée produit toujours la même sortie, sans autre effet de bord ; « irréversible » signifie qu’une fois exécutée, on ne peut plus revenir en arrière. Alors le cœur du tableau apparaît — des quatre étapes, seule la ② est probabiliste, et seule la ④ est irréversible. La génération ne peut pas juger, et le jugement ne peut pas générer. L’incertitude de l’IA est confinée dans une case, et la décision sans retour dans une autre.

Un choix de conception singulier mérite d’être noté. Cette cascade en quatre étapes n’est pas implémentée en deux jeux de code Go. Elle est définie dans un unique document lisible par un humain, pkg/cli/turn.md (un document TANGEUL), embarqué dans le binaire (go:embed) et interprété à l’exécution. La source canonique de « comment tourne un turn » n’est pas du code mais un document lisible — la raison de ce choix reviendra à la fin de cet article.

① compose — le contexte ne vient que du Log

Le Log est le registre, tenu sur disque, où chaque turn effectué jusqu’ici est enregistré. Et l’entrée pour assembler le prompt du turn N est exactement une seule chose : ce Log. Un état qui se cacherait quelque part dans la mémoire du programme et s’évanouirait à la mort du processus — cela n’existe pas.

Le prompt assemblé depuis le Log a trois couches.

• Quoi faire — ce qui doit être produit pour cet item (les instructions de rédaction et le contexte de vérification)
• Manuel — le prompt système global, plus, si le turn précédent était un FAIL, le coaching de la règle qui l’a causé (le manuel par règle)
• Queue de feedback — les faits du FAIL précédent. « Où, ce que ça devait être, ce que c’était réellement »

Dans le langage des six éléments ci-dessus, le manuel est le contexte directionnel et la queue de feedback est le feedback déterministe. Les deux sont assemblés mécaniquement depuis le Log, à chaque turn.

Il y a une règle subtile mais importante. Ce que compose prend pour référence n’est pas le dernier Attempt, mais le dernier Attempt jugé (judged) — mené jusqu’au verdict. Même si une erreur de génération, comme une panne du serveur LLM, s’intercale entre-temps, ce que voit la nouvelle tentative n’est pas le message d’erreur d’infrastructure mais le feedback factuel du FAIL précédent. Les pannes opérationnelles ne contaminent pas le contexte du travail.

② generate — le LLM ne fait que générer

Le prompt assemblé part vers le backend LLM en un seul appel. Peu importe que le backend soit une API HTTP (ollama/xai/gemini) ou un outil en ligne de commande (claude/grok/codex/geminicli). Dans les deux cas, son rôle est fixé : générateur. Le framework n’expose aucune API par laquelle un LLM pourrait se voir accorder l’autorité de PASS. Ce n’est pas que le framework « a choisi de ne pas accorder » l’autorité de juger — il n’existe aucun moyen de l’accorder. C’est ainsi que l’élément 1 des six (achèvement jugé par la machine) devient structure.

Même le choix du backend est recalculé depuis le Log à chaque turn. Un item qui échoue sans cesse sur le modèle par défaut est envoyé vers un modèle plus fort (escalade), et cette décision aussi se lit dans le Log à chaque turn — « parmi les règles causales des FAIL passés, y en a-t-il une qui déclenche l’escalade ? » Il n’y a pas d’interrupteur resté allumé quelque part, pas de variable locale à l’intérieur de la boucle. Même programme, même Log — même backend sélectionné. La propriété de se comporter à l’identique après avoir tué et relancé le processus — la résilience au redémarrage — vient gratuitement.

③ judge — seul le gate juge

Ce qui statue sur la sortie, c’est le gate. Un gate est un ensemble de règles de détection de violations. Chaque règle se déclenche (fire) lorsqu’elle trouve le problème dont elle est responsable, et laisse derrière elle un fait — où (Where), ce que ça devait être (Expected), ce que c’était réellement (Actual).

L’agrégation est déterministe. Si une seule règle Fail se déclenche, FAIL. Sinon, si une règle Review se déclenche, REVIEW (une zone grise qu’un humain doit vérifier). Si rien ne se déclenche, PASS. Même soumission, mêmes règles — toujours le même verdict. Il n’y a pas ici d’inspecteur dont la réponse change à chaque fois qu’on l’interroge.

Dans les domaines complexes où les règles s’enchevêtrent — où une violation rend un autre contrôle sans objet — le verdict peut être élevé sur un graphe d’argumentation (toulmin), et la logique de jugement elle-même peut être déplacée dans un document auditable (gate.md). Quelle que soit la forme, une chose ne change pas : le juge est une machine.

④ record — la seule étape irréversible

Appliquer le verdict au ratchet, sauvegarder sur disque, et exporter les items conclus. C’est le seul point d’un turn qui ne peut pas être défait.

• PASS / REVIEW / SKIPPED / BLOCKED → verrouillage. Le ratchet est à sens unique ; il ne revient pas en arrière.
• FAIL → le compteur d’essais (Tries) augmente de 1 et l’item reste TODO. Au maximum d’essais atteint (3 par défaut), il est verrouillé en DONE. « Cet item ne marche pas de cette façon » est aussi une forme de conclusion — on ne laisse pas un item bloqué prendre en otage toute la boucle pour toujours.
• Erreur de génération → elle est enregistrée dans le Log comme Attempt (la trace de ce qui s’est passé est conservée), mais elle ne consomme pas d’essai. Un serveur LLM qui tombe n’est pas la faute de l’item ; c’est une panne opérationnelle. Si la panne persiste, une protection séparée arrête la boucle (halte après N échecs de génération consécutifs — un disjoncteur).

Ce n’est qu’avec cette étape que le Log existe pour que le compose du turn suivant puisse le lire. record est la conclusion du turn et le générateur du turn suivant.

L’échec est un fait, pas une opinion

Sous quelle forme revient un FAIL — voilà la clé pour qu’un turn converge (se rapproche de la réponse à chaque nouvelle tentative). Pas une opinion du genre « la qualité laisse un peu à désirer », mais ceci :

FAIL. root cause = who-anchor-present
  Fact: where=who.anchors expected="source substring" actual="Charles Martin, chef adjoint"

La lecture est simple. Quel champ (where), ce que ça devait être (expected — une chaîne qui existe réellement dans la source), ce que c’était réellement (actual). Emplacement + valeur attendue + valeur réelle. Pour le LLM, c’est un feedback sans personne à flatter — les nombres et les emplacements ne sont pas des émotions. C’est ce fait structuré qui mène un modèle flagorneur non pas à la dispute mais à la convergence.

Un bonus par-dessus. Le texte de FAIL donné au modèle est exactement le même rendu que la chaîne affichée à l’écran quand un humain lance la commande submit (feedback parity). Le feedback que voit l’humain et le feedback que voit le modèle ne divergent jamais. Le mystère « qu’est-ce qui a bien pu être envoyé à l’IA pour qu’elle corrige comme ça ? » est structurellement absent.

Trois points d’entrée, un seul turn

Appelons driver celui qui conduit le turn. reins en a trois : next, où un humain reçoit directement le prompt ; submit, où un humain soumet le résultat ; et le loop automatique, sans surveillance. Mais ce ne sont pas trois implémentations distinctes. Ce sont trois points d’entrée dans le même document de turn. Ce qui sépare le manuel de l’automatique, c’est exactement une règle à l’intérieur du document.

La propriété pratique que cela procure : changez de driver en pleine quête, et le prompt reste identique à l’octet près. Faites tourner le loop automatique hier, laissez un humain reprendre avec next aujourd’hui — à état de Log égal, le même prompt en sort. C’est possible parce que le contexte ne vient que du Log (nous l’avons vu à l’étape ①), et c’est une propriété prouvée, pas un espoir — un golden test d’échange de drivers (driver-swap golden test) vérifie l’identité octet par octet en comparant les sorties d’un driver à l’autre.

Suivre un turn jusqu’au bout

La théorie est finie. Regardons un vrai turn du début à la fin. C’est un item d’une quête qui extrait des adresses e-mail de documents, à sa deuxième tentative après que le turn précédent a fini en FAIL pour « format d’e-mail invalide ».

[Contrôle d'entrée du turn]  L'item est-il TODO ? Reste-t-il des essais ? → on continue
① compose      Trouve le dernier Attempt judged dans le Log → FAIL, cause = email-format
               Manuel = prompt global + le coaching de la règle email-format
               Prompt = quoi faire + "FAIL. Fact: where=email
                        expected='valid email format' actual='kim at example'"
② generate     Appel LLM → {"email":"kim@example.com", ...}
③ judge        Balayage des règles : email-format passe, source-lacks-email passe, freemail passe
               → aucune règle Fail déclenchée → PASS
④ record       Le ratchet verrouille (irréversible) → Attempt #2 enregistré → sauvegardé → export

Le modèle, recevant le fait de l’échec précédent (« kim at example n’est pas un format d’e-mail valide »), a corrigé exactement cet endroit ; le gate a confirmé le passage ; le ratchet a verrouillé. Cet item est désormais PASS pour toujours. Le turn suivant le saute, et le travail restant ne fait que diminuer. Quand chaque item atteint un état conclu (PASS, REVIEW, ou maximum d’essais atteint), la boucle se termine. Non pas « quand l’IA a le sentiment d’avoir fini », mais quand les items restants tombent à zéro. La convergence est garantie par la structure.

Loop Engineering — l’industrie a nommé le même problème

En juin 2026, un changement dans la manière de manier les agents a reçu un nom. Peter Steinberger a écrit “You shouldn’t be prompting coding agents anymore. You should be designing loops that prompt your agents” (vous ne devriez plus prompter les agents de codage ; vous devriez concevoir les boucles qui promptent vos agents), et plus tôt le même mois, Boris Cherny d’Anthropic, le créateur de Claude Code, avait déclaré lors d’un événement : “I don’t prompt Claude anymore. I have loops running… My job is to write loops” (je ne prompte plus Claude ; j’ai des boucles qui tournent… mon travail est d’écrire des boucles). Quelques jours plus tard, Addy Osmani, de Google, a donné un nom à ce courant : Loop Engineering — de la personne qui prompte des agents à la personne qui conçoit les systèmes qui promptent des agents.

Ce discours dessine un seul récit de transition. Prompt engineering (choisir les mots) → context engineering (choisir quelles informations montrer) → harness engineering (bâtir l’environnement d’exécution) → loop engineering (concevoir le cycle observer-agir-vérifier-récupérer lui-même). Le levier s’est déplacé vers l’extérieur, une couche à la fois : des mots à l’information, de l’information à l’environnement, de l’environnement au cycle.

L’anatomie d’une bonne boucle selon Osmani devrait sembler familière à quiconque a lu jusqu’ici. Externalisez l’état sur disque ou sur un tableau, pas dans la conversation. Séparez l’agent qui construit de l’agent qui vérifie. Faites confirmer la terminaison par un adjudicateur séparé, pas par l’auto-déclaration de l’agent de codage. Placez cela à côté du turn, et la correspondance est nette.

Le cœur de la différence est la distance entre recommandation et structure. La littérature du loop engineering concède elle-même la hiérarchie de la vérification — le LLM-as-judge, qui confie le verdict à une IA, “can be gamed or can collude with the actor” (peut être dupé ou être de mèche avec l’acteur), donc partout où un contrôle déterministe est possible, mettez un contrôle déterministe. Mais cela reste une bonne pratique — une recommandation confiée à la bonne volonté du concepteur. Si le sous-agent vérificateur est finalement lui aussi un LLM, la porte de la collusion reste ouverte. reins ferme cette porte par conception. Seul le gate juge, et le framework n’expose aucun moyen de donner un PASS à un LLM.

Et là où le loop engineering parle de la boucle entière, reins fait d’un tour de cette boucle un contrat. Pour aller un pas au-delà du « my job is to write loops » de Cherny, ce qu’une boucle accomplit en une révolution — ce qui est probabiliste, ce qui est déterministe, ce qui est irréversible — doit d’abord être défini. Le nom de cette définition est le turn.

Pourquoi cette unité

Serrez le turn ainsi, et vous gagnez trois choses. Les noms qui n’avaient fait que passer plus haut trouvent ici leur place.

• Auditabilité — la réponse à « en quoi le loop automatique diffère-t-il du next manuel ? » n’est pas un travail de comparaison entre deux bases de code, mais une seule règle dans un document. Vous pouvez confirmer de vos propres yeux qu’exactement un chemin dans le document peut verrouiller un PASS. C’est pourquoi la source canonique du turn est un document lisible, pas du code.
• Résilience au redémarrage — chaque entrée d’un turn dérive du Log sur disque ; même si le processus meurt, le même Log reproduit le même turn.
• Jetabilité des agents — remplacez les agents (LLM, drivers), le progrès continue de s’accumuler et ne recule jamais. “Agents are disposable; progress is cumulative.”

Dit à l’envers : un système où le turn est flou — où le contexte se cache dans la mémoire de session, où le modèle auto-déclare l’achèvement, où les nouvelles tentatives s’appuient sur l’historique de conversation — perd les trois.

Le turn paraît petit. Mais en tant que plus petite unité qui sépare et sérialise la génération (probabilité), le jugement (déterminisme) et l’enregistrement (irréversibilité) au sein d’un même cycle, comprendre le turn, c’est comprendre tout reins.

Articles liés

• reins — ne garder du Quest CLI que le domaine, le ratchet devient un framework — le framework vedette de cet article, au complet.
• Ratchet Pattern — comment forcer un agent à aller jusqu’au bout — le traitement complet du verrouillage contractuel (élément 4 des six).
• Comment créer un Quest CLI — bâtir soi-même l’outil qui laisse la machine juger de l’achèvement — le plan pratique : les cinq pièces d’une quête, la conception des gates, les défenses anti-cheese.
• Le code a cliquet qui retourne IFEval a son avantage — l’expérience où feedback déterministe + contexte directionnel produisent la convergence.
• Reins Engineering — L’IA avec des renes — la déclaration de la lignée prompt→contexte→harness→Reins.
• TANGEUL — Des règles écrites en Markdown, auditées par des humains — pourquoi la source canonique du turn est un document.

Lectures complémentaires (externes)

• Building Effective Agents — Anthropic — le classique de la conception des boucles d’agents. Sa distinction entre « workflows (orchestration déterministe) et agents (pilotés par le modèle) » résonne avec la séparation génération/jugement de cet article.
• Agentic Loops: From ReAct to Loop Engineering — Data Science Dojo — un panorama de la lignée des boucles d’agents, de ReAct au loop engineering.
• The Anthropic leader who built Claude Code says he ditched prompting — now he just writes loops — The New Stack — la couverture presse du virage de Boris Cherny.

Sources

• Loop Engineering — Addy Osmani — 2026-06. Le baptême du terme et l’anatomie d’une bonne boucle (automatisation, worktrees, skills, sous-agents, adjudicateurs séparés, externalisation de l’état).
• What Is Loop Engineering? A Complete Guide from Prompt to Harness Engineering — Tosea.ai — la transition en quatre étapes prompt→contexte→harness→loop, la hiérarchie de vérification « déterminisme d’abord », et le risque de collusion du LLM-as-judge.
• Claude Code’s Creators Explain Agent Loops — The Neuron — Boris Cherny et Cat Wu sur l’exploitation des boucles en détail : /loop et /goal, l’externalisation de l’état sur disque et dans Linear, la séparation constructeurs/vérificateurs.

Journal des modifications

• 2026-07-07: First edition