Loopcraft : l'art de combiner les boucles IA

Une seule boucle ne suffit jamais longtemps

Concevoir une boucle isolée est un excellent point de départ — à condition d'en maîtriser les cinq blocs fondamentaux, car on n'empile bien que ce qu'on sait déjà construire. Mais très vite, les praticiens les plus avancés ont fait le même constat : une boucle unique, aussi bien conçue soit-elle, atteint un plafond. Elle exécute son action, vérifie son résultat, persiste son état — mais elle ne s'occupe que d'une chose. Or les systèmes réels demandent qu'on automatise plusieurs niveaux en même temps : faire le travail, vérifier qu'il est bon, réagir aux événements, et améliorer le système lui-même.

C'est là qu'intervient ce que swyx, du podcast Latent Space, a baptisé le loopcraft : l'art d'empiler les boucles (« the art of stacking loops »). L'idée centrale est qu'au lieu de dépendre d'un seul agent monolithique ou d'une seule boucle, on combine plusieurs boucles spécialisées qui s'imbriquent et se nourrissent mutuellement. LangChain a formalisé cette intuition dans un article du 16 juin 2026, signé Sydney Runkle, qui décrit quatre niveaux de boucles. Cet article explore le loopcraft : les quatre boucles, la manière de les empiler, et la distinction fondamentale entre le harnais et la boucle.

Avant d'entrer dans le détail, une remarque sur le statut de ces concepts. Le « loopcraft » et le « stack à quatre boucles » sont des cadres proposés par des praticiens — swyx pour le terme, LangChain pour la formalisation — et non des standards neutres de l'industrie. Ce sont des manières de penser puissantes, mais il faut les attribuer comme telles plutôt que les présenter comme des lois universelles.

Distinguer le harnais de la boucle

Le harnais équipe une exécution d'agent unique ; la boucle est ce qui relance ces exécutions sur une cadence, engendre des assistants et se nourrit elle-même. Avant d'empiler quoi que ce soit, c'est cette distinction — que Cobus Greyling juge essentielle pour maîtriser la philosophie de ces systèmes — qu'il faut clarifier.

Le harnais, c'est l'ensemble de la configuration dans laquelle un agent tourne : ses outils, ses permissions, son contexte initial, ses garde-fous. Quand vous lancez un agent une fois, c'est le harnais qui détermine ce qu'il peut faire et comment. C'est précisément l'objet du Harness Engineering, où le harnais fait gagner plus de points de performance que le choix du modèle. La boucle, elle, opère un cran au-dessus : elle est ce qui ne cesse de solliciter les agents sur un calendrier, de créer des aides et de s'alimenter. Greyling le résume ainsi : le harnais équipe une exécution unique ; la boucle est ce qui aiguillonne les agents en continu.

Cette distinction est exactement celle qu'Addy Osmani formule autrement, dans son article fondateur du 7 juin 2026, quand il situe le Loop Engineering « un étage au-dessus du harnais » : le harnais, mais qui tourne sur une horloge, engendre de petits assistants et se nourrit lui-même. Comprendre cette différence évite une confusion fréquente : optimiser son harnais (choisir les bons outils, le bon contexte) ne suffit pas à faire du Loop Engineering. Tant qu'un humain doit relancer l'agent à chaque fois, on reste au niveau du harnais. Le passage à la boucle, c'est le moment où le système se relance lui-même.

Les quatre boucles du loopcraft

Selon la formalisation de LangChain (16 juin 2026), le loopcraft s'appuie sur quatre types de boucles : la boucle de l'agent automatise le travail, la boucle de vérification garantit la qualité, la boucle événementielle passe à l'échelle, et la boucle d'ascension automatise l'amélioration. Chacune répond à une dimension distincte ; c'est leur combinaison qui fait la puissance du stack.

Loop 1 — La boucle de l'agent : automatiser le travail

La première boucle est la plus fondamentale. C'est le cycle de base par lequel un modèle appelle des outils, observe les résultats, et rappelle des outils, jusqu'à ce que la tâche soit complète. C'est l'héritière directe de ReAct, le mécanisme raisonnement-action-observation qui définit ce qu'est un agent. Son rôle, dans le vocabulaire de LangChain : automatiser le travail. C'est le moteur qui transforme une intention en exécution — une primitive comme create_agent, ou tout simplement une session d'agent qui enchaîne lecture de fichiers, écriture de code, exécution de tests. Tant qu'on en reste à cette boucle, on a déjà beaucoup gagné : l'agent fait le travail. Mais rien ne garantit que ce travail soit bon, ni qu'il se déclenche au bon moment, ni que le système s'améliore. D'où les trois boucles suivantes.

Loop 2 — La boucle de vérification : garantir la qualité

La deuxième boucle s'attaque au problème laissé ouvert par la première : comment savoir que la sortie est bonne ? La boucle de vérification est un système parallèle dont le rôle exclusif est d'auditer et de valider les sorties de la boucle de l'agent. Un évaluateur (grader) confronte la sortie à une grille de critères (un rubric) ; si elle échoue, il la renvoie à l'agent accompagnée d'un retour. LangChain l'implémente via un composant comme RubricMiddleware, et l'évaluateur peut être déterministe (un test, un linter, une règle) ou bien un modèle jouant le rôle de juge (LLM-as-judge).

Cette boucle incarne, au niveau architectural, le principe maker/checker : l'agent qui produit n'est pas celui qui juge. C'est exactement le déplacement décrit dans notre analyse du passage du créateur au vérificateur dans la code review à l'ère de l'IA. Mais elle a un coût qu'il faut assumer lucidement : elle ajoute de la latence et de la consommation de tokens à chaque exécution. Vérifier coûte. C'est précisément le genre d'arbitrage qui rend le loopcraft délicat : chaque boucle ajoutée améliore une dimension (ici la qualité) au prix d'une autre (ici le coût et la vitesse).

Loop 3 — La boucle événementielle : passer à l'échelle

La troisième boucle change la nature du déclenchement. Au lieu d'être lancée par un humain ou par un simple intervalle, la boucle événementielle se déclenche sur un événement : un nouveau document arrive, un calendrier se déclenche, un webhook est appelé — et l'agent tourne en arrière-plan, sans intervention. Son rôle : automatiser le travail à grande échelle. C'est elle qui transforme un agent ponctuel en assistant permanent. LangChain note que les « heartbeats » — ces déclenchements réguliers qu'on trouve dans des outils comme OpenClaw — font précisément cela : ils convertissent un agent passif en assistant toujours actif. Les déclencheurs cron et les webhooks en sont les mécanismes typiques. C'est cette boucle qui rend possibles les usages les plus spectaculaires du Loop Engineering : Boris Cherny décrit ainsi des boucles qui surveillent ses pull requests en permanence, auto-corrigent les échecs d'intégration continue, ou scrutent les retours sur les réseaux sociaux pour les regrouper par thème à intervalle régulier. Sans la boucle événementielle, le système attend qu'on l'active ; avec elle, il ne sollicite l'humain que lorsqu'une décision est requise.

Loop 4 — La boucle d'ascension : automatiser l'amélioration

La quatrième boucle est la plus subtile, et c'est elle qui distingue vraiment le loopcraft d'un simple empilement. La boucle d'ascension — hill-climbing loop — ne fait pas le travail, ne le vérifie pas, ne réagit pas aux événements : elle améliore le système lui-même. Un agent d'analyse passe sur les traces de production — l'historique de ce que les autres boucles ont fait — et réécrit la configuration du harnais : il ajuste le prompt, modifie les outils disponibles, affine la grille d'évaluation. Pour les modèles à poids ouverts, cette boucle peut même alimenter un fine-tuning par apprentissage par renforcement. Son rôle : automatiser l'amélioration.

Le point décisif, souligné par LangChain, est la nature de la flèche de retour. Dans les trois premières boucles, elle ramène simplement au sommet pour relancer le cycle. Dans la boucle d'ascension, la flèche de retour ne se contente pas de boucler vers le haut : elle plonge à l'intérieur et met à jour la boucle de l'agent directement. Autrement dit, chaque cycle de la boucle externe rend les boucles internes plus efficaces. C'est ainsi qu'un système ne se contente pas de produire à l'infini, mais produit de mieux en mieux — l'incarnation technique de l'idée que le Loop Engineering ne sert pas à exécuter, mais à améliorer.

Empiler les boucles : monter ou descendre d'un cran

Disposer de quatre types de boucles ne dit pas encore comment les combiner. C'est ici que le loopcraft devient un art, et swyx en donne la règle directrice sous une forme mémorable : quand les choses cassent, descendez d'une boucle pour gagner en fiabilité ; à mesure que les modèles s'améliorent, montez d'une boucle pour gagner en levier.

Cette dialectique monter/descendre est le cœur de la pratique. Si votre système produit des résultats peu fiables, la tentation est d'ajouter de la complexité ; souvent, la bonne réponse est l'inverse — redescendre vers une boucle plus simple et plus contrôlée, le temps de rétablir la fiabilité. Inversement, quand le modèle devient suffisamment bon et que la boucle tourne sans accroc, on peut monter d'un cran : déléguer davantage, automatiser un niveau de plus, se retirer un peu plus du circuit.

swyx rattache cette idée à ce qu'il appelle la « Salty Lesson », un clin d'œil à la « Bitter Lesson » de Richard Sutton transposée aux agents : ne corrigez pas les choses vous-même comme vous l'avez toujours fait ; concentrez-vous plutôt sur des systèmes qui passent à l'échelle avec davantage d'agents, comme les objectifs et l'orchestration. La même intuition se retrouve chez Andrej Karpathy, cité par LangChain : se retirer en tant que goulot d'étranglement, refactoriser les abstractions pour tout arranger une fois, puis « appuyer sur démarrer ». Le fil commun est clair : le rôle de l'ingénieur n'est plus d'être dans la boucle à chaque itération, mais de concevoir la boucle qui itère sans lui.

L'architecture composée : un exemple intégré

Pour rendre tout cela concret, imaginons un système réel qui empile les quatre boucles — par exemple un agent qui maintient la documentation d'un produit, qui est précisément l'exemple fil rouge de LangChain.

La boucle de l'agent fait le travail : quand on lui signale une fonctionnalité nouvelle, elle lit le code, rédige la page de documentation correspondante et la propose. La boucle de vérification garantit la qualité : un évaluateur confronte la page produite à un rubric (exactitude technique, ton, complétude, exemples fonctionnels) et la renvoie si elle échoue. La boucle événementielle passe à l'échelle : au lieu d'attendre qu'un humain signale une fonctionnalité, le système se déclenche à chaque fusion de pull request pertinente, et lance l'agent en arrière-plan. La boucle d'ascension, enfin, automatise l'amélioration : un agent d'analyse examine périodiquement les pages produites, repère les schémas d'erreur récurrents, et met à jour le rubric et le prompt de l'agent de documentation — de sorte que la qualité monte cycle après cycle.

Aucune de ces boucles, prise isolément, ne produirait ce résultat. C'est leur composition qui crée un système qui fait, vérifie, réagit et s'améliore tout seul. Et c'est exactement la conclusion à laquelle, comme le note LangChain, des figures aussi différentes que Peter Steinberger, Boris Cherny et Andrej Karpathy sont parvenues indépendamment : le potentiel des agents ne réside pas tant dans les agents eux-mêmes que dans les boucles qu'on bâtit autour d'eux.

Les pièges du loopcraft : quand empiler devient nuire

Le loopcraft a ses dérives, et les nommer évite les déconvenues. La première est l'empilement prématuré : ajouter une boucle de vérification, puis une boucle événementielle, puis une boucle d'ascension, avant même que la boucle de l'agent soit fiable. On se retrouve alors avec un système complexe dont aucun étage ne fonctionne vraiment, et dont les défaillances se masquent les unes les autres. La règle de swyx — descendre d'une boucle quand les choses cassent — est précisément l'antidote : ne montez d'un cran que lorsque le cran inférieur est solide.

La deuxième dérive est la boucle de vérification qui devient plus chère que le travail qu'elle vérifie. Faire juger chaque sortie par un modèle a un coût en latence et en tokens ; si ce coût dépasse la valeur de la vérification, on a inversé l'arbitrage. Le sujet est loin d'être théorique : empiler des boucles et des sous-agents fait grimper la facture de tokens dans des proportions importantes, un enjeu que nous détaillons dans notre analyse du budget de tokens du contexte comme actif plutôt que dépense. La parade consiste à graduer la preuve : une vérification déterministe bon marché (un test, un linter) pour la majorité des cas, et un juge-modèle coûteux réservé aux cas où la qualité est réellement subjective.

La troisième dérive, plus insidieuse, concerne la boucle d'ascension. Parce qu'elle réécrit le harnais lui-même — prompts, outils, rubrics — une boucle d'ascension mal surveillée peut faire dériver le système dans une direction que personne n'a choisie. C'est une boucle qui modifie une autre boucle, ce qui rend la dérive d'autant plus difficile à tracer. La discipline indispensable est de versionner chaque modification apportée par la boucle d'ascension, de la traiter comme un commit relisible, et de pouvoir revenir en arrière. Sans cette mémoire de version, l'amélioration automatique devient une boîte noire qui s'éloigne lentement de vos intentions.

Ces trois pièges partagent une racine commune : ils surviennent quand on empile pour automatiser davantage plutôt que pour résoudre un problème précis. Chaque boucle supplémentaire doit gagner sa place en répondant à un besoin réel : la qualité dérape (boucle de vérification), le déclenchement manuel ne tient pas l'échelle (boucle événementielle), le système stagne (boucle d'ascension).

Par où commencer son loopcraft

Le loopcraft se construit de l'intérieur vers l'extérieur : on commence par fiabiliser la boucle de l'agent, puis on ajoute la vérification, puis le déclenchement événementiel, et enfin l'ascension — jamais l'inverse. Devant ces quatre boucles, la tentation est de vouloir tout bâtir d'un coup ; c'est la pire stratégie. Tant que la boucle de l'agent n'est pas fiable sur une tâche circonscrite, ajouter des étages ne fait qu'empiler de la complexité sur une fondation instable.

Une fois la boucle de l'agent solide, la deuxième boucle à ajouter est presque toujours la boucle de vérification — non pas parce qu'elle est la plus spectaculaire, mais parce qu'elle est celle qui vous autorise à faire confiance au système. Sans preuve, vous restez condamné à tout relire vous-même, ce qui annule le bénéfice de l'automatisation. La boucle de vérification est la condition pratique de votre propre retrait du circuit. Ce n'est qu'ensuite, quand l'agent fait et qu'un vérificateur valide, que l'ajout d'une boucle événementielle commence à payer : vous pouvez alors laisser le système se déclencher seul, puisque vous avez la garantie qu'il s'auto-contrôle.

La boucle d'ascension, elle, arrive en dernier, et seulement quand le système tourne assez pour produire des traces exploitables : réécrire le harnais sans données de production, c'est optimiser à l'aveugle. La séquence naturelle du loopcraft est donc faire, puis vérifier, puis déclencher à l'échelle, puis améliorer — l'inverse de l'instinct qui pousse à concevoir d'emblée l'architecture complète. C'est ce que swyx résume par sa règle de montée graduelle : on ne monte d'un cran que lorsque le cran inférieur est devenu invisible tant il est fiable.

Du loopcraft individuel à l'échelle organisationnelle

Un point traverse les quatre boucles et devient décisif dès qu'une équipe entière, et non un individu, adopte le Loop Engineering : la supervision humaine est une primitive de premier rang, présente à chaque niveau. Empiler des boucles ne signifie pas évacuer l'humain ; cela signifie placer son jugement aux bons endroits. La question n'est plus seulement « comment empiler mes boucles ? » mais « comment des dizaines de boucles, conçues par des personnes différentes, coexistent-elles sans se nuire ? » — un problème de coordination que nous avons exploré sous l'angle du contexte dans le cas où dix agents ignorent ce qu'un seul sait déjà.

Le premier enjeu est la propriété : une boucle sans propriétaire identifié devient orpheline — personne ne surveille sa dérive, ne révise ses artefacts, ne répond de son coût. À l'échelle d'une équipe, chaque boucle devrait avoir un responsable nommé, comme un service en production, pour que la boucle d'ascension ne dérive pas en silence : quelqu'un doit relire ses modifications comme on relit un commit. Le deuxième enjeu est la composition entre boucles de personnes différentes : quand la boucle de vérification de l'un devient l'entrée de la boucle d'action de l'autre, on crée des dépendances qui ressemblent à une architecture de microservices, avec les mêmes exigences — interfaces claires, contrats explicites, isolation. Le troisième est la mémoire partagée : si chaque boucle garde sa mémoire isolée, l'organisation accumule des silos d'apprentissage qui ne communiquent pas. La réponse esquissée par plusieurs praticiens est de faire du dépôt commun la mémoire du système — artefacts, rubrics, résultats d'évaluation et journaux de décision consultables par toutes les boucles.

Ce passage de la mémoire éphémère d'une boucle à la mémoire persistante d'une organisation est exactement le glissement que SFEIR décrit avec le Context Engineering : on passe d'un ROI linéaire, où chaque interaction repart de zéro, à un ROI composé, où le jugement accumulé se capitalise — un sujet que nous traitons dans notre guide complet du Context Engineering. Une formule reprise par LangChain, attribuée à Satya Nadella, le dit autrement : les entreprises qui construisent tôt des boucles d'apprentissage, où le jugement humain et le capital-token composent ensemble, bâtiront un avantage difficile à répliquer. À l'échelle d'une organisation, ce qui compose n'est pas seulement le calcul d'une boucle isolée, mais le jugement d'une équipe entière, encodé dans une mémoire commune et raffiné par des boucles d'ascension supervisées.

Le loopcraft est donc, en définitive, l'art d'orchestrer non pas seulement des agents, mais l'équilibre entre automatisation et jugement, à plusieurs niveaux. On revient ainsi au point de départ : une seule boucle ne suffit jamais longtemps, mais empiler sans discernement ne suffit pas davantage. Le bon loopcraft tient dans cet écart — assez de boucles pour que le système vive sa propre vie, assez de jugement pour qu'il vive la vôtre.

Points clés

• Le loopcraft (terme de swyx, Latent Space) est l'art d'empiler des boucles spécialisées plutôt que de s'appuyer sur un agent ou une boucle unique.
• Harnais ≠ boucle : le harnais équipe une exécution d'agent unique (outils, contexte, garde-fous) ; la boucle relance ces exécutions sur une cadence et se nourrit elle-même. Le Loop Engineering est « un étage au-dessus du harnais » (Osmani, 7 juin 2026).
• LangChain (16 juin 2026) formalise quatre boucles : agent (automatiser le travail) · vérification (garantir la qualité) · événementielle (passer à l'échelle) · ascension/hill-climbing (automatiser l'amélioration).
• La boucle d'ascension est la seule dont la flèche de retour modifie les boucles internes : le système ne produit pas seulement à l'infini, il produit de mieux en mieux.
• Règle de swyx : descendre d'une boucle quand les choses cassent (fiabilité) ; monter d'une boucle quand les modèles s'améliorent (levier). On empile de l'intérieur vers l'extérieur : faire, vérifier, déclencher, améliorer.
• Trois pièges : empilement prématuré, vérification plus chère que le travail vérifié, boucle d'ascension non versionnée qui fait dériver le harnais en silence.

Sources

1. LangChain (Sydney Runkle) — The Art of Loop Engineering — langchain.com, 16 juin 2026.
2. swyx (Latent Space) — « loopcraft » (the art of stacking loops) — 2026.
3. Addy Osmani — Loop Engineering — addyosmani.com, 7 juin 2026.
4. Cobus Greyling — Loop Engineering — cobusgreyling.substack.com, 9 juin 2026.
5. SFEIR — matière first-party Harness Engineering.