Loop engineering : au-delà du prompt

Il y a quelque chose d'ironique dans la fortune du mot « prompt engineering » : au moment où il entrait dans le vocabulaire des directions, les praticiens en sortaient déjà. Dans nos hackathons, un POD produit un démonstrateur fonctionnel en moins de trois heures de delivery, évalué contre une baseline sans IA — et ce n'est jamais le prompt qui fait cette performance. C'est tout ce qui a été construit autour : l'environnement préparé, les workflows, les outils, les vérifications, et la discipline de la boucle. Andrej Karpathy a donné son nom à une partie de cette réalité — le « context engineering », « l'art délicat de remplir la fenêtre de contexte avec exactement la bonne information pour l'étape suivante »^[1]. J'élargis le propos : ce qui fait un système agentique fiable, c'est l'ingénierie de la boucle entière. J'appelle cela le loop engineering.

Pourquoi la boucle, et pas le modèle

La raison tient en deux courbes qui ne se suivent pas. La première est spectaculaire : selon METR, la durée des tâches que les agents savent mener à bien double environ tous les sept mois — et le rythme s'accélère depuis 2024. Les meilleurs modèles de 2026 tiennent des tâches de plusieurs heures là où ceux de 2023 s'essoufflaient en minutes^[2]. La seconde courbe, elle, est presque plate : sur douze métriques de fiabilité appliquées à quinze modèles, l'équipe d'Arvind Narayanan à Princeton mesure que deux ans de gains de capacités n'ont produit que de faibles gains de fiabilité^[3] ; et le benchmark τ-bench montre des agents qui réussissent une tâche mais s'effondrent quand on exige huit réussites consécutives^[4]. Capacité qui explose, fiabilité qui stagne : l'écart entre les deux, c'est exactement l'espace de travail du loop engineering. Le terrain le confirme — 90 % des développeurs utilisent désormais l'IA, mais 30 % ne font pas confiance au code qu'elle génère, et l'adoption améliore le débit de livraison tout en dégradant sa stabilité quand rien ne l'encadre^[5].

Anatomie d'une boucle : quatre organes

Le harness — ce que l'agent peut faire

Le premier organe est le harnais : les outils que l'agent peut appeler, les règles qui l'encadrent, les garde-fous qui l'arrêtent. Trois enseignements des équipes qui en construisent à l'échelle. D'abord la frugalité : « plus d'outils ne produit pas de meilleurs résultats » — mieux vaut peu d'outils à fort impact, aux descriptions travaillées, car « de petits raffinements dans la description d'un outil produisent des améliorations spectaculaires »^[6]. Ensuite la simplicité architecturale : les implémentations qui réussissent reposent sur « des patterns simples et composables » — enchaînement, routage, parallélisation, orchestrateur-exécutants, évaluateur-optimiseur — plutôt que sur des frameworks opaques^[7]. Enfin la défense en couches : un garde-fou isolé protège rarement ; c'est leur combinaison — filtres de pertinence et de sécurité, protections d'outils graduées selon la réversibilité de l'action, validation des sorties — qui rend un agent résilient, avec deux déclencheurs d'escalade humaine non négociables : le dépassement d'un seuil d'échecs, et toute action à haut risque ou irréversible^[8].

Le contexte — ce que l'agent sait maintenant

Le deuxième organe est la fenêtre de contexte, et la discipline qui va avec : traiter le contexte « comme une ressource finie au rendement marginal décroissant »^[9]. C'est une contrainte économique autant que cognitive : dans les boucles agentiques, le coût est dominé par les tokens d'entrée, parce que l'agent relit son contexte à chaque itération — la « boule de neige » documentée par le Stanford Digital Economy Lab, qui mesure des consommations jusqu'à mille fois supérieures à un simple chat sur les tâches de code^[10]. Le loop engineer décide donc en permanence ce qui entre dans la fenêtre, ce qui se résume, ce qui se relit à la demande — et ce qui n'y entrera jamais.

La mémoire — ce que le système apprend

Le troisième organe déborde la session : c'est ce que le système retient d'une exécution à l'autre. Règles de projet auto-appliquées, conventions apprises, registres de décisions, leçons converties en garde-fous — chaque enseignement rencontré en production doit finir codé quelque part, plutôt que dans la mémoire d'une personne ou d'un agent. C'est l'organe le plus négligé et le plus rentable : c'est lui qui fait qu'une boucle s'améliore avec l'usage au lieu de répéter ses erreurs, et c'est lui qui transforme le savoir-faire individuel en actif d'organisation.

L'évaluation — ce qui dit si c'est bon

Le quatrième organe juge les trois autres. Sans évaluation, une boucle produit du plausible avec une assurance parfaite ; les produits d'IA qui échouent partagent presque tous cette cause racine^[11]. La bonne nouvelle est que le ticket d'entrée est bas : « vingt à cinquante tâches simples tirées de vraies défaillances constituent un excellent départ », avec trois familles de correcteurs — programmatiques, rapides mais rigides ; par modèle, flexibles mais à calibrer ; humains, référence mais coûteux^[12]. Et parce que les critères d'évaluation émergent de l'usage plutôt qu'ils ne préexistent^[13], la suite d'évaluation est un actif que chaque organisation forge elle-même — celui qui, accessoirement, rend les changements de modèle indolores.

Les patterns qui font tenir la boucle

Quatre patterns reviennent dans tous mes systèmes qui ont tenu en production. La seconde passe adversariale : après chaque production en volume, une relecture contradictoire recoupe les affirmations fortes contre leurs sources — c'est elle qui intercepte les sur-affirmations avant le client, et elle se planifie comme une étape du workflow, pas comme un remords. Le routage par charge cognitive : le modèle économique pour les tâches mécaniques, l'intermédiaire pour la lecture et la rédaction, le plus capable réservé aux jugements à fort enjeu — d'autant plus rationnel que le volume de tokens explique à lui seul 80 % de la variance de performance d'un système agentique : on place ses tokens là où ils produisent^[14]. La profondeur de boucle bornée : les horizons de METR donnent la règle de dimensionnement — au-delà de la durée de tâche que le modèle tient à 50 %, on ne prie pas, on découpe, on pose une porte de vérification, ou on escalade vers un humain^[2]. Le fan-out gouverné, enfin : la parallélisation massive pour les lots homogènes à faible enjeu unitaire, le séquentiel ordonné pour les lots critiques ou interdépendants — jamais l'inverse.

Les anti-patterns qui la font dérailler

Les échecs aussi ont leurs classiques. La boucle infinie confiante : un agent sans borne de profondeur ni seuil d'échec, qui insiste avec assurance dans une impasse — variante moderne du « retry storm ». Le contexte boule de neige, qui dégrade simultanément le coût et la qualité à mesure que la fenêtre enfle. Le multi-agents prématuré : la complexité d'orchestration ajoutée avant d'avoir épuisé ce qu'un agent unique bien harnaché sait faire — les deux laboratoires de référence donnent ici le même conseil, commencer simple^[7][8]. Et l'évaluation remise à plus tard, qui condamne à piloter aux impressions — or nous savons, mesures à l'appui, que les impressions mentent : des développeurs chevronnés se croient accélérés de 20 % quand ils sont ralentis de 19 %^[15].

De la boucle au système de production

Une boucle bien conçue reste un composant ; en production, elle s'insère dans un cadre. Le modèle de capacités du rapport DORA le dit à sa façon — « renforcez vos filets de sécurité » figure parmi les sept capacités qui font que l'IA amplifie le meilleur plutôt que le pire^[5] ; et pour les organisations qui doivent formaliser, le profil GenAI du cadre de gestion des risques du NIST fournit la grammaire complète — douze catégories de risques et deux cents actions réparties entre gouverner, cartographier, mesurer et gérer^[16]. Mon conseil est plus simple : que chaque système agentique ait, écrit quelque part, son contrat de boucle — profondeur maximale, budget de tokens, portes de vérification, conditions d'escalade, suite d'évaluation. Un système dont on ne sait pas écrire ce contrat n'est pas prêt pour la production.

On me demande parfois si le loop engineering survivra aux prochains modèles — après tout, des modèles plus fiables auront besoin de moins de garde-fous. C'est probable, et tant mieux : la boucle s'allégera. Mais elle ne disparaîtra pas, car elle encode ce que le modèle ne saura jamais de lui-même : ce que votre organisation appelle un travail bien fait, ce qu'elle interdit, ce qu'elle tolère, ce qu'elle a appris de ses échecs. Le prompt se copie en dix secondes. La boucle, elle, se construit — et c'est précisément pour cela qu'elle vaut quelque chose.