Conversation avec Enrico Papalini sur le 'Non-Deterministic Loop Engineering'
Quand nous avions parlé avec Enrico Papalini il y a un an de son premier livre, le thème central était un pacte silencieux rompu : celui entre les développeurs et les machines déterministes, brisé au moment où le code a cessé de faire toujours et en tout cas ce qui lui était écrit. Papalini, Head of Software Development pour Issuances, Custody, Data & UX/UI Solutions chez Euronext Securities, avec un passé au London Stock Exchange Group et à la Borsa Italiana, avait raconté cette transition avec la voix de celui qui gère des systèmes où l'erreur n'est pas une option contractuelle, mais un incident.
Depuis, la conversation a évolué. Il ne suffit plus de se demander ce qui se passe lorsqu'un modèle génère une réponse erronée, car la vraie question concerne ce qui se passe lorsque ce modèle continue de travailler seul, pendant des heures, en prenant des décisions, en utilisant des outils, en modifiant des fichiers, sans que personne ne surveille chaque étape. C'est de là que naît son nouveau livre, Non-Deterministic Loop Engineering, dédié non plus à la production d'un résultat unique mais au cycle qui le produit, le vérifie et décide de le relancer ou non.
Nous avons repris le fil avec lui, cette fois en nous concentrant sur un seul objet : le loop, son architecture, ses risques et les questions qu'il laisse ouvertes.
Du pacte au loop
Les deux questions d'ouverture servent à comprendre pourquoi Papalini a décidé d'isoler le loop en tant que discipline à part entière, et s'il s'agit vraiment de quelque chose de nouveau ou d'un simple rebranding d'idées déjà connues dans le logiciel.
Je lui demande ce qui l'a amené, après avoir raconté le passage du déterminisme au non-déterminisme, à consacrer un livre entier précisément au loop, et comment il l'expliquerait en une seule phrase à quelqu'un qui ne maîtrise pas le sujet.
"Le Prompt Engineering enseigne comment parler à un modèle. Le Loop Engineering conçoit ce qui se passe quand le modèle continue à travailler même après que nous avons cessé de lui parler", répond Papalini. "C'est cette étape qui m'a poussé à écrire le livre. Tant que nous utilisons l'IA comme assistante, le cycle est simple : nous posons une question, nous recevons une réponse et nous l'évaluons. L'être humain conserve le contrôle à chaque étape. Mais lorsque nous introduisons un agent, nous lui confions un objectif plus large. Le système lit l'état du travail, choisit une action, utilise des outils, modifie des fichiers ou des données, vérifie le résultat et décide de continuer ou non. À ce stade, le modèle n'est plus le système. Il n'est qu'un composant du système. Le véritable objet d'ingénierie devient le loop qui l'entoure : où nous conservons l'objectif, comment nous représentons l'état, quels outils il peut utiliser, qui vérifie le résultat, combien de fois il peut réessayer, combien il peut dépenser et quand il doit restituer le contrôle à une personne. J'ai isolé le loop parce que beaucoup d'entreprises passent des copilotes aux agents en traitant ce changement comme une simple augmentation de puissance du modèle. Ce n'est pas le cas. C'est un changement dans l'architecture du contrôle."
La deuxième question est la plus délicate, et je la lui pose sans détour : dans le livre, vous distinguez quatre niveaux (prompt, context, harness et loop engineering), et pourtant ReAct formalisait déjà des cycles de raisonnement et d'action, tandis que le maker-checker existe bien avant l'IA. Ne s'agit-il pas simplement de réétiqueter des patterns déjà consolidés ?
"C'est une question légitime et la réponse honnête est que presque aucun élément du Loop Engineering, pris individuellement, n'est complètement nouveau", admet-il. "Le cycle observation-action existe depuis des décennies. Le maker-checker est à la base de la code review, de la séparation des tâches et de nombreux systèmes de contrôle. Les retry, timeout, circuit breaker, files d'attente de travail et supervision humaine ne sont pas des inventions de l'IA générative. La nouveauté ne réside pas dans la brique individuelle, mais dans le fait que ces briques doivent être recomposées autour d'un exécuteur non déterministe. C'est un peu ce qui s'est passé avec DevOps. DevOps n'a pas inventé le déploiement, la surveillance, le versionnement ou l'automatisation. Il a reconnu que, pour produire des logiciels fiables avec continuité, ces mécanismes devaient être conçus comme un système opérationnel et organisationnel unique. Le Loop Engineering essaie de faire quelque chose de similaire pour les agents. ReAct décrit un pattern avec lequel le modèle alterne raisonnement et action. Il ne détermine pas nécessairement où doit vivre l'intention durable, qui a l'autorité de déclarer le travail terminé, comment les critères d'acceptation doivent être protégés ou combien le cycle peut coûter. Un pattern explique comment peut fonctionner une partie du comportement. Une discipline doit également expliquer comment le limiter, l'observer, le vérifier et l'interrompre."
Maker, Checker, Ralph
Ici, on entre dans le cœur technique de la méthode, avec deux patterns opérationnels mis en avant dans le livre : la séparation entre Maker et Checker, et le Ralph Loop.
Je l'interroge sur le risque le plus évident : le Checker peut également être un modèle probabiliste, alors comment gère-t-on le risque d'une "hallucinated approval", un contrôleur qui approuve un travail erroné, en particulier lorsque Maker et Checker partagent les mêmes angles morts.
"Séparer Maker et Checker est nécessaire, mais pas suffisant", explique Papalini. "Si je demande à un modèle de produire un résultat et que je demande ensuite au même modèle, peut-être dans la même conversation, si le résultat est correct, je n'ai pas construit un contrôle réellement indépendant. J'ai simplement demandé au système d'approuver son propre travail. Le risque augmente lorsque Maker et Checker partagent le même modèle, le même contexte, les mêmes exemples et la même interprétation implicite de l'objectif. Ils peuvent être deux agents distincts et avoir tout de même le même angle mort. C'est pourquoi, dans le livre, je parle de vérification protégée. Lorsque c'est possible, le Checker ne devrait pas se limiter à exprimer une opinion linguistique. Il devrait s'appuyer sur des signaux externes : tests, compilation, analyse statique, contraintes de schéma, politiques, données de référence, simulations ou contrôles déterministes. Dans le logiciel, par exemple, il est bien préférable de demander au Checker d'exécuter une suite de tests plutôt que de lui demander si le code 'semble correct'. Lorsqu'une vérification déterministe n'est pas possible, nous pouvons réduire le risque en séparant les contextes, en utilisant des grilles d'évaluation explicites, des modèles différents ou des réviseurs humains pour les cas à fort impact. Mais soyons honnêtes : un deuxième modèle ne transforme pas magiquement un résultat probabiliste en vérité. Le Checker n'élimine pas l'incertitude. Il la rend plus visible et plus gouvernable."
Passons au Ralph Loop, l'un des patterns opérationnels d'où part le livre. Je lui demande comment il fonctionne en pratique et, surtout, où il tend à échouer, s'il a observé des cas où le loop continuait à travailler sans produire de progrès réel.
"Le Ralph Loop naît d'une idée presque provocatrice de simplicité : on fournit à un agent un objectif persistant et on le relance plusieurs fois avec un contexte frais, en le laissant lire à chaque itération l'état du repository et choisir l'étape suivante", raconte-t-il. "Sa force réside précisément dans sa simplicité. Il réduit la dépendance vis-à-vis d'une très longue conversation, rend le travail persistant et permet à l'agent de repartir de ce qui existe réellement sur le disque, au lieu de se fier uniquement à la mémoire du chat. Mais cette simplicité met aussi en évidence les limites. Un loop peut modifier de manière répétée les mêmes fichiers, corriger un test en en cassant un autre, déclarer terminée une partie qu'il n'a pas réellement vérifiée ou consommer des itérations sans réduire la distance par rapport à l'objectif. Il peut être très actif sans être réellement productif. Dans mes expériences, l'un des comportements les plus courants n'a pas été l'échec spectaculaire, mais la stagnation : le système continue de produire de petites variations autour du même problème. C'est comme une personne qui cherche ses clés toujours dans le même tiroir parce qu'elle est convaincue qu'elles doivent y être. C'est pourquoi le Ralph Loop est un bon point de départ, pas une architecture complète. Il faut ajouter des critères de succès externes, la détection du non-progrès, un budget, des limites aux modifications, des checkpoints et des procédures d'escalade. Concernant des exemples d'entreprises spécifiques, je ne peux pas parler de comportements internes non publics. Le livre distingue délibérément entre expériences, modèles analytiques et systèmes effectivement validés en production. Il serait contraire à la thèse même du livre de présenter une expérience limitée comme une preuve universelle."
Le coût caché
Ici, le livre aborde deux critiques indépendantes, l'une économique et l'autre architecturale, et je lui soumets les deux.
Papalini introduit le concept de coût par résultat accepté. Je lui fais remarquer que l'automatisation permet de multiplier plus facilement les appels aux modèles, alors le Loop Engineering ne risque-t-il pas d'augmenter la consommation totale au moment même où il cherche à l'optimiser ?
"Oui, le risque existe. En fait, il serait naïf de le nier", répond-il. "Lorsque le coût marginal perçu d'une action diminue, nous avons tendance à l'utiliser davantage. C'est le mécanisme à la base du paradoxe de Jevons : une technologie plus efficace peut augmenter la consommation globale car elle permet de faire beaucoup plus de choses de manière rentable. Avec l'IA, c'est déjà le cas. Si un agent peut générer dix implémentations pendant que nous dormons, le risque est de se retrouver le matin avec dix implémentations à comprendre, vérifier et peut-être jeter. C'est pourquoi le nombre de tokens est, à lui seul, un très mauvais indicateur. Mais son contraire l'est tout autant : récompenser ceux qui utilisent moins de tokens ne signifie pas automatiquement récompenser ceux qui produisent le plus de valeur. La mesure que je propose est le coût par résultat accepté. Dans le calcul, il n'y a pas seulement les tokens. Il y a les tentatives infructueuses, le temps de vérification, l'infrastructure, le travail humain, le rework et le risque opérationnel. Un loop qui coûte 20 euros et produit un résultat vérifié peut être plus économique qu'un appel unique à 2 euros qui génère une erreur découverte trois semaines plus tard. Au contraire, un agent qui continue à travailler pendant des heures sur une activité marginale est simplement une machine efficace pour consommer du budget. Le but n'est pas de minimiser chaque appel. C'est de justifier chaque itération par une réduction mesurable de l'incertitude ou de la distance par rapport à l'objectif."
L'autre critique concerne le lock-in vis-à-vis des éditeurs et ce qu'il appelle dans le livre la dette conceptuelle. Je lui demande ce qu'il reste réellement d'un système construit aujourd'hui si, dans un an, le modèle utilisé est déjà dépassé.
"C'est l'une des raisons pour lesquelles je pense qu'il est utile de déplacer l'attention du modèle vers le loop", dit-il. "Si une entreprise construit tout autour des caractéristiques propriétaires d'un fournisseur unique, le lock-in est inévitable. Cela ne concerne pas seulement les API. Cela concerne le format des outils, la mémoire, le caching, les prompts système, les politiques, les systèmes d'évaluation et même les habitudes des gens. Le meilleur moyen de réduire le lock-in n'est pas de faire semblant que tous les modèles sont interchangeables. Aujourd'hui, ils ne le sont pas. Ils ont des capacités, des coûts, des latences et des modes de fonctionnement différents. Il faut cependant séparer ce qui change rapidement de ce qui doit durer. Le modèle devrait être un exécuteur remplaçable dans des limites raisonnables. L'intention, l'état du travail, les critères d'acceptation, les autorisations, les preuves et l'historique des décisions devraient vivre en dehors du modèle et, autant que possible, en dehors du produit du fournisseur. Dans un an, nous pourrions changer de Claude, GPT, Gemini ou utiliser un modèle local. Mais le plan, les tests, les règles, les données et la capacité à reconstruire pourquoi le système a pris une décision devraient rester. Il y a ensuite la dette de compréhension. Si nous générons du code ou des documents en batch plus vite que nous ne pouvons les lire, nous n'éliminons pas le travail : nous le déplaçons dans le futur, avec les intérêts. Le lock-in le plus dangereux n'est pas toujours technologique. C'est de devenir dépendant de résultats que plus personne dans l'organisation ne sait expliquer."
L'apprentissage perdu
Passons aux points faibles opérationnels, ceux qui concernent les personnes plus que l'architecture.
Je lui pose la question que je considère comme la plus délicate : si les professionnels les plus jeunes passent leur temps à superviser des agents au lieu d'écrire, d'analyser et de faire du debugging en personne, comment construiront-ils l'expérience nécessaire pour devenir seniors ? Ne risquons-nous pas de créer des architectes de loops qui ignorent ce qui se passe à l'intérieur ?
"C'est probablement le risque social le plus sérieux de toute cette transformation", admet-il sans hésiter. "On ne devient pas expert uniquement en étudiant des solutions correctes. On devient expert en rencontrant des erreurs, en faisant de mauvaises hypothèses, en lisant du code difficile, en suivant un bug à travers différents niveaux du système et en apprenant à reconnaître les signaux faibles. Si nous déléguons à l'IA précisément cette partie du parcours, nous pouvons obtenir des juniors apparemment très productifs mais dépourvus des modèles mentaux nécessaires pour comprendre quand le système se trompe. Le paradoxe est évident : nous demandons à des jeunes de superviser des outils qui produisent un travail de niveau presque senior, mais nous ne leur donnons pas le temps de construire l'expérience nécessaire pour l'évaluer. La solution n'est pas d'interdire l'IA. Ce serait irréaliste et probablement contre-productif. Il faut concevoir son utilisation comme faisant partie du parcours de formation. Dans le livre, je reprends l'idée du trio working : un junior, un senior et l'IA travaillent sur le même problème. L'IA accélère l'exécution. Le junior doit comprendre, modifier et expliquer le résultat. Le senior ne se limite pas à approuver : il pose des questions. Pourquoi cette structure a-t-elle été choisie ? Quelle hypothèse soutient le code ? Que se passe-t-il quand le service externe ne répond pas ? Quel test démontre réellement que la fonctionnalité est correcte ? La règle devrait être simple : ne pas confier à un agent une activité que le professionnel n'est pas encore capable de comprendre au moins à un niveau suffisant pour la vérifier. Si nous éliminons complètement l'apprentissage de base, nous risquons de découvrir dans quelques années que nous n'avons plus de personnes capables de concevoir les loops que nous prétendons superviser."
L'autre point faible est technique et concerne ce qu'il appelle le Loop Drift, la tendance du système à s'éloigner lentement de l'intention originale après de nombreuses itérations. Je lui demande comment il le gère.
"La première règle est de ne pas confier l'identité du travail à la mémoire conversationnelle du modèle", explique-t-il. "Une conversation longue est pratique, mais ce n'est pas un registre fiable. Les informations sont résumées, compactées, réinterprétées et parfois oubliées. Après de nombreuses itérations, le système peut continuer d'être cohérent avec sa propre histoire récente et ne plus l'être avec l'objectif d'origine. C'est pourquoi l'intention doit vivre dans un état externe et durable : une spécification, un plan versionné, des critères d'acceptation, des contraintes et des décisions déjà prises. À chaque itération, l'agent devrait relire ces éléments, et non les reconstruire librement à partir de sa propre mémoire. La deuxième règle est de distinguer entre les faits, les décisions et les synthèses. Un fait vérifié ne devrait pas être réécrit à chaque étape. Une décision devrait avoir une motivation et, si possible, une référence à la preuve qui l'a soutenue. Les synthèses produites par le modèle peuvent être utiles, mais elles ne doivent pas remplacer les sources. La troisième consiste à contrôler la progression par rapport à des signaux externes. Si l'objectif est de faire passer 120 tests, le loop ne devrait pas décider qu'il a 'presque fini' parce que le code semble meilleur. Il doit montrer quels tests passent, lesquels échouent et comment cette situation évolue dans le temps. Enfin, il faut des checkpoints et des resets. Parfois, ajouter du contexte aggrave le problème. Il est plus sain de repartir sur une session fraîche, avec l'état essentiel et les preuves réelles, plutôt que de traîner une conversation déjà déformée. La mémoire utile ne consiste pas à se souvenir de tout. C'est conserver ce qui sert sans permettre au récit de remplacer la réalité."
Du code au client
Nous terminons par le cas concret que le livre présente en dehors du domaine du logiciel, et par la vision de Papalini sur le destin du terme lui-même.
Le livre consacre un cas d'étude au service client, loin du code. Je lui demande comment il a évolué pendant l'écriture, ce qu'il veut démontrer et quel est son niveau réel de validation.
"J'ai inclus ce cas parce que je ne voulais pas que le Loop Engineering apparaisse comme un synonyme de coding agent", explique-t-il. "Le logiciel est le laboratoire le plus visible, car il dispose de tests, de repositories, de compilateurs et d'outils qui facilitent l'observation du comportement de l'agent. Mais les principes du loop s'appliquent également lorsque le résultat est une réponse à un client, un rapport, une vérification documentaire ou une proposition commerciale. Dans ce cas d'étude, le système reçoit une demande, récupère les informations pertinentes, prépare une réponse, la compare aux politiques et décide de l'envoyer, de la réviser ou de l'orienter vers un opérateur humain. Pendant l'écriture, je me suis rendu compte que la partie la plus intéressante n'était pas la génération de la réponse. C'est relativement facile. Le vrai problème était de définir qui avait le droit de l'envoyer. Une réponse peut être linguistiquement excellente tout en étant fausse : elle pourrait promettre un remboursement non autorisé, utiliser des informations non mises à jour ou traiter avec une confiance excessive un cas ambigu. Le cas sert donc à montrer que l'autonomie doit être proportionnelle au risque. Les demandes simples et bien documentées peuvent traverser le loop automatiquement. Les demandes ambiguës, économiquement significatives ou émotionnellement délicates doivent faire l'objet d'une escalade. Il est important d'être précis : le cas présenté dans le livre est un modèle conceptuel complet, construit pour montrer la méthode et ses outils. Il n'est pas présenté comme un système industriel déjà validé à grande échelle en production. Le transformer en preuve empirique nécessiterait un projet pilote réel, des données mesurées, une comparaison avec une baseline et une analyse des erreurs. Le livre propose l'architecture. Il ne prétend pas qu'une architecture sur le papier équivaut automatiquement à une preuve en production."
Nous terminons en regardant vers l'avenir : dans un an, parlerons-nous encore de Loop Engineering, ou le terme deviendra-t-il superflu comme c'est le cas pour le Prompt Engineering ? Peut-il devenir une discipline autonome, semblable au DevOps, ou sera-t-il absorbé par l'ingénierie des systèmes ?
"J'espère qu'une partie du terme deviendra superflue", répond Papalini. "Quand une pratique est vraiment absorbée par l'ingénierie, nous cessons de la considérer comme spéciale. Personne aujourd'hui ne s'étonne qu'une application doive comporter des logs, de la surveillance, des tests automatiques et des procédures de rollback. Ce sont devenus des éléments normaux du système. Il pourrait se passer la même chose avec les loops. Dans quelques années, il semblera peut-être évident qu'un agent doive posséder un état externe, un budget, des critères de réussite, des autorisations limitées et un mécanisme d'escalade. Mais je ne pense pas que le problème disparaîtra. Le DevOps n'a pas disparu lorsque les pipelines sont devenus courants. Il a changé. C'est devenu un ensemble de pratiques, de responsabilités et de compétences qui traversent le développement et les opérations. Le Loop Engineering pourrait suivre une voie similaire, mais je ne suis pas convaincu qu'il faille immédiatement de nouveaux titres professionnels ou des certifications. L'industrie technologique a déjà une capacité remarquable à créer des rôles avant d'avoir clarifié le travail. Je pense plutôt que ces compétences s'intégreront dans les rôles existants. Les développeurs devront concevoir des vérifications et des états persistants. Les architectes devront réfléchir aux niveaux d'autorité et aux limites. Les product owners devront exprimer des objectifs vérifiables. Les gestionnaires de risques devront comprendre des systèmes qui ne suivent pas toujours le même chemin. Le nom pourra changer. Mais le problème restera le même : comment transformer un exécuteur probabiliste en un système fiable, vérifiable et gouvernable."
Le livre Non-Deterministic Loop Engineering d'Enrico Papalini approfondit, outre les thèmes abordés ici, les aspects d'implémentation pratique du Ralph Loop et les modèles de gouvernance pour l'autonomie progressive des agents.