Les agents d’IA plantent rarement. Ils échouent discrètement, et la recherche explique pourquoi

Les agents fondés sur de grands modèles de langage répondent désormais aux demandes d’assistance, interrogent des bases de données et planifient des voyages. Lorsqu’ils dysfonctionnent, ils renvoient généralement une réponse assurée et un code de réussite. De plus en plus de travaux de recherche expliquent pourquoi ces échecs sont difficiles à détecter et comment les équipes d’ingénierie apprennent à les mesurer.

Un échec qui ressemble à une réussite

Les logiciels traditionnels ont tendance à échouer de manière manifeste. Une fonction déclenche une exception, un serveur renvoie un code d’erreur et un tableau de bord de supervision passe au rouge. Un agent d’IA se comporte différemment. Il fonctionne en boucle : un modèle de langage lit une invite, décide d’appeler un outil comme une API de recherche ou une base de données, lit le résultat, puis décide de la suite. Chaque étape peut échouer alors même que toutes les requêtes réseau de la chaîne aboutissent.

Prenons un cas courant. Un outil météorologique tombe en panne et renvoie le texte « service indisponible » dans une réponse par ailleurs normale. Le modèle lit ce texte, présente poliment ses excuses ou, pire encore, rédige des prévisions plausibles à partir de ses données d’entraînement. L’utilisateur reçoit une réponse fluide. Les journaux du serveur indiquent une requête réussie, avec une latence normale. Dans une infrastructure de supervision classique, rien ne signale qu’un problème s’est produit.

Les fournisseurs de modèles décrivent la même lacune dans leur propre documentation. Le guide de l’API Gemini de Google précise que le modèle « n’exécute pas lui-même la fonction ». Il se contente de proposer un nom de fonction et des arguments ; c’est l’application du développeur qui exécute l’appel. L’application est donc la seule partie du système à connaître le résultat réel. Le guide d’ingénierie d’Anthropic sur la création d’agents souligne également que les agents ont besoin, à chaque étape, d’une « vérité terrain » issue de l’environnement, comme les résultats des outils, pour évaluer leur progression. Lorsqu’un outil signale un échec sous la forme d’un texte ordinaire, cette vérité terrain est erronée et l’agent ne peut pas s’en rendre compte.

Il ne s’agit pas d’un problème nouveau, mais d’une version plus aiguë d’un problème ancien. En 2015, des ingénieurs de Google dirigés par D. Sculley ont décrit la « dette technique cachée » des systèmes d’apprentissage automatique. Selon eux, la majeure partie des risques liés à un système d’apprentissage automatique en production se situe en dehors du code du modèle, dans les dépendances aux données, la configuration et le code de liaison. Les agents ajoutent un nouvel élément à cette liste. Les invites et les descriptions des outils sont des éléments de configuration qui peuvent modifier le comportement d’un système sans que son code change.

Petites modifications, grands effets

Quelle peut être l’incidence d’une petite modification d’invite ? Dans un article présenté à ICLR 2024, Melanie Sclar, de l’University of Washington, et ses collègues n’ont modifié que la mise en forme des invites à quelques exemples : séparateurs, espacement et majuscules. Le sens est resté le même. Pourtant, les performances sur la même tâche variaient toujours jusqu’à 76 points de précision avec LLaMA-2-13B. Cette sensibilité ne disparaissait ni avec des modèles plus grands, ni avec davantage d’exemples, ni avec l’ajustement par instructions.

Les auteurs recommandent de présenter une plage de performances obtenues avec des formats d’invite plausibles plutôt qu’un seul chiffre. Pour les équipes d’ingénierie, la leçon pratique est plus simple : modifier une invite revient à modifier du code. Il faut conserver un historique des versions et effectuer un test avant de la mettre à la disposition des utilisateurs.

Il en va de même pour les descriptions des outils, que le modèle lit dans le cadre de son invite. Le guide d’Anthropic recommande d’accorder aux définitions des outils « autant d’attention en ingénierie des invites » qu’à l’invite principale. Il décrit un agent de programmation qui commettait régulièrement des erreurs avec les chemins de fichiers relatifs. Lorsque l’outil a été modifié pour exiger des chemins absolus, le modèle l’a utilisé sans erreur. Le modèle n’avait pas changé. Seule la description qu’il lisait avait été modifiée.

Une seule réussite ne prouve pas grand-chose

Une deuxième piste de recherche porte sur la régularité des résultats. Le banc d’essai τ-bench, publié par Shunyu Yao et ses collègues de Sierra et présenté à ICLR 2025, simule des conversations avec le service client dans lesquelles un agent doit utiliser des outils et respecter des règles commerciales. Les auteurs ont introduit une mesure appelée pass^k : la probabilité qu’un agent accomplisse correctement la même tâche lors de chacune des k tentatives.

Les résultats sont préoccupants. Un agent GPT-4o réussissait environ 61 % des tâches de vente au détail lors d’une seule tentative. Lorsqu’il devait réussir la même tâche huit fois de suite, le taux tombait à environ 25 %. Une démonstration qui fonctionne une fois en dit peu sur le comportement d’un système à sa millième exécution.

Où les systèmes multiagents échouent

De nombreuses équipes enchaînent désormais plusieurs agents : l’un planifie, un autre exécute et un troisième vérifie le travail. Une étude de 2025 menée par UC Berkeley, « Pourquoi les systèmes LLM multiagents échouent-ils ? », a analysé plus de 1 600 traces d’exécution annotées issues de sept cadres multiagents populaires. Les auteurs, sous la direction de Mert Cemri, ont élaboré une taxonomie appelée MAST, qui recense 14 modes d’échec répartis en trois groupes : problèmes de conception du système, désalignement entre les agents et vérification des tâches.

Leur principale conclusion est que de nombreux échecs tiennent à la conception du système, et pas seulement aux limites du modèle sous-jacent. Les agents ignorent le rôle qui leur a été attribué, perdent le fil de la conversation ou déclarent une tâche terminée sans en vérifier le résultat. Ces échecs ne laissent aucune trace d’erreur. Ils ne sont visibles que si quelqu’un peut lire ce que chaque agent a réellement fait. L’article d’Unite.AI sur le paradoxe multiagent fait un constat similaire du point de vue de l’architecture : l’ajout d’agents peut amplifier une erreur initiale plutôt que la compenser.

Rendre visible l’invisible

La réponse technique s’inspire des systèmes distribués, où les requêtes sont suivies depuis longtemps à travers de nombreux services au moyen d’une technique appelée traçage. Appliquée aux agents, chaque requête utilisateur devient une trace, et chaque appel de modèle ou appel d’outil devient un « segment » au sein de celle-ci. Un segment consigne son entrée, sa sortie, les jetons utilisés et le temps nécessaire. L’organisme chargé des normes du secteur dans ce domaine, OpenTelemetry, élabore des conventions communes pour les segments d’IA générative. En 2026, ces conventions sont toujours considérées comme étant en cours d’élaboration ; les noms des attributs peuvent donc encore changer.

Plusieurs projets open source, tels que Langfuse, Arize Phoenix et AcruxCore, appliquent déjà cette idée. Leur code source est public : les équipes peuvent donc examiner la manière dont une trace est stockée et exécuter le logiciel sur leurs propres serveurs. Ces projets enregistrent les appels de modèles et les appels d’outils sous forme de segments au sein d’une même trace, et permettent aux équipes de leur attribuer des scores de qualité. Le choix de l’outil importe moins qu’un détail : un segment d’outil doit consigner ce que l’outil a effectivement renvoyé, et pas seulement indiquer si la requête réseau a abouti. Sans cela, l’échec de l’outil météo décrit plus haut reste invisible.

Les enquêtes menées dans le secteur suggèrent que le traçage est désormais courant, mais que les tests ne suivent pas le même rythme. Le rapport sur l’état de l’ingénierie des agents de LangChain a interrogé 1 340 professionnels à la fin de 2025. La qualité était le principal obstacle cité à la mise en production des agents, mentionné par 32 % des personnes interrogées. 89 % des organisations ont déclaré disposer d’une certaine forme d’observabilité de leurs agents, et 62 % effectuaient un traçage détaillé des étapes individuelles et des appels d’outils. Seules 52,4 % réalisaient des évaluations hors ligne sur des jeux de test, et 37,3 % évaluaient le trafic en production. La plupart des équipes peuvent voir ce que leurs agents ont fait. Moins nombreuses sont celles qui vérifient si c’était correct.

Évaluer les réponses à grande échelle

Les traces montrent ce qui s’est passé. Elles ne disent pas si la réponse était bonne. Lire chaque conversation manuellement ne passe pas à l’échelle ; les équipes ont donc de plus en plus recours à un second modèle comme évaluateur, une approche appelée « LLM en tant que juge ». Un article présenté à NeurIPS 2023, signé par Lianmin Zheng et ses collègues, a montré que des modèles performants tels que GPT-4 concordaient avec les préférences humaines dans plus de 80 % des cas, soit à peu près autant que les humains entre eux.

Le même article a documenté les faiblesses de cette méthode. Les modèles juges privilégient la réponse présentée en premier, préfèrent les réponses plus longues et peuvent favoriser les textes qu’ils ont eux-mêmes rédigés. Les scores des juges ne sont donc que des estimations. Ils sont utiles à grande échelle, mais doivent être vérifiés à l’aide d’un petit ensemble d’exemples annotés par des humains, en faisant varier l’ordre des réponses.

De la pratique aux politiques

Ce travail de mesure devient également une exigence en matière de gouvernance. L’Institut national des normes et de la technologie des États-Unis a publié son Cadre de gestion des risques liés à l’IA en janvier 2023. L’une de ses quatre fonctions fondamentales, « Mesurer », demande aux organisations de quantifier, de suivre et de documenter les risques liés à l’IA au fil du temps. Pour un agent, les traces et les scores d’évaluation constituent les éléments probants exigés par cette fonction.

Ce que les équipes peuvent faire dès maintenant

Cela fait écho à l’argument avancé sur cette plateforme : la fiabilité est le véritable critère de l’IA agentique. Les recherches présentées plus haut apportent un éclairage sur les mesures qui sous-tendent cet argument : la fiabilité n’est pas une propriété que l’on observe une seule fois ; c’est une plage de valeurs qu’il faut mesurer en continu.

Les recherches font ressortir quelques bonnes pratiques, dont beaucoup sont également recommandées par les principaux fournisseurs de modèles. Le guide pratique d’OpenAI pour créer des agents conseille aux équipes de « mettre en place des évaluations afin d’établir une référence de performance » avant toute optimisation, et de confier le contrôle à un humain lorsqu’un agent dépasse un nombre défini de tentatives infructueuses ou est confronté à une action à haut risque. Anthropic recommande de procéder à des « tests approfondis dans des environnements en bac à sable » avant de laisser les agents agir de manière autonome.

Concrètement, cela se traduit par quelques mesures simples. Gérez les invites et les descriptions d’outils sous contrôle de version, comme du code. Testez chaque modification d’invite sur un jeu de données fixe et attendez-vous à une plage de résultats plutôt qu’à un seul chiffre. Exécutez chaque cas de test plusieurs fois, car un seul passage ne révèle pas les incohérences. Consignez les sorties des outils dans les traces afin qu’un outil défaillant ne puisse pas se dissimuler derrière un code de réussite. Considérez les scores des évaluateurs automatisés comme des estimations et vérifiez-les auprès de personnes.

Aucune de ces pratiques ne nécessite une avancée majeure dans les capacités des modèles. Elles exigent de considérer un agent d’IA pour ce qu’il est : un système probabiliste qu’il faut mesurer, car il signale rarement lui-même ses échecs.