Loop Engineering

Un agent IA travaille en cycle : observer, décider, agir, vérifier, recommencer. Ce cycle existe depuis le papier ReAct (2022) et n'a rien de neuf. Ce qui est neuf, c'est le déplacement du travail d'ingénierie : la valeur ne se joue plus dans le prompt qu'on écrit à la main, mais dans la conception de la boucle qui enchaîne ces cycles sans nous.

L'escalier d'abstraction se lit simplement : le prompt engineering configure un appel, le context engineering configure une session, le loop engineering configure un système récurrent qui s'étend sur plusieurs sessions, outils et agents. Chaque couche englobe la précédente, aucune ne la remplace.

Concrètement, une boucle bien conçue a six briques (la décomposition du billet fondateur d'Addy Osmani) : des automations qui la déclenchent, des espaces de travail isolés pour paralléliser, des skills qui codifient la connaissance du projet, des connecteurs vers les outils existants, des sous-agents qui séparent celui qui produit de celui qui vérifie, et une mémoire persistante qui survit aux redémarrages.

Le signal le plus net vient des plateformes. AWS a passé en disponibilité générale son AgentCore Harness : deux appels d'API suffisent à faire tourner un agent dans un environnement isolé, avec mémoire managée et observabilité intégrée. Le message est explicite : le harness devient quelque chose qu'on configure, plus quelque chose qu'on construit.

Databricks a pris l'angle complémentaire en open-sourçant Omnigent, un méta-harness qui traite Claude Code, Codex ou Pi comme des composants interchangeables derrière une API commune, avec des règles de gouvernance dynamiques : approbation manuelle avant un git push sensible, pause automatique à un seuil de coût. C'est la couche de contrôle que les grandes organisations attendaient.

Côté outillage quotidien, GitHub a fermé la boucle dans VS Code : l'agent peut désormais vérifier visuellement son travail dans le navigateur, les sessions tournent en parallèle et une modification importante se découpe en fils dédiés (implémentation, revue, tests, documentation). Et quand IBM consacre une page de glossaire au loop engineering, on peut considérer que le terme est sorti de la niche.

NVIDIA a publié la démonstration la plus solide à date : son framework de recherche NOOA isole six capacités d'interface entre le modèle et son harness (entrées-sorties typées, code comme action, état explicite, boucle programmable, entre autres). Résultat : à modèle constant, le harness seul fait bouger les benchmarks de plusieurs dizaines de points. Autrement dit, une partie de ce qu'on attribue au « bon modèle » est en réalité du bon harness.

L'expérience la plus contre-intuitive vient de Towards Data Science : un contrôleur déterministe, sans aucun appel LLM, qui applique le cycle observer-agir-réviser. Face à un pipeline linéaire qui s'arrête à son premier obstacle, la boucle isole les échecs branche par branche : 3,3 branches complétées en moyenne contre 0,4. La leçon vaut pour tous nos clients : l'architecture de contrôle et le raisonnement sont deux couches séparées, et la première se travaille indépendamment de la seconde.

Même logique dans le retour d'expérience de l'université des Nations Unies sur l'analyse de données avec des modèles locaux : ce qui rend un petit modèle fiable, c'est la boucle qui lui renvoie ses erreurs d'exécution pour qu'il retente. L'auto-évaluation intrinsèque (le modèle qui se relit) déçoit systématiquement ; l'ancrage dans les résultats réels d'exécution fonctionne.

Santander a publié le premier retour d'expérience bancaire d'ampleur sur le sujet. Leur position rejoint ce qu'on observe en mission : le comportement d'un agent dépend moins du modèle au centre de la boucle que du harness qui l'entoure. Leurs règles : toute boucle a des conditions d'arrêt, d'escalade et de passage à l'humain explicites ; des plafonds d'itérations ; et l'agent doit régulièrement se reconfronter à des sources de vérité vérifiées plutôt que de raisonner sur son propre historique, pour empêcher les petites erreurs de se composer en grandes.

En contrepoint, un retour plus rugueux publié sur HackerNoon démonte l'orchestration multi-agents « à l'instinct » : lancer un planificateur, un codeur et un relecteur en espérant que ça converge. Sa refonte s'inspire du red teaming militaire : un rôle qui attaque le plan avant validation, un autre qui teste l'implémentation après, au motif qu'un relecteur qui ne voit que le code fini est un rapport d'accident, pas un garde-fou. La formule est brutale mais le diagnostic est juste.

La taxonomie qui circule depuis fin juillet est propre : un prompt contrôle une réponse de modèle, une boucle contrôle le cycle d'un agent, un graphe contrôle l'organisation de plusieurs agents. Trois unités de contrôle empilées, chacune préservant celle du dessous.

On garde la tête froide : le terme graph engineering est apparu six semaines après le pic de loop engineering, et le rythme d'un nouveau mot-valise par semestre invite à juger sur pièces. Ce qui est sûr, c'est que les questions qu'il recouvre (qui orchestre les orchestrateurs, comment gouverner une flotte d'agents) sont déjà celles que se posent les organisations qui ont dépassé le stade du pilote.