En juillet 2026, le domaine de la programmation par IA connaît une transformation majeure. Peter Steinberger a annoncé sur X la fin de l'ère de l'ingénierie cyclique, orientant l'industrie vers l'ingénierie de graphes. L'ingénierie cyclique, issue de la méthode Ralph de Geoffrey Huntley, contourne les limites des fenêtres de contexte en permettant aux agents IA de s'exécuter en continu jusqu'à atteindre un objectif. Entre avril et mai 2026, des outils tels que Codex et Claude Code ont introduit la fonctionnalité Goal, commercialisant ainsi l'approche cyclique. Actuellement, l'industrie explore des ingénieries de graphes plus complexes, impliquant la conception conjointe de graphes organisationnels et de graphes de travail.

Auteur de l’article, source : WeChat Official Account InfoQ (ID : infoqchina)

Nous discutons encore du cycle, ou avons-nous déjà passé à la figure ?

Le 18 juillet 2026, Peter Steinberger a annoncé discrètement la fin de l'ère de l'ingénierie circulaire sur la plateforme X avec cette phrase. Ce message a obtenu 2,6 millions de vues dans les deux jours suivant sa publication.

Il y a six semaines, il a obtenu 8,4 millions de vues avec « concevoir des boucles pour orienter les agents », faisant prendre conscience aux développeurs du monde entier que l’ère de l’ingénierie de prompts est révolue et que l’ingénierie de boucles est désormais la nouvelle direction.

Deux publications, avec un total de plus de 11 millions de vues, ont propulsé la discussion la plus populaire dans le domaine de la programmation IA vers un nouveau niveau.

La montée en puissance de la boucle

Au cours du dernier mois, « Loop Engineering » est devenu un concept très populaire dans le domaine de la programmation par IA.

Mais son origine réelle remonte à un an. En juillet 2025, l'ingénieur logiciel Geoffrey Huntley a proposé une méthode qu'il a appelée « Ralph » — une simple boucle Bash permettant à Claude d'exécuter répétitivement une tâche jusqu'à l'atteinte de l'objectif :

while :; do cat PROMPT.md | claude-code ; done

Le cœur de la méthode Ralph réside dans la contournement des limites de la fenêtre de contexte. À l'époque, en milieu d'année 2025, la taille maximale de la fenêtre de contexte était de 200 000 tokens. Cela était largement insuffisant pour des tâches plus complexes, ce qui nécessitait de décomposer l'exécution de l'agent en unités plus petites, à exécuter une par une.

Dans ce contexte, la méthode Ralph fonctionne comme suit :

• Définissez un objectif pour le projet, puis exécutez ou réexécutez l'Agent jusqu'à ce que l'objectif soit atteint.
• Persistez les travaux déjà effectués sous forme « compressée » dans le système de fichiers, par exemple en les enregistrant sous forme de journaux ou de plans mis à jour.
• Démarrez l'Agent avec un nouveau contexte pour minimiser la "corruption du contexte".
• Permettre à chaque agent d'ajouter ou de modifier le « plan global » si nécessaire.

Huntley a utilisé cette méthode pour construire un langage de programmation à partir de zéro, validant sa faisabilité. Mais ce n'est qu'avec l'apparition de modèles plus puissants qu'il s'est répandu rapidement dans la communauté des développeurs.

Le succès de Loop s'explique également par certains développeurs clés d'Anthropic et d'OpenAI. Lors de la conférence des développeurs d'Anthropic, Boris Cherny, créateur de Claude Code, a déclaré : « Je ne donne plus de instructions à Claude. J'exécute des boucles qui envoient des instructions à Claude et déterminent la suite des actions. Mon travail consiste à écrire des boucles. »

Ensuite, Peter Steinberger a également publié un message appelant les développeurs à cesser de fournir directement des invites aux agents de programmation : « Rappel mensuel : vous ne devriez plus saisir manuellement les invites pour les agents de programmation. Vous devriez concevoir des boucles capables de générer des invites pour les agents. »

L'ingénieur ancien de Google, Addy Osmani, a ensuite rédigé un article intitulé « Loop Engineering », qu'il résume ainsi : « L'ingénierie de boucle consiste à se retirer du rôle de celui qui donne directement des instructions à l'Agent, pour concevoir un système qui accomplira cette tâche à votre place. »

Le concept est là, le nom est choisi, et l'infrastructure suit rapidement.

Entre avril et mai 2026, Codex, Claude Code et Hermes ont introduit la commande /goal, transformant des boucles écrites à la main en une seule instruction.

Six mois après le déploiement généralisé de Ralph, Codex a lancé la fonction goal.

La documentation Codex indique : « Les objectifs sont des cibles persistantes dans Codex qui permettent à un fil de conversation de progresser vers un résultat précis à travers plusieurs interactions. Un objectif fournit à Codex une condition de fin : quel état doit être atteint, comment vérifier le succès, et quelles contraintes doivent toujours être respectées. »

Le document précise particulièrement : « Les instructions générales expriment : faites maintenant cela. Le but exprime : continuez à travailler jusqu'à ce que ce résultat soit atteint. »

Dans une requête standard, Codex traite l'instruction actuelle, rapporte les résultats, puis attend les prochaines étapes. Lorsqu'un objectif (Goal) est utilisé, un objectif persistant est associé au thread. À la fin d'un cycle d'exécution, il peut examiner les preuves actuelles et déterminer si l'objectif a été atteint. Si la réponse est négative et que l'objectif reste actif tout en n'ayant pas épuisé le budget, Codex peut reprendre son travail à partir de l'état le plus récent.

Par exemple : « Réduire la latence p95 dans les tests de paiement à moins de 120 ms, tout en garantissant que la suite de tests de correction passe systématiquement. »

Ceci est un « critère de fin » suffisamment clair pour être directement transmis à l’Agent. Ensuite, l’Agent décomposera automatiquement la tâche, créera des sous-Agents et continuera à s’exécuter jusqu’à la completion du travail. L’équipe Codex s’est inspirée de la boucle de Ralph pour construire l’infrastructure correspondante : coordonner plusieurs Agents, éviter qu’ils ne se perturbent mutuellement ; gérer l’état ; exécuter des tests ; démarrer et arrêter les Agents ; puis ajouter ultérieurement des fonctionnalités telles que la définition de budgets.

Architecture de la fonctionnalité Goals

Comment les développeurs utilisent-ils les boucles ?

Qu'est-ce que les développeurs font réellement avec une boucle ? Selon les retours de la communauté, le scénario le plus courant reste le traitement de tâches périodiques.

Mais la capacité de boucle va bien au-delà de cela. La véritable valeur de l'ingénierie de boucle réside dans certaines tâches à long terme plus complexes nécessitant des itérations continues.

Par exemple, effectuer un grand transfert de code. Le fondateur d'entreprise start-up Rafel Mendiola devait convertir une application React en React Native. La méthode traditionnelle consistait à créer un grand Epic, puis à le décomposer en 50 à 100 tickets, ce qui rendait la mise en place de l'infrastructure intimidante.

Son alternative consiste à créer une compétence permettant à l’agent d’identifier automatiquement les blocs de code transférables, d’effectuer la conversion, de suivre la progression, puis d’intégrer cette compétence dans une tâche Cron exécutée toutes les 30 minutes. Cette approche est beaucoup plus légère sur le plan cognitif que la gestion d’un vaste plan de migration.

Prochaine étape : Graph

La question de Peter fait en réalité référence à un chemin d'évolution.

Il y a un an, le prompt engineering était une compétence essentielle. En 2025 et au début de 2026, l'accent s'est déplacé vers la conception de boucles. Maintenant, Peter pointe vers un domaine encore plus éloigné : concevoir des graphes composés de plusieurs boucles — chaque agent exécute sa propre boucle, connectée aux autres par des dépendances.

La réponse la plus remarquable dans la chaîne de commentaires de ce tweet provient de Luis Catacora : « Il y a beaucoup de marge d'erreur dans le cycle. Le graphique vous oblige à reconnaître combien de parties du flux de travail ne sont pas réellement modélisées. »

Cette phrase illustre la différence entre ces deux paradigmes. La boucle vous permet de reporter la conception de l’architecture : commencez par faire accomplir tout le travail à un seul Agent, jusqu’à ce qu’il ne puisse plus le gérer. Le graphe, en revanche, exige que vous définissiez à l’avance l’ensemble de la structure — qui est responsable de quoi, quelles tâches dépendent des autres, et que faire en cas d’échec d’une branche. La boucle repose sur une décision différée, le graphe sur une décision anticipée.

Shubham Saboo, produit manager senior en intelligence artificielle chez Google et auteur de la bibliothèque de code Awesome LLM Apps (plus de 124 000 étoiles sur GitHub), propose une autre décomposition, distinguant deux niveaux : « Le diagramme organisationnel à long terme définit qui est responsable de quel domaine et conserve le contexte ; le diagramme de travail définit ce qui doit être fait actuellement, et peut être divisé, fusionné, réordonné ou disparaître directement selon les preuves. »

What the heck is Graph?

Loop permet de rendre les comportements des agents programmables. Graph permet de rendre l'organisation des agents programmable.

Le pas suivant est l'organisation dynamique d'agents : pendant l'exécution de la tâche, le Graph réécrit automatiquement sa propre structure.

Preston Holmes : Il existe au moins deux graphes importants. Le premier est celui que vous montrez dans votre graphique, composé d'agents persistants qui, comme une défense par zone, sont chacun responsables d'une région. Le second est le graphe formé par les tâches à accomplir. Il est dynamique et change constamment.

Shubham Saboo : Le « schéma organisationnel » persistant détermine qui est responsable de chaque zone et assure la conservation du contexte. Le « schéma de travail » détermine quelles tâches doivent être accomplies actuellement. Il peut être divisé, fusionné, réordonné ou disparaître complètement au fur et à mesure de l'apparition de nouveaux éléments.

Ceci est essentiel pour un système multi-agent de production : en réalité, deux graphiques fonctionnent simultanément.

Organigramme (Org Graph) : définit « qui est responsable de quoi ». Il est composé d'agents permanents, chacun chargé d'un domaine fixe, conservant le contexte, les compétences spécialisées et les autorisations d'outils de ce domaine. L'organigramme est relativement stable, semblable à la structure organisationnelle d'une entreprise.

Graphique de travail (Work Graph) : définit « ce qui doit être fait maintenant et comment les tâches se transmettent ». Il évolue en continu avec les tâches et les nouvelles preuves, et peut être décomposé, fusionné, réorganisé ou annulé directement. Le graphique de travail ressemble davantage à un plan de projet généré en temps réel.

Preston Holmes est également d'avis que les deux graphiques sont importants et qu'ils fonctionnent à des échelles de temps différentes. Le graphique d'organisation est conçu et déployé à l'avance ; le graphique de travail est généré dynamiquement pour chaque tâche et supprimé une fois la tâche terminée.

Si la boucle rend le comportement de l'Agent programmable, alors le graphe rend l'organisation de l'Agent programmable. La prochaine étape est l'organisation dynamique des agents — pendant l'exécution de la tâche, le graphe réécrit automatiquement sa propre structure.

Du bon usage des prompts à la conception des boucles, puis à la construction des graphes, le centre de gravité des capacités de programmation par l'IA continue de s'élever. Les développeurs doivent de moins en moins se préoccuper de la manière d'interagir avec un agent unique, et de plus en plus réfléchir à la conception de structures de collaboration entre agents.