Le passage de la réponse à l’action
Depuis quelques années, la plupart d’entre nous associent les modèles de langage à la façon dont on se rapporte à un collègue très bien lu. Vous posez une question, vous obtenez une réponse, et la suite dépend de vous. Cette manière de travailler est en train d’être remplacée discrètement. Les problèmes intéressants ne consistent plus à obtenir qu’un modèle dise la bonne chose. Ils consistent à faire en sorte qu’un système fasse la bonne chose, sur de nombreuses étapes, avec des outils réels, dans des environnements chaotiques où le premier plan survit rarement au contact avec la réalité.
C’est de cela qu’il s’agit avec l’ingénierie agentique. C’est la discipline qui consiste à concevoir, construire et faire fonctionner des systèmes dans lesquels un modèle ne produit pas seulement du texte, mais pose des actions, observe les résultats et décide de la suite jusqu’à ce qu’un objectif soit atteint. Le modèle reste au centre, mais ce n’est désormais qu un composant dans une machine plus vaste, et la difficulté réelle réside surtout dans tout ce qui l’entoure.
Ce changement compte parce que les compétences sont différentes. L’écriture de prompts récompense une formulation ingénieuse. L’ingénierie agentique récompense les éléments qui, depuis toujours, rendent le logiciel fiable : des interfaces claires, une bonne observabilité, une gestion sensée de l’échec et une boucle étroite entre ce que vous mettez en production et ce que vous apprenez. La seule nouveauté vraiment déterminante, c’est le composant imprévisible placé au cœur de tout.
Ce qu’est réellement un agent
Le mot « agent » est tellement étendu qu’il couvre presque tout, aussi vaut-il la peine d’être précis. Un agent est un système qui poursuit un objectif en choisissant de manière répétée des actions à partir de ce qu’il observe, plutôt qu’en suivant un script fixe. La caractéristique déterminante, c’est la boucle, pas l’intelligence. Un thermostat suit une règle. Un agent décide.
Il est utile de traiter l’autonomie comme un continuum plutôt que comme un oui ou non. À une extrémité, il y a un seul appel à un modèle qui classe un e-mail. Un peu plus loin, un workflow enchaîne plusieurs appels dans un ordre fixe : c’est utile, mais cela reste scripté. Encore plus loin, le modèle choisit quel outil appeler et quand, et continue jusqu’à ce qu’il juge le travail terminé. À l’autre extrémité, le système fixe ses propres sous-objectifs, gère sa propre mémoire et fonctionne pendant des heures. La plupart des systèmes de production se situent aujourd’hui quelque part au milieu, et c’est généralement au bon endroit, car une autonomie totale n’est que rarement ce dont un problème a réellement besoin.
Décider où votre système se situe sur ce continuum fait partie de ce qu’on peut faire de plus éclairant très tôt. Cela vous indique jusqu’où vous pouvez vous appuyer sur le jugement du modèle, combien de structure vous devez imposer et où le risque va se concentrer.
La boucle de l’agent
Retirez les noms de frameworks et la dimension marketing, et presque tous les agents exécutent la même boucle. Ils rassemblent le contexte de leur situation, réfléchissent à ce qu’il faut faire, effectuent une action, puis observent ce qui s’est passé. Ensuite, ils repartent pour un nouveau tour, en utilisant ce qu’ils viennent d’apprendre, jusqu’à ce que l’objectif soit atteint ou qu’ils renoncent.
Chaque passage dans cette boucle est un point de décision, et les points de décision sont là où les choses tournent bien ou mal. Une bonne boucle d’agent n’est pas celle qui utilise le prompt le plus ingénieux. C’est celle où chaque étape dispose juste de la quantité d’informations nécessaire pour faire un choix judicieux, et pas plus. Donnez au modèle toute l’historique de tout ce qui s’est passé et il perd le fil. Donnez-lui trop peu et il agit à l’aveugle. Une grande part du travail consiste à décider ce que le modèle a le droit de voir à chaque tour.
La boucle explique aussi pourquoi construire des agents donne l’impression d’être si différent d’un logiciel ordinaire. Dans le code normal, vous pouvez raisonner sur chaque chemin. Ici, le modèle peut choisir un chemin que vous n’aviez jamais imaginé, se remettre d’une erreur d’une manière que vous n’aviez pas prévue, ou s’égarer dans une direction qui semble raisonnable pendant trois étapes, puis s’effondrer. Vous n’écrivez pas le chemin. Vous façonnez l’espace des chemins possibles et essayez de rendre les bons faciles à trouver.
L’anatomie d’un agent
Il aide à se représenter un agent comme un petit ensemble de composants, chacun faisant un travail précis. Il y a le modèle, qui fournit le raisonnement et le langage. Il y a des outils, qui permettent au système d’agir sur le monde et d’en lire les retours. Il y a la mémoire et le contexte, qui transportent les informations pertinentes vers chaque décision. Et il y a l’orchestration autour de tout cela, qui exécute la boucle, impose des limites et décide quand s’arrêter.
Ce qui ressort, une fois qu’on en a construit quelques-uns, c’est à quel point une grande partie du travail difficile ne concerne pas le modèle lui-même. Le modèle est surtout un choix fixe. Vous en sélectionnez un, vous lui donnez un prompt, puis vous passez à autre chose. L’effort d’ingénierie se concentre sur les parties autour. De bons outils, une bonne gestion du contexte et une bonne orchestration permettent de distinguer une démo qui fonctionne une fois d’un système que vous pouvez laisser tourner. Les équipes qui s’acharnent sur la formulation des prompts tout en négligeant ces éléments ont tendance à construire des choses impressionnantes le mardi et cassées dès le vendredi.
Outils et contexte : la vraie surface
Si la boucle est le squelette, les outils et le contexte sont là où se produit réellement l’ingénierie.
Un outil, ce sont les mains du modèle. C’est la manière dont l’agent lit une base de données, envoie un message, exécute une requête ou déplace un fichier. La qualité de vos outils fixe un plafond strict sur ce que l’agent peut faire, et il s’avère que la conception d’outils est, elle aussi, un artisanat à part entière. Un bon outil fait une chose claire, porte un nom et une description qui indiquent exactement au modèle quand y recourir, vérifie ses entrées et renvoie des résultats faciles à exploiter. Un outil vague avec une description ambiguë est pire que l’absence d’outil, parce que le modèle l’utilisera avec assurance et de façon incorrecte. Le soin que vous mettriez à concevoir l’interface pour un collègue compétent mais nouveau mérite à peu près le même niveau de soin que l’outil lui-même, car c’est à peu près la situation.
Le contexte constitue l’autre moitié. Un modèle ne sait que ce qu’on met devant lui ; à chaque tour, vous répondez donc à une question silencieuse : de quoi le modèle a-t-il besoin de voir maintenant pour choisir judicieusement ? C’est d’ici que vient l’expression « context engineering », et c’est devenu l’un des problèmes centraux du domaine. L’approche naïve consiste à continuer d’en mettre davantage dans la fenêtre : plus d’historique, plus de documents, plus d’instructions. Cela ne passe pas à l’échelle. L’attention se dilue, les coûts augmentent et le modèle commence à manquer exactement la chose qui comptait. La meilleure approche traite le contexte comme un budget à dépenser à dessein. Vous récupérez ce qui est pertinent, résumez ce qui est ancien, abandonnez ce qui est terminé, et gardez l’ensemble actif petit et net. Le réussir fait souvent la différence entre un agent qui reste cohérent pendant une tâche longue et un agent qui perd progressivement le fil.
Pourquoi les agents sont difficiles
Voici le fait peu confortable que chaque équipe finit par découvrir. Un seul appel à un modèle est raisonnablement fiable. Enchaînez-en vingt, et de petites erreurs s’accumulent pour créer des systèmes qui échouent plus souvent qu’ils ne réussissent.
Les calculs sont impitoyables. Si chaque étape d’une tâche en dix étapes est correcte 95 % du temps, la tâche entière ne réussit qu’environ 60 % du temps, et cela suppose que les erreurs sont indépendantes, ce qui n’est souvent pas le cas. Une mauvaise observation au début peut empoisonner toutes les décisions qui suivent. Cette accumulation est la raison principale qui explique pourquoi les agents qui impressionnent dans une démo ont du mal en production. La démo, c’est un chemin heureux. La production, ce sont dix mille chemins, et la longue traîne est remplie d’entrées que personne n’avait pensé à considérer.
Les modes d’échec développent leur propre personnalité une fois qu’on en a vu assez. Les agents se retrouvent bloqués dans des boucles, en appelant le même outil encore et encore en s’attendant à une réponse différente. Ils hallucinent un outil ou un résultat qui n’a jamais existé. Ils annoncent la réussite alors que rien n’a été accompli. Ils exécutent tranquillement la mauvaise tâche avec une confiance totale. Aucun de ces problèmes n’est un bug que vous pouvez traquer avec une trace de pile. Ce sont des comportements contre lesquels il faut concevoir, détecter quand ils se produisent et gérer avec élégance. Les accepter tôt, plutôt que d’espérer qu’un modèle plus performant fera disparaître le problème, c’est ce qui distingue les équipes qui mettent des agents en production de celles qui ne font que les montrer en démo.
Evals et observabilité
Si les agents échouent de manière subtile, par accumulation et de façons difficiles à prédire, alors la chose la plus importante que vous puissiez construire n’est pas l’agent lui-même. C’est la capacité à voir ce qu’il fait et à mesurer si vos changements le rendent meilleur.
L’observabilité d’abord. On ne peut pas déboguer ce qu’on ne voit pas, et le raisonnement d’un agent est invisible par défaut. Chaque exécution doit laisser une trace : ce que l’agent a vu, ce qu’il a décidé, quels outils il a appelés, ce qui est revenu, et où il s’est retrouvé. La première fois qu’un agent de production
