Pourquoi les agents d’IA échouent en production : explication de l’ingénierie des harness

Imaginez un développeur à 2 heures du matin, qui a passé trois semaines à réécrire les instructions, à tester le dernier modèle phare et à ajuster la taille des blocs de données RAG. Dans un environnement de test, l’agent fonctionne parfaitement. En production, il échoue : il oublie une décision prise deux étapes plus tôt, annonce un succès juste avant de restituer quelque chose de défectueux, et son taux de réussite des tâches reste à 68 % quel que soit le modèle utilisé. Dépasser les 70 % semble impossible.

De nombreuses équipes reconnaissent cette situation. Le diagnostic habituel est que le modèle n’est pas suffisamment performant. Un diagnostic plus précis indique que le problème réside dans le système construit autour du modèle, et tant cela n’est pas admis, aucun changement de modèle ne produira de grands résultats.

Trois étapes pour travailler avec les LLM

La réflexion sur les applications basées sur des LLM a évolué à travers trois étapes, et de nombreuses équipes sont encore bloquées à l’une ou l’autre d’entre elles en rencontrant les problèmes de la troisième étape.

Étape un : ingénierie des prompts

Tout le monde commence ici, en se demandant si le modèle a compris la demande. Les LLM sont extrêmement sensibles à la manière dont on les guide. Un rôle bien choisi, quelques exemples et un format de sortie précis peuvent transformer les résultats, et pour des tâches simples à un seul tour, un bon prompt est indispensable.

Cependant, cela bute aussi sur des limites. Peu importe l’élégance avec laquelle les instructions sont formulées, elles ne peuvent pas fournir au modèle des faits qu’il manque, lui faire se souvenir de ce qui s’est passé il y a trois appels d’outil, ou l’empêcher d’inventer des données lorsque la réalité est décevante. Le piège courant est de croire qu’un prompt plus élaboré peut remplacer un manque de fondements ou de contexte réel. Ce n’est pas possible.

Étape deux : ingénierie du contexte

La question suivante est de savoir si le modèle dispose des faits nécessaires. Les équipes intègrent des pipelines RAG, un système de récupération dynamique, des résultats d’outils réinjectés dans le processus, ainsi qu’une histoire de conversation soigneusement gérée, et commencent à se soucier de ce que le modèle peut voir lorsqu’il prend une décision. Il s’agit d’un véritable progrès, et les agents deviennent nettement plus intelligents lorsque les informations appropriées arrivent au bon moment.

Le contexte ne permet pas de corriger le dérive d’exécution. L’agent élabore un plan excellent, exécute correctement la première étape, interprète mal la valeur de retour d’un outil à la deuxième étape et s’écarte du bon chemin pendant encore une douzaine d’étapes. Rien dans le système ne s’en aperçoit. Il continue d’exécuter un plan qui s’est déjà révélé erroné depuis longtemps.

Une erreur fréquente ici consiste à considérer l’ingénierie du contexte comme étant identique au RAG utilisé dans les bases de données vectorielles. Une véritable gestion du contexte inclut également l’injection dynamique d’états, la synthèse des réponses des outils et le troncature intentionnelle de l’historique. Le RAG n’est que le début.

Étape trois : l’ingénierie de contrôle

La question qui se pose maintenant est de savoir si le modèle peut continuer à fonctionner correctement dans le temps, et la réponse est un peu décevante pour ceux qui espéraient qu’un meilleur modèle s’en chargerait. L’ingénierie de contrôle consiste à construire un cadre autour du modèle : des systèmes déterministes qui surveillent ses actions, détectent ses erreurs, imposent des limites et le ramènent sur la bonne voie lorsqu’il s’écarte. Ce terme provient des rênes et des amarres de sécurité, équipements servant au contrôle.

Un modèle mental : l’agent égale le modèle plus le système de contrôle

Une approche popularisée par LangChain l’exprime simplement : un agent est un modèle associé à un ensemble d’outils. Presque tout ce qui, dans une base de code, permet à un agent de fonctionner en production, à l’exception de l’appel à l’API du modèle de base, fait partie de cet ensemble d’outils.

Pensez à envoyer un collègue junior assister à une réunion importante avec un client.

• Les prompts représentent l’ordre du jour : dire bonjour, présenter le produit, poser des questions sur les besoins.
• Le contexte correspond au dossier contenant les informations de base : l’historique avec le client, la liste des prix et les objectifs de la réunion.
• L’ensemble d’outils comprend le reste : la liste de contrôle à emporter, un point avec vous à mi-parcours, une transcription enregistrée, un moyen de les corriger s’ils s’écartent du sujet, ainsi que des critères d’acceptation clairs pour le rapport de la réunion.

Même une meilleure présentation des informations ne peut compenser l’absence d’une structure de responsabilisation. Les deux premières étapes aident un modèle à penser plus efficacement, tandis que le système de contrôle en assure le fonctionnement fiable. Le témoignage d’une équipe, qui n’est qu’une anecdote et non une référence, indique que la réorganisation de la décomposition des tâches, du traitement des états, de la validation des étapes critiques et du rétablissement en cas d’échec a permis à ce même modèle, avec les mêmes instructions, d’atteindre un taux de réussite des tâches allant d’environ 70 % à plus de 95 %.

Six niveaux d’un système de contrôle mature

Un système de contrôle n’est pas un seul fichier ni un simple conteneur ingénieux. Il est structuré en plusieurs niveaux, chacun couvrant un type différent d’échec.

Niveau 1 : limites de l’information

Ce que le modèle perçoit dans son contexte immédiat influence ses performances plus que presque tout autre facteur. Des données supplémentaires ne le rendent pas plus intelligent, elles le font perdre son focus. Mélanger des règles système, l’état de la tâche en cours et des éléments externes en un ensemble non structuré est encore pire, car le modèle commence à négliger les contraintes et les règles essentielles deviennent du bruit de fond. Le système de gestion doit déterminer et qualifier explicitement ce que le modèle reçoit : son rôle, l’objectif actuel, les critères de succès, ainsi qu’une séparation claire entre les différents types d’informations.

Couche 2 : le système d’outils

Sans outils, un LLM ne fait que prédire du texte. Avec un bon système d’outils, il peut agir dans le monde réel. Une erreur fréquente au début est de lui fournir trop d’outils. Quinze outils soigneusement documentés semblent puissants, mais cela dilue son attention et le modèle commence à inventer des paramètres inexistants ou à utiliser à tort des API qu’il ne comprend pas vraiment.

Le cadre de gestion doit déterminer quand les outils sont utilisés, et non seulement quels outils existent. Il doit empêcher le modèle de deviner quand il doit effectuer des recherches, ainsi que de chercher lorsqu’il connaît déjà la réponse. Une règle ne souffre aucune exception : ne pas rediriger directement les résultats bruts des outils vers le LLM. Une réponse JSON contenant 50 éléments provenant d’une API contamine le contexte. Filtrer, analyser et résumer les résultats avant que le modèle ne les voie.

Niveau 3 : orchestration de l’exécution

Les modèles échouent souvent non pas en raison d’un manque de compétences individuelles, mais parce qu’ils ne parviennent pas à les enchaîner dans le bon ordre. Ils fonctionnent de manière désordonnée, sautant d’une étape à l’autre, omettant des vérifications et générant des résultats avant d’avoir ce dont ils ont besoin. Le cadre de gestion impose des étapes fixes : comprendre l’objectif, évaluer les informations disponibles, obtenir ce qui manque, analyser, générer, vérifier, puis produire le résultat final.

Cela fait passer la gestion de projet d’un modèle probabiliste à un système déterministe. Le modèle ne devrait pas décider de l’ordre des tâches, et cette structure doit figurer dans le cadre de gestion.

Niveau 4 : mémoire et état

Un agent sans état souffre d’amnésie à chaque tour, comme si chaque étape d’une tâche en plusieurs phases était une nouvelle conversation. Une approche fonctionnelle maintient strictement séparés trois types de mémoire :

1. L’état actuel de la tâche, c’est-à-dire quelle étape est en cours, ce qui est en attente et ce qui a été confirmé.
2. Les conclusions intermédiaires issues de cette session.
3. La mémoire à long terme et les profils d’utilisateur, tels que les préférences et le contexte qui perdurent entre les sessions.

L’erreur la plus dommageable consiste à fusionner l’état de la tâche avec l’historique des conversations. On se retrouve ainsi avec une fenêtre de contexte en constante expansion et sans forme, ce qui détériore les performances du modèle au fil avancement de la tâche.

Niveau 5 : évaluation et observabilité

Les agents primitifs échouent ici. Ils produisent des résultats, annoncent un succès sans pouvoir savoir s’ils sont corrects. Un agent qui évalue son propre travail présente un biais optimiste intrinsèque : il qualifie du code défectueux de fonctionnel et considère une réponse comme satisfaisante alors qu’il n’a jamais répondu à la question.

Cet ensemble nécessite des vérifications automatisées et indépendantes. Le contrôle humain a posteriori est trop lent et ne peut pas être étendu. Cette couche gère la validation automatique des résultats, les environnements de test, le journalisation détaillée, les métriques ainsi que l’attribution des erreurs. Le système doit constamment démontrer que ses actions sont correctes sans jamais simplement l’assumer.

Couche 6 : contraintes, validation et récupération

L’échec est l’état normal en production. Les API expirent, le JSON est corrompu et les résultats de recherche sont erronés. Un agent sans mécanisme de récupération nécessite un redémarrage complet par un humain après chaque erreur. Trois éléments sont requis :

• Contraintes : règles codées de manière fixe indiquant ce que l’agent ne doit absolument pas faire.
• Vérification : contrôles effectués avant et après la génération du résultat, tels que la validation du schéma, les vérifications de format et le contrôle des contraintes.
• Récupération : tentatives de réexécution, chemins de secours et retour à l’état stable le plus récent connu.

Anxiété de contexte

Dans les tâches qui comprennent des dizaines d’étapes, lorsque quelque chose d’anormal se produit, les chercheurs d’Anthropic ont donné un nom à ce phénomène : anxiété de contexte. Lorsque la fenêtre de contexte approche de sa limite, les modèles omettent des détails importants, perdent de vue leurs objectifs principaux et semblent se hâter pour terminer. Ils inventent des conclusions auxquelles ils n’ont jamais abouti et sautent les vérifications, dans une urgence qui les rend négligents.

Le remède évident est la compression : résumer l’historique, injecter ce résumé et continuer. Cela diminue le nombre de tokens mais ne réinitialise pas l’état cognitif du modèle ni la dilution de son attention. Ce qui fonctionne vraiment, c’est une solution plus radicale : redémarrer complètement l’agent. Lorsque le contexte devient trop volumineux, le résumé compressé est transmis à une nouvelle instance d’agent disposant d’un contexte vierge, sans aucune confusion accumulée. C’est comme corriger une fuite de mémoire en redémarrant le processus plutôt qu’en procédant à une collecte de déchets frénétique. Le terme utilisé pour cette approche est « reflection du contexte ».

L’exposition aux outils bénéficie d’une idée similaire appelée divulgation progressive. Au lieu de charger toute la bibliothèque d’outils au démarrage, le modèle ne voit que des éléments de base minimaux. Lorsqu’il indique qu’il a besoin d’une capacité particulière, le système injecte alors la documentation détaillée ainsi que le schéma des paramètres. Optimiser le contexte ne consiste pas à fournir davantage au modèle, mais plutôt à lui donner les informations nécessaires sur demande, au moment où elles sont requises.

Séparation de la génération et de l’évaluation

L’une des idées les plus utiles provient de la manière dont Anthropic crée des agents autonomes capables de produire des produits fonctionnels complets pendant des heures sans aucune révision humaine. Le principe de base repose sur une division stricte en trois parties :

• Le planificateur transforme les demandes floues des utilisateurs en spécifications techniques précises.
• Le générateur prend ces spécifications et les met en œuvre étape par étape.

L’évaluateur agit en tant que responsable qualité indépendant, fonctionnellement séparé du générateur.

L’évaluateur ne se contente pas de lire le code du générateur. Il interagit avec le résultat obtenu. Dans le cas des interfaces utilisateur, il parcourt l’interface, examine la mise en page et teste les états interactifs. Il vérifie contre le monde réel et non contre la description que donne le générateur du monde réel.

OpenAI est allé encore plus loin. Une fois que les agents ont commencé à écrire du code plus rapidement que les humains ne pouvaient examiner les demandes de fusion, ils leur ont attribué leur propre pipeline CI/CD automatisé. Cet agent exécute ses tâches à l’intérieur de sandbox isolés, prend des captures d’écran via des navigateurs sans interface graphique, consulte ses propres journaux de logs, et continue à itérer jusqu’à ce que le déploiement soit validé, toujours sans aucune surveillance. Le statut « Terminé » ne signifie plus simplement que le texte a été généré ; il indique plutôt que le code s’est exécuté, que les journaux de logs ont été vérifiés, qu’un bug a été détecté et corrigé, et que le déploiement a été confirmé dans le sandbox.

Où se trouve réellement la limite

L’intelligence d’un modèle de base fixe la limite théorique des classements des benchmarks. La qualité de conception du cadre d’exploitation détermine si cette intelligence peut survivre, se remettre de ses échecs et apporter de la valeur dans des conditions réelles complexes. Au-delà d’un certain niveau, le modèle n’est plus le goulot d’étranglement. L’écart entre un taux de réussite de 70 % et un taux de 95 %, qui correspond également à l’écart entre une démonstration et un produit, réside dans le cadre d’exploitation.