Le tool calling est un pattern applicatif dans lequel un modèle choisit ou propose une capacité nommée et fournit des arguments structurés, puis l’application hôte décide si et comment l’exécuter. L’outil peut rechercher une donnée, calculer, créer un brouillon ou changer un système externe. La sortie du modèle est une demande, pas la preuve que l’opération est autorisée, valide ou achevée. L’application valide le schéma, authentifie utilisateur et service, impose la politique, contrôle l’état, exécute via une intégration de confiance et retourne le résultat observé.
Un prototype réduit l’usage d’outils à une boucle: décrire les fonctions, parser un appel, renvoyer le résultat. La production ajoute identité, permissions, état périmé, duplication, échec partiel, instructions hostiles et conséquences irréversibles. Un argument syntaxiquement valide peut viser le mauvais client ou montant. Un timeout peut cacher un paiement réussi, puis le retry le répète. Une sortie d’outil peut contenir du contenu non fiable qui redirige le modèle. Si le modèle décide aussi l’autorisation et interprète le succès, un seul composant probabiliste contrôle toute la transaction.
Concevez les outils comme des contrats applicatifs étroits et typés autour de capacités métier. Gardez identité, autorisation, limites et validations à forte conséquence hors du modèle. Séparez lecture, brouillon, aperçu et commit lorsque cela rend l’effet compréhensible. Utilisez idempotence et contrôle d’état pour les mutations, minimisez les accès et renvoyez une preuve structurée. Le modèle peut choisir et expliquer, mais des services déterministes décident si l’effet exact est permis. Testez refus, annulation, timeout, retry, compensation et sortie malveillante.
Cycle de l’appel
Sélection, autorisation, exécution et observation sont distinctes
Le modèle sélectionne un outil parce que nom, description et schéma semblent pertinents, puis construit des arguments depuis la conversation. L’hôte parse et valide la proposition avant exécution. L’authentification établit l’identité, l’autorisation décide du droit et la validation métier contrôle les conditions actuelles. Seule l’intégration effectue l’opération. Une observation finale rapporte succès, échec, identifiants créés ou nouvel état. Confondre les étapes produit une fausse complétion et un audit faible.
La spécification Model Context Protocol définit les outils par identifiant, description et schéma d’entrée, ainsi que les messages d’appel et de résultat. Un protocole standardise découverte et échange sans décider le modèle de permissions ou l’appétit de risque de l’organisation. Traitez annotations et métadonnées comme de l’information provenant d’une source de confiance. La même revue sécurité s’applique à MCP, aux interfaces d’un fournisseur et au code interne.
| État | Couche responsable | Preuve |
|---|---|---|
| Proposé | Modèle et parser hôte | Nom et arguments |
| Autorisé | Service identité et politique | Décision et périmètre |
| Validé | Application métier | État et invariants |
| Exécuté | Intégration de confiance | Réponse ou transaction |
| Observé | Application et interface | Résultat vérifié |
Sûreté des effets
Concevoir l’API pour contenir une erreur plausible du modèle
Un outil étroit réduit l’ambiguïté. Un outil de lecture ne mute pas en effet secondaire. Un brouillon prépare sans envoyer. Un aperçu résout prix, destinataire et impact juste avant approbation. Le commit peut exiger un token d’aperçu immuable et une clé d’idempotence. Ces limites améliorent compréhension et tests. Elles font aussi du refus un résultat normal plutôt qu’un échec conversationnel que le modèle tente de contourner.
La gestion du risque doit couvrir usages abusifs prévisibles et changement opérationnel sur le cycle, conformément à l’approche NIST AI RMF. Construisez des cas pour injection, record interdit, arguments mal formés, aperçu périmé, timeout fournisseur et résultats contradictoires. Masquez les secrets, limitez la rétention et alertez les motifs anormaux. Les effets irréversibles ou réglementés demandent une revue métier et sécurité qualifiée.
- Garder des outils étroits et typés.
- Autoriser chaque effet sur l’identité actuelle.
- Séparer aperçu et commit sensible.
- Rendre les retries idempotents.
- Rapporter le résultat observé.
Ce qui caractérise un bon résultat
Résultats concrets pour tool calling IA
- Chaque outil a un but limité, un schéma explicite et un résultat défini.
- Les permissions utilisateur et service sont contrôlées à l’exécution.
- Les actions sensibles exposent aperçu et approbation lorsque nécessaire.
- Un retry ne duplique pas silencieusement un effet protégé.
- Les états demandé, accepté, achevé et échoué restent distincts.
- Les logs permettent l’enquête sans secrets ou contenu privé superflu.
Modèle opératoire
Comment exécuter le travail
- 01
Modéliser la capacité métier
Nommez acteur, objet, opération, préconditions, effet et conséquences d’échec. Décidez si la capacité doit lire, produire un brouillon, rester réversible ou committer avant la description au modèle.
- 02
Spécifier le contrat typé
Créez noms et descriptions précis, schémas contraints et sorties structurées. Rendez les identifiants explicites, refusez les champs inconnus et distinguez erreurs métier et transport.
- 03
Imposer les contrôles
Authentifiez l’identité, autorisez l’objet et l’action, validez l’état, appliquez limites de fréquence et valeur, demandez une approbation et utilisez une clé d’idempotence pour les mutations.
- 04
Observer et évaluer les effets
Retournez le résultat réel, pas une hypothèse optimiste. Enregistrez corrélation, décision et outcome. Testez cas normal, refusé, ambigu, hostile et partiellement échoué avec compensation ou escalade.
Évaluation
Les questions qui changent la décision
- Le modèle doit-il lire, rédiger, prévisualiser ou committer cette opération?
- Quelle identité et quelle politique autorisent l’objet et l’action?
- Que faut-il valider de façon déterministe au-delà du schéma?
- Quel effet exige une confirmation humaine sur l’état actuel?
- Comment résoudre retries, timeouts et demandes dupliquées?
- Quelle preuve structurée indique ce qui s’est réellement produit?
Modes d’échec
Où les équipes perdent le contrôle
Un outil large permet davantage que sa description ne le suggère.
Le modèle invente un identifiant valide qui vise le mauvais record.
Une sortie non fiable injecte des instructions dans l’étape suivante.
Un timeout est rejoué après que l’effet a déjà réussi.
L’approbation précède une modification du montant ou de l’état.
L’assistant annonce la fin depuis la demande plutôt que le résultat.
Mesure
Mesurer le travail terminé
La mesure porte sur le processus terminé, y compris la revue et les exceptions. Le volume produit ne prouve pas à lui seul que le processus est meilleur.
- demandes acceptées, refusées, clarifiées et abandonnées par motif
- échecs de schéma, autorisation et règle métier
- effets dupliqués empêchés par idempotence
- opérations demandées avec preuve d’achèvement vérifiée
- taux d’approbation et d’annulation par conséquence
- temps de détection, confinement et résolution d’un échec partiel
Questions
Questions fréquentes
Qu’est-ce que le tool calling en IA?
Le modèle propose une opération nommée avec des arguments structurés; l’application hôte valide, autorise et exécute. Les outils peuvent lire des informations ou produire des effets externes.
Le function calling exécute-t-il déjà la fonction?
Non. Le modèle produit généralement une demande. Le code décide de sa validité et de son autorisation, exécute puis renvoie le résultat observé. La sortie du modèle ne crée pas de droit.
Comment sécuriser les tool calls?
Par schémas étroits, moindre privilège, autorisation sur état actuel, règles déterministes, aperçu et approbation, idempotence, résultats structurés, monitoring et reprise testée.
MCP sécurise-t-il automatiquement le tool calling?
Non. MCP standardise découverte et messages. L’application reste responsable de confiance, authentification, autorisation, validation, approbation, secrets, exécution et audit.
Sources
Sources primaires
- Model Context Protocol: Tools Model Context Protocol
- Artificial Intelligence Risk Management Framework 1.0 National Institute of Standards and Technology
À propos de l’auteur
Tony Kim
Tony écrit sur l’IA appliquée, l’ingénierie produit fiable et les systèmes qui transforment les réponses complexes en exécution maîtrisée.
Zeke
Ingénierie de produits IA pour transformer un cahier des charges en produit fiable en production.
Directions produit, fondateurs et équipes d’ingénierie. Le point de départ est le processus existant, ses contraintes et les preuves déjà disponibles.
Découvrir Zeke→