L'ingénierie des boucles : la compétence qui a discrètement remplacé le prompt engineering

Alors, qu'est-ce que l'ingénierie des boucles, exactement ?

Commençons par ce qui est conçu. Un agent IA, réduit à son essence, est "un LLM dans une boucle while avec des outils." Il reçoit une entrée, le modèle réfléchit à quoi faire, appelle un outil, observe le résultat, et recommence jusqu'à ce que la tâche soit terminée ou qu'une limite soit atteinte. Ce cycle, c'est la boucle de l'agent IA, et c'est la seule caractéristique qui distingue un agent d'un chatbot : un chatbot répond en un seul passage, un agent persiste et s'adapte sur de nombreuses étapes.

L'ingénierie des boucles est la discipline qui consiste à rendre cette boucle fiable. Comme l'a dit Simon Willison en nommant cette pratique :

"Ma définition préférée d'un agent LLM est quelque chose qui exécute des outils en boucle pour atteindre un objectif. L'art de bien les utiliser consiste à concevoir soigneusement les outils et la boucle qu'ils vont utiliser."

Simon Willison, Designing agentic loops (septembre 2025)

La façon la plus claire de voir où cela se situe est d'observer comment cet art s'est développé par couches. Le prompt engineering est venu en premier : écrire une bonne instruction. Puis le context engineering : organiser tout l'ensemble des tokens que le modèle voit à chaque tour, pas seulement le prompt. L'ingénierie des boucles se situe au-dessus des deux, elle conçoit le système d'exécution autour du modèle.

Anthropic décrit la couche intermédiaire comme "la progression naturelle du prompt engineering", et la même logique se prolonge encore d'un cran :

"Un agent qui tourne en boucle génère de plus en plus de données susceptibles d'être pertinentes pour le prochain tour d'inférence, et ces informations doivent être affinées de façon cyclique."

Anthropic, Effective context engineering for AI agents

La relation n'est donc pas concurrentielle, elle est imbriquée. Le prompt engineering optimise un seul appel. Le context engineering optimise l'état que le modèle voit à chaque tour. L'ingénierie des boucles optimise la mécanique qui décide si l'agent atteint un jour un bon état. Si vous avez lu notre article sur le prompt engineering, voici l'étage suivant.

Pourquoi la boucle est devenue le levier, pas le prompt

Pendant une bonne partie de 2023 et 2024, la chose la plus intelligente à faire était d'apprendre à parler au modèle. Cela fonctionnait parce que les modèles répondaient en un seul passage. Au moment où ils ont commencé à tourner en boucles, à appeler des outils et à agir sur de nombreuses étapes, le prompt a cessé d'être le goulot d'étranglement. Ce qui risque le plus de casser un agent aujourd'hui, ce n'est pas une instruction mal formulée, c'est une boucle sans interrupteur d'arrêt, sans stratégie de mémoire, ou sans moyen de vérifier son propre travail.

Solomon Hykes, le fondateur de Docker, a résumé le danger en une phrase que tout le secteur cite désormais :

"Un agent IA est un LLM en train de saccager son environnement en boucle."

Solomon Hykes, via Simon Willison (AI Engineer World's Fair, juin 2025)

Voilà le recadrage. Un modèle plus puissant dans une boucle mal conçue est plus dangereux, pas moins, car il exécute ses mauvaises idées avec plus de compétence. La communauté des praticiens a vite compris cela. Sur Hacker News, l'une des publications les plus votées sur le sujet s'intitule sobrement "The canonical agent architecture: a while loop with tools", et un autre fil populaire sur l'efficacité déraisonnable d'une boucle d'agent LLM regorge de gens surpris de voir à quel point une boucle simple fonctionne bien une fois que l'échafaudage autour est bien fait.

LangChain a résumé cela en une équation limpide : Agent = Modèle + Harness.

"L'ingénierie de harness consiste à construire des systèmes autour des modèles pour en faire des moteurs de travail. Le modèle contient l'intelligence et le harness rend cette intelligence utile."

LangChain, The anatomy of an agent harness

Qu'on l'appelle ingénierie des boucles, ingénierie de harness, ou codage agentique (les étiquettes ne sont pas encore fixées), l'idée est la même : si vous n'êtes pas le modèle, vous êtes la boucle, et c'est dans la boucle que réside désormais l'ingénierie.

Les cinq leviers d'une boucle bien conçue

En parcourant ceux qui définissent ce domaine, Willison, Anthropic, LangChain, Thoughtworks, la boucle se décompose à chaque fois dans la même poignée de leviers. Ce sont les molettes que vous actionnez réellement.

1. Outils (l'interface agent-ordinateur). Ce que l'agent peut réellement faire. Anthropic a passé plus de temps à optimiser les outils que le prompt dans ses travaux sur SWE-bench, et a inventé le terme ACI (interface agent-ordinateur), l'équivalent pour l'agent d'une interface utilisateur. Willison préfère les commandes shell simples pour les agents de codage parce que "les agents de codage sont vraiment doués pour exécuter des commandes shell."
2. Conditions d'arrêt. Quand la boucle a le droit de s'arrêter, en cas de succès, à un plafond maximal d'itérations, à une limite de budget, ou quand elle détecte qu'elle ne progresse plus. Une boucle sans logique d'arrêt déclare la victoire trop tôt ou ne s'arrête jamais. Anthropic : "il est aussi courant d'inclure des conditions d'arrêt (comme un nombre maximal d'itérations) pour garder le contrôle."
3. Gestion du contexte. Ce qui survit d'un tour à l'autre. Les techniques ici sont la compaction (résumer et redémarrer près de la limite de la fenêtre), la prise de notes (un NOTES.md que l'agent conserve en dehors de son contexte), et les sous-agents qui consomment chacun des dizaines de milliers de tokens mais renvoient un résumé compact de 1 000 à 2 000 tokens. La raison pour laquelle cela compte : la capacité de rappel se dégrade à mesure que le nombre de tokens augmente, il faut donc organiser activement (voir notre note sur la taille de la fenêtre de contexte).
4. Vérification. Comment la boucle prouve qu'elle a réellement fait ce qu'il fallait. C'est le levier le plus souvent répété. Willison affirme que la valeur d'un agent de codage "est massivement amplifiée par une suite de tests bonne et qui passe proprement." Le harness d'Anthropic pour les agents de longue durée utilise une liste de fonctionnalités en JSON de plus de 200 fonctionnalités de bout en bout, chacune initialement marquée passes: false, de sorte que l'agent ne peut pas marquer une fonctionnalité comme terminée sans le prouver.
5. Garde-fous. Ce qui empêche la boucle de faire des dégâts. Bacs à sable, identifiants strictement cadrés, et budgets. Willison a donné à Claude Code sa propre organisation Fly.io avec un budget de 5 dollars pour qu'une boucle incontrôlée ne puisse pas dépenser de vrai argent.

Quand un agent se comporte mal, la correction se situe presque toujours dans l'un de ces cinq leviers, pas dans un prompt reformulé. Voici le diagnostic rapide auquel je recours :

L'ingénierie des boucles, mais pour le support client

Voici la partie que la plupart des articles centrés sur le codage passent sous silence. La version la plus claire du métier de loop engineer dans le monde réel, ce n'est pas de construire une CLI de codage, c'est de faire tourner un agent IA sur une véritable file de support, et je le dis en tant que personne qui construit ce type d'agents pour gagner sa vie.

Un ticket de support est une boucle quasi parfaite. L'agent perçoit le message entrant, raisonne sur l'intention, récupère ce dont il a besoin (historique de commandes, documentation, état du compte), exécute une action (un remboursement, une réinitialisation, une mise à jour de ticket), vérifie le résultat, puis résout le ticket ou le transmet à un humain. Anthropic désigne le support comme "un terrain naturel pour des agents plus ouverts", précisément parce que le travail nécessite à la fois de la conversation et de l'action, avec un succès qui "peut être clairement mesuré par des résolutions définies par l'utilisateur."

Et chacun des cinq leviers correspond à une décision de support qui compte pour les acheteurs plus qu'ils ne le réalisent. Nous avons passé les trois dernières années et plus à déployer des agents IA sur de véritables files de support, et ce qui décide si un déploiement fonctionne n'est jamais l'astuce du prompt. C'est la boucle. La version la plus incisive de cela que j'aie entendue venait d'une responsable CX d'une marque de compléments alimentaires en DTC, sur Gorgias et Shopify, gérant environ 7 000 tickets par mois, qui nous a dit lors d'un appel :

"L'IA ne pourra jamais répondre à 100% des questions... J'ai besoin d'une IA qui ne traite que les tickets pour lesquels elle est confiante et qui laisse tranquilles tous les autres."

C'est une exigence d'ingénierie des boucles exprimée en langage courant. "Ne traite que ce dont tu es sûre" est une condition d'arrêt et un garde-fou fusionnés en un seul, et c'était l'unique fonctionnalité qui a décidé de leur choix d'achat. Un bot qui essaie de répondre à tout est impressionnant en démo et sape discrètement la confiance en production. C'est le même schéma d'échec derrière la plupart des problèmes de chatbots IA : pas de portail de confiance, donc il répond quand il ne devrait pas. C'est aussi la ligne de démarcation entre un véritable agent et un chatbot à base de règles, qui ne peut absolument pas faire ce genre de jugement.

Le levier de vérification a un équivalent exact côté support. En codage, on vérifie avec une suite de tests. En support, on vérifie en simulant l'agent sur ses propres tickets passés avant qu'il ne touche un seul client, en observant ce qu'il aurait dit, où la couverture est faible, et ce qu'il fait mal. C'est l'équivalent, dans le monde du support, de la discipline d'Anthropic des "200 fonctionnalités, toutes passes: false", et c'est pourquoi nous avons intégré la simulation à l'agent helpdesk d'eesel plutôt que de laisser les équipes le découvrir en production.

Les chiffres confirment pourquoi l'ingénierie compte. Dans un rapport de référence de 2026, Notch situe les chatbots traditionnels entre 10 et 25% de résolution, et les plateformes agentiques (celles qui "se connectent directement aux systèmes CRM, de facturation et de sinistres et exécutent des actions") entre 70 et 85% de résolution de bout en bout. L'écart ne vient pas de la qualité du modèle, chaque niveau peut utiliser les mêmes modèles de pointe. L'écart vient de savoir si quelqu'un a conçu la boucle autour. La phrase la plus incisive du rapport est un conseil d'achat : la question honnête à poser à un fournisseur est "non pas quel est son taux de résolution, mais ce qu'il compte comme résolu."

Vous pouvez aussi ajuster cette boucle en langage courant plutôt qu'en code, ce qui rend justement l'ingénierie des boucles accessible à une équipe de support, et pas seulement aux ingénieurs.

Construire la boucle vous-même, ou en utiliser une déjà construite

Une fois qu'on voit l'automatisation du support comme de l'ingénierie des boucles, la question du build-versus-buy devient plus claire. Vous pouvez construire la boucle vous-même sur l'API brute de Claude ou d'OpenAI, beaucoup d'équipes techniques le font, et les articles sur les bonnes pratiques de Claude Code sont un très bon endroit pour apprendre ce métier. Mais le harness est la partie difficile, et c'est la partie qu'il faut continuer à maintenir. Le travail d'Anthropic sur les agents de longue durée a lui-même nécessité une liste de vérification de plus de 200 fonctionnalités, une orchestration de sous-agents, et une logique de compaction, et cela juste pour garder un agent de codage sur les rails. Une boucle de support en production ajoute par-dessus le routage par confiance, la gestion multilingue, des règles par type de ticket, et une transmission propre à un humain.

Un responsable ingénierie d'une entreprise de matériel crypto, avec une base de connaissances de plus de 300 articles, a résumé le calcul après avoir choisi d'acheter :

"Nous aurions pu essayer d'écrire notre propre application LLM, mais nous ne voulions pas y investir notre temps. Nous voulions quelque chose que nous n'aurions pas à maintenir."

Karel, responsable ingénierie chez GENERAL BYTES (client eesel)

Voilà le véritable arbitrage. La boucle est désormais le produit, la question est donc de savoir si vous voulez être celui qui la conçoit et la maintient, ou si vous préférez acheter une boucle déjà conçue pour le cas d'usage du support. Si vous évaluez cette seconde option, notre comparatif du meilleur logiciel de helpdesk IA, notre panorama d'exemples d'agents IA, et notre sélection des meilleurs agents IA constituent une bonne carte pour savoir qui a fait ce travail d'ingénierie, et avec quel niveau de qualité.

Essayer eesel

eesel AI est, dans le cadre de cet article tout entier, une boucle déjà conçue pour le support. Vous la branchez sur votre helpdesk (Zendesk, Freshdesk, Gorgias, Help Scout, et plus de 100 autres), et elle apprend de vos tickets et documents passés dès le premier jour. Les cinq leviers sont déjà construits pour le cas d'usage du support : la simulation sur vos tickets historiques est l'étape de vérification, le routage basé sur la confiance est la condition d'arrêt, et les actions cadrées ainsi que les exclusions par type de ticket sont les garde-fous, le tout configurable en langage courant plutôt qu'en code.

C'est pour cela qu'une équipe comme Gridwise a vu eesel résoudre 73% des demandes de niveau 1 dès le premier mois, la boucle tournant d'abord sous supervision et gagnant en autonomie à mesure que la simulation prouvait qu'elle était sûre. Vous obtenez la boucle conçue, et la vérification pour lui faire confiance, sans avoir à mettre en place et à maintenir la vôtre. Vous pouvez commencer gratuitement et la simuler sur votre propre historique de tickets avant qu'un seul client ne la voie.