L'Anatomie d'une Loop : les 5 Blocs Fondamentaux

Pourquoi une boucle n'est pas une simple répétition

Le mot « boucle » trompe. Il évoque une répétition mécanique, un while true qui tourne sans fin — l'event loop de Node, la game loop d'un moteur de jeu, le crash-loop-backoff d'un pod Kubernetes. Or une boucle au sens du Loop Engineering est un tout autre objet : un système composé de pièces distinctes, chacune ayant un rôle précis, et dont l'assemblage produit un comportement autonome et améliorable. Une boucle d'agent n'est pas une répétition mécanique, c'est un assemblage de cinq blocs — déclencheur, action, preuve, mémoire, condition d'arrêt — qui transforme une exécution en amélioration. Comprendre ces pièces, c'est comprendre comment on conçoit une boucle qui fonctionne plutôt qu'une boucle qui s'emballe.

Le fait remarquable — et rassurant — est que plusieurs praticiens majeurs sont arrivés indépendamment à la même décomposition en cinq éléments. Shubham Saboo l'a formalisée pour les Product Managers ; Matthew Berman l'a inscrite en tête de sa Loop Library — une boucle utile spécifie cinq choses ; Claire Vo en parle dans son émission How I AI comme des « cinq choses dont toute boucle a besoin ». Cette convergence indépendante est le signe que nous tenons une structure réelle, pas une grille arbitraire. (Les sources primaires de cet article — Saboo, Berman, Vo, Osmani, Greyling, Huntley, Willison — sont des praticiens publics ; le nombre exact de boucles décrites varie d'un auteur à l'autre.)

Cet article détaille ces cinq blocs fondamentaux — le déclencheur, l'action, la preuve, la mémoire et la condition d'arrêt — puis les met en regard d'une seconde grille, plus technique, proposée par Addy Osmani (Google) dans son article fondateur sur le Loop Engineering (addyosmani.com, juin 2026) : automatisations, worktrees, skills, connecteurs et sous-agents. Les deux grilles ne se contredisent pas ; elles décrivent la même chose à deux niveaux d'abstraction. Au sens de SFEIR, la boucle est l'étage situé au-dessus du Harness Engineering — l'équation « Agent = Model + Harness » : une fois le harnais d'un agent solide, le Loop Engineering est la discipline qui le fait tourner sans qu'on le prompte.

Bloc 1 — Le Déclencheur (Trigger) : quand la boucle démarre

Le déclencheur est le bloc qui définit à quel moment exact la boucle s'exécute — temporel (une heure fixe), événementiel (un changement d'état) ou conditionnel (un état du monde à atteindre). C'est le premier choix de conception, et il est plus lourd de conséquences qu'il n'y paraît, car il détermine à la fois la fraîcheur des résultats et le coût en tokens.

Trois familles se distinguent. Le déclencheur temporel — une heure fixe, un intervalle — est le plus simple (« chaque vendredi à 9 h ») : c'est ce que produit la commande /loop de Claude Code, qui convertit un intervalle en expression cron. Le déclencheur événementiel réagit à un changement d'état — un document arrive, une pull request s'ouvre, un webhook est appelé : c'est la base de ce que LangChain nomme la boucle événementielle. Le déclencheur conditionnel, enfin, dépend d'un état du monde plutôt que d'un calendrier — tant qu'il reste des tickets non traités, par exemple.

L'erreur classique sur le déclencheur est le « trigger vague ». Une boucle dont le déclencheur est mal défini se met à tourner trop souvent (et brûle des tokens pour rien) ou trop rarement (et rate l'information fraîche). Cobus Greyling, dans son traitement opérationnel du Loop Engineering (cobusgreyling.substack.com, juin 2026), donne la règle d'or : le triage doit être bon marché. C'est-à-dire que la partie de la boucle qui se déclenche fréquemment — celle qui regarde s'il y a quelque chose à faire — doit être légère. Les opérations coûteuses ne doivent se lancer que lorsque l'état indique qu'il y a réellement du travail actionnable.

Bloc 2 — L'Action : ce que l'agent doit faire

L'action est le cœur exécutif de la boucle : ce que l'agent fait concrètement à chaque tour. C'est ici, et seulement ici, que survit le prompt engineering classique — sous la forme de l'instruction donnée à l'agent et des artefacts qui la guident.

Mais l'action dans une boucle a une particularité : elle s'appuie sur des artefacts durables plutôt que sur une formulation jetée dans le chat. C'est le point de bascule du prompt engineering vers le Context Engineering, cet « art de nourrir les agents IA » qui remplace l'interaction isolée par un environnement durable. L'action « résumer les appels clients » ne se réduit pas à la phrase « résume-moi ces appels » ; elle invoque un résumeur d'appels, c'est-à-dire un artefact qui encode ce que votre équipe considère comme important. De même, l'action « réviser cette PRD » invoque une skill de revue qui connaît votre barre de qualité. La qualité de l'action dépend donc moins de l'éloquence du prompt que de la solidité des artefacts qu'il mobilise. C'est, transposé à la boucle, le principe que SFEIR formule crûment pour le développement : écrire du code à la main est devenu un anti-pattern — ce qui compte n'est plus la formulation, mais l'environnement qui guide l'agent.

Un principe issu de la technique Ralph Wiggum éclaire la conception de l'action : il vaut mieux dire à l'agent de choisir l'élément le plus important et de n'en faire qu'un seul à la fois. Geoffrey Huntley note que cette consigne — « pick the most important item and only do one » — réduit ce que l'agent charge dans sa fenêtre de contexte, et rend chaque itération plus fiable. Une action trop ambitieuse, qui demande tout d'un coup, produit des résultats brouillons ; une action atomique, répétée dans la boucle, produit une accumulation propre.

Bloc 3 — La Preuve (Proof) : comment savoir que c'est meilleur

La preuve est le bloc qui vérifie, de façon externe et mécanique, que le résultat d'un tour est bon — et meilleur que le précédent — plutôt que de croire l'agent sur parole. C'est le bloc le plus négligé et, paradoxalement, le plus déterminant pour la fiabilité d'une boucle.

Le principe directeur tient en une phrase d'Osmani (addyosmani.com, juin 2026) : « 'done' is a claim and not a proof » — « terminé » est une affirmation, pas une preuve. Le fait qu'un agent déclare une tâche accomplie ne prouve rien. La preuve doit être quelque chose d'externe et de vérifiable : des tests qui passent, un linter propre, une couverture de code qui atteint un seuil, une comparaison à un jeu d'exemples de référence. Plus la preuve est mécanique, plus la boucle peut tourner sans surveillance.

C'est sur ce bloc que repose toute la pratique des évaluations (evals), centrale chez les Product Managers comme chez les ingénieurs. Une eval ne réclame pas un benchmark géant ; elle peut commencer modestement, avec des exemples connus. Prenez trois PRD fortes et trois PRD faibles, faites tourner votre artefact de revue dessus : a-t-il repéré les vrais manques ? A-t-il évité les chicaneries inutiles ? A-t-il préservé l'intention produit ? On distingue souvent deux types de preuve : l'évaluation de la sortie (le résultat est-il correct ?) et l'évaluation de la trajectoire (le chemin emprunté, les appels d'outils, le raisonnement étaient-ils sains ?). Simon Willison a popularisé la formule « evals as unit tests » : les evals sont aux systèmes non déterministes ce que les tests unitaires sont au code déterministe.

Une conséquence architecturale majeure découle de ce bloc : l'agent qui produit ne doit pas être celui qui juge. C'est le principe du « maker/checker » — la même asymétrie que SFEIR décrit pour la revue de code, où le créateur cède la place à un vérificateur distinct. Dans Claude Code, la commande /goal l'implémente nativement : après chaque tour, un petit modèle rapide vérifie si la condition est remplie — de sorte que l'agent qui a écrit le code n'est pas celui qui le note.

Bloc 4 — La Mémoire : où l'apprentissage se sauvegarde

La mémoire est le bloc qui stocke sur disque les apprentissages de la boucle pour la prochaine itération — c'est lui qui transforme une répétition en amélioration. Sans mémoire, chaque tour repart de zéro ; avec mémoire, chaque tour démarre en avance sur le précédent.

Il faut distinguer soigneusement le contexte et la mémoire, car la confusion est fréquente — c'est précisément la frontière qu'établit le Context Engineering, dont notre guide complet détaille l'architecture en tiers. Shubham Saboo le formule clairement : le contexte est ce que le modèle voit pour une seule requête — éphémère, borné, perdu au redémarrage ; la mémoire est ce qui est stocké sur disque — persistant, illimité, consultable, qui survit aux redémarrages. Une boucle a besoin des deux, mais c'est la mémoire persistante qui fait sa puissance dans la durée. Comme le résume Patrick Debois, sans cette persistance « chaque session est un nouvel employé qui repart de zéro ».

Concrètement, cette mémoire peut prendre des formes simples : un fichier markdown qui liste ce qui est fait et ce qui reste à faire, un fichier AGENTS.md, un board Linear consulté via MCP. Une bonne mémoire d'état répond à trois questions, selon Cobus Greyling : sur quoi travaillons-nous en ce moment ? qu'avons-nous essayé la dernière fois, et que s'est-il passé ? qu'est-ce qui attend une décision humaine ?

Pour les ingénieurs comme pour les Product Managers, le support privilégié de cette mémoire est souvent le dépôt Git. Non pas par dogme, mais parce qu'on a besoin d'un historique de version pour les artefacts qui façonnent le travail : si un artefact s'améliore, on veut le commit ; s'il empire, on veut le diff. Le dépôt devient la mémoire du système — artefacts, résultats d'évaluation, journal de décision, chemin de retour arrière. La formule d'Osmani condense tout cela : l'agent oublie, le dépôt non.

Bloc 5 — La Condition d'Arrêt (Stop) : le bloc le plus critique

La condition d'arrêt indique quand la boucle doit se terminer — combinant une condition sémantique vérifiable et une borne quantitative (un nombre maximal d'itérations). C'est l'élément le plus critique pour les boucles récursives, et celui dont l'absence cause le plus d'échecs spectaculaires.

Shubham Saboo le martèle : beaucoup de systèmes IA n'échouent pas parce que le modèle est mauvais, mais parce que la boucle n'a pas de sortie propre. L'agent continue de générer. Il étend la portée. Il invente du travail. Ou bien il vous livre un résumé confiant sans preuve suffisante. Une boucle sans condition d'arrêt claire est une boucle qu'il faut surveiller en permanence — ce qui annule l'intérêt même de l'automatiser.

Une bonne condition d'arrêt doit autoriser plusieurs types de sortie. La boucle doit pouvoir dire : rien de significatif n'a changé ; l'entrée est trop maigre ; c'est bloqué ; la barre de qualité n'a pas été atteinte ; ceci requiert une décision humaine. Une boucle qui sait dire « stop » dans tous ces cas est une boucle que vous pouvez laisser tourner ; une boucle qui ne le sait pas est une boucle que vous devez babysitter.

Dans la pratique des outils, la condition d'arrêt prend deux formes complémentaires. La forme sémantique : une condition vérifiable que l'agent doit satisfaire, comme dans /goal (« tous les tests du dossier auth passent et le lint est propre »). La forme quantitative, qui sert de garde-fou : un nombre maximal d'itérations. La technique Ralph Wiggum fait d'un paramètre de type --max-iterations son principal mécanisme de sécurité — précisément parce qu'une condition sémantique mal formulée peut ne jamais être atteinte. La bonne pratique consiste souvent à combiner les deux : « jusqu'à ce que la condition X soit vraie, ou au bout de 20 tours, selon la première éventualité ».

La seconde grille : les blocs techniques d'Addy Osmani

À la grille conceptuelle en cinq parties s'ajoute une grille plus technique, proposée par Addy Osmani pour l'ingénierie logicielle. Elle ne remplace pas la première ; elle la concrétise en cinq primitives que l'on retrouve dans les outils actuels — au premier rang desquels Claude Code, dont les commandes natives /loop, /goal et la boucle Ralph Wiggum implémentent directement ces blocs.

Les automatisations sont le « battement de cœur » de la boucle : la découverte et le triage programmés qui se déclenchent tout seuls. Elles correspondent au bloc déclencheur, instancié par des tâches planifiées, des hooks ou /loop.

Les worktrees (arbres de travail Git) permettent à deux agents de travailler en parallèle sans se marcher dessus. C'est une condition pratique du passage à l'échelle : sans isolation, plusieurs agents qui modifient le même dossier produisent le chaos. Claude Code expose git worktree, l'option --worktree et le mode d'isolation correspondant.

Les skills consistent à écrire la connaissance du projet que l'agent devrait sinon deviner. Un fichier SKILL.md encode les conventions, les pièges connus, les façons de faire propres à votre code. C'est une part de la mémoire, mais une mémoire de savoir-faire plutôt que d'état.

Les plugins / connecteurs branchent l'agent sur les outils que vous utilisez déjà — le plus souvent via le protocole MCP (Model Context Protocol). Ils donnent à l'action et au déclencheur leur prise sur le monde réel : Slack, GitHub, Linear, une base de données.

Les sous-agents (sub-agents) incarnent le principe maker/checker : un sous-agent a l'idée, un autre la vérifie. C'est la traduction architecturale du bloc preuve — et l'endroit où le contexte se fragmente entre plusieurs agents. Cette puissance a un prix : multiplier les sous-agents fait exploser le budget de tokens, une architecture multi-agents pouvant consommer de l'ordre de quinze fois plus de jetons qu'un agent unique (Anthropic, 2025). Cobus Greyling propose un schéma de boucle complète qui assemble toutes ces primitives : planification (schedule) → skill de triage → lecture/écriture de l'état → worktree isolé → sous-agent implémenteur → sous-agent vérificateur → connecteurs MCP/Git → portail humain (si sûr, commit/PR ; si risqué, escalade) → retour à la planification.

Les cinq blocs à l'œuvre : la boucle « signal produit hebdomadaire »

Pour voir les cinq blocs s'articuler, déroulons une boucle complète — celle que Shubham Saboo recommande comme première boucle pour un Product Manager, parce qu'elle est répétée, riche en preuves et tolérante à l'erreur. L'objectif : produire chaque semaine un mémo qui sépare le signal produit récurrent du bruit isolé.

Le déclencheur est temporel et net : chaque vendredi — une cadence fixe qui rend la boucle prévisible et facile à évaluer. L'action lit un ensemble d'entrées défini à l'avance (appels clients, tickets, notes de vente, analytics, escalades) et produit un mémo unique, guidée par un artefact durable : un gabarit qui sait isoler le signal répété du bruit ponctuel et montrer ce qui a changé depuis la semaine précédente. La preuve mêle jugement humain et outillage : on relit le mémo, et on rend le contrôle systématique avec un petit jeu d'évaluation — cinq appels déjà compris, sur lesquels on vérifie que le résumeur capte la vraie douleur et distingue le fort du faible. La mémoire vit dans le dépôt : chaque mémo y est committé, ce qui permet de comparer les thèmes d'une semaine à l'autre ; si le mémo a manqué une nuance, on ne corrige pas le prompt, on met à jour l'artefact et le commit garde la trace du pourquoi.

La condition d'arrêt, enfin, est double : sémantiquement, la boucle s'arrête quand le mémo est produit et relu ; mais elle doit aussi savoir dire « rien de significatif n'a changé cette semaine » plutôt que d'inventer un signal pour justifier son existence. Cet exemple illustre la règle d'or de la première boucle : ne commencez pas par une boucle qui décide de la stratégie — trop large, trop subjective — mais par une boucle d'opérations, là où le travail est répété, où les preuves sont là, et où la cohérence compte.

Assembler les blocs : du squelette à la boucle vivante

Comment passe-t-on de ces blocs à une boucle réelle ? Saboo propose un squelette minimal qui ne réclame aucune compétence d'ingénieur : choisissez une tâche produit répétée, et notez sept choses — quand elle démarre, quelles entrées elle utilise, quel artefact la guide, ce que l'agent doit faire, à quoi ressemble une bonne sortie, où l'apprentissage est sauvegardé, et quand la boucle doit s'arrêter. C'est suffisant pour commencer.

La clé est de garder la boucle assez petite pour pouvoir réellement juger si elle s'améliore. Une boucle trop ambitieuse échoue de manière opaque : on ne sait pas quel bloc est en cause. Une boucle minimale échoue de manière lisible. Cobus Greyling recommande d'ailleurs un déploiement par paliers : niveau 1, la boucle produit un rapport (elle informe) ; niveau 2, elle propose des corrections assistées ; niveau 3, elle agit sans surveillance. On ne franchit un palier qu'après avoir gagné la confiance au précédent. Ce séquençage prudent rejoint la conviction de SFEIR : viser non pas un gain marginal mais une productivité ×10, en restructurant les équipes autour de Single Owners qui pilotent des boucles plutôt que de produire à la main.

Connaître les cinq blocs, c'est enfin disposer d'une grille de diagnostic, car chaque bloc possède son mode de défaillance caractéristique. Quand une boucle déraille, le réflexe est de demander lequel des cinq blocs est en cause — plutôt que de tâtonner sur l'ensemble du système.

Le déclencheur échoue par mauvaise fréquence : trop fréquent, il brûle des tokens à scruter un état figé ; trop rare, il laisse l'information vieillir. Remède : séparer un triage léger et fréquent d'un travail lourd et rare, déclenché seulement sur signal actionnable. L'action échoue par sur-ambition : demander tout d'un coup (« refactorise le module, écris les tests et la doc ») charge trop de contexte et produit du brouillon ; le remède est l'action atomique répétée. La preuve échoue par subjectivité : « le résultat est bon » n'est pas vérifiable et laisse l'agent juge de lui-même ; le remède est une preuve externe et mécanique, évaluée par une instance distincte de celle qui a produit. La mémoire échoue par évaporation : restée dans le chat, elle disparaît et la boucle repart de zéro ; le remède est un support persistant et versionné. La condition d'arrêt, enfin, échoue par faiblesse : mal posée, elle laisse la boucle inventer du travail ; le remède est la combinaison d'une borne quantitative et d'une condition sémantique vérifiable.

Ces cinq modes d'échec se recoupent souvent — une boucle qui s'emballe cumule fréquemment une preuve subjective et une condition d'arrêt faible — mais les traiter un bloc à la fois reste la méthode la plus sûre pour rétablir une boucle défaillante.

C'est là toute la valeur de l'anatomie. Elle transforme un objet intimidant — un système autonome qui pilote des agents — en un assemblage de cinq pièces compréhensibles. Le while true du début n'a jamais été le sujet : ce qui distingue une boucle d'ingénierie d'une simple répétition mécanique, c'est l'agencement réfléchi de ces cinq blocs. Maîtriser ces pièces, c'est passer du statut d'utilisateur qui subit ses boucles à celui d'ingénieur qui les conçoit. Reste alors à apprendre à les combiner entre elles — empiler une boucle de vérification sur une boucle d'action, brancher une boucle événementielle sur une boucle de fond — dans l'art que swyx a baptisé le loopcraft.

Points clés

• Une boucle d'agent se décompose en cinq blocs : déclencheur, action, preuve, mémoire, condition d'arrêt — une structure sur laquelle plusieurs praticiens (Saboo, Berman, Vo) ont convergé indépendamment.
• Le déclencheur décide quand la boucle tourne (temporel, événementiel ou conditionnel) ; sa règle d'or, selon Cobus Greyling, est que le triage fréquent doit rester bon marché.
• La preuve est le bloc le plus négligé : « 'done' is a claim and not a proof » (Osmani). Elle impose une vérification externe et le principe maker/checker — l'agent qui produit n'est pas celui qui juge.
• La mémoire est ce qui transforme la répétition en amélioration : contexte = éphémère par requête, mémoire = persistante sur disque (souvent le dépôt Git). « L'agent oublie, le dépôt non. »
• La condition d'arrêt est le bloc le plus critique : combiner une condition sémantique vérifiable et une borne quantitative (max-iterations) évite les boucles qui inventent du travail.
• À la grille conceptuelle répond une grille technique (Osmani) : automatisations, worktrees, skills, connecteurs MCP, sous-agents — les sous-agents pouvant multiplier par ~15 la consommation de tokens (Anthropic, 2025).
• Les cinq blocs forment aussi une grille de diagnostic : quand une boucle déraille, identifier le bloc fautif plutôt que de tâtonner sur l'ensemble.

Sources

1. Addy Osmani — Loop Engineering — addyosmani.com, 7 juin 2026.
2. Cobus Greyling — Loop Engineering — cobusgreyling.substack.com, 9 juin 2026.
3. LangChain — The Art of Loop Engineering — langchain.com, 16 juin 2026.
4. Anthropic — données multi-agents (~15× tokens vs agent unique), 2025.
5. SFEIR — matières first-party : Harness Engineering, AI for IT — 10x.