BuildRéservé aux abonnés 14/07/2026 à 22h307Ajouter aux favoris

Un agent, ce n'est pas de la magie. C'est une boucle d'inférence, une boucle d'outils, et un humain qui bloque. Le métier bascule : on n'écrit plus le prompt, on écrit la boucle.
Un « agent IA », démonté, ce sont trois boucles empilées : une qui parle au modèle, une qui exécute les outils qu'il réclame, et une qui attend qu'un humain dise oui. La première est triviale, la troisième est un enfer d'ingénierie. Et le métier de dev est en train de se déplacer vers l'écriture de ces boucles plutôt que vers l'écriture des prompts.
Le billet de bobbytables.io fait ce que trop peu de contenus « agentic » font : il montre le code. La boucle d'inférence est une boucle while presque bête - on appelle l'API de complétion, on empile le résultat dans l'historique, et on sort dès que le modèle ne demande plus d'outil. La boucle d'outils prend le relais quand il en demande un : on résout le nom, on appelle la fonction, on renvoie le résultat corrélé par son tool_call_id.
C'est là que se cache le piège que l'auteur pointe justement : un appel d'outil est lui aussi du texte inféré. Donc le nom de la fonction et ses paramètres peuvent être hallucinés. Votre dispatcher d'outils n'est pas un routeur, c'est une surface d'attaque et de validation.
La troisième - la boucle humaine - n'en est pas une, techniquement. C'est un appel bloquant : quelqu'un, quelque part, décide de continuer ou non. C'est aussi la seule qui casse votre process, parce qu'un humain peut mettre trois jours à répondre. D'où le recours à des moteurs d'exécution durable type Temporal.
while continueInferenceLoop
inferred = aiClient.completeChat(messages: chatMessages)
chatMessages.push(inferred result)
if inferred.toolCalls.length == 0
continueInferenceLoop = false
end Quatre lignes. Tout le reste - la persistance de l'historique, l'idempotence des outils, la reprise après l'approbation humaine - est de l'ingénierie classique de systèmes distribués. Pas de l'IA.
Le pendant industriel de cette anatomie a un nom, et The Pragmatic Engineer vient de le documenter : le loop engineering. La formule d'Addy Osmani résume la bascule - « You design the system that does it instead » : vous ne formulez plus la demande, vous concevez le système qui la formule en boucle. Boris Cherny (Anthropic) va plus loin : « My job is to write loops ». La technique descend de la « Ralph loop » de Geoffrey Huntley, une simple boucle Bash qui rappelle l'agent jusqu'à atteindre l'objectif.
Les usages qui ont shippé sont prosaïques : PR ouverte automatiquement sur un nouveau ticket Sentry, correction des tests instables pendant les runs nocturnes, triage d'alertes, migrations longues. Depuis mai 2026, Codex, Claude Code et Hermes exposent une commande /goal qui emballe tout ça.
Si vous recrutez, la compétence à chercher n'est plus « sait prompter ». C'est : sait rendre une boucle idempotente, observable et interruptible.
Créez un compte gratuit pour accéder à l'intégralité de nos contenus et à la revue hebdomadaire.
Article produit par intelligence artificielle, relu sous contrôle éditorial humain.
Connectez-vous pour rejoindre la discussion.
Est-ce que ces boucles peuvent vraiment comprendre les sentiments et l'intuition humaine ?
Est-ce que les boucles peuvent vraiment remplacer la créativité humaine ?
Comment évaluer la courbe d'apprentissage pour maîtriser ces boucles ? Est-ce vraiment accessible ?
Comment adapter ces boucles à des situations imprévues ?
Est-ce que ces boucles ne vont pas tuer la créativité humaine ?
Je suis d'accord, mais comment éviter que l'humain dans la boucle ne devienne inutile ? Quel est l'équilibre ?
L'humain reste indispensable pour valider et guider. L'éducation continue est la clé pour rester pertinent.
Intéressant, mais à quoi sert l'humain dans la boucle ? On devient juste des surveillants ?
Harness Ops : post-mortems et bench des agents en prod