Qu’est-ce que la conception de boucles IA ?

Ce que signifie la conception de boucles

La conception de boucles consiste à définir le cycle répétitif d’un agent 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. La conception de prompts façonne un message destiné à un modèle. La conception de boucles façonne le processus qui envoie des milliers de messages pendant votre sommeil. L’unité de travail n’est plus le prompt, mais 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, vérifie son propre résultat avec un test et s’arrête lorsque le budget est épuisé.

Pourquoi ce terme est apparu en 2026

Le nom est en train de s’imposer publiquement. Le dépôt GitHub cobusgreyling/loop-engineering a dépassé 9,600 stars dans les deux mois qui ont suivi sa première apparition (en juillet 2026), avec la formule « Stop prompting. Design the loop. Get a score. ». Il regroupe cette évolution en six éléments : la planification, les worktrees, les skills, les plugins et les connecteurs, les sous-agents, ainsi qu’une mémoire persistante conservée en dehors de la conversation.

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

Je ne donne plus de prompts à Claude. J’exécute des boucles qui donnent des prompts à Claude.

Un second dépôt, AI-Builder-Club/skills, approche les 1,100 stars (en juillet 2026) et nomme directement les deux rôles : un « codebase harness », qui rend un dépôt suffisamment sûr pour qu’un agent y exécute des tests et des déploiements, et un « loop engineer », qui construit 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 qui a déjà exécuté un build nocturne, un linter dans une intégration continue ou une tâche cron ouvrant un ticket en connaît déjà le principe. La nouveauté tient au fait que le worker à l’intérieur de la boucle est désormais non déterministe. Cela modifie les responsabilités des composants qui l’entourent.

Les quatre éléments d’une boucle

Toute boucle fonctionnelle comporte ces quatre éléments. Une boucle qui en omet un est celle qui vous réveille à 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 le résultat de l’exécution est conservé ou rejeté.
• Budget. La limite de tokens, de temps et d’argent qui met fin à l’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 vous apprêtez à 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 timer systemd est préférable à cron, car il journalise les exécutions, réessaie selon vos paramètres et ne démarre pas une seconde instance d’une unité qui est encore en cours d’exécution. 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 programme pour le prochain démarrage uniquement. TimeoutStartSec=1800 est plus important qu’il n’y paraît : sans cette limite, un agent bloqué en attente d’une entrée 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 pilotez plutôt la boucle avec cron, ajoutez votre propre mécanisme pour empêcher les chevauchements, car cron démarre sans problème une seconde 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 seconde exécution disparaît donc silencieusement au lieu d’entrer en concurrence avec la première. La même configuration du service et du timer systemd s’applique à toutes les tâches qui s’exécutent longtemps sur la machine, qu’il s’agisse ou non d’un agent.

Limite : donnez à chaque exécution sa propre copie

Un agent qui modifie votre arborescence de travail peut écraser votre travail non validé. Les worktrees Git résolvent ce problème à moindre coût : chaque exécution dispose de son propre répertoire et de sa propre branche, tout en partageant un 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 arborescence 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 n’existe plus. Les boucles parallèles deviennent alors sûres, car deux agents travaillant sur deux branches dans deux répertoires ne peuvent pas écraser le travail de l’autre.

La limite concerne aussi les identifiants. Une boucle exécutée sans surveillance détient des tokens persistants, et chaque exécution peut en divulguer un dans un journal, un commit ou le contexte du modèle. Limitez le token au seul dépôt utilisé par la boucle. Lorsque c’est possible, empêchez-le d’apparaître dans l’environnement visible par le shell de l’agent lui-même. Consultez comment empêcher les agents IA d’exposer les secrets avant d’accorder à une boucle un accès à la production. Pour une isolation plus stricte, exécutez toute la boucle sur une VM éphémère que vous pouvez détruire après chaque exécution. L’outil utilisé définit également une partie de cette limite avant même que vous écriviez quoi que ce soit. Il est donc utile de consulter comment le sandbox géré de Cowork se compare à Claude Code sur votre propre machine avant de décider du niveau d’isolation à mettre en place vous-même.

Vérification : le contrôle qui sécurise la boucle

C’est ce qui distingue une boucle d’une tâche cron qui saisit des commandes. La sortie de l’agent est une proposition. Le contrôle décide.

#!/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 joue un rôle réel 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 le nom d’une variable est remplacée par une chaîne vide, puis le nettoyage s’exécute sur le mauvais chemin au lieu d’échouer explicitement.

Le bloc if ! npm test contient toute l’idée. Le code de sortie d’un contrôle auquel vous faites déjà confiance, votre suite de tests ou votre vérificateur de types, détermine si la branche est pushée ou supprimée. Une boucle sans contrôle produit du travail que personne n’a le temps de relire, ce qui est pire que de ne rien faire. Une boucle avec un contrôle produit une branche qui a déjà satisfait les mêmes exigences que celle d’un contributeur humain. Un contrôle au vert ne dit rien de la quantité de code que l’agent a modifiée pour y parvenir. Il est donc utile d’associer ce contrôle à une instruction permanente comme la règle qui impose à l’agent de choisir la plus petite modification fonctionnelle, afin de conserver un diff suffisamment réduit pour que sa relecture reste rapide.

Choisissez un contrôle qui échoue de manière fiable. Une suite de tests qui réussit avec un diff vide apprend à la boucle que ne rien faire est une réussite. Les dépôts dont les tests sont faibles produisent des boucles faibles. C’est pourquoi les dépôts populaires placent « rendre la base de code prête pour les agents » avant « écrire la boucle ». Si vous voulez savoir si votre suite détecterait réellement une régression au lieu de simplement exécuter les lignes concernées, les tests par mutation fournissent la réponse. Et un agent qui renvoie un rapport de preuves réexécutable au lieu de vous demander de lire son diff transforme cette réponse en un résultat que vous pouvez vérifier vous-même.

Budget : ce qui arrête une exécution

Un agent qui réessaie indéfiniment génère une facture sans limite. Donnez à chaque boucle une durée maximale, imposée par TimeoutStartSec ci-dessus ; ajoutez un compteur de tentatives dans votre script ; et définissez un plafond de dépenses au niveau du compte fournisseur. Journalisez ensuite le coût de chaque exécution afin de détecter une dérive de la boucle avant de la voir apparaître sur la facture. Contrôler les coûts d’un VPS avec un agent actif en permanence traite l’aspect comptable, tandis que gérer le contexte qu’un agent conserve entre deux tours couvre le principal levier du coût par exécution : une boucle qui relit le même dépôt toutes les 30 minutes le paie 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 dans 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 dans son historique toutes les erreurs précédentes 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 pour la production. Il vaut mieux les lire comme un menu que comme un manifeste. Le triage quotidien. Un assistant de pull request qui surveille les commentaires de revue et y répond. Un outil de surveillance de l’intégration continue qui récupère les builds en échec. Un outil de suivi des dépendances. Un outil de préparation du changelog. Le nettoyage post-merge. Le triage des issues.

Ces modèles ont en commun une tâche ciblée et une condition de validation évidente. « Corriger le build en échec » possède une condition de réussite que la machine peut lire. « Améliorer la base de code » n’en possède pas. Cette tâche ne devient donc jamais une boucle. Elle devient un désordre planifié.

Ils ont aussi en commun une trace écrite. Les deux dépôts sortent l’état de la conversation pour le placer 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 aussi ainsi que vous pouvez auditer un agent après coup, car le contexte du modèle disparaît dès que l’exécution se termine. La coordination en direct passe par un canal distinct, et une session Claude Code peut transmettre du travail à une autre sur le même serveur tant que les deux sont encore actives. Toutefois, rien dans cet échange ne subsiste après la fin de l’une ou l’autre session. Le fichier reste donc l’élément que vous pourrez relire plus tard.

Quand les boucles échouent

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

• Aucune barrière. La sortie s’accumule, personne ne la vérifie, la confiance disparaît et la boucle est désactivée.
• Chevauchement. Deux exécutions sur une même branche, ou deux agents dans le 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 illimité. 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 correction est toujours la même : réduire la tâche, rendre le contrôle plus précis 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ébuter sans le vocabulaire

Vous n’avez pas besoin d’un framework. Un petit serveur Linux toujours allumé, un dépôt git dont la suite de tests échoue quand elle le devrait, 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 choix d’architecture se tranchent en exécutant le système plutôt qu’en choisissant un outil. Une fois une boucle stable, en exécuter une deuxième 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 s’exécute lui-même 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 message : formulation, exemples et format de sortie. L’ingénierie des boucles optimise le cycle autour du message : le déclencheur qui lance une exécution, le sandbox dans lequel 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 cesse d’être 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 cette définition. Les frameworks ajoutent des interfaces de planification, des formats de mémoire partagée et du routage entre agents, qui deviennent utiles lorsque vous exécutez plusieurs boucles. Ils ne sont pas nécessaires pour commencer avec une première boucle.

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 exécutables sans interaction et qui é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 apparue en 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 ?

Plafonnez-la à trois endroits. Définissez TimeoutStartSec sur l’unité systemd afin qu’une exécution bloquée soit arrêté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 par la discussion. Journalisez 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 progressivement sans que cela soit explicite.

Quels jobs faut-il transformer en boucle en premier ?

Choisissez un job 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 tâches ouvertes, comme le refactoring ou la conception, ne conviennent pas encore, car le contrôle n’a rien à vérifier. Une boucle sans contrôle est une manière coûteuse de produire une dette de revue.