Du prompt à la loopQuatre couches qui s'empilent, pas quatre modes

Depuis 2020, on n'optimise plus la même chose. D'abord les mots donnés au modèle. Puis ce qu'il pouvait voir. Puis l'environnement dans lequel il pouvait agir. Aujourd'hui, on commence à concevoir le cycle qui décide quand le relancer, avec quel objectif, quelle mémoire et quelle condition d'arrêt.

Le changement n'est pas que l'IA répond mieux. C'est que l'humain transporte de moins en moins d'informations d'un tour à l'autre.

Quatre couches, pas quatre remplacements

Le schéma ci-dessous garde la tâche constante : un bug de paiement à corriger. Ce qui change, c'est qui transporte l'information, qui agit, qui vérifie, et qui relance le cycle.

Harnais et loop : deux questions différentes

Là où la loop devient vraiment utile

Sur une correction isolée, la loop réduit surtout les relances : un gain réel, mais modeste.

Elle change de nature sur un système vivant - un site qui suit des scores, des prix, des tickets clients, des incidents. Le problème n'est plus de le construire une fois : c'est de détecter ce qui a changé, décider si une action s'impose, corriger, tester, documenter, puis recommencer le lendemain. Ce n'est plus « un prompt plus long » : c'est une petite organisation construite autour de l'agent.

Une loop tient en six pièces

• Déclencheur : à heure fixe, sur événement, sur ticket, sur échec de test.
• Objectif : ce que la boucle cherche à accomplir.
• Contexte : les sources qu'elle doit lire.
• Action : ce qu'elle peut modifier ou produire.
• Vérification : comment elle sait que c'est bon.
• Mémoire : ce qu'elle retient pour l'itération suivante.

Retirez-en une seule et la boucle tourne sans le savoir : sans déclencheur, elle ne part jamais ; sans mémoire, elle répète les mêmes erreurs.

Ce que la loop ne résout pas

Une loop mal conçue ne rend pas un agent plus intelligent : elle rend ses erreurs plus régulières.

Objectif flou, et elle tourne dans le vide. Vérification faible, et elle valide ses propres approximations. Mémoire mauvaise, et elle répète les mêmes erreurs. Coût non borné, et une tâche simple devient une consommation continue de tokens.

L'autonomie n'est donc pas la valeur par défaut d'une loop. Sa valeur, c'est d'être bornée : par un objectif, une vérification et une condition d'arrêt.

Ce que ça change

Ce n'est pas la fin du prompt engineering, c'est son déplacement dans une architecture plus large - une architecture où l'humain ne disparaît pas, mais cesse d'être le convoyeur manuel entre chaque étape.