Ingénierie des boucles : définition pour les agents IA

Ce que signifie l’ingénierie des boucles

L’ingénierie des boucles consiste à concevoir le cycle répétitif exécuté par un agent d’IA : ce qui le réveille, les éléments auxquels il peut accéder, la manière dont sa sortie est vérifiée et ce qui l’arrête. L’ingénierie des prompts façonne un message destiné à un modèle. L’ingénierie des boucles façonne le processus qui envoie des milliers de messages pendant votre sommeil. L’unité de travail passe du prompt à la boucle.

En bref : vous cessez d’écrire des instructions et commencez à écrire un système de contrôle. L’agent a toujours besoin de bonnes instructions, mais celles-ci deviennent un composant d’un cycle qui s’exécute selon un calendrier, travaille dans une copie isolée de votre code, prouve son propre résultat au moyen d’un test et s’arrête lorsqu’un budget est épuisé.

Pourquoi le terme est apparu en 2026

Le nom est en train de se fixer publiquement. Le dépôt GitHub cobusgreyling/loop-engineering a dépassé 9,600 étoiles en moins de deux mois après sa première apparition (en juillet 2026), avec la formule « Ne rédigez plus de prompts. Concevez la boucle. Obtenez un score. » Il regroupe cette évolution en six composants : planification, worktrees, skills, plugins et connecteurs, sous-agents, et mémoire durable conservée en dehors de la conversation.

Il cite Boris Cherny, qui dirige Claude Code chez Anthropic :

Je ne rédige plus de prompts pour Claude. J’ai des boucles qui rédigent des prompts pour Claude.

Un second dépôt, AI-Builder-Club/skills, compte près de 1,100 étoiles (en juillet 2026) et nomme directement les deux rôles : un « codebase harness » qui permet à un agent d’exécuter des tests et des déploiements dans un dépôt de manière sûre, et un « loop engineer » qui crée des workflows déclenchés par un événement, effectue le travail, puis écrit ce qu’il a appris dans un fichier partagé afin que la boucle suivante puisse le lire.

Aucun de ces dépôts n’a inventé cette pratique. Toute personne ayant déjà exécuté une build nocturne, un linter dans l’intégration continue ou une tâche cron qui ouvre un ticket en connaît déjà le principe. La nouveauté est que le worker de la boucle est désormais non déterministe. Cela modifie les fonctions que doit assurer l’infrastructure environnante.

Les quatre éléments d’une boucle

Toute boucle fonctionnelle comporte ces quatre éléments. Une boucle qui en omet un peut vous réveiller à 3am.

• Déclencheur. L’événement qui démarre une exécution : un timer, un webhook, une nouvelle pull request ou une alerte.
• Périmètre. Les fichiers, les identifiants et le réseau auxquels l’agent peut accéder pendant cette exécution.
• Vérification. Un contrôle avec un exit code qui détermine si la sortie de l’exécution est conservée ou rejetée.
• Budget. La limite de tokens, de temps et d’argent qui met fin à une exécution, qu’elle ait réussi ou non.

Transformez ces quatre éléments en questions : vous obtenez une revue de conception pour tout agent que vous êtes sur le point de laisser s’exécuter.

Déclencheur : ce qui réveille l’agent

Un timer est le déclencheur le plus simple. Sur un serveur Linux, un systemd timer est préférable à cron, car il journalise les exécutions, réessaie selon vos paramètres et ne démarre pas une deuxième instance d’une unité qui s’exécute encore. Cette dernière propriété élimine le problème de chevauchement le plus courant dans les boucles d’agent : deux exécutions qui modifient la même branche.

Créez l’unité dans /etc/systemd/system/agent-loop.service :

[Unit]
Description=Agent loop: triage open issues
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
User=agent
WorkingDirectory=/srv/agent/repo
ExecStart=/srv/agent/bin/loop.sh
TimeoutStartSec=1800

Puis créez le timer dans /etc/systemd/system/agent-loop.timer :

[Unit]
Description=Run the triage loop every 30 minutes

[Timer]
OnBootSec=5min
OnUnitActiveSec=30min
Unit=agent-loop.service

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now agent-loop.timer
systemctl list-timers agent-loop.timer

systemctl list-timers doit afficher une colonne NEXT contenant une heure future et une colonne LEFT indiquant le compte à rebours. Un résultat vide signifie que le timer n’est pas activé, car enable sans --now le planifie uniquement pour le prochain démarrage. TimeoutStartSec=1800 est plus important qu’il n’y paraît : sans cette limite, un agent bloqué dans l’attente d’une saisie conserve l’unité active indéfiniment et le timer ne se déclenche plus. Consultez une exécution avec journalctl -u agent-loop.service -n 50.

Si vous lancez plutôt la boucle depuis cron, ajoutez votre propre protection contre les chevauchements, car cron peut démarrer sans problème une deuxième instance :

*/30 * * * * /usr/bin/flock -n /tmp/agent-loop.lock /srv/agent/bin/loop.sh

flock -n se termine immédiatement avec le statut 1 lorsque le verrou est déjà détenu. La deuxième exécution disparaît donc silencieusement au lieu d’entrer en concurrence avec la première. La même configuration d’un service et d’un timer systemd s’applique à toute tâche longue sur la machine, qu’il s’agisse d’un agent ou non.

Périmètre : donnez à chaque exécution sa propre copie

Un agent qui modifie votre working tree peut écraser votre travail non validé. Les worktrees Git résolvent ce problème à faible coût : chaque exécution reçoit son propre répertoire et sa propre branche, tout en partageant le même object store.

cd /srv/agent/repo
git worktree add -b loop/triage-01 /srv/agent/work/triage-01 origin/main
git worktree list

git worktree list affiche une ligne par tree, avec son chemin, son commit et sa branche. À la fin de l’exécution, git worktree remove /srv/agent/work/triage-01 supprime le répertoire et git worktree prune supprime les entrées dont le répertoire a disparu. Les boucles parallèles sont alors sûres, car deux agents sur deux branches et dans deux répertoires différents ne peuvent pas s’écraser mutuellement.

Le périmètre concerne aussi les credentials. Une boucle exécutée sans supervision conserve des tokens à longue durée de vie. Chaque exécution peut en divulguer un dans un log, un commit ou le contexte du modèle. Limitez le token au seul repository auquel la boucle accède. Lorsque c’est possible, ne le placez pas dans l’environnement visible par le propre shell de l’agent. Consultez comment empêcher les secrets d’atteindre les agents IA avant d’accorder à une boucle un accès à la production. Pour une séparation plus stricte, exécutez toute la boucle sur une VM jetable que vous pouvez détruire après chaque exécution.

Vérification : la barrière qui sécurise la boucle

C’est cette étape qui distingue une boucle d’un cron job qui saisit du texte. La sortie de l’agent est une proposition. La barrière prend la décision.

#!/usr/bin/env bash
set -euo pipefail

repo=/srv/agent/repo
branch="loop/$(date -u +%Y%m%dT%H%M%SZ)"
tree="/srv/agent/work/$(basename "$branch")"

cd "$repo"
git fetch --quiet origin
git worktree add -b "$branch" "$tree" origin/main
cd "$tree"

# the agent's own command runs here, in non-interactive mode

if ! npm test; then
  echo "gate failed: discarding $branch" >&2
  cd "$repo"
  git worktree remove --force "$tree"
  exit 1
fi

git push origin "$branch"
cd "$repo"
git worktree remove "$tree"

set -euo pipefail effectue un vrai travail dans ce script. Sans -e, l’échec de git fetch est ignoré et l’exécution continue avec un origin/main obsolète. Sans -u, une faute de frappe dans un nom de variable est remplacée par une chaîne vide. Le nettoyage s’exécute alors sur le mauvais chemin au lieu d’échouer explicitement.

Le bloc if ! npm test contient toute l’idée. Le code de sortie d’une vérification fiable, votre test suite ou votre type checker, détermine si la branche est poussée ou supprimée. Une boucle sans barrière produit du travail que personne n’a le temps de vérifier. C’est pire que de ne rien produire. Une boucle avec une barrière produit une branche qui a déjà passé le même niveau d’exigence que celui imposé à la branche d’un contributeur humain.

Choisissez une barrière qui échoue réellement. Une test suite qui réussit avec un diff vide apprend à la boucle que ne rien faire est une réussite. Les repositories avec des tests faibles produisent des boucles faibles. C’est pourquoi les repositories tendance placent « rendre la codebase compatible avec les agents » avant « écrire la boucle ».

Budget : ce qui arrête une exécution

Un agent qui réessaie indéfiniment génère une facture illimitée. Donnez à chaque boucle une limite de temps réelle, imposée par TimeoutStartSec ci-dessus ; un nombre maximal de tentatives dans votre script ; et un plafond de dépenses imposé par le compte du fournisseur. Consignez ensuite le coût de chaque exécution. Vous pourrez ainsi détecter une dérive de la boucle avant de la voir sur la facture. Contrôle des coûts pour un VPS d’agent toujours actif traite le suivi comptable, et gestion du contexte conservé par un agent entre les tours traite le principal levier du coût par exécution. En effet, une boucle qui relit le même dépôt toutes les 30 minutes le fait payer toutes les 30 minutes.

Le coût explique pourquoi les boucles sont généralement préférables à une longue session. Une exécution qui démarre avec un contexte vierge, effectue une tâche précise, puis se termine conserve un contexte réduit. Une session laissée ouverte pendant huit heures conserve chaque erreur précédente dans son historique et facture l’intégralité de la transcription à chaque tour.

Les modèles que les dépôts tendance formalisent

Le dépôt loop-engineering répertorie sept modèles de production. Il est préférable de les lire comme un menu plutôt que comme un manifeste. Triage quotidien. Un assistant de pull request qui surveille les commentaires de review et y répond. Un outil de surveillance de l’intégration continue qui traite les builds en échec. Un outil de surveillance des dépendances. Un outil de rédaction du changelog. Nettoyage post-merge. Triage des issues.

Ces modèles ont en commun une tâche précise avec une condition de validation évidente. « Corriger le build en échec » a une condition de réussite que la machine peut vérifier. « Améliorer la codebase » n’en a pas. Cette tâche ne devient donc jamais une boucle. Elle devient un ensemble désordonné d’actions planifiées.

Ils ont également en commun une trace écrite. Les deux dépôts sortent l’état de la conversation pour l’enregistrer dans des fichiers du dépôt : ce qui a été exécuté, ce qui a été trouvé et ce qui a été décidé. Ce fichier constitue la mémoire de la boucle. C’est ce qui permet à une deuxième boucle de s’appuyer sur le travail de la première au lieu de le redécouvrir. C’est également ainsi que vous pouvez auditer un agent après son exécution, car le contexte du modèle disparaît dès que l’exécution se termine.

Échecs des boucles

Les échecs sont prévisibles et se répètent d’une équipe à l’autre.

• Aucun contrôle. La sortie s’accumule, personne ne l’examine, la confiance disparaît et la boucle est désactivée.
• Chevauchement. Deux exécutions sur une même branche, ou deux agents dans un même working tree, produisent des conflits que l’agent tente ensuite de résoudre.
• Dérive silencieuse. La boucle continue de réussir parce que le contrôle est trop faible pour échouer.
• Périmètre non limité. Un trigger qui se déclenche à chaque commit dans un dépôt très actif devient un problème de coûts en une journée.

La solution est la même dans chaque cas : réduire la tâche, renforcer le contrôle et journaliser l’exécution. Si vous ne pouvez pas décrire la condition de réussite en une phrase, la tâche n’est pas prête à être automatisée.

Démarrer sans le vocabulaire

Vous n’avez pas besoin d’un framework. Un petit serveur Linux toujours actif, un dépôt git dont la suite de tests échoue quand elle le doit, un timer systemd et un script shell contenant un if forment une boucle complète. C’est réellement par là que la plupart des utilisateurs devraient commencer, car les questions de conception trouvent leur réponse en exécutant le système plutôt qu’en choisissant un outil. Une fois une boucle stable, l’exécution d’une deuxième boucle consiste principalement à ajouter un autre timer et un autre worktree. Consultez comment exécuter un agent d’IA de programmation sur un VPS pour la configuration de base, et les options actuelles d’agents d’IA auto-hébergés si vous voulez que l’agent lui-même s’exécute sur du matériel que vous contrôlez.

FAQ

L’ingénierie des boucles est-elle différente de l’ingénierie des prompts ?

L’ingénierie des prompts optimise un seul message : la formulation, les exemples et le format de sortie. L’ingénierie des boucles optimise le cycle autour du message : le déclencheur qui démarre une exécution, la sandbox dans laquelle elle s’exécute, le contrôle qui accepte ou rejette sa sortie et le budget qui y met fin. Vous avez toujours besoin d’un bon prompt dans la boucle. Le prompt n’est simplement plus l’élément que vous ajustez au quotidien, car le contrôle et le déclencheur ont davantage d’effet sur le résultat.

Ai-je besoin d’un framework pour créer une boucle d’agent ?

Non. Un timer systemd, un git worktree par exécution, un script shell qui se termine par une commande de test et un plafond de dépenses sur le compte du fournisseur couvrent tous les éléments de la définition. Les frameworks ajoutent des interfaces de planification, des formats de mémoire partagée et du routage entre agents. Ces fonctions sont utiles lorsque vous exécutez plusieurs boucles. Elles ne sont pas indispensables pour commencer.

Qu’est-ce qu’un harness de codebase ?

C’est l’ensemble des éléments qui permettent à un agent de travailler dans un dépôt sans intervention humaine : une configuration en une commande, des tests qui s’exécutent de manière non interactive et échouent explicitement, un linter, ainsi qu’un moyen de déployer ou de prévisualiser une modification. Le terme vient de la même vague de dépôts de 2026 que l’ingénierie des boucles. Le test pratique est simple : si un nouveau contributeur humain ne peut pas passer du clone à des tests au vert avec une seule commande, un agent ne le peut pas non plus.

Comment empêcher une boucle d’agent de générer une facture élevée ?

Limitez-la à trois endroits. Définissez TimeoutStartSec sur l’unité systemd afin qu’une exécution bloquée soit tuée. Limitez le nombre de retries dans le script au lieu de boucler jusqu’à la réussite. Définissez une limite de dépenses stricte sur le compte API, car c’est le seul plafond que l’agent ne peut pas contourner en argumentant. Enregistrez ensuite le coût de chaque exécution, car une boucle dont le coût double est généralement une boucle dont le périmètre s’est élargi discrètement.

Quels travaux valent la peine d’être transformés en boucle en premier ?

Choisissez un travail avec une condition de réussite lisible par une machine et un faible rayon d’impact. Corriger un build en échec, mettre à jour une dépendance et régénérer un changelog conviennent tous, car une suite de tests ou un diff peut prouver le résultat. Les travaux ouverts, comme le refactoring ou la conception, ne conviennent pas encore, puisqu’il n’y a rien que le contrôle puisse vérifier. Une boucle sans contrôle est un moyen coûteux de produire de la dette de revue.