Pourquoi les agents qui impressionnent lors des démos échouent en production, et ce qu’il convient de développer à la place.

Ce que la démonstration ne montre jamais

Une bonne démonstration d’agent est organisée autour du parcours idéal. L’appel à l’outil renvoie exactement ce qui était attendu, le modèle comprend correctement la tâche, et rien ne prend du temps supplémentaire. Dans de telles conditions, un agent qui utilise des outils et résout une tâche semble presque terminé. La distance entre cet état et celui dont dépendent les utilisateurs est régulièrement sous-estimée.

En production, tout ce qui se passe en dehors du parcours idéal compte. Les certificats expirent. Un schéma change sans préavis. Une commande est mal interprétée. Les réponses arrivent en retard, de manière incomplète ou pas du tout, et chaque API externe utilisée par l’agent a ses propres particularités. Rien de tout cela n’est dû à la malchance. C’est ce à quoi on doit s’attendre lorsque des composants non déterministes font partie d’un système dont le monde extérieur continue de bouger.

Les démos ont également tendance à omettre l’évaluation et le suivi. Sans eux, une hallucination ou un débordement silencieux de la fenêtre de contexte ne déclenche aucun signal d’alarme. L’agent continue de répondre, les réponses sont fausses, et le premier signe est une plainte de l’utilisateur ou un enregistrement endommagé. Un système qui ne fonctionne bien que lorsqu’il est surveillé de près n’est pas prêt à fonctionner sans surveillance.

Un petit exemple rend cette différence concrète. Imaginez un agent qui réserve des réunions en appelant une API de calendrier. Dans la démo, le calendrier répond en 200 millisecondes avec un JSON bien structuré. En production, l’API renvoie parfois un champ dont le nom a changé pendant la nuit, parfois une page vide, et parfois reste bloquée pendant trente secondes. Le modèle peut alors inventer un créneau horaire plausible pour combler ce vide. Chacun de ces cas nécessite une réponse délibérée : valider la structure des données, traiter le vide comme un état distinct, limiter le temps d’attente, et refuser de deviner.

Où les agents échouent une fois qu’ils ont envoyé des données

Les mêmes points de défaillance réapparaissent sans cesse.

• Résultats du modèle peu fiables. Le modèle affirme des choses sans aucun fondement dans la réalité. Lorsque l’agent est connecté à des systèmes en temps réel ou qu’on lui demande des informations cruciales, un détail inventé se transforme en action erronée.
• Faillites des outils. Les agents dépendent d’API et d’outils externes qui changent de fonctionnement, interrompent les connexions ou rejettent des entrées inattendues. L’agent doit disposer d’un plan en cas de panne d’un outil, comme tenter à nouveau ou passer à une méthode plus simple.
• Boucles infinies. Un suivi insuffisant de l’état ou un cas limite non géré peuvent faire en sorte que l’agent tourne en rond sans progresser. Tenir un registre clair de ce qui a été fait est ce qui empêche le travail répétitif.

Débordement du contexte. Plus un agent lit, plus il est probable qu’il dépasse la limite de sa fenêtre de mémoire, ce qui rend les résultats partiels ou erronés. Les tâches qui exigent une grande capacité de mémorisation en souffrent le plus.

Réponses lentes et utilisation excessive de tokens. Les retards détériorent l’expérience utilisateur, et une utilisation imprévue des tokens augmente les coûts, surtout à grande échelle.

Politiques de permission floues. Si ce qu’un agent peut modifier n’est pas clairement défini, tôt ou tard il lira ou modifiera quelque chose qu’il ne devrait pas, avec des conséquences sur la sécurité et la confidentialité.

Observabilité limitée et évaluation insuffisante. Les pannes ne peuvent pas être corrigées rapidement si elles ne sont pas détectées. La surveillance montre ce que l’agent a fait, tandis qu’un bon ensemble d’évaluation révèle ses points forts et ses faiblesses.

API de tiers peu fiables. Les délais de réponse varient et des pannes surviennent. Les temps d’attente et les tentatives de réessai constituent les moyens de défense de base.

Avoir plus d’agents ne signifie pas plus de fiabilité

On a tendance à penser que répartir le travail entre plusieurs agents améliorera les performances et la fiabilité. En réalité, cela crée souvent plus de problèmes qu’il n’en résout, car chaque agent supplémentaire ajoute des tâches de communication et de coordination.

Un seul agent présente un avantage clair : une seule chose à ajuster, un seul aspect à surveiller. Lorsqu’une tâche suit une séquence linéaire et simple, comme dans une recherche directe avec des étapes bien définies, un seul agent est généralement le plus adapté.

Plusieurs agents s’avèrent utiles pour des tâches complexes qui peuvent être divisées en parties indépendantes et exécutées en même temps. Même dans ce cas, il y a des coûts : quelqu’un doit veiller à ce que les agents ne travaillent pas dans des directions opposées ou ne dupliquent pas les efforts les uns des autres. Sans coordination, ils commencent à travailler à partir d’informations obsolètes ou contradictoires. Chaque agent supplémentaire représente un point de défaillance supplémentaire, et chaque transfert de tâche est un endroit où le contexte peut être perdu ou déformé. De plus, les dépendances entre agents permettent à une défaillance de se propager aux autres, ce qui exige une surveillance d’autant plus stricte.

L’orchestration est avantageuse lorsque la tâche se divise naturellement. Dans un environnement de support client, un agent peut récupérer des informations, un autre évaluer l’émotion exprimée dans le message et un troisième rédiger la réponse, l’orchestration permettant ensuite de relier ces éléments en une seule réponse cohérente.

Pensez au cas par lots : quelques centaines de tickets de support presque identiques qui nécessitent tous la même classification et la même procédure standardisée. Un processus fixe avec une seule appel à un modèle au moment de la décision est plus facile à tester, à tarifer et à expliquer à un auditeur qu’un groupe d’agents collaborant.

Cependant, dans de nombreux cas, un flux de travail déterministe classique est préférable à une équipe d’agents. Si une tâche ne nécessite pas de parallélisme, ou si les coûts de gestion l’emportent sur tout avantage, un seul agent suivant une séquence fixe gère plus efficacement un lot de demandes similaires, car il y a peu de variations à gérer.

La décision doit reposer sur la tâche elle-même : sa complexité, le fait que le travail en parallèle soit utile, ainsi que le coût de la coordination et du suivi. En évaluant honnêtement ces éléments, une conception peut tirer parti des forces de chaque approche tout en évitant ses faiblesses.

Concevoir pour la production dès le début

Construire pour la production signifie abandonner l’objectif d’une démonstration impressionnante au profit d’un système capable de se remettre des pannes inévitables. Plusieurs pratiques jouent un rôle essentiel.

Sorties structurées. Imposer un format de sortie cohérent réduit les risques de mauvaise interprétation et facilite le débogage. Les systèmes ultérieurs peuvent compter sur une structure prévisible.

Essais répétés avec retards progressifs, ainsi que des délais d’expiration. Les problèmes temporaires tels qu’une interruption réseau ou un service temporairement indisponible doivent être gérés par des essais répétés, avec des intervalles de pause qui augmentent à chaque tentative. Les délais d’expiration empêchent un agent d’attendre indéfiniment quelque chose qui ne viendra pas.

Plans de secours. Une chaîne de plans de secours doit être écrite et testée comme n’importe quel autre chemin de code, car un plan de secours non testé échoue généralement au pire moment. Lorsque le parcours principal échoue, un outil ou une méthode alternative peut parvenir au même résultat, mais avec une précision ou une portée réduites. Le service continue de fonctionner au lieu de s’arrêter.

Implication des personnes concernées. Ce sont les cas complexes ou ambigus qui posent des difficultés aux agents. En les orientant vers un opérateur humain, on apporte un jugement aux décisions les plus importantes et on assure une responsabilité claire.

Affectation aux modèles. Les différents modèles ont des forces distinctes. En envoyant chaque tâche au modèle le plus adapté, on améliore la précision et les performances, bien que cela dépende de la connaissance des capacités et des limites de chaque modèle.

Ensembles d’évaluation. Un ensemble utile mélange des requêtes ordinaires avec des requêtes problématiques : des entrées mal formatées, des instructions contradictoires, des outils qui atteignent leur limite de temps. Tester en permanence sur une collection variée de scénarios permet de détecter tôt les faiblesses et de savoir si l’agent reste fiable face aux changements de conditions.

Suivi des traçages et des coûts. Les traçages suivent le parcours des données et des décisions au sein du système, ce qui facilite le débogage et l’optimisation. Le suivi des coûts garantit que l’utilisation des ressources reste dans les limites convenues et permet de déterminer si le système est rentable.

Dégradation planifiée. Un agent qui ne peut pas accéder à son outil de recherche peut néanmoins répondre à partir de données mémorisées et l’indiquer, ce qui est préférable à une page d’erreur. En situation de stress, un système doit perdre progressivement certaines fonctionnalités plutôt que de tomber en panne. La planification des pannes permet une récupération rapide et limite l’impact sur les utilisateurs.

Le vrai coût de la gestion d’un agent

Les frais de token représentent la ligne visible sur la facture, mais ce n’est que la partie émergée de l’iceberg. Une comptabilisation juste prend en compte plusieurs autres éléments.

• Appels aux outils. Chaque appel à un service externe coûte de l’argent et du temps, et ajoute un élément supplémentaire susceptible de tomber en panne. L’agent ne peut souvent pas fonctionner sans eux, mais ces dépendances rendent le système plus coûteux et plus complexe.
• Infrastructure. Les serveurs, le stockage et les réseaux doivent être dimensionnés en fonction d’une demande qui varie en fonction de l’activité des utilisateurs et de la difficulté des tâches. Assurer une haute disponibilité de cette infrastructure entraîne des coûts supplémentaires.
• Essais répétés et gestion des erreurs. Essentiels pour la fiabilité, mais chaque essai consomme des ressources de calcul. Dans un système où les pannes temporaires sont fréquentes, ces coûts s’accumulent rapidement.

Latence. La lenteur frustre les utilisateurs et peut entraîner davantage de tentatives ou maintenir les ressources occupées plus longtemps. La réduction de cette latence nécessite des investissements tant en infrastructure qu’en logiciels.

Surveillance et observabilité. Essentielles pour assurer le bon fonctionnement, elles exigent des logiciels supplémentaires, du matériel additionnel ainsi que du personnel pour interpréter les rapports générés par les outils et y répondre.

Intervention humaine. Les vérifications, corrections et validations garantissent l’exactitude et le respect des normes, mais le temps de travail nécessaire peut avoir un impact majeur sur l’efficacité économique.

Une façon de rester honnête dans l’évaluation est de calculer le coût par tâche achevée et non par appel de modèle. Une tâche qui nécessite trois tentatives, deux appels d’outils et une vérification humaine est bien plus coûteuse que ce que le nombre de tokens suggère, et c’est ce chiffre qu’il convient de comparer entre les différentes solutions et de suivre semaine après semaine.

La conclusion pratique est que les coûts doivent être gérés globalement dans l’ensemble de ces catégories. Un système qui semble bon marché en fonction uniquement des jetons peut s’avérer coûteux une fois que l’on prend en compte les tentatives de réessai, le personnel d’assistance et les serveurs.

Que signifie réellement la fiabilité

Le futur de l’IA agente dépend moins des démonstrations les plus autonomes et spectaculaires et plus du fait que les systèmes tiennent le choc, se remettent en marche et se rentabilisent en environnement de production. L’attention doit se déplacer de la démonstration des compétences techniques en conditions contrôlées vers la gestion des réalités complexes liées au déploiement.

La fiabilité passe en premier. Cela signifie gérer les pannes sans dramatisme, s’adapter lorsque les conditions changent et rester stable sous charge. L’architecture qui la soutient privilégie des sorties structurées, une gestion des erreurs judicieuse et un suivi approfondi. En anticipant où les problèmes peuvent survenir et en intégrant des tentatives répétées, des délais de timeout et des solutions de secours, une équipe obtient un système capable de se remettre en marche tout en assurant une performance constante.

Les considérations économiques viennent en deuxième position. Le coût réel d’un système d’IA comprend l’infrastructure, les interactions avec les outils, les retards et l’effort humain, ainsi que les tokens du modèle. Pour le rendre abordable, il faut utiliser judicieusement les ressources et avoir une vision claire du coût de chaque choix architectural. Un modèle moins cher qui nécessite davantage de tentatives répétées et de révisions humaines peut facilement coûter plus cher qu’un modèle plus performant qui résout le problème dès la première tentative.

Une liste de contrôle utile avant tout lancement est courte. Chaque mode de défaillance mentionné peut-il être identifié, et chacun dispose-t-il d’un responsable et d’une procédure d’intervention ? Une personne peut-elle voir ce que l’agent a fait la veille ? Existe-t-il une limite de dépenses et de profondeur des boucles ? Y a-t-il un moyen d’éteindre rapidement l’agent ? Si la réponse à l’une de ces questions est non, le système reste une démonstration.

Finalement, le succès sera mesuré par la capacité des agents à s’intégrer aux flux de travail existants et par la valeur concrète qu’ils apportent. Cela exige un changement de mentalité, en passant d’agents qui ont l’air performants seuls à des systèmes qui étendent les capacités des utilisateurs. Si l’accent reste mis sur la fiabilité, des économies rationnelles et les besoins des personnes qui les utilisent, l’IA agente peut devenir un partenaire fiable tant pour les problèmes complexes que pour le travail quotidien.

Lectures complémentaires

• Notes pratiques : Construction d’un système de détection des fraudes agent prêt pour la production — Guide pas à pas des Notes pratiques : Construction d’un système de détection des fraudes agent prêt pour la production : contrats, vérifications et emplacements de code à insérer pour les équipes qui mettent en œuvre ce modèle.
• Notes pratiques : Claude Code Agent Teams : Un guide pratique pour la création d’une équipe — Guide pas à pas des Notes pratiques : Claude Code Agent Teams : Un guide pratique pour la création d’une équipe : contrats, vérifications et emplacements de code à insérer pour les équipes qui mettent en œuvre ce modèle.

Notes pratiques : Les feature stores ont passé une décennie à éliminer les fuites temporelles en apprentissage automatique. — Guide pas à pas des Notes pratiques : Les feature stores ont passé une décennie à éliminer les fuites temporelles en apprentissage automatique : contrats, vérifications et emplacements de code prêts à l’emploi pour les équipes qui mettent en œuvre ce modèle.

Un nom d’agent stable n’est pas l’artefact que vous avez examiné : Identifier le candidat — Pourquoi le nom d’un agent peut rester identique tandis que les compétences, les outils et les permissions changent, et comment séparer le nom, le candidat comportemental et l’identité de exécution pour l’examen et le retrait.

Notes pratiques : Conception d’un cache pour les agents IA : leur mise en production — Guide pas à pas des Notes pratiques : Conception d’un cache pour les agents IA : leur mise en production, incluant des contrats, des vérifications et des blocs de code prêts à l’emploi pour les équipes qui implémentent ce modèle.

Pourquoi la plupart des agents IA meurent après une seule session et comment ceux qui fonctionnent longtemps survivent — Les limites liées au contexte, l’absence d’état et des vérifications insuffisantes entraînent la mort de la plupart des agents. Découvrez les modèles de points de contrôle, de mémoire, d’évaluation et d’approbation qui permettent aux agents de fonctionner sur de longues périodes.