Foundry dans VS Code : la configuration de votre agent, en YAML et dans Git

Le module Microsoft Learn « Develop AI agents with Microsoft Foundry and Visual Studio Code » s'ouvre sur un scénario concret. Une organisation de santé a besoin d'un agent qui réponde aux questions des patients, gère les rendez-vous et fournisse des informations médicales en temps réel. Tout ce qui suit naît de là : ce qu'est un vrai agent, comment on en configure un dans Foundry, et pourquoi cette configuration devrait vivre dans un fichier YAML dans Git. Aussi quels outils il peut utiliser et comment le publier sans surprises. Ce post parcourt la route complète : de la définition de l'agent au point de terminaison publié.

Ce qu'est un agent IA

Un agent IA est un service logiciel qui utilise l'IA générative pour comprendre et réaliser des tâches au nom d'utilisateurs ou d'autres programmes. La différence avec une application traditionnelle est dans le mode d'opération. L'application suit des règles prédéfinies ; l'agent opère avec indépendance, comprenant le contexte, prenant des décisions et agissant pour atteindre ses objectifs. Il combine aussi le modèle avec des outils spécialisés.

La valeur se mesure à ce qu'il fait : il automatise les tâches routinières et améliore la prise de décision. Il permet de monter en charge sans ressources humaines proportionnelles, et il est disponible 24 heures sur 24. Des cas concrets l'illustrent : Microsoft 365 Copilot pour la productivité, le suivi des tendances en recherche, et la génération et qualification de prospects en vente. Cineplex traite les remboursements avec un agent ; GitHub Copilot relit le code et corrige les bugs.

Pour les construire, Microsoft Foundry Agent Service est une plateforme entièrement managée : vous créez, déployez et dimensionnez des agents sans administrer les ressources de calcul et de stockage en dessous. Le service simplifie la complexité au point de permettre des agents avec moins de 50 lignes de code.

Déclaratifs et hébergés

Foundry accepte deux types d'agents. Les agents déclaratifs se définissent par configuration plutôt que par code, et viennent en deux formes : basés sur les messages (un agent avec modèle, instructions, outils et avis) et à flux de travail (orchestrations multi-agents en YAML). Les agents hébergés se créent en code, dans des conteneurs, avec un contrôle total de la logique tandis que la plateforme gère l'infrastructure. Le point de départ est le déclaratif à messages, la voie la plus accessible pour commencer.

Portail ou VS Code : deux approches, un flux

Il y a deux façons de développer. Le portail (ai.azure.com) sert aux prototypes rapides, à la configuration visuelle, à l'administration centralisée, à la collaboration avec des parties prenantes non techniques et au suivi des tokens, de la latence et des évaluations. L'extension Microsoft Foundry pour VS Code, installée depuis le Marketplace, s'organise en trois sections : Ressources, Outils, et Aide et commentaires. Elle brille là où le développeur vit : contrôle de versions des configurations, itération rapide, développement code-first avec YAML et développement local. L'installation est standard : Marketplace avec Ctrl ou Cmd + Shift + X, et la connexion passe par l'icône Azure (se connecter, choisir son abonnement, section Foundry). Dans Ressources vous déployez aussi des modèles par nom, version et capacité, et gérez plusieurs agents : comparer les YAML côte à côté, dupliquer, archiver.

Les deux partagent le même flux : se connecter au projet, créer l'agent avec un nom et un but, configurer les instructions, ajouter des outils, tester, itérer, déployer et intégrer. Et ils exigent les mêmes ressources : le projet Foundry, qui provisionne l'infrastructure automatiquement, et les déploiements de modèles comme GPT-4.1 ou Claude Sonnet 4.6. En option : Azure AI Search pour la récupération avancée, Azure Storage pour les fichiers, Key Vault pour les secrets et Azure Functions pour les outils personnalisés. Beaucoup d'équipes combinent les deux approches.

Le concepteur et son YAML

YAML est un fichier texte brut où la configuration s'écrit comme une liste lisible, tant par vous que par la machine. Dans Foundry, le YAML synchronisé avec le concepteur garde la recette complète de l'agent.

Les propriétés de l'agent sont les mêmes dans les deux vues : nom, modèle (seulement les déployés), description, instructions système (la base du comportement) et identifiant d'agent généré automatiquement. De là on règle les paramètres du modèle. La temperature va de 0,1 à 0,3 pour des réponses cohérentes, de 0,7 à 1,0 pour les créatives et de 0,3 à 0,7 pour les tâches d'entreprise structurées ; top_p reste à 1,0 par défaut.

L'exemple est un assistant santé (healthcare-assistant) sur gpt-4.1, avec temperature 0,5 et top_p 1. Ses instructions multilignes définissent des responsabilités (trouver les rendez-vous disponibles, répondre sur les politiques, aider à reprogrammer) et des règles de conduite (ne jamais accéder aux informations médicales des patients, vérifier les détails avant de confirmer). Le bloc tools vient vide et les métadonnées étiquettent l'agent comme healthcare, customer-service et scheduling. L'exemple, avec ses champs :

name: healthcare-assistant
model: gpt-4.1
description: Asistente sanitario para consultas de pacientes y citas
instructions: |
  Encontrar citas disponibles.
  Responder preguntas sobre políticas de la clínica.
  Ayudar a reprogramar citas.
  Nunca acceder a información médica de pacientes.
  Verificar los detalles antes de confirmar.
temperature: 0.5
top_p: 1.0
tools: []
metadata:
  tags: [healthcare, customer-service, scheduling]

En clair : c'est la même configuration que vous construiriez dans le concepteur visuel, mais dans un fichier qui vit à côté du code. Chaque bloc a son rôle : nom et modèle définissent l'identité ; instructions est le comportement ; temperature et top_p, quelle variation vous acceptez ; tools, ce qu'il peut invoquer ; et les tags, comment le retrouver ensuite. Modifier le YAML synchronisé avec le concepteur, c'est là que la vie s'améliore : contrôle de versions dans Git avec le code, mises à jour groupées en confiance et modèles réutilisables. Ça ajoute la revue de code et l'automatisation planifiée, avec validation de syntaxe en temps réel. Les bonnes pratiques suivent : versionner le YAML dans Git avec le code, noms et étiquettes descriptifs, et documenter les décisions avec des commentaires. Tester après chaque changement, commencer simple et itérer, et garder chaque agent avec un but clair.

Les outils : ce que l'agent peut faire

Les outils sont des fonctions invocables que l'agent décide d'utiliser automatiquement. L'utilisateur fait une requête ; l'agent l'analyse, invoque l'outil, reçoit les résultats et répond en langage naturel. Les principaux de la plateforme : interpréteur de code (Python isolé pour les calculs, l'analyse de données et les graphiques) et recherche de fichiers (RAG sur les documents du magasin de vecteurs : PDF, DOCX, TXT et MD). Du côté de l'information : Bing Web Search, avec citations automatiques, et Azure AI Search sur des index existants à l'échelle entreprise. Pour les API externes, les outils OpenAPI, définis avec OpenAPI 3.0 (le standard pour décrire une API par écrit). Le catalogue ajoute l'automatisation du navigateur, l'utilisation de l'ordinateur, la génération d'images, SharePoint, Microsoft Fabric, la recherche approfondie et agent à agent.

Pour vos propres outils, les serveurs MCP standardisent l'intégration et viennent en trois types : distants pour la production, locaux pour le développement et personnalisés. MCP signifie Model Context Protocol, le standard par lequel un assistant reçoit des outils externes. Ils apportent un protocol standardisé, des composants réutilisables, des outils de la communauté et une intégration simple, et s'ajoutent depuis le registre de l'extension pour être testés dans l'aire de jeux.

Le bond se voit avec un second agent : un assistant de recherche avec plusieurs outils à la fois. Interpréteur de code pour analyser des données, recherche web avec la connexion Foundry pour l'information actuelle, et recherche de fichiers sur le magasin de vecteurs pour la documentation interne. L'agent orchestre les trois selon la demande : une question de tendance part en recherche web ; une question de chiffres, au code ; une question de processus interne, aux documents.

Les risques, au sérieux

Les agents accèdent à des données confidentielles et agissent avec autonomie, donc les risques méritent leur propre liste. La liste complète :

Perte de données et exposition de la vie privée.
Injection et manipulation de commandes.
Accès non autorisé et escalade de privilèges.
Empoisonnement des données.
Vulnérabilités de la chaîne d'approvisionnement, via les compléments de tiers.
Dépendance excessive aux actions autonomes.
Journalisation inadéquate.
Inversion du modèle : déduire les données d'entraînement par des requêtes répétées.

Les mitigations suivent : RBAC avec le privilège minimum (RBAC signifie contrôle d'accès basé sur les rôles : qui a le droit de faire quoi sur chaque ressource), filtrage et validation des messages, approbation humaine pour les opérations sensibles, journalisation et traçabilité complètes, audit périodique des dépendances, et réentraînement et validation continus. Deux cas rendent ça concret : un complément de tiers compromis qui insère du code malveillant, et un agent CRM qui finit par agir avec des privilèges d'administrateur.

Cinq choses à tester avant de déployer

Il vaut couvrir cinq fronts : chemin heureux, cas avancés (entrées ambiguës ou incomplètes), limites (requêtes hors périmètre), conversation multi-étapes et invocation d'outils. Les résultats sont journalisés à chaque exécution.

Déployer sauvegarder ; publier exposer

Déployer sauvegarde la configuration de l'agent dans le projet pour tester et itérer dans l'espace de travail. Publier la déplace vers une ressource Azure appelée application d'agent. Là l'application est créée, avec son URL d'invocation, sa politique d'authentification et son identité Microsoft Entra (Microsoft Entra ID est le système de comptes et d'identités de Microsoft : celui qui décide qui entre où et avec quels droits). À côté reste le déploiement : l'instance en cours d'exécution de la version. Le résultat : les consommateurs externes peuvent appeler l'agent sans accès au projet.

flowchart LR
    D[Déployer : sauvegarde la configuration dans votre projet] --> P[Publier : crée l'application d'agent dans Azure]
    P --> I[Une nouvelle identité Entra naît, distincte de celle du projet]
    I --> R[Réaffectez les rôles RBAC dont l'agent a besoin pour ses outils]
    R --> U[Les consommateurs externes appellent la même URL, sans accès au projet]

En simple : déployer, c'est sauvegarder ; publier, c'est ouvrir la porte. Et quand vous ouvrez la porte, un nouvel identifiant naît sans aucun droit.

Le point de terminaison utilise le protocole Responses API (le protocole avec lequel les applications parlent à l'agent) et reste stable entre les versions : les mises à jour acheminent 100 % du trafic vers la nouvelle version. L'identité est la partie qui fait mal : l'application publiée reçoit sa propre identité Microsoft Entra, indépendante de celle du projet, et les droits ne se transfèrent pas tout seuls. L'appelant a besoin du rôle Azure AI User sur l'application d'agent (les clés API ne sont pas acceptées). Les rôles RBAC que l'agent utilise pour ses outils doivent aussi être réaffectés. Sans cela, les appels qui fonctionnaient en développement échouent avec des erreurs d'autorisation après publication. La vérification est directe : az account get-access-token --resource https://ai.azure.com et un POST avec l'en-tête Bearer ; un 403 indique que le rôle manque.

Intégrer et exploiter

L'extension génère du code d'intégration (View code → dossier) avec authentification, connexion, envoi et traitement. Les schémas d'intégration sont les applications web, les flux de travail pilotés par API, les interfaces de chatbot et l'automatisation en arrière-plan. En production il faut surveiller avec Application Insights : temps de réponse, taux d'invocation, erreurs et tokens. Travailler aussi avec les identités managées et le privilège minimum, et surveiller le coût avec des limites de longueur et de débit. Les erreurs se gèrent avec réessai et attente croissante (backoff exponentiel : chaque délai attend le double du précédent). Comme les points de terminaison acceptent l'API d'état sans état Responses, l'historique de conversation est stocké côté client.

Avant de publier pour de vrai

Ce qui n'a pas été exécuté, c'est l'exercice final de construction et déploiement : il exige un abonnement Azure, et il est resté non exécuté ici. Le post a parcouru le chemin complet, de la définition de l'agent au point de terminaison publié. Il reste à l'essayer de bout en bout sur votre propre abonnement : construire, déployer et publier.

Trois choses valent la peine d'être vérifiées avant de dépendre d'un agent publié : faites le test du 403 avec le token et le POST de la section précédente avant d'envoyer l'URL à qui que ce soit ; vérifiez l'api-version en vigueur (2025-11-15-preview) avant de l'utiliser en production ; et n'oubliez pas de nettoyer les ressources Azure créées à la fin : c'est facile à négliger.

Mon avis

Ce qui rend un agent maintenable, c'est que sa configuration vive dans Git avec le code : vous relisez le changement comme n'importe quel diff, vous construisez des modèles, et vous pouvez revenir en arrière sans drame. La plateforme s'occupe du comportement. Ce qu'il faut planifier à l'avance, c'est la publication : la nouvelle identité n'hérite de rien. Un RBAC en retard se découvre avec un 403 en production, quand il y a déjà des utilisateurs qui attendent.

---

*Source : le module « Develop AI agents with Microsoft Foundry and Visual Studio Code » de Microsoft Learn.*