# Cinq, cinquante ou cinq cents outils : la sélection change d’échelle.

Présenter directement un petit catalogue, réduire le périmètre à taille moyenne, puis chercher et reclasser dans les grands systèmes d’outils.

Version 1.0 · 2026-07-29 · 9 min

## Réponse courte

La sélection doit se structurer à mesure que le catalogue grandit. Avec quelques outils, présentez tout l’ensemble autorisé et soignez chaque description. Avec plusieurs dizaines, filtrez d’abord selon le rôle, le module et le parcours. Avec plusieurs centaines, recherchez les définitions pertinentes, reclassez-les, ajoutez les dépendances nécessaires puis validez les paramètres avant l’exécution. Ces nombres servent à expliquer les changements d’architecture, pas à fixer des seuils universels. Une étape supplémentaire se justifie lorsque les évaluations révèlent de la confusion, de la latence ou un contexte trop lourd.

## À retenir

- Les droits et l’éligibilité sont filtrés avant toute sélection sémantique.
- Une description d’outil précise son objectif, ses conditions d’usage, ses exclusions et des exemples.
- Les grands catalogues exigent des évaluations de recherche et des tests qui exécutent réellement les parcours.

## Un catalogue plus grand change la nature du problème

Un modèle peut comparer cinq outils clairement présentés. À cinquante, des noms proches et des responsabilités qui se chevauchent créent de la confusion. À cinq cents, envoyer toutes les définitions coûte cher et confie au modèle la découverte du catalogue.

L’architecture doit donc évoluer avec l’échelle, pas seulement le prompt. Le contexte produit réduit d’abord le domaine de manière déterministe. Une recherche sémantique classe ensuite les options autorisées. Au dernier moment, l’exécuteur valide encore l’outil et ses paramètres.

## Trois ordres de grandeur

Ces plages servent de repères. Le vrai point de bascule dépend du recouvrement entre les outils, de leurs descriptions et des résultats observés.

### 1. Autour de cinq : tout présenter

Envoyer tous les outils autorisés. Employer des noms distincts, des paramètres typés, une description claire, des cas d’usage et de non-usage ainsi que des exemples réalistes.

### 2. Autour de cinquante : réduire par des règles

Filtrer selon le module, le rôle, l’étape du parcours et l’état actuel. Regrouper les opérations proches et protéger les écritures importantes par une règle explicite.

### 3. Autour de cinq cents : rechercher les définitions

Indexer les descriptions et les exemples, retrouver les candidats, les reclasser avec la question et le contexte, puis ajouter leurs dépendances.

### 4. Valider avant l’appel

Vérifier de nouveau l’éligibilité, analyser les paramètres avec un schéma, appliquer les droits et les règles d’état, puis conserver la provenance.

### 5. Évaluer le résultat exécuté

Tester les reformulations, les outils voisins, les dépendances absentes, les refus, les pannes et les enchaînements. Contrôler l’état obtenu, pas seulement le nom choisi.

## Exemples

### Petit espace de support

Cinq outils couvrent l’état, la navigation, la recherche de sources, la proposition de ticket et l’escalade. Ils peuvent tous être présentés avec de bonnes descriptions.

### Logiciel d’opérations à plusieurs modules

Le module actuel et le rôle réduisent cinquante outils aux six qui servent réellement dans le parcours ouvert.

### Couche d’action d’entreprise

Des centaines d’opérations internes sont indexées comme capacités. La recherche propose quelques candidats, mais l’application contrôle chaque appel.

## Pièges fréquents

- Présenter tous les outils quel que soit le rôle ou le parcours.
- Rédiger des descriptions vagues qui ne diffèrent que par un nom.
- Utiliser le classement sémantique comme système d’autorisation.
- Choisir le bon outil tout en générant des paramètres invalides ou dangereux.
- Tester le nom sélectionné sans exécuter l’opération sur des cas contrôlés.

## Checklist

1. Chaque outil possède un contrat d’entrée et de sortie structuré.
2. Les descriptions précisent l’objectif, les exclusions et des exemples.
3. L’application calcule le catalogue autorisé.
4. Les grands catalogues conservent des traces de recherche et de reclassement.
5. Les dépendances et les opérations incompatibles sont représentées.
6. L’exécuteur revérifie la règle et l’état.
7. Les évaluations contrôlent l’état final et le chemin de reprise.

## Limites

- La taille ne détermine pas seule la difficulté. Le recouvrement et la qualité des descriptions comptent davantage.
- Les résultats de benchmarks d’API ne démontrent pas la sûreté dans un produit réel.
- La recherche d’outils ajoute une étape probabiliste qui doit être évaluée séparément.

## Sources

1. [τ-bench: Tool-Agent-User Interaction in Real-World Domains](https://openreview.net/forum?id=roNSXZpUDN) — Yao et al., 2025; nature: research.
2. [Model Context Protocol specification](https://modelcontextprotocol.io/specification/2025-11-25) — MCP maintainers, 2025-11-25; nature: standard.
3. [Toolformer: Language Models Can Teach Themselves to Use Tools](https://arxiv.org/abs/2302.04761) — Schick et al., 2023; nature: research.
4. [ToolLLM: Facilitating Large Language Models to Master 16000+ APIs](https://arxiv.org/abs/2307.16789) — Qin et al., 2023; nature: research.
5. [ToolRet: Tool Retrieval for Large Language Models](https://aclanthology.org/2025.findings-acl.1258/) — ACL Findings, 2025; nature: research.
6. [ToolRerank: Adaptive and Hierarchy-Aware Reranking for Tool Retrieval](https://aclanthology.org/2024.lrec-main.1413/) — LREC-COLING, 2024; nature: research.

## Questions fréquentes

### MCP est-il indispensable pour sélectionner les outils ?

Non. MCP peut standardiser leur découverte et leur appel, mais la même conception s’applique à des API typées ou à des outils en ligne de commande.

### Le modèle doit-il planifier des suites d’outils ?

Uniquement dans des limites explicites. Pour les opérations importantes, préférez des parcours connus et testez les dépendances, les reprises et les échecs partiels.

### Quand faut-il mettre à jour une description d’outil ?

Versionnez-la avec le contrat technique. Relancez les évaluations de routage et d’exécution dès que le sens, le schéma ou les conditions d’accès changent.

---

Canonical: https://scoperail.fokalabs.io/fr/guides/selection-outils-ia-echelle
Author: Ramzi Laieb, FokaLabs