Loop Engineering : Des Agents IA qui Tournent Seuls

La fin du prompt engineering

En 2023, GitHub comptabilisait environ 300 millions de commits assistés par IA. Début 2026, ce chiffre avait grimpé à 1,4 milliard — soit près de cinq fois plus en trois ans. Lors du keynote GTC Taipei de NVIDIA, Jensen Huang a cité cette statistique comme preuve d'un changement plus profond : les développeurs n'écrivent plus de prompts. Ils écrivent des boucles.

C'est ce que l'on appelle le loop engineering — la pratique de concevoir des systèmes qui sollicitent des agents IA de manière autonome, plutôt que de taper des instructions soi-même. Là où le prompt engineering optimisait les interactions individuelles, le loop engineering conçoit l'échafaudage autour de l'agent pour qu'il puisse raisonner, agir, se corriger et se terminer sans intervention humaine.

Pendant la majeure partie de 2024 et 2025, obtenir de la valeur d'un agent de codage signifiait écrire un prompt, lire la réponse, écrire le prompt suivant. Le loop engineering inverse cette dynamique : vous cessez d'être la personne qui sollicite l'agent et devenez la personne qui conçoit le système qui le sollicite.

Les quatre types de boucles

Tous les agents autonomes ne nécessitent pas la même forme de boucle. Il existe quatre patterns principaux en production aujourd'hui :

Les boucles heartbeat tournent en continu à intervalles courts — de quelques secondes à quelques minutes — pour des tâches de surveillance permanente : surveiller des logs, alerter sur des anomalies, maintenir une connexion active. Elles sont peu coûteuses, sans état, et ne dorment jamais.

Les boucles cron se déclenchent selon un planning. Revues de code quotidiennes, audits de dépendances hebdomadaires, rapports SEO mensuels. Le déclencheur est le temps, la portée est délimitée, et la sortie est un livrable à chaque tick.

Les boucles hook sont pilotées par les événements. Un PR est poussé, une étape CI échoue, un fichier change, un webhook API se déclenche. La boucle se réveille, fait son travail, et se rendort. Les boucles hook sont les plus réactives et les plus composables avec les pipelines CI/CD existants.

Les boucles de but sont les plus puissantes et les plus dangereuses. Elles itèrent jusqu'à ce qu'une condition de succès soit atteinte, puis se terminent. Vous donnez à l'agent un objectif — "livrer cette fonctionnalité avec des tests qui passent" — et la boucle raisonne, planifie, agit, observe et réessaie jusqu'à ce que l'objectif soit vérifié. La durée peut s'étendre de quelques minutes à plusieurs heures.

Le cycle de l'agent en cinq étapes

À l'intérieur de chaque boucle, l'agent exécute le même cycle interne en cinq étapes :

1. Percevoir — recevoir l'objectif actuel, les résultats des outils et les erreurs de l'itération précédente
2. Raisonner — analyser ce qui est nécessaire et les options disponibles
3. Planifier — sélectionner la prochaine action ou ensemble d'actions parallèles
4. Agir — exécuter des outils, écrire du code, interroger des bases de données ou appeler des APIs
5. Observer — recevoir les résultats, mettre à jour l'état interne et évaluer les progrès

Ce cycle se répète jusqu'à ce qu'une condition d'arrêt soit atteinte : objectif vérifié, plafond d'itérations atteint, budget dépassé, ou déclenchement d'un disjoncteur.

Les cinq composants essentiels

Construire une boucle fiable nécessite cinq éléments structurels qui fonctionnent ensemble :

1. Worktrees

Des environnements git isolés où l'agent peut effectuer des changements sans toucher la branche principale. Si l'agent casse quelque chose, git worktree remove écarte les dégâts. Sans worktrees, une boucle de but qui tourne pendant une heure de tentatives échouées laisse le dépôt dans un état inconnu.

2. Skills

Des fichiers d'instructions réutilisables et versionnés (généralement SKILL.md) qui définissent comment l'agent doit traiter un type de tâche spécifique. Les skills remplacent la répétition de prompts : plutôt que de réexpliquer "comment écrire un article de blog" dans chaque message déclencheur, vous pointez l'agent vers le fichier skill. Les skills créent aussi une mémoire d'équipe — les améliorations du comportement d'un agent se propagent à tous les agents utilisant le même skill.

3. Connecteurs MCP

Les intégrations Model Context Protocol donnent à l'agent accès aux outils externes : bases de données, systèmes de fichiers, APIs, moteurs de recherche, systèmes CI. Les connecteurs MCP sont les mains de l'agent — sans eux, la boucle peut seulement raisonner ; elle ne peut pas agir sur le monde extérieur.

4. Sous-agents

Des sous-boucles spécialisées avec leurs propres fenêtres de contexte isolées. Un agent parent délègue des sous-tâches aux sous-agents pour éviter le débordement de contexte dans les sessions longues. Chaque sous-agent peut utiliser un tier de modèle différent — des modèles économiques pour la classification, des modèles frontier pour la révision finale — permettant une optimisation significative des coûts.

5. Suivi d'état

Des points de contrôle basés sur des fichiers ou des bases de données qui enregistrent ce qui a été accompli. Sans suivi d'état, une boucle qui plante à mi-parcours repart de zéro, gaspillant des tokens et répétant potentiellement des effets secondaires irréversibles. Le suivi d'état permet la reprise en toute sécurité.

Réalité des coûts et routage de modèles

Une boucle d'agent unique consomme environ quatre fois plus de tokens qu'une interaction de chat standard. Les systèmes multi-agents en consomment quinze fois plus. À l'échelle, c'est la principale contrainte d'ingénierie.

La solution est le routage de modèles : diriger chaque tier de tâche vers la taille de modèle appropriée.

Combiné avec le cache de prompts, les équipes appliquant le routage de modèles rapportent une réduction de 60 à 80 pourcent du coût total d'inférence par rapport au routage de chaque étape via un modèle frontier.

Une boucle de but minimale en TypeScript

Voici un squelette de boucle de but avec suivi d'état et plafond d'itérations strict :

import { runAgent } from "./agent";
import { readState, writeState } from "./state";
import { verifyGoal } from "./verifier";
 
const MAX_ITERATIONS = 10;
 
async function goalLoop(goal: string): Promise<void> {
  const state = readState() ?? { iteration: 0, history: [] };
 
  while (state.iteration < MAX_ITERATIONS) {
    const result = await runAgent(goal, state.history);
    state.history.push(result);
    state.iteration++;
    writeState(state);
 
    if (await verifyGoal(goal, result)) {
      console.log(`Objectif atteint en ${state.iteration} itérations.`);
      return;
    }
  }
 
  console.error("La boucle a atteint le plafond sans vérification du succès.");
}

Décisions de conception clés : l'état est écrit après chaque itération (résistant aux pannes), le vérificateur est une fonction séparée (peut être mise à niveau indépendamment), et le plafond est explicite (pas de dépense incontrôlée).

Garde-fous de production

Le loop engineering sans garde-fous est coûteux au mieux et destructeur au pire. Contrôles non optionnels pour toute boucle de production :

• Plafond strict d'itérations — la boucle doit s'arrêter même si l'objectif n'est pas atteint
• Budget de tokens et de coûts — rejeter l'exécution si la dépense projetée dépasse un seuil
• Détection d'absence de progrès — si les N dernières itérations produisent des résultats identiques, terminer
• Disjoncteurs sur les tentatives d'outils — backoff exponentiel avec limite maximale de tentatives par appel d'outil
• Points de contrôle humains — pour les actions irréversibles (déploiements, e-mails, écritures en base), mettre en pause et demander une confirmation humaine avant de procéder

Par où commencer

Pour les nouvelles équipes, commencez par ReAct — il gère 80 pourcent des cas d'utilisation en production et est le plus facile à déboguer. Ajoutez la correction automatique de style Reflexion quand la précision prime sur la vitesse. Passez aux boucles de but complètes pour les tâches d'ingénierie ouvertes où vous pouvez définir une condition de sortie vérifiable.

Le changement de mentalité le plus important n'est pas technique : c'est reconnaître que le prompt est désormais un artefact dans un pipeline, pas un message dans un chat. Concevez le pipeline. L'agent gérera les prompts.

Conclusion

Le loop engineering marque un véritable changement architectural dans la façon dont les développeurs intègrent l'IA. Là où le prompt engineering demandait "comment écrire une meilleure instruction ?", le loop engineering demande "comment concevoir un système qui tourne et se corrige sans moi ?" Les équipes qui répondent à cette deuxième question sont celles qui voient leur nombre de commits se multiplier — et leur productivité par ingénieur s'élargir.