Le dispatch d'outils
Parcours : Construire un agent de code — le harnais · Opérationnel
≈ 9 min
Le problème
Le problème : un seul outil universel, et l'agent fait tout par le shell — illisible pour vous, dangereux pour vos fichiers.
Au programme de ce module
- 01Le problème≈ 9 min
- 02L'intuition≈ 8 min
- 03Le mécanisme≈ 8 min
- 04Le code, pas à pas≈ 11 min
- 05Pièges & pratiques≈ 10 min
- 06Exercice≈ 6 min
- 07Quiz≈ 5 min
Objectifs d’apprentissage
À la fin de ce module, votre agent disposera de plusieurs outils spécialisés, et vous saurez comment le programme route chaque demande vers la bonne fonction — sans jamais toucher à la boucle du module 1. Voici les acquis visés.
- Expliquer pourquoi tout faire par Bash devient illisible, fragile et dangereux à mesure que l’agent travaille ;
- Décrire le dispatch comme une table nom → fonction, et non comme un if/else métier ;
- Gérer plusieurs demandes d’outils dans une même réponse, et renvoyer les erreurs d’outil comme information ;
- Ajouter vous-même un outil complet : déclaration, fonction, entrée dans la table.
Sources
Curriculum open-source shareAI-lab/learn-claude-code, chapitre s02 (Tool Dispatch). Documentation tool use des fournisseurs LLM. Comme au module 1, le motif est indépendant du fournisseur : il vaut pour toute API offrant l’appel d’outils.
Quand tout passe par le shell
Votre agent du module 1 fonctionne, et c’est déjà beaucoup. Mais observez-le travailler une heure. Pour lire un fichier, il lance cat rapport.txt. Pour en créer un, il bricole un echo suivi d’une redirection — et dès que le contenu dépasse trois lignes ou contient des guillemets, la commande devient un concours d’échappement. Pour corriger une faute, il dégaine un sed -i dont personne ne peut dire, à la première lecture, ce qu’il va vraiment modifier.
Trois problèmes grossissent en même temps. L’illisibilité : votre journal d’actions n’est qu’une suite de commandes shell cryptiques, pénible à auditer. La fragilité : échappements, guillemets, différences entre systèmes — chaque écriture de fichier est un petit pari. Et le danger : le shell peut TOUT faire. Pour une tâche qui ne demandait que de lire un fichier, l’agent garde en main un outil capable d’effacer un disque.
Pour comprendre : un outil dédié borne le geste
Un outil read_file ne peut QUE lire ; un outil write_file ne peut QU’écrire le fichier désigné. En spécialisant les outils, on réduit la surface d’action de chaque geste ET on gagne un journal lisible : read_file(notes.txt) se comprend d’un coup d’œil, là où la commande shell équivalente demande un déchiffrage. C’est aussi la fondation du futur système de permissions (s03) : on n’autorise finement que ce qu’on a d’abord séparé.
Spécialiser sans rien casser
On veut donc des outils spécialisés — lire un fichier, écrire un fichier — et un agent qui CHOISIT le bon au bon moment. Avec une exigence cachée : la boucle du module 1 ne doit pas bouger d’une ligne. Toute la question du module tient alors en une phrase : quand le modèle répond utilise read_file, comment le programme sait-il quelle fonction appeler ? La réponse est une structure de données d’une simplicité désarmante : la table de dispatch.
Vérifiez votre compréhension
Pourquoi remplacer tout par Bash par des outils spécialisés comme read_file et write_file ?
À retenir
Un seul outil universel = un agent qui fait tout par le shell : journal illisible, écritures fragiles, surface d’action démesurée. On spécialise (read_file, write_file) SANS toucher à la boucle. La pièce qui rend cela possible — la table de dispatch — est l’objet de ce module.