Pendant longtemps, on a beaucoup parlé de prompt engineering. C'était logique : quand les modèles sont arrivés, le premier réflexe était d'apprendre à mieux leur parler. Ensuite, on a compris que le contexte était déterminant. Aujourd'hui, avec les agents, je suis convaincu que le sujet central devient la boucle.

Un agent IA ne se limite pas à produire une réponse. Il peut lire, chercher, appeler un outil, modifier un fichier, lancer un test, demander une validation humaine et reprendre son travail. À partir de ce moment, la question n'est plus seulement : "que doit-il répondre ?". La vraie question devient : comment doit-il avancer ?

C'est exactement le rôle du loop engineering : concevoir la boucle d'exécution d'un agent pour qu'elle soit utile, lisible, vérifiable et maîtrisée.

Moment 01

Agir

Choisir une action utile, limitée et compatible avec les droits accordés.

Moment 02

Observer

Récupérer le résultat réel de l'environnement, pas une impression.

Moment 03

Vérifier

Contrôler que l'étape a vraiment rapproché l'agent du résultat attendu.

Définition simple du loop engineering

Le loop engineering, c'est la conception de la boucle qui pilote un agent IA pendant l'exécution d'une tâche. Cette boucle peut être très simple : objectif, action, observation, décision, nouvelle action, puis terminaison. Mais sa simplicité apparente cache un vrai sujet d'architecture.

Un modèle peut proposer une action. Le loop engineering décide comment cette action est exécutée, comment le résultat est récupéré, comment l'erreur est remontée, comment le contexte est mis à jour, quand l'humain doit valider, et quand l'agent doit arrêter.

Dit autrement : le prompt donne une intention, le contexte donne de la matière, la boucle donne une trajectoire.

Pourquoi ce sujet devient central

Anthropic décrit les agents comme des systèmes dans lesquels le modèle peut diriger dynamiquement son processus et son usage des outils. Dans cette logique, le modèle n'est plus seulement un générateur de texte. Il devient une pièce de décision dans une boucle plus large.

Le papier ReAct a posé une idée très forte : raisonner et agir doivent être pensés ensemble. Le modèle peut alterner entre raisonnement, action et observation pour avancer dans un environnement. C'est une base très importante pour comprendre les agents modernes.

De plus, les frameworks récents vont tous dans ce sens. OpenAI Agents SDK expose des notions comme tools, sessions, guardrails, human in the loop et tracing. LangGraph se concentre sur l'orchestration durable, la mémoire, les interruptions, le streaming et la persistance. Tout cela montre une chose : la qualité d'un agent dépend de plus en plus de la qualité de sa boucle.

L'anatomie d'une bonne boucle agentique

1. L'objectif doit être exploitable

Un agent ne doit pas partir avec une mission floue. Il doit comprendre le résultat attendu, le périmètre, les limites et les critères de fin. Sinon, il risque de multiplier les étapes sans vraiment avancer.

2. L'action doit être bornée

Chaque outil donné à l'agent doit avoir une intention claire. Lire un fichier, chercher une information, appeler une API, créer un brouillon, lancer un test : chaque action doit avoir un cadre. Plus l'action est large, plus le risque augmente.

3. L'observation doit être exploitable

Une boucle fiable dépend de la qualité du retour. Si un outil échoue, le modèle doit le savoir. Si un test ne passe pas, l'erreur doit être visible. Si une API répond vide, ce vide doit être interprété comme une information, pas comme un succès silencieux.

4. La vérification doit être intégrée

J'ai pu constater que les agents les plus utiles ne sont pas ceux qui produisent le plus vite. Ce sont ceux qui savent se confronter au réel. Un agent de code doit lancer des tests. Un agent de recherche doit citer ses sources. Un agent métier doit vérifier l'état final dans le système concerné.

5. La terminaison doit être claire

Un agent doit savoir s'arrêter. C'est un point souvent sous-estimé. Sans conditions d'arrêt, une boucle peut continuer à consommer du temps, des tokens et de l'énergie sans apporter plus de valeur. Il faut donc définir ce qui signifie : terminé, bloqué, à valider, ou hors périmètre.

Les erreurs classiques

La première erreur est de croire qu'un meilleur modèle compensera une boucle fragile. Un modèle plus intelligent peut masquer le problème pendant une démo, mais en production les limites reviennent : erreurs silencieuses, outils ambigus, contexte trop long, absence de preuve.

La deuxième erreur est de donner trop d'autonomie trop tôt. Un agent n'a pas besoin de tous les outils dès le premier jour. Il a besoin d'un petit périmètre bien maîtrisé, avec des observations fiables et des validations claires.

La troisième erreur est de ne pas tracer la boucle. Si on ne sait pas quel outil a été appelé, avec quelles entrées, quel résultat, quel coût et quelle décision suivante, on ne peut pas améliorer le système. On pilote à l'aveugle.

Ma méthode pour concevoir une boucle

J'aime repartir du terrain. Avant de parler framework, je pose une question simple : quelle est la tâche réelle que l'agent doit accomplir, et comment un humain compétent vérifierait qu'elle est terminée ?

  • Définir le résultat attendu : ce que l'agent doit livrer, pas seulement ce qu'il doit faire.
  • Découper les étapes : recherche, action, vérification, correction, validation.
  • Limiter les outils : donner uniquement les capacités nécessaires à la tâche.
  • Structurer les observations : chaque outil doit renvoyer un résultat clair, utile et interprétable.
  • Ajouter les garde-fous : droits, sandbox, validation humaine, refus explicite.
  • Tracer la boucle : logs, coûts, erreurs, décisions et état final.
  • Définir l'arrêt : succès, blocage, doute, limite atteinte ou validation demandée.

En parallèle, je pense qu'il faut garder une vraie humilité sur ce sujet. Les agents sont puissants, mais ils peuvent aussi échouer d'une manière très crédible. Le loop engineering sert justement à éviter que l'agent donne l'impression d'avancer alors qu'il ne fait que produire du texte autour d'un problème mal vérifié.

Mon objectif est vraiment de défendre une approche plus mature de l'IA : moins fascinée par la démo, plus attentive à l'architecture, aux preuves et à la valeur concrète. Le loop engineering va dans ce sens. Il permet de passer d'une IA qui répond à une IA qui travaille, avec un cadre.

À retenir

Le loop engineering est probablement l'un des sujets les plus importants pour comprendre les agents IA modernes. Ce n'est pas un nouveau mot pour faire tendance. C'est une vraie discipline d'architecture.

Un agent fiable, ce n'est pas seulement un bon modèle avec un bon prompt. C'est une boucle bien conçue : elle agit, observe, vérifie, corrige, demande de l'aide quand il faut, puis s'arrête proprement.