Agents IA en production : stopper les faux succès

Dans les systèmes d’agents IA en production, une panne souvent ignorée est celle où un agent continue de répondre après l’échec de ses outils. Imaginons un agent chargé de rechercher des factures clients via une API interne. Les deux premiers appels réussissent, puis un identifiant expiré renvoie des erreurs 401 pour les appels suivants. Au lieu de s’arrêter, l’agent répète ses appels en modifiant légèrement les arguments, puis rédige une réponse cohérente pour les quatre clients, alors que deux recherches ont échoué. L’exécution se termine même avec un statut de succès, ce qui masque le problème. Ce type de défaillance est plus discret que les échecs coûteux ou visibles qui conduisent à l’annulation de projets d’agents IA. Gartner prévoit d’ailleurs plus de 40 % d’annulations d’ici fin 2027, mais ces échecs-là sont généralement remarqués grâce à des coûts élevés, des cas d’usage insuffisants ou des contrôles de risque faibles. Une authentification expirée peut, elle, rester silencieuse longtemps. Améliorer le modèle ne suffit pas : un modèle plus capable produit des réponses plus plausibles, donc parfois plus trompeuses si les données manquent. L’enjeu est plutôt la capacité du système à s’arrêter quand un outil tombe en panne. La première protection consiste à trier les erreurs avant qu’elles n’atteignent le modèle. Les pannes temporaires, comme un délai dépassé, une perte de connexion, un plafond de débit ou une erreur 503, peuvent mériter un nouveau essai. Les erreurs d’authentification, d’autorisation ou de ressource introuvable, comme 401, 403 ou 404, ne disparaîtront pas en répétant l’appel. Certains cas incertains, par exemple un paiement dont l’issue est inconnue, doivent être transmis à un humain. Ce triage doit être écrit dans le code, en dehors de la consigne du modèle, afin que l’agent ne puisse pas décider seul de réessayer ou d’improviser. Il faut aussi limiter le nombre de tentatives, prévenir les boucles infinies, espacer les réessais et respecter les indications de délai envoyées par certains serveurs. Une réponse avec un contenu invalide doit elle aussi être traitée explicitement. Ensuite, le système doit enregistrer chaque échec et fournir au modèle une consigne claire lui interdisant d’inventer une réponse. Une garde finale vérifie si au moins un appel a réellement abouti. Si aucun outil n’a répondu, l’agent doit refuser de terminer la tâche plutôt que produire un texte séduisant mais faux. Cette vérification peut d’abord être simple, puis devenir plus stricte en indiquant quels outils sont indispensables pour une question donnée. Une réponse honnête indiquant que l’agent n’a pas pu accomplir sa mission est plus utile à l’utilisateur qu’une réponse convaincante fondée sur des informations manquantes. Enfin, la supervision ne doit pas se limiter à la disponibilité des services. Il faut suivre les appels réussis ou échoués, les outils défaillants, les codes d’erreur et les refus déclenchés. Un tableau de bord affichant le nombre de fois où le système refuse de répondre est essentiel : un chiffre toujours nul peut signaler une protection mal activée, tandis qu’une hausse soudaine peut révéler une clé expirée ou un service qui se dégrade. Pour agir rapidement, il faut donc trier les erreurs dans le code, interdire une réponse quand les données nécessaires manquent, journaliser les échecs et surveiller les refus. Un agent qui continue à répondre quand ses outils échouent manque souvent de cette couche qui reconnaît l’absence d’information et le dit clairement.