Pourquoi moins d'outils rendent un agent IA plus performant

Donnez dix outils à un agent IA et vous obtenez généralement un résultat moins bon, pas une plus grande capacité. Chaque outil que vous ajoutez est une occasion supplémentaire pour le modèle de faire le mauvais choix, de passer de mauvais arguments, ou de faire silencieusement la mauvaise chose tout en renvoyant une réponse formulée avec assurance. Les agents qui fonctionnent vraiment en production tournent généralement avec deux à cinq outils, chacun dédié à une seule tâche.

Ce n'est pas une préférence théorique. Elle revient constamment dans la description des agents bien construits : un script qui lit les issues GitHub et les manifestes de dépendances pour trouver de vraies alertes de sécurité sans toucher au code, ou un scanner qui classifie les sous-domaines comme susceptibles d'être des wildcards en utilisant rien d'autre que des requêtes DNS. Le fil conducteur n'est pas un prompting astucieux. C'est que chaque agent dispose d'une boîte à outils petite et fixe, et n'a jamais à deviner laquelle de quinze options utiliser.

Le piège du nombre d'outils

Lorsque vous définissez le périmètre d'un projet agentique, le réflexe est d'être généreux : donner à l'agent un outil de recherche, un outil de base de données, un outil de fichiers, un outil d'e-mail, un outil de calendrier, « au cas où » il en aurait besoin. Cela semble prudent. Ça ne l'est pas — et les deux exemples ci-dessus montrent pourquoi chaque mode d'échec est concret, pas hypothétique :

• La précision de sélection diminue. Le scanner de manifestes de dépendances fonctionne parce qu'il ne choisit qu'entre « lire un manifeste » et « lire une issue ». Ajoutez une troisième option — disons, un outil de recherche web généraliste — et le modèle doit désormais décider à chaque exécution si l'alerte dont il a besoin se trouve dans le dépôt ou sur le web, et il se trompera assez souvent pour que cela compte.
• Les erreurs d'arguments s'accumulent. Le classificateur de sous-domaines basé sur le DNS prend une seule entrée : un nom d'hôte. C'est le schéma dans son intégralité. Dès que vous greffez un deuxième outil avec ses propres paramètres, vous avez doublé la surface d'exposition à un appel malformé — et sur une action d'écriture, le coût de cet appel malformé n'est plus « mauvaise réponse DNS » mais « mauvais enregistrement soumis ».
• Les échecs restent silencieux. Ces deux outils sont en lecture seule, donc un mauvais choix produit simplement une mauvaise classification visible dans la sortie. Un agent câblé avec un outil d'écriture à côté peut en faire un mauvais usage, consigner un succès et passer à la suite — et personne ne s'en aperçoit avant qu'un client se plaigne.
• Les coûts augmentent insidieusement. Chaque définition d'outil s'embarque dans la fenêtre de contexte à chaque appel, que le scanner de manifestes touche jamais son deuxième ou troisième outil ou non. Une liste d'outils surchargée, c'est un prompt surchargé à chaque tour.

Les propres recommandations d'Anthropic sur la conception d'agents font le même constat du côté de la construction : les systèmes agentiques les plus fiables sont composés de composants simples et bien testés, pas d'un agent unique jonglant avec toutes les capacités à la fois (voir le document technique d'Anthropic sur la construction d'agents efficaces). La simplicité n'est pas un point de départ dont on s'affranchit avec le temps. C'est ce qui continue de fonctionner à l'échelle.

À quoi ressemble un périmètre restreint en pratique

Nous exploitons notre propre moteur d'outreach de cette façon. Il scrape le site d'un prospect, extrait la poignée de faits qui comptent, et rédige un e-mail personnalisé — le tout en un seul appel concentré plutôt qu'une chaîne en plusieurs étapes avec un outil de recherche, un outil CRM et un outil de rédaction assemblés ensemble. Moins de pièces mobiles signifie moins d'endroits où le processus peut silencieusement dérailler, et le coût par lead est moindre. La leçon s'est généralisée au-delà de l'outreach : moins un agent a besoin d'outils, plus il est facile de savoir exactement ce qu'il a fait et pourquoi. C'est une question distincte de celle de savoir s'il faut utiliser un appel LLM unique ou une chaîne d'agents pour une tâche donnée, mais le même instinct s'applique au niveau des outils : ne donnez pas au modèle des options dont il n'a pas besoin.

Comment auditer la liste d'outils de votre agent

Si vous évaluez un projet (en interne ou via une agence), demandez à voir la liste des outils avant de vous intéresser au modèle ou au prompt. Quelques vérifications à effectuer :

• Pouvez-vous nommer en une phrase la tâche unique de cet agent ? Notre moteur d'outreach passe ce test en une phrase : il transforme le site d'un prospect en un e-mail rédigé. Si la réponse pour l'agent d'un tiers nécessite un paragraphe, c'est probablement deux agents qui partagent un même costume.
• Chaque outil est-il utilisé lors d'une exécution normale, ou certains sont-ils là « au cas où » ? L'appel scrape-extraction-rédaction n'a aucun outil inutilisé qui traîne dans le schéma. Les outils inutilisés ne représentent que des inconvénients : des coûts et de la confusion sans aucun bénéfice.
• Deux outils sont-ils faciles à confondre d'après leurs noms et descriptions seuls ? Si un humain parcourant le schéma hésiterait, le modèle aussi.
• Que se passe-t-il quand l'agent choisit le mauvais outil ? S'il n'existe aucune journalisation qui remonte un mauvais appel, vous ne le découvrirez pas avant que le client ne le fasse.
• Pourrait-on remplacer cet agent généraliste par deux agents spécialisés avec un routeur ? La logique de routage est ennuyeuse et testable. Un modèle unique jonglant avec douze outils n'est ni l'un ni l'autre.

Quand plus d'outils se justifient vraiment

Rien de tout cela ne signifie que chaque agent devrait être un script à outil unique. Certaines tâches couvrent véritablement plusieurs systèmes — un agent de support qui doit consulter une commande, vérifier un transporteur et émettre un remboursement fait légitimement trois choses. La solution n'est généralement pas de réduire le nombre d'outils sur un seul agent, mais de répartir la tâche sur un workflow d'étapes plus petites avec des passages de relais explicites, plutôt qu'un modèle unique qui décide parmi une douzaine d'options à chaque tour. Un workflow déterministe qui appelle trois agents spécialisés en séquence est bien plus facile à déboguer qu'un agent à neuf outils qui tente de déterminer lui-même le bon ordre.

Ce qu'il faut demander à un prestataire à ce sujet

Si vous comparez des agences ou des propositions en interne pour un projet agentique, le périmètre des outils est une question peu coûteuse et très révélatrice à ajouter à votre liste d'évaluation des prestataires. Demandez-leur de passer en revue la liste d'outils de l'agent proposé et de justifier chacun d'eux. Une équipe qui a réfléchi à la question aura une réponse nette pour chaque outil. Une équipe qui ne l'a pas fait commencera à justifier les outils par des scénarios — ce qui ressemble généralement au son de la dérive de périmètre en temps réel.

Le nombre d'outils est l'une des rares décisions de conception d'agent que vous pouvez vérifier sans lire une seule ligne de code, et il est fortement corrélé au comportement de l'ensemble du système une fois en production, quand personne ne surveille son exécution.

Si vous définissez le périmètre d'un projet agentique et souhaitez un second avis sur la liste d'outils avant de vous engager, parlons-en.