Une analyse approfondie des agents ReAct révèle un gaspillage critique de ressources en production : 90,8 % des tentatives de reprise sont inefficaces. Ces échecs ne proviennent pas d'erreurs temporaires, mais du fait que le modèle tente systématiquement d'appeler des outils qui n'existent pas en raison d'hallucinations. Ce problème structurel signifie que les ingénieurs paient pour des retraits inutiles, vidant le budget de retries disponible pour les problèmes qui pourraient réellement être résolus. L'étude se fonde sur une hypothèse centrale : la reprise ne doit concerner que les erreurs susceptibles d'évoluer. Une demande d'outil halluciné, par exemple, retournera toujours un résultat nul, quelle que soit la durée de la tentative. Dans les architectures conventionnelles, le nom de l'outil est choisi à l'exécution par le modèle de langage et validé par une recherche de chaîne de caractères. Si le modèle invente un nom, le système ne détecte pas la nature permanente de l'erreur et consomme une unité de budget de retries, traitant cet échec permanent comme une panne temporaire réseau. Sur une base de 200 tâches simulées, l'approche traditionnelle a gaspillé 466 retries sur 513 totaux. À l'inverse, une approche améliorée a éliminé ces gaspillages grâce à trois correctifs structurels. Premièrement, une taxonomie des erreurs permet de classer les échecs en catégories retryables (comme les limites de débit ou les problèmes réseau) et non retryables (comme un outil introuvable). Les erreurs non retryables sont alors ignorées immédiatement sans consommer de budget. Deuxièmement, l'implémentation de disjoncteurs de protection par outil remplace le compteur global. Cela isole les pannes spécifiques et empêche un seul outil défaillant d'épuiser les retries de tout le système. Le correctif le plus transformateur est le routage déterministe des outils. Au lieu de laisser le modèle fournir le nom de la fonction à exécuter, le plan de tâche est défini par des types d'étapes structurées. Un dictionnaire Python associe ces types à des fonctions valides, rendant les hallucinations au niveau du routage techniquement impossibles. Le modèle se concentre uniquement sur la logique et les arguments, tandis que la sécurité de l'exécution est gérée par le code. Les résultats de cette approche montrent une performance radicalement différente. Le taux de réussite passe de 89,5 % à 100 %, mais la véritable victoire réside dans la prévisibilité. La variance du nombre d'étapes par tâche, mesurée par l'écart-type, chute de 1,36 à 0,46, rendant les coûts et la latence bien plus stables. Bien que la latence moyenne simulée semble légèrement plus élevée due à la façon dont les échecs sont comptabilisés, le percentile 95, métrique critique pour les accords de niveau de service, reste identique entre les deux approches. Cela prouve que la fiabilité accrue ne se fait pas au détriment de la performance en cas de charge élevée. Les implications pour les développeurs sont directes. Si votre système continue de faire des retries sur des erreurs d'outils inexistants, votre tableau de bord de surveillance ne montrera pas la dégradation réelle tant que les tâches ne sont pas totalement échouées. Pour corriger cela, il est impératif d'introduire une classification d'erreurs dès l'appel des outils et de déplacer la logique de sélection des fonctions dans le code plutôt que de la laisser à la sortie du modèle. Ces modifications, bien qu'apparemment techniques, constituent une nécessité fondamentale pour toute agent IA fonctionnant en production avec des boucles d'outils complexes.