06 · Construire des agents avec Microsoft Foundry

Version : 1.1 · Date : 2026-10-21 · Domaine 2 de l'examen : Implement generative AI and agentic solutions (30 à 35 %)

En une phrase : un agent Foundry est un model, des instructions et des tools, versionné, exposé par un endpoint stable et doté de sa propre identité Microsoft Entra ; on le relie à des connaissances et à des API, on l'orchestre avec d'autres agents, on encadre ses actions par des approbations, puis on le trace et on l'évalue en continu.

Ce que l'examen demande#

Bloc Build agents by using Foundry, repris mot pour mot du guide d'étude AI-103 (compétences mesurées au 16 avril 2026) :

Le choix des tools, de la memory et des knowledge est posé au chapitre 01 (sections 3 et 5) ; basic et standard agent setup, réseau et CI/CD sont au chapitre 02 ; guardrails et évaluations de sécurité au chapitre 04 ; le RAG côté application au chapitre 05. L'identité des agents côté sécurité (Microsoft Entra Agent ID, Conditional Access) est détaillée dans SC-500, chapitre 07.

1. Les bases d'un agent Foundry#

1.1 Les trois types d'agents et l'agent « éphémère »#

Foundry Agent Service propose trois types d'agents ; le choix fixe ce que vous construisez et ce que Foundry gère :

Quatrième voie : appeler directement la Responses API depuis votre code. C'est un agent éphémère : sa définition (instructions, tools, model) vit dans votre application, versionnée avec elle, sans ressource agent dans Foundry.

Les hosted agents sont GA. Points à connaître : image linux/amd64 obligatoire ; protocoles Responses (/responses), Invocations (/invocations, webhooks, charges non conversationnelles), Invocations WebSocket (voix) et A2A ; $HOME et /files persistés entre les tours (scale-to-zero avec reprise d'état) ; une agent identity Entra dédiée créée au déploiement ; la managed identity du project sert seulement à l'infrastructure (par exemple tirer l'image de Container Registry). Déploiement par Azure Developer CLI (azd), le SDK ou REST.

1.2 Agent, conversation, response#

Ce vocabulaire remplace celui des agents classic et de l'Assistants API : threads → conversations, runs → responses, messages → items. Les agents classic sont dépréciés et seront retirés le 31 mars 2027. Dans le SDK Python, la création et les versions d'agents passent par le project client (AIProjectClient) ; conversations et responses par le client OpenAI obtenu avec project.get_openai_client().

from azure.identity import DefaultAzureCredential
from azure.ai.projects import AIProjectClient
from azure.ai.projects.models import PromptAgentDefinition

# Endpoint du project : https://<resource>.services.ai.azure.com/api/projects/<project>
project = AIProjectClient(endpoint="<project-endpoint>", credential=DefaultAzureCredential())
openai = project.get_openai_client()

# Chaque create_version crée une nouvelle version immuable de l'agent
agent = project.agents.create_version(
    agent_name="support-it",
    definition=PromptAgentDefinition(
        model="gpt-5-mini",
        instructions="Tu es l'assistant du support IT de Contoso. Réponds en français, en trois phrases au plus.",
    ),
)

conversation = openai.conversations.create()
response = openai.responses.create(
    conversation=conversation.id,
    input="Mon VPN se coupe toutes les dix minutes.",
    extra_body={"agent_reference": {"name": agent.name, "type": "agent_reference"}},
)
print(response.output_text)

1.3 Les rôles RBAC à connaître#

Les rôles Foundry ont été renommés (mêmes identifiants et mêmes permissions) : Foundry User (ex-Azure AI User), Foundry Owner, Foundry Account Owner et Foundry Project Manager (ex-Azure AI Project Manager). Il faut Foundry User sur le project pour créer et tester des agents, Foundry Project Manager pour créer une project connection (par exemple l'authentification d'un serveur MCP). Les Foundry workflows du portail demandent le rôle Contributor ou plus sur le project.

Règle Microsoft : pour Foundry, ne pas attribuer de rôle « Cognitive Services … », sauf Cognitive Services Usages Reader au niveau de la subscription pour voir les quotas ; ne pas utiliser Azure AI Developer (prévu pour les hubs et Azure Machine Learning). Exceptions documentées service par service : appels directs à un Foundry Tool (Speech, Language, Translator…) et certains skills d'Azure AI Search, qui citent encore des rôles Cognitive Services (chapitres 09 et 10).

2. Rôle, objectifs, suivi de conversation et tool schemas#

2.1 Écrire les instructions : rôle, objectifs, limites#

Les instructions sont le premier levier de qualité. Une bonne structure :

Les structured inputs rendent une définition réutilisable : un paramètre {{nom}} dans les instructions ou dans la configuration d'un tool (filtre Azure AI Search, fichier pour Code Interpreter, en-tête d'un MCP tool) est fourni à chaque requête par extra_body={"structured_inputs": {...}}.

2.2 Choisir comment suivre la conversation#

Si la conversation dépasse la context window du modèle, l'entrée est tronquée automatiquement : la conversation n'est pas raccourcie, seul un sous-ensemble est envoyé. Une conversation très longue coûte cher en jetons ; la memory sert à garder l'essentiel sans tout renvoyer.

Dans Microsoft Agent Framework (hosted agents, agents en code), le contexte est porté par une AgentSession.

2.3 Définir les tool schemas#

Le modèle choisit un tool d'après son nom, sa description et le schéma JSON de ses paramètres. Bonnes pratiques documentées :

• nom et description explicites, descriptions des paramètres avec exemples (« The city and state, e.g. Seattle, WA ») ;
• "required": [...] pour les champs obligatoires et strict=True (avec "additionalProperties": false) pour une validation stricte des arguments ;
• éviter anyOf / allOf et les paramètres multi-types : un serveur MCP qui en contient provoque l'erreur « Invalid tool schema » ;
• pour OpenAPI, des operationId descriptifs (lettres, - et _ uniquement) et des schémas de réponse ;
• tool_choice pour un comportement déterministe : auto (le modèle décide), required (au moins un appel d'outil), none (aucun).

Un tool n'est utilisable que si le modèle et la région le prennent tous deux en charge : par exemple Code Interpreter ne fonctionne pas dans les régions qui ne le proposent pas (comme southcentralus ou spaincentral), quel que soit le modèle.

3. Retrieval, function calling et conversation memory#

3.1 Function calling : le modèle demande, votre code exécute#

Le function calling est un tool côté client : le service n'exécute jamais votre fonction. Le cycle :

1. définir un FunctionTool (nom, description, schéma) et créer la version d'agent ;
2. envoyer la question ; la réponse contient un ou plusieurs items function_call (avec call_id et arguments JSON) ;
3. votre code exécute la fonction ;
4. renvoyer chaque résultat en item function_call_output (même call_id) dans un seul appel suivant, avec la même conversation ;
5. l'agent produit la réponse finale.

import json
from azure.ai.projects.models import PromptAgentDefinition, FunctionTool
from openai.types.responses.response_input_param import FunctionCallOutput

def get_ticket_status(ticket_id: str) -> dict:
    return {"ticket_id": ticket_id, "status": "En cours", "owner": "Équipe réseau"}   # votre API réelle ici

tool = FunctionTool(
    name="get_ticket_status",
    description="Renvoie le statut d'un ticket du support IT à partir de son identifiant.",
    parameters={"type": "object",
                "properties": {"ticket_id": {"type": "string", "description": "Identifiant, par exemple INC-2041"}},
                "required": ["ticket_id"], "additionalProperties": False},
    strict=True,
)
agent = project.agents.create_version(agent_name="support-it", definition=PromptAgentDefinition(
    model="gpt-5-mini", instructions="Utilise get_ticket_status pour toute question sur un ticket.", tools=[tool]))

conversation = openai.conversations.create()
ref = {"agent_reference": {"name": agent.name, "type": "agent_reference"}}
response = openai.responses.create(conversation=conversation.id, input="Où en est INC-2041 ?", extra_body=ref)

outputs = []
for item in response.output:
    if item.type == "function_call" and item.name == "get_ticket_status":
        result = get_ticket_status(**json.loads(item.arguments))      # arguments = entrée non fiable : valider
        outputs.append(FunctionCallOutput(type="function_call_output", call_id=item.call_id, output=json.dumps(result)))

response = openai.responses.create(conversation=conversation.id, input=outputs, extra_body=ref)
print(response.output_text)

À retenir pour l'examen :

• un run expire 10 minutes après sa création : renvoyer les sorties vite ; pour une opération longue, renvoyer un statut et sonder séparément ;
• le portail sait exécuter un agent qui a des function tools mais ne sait pas ajouter, modifier ou supprimer leurs définitions : SDK ou REST ;
• dans Agent Framework, une fonction décorée @tool est appelée automatiquement par le framework ; le paramètre approval_mode="always_require" exige une approbation humaine avant chaque appel (section 6).

3.2 Retrieval : un agent qui s'ancre sur vos données#

Trois façons de donner des connaissances à un agent (le choix est détaillé au chapitre 01) :

from azure.ai.projects.models import (AzureAISearchTool, AzureAISearchToolResource, AISearchIndexResource,
                                      AzureAISearchQueryType, PromptAgentDefinition)

search = project.connections.get("search-contoso")              # project connection vers Azure AI Search
agent = project.agents.create_version(agent_name="rh-agent", definition=PromptAgentDefinition(
    model="gpt-5-mini",
    instructions="Réponds uniquement à partir de l'index et cite tes sources. Sinon, réponds « je ne sais pas ».",
    tools=[AzureAISearchTool(azure_ai_search=AzureAISearchToolResource(indexes=[
        AISearchIndexResource(project_connection_id=search.id, index_name="politiques-rh",
                              query_type=AzureAISearchQueryType.SIMPLE)]))],
))
response = openai.responses.create(input="Combien de jours de télétravail par semaine ?", tool_choice="required",
                                   extra_body={"agent_reference": {"name": agent.name, "type": "agent_reference"}})

Pour que l'agent ne renvoie que ce que l'utilisateur a le droit de lire avec Foundry IQ, le jeton de l'utilisateur est transmis par l'en-tête x-ms-query-source-authorization du MCP tool, alimenté par un structured input ({{search_auth_token}}).

3.3 Conversation memory#

• Court terme : la conversation (ou previous_response_id) garde le fil de la session (section 2.2).
• Long terme : le Memory search tool (preview) attaché à un prompt agent, avec un scope par utilisateur ; la memory est extraite et consolidée après une période d'inactivité (update_delay, 300 secondes par défaut dans l'exemple officiel). Pas d'intégration VNet pour les memory stores ; risque d'empoisonnement de la memory par injection d'invite (chapitre 01, 5.3).

4. Intégrer les tools d'un agent#

4.1 Ce qui a changé avec la nouvelle Agent Service#

4.2 La toolbox : la méthode recommandée#

Une toolbox regroupe Web search, Code Interpreter, File search, Azure AI Search, MCP, OpenAPI et A2A derrière un seul endpoint compatible MCP, consommable par n'importe quel runtime. L'agent s'y connecte comme à un serveur MCP (server_url, server_label), la toolbox gère l'authentification (injection des identifiants, rafraîchissement des jetons) et les versions : on teste une version sur son endpoint dédié, puis on la promeut par défaut ; les agents de production utilisent l'endpoint consommateur ({project_endpoint}/toolboxes/{name}/mcp?api-version=v1).

4.3 MCP : brancher un serveur distant#

from azure.ai.projects.models import PromptAgentDefinition, MCPTool

tool = MCPTool(
    server_label="github",                          # unique dans l'agent
    server_url="https://api.githubcopilot.com/mcp",
    require_approval="always",                      # valeur par défaut : approbation à chaque appel
    allowed_tools=["get_me", "list_issues"],        # liste blanche ; sans elle, tous les outils du serveur
    project_connection_id="github-mcp-conn",        # identifiants stockés dans une project connection
)
agent = project.agents.create_version(agent_name="dev-agent", definition=PromptAgentDefinition(
    model="gpt-5-mini", instructions="Utilise les outils GitHub au besoin.", tools=[tool]))

4.4 OpenAPI, A2A, Content Understanding, Logic Apps#

• OpenAPI (3.0 ou 3.1) : trois authentifications : anonymous, API key (project connection + sections securitySchemes et security dans la spécification ; pour un bearer token, valeur Bearer <jeton>) et managed identity (rôle data-plane minimal donné à l'identité du project sur la cible, et audience correcte : https://storage.azure.com, https://vault.azure.net, https://search.azure.com, ou l'Application ID URI d'une app registration ; un 401 avec rôle attribué vient souvent d'une mauvaise audience).
• Agent-to-Agent (A2A) : appeler un agent compatible A2A, Foundry ou non. Le tool a2a (protocole A2A 1.0) est GA ; a2a_preview (0.3) reste en preview. Pour exposer votre agent, activer le protocole A2A et une agent card sur son endpoint (REST ou SDK, pas encore dans le portail) ; un agent hébergé ailleurs peut être enregistré dans Foundry Control Plane, qui découvre sa card à /.well-known/agent-card.json.
• Content Understanding : transforme documents, images, audio et vidéo en Markdown et en champs avec scores de confiance. Dans Foundry, le Content Understanding Tool sert dans les workflows d'agents ; dans Agent Framework, un context provider (preview) analyse automatiquement les pièces jointes avant chaque appel du modèle (analyseurs par défaut prebuilt-documentSearch, prebuilt-audioSearch, prebuilt-videoSearch). Détails au chapitre 10.
• Azure Logic Apps (preview) : un workflow Logic Apps peut appeler un agent Foundry, le lancer de façon autonome sur un déclencheur (événement, planification) et exposer ses actions, parmi plus de 1 400 connecteurs, comme tools ; utile pour les processus longs, les rappels et les approbations humaines.
• Code Interpreter, Web search, Browser automation, Computer use : voir le tableau ci-dessus ; les citations de Grounding with Bing doivent être affichées telles que fournies.

5. Solutions multi-agents orchestrées#

5.1 Trois façons de faire travailler des agents ensemble#

Conseil de Microsoft : commencer par des agents uniques fiables, puis les orchestrer. Ne pas ajouter d'agents qui n'apportent pas de spécialisation réelle : chaque saut ajoute latence et jetons.

5.2 Les cinq motifs d'orchestration#

flowchart TD
    A["Plusieurs agents nécessaires ?"] -- Non --> S["Un seul agent avec tools"]
    A -- Oui --> B{"L'ordre des étapes<br/>est-il connu ?"}
    B -- "Oui, fixe" --> SEQ["Sequential"]
    B -- "Non" --> C{"Les sous-tâches sont-elles<br/>indépendantes ?"}
    C -- Oui --> CON["Concurrent"]
    C -- Non --> D{"Un seul spécialiste<br/>à la fois suffit ?"}
    D -- Oui --> HO["Handoff"]
    D -- Non --> E{"Faut-il construire<br/>un plan dynamique ?"}
    E -- Oui --> MAG["Magentic"]
    E -- Non --> GC["Group chat"]

Exemple Agent Framework : une orchestration sequential exposée comme un agent (et donc déployable en hosted agent) :

from agent_framework.foundry import FoundryChatClient
from agent_framework.orchestrations import SequentialBuilder
from azure.identity import AzureCliCredential

client = FoundryChatClient(project_endpoint="<project-endpoint>", model="gpt-5-mini", credential=AzureCliCredential())
redacteur = client.as_agent(name="Redacteur", instructions="Rédige une note de changement à partir de la demande.")
relecteur = client.as_agent(name="Relecteur", instructions="Vérifie les risques et produis la version finale.")

workflow = SequentialBuilder(participants=[redacteur, relecteur]).build()
agent_pipeline = workflow.as_agent(name="Pipeline de changement")   # un workflow vu comme un agent

Coûts : sequential et handoff accumulent les appels un par un ; concurrent provoque des pics ; magentic est le plus variable. Donner à chaque agent le modèle adapté à sa tâche (un petit modèle pour classer ou extraire), suivre les jetons par agent et compacter le contexte entre agents. Appliquer les guardrails à plusieurs points : entrée, tool calls, tool responses, sortie (chapitre 04).

6. Workflows autonomes ou semi-autonomes, garde-fous et approbations#

6.1 Où placer le curseur d'autonomie#

Pour chaque étape, se demander qui décide : le modèle (étape agent), le code (étape déterministe, règles métier) ou un humain (porte d'approbation). La plupart des systèmes réels sont au milieu : un workflow fixe la structure, les agents interviennent là où le raisonnement apporte quelque chose.

6.2 L'approbation d'un appel MCP#

require_approval accepte always (valeur par défaut), never, {"never": [outils]} ou {"always": [outils]}.

from openai.types.responses.response_input_param import McpApprovalResponse

response = openai.responses.create(conversation=conversation.id, input="Ferme le ticket INC-2041.",
                                   extra_body={"agent_reference": {"name": agent.name, "type": "agent_reference"}})
approvals = []
for item in response.output:
    if item.type == "mcp_approval_request":
        # Afficher serveur, outil et arguments à un humain ; ici une règle simple pour l'exemple
        ok = item.server_label == "itsm" and getattr(item, "name", "") == "close_ticket"
        approvals.append(McpApprovalResponse(type="mcp_approval_response", approve=ok, approval_request_id=item.id))

response = openai.responses.create(input=approvals, previous_response_id=response.id,   # suite de la même réponse
                                   extra_body={"agent_reference": {"name": agent.name, "type": "agent_reference"}})

sequenceDiagram
    actor U as Utilisateur
    participant A as Agent (Foundry)
    participant H as Approbateur (votre UX)
    participant M as Serveur MCP
    U->>A: « Ferme le ticket INC-2041 »
    A-->>H: mcp_approval_request (serveur, outil, arguments)
    H->>A: mcp_approval_response approve=true, previous_response_id
    A->>M: close_ticket(INC-2041) avec les identifiants de la connexion
    M-->>A: Résultat
    A-->>U: « Ticket fermé » (réponse finale)

Bonnes pratiques officielles : liste blanche allowed_tools, approbation pour tout outil qui écrit ou modifie des données, relecture du nom et des arguments avant d'approuver, revue des réglages quand le serveur ou ses outils changent, journalisation des approbations et des appels. Une approbation peut être ciblée sur des outils précis : les actions à faible risque restent autonomes, seules les opérations sensibles attendent un humain.

6.3 Les autres garde-fous d'un agent autonome#

• Identité à privilège minimum : l'agent agit avec son identité Entra ; ne lui donner que les rôles nécessaires, sur les seules ressources nécessaires ; pas de secrets dans les instructions, l'historique ou les sorties d'outils (utiliser des connections et Key Vault).
• Guardrails : content filters et Prompt Shields sur l'entrée, les tool calls, les tool responses et la sortie, contre l'injection d'invite indirecte (XPIA) (chapitre 04).
• Travaux longs : background mode (background=True, puis sonder responses.retrieve jusqu'à completed) ; workflows durables avec checkpoints ; déclencheurs Logic Apps pour les agents qui réagissent à des événements.
• Réseau : réseau privé pour les prompt agents, BYO VNet pour les hosted agents (chapitre 02, chapitre 03).

7. Surveiller, évaluer et analyser les erreurs#

7.1 Le tracing#

Le tracing est GA pour les prompt agents et les hosted agents (preview pour les workflows et les agents externes). Il s'appuie sur OpenTelemetry et stocke la télémétrie dans l'Application Insights connecté au project ; il faut le rôle Log Analytics Reader pour lire traces et tableaux de bord. Les conventions sémantiques GenAI (statut Development) définissent les spans invoke_agent, invoke_workflow, plan, execute_tool, les opérations de memory et des attributs comme gen_ai.tool.call.arguments et gen_ai.tool.call.result.

Les traces contiennent invites, arguments et résultats : masquer les données personnelles et les secrets avant qu'ils n'atteignent la télémétrie, appliquer les mêmes contrôles d'accès et la même rétention qu'aux journaux de production.

7.2 Les agent evaluators#

Les agent evaluators renvoient Pass/Fail avec une explication ; ceux qui notent de 1 à 5 (comme intent_resolution et tool_call_accuracy) ajoutent un score, avec un seuil de 3. Ce sont des juges LLM : il faut un model deployment pour les exécuter.

from azure.ai.projects.models import TestingCriterionAzureAIEvaluator

criteres = [
    TestingCriterionAzureAIEvaluator(type="azure_ai_evaluator", name="Intent Resolution",
        evaluator_name="builtin.intent_resolution", initialization_parameters={"model": "gpt-5-mini"},
        data_mapping={"query": "{{item.query}}", "response": "{{sample.output_items}}"}),
    TestingCriterionAzureAIEvaluator(type="azure_ai_evaluator", name="Task Adherence",
        evaluator_name="builtin.task_adherence", initialization_parameters={"model": "gpt-5-mini"},
        data_mapping={"query": "{{item.query}}", "response": "{{sample.output_items}}"}),
]
evaluation = openai.evals.create(name="eval-support-it",
                                 data_source_config={"type": "custom", "include_sample_schema": True,
                                                     "item_schema": {"type": "object", "properties": {"query": {"type": "string"}},
                                                                     "required": ["query"]}},
                                 testing_criteria=criteres)
# Le run cible l'agent : data_source de type "azure_ai_target_completions" avec target {"type": "azure_ai_agent", "name": ...}
# ("version" est facultatif : sans lui, c'est la dernière version de l'agent qui est évaluée)

On peut évaluer un jeu de données contre l'agent, des réponses existantes par leur response_id, ou des traces de production (preview), et intégrer l'évaluation comme porte de qualité dans GitHub Actions ou Azure DevOps.

7.3 Surveiller en production et analyser les erreurs#

• Agent Monitoring Dashboard (preview, onglet Monitor de l'agent) : jetons, latence, run success rate, scores d'évaluation, résultats de red teaming. Repères de la doc : une latence au-dessus de 10 secondes évoque du throttling, des tools complexes ou le réseau ; un taux de réussite sous 95 % mérite une enquête.
• Recurring evaluations : scheduled evaluation (planifiée, sur un dataset de référence) ou continuous evaluation (échantillonne le live traffic, aléatoire ou intelligent sampling) ; plus red team scans et alerts (latence, jetons, scores, findings).
• Analyse d'erreurs : ouvrir la trace d'un run en échec (quel tool, quels arguments, quelle réponse), utiliser la cluster analysis pour regrouper les échecs par motif, transformer des traces en dataset de régression, corriger les instructions ou les tools, réévaluer et comparer les runs jusqu'au seuil voulu. L'agent optimizer (preview) propose de meilleures instructions, descriptions d'outils et choix de modèle à partir d'évaluations.
• Un agent qui tourne hors de Foundry peut être enregistré dans Foundry Control Plane et envoyer ses traces OpenTelemetry au même Application Insights pour bénéficier des mêmes évaluations continues.

8. Versions, endpoint, identité et publication#

8.1 Le modèle actuel#

• Agent version : instantané immuable ; toute modification (même une ligne d'instructions) crée une version. Une modification non enregistrée en version est temporaire : pas de comparaison ni d'évaluation complète possible.
• Agent endpoint : URL stable, active dès la création de l'agent ; elle ne change pas quand de nouvelles versions arrivent.
• version_selector : Always use latest (défaut, 100 % du trafic vers la dernière version) ou pinned (une version fixe, recommandé en production et quand l'agent est publié dans Teams ou Microsoft 365).
• Protocoles de l'endpoint : Responses (activé par défaut), A2A, Activity (Microsoft 365), Invocations ; authorization Entra par défaut ; une agent card décrit l'agent aux consommateurs A2A.
• Identité : un agent créé avec le nouveau modèle reçoit par défaut son propre agent blueprint et sa propre agent identity Microsoft Entra Agent ID.
• Publier signifie désormais diffuser l'endpoint vers Microsoft 365 Copilot et Teams.

8.2 L'ancien modèle (encore cité)#

Avant cette évolution, les agents non publiés d'un project partageaient une identité et un blueprint ; publier créait une Agent Application (ressource Azure, avec sa propre RBAC, sa stable URL, son identité distincte, gouvernable par Azure Policy) et un Deployment (démarrable et arrêtable) qui routait 100 % du trafic vers une version. Points d'examen : les permissions données à l'identité du project ne suivent pas l'agent publié (les réattribuer à la nouvelle identité) ; pour appeler l'application, il faut le rôle Foundry User sur la ressource Agent Application (sinon 403 Forbidden). Les Agent Applications existantes continuent de fonctionner.

9. Labs conseillés#

Dans un abonnement de test, avec une Foundry resource, un project et un model deployment gpt-5-mini (ou équivalent). Coût : surtout les jetons ; Azure AI Search et Application Insights selon leur niveau ; supprimer le groupe de ressources à la fin.

1. Premier prompt agent et conversation
   1. Créer l'agent du code 1.2, poser deux questions dans la même conversation.
   2. Refaire avec previous_response_id, puis avec store=False en renvoyant l'historique.
   3. Attendu : la deuxième réponse tient compte de la première dans les trois cas ; avec store=False, rien n'est visible côté service.
2. Function calling
   1. Exécuter l'exemple de la section 3.1.
   2. Ne pas renvoyer la sortie de fonction, observer la réponse.
   3. Attendu : un item function_call avec call_id ; sans function_call_output, aucune réponse finale.
3. Agent RAG avec Azure AI Search puis Foundry IQ
   1. Créer un index (Import data, vectorisation) sur quelques PDF et un agent avec l'Azure AI Search tool.
   2. Créer une knowledge base Foundry IQ et la brancher par un MCP tool.
   3. Attendu : réponses avec citations ; une question hors corpus donne « je ne sais pas ».
4. MCP avec approbation
   1. Brancher un serveur MCP public (par exemple Microsoft Learn, https://learn.microsoft.com/api/mcp) avec require_approval="always".
   2. Refuser une première demande, accepter la suivante.
   3. Attendu : un item mcp_approval_request ; l'appel n'a lieu qu'après approve=True.
5. Tracing et évaluation
   1. Connecter Application Insights au project, exécuter dix conversations.
   2. Ouvrir les traces (spans invoke_agent, execute_tool) puis lancer une évaluation Intent Resolution et Task Adherence.
   3. Attendu : scores et raisons par ligne ; l'onglet Monitor affiche jetons, latence et run success rate.

10. Pièges d'examen#

11. Scénarios d'entraînement#

1. Un agent de support doit consulter l'état des tickets dans l'outil ITSM interne, qui n'est pas exposé sur Internet et dispose d'une API REST décrite en OpenAPI. Les données doivent être à jour. Que choisir ?

Si l'application appelante a déjà accès à l'API : function calling, votre code appelle l'API. Si l'agent doit l'appeler lui-même : OpenAPI tool (ou serveur MCP privé) avec authentification par managed identity ou API key dans une project connection, et réseau privé si l'API n'est pas publique.

2. Un client veut que l'agent garde l'historique d'une demande commencée le lundi et reprise le jeudi, mais aussi qu'il se souvienne d'un mois à l'autre que l'utilisateur préfère les réponses courtes.

Une conversation réutilisée pour la demande (historique côté service) et la memory (Memory search tool, scope par utilisateur) pour la préférence durable.

3. Une équipe migre un agent classic qui utilisait Connected Agents pour appeler un agent de facturation. Que faire ?

Remplacer par l'A2A tool (l'agent de facturation expose un endpoint A2A et une agent card) ou par un workflow si l'enchaînement est formel ; threads et runs deviennent conversations et responses.

4. Un agent DevOps doit pouvoir lire les work items Azure DevOps librement, mais toute création ou fermeture doit être validée par un humain.

Azure DevOps MCP Server depuis le catalogue Add Tools (choisir le sous-ensemble d'outils exposés, équivalent de allowed_tools), et require_approval sous la forme {"always": [<outils d'écriture>]} : les outils de lecture restent autonomes, ceux qui créent ou modifient attendent une validation ; approbations journalisées.

5. Un processus de revue de contrat enchaîne extraction des clauses, analyse juridique et rédaction d'un avis, toujours dans cet ordre ; le juriste doit valider l'analyse avant la rédaction, et le processus doit reprendre après un redémarrage.

Orchestration sequential dans Microsoft Agent Framework, with_request_info sur l'agent d'analyse (porte humaine), checkpoints pour reprendre, déployée en hosted agent.

6. Un service client reçoit des demandes très variées ; un premier agent doit traiter les cas simples et transmettre les problèmes de facturation ou techniques au bon spécialiste, voire à un humain.

Motif handoff : agent de triage, agents spécialisés, escalade vers un humain ; prévoir de quoi éviter les boucles de transfert.

7. Après une mise à jour des instructions, le taux de réussite des runs passe de 98 % à 89 % et les utilisateurs se plaignent de réponses hors sujet. Comment analyser ?

Ouvrir l'Agent Monitoring Dashboard, inspecter les traces des runs en échec (tool appelé, arguments, résultat), lancer une cluster analysis, comparer les évaluations Intent Resolution et Task Adherence entre l'ancienne et la nouvelle version, puis pinner l'ancienne version le temps de corriger.

8. Un agent en production est publié dans Teams ; l'équipe crée chaque semaine de nouvelles versions de test. Les utilisateurs voient parfois des comportements non validés. Pourquoi ?

Le version_selector est resté sur Always use latest : chaque nouvelle version est servie. Passer en pinned sur la version validée.

9. Un agent doit interroger un serveur MCP hébergé dans un VNet d'entreprise, sans exposition publique.

Standard agent setup avec réseau privé (BYO VNet), sous-réseau MCP dédié délégué à Microsoft.App/environments, serveur sur Azure Container Apps en ingress interne.

10. Une équipe veut mesurer avant chaque mise en production que l'agent choisit les bons outils avec les bons paramètres.

Une évaluation sur un dataset de référence avec Tool Call Accuracy (et Tool Selection, Tool Input Accuracy), lancée dans le pipeline (GitHub Actions ou Azure DevOps) comme porte de qualité ; en production, continuous evaluation sur le live traffic.

12. Pour aller plus loin#

• Voice-based prompt agents (preview) : architecture speech-to-speech native (faible latence) ou cascadée (reconnaissance, modèle texte, synthèse) ; canaux téléphoniques Teams Phone et Twilio (chapitre 09).
• Tools governance with AI Gateway (preview) : routage et politiques centralisés pour les outils MCP (voir la passerelle IA d'API Management, SC-500, chapitre 07).
• Foundry Control Plane : inventaire et gouvernance d'un parc d'agents, y compris des agents hébergés ailleurs.
• Microsoft Foundry Toolkit for Visual Studio Code : Agent Builder, Agent Inspector pour déboguer un workflow local, tracing local.
• AI agent orchestration patterns (Centre des architectures Azure) : variantes et antipatterns (complexité inutile, état mutable partagé entre agents concurrents, motif non déterministe pour un processus déterministe).

13. Fiche à retenir#

• Trois types : prompt agent (déclaratif), voice-based prompt agent (preview), hosted agent (votre code, GA) ; plus l'agent éphémère par la Responses API.
• Agent (versionné) + conversation (items) + response ; threads/runs/messages = classic, retrait le 31/03/2027.
• Project client pour les agents, client OpenAI pour conversations et responses.
• Rôles renommés : Foundry User, Foundry Owner, Foundry Account Owner (déploie), Foundry Project Manager (projects, connections) ; Foundry Agent Consumer pour seulement appeler un agent ; pas de rôle Cognitive Services sauf Usages Reader.
• Instructions = rôle, objectif, règles d'usage des tools, limites, format ; structured inputs {{param}}.
• Suivi : conversation, previous_response_id, store=false, memory ; entrée tronquée si trop longue.
• Tool schemas : descriptions claires, required, strict=True ; pas d'anyOf/allOf côté MCP ; tool_choice auto, required, none.
• Function calling = côté client ; function_call → function_call_output (même call_id) ; run expiré après 10 min.
• Retrieval : Foundry IQ (MCP, ACL), Azure AI Search tool (index existant), File search (fichiers de la conversation).
• Toolbox : un endpoint MCP, auth et versions centralisées ; endpoint consommateur en production.
• MCP : require_approval always par défaut, allowed_tools, serveur distant seulement, 100 s sans background mode, privé = standard setup + sous-réseau MCP.
• OpenAPI : anonymous, API key, managed identity (bonne audience) ; operationId en lettres, -, _.
• A2A GA (1.0) ; Connected Agents retiré de la nouvelle Agent Service ; Azure Functions tool = files d'attente (input / output, CorrelationId), standard setup, rôle Storage Queue Data Contributor pour l'identité du project et celle de la function app.
• Motifs : sequential, concurrent, handoff, group chat, magentic ; Foundry workflows retirés le 01/12/2026 → Agent Framework.
• Garde-fous : approbations MCP, approval_mode, request info, checkpoints, privilège minimum, guardrails à chaque point.
• Tracing GA (prompt et hosted agents), OpenTelemetry vers Application Insights, spans invoke_agent, execute_tool.
• Evaluators : Intent Resolution, Task Adherence, Task Completion, Tool Call Accuracy (et outils) ; Pass/Fail, seuil 3.
• Production : Agent Monitoring Dashboard, continuous ou scheduled evaluation, cluster analysis, traces → dataset.
• Versions immuables, endpoint stable, version_selector latest ou pinned ; publier = diffuser vers M365/Teams.

Références#

Toutes lues le 21/10/2026 sur Microsoft Learn :

• Guide d'étude de l'examen AI-103 (en anglais)
• Agents in Microsoft Foundry
• Build with agents, conversations, and responses
• Use function calling with Microsoft Foundry agents
• Tool best practices for Microsoft Foundry Agent Service
• Connect agents to Model Context Protocol servers
• Connect agents to OpenAPI tools
• Connect to an A2A agent endpoint from Foundry Agent Service
• Enable incoming A2A on a Foundry agent
• Azure AI Search tool
• Structured inputs
• Connect a Foundry IQ knowledge base to an agent
• Memory in Foundry Agent Service (usage)
• Migrate to the new agents developer experience
• What are hosted agents?
• Deploy a hosted agent
• Build a workflow in Microsoft Foundry (preview)
• Microsoft Agent Framework : workflow orchestrations
• Microsoft Agent Framework : human-in-the-loop
• Microsoft Agent Framework : workflows as agents
• AI agent orchestration patterns
• Automate Microsoft Foundry agents with workflows in Azure Logic Apps (preview)
• Use Content Understanding with the Microsoft Agent Framework
• Agent tracing overview
• Monitor agents with the Agent Monitoring Dashboard
• Built-in evaluators reference
• Agent evaluators
• Evaluate your AI agents
• Agent development lifecycle
• Configure and share your agent
• Migrate from agent applications to the new agent endpoint and publishing experience
• Publish your agent as an Agent Application
• Agent identity concepts in Microsoft Foundry