Il y a trois ans, construire avec l'IA ressemblait surtout à une conversation. On écrivait un prompt soigneusement formulé, on l'envoyait au modèle, puis on jugeait la réponse. Si le résultat décevait, la réaction évidente consistait à reformuler l'instruction et à recommencer. Le Prompt Engineering est né naturellement de ce contexte : de meilleures instructions donnaient de meilleures réponses.
Ce cadre ne suffit plus. Les agents de code modernes ne se contentent pas de répondre à une demande. Ils inspectent une base de code, lisent la documentation, formulent un plan, modifient des fichiers, lancent des tests, rencontrent des échecs, révisent leur approche et continuent jusqu'à ce que le travail atteigne un état utilisable. Ce qui compte n'est plus seulement l'instruction initiale. C'est la boucle qui suit.
La première génération d'applications IA traitait les modèles de langage comme de puissants moteurs de recherche ou de génération : demander, recevoir, répéter. Les interfaces conversationnelles ont ajouté de la mémoire entre les échanges, mais l'utilisateur pilotait toujours chaque étape. Les agents autonomes ont changé l'unité de travail. Nous ne demandons plus seulement une fonction ou une explication ; nous demandons un résultat.
Ce résultat est produit par l'itération. Un système IA utile planifie, exécute, valide, apprend et recommence. La fiabilité vient de la capacité du système à réduire l'incertitude au fil du temps, pas du fait de recevoir un prompt parfait au départ.
Les prompts comptent toujours, mais ils ne définissent plus tout le système. Une exécution autonome peut mobiliser des prompts de planification, de sélection d'outils, de validation, de récupération, de synthèse et de gestion du contexte. La qualité du produit dépend de la manière dont ces pièces interagissent.
La question d'ingénierie change donc de nature. Au lieu de demander seulement comment formuler la requête, nous demandons comment le système choisit sa prochaine action, quand il réessaie, comment il détecte l'échec, ce qu'il mémorise, ce qu'il oublie, et comment il sait que la tâche est terminée.
Le Loop Engineering est la discipline qui consiste à concevoir des systèmes d'exécution autonomes capables de planifier, exécuter, valider, apprendre et itérer en continu jusqu'à atteindre un objectif. Il ne dépend pas d'un modèle, d'un framework, ni même du vocabulaire actuel autour des agents. Ce sont des composants. La boucle est l'architecture.
Cela requalifie le développement IA comme un sujet de design système. Les stratégies de validation, les politiques de retry, les limites de mémoire, les boucles de feedback et les conditions de sortie deviennent des préoccupations de premier rang. L'écriture de prompts reste utile, comme comprendre SQL ou les réseaux reste utile, mais le niveau d'abstraction monte.
Si le Prompt Engineering nous a appris à communiquer avec l'IA, le Loop Engineering consiste à apprendre à l'IA à travailler. Les meilleurs produits IA ne seront pas nécessairement ceux qui possèdent les prompts les plus astucieux. Ce seront ceux qui disposent des systèmes d'exécution les plus fiables : des systèmes capables de récupérer après un échec, de valider leur progression, de gérer le contexte dans le temps et de savoir quand le travail est réellement terminé.
La frontière se déplace de ce que le modèle doit dire vers la manière dont le système doit continuer à avancer. C'est le début du Loop Engineering.
Lire l'article original sur LinkedIn →
Le codage agentique transforme l'unité de production logicielle : le développeur conçoit, supervise et améliore de plus en plus une usine de systèmes connectés pour construire, auditer, déployer et exploiter.
Les agents de code rendent le logiciel extensible plus précieux : davantage d'utilisateurs peuvent transformer de petits irritants de workflow en outils fonctionnels.
Le codage agentique transforme le métier de développeur : moins d'implémentation ininterrompue, davantage de délégation, de revue et de passage maîtrisé entre plusieurs flux de travail.