L'ingénierie de boucle connaît un véritable essor. Parcourez n'importe quel forum technique et vous trouverez des voix affirmant que nous devrions cesser de traiter les agents IA comme des chatbots à coacher avec des prompts astucieux. Au lieu de cela, ils disent que nous devrions concevoir des boucles : des cycles autonomes qui permettent à un agent de planifier, d'exécuter, de vérifier son propre travail et d'itérer pendant que nous dormons. L'argument est séduisant. Si la boucle est bien construite, l'agent reste sur la bonne voie sans supervision humaine constante, transformant une intention brute en un résultat final pendant la nuit.

Cette promesse fonctionne magnifiquement en théorie. En pratique, la plupart des agents fonctionnent déjà en boucle. Ils génèrent du code, inspectent les erreurs de compilation ou les échecs de tests, corrigent le code et relancent la suite de tests. Ce cycle de rétroaction de base n'est pas nouveau. Ce que les partisans réclament aujourd'hui est quelque chose de plus ambitieux : une boucle externe qui régit l'ensemble de la tâche, et pas seulement les erreurs de syntaxe. C'est la construction de cette boucle externe qui devient difficile, car le génie logiciel est rarement un système fermé aux règles fixes.

Le problème de la conception de boucle

Les objectifs de produit sont complexes. On commence rarement avec une définition parfaite du « terminé ». Plus souvent, on découvre le véritable objectif alors que l'on est déjà plongé dans la construction. Une exigence qui semblait simple sur un tableau blanc s'avère comporter des cas limites qui modifient entièrement la forme de la solution. Lorsque vous enfermez un agent dans une boucle rigide, cette rigidité devient un handicap. La boucle continue de frapper une cible qui n'est peut-être pas la bonne. Pire encore, une boucle flexible résout parfois l'impasse en modifiant discrètement l'objectif pour qu'il corresponde au résultat qu'elle a réussi à produire. L'un gaspille de la puissance de calcul ; l'autre livre des déchets avec assurance.

Le problème de fond est le coût de la spécification. Si vous voulez qu'une boucle fonctionne sans supervision, vous devez rédiger une spécification qui anticipe presque tout. Que l'agent doit-il changer exactement ? Quel comportement existant est sacré et doit être préservé ? Dans quelles conditions précises l'agent doit-il cesser d'itérer ? Quels risques sont acceptables, et quels effets secondaires devraient déclencher un arrêt immédiat ? La rédaction de ce document peut prendre plus de temps que de simplement s'asseoir avec l'agent et le guider à travers la tâche en temps réel. Vous payez une lourde taxe initiale en échange d'une automatisation qui n'est rentable

Il manque une distinction cruciale à une grande partie de la conversation actuelle. Les boucles sont des régulateurs. Elles maintiennent un système aligné sur un objectif prédéterminé, tout comme un thermostat maintient une pièce à soixante-douze degrés. Mais le thermostat ne choisit pas les soixante-douze degrés. Quelqu'un a dû décider au préalable que c'était la bonne température.

Appliqué au logiciel, cela signifie qu'un agent au sein d'une boucle peut corriger des bugs, refactoriser des fonctions ou ajuster des paramètres toute la journée. Il ne peut cependant pas décider quelle fonctionnalité aide réellement le client ou si un bug mérite d'être corrigé avant la prochaine version. Ces choix nécessitent un jugement sur le contexte métier, les points de friction des utilisateurs et les priorités stratégiques. Les agents exécutent. Les humains décident. C'est ainsi que les équipes finissent par obtenir des systèmes magnifiquement optimisés qui résolvent le mauvais problème.

L'ingénierie des boucles est utile, mais elle est limitée. Elle vous aide à faire fonctionner la machine avec discipline et rapidité. Elle ne décide pas de quelle machine construire, pour qui, ni de ce qu'est le succès en termes humains. Le jugement sur l'importance d'une fonctionnalité, l'acceptabilité d'un risque et le moment où l'objectif lui-même doit changer vous appartient. Construisez des boucles pour le travail que vous comprenez déjà assez bien pour le vérifier automatiquement. Gardez la maîtrise de tout le reste.

Cet article s'appuie sur des idées initialement discutées par Isaac Hagoel dans « Loop Engineering Minus The Hype. » Pour plus de discussions techniques, rejoignez notre communauté d'apprentissage sur Telegram.