Quatre chemins pour donner vos propres outils à votre agent

Un agent connecté à un modèle sait expliquer et rédiger, mais il ne peut pas interroger votre CRM, consulter l'inventaire ni ouvrir un ticket. Vous pouvez avoir la meilleure API de l'entreprise (la porte par laquelle un programme demande des choses à un autre) ; si l'agent ne peut pas l'appeler, il reste à répondre de mémoire. C'est là que viennent les outils personnalisés : des fonctions ou des services qui vivent hors du modèle et que l'agent peut invoquer. Le module Microsoft Learn « Integrate custom tools into the agent » énumère quatre routes et explique quand chacune s'applique. Je les parcours en entier, avec leurs exemples et la question qui les sépare. Et je termine par la confusion qu'il vaut mieux éviter.

Ce qu'est un outil personnalisé

C'est une fonction ou un service défini hors du modèle que l'agent invoque pour exécuter des actions spécifiques : interroger un CRM, traiter un remboursement, vérifier l'inventaire. Ils étendent ce que l'agent peut faire au-delà des outils intégrés du Foundry Agent Service, qui couvrent des cas génériques comme rassembler des connaissances et générer du code. Une clarification évite la confusion : ce ne sont ni des modèles ajustés ni des extensions VS Code.

Le design compte ici : celui qui décide quand utiliser l'outil, c'est l'agent. Il le fait dynamiquement, selon la définition de l'outil et la saisie de l'utilisateur. Vous décrivez ce que fait la fonction ; le modèle choisit de l'invoquer quand la demande l'exige.

Pourquoi ça vaut le coup

Trois bénéfices, et les trois se ressentent différemment. Productivité : les tâches répétitives cessent de consommer du temps humain. Précision : la sortie reste cohérente, avec moins d'erreurs humaines. Solutions adaptées : la logique qui s'exécute est celle de votre métier. Les scénarios typiques sont le support technique connecté au CRM, la gestion d'inventaire, la programmation de rendez-vous médicaux et le support TI avec ticketing. Dans les quatre, l'outil remplit la même idée : connecter un système qui existe déjà à l'agent qui décide.

Le flux complet, étape par étape

Ça vaut la peine de regarder tout le mécanisme avant les routes, car les quatre le partagent :

Vous ajoutez l'outil à la définition de l'agent. Ainsi, la fonctionnalité est à la disposition de l'agent.
L'utilisateur fait une demande, en langage naturel et sans connaître l'outil.
L'agent analyse la demande et décide si un outil lui sert. La décision est dynamique : elle dépend de sa définition et de la saisie de l'utilisateur.
L'outil s'exécute (votre code, votre fonction hébergée, votre API) et le résultat revient à l'agent.
L'agent transforme le résultat en réponse en langage naturel.

L'étape 3 s'illustre sans bruit avec un exemple : l'utilisateur demande la météo et l'agent décide d'interroger l'API météo. Personne n'a écrit un if pour cette décision. Le même schéma s'applique aux quatre routes ; ce qui change, c'est où vit l'étape 4.

Les quatre routes d'un coup d'œil

Foundry Agent Service propose quatre routes d'intégration. Les choisir est plus facile si vous demandez où vit la logique qui manque :

flowchart TD
    L{Où vit la logique qui manque ?}
    L -->|Dans votre code| F[Appel de fonction : vous décrivez la fonction et FunctionTool l'enregistre]
    L -->|Dans du code piloté par événements| A[Azure Functions : files de stockage en entrée et sortie]
    L -->|Existe déjà comme API| O[Outil OpenAPI 3.0 : se connecte tel quel, avec son authentification]
    L -->|Dans des connecteurs Power ou Azure| G[Logic Apps : low-code ou no-code]

En clair : une seule question décide la route. Si la logique est dans votre code, enregistrez la fonction. Si elle déclenche des événements, accrochez-la à une file. Si l'API est déjà faite, décrivez-la. Si vous vivez déjà dans les connecteurs Power, ne réécrivez rien. Aucune route n'est meilleure qu'une autre : ce sont des réponses à des questions différentes. Les quatre routes partagent le même squelette du flux ci-dessus : quelqu'un enregistre l'outil, l'agent décide, le résultat revient.

Route 1 : appel de fonction

L'appel de fonction décrit la structure de la fonction dans la définition de l'agent. Le modèle renvoie le nom de la fonction à invoquer, avec ses arguments, et votre code l'exécute. C'est le mécanisme par lequel le modèle « demande » l'exécution de quelque chose qu'il ne peut pas faire seul.

Dans le SDK (la boîte à outils de bibliothèques avec laquelle vous programmez contre le service), cela s'implémente avec FunctionTool : nom, paramètres avec schéma JSON (JSON, le format de données utilisé pour échanger de l'information ; « strict » signifie que les arguments n'admettent pas l'improvisation) et description, et cela s'ajoute à la liste tools de PromptAgentDefinition. Le schéma strict a un but : il dit au modèle quels arguments la fonction accepte, sans marge pour les inventer. Ces trois champs sont ce que le modèle lit avant de décider : le nom identifie l'action, la description explique quand l'utiliser et le schéma borne les arguments. Et il faut le savoir : l'enregistrement ne se configure pas dans le portal et ne requiert pas de modifier le modèle. Ça se passe dans le code, à la création de l'agent.

L'exemple est une fonction recent_snowfall(location) qui renvoie un JSON avec les totaux de neige. Elle s'enregistre avec FunctionTool, location requis et strict, et l'agent « snowfall-agent » est créé sur gpt-4.1 avec des instructions qui lui ordonnent d'utiliser les fonctions fournies. Quand la demande l'exige (« combien de neige est tombée à Quevedo ? »), l'agent invoque la fonction, reçoit les totaux et rédige la réponse avec. Le cycle complet : la personne demande, l'agent analyse, décide qu'il a besoin de la fonction, l'exécute, reçoit le JSON des totaux et seulement alors rédige. Si la source de données change, l'agent n'est pas touché : c'est la fonction qui l'est, car c'est là que vit la logique.

Route 2 : Azure Functions

Azure Functions est du calcul sans serveur orienté événements : du code qui s'exécute sans que vous administriez des serveurs, déclenché quand quelque chose s'y déclenche. L'appelle pas directement : il envoie des requêtes à la fonction via des files de stockage, avec des bindings d'entrée et de sortie (connexions déclarées entre la fonction et les files), et traite les résultats. Ainsi il peut répondre à des déclencheurs comme des requêtes HTTP ou des messages de file, sans héberger d'infrastructure propre.

En pratique, AzureFunctionTool avec AzureFunctionDefinition déclare deux bindings pointant vers des files de stockage : input_binding et output_binding, chacun avec son queue_name et son queue_service_endpoint. Le binding d'entrée amène la requête à la fonction ; celui de sortie renvoie le résultat. La fonction queue_trigger reçoit la location, décrit l'outil pour le modèle et renvoie le résultat par la file de sortie. L'agent laisse une demande dans une file, votre fonction la traite à son rythme et laisse la réponse dans une autre file. Ni l'un ni l'autre n'attend l'autre, et pas de serveur à maintenir allumé pour ça. L'avantage pratique est celui du sans-serveur : si personne ne demande de neige, rien ne tourne et rien n'est payé pour tourner.

Route 3 : OpenAPI 3.0

Si l'API externe existe déjà et a sa spécification OpenAPI 3.0 (le standard pour décrire une API par écrit : quels endpoints elle accepte, ce qu'elle reçoit et renvoie), l'outil la connecte tel quel. Pas d'appels à écrire à la main ni d'Azure Functions à héberger. Ça standardise l'intégration : la spécification est le contrat, et l'outil la lit. Elle admet trois types d'authentification : anonyme, clé API et identité managée. Et la réponse face à un service web basé sur OpenAPI 3.0 ne laisse aucun doute : l'ajouter comme outil de spécification OpenAPI à la définition de l'agent.

Route 4 : Logic Apps

C'est l'option low-code ou no-code : vous ajoutez des flux de travail et connectez applications, données et services à l'agent. Ça a du sens quand l'intégration vit déjà dans les connecteurs Power Platform ou Azure. C'est celle qui laisse le moins de code derrière elle : si le flux existe déjà dans les connecteurs, il ne reste à l'agent que de l'invoquer. Et pour une équipe qui ne programme pas, c'est la route qui permet de participer quand même : le flux s'assemble en faisant glisser des étapes, pas en écrivant des fonctions.

Comment choisir, en une phrase

Le critère est simple. Si la logique vit dans le code de l'application, l'appel de fonction s'applique. Azure Functions s'applique au code hébergé sans serveur. OpenAPI s'applique à une API externe. Et Logic Apps est la voie quand vous voulez éviter votre propre code. Bien choisir évite des paiements de maintenance : l'appel de fonction vous laisse du code à soutenir dans l'app ; l'outil OpenAPI laisse l'intégration déclarée dans la spécification, sans appels manuels.

La confusion qu'il vaut mieux éviter

Il y a une erreur classique qu'il vaut mieux nommer d'emblée, parce que ça économise des problèmes : penser qu'un modèle ajusté est un outil personnalisé. Ce n'en est pas un. Un outil personnalisé est une fonction ou un service disponible pour l'agent qui étend ce qu'il peut faire, et rien de plus. Si vous mélangez les deux catégories, vous finissez par chercher dans le catalogue des modèles une capacité qu'il faut en réalité connecter comme code ou comme service.

De la lecture à l'exécution

Ce qui n'a pas été exécuté, c'est l'exercice « Build an agent with custom tools » : il exige un abonnement Azure, et il est resté non exécuté ici. Le post a couvert les quatre routes, leurs exemples et le critère de choix. Il reste à les essayer : construire l'agent et voir chaque route résoudre un vrai outil.

Si vous l'appliquez à votre projet, l'ordre du post est celui qui vous convient : d'abord répondre où vit la logique qui manque, ensuite choisir la route, ensuite enregistrer l'outil avec une bonne description, et seulement après tester que l'agent décide de l'utiliser. Et la mesure qui compte dès que l'agent tourne, c'est le taux de réussite de cette décision : combien de fois il a choisi le bon outil quand la demande l'exigeait. Avec ce chiffre en main, la description de l'outil cesse d'être intuition et devient donnée.

Mon avis

La question qui ordonne les quatre routes, c'est où vit la logique qui manque. Si elle est dans votre code, enregistrez la fonction. Si elle déclenche un événement, accrochez Azure Functions à la file. Si l'API est déjà faite, lâchez la spécification OpenAPI. Dans les quatre cas, l'étape que vous ne sautez pas est la même : mettre l'outil à disposition avec une bonne description et laisser l'agent décider quand l'utiliser.

---

*Source : le module « Integrate custom tools into the agent » de Microsoft Learn.*