02 · Spécifier les composants techniques d'une solution multi-agents

Version : 1.1 · Date : 2026-10-22 · Domaine 1 : Architect multi-agent solutions (15–20 %)

En une phrase : une fois l'architecture logique posée, l'architecte choisit les briques Azure qui la portent : intégration (A2A, MCP, Foundry IQ, AI gateway), identité et Zero Trust par agent (Entra Agent ID), état sur trois niveaux (session, équipe, mémoire), compute (Agent Service, Container Apps, Functions, AKS), observabilité et monitoring capables de rejouer et de remédier, et un environnement de développement reproductible.

Ce que l'examen demande#

Bloc Specify technology components to include in a multi-agent solution, repris mot pour mot du guide d'étude AI-500 (examen en bêta, guide relu le 22/10/2026) :

Ce chapitre spécifie : il dit quelle brique choisir et pourquoi. La mise en œuvre détaillée est ailleurs : architecture logique au chapitre 01, prompts, mémoire et connaissances au chapitre 03, outils et MCP au chapitre 04, orchestration au chapitre 05, évaluation et observabilité au chapitre 06, sécurité et déploiement au chapitre 07. Les bases Foundry (types d'agents, RBAC, tools, tracing) sont supposées acquises : AI-103, chapitre 06.

1. Le plan de composants d'une solution multi-agents#

1.1 Spécifier par couches#

Une solution multi-agents de production se décrit en sept couches, une par compétence de l'examen. Pour chacune, l'architecte fixe le composant, sa configuration critique et la règle de gouvernance associée.

1.2 Managé ou code-first : la première décision#

L'architecture de référence Microsoft Build a multiple-agent workflow automation solution by using Microsoft Agent Framework (citée par le guide) pose l'alternative qui structure tout le reste :

• Code-first : le code Agent Framework orchestre les agents, il tourne dans Azure Container Apps (orchestrateur central), l'état des plans et des résultats est dans Azure Cosmos DB, les images dans Azure Container Registry, le front sur App Service ; contrôle maximal du comportement, de l'orchestration et du scaling.
• Managé : les agents sont définis dans Foundry Agent Service et reliés individuellement aux connaissances et outils ; pas de contrôle du compute. À choisir si l'orchestration n'a pas besoin d'être déterministe, si un system prompt suffit et si les outils sont joignables en HTTPS.
• Hybride (recommandé par l'article quand les besoins sont mixtes) : Agent Service pour les workflows standards, Container Apps pour les processus critiques ou très spécifiques.

Depuis, les hosted agents (GA) comblent une partie de l'écart : votre code Agent Framework, LangGraph ou autre, hébergé par Foundry avec identité, scaling et état de session gérés (section 5.2).

2. Les composants d'intégration#

Trois flux, trois protocoles, un point de gouvernance commun :

2.1 Agent-to-agent : A2A#

• Appeler un agent distant : l'A2A tool. Le type a2a (protocole A2A 1.0) est GA ; a2a_preview (A2A 0.3) reste en preview pour les intégrations existantes. L'agent Foundry garde la main sur la conversation : il reçoit la réponse de l'agent distant et l'utilise pour répondre.
• Exposer son agent : l'endpoint d'un agent Foundry accepte le protocole A2A (en plus de Responses, Activity, Invocations) et publie une agent card (skills, authentification, URL).
• Méthode recommandée : mettre l'A2A tool dans une toolbox, attachée à l'agent comme un MCP tool ; credentials, versions et politiques sont alors centralisés.
• Authentification : connexion de catégorie RemoteA2A avec le type AgenticIdentityToken (l'agent identity obtient un jeton pour l'audience de l'agent distant), ou clé, ou OAuth selon l'endpoint.
• Connected Agents n'existe plus dans la nouvelle Agent Service : A2A le remplace (AI-103, 4.4).

API Management comme médiateur A2A (Import an A2A agent API, tous les tiers sauf Consumption) : il relaie les opérations JSON-RPC vers le backend, applique les policies (throttling, authentification), réécrit l'agent card (nom d'hôte APIM, transport JSON-RPC, exigence de subscription key) et, avec Application Insights, ajoute les attributs OpenTelemetry genai.agent.id et genai.agent.name : c'est la base du suivi de coordination entre agents (section 7.1).

2.2 Agent-to-tool : toolbox, MCP et AI gateway#

• La toolbox regroupe MCP, OpenAPI, A2A et autres outils derrière un seul endpoint MCP versionné : un agent prompt, un hosted agent ou n'importe quel client MCP l'utilise de la même façon. Détails au chapitre 04.
• Les serveurs MCP maison tournent sur Container Apps ou Functions (les serveurs stdio locaux ne sont pas acceptés par l'Agent Service) ; API Management sait aussi exposer une API REST comme serveur MCP ou faire passer un serveur MCP existant.
• Govern MCP tools by using an AI gateway (preview) : une fois une instance API Management reliée au Foundry resource, les nouveaux MCP tools créés dans le portail (sans managed OAuth) passent par le gateway : rate limit, filtrage IP, correlation ID, suppression d'en-têtes sensibles, routage. Limites à connaître :
  • seulement les MCP tools : pas SharePoint, pas les MCP code-first, pas OpenAPI, pas le managed OAuth ;
  • le routage est fixé à la création du tool : un tool existant n'est pas migré ;
  • les policies s'écrivent dans le portail Azure (API Management), pas dans le portail Foundry ;
  • le gateway ne journalise pas les traces d'outil : métriques et logs API Management d'un côté, logs du serveur MCP de l'autre.

<!-- Policy inbound API Management sur un MCP tool gouverné : quota par IP et correlation ID pour relier les logs -->
<inbound>
  <base />
  <rate-limit-by-key calls="60" renewal-period="60" counter-key="@(context.Request.IpAddress)" />
  <set-header name="X-Correlation-Id" exists-action="override">
    <value>@(context.RequestId)</value>
  </set-header>
</inbound>

L'AI gateway sert aussi aux modèles (token quotas, rate limits) et aux agents hébergés ailleurs, enregistrés dans le Foundry Control Plane pour l'inventaire et la télémétrie. Stratégies APIM détaillées : SC-500, chapitre 07, section 7 et AKS, 8.1.

2.3 Agent-to-knowledge : router vers les sources#

Le routage vers la bonne source de connaissances ne se code plus à la main dans chaque agent : on le délègue à une knowledge base Foundry IQ (agentic retrieval). Un LLM planifie la requête, lance des sous-requêtes en parallèle sur plusieurs knowledge sources (index Azure AI Search, Blob, OneLake, SharePoint, web) et renvoie des chunks avec citations et ACL appliquées. Plusieurs agents peuvent partager la même knowledge base, connectée en MCP. Le choix entre File search, Azure AI Search tool, Foundry IQ et Memory est au chapitre 03.

Règle d'architecte : un agent spécialiste par domaine de connaissance si les droits ou la qualité diffèrent fortement ; une knowledge base partagée si les mêmes sources et les mêmes ACL servent plusieurs agents.

2.4 Quel composant d'intégration choisir#

3. Les composants Zero Trust#

Les trois principes Zero Trust appliqués aux agents : vérifier explicitement (chaque agent a sa propre identité et s'authentifie sans secret), privilège minimum (rôles au plus juste, sur des ressources précises), supposer la compromission (un agent compromis ne doit pas pouvoir rebondir).

3.1 Une identité par agent#

Microsoft Entra Agent ID ajoute des objets dédiés aux agents (SC-500, 5.1) :

Statut au 22/10/2026 : Microsoft Entra Agent ID est en preview ; étendre les fonctions de sécurité Entra (Conditional Access, ID Protection…) aux agents demande une licence Microsoft Agent 365. Foundry crée et gère ces objets pour vous.

Points d'architecture souvent testés :

• Azure RBAC ne se pose pas sur un blueprint : attribuer les rôles Azure directement à chaque agent identity ; les permissions déclarées sur le blueprint (Graph, par exemple) ne sont effectives qu'après consentement d'un administrateur.
• Un blueprint commun permet d'agir en une fois sur tous les agents d'un même type (Conditional Access, révocation, désactivation).
• Dans les journaux, on distingue blueprint, agent identity et agent's user account ; en OBO, l'utilisateur est le sujet et l'agent l'acteur ; en service-to-service, l'agent identity est le sujet.
• Dans Foundry : avec le nouveau modèle d'agent, chaque agent (prompt ou hosted) reçoit dès sa création son propre blueprint et sa propre agent identity (instance_identity) ; publier ne la change plus. Dans l'ancien modèle Agent Application (legacy, toujours servi, dépréciation planifiée), les agents non publiés partagent l'identité du project et publier crée une identité distincte dont les rôles sont à réattribuer. Dans les deux cas, l'identité partagée est un blast radius plus large (AI-103, section 8).
• Inventaire : Entra admin center > Entra ID > Agent ID > All agent identities ; Conditional Access, ID Protection, governance (expiration, owners, sponsors).

# Rôle au plus juste pour l'agent identity d'un hosted agent (principal ID lu dans la définition de l'agent)
az role assignment create \
  --assignee-object-id "<agent-identity-principal-id>" \
  --assignee-principal-type ServicePrincipal \
  --role "Storage Blob Data Reader" \
  --scope "/subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.Storage/storageAccounts/<compte>"

--assignee-object-id avec --assignee-principal-type ServicePrincipal évite les échecs de recherche Graph sur les service principals d'agents. Les rôles de données Cosmos DB (Built-in Data Reader) se posent avec az cosmosdb sql role assignment create, pas az role assignment create.

3.2 Empêcher le mouvement latéral#

Le risque est décrit dans le Microsoft cloud security benchmark v2, AI-4 : Apply least privilege for agent functions : une fonction ou un plugin d'agent trop permissif permet l'élévation de privilèges, l'accès à des données hors besoin et le mouvement latéral. Les contrôles à spécifier :

Points réseau à connaître : l'injection réseau se choisit à la création du Foundry resource et ne se change pas ensuite ; tous les tools ne fonctionnent pas derrière un VNet (vérifier le tableau Agent tools with network isolation) ; les private endpoints vers Cosmos DB, Storage et AI Search ne sont pas créés automatiquement. Détails : AI-103, 5.4 et chapitre 07.

3.3 Mapper les contrôles de conformité#

Pour un déploiement réglementé, l'architecte relie chaque exigence à un contrôle mesurable :

4. La persistance de l'état en trois niveaux#

4.1 Session state#

• Basic setup : état dans un stockage multitenant géré par Microsoft, séparé logiquement par project, chiffré par des clés Microsoft, non configurable.
• Standard setup : BYO Azure Storage (fichiers), Azure AI Search (vector stores) et Azure Cosmos DB for NoSQL (conversations et définitions d'agents) ; base enterprise_memory, au moins 3 000 RU/s au total. La nouvelle Agent Service utilise les conteneurs agent-definitions-v1 et run-state-v1 (les trois autres appartiennent au runtime classic). Isolation par project par défaut : le project est l'unité de partage et d'isolation.
• Hosted agents : chaque session a un $HOME persistant (conservé quand le compute est libéré après l'idle timeout, restauré à la reprise) ; idle timeout de 2 à 240 minutes (15 par défaut) ; session supprimée après 30 jours d'inactivité. Isolation par utilisateur par défaut, d'après l'identité Entra de l'appelant ; regrouper plusieurs utilisateurs dans une session revient à partager le sandbox.

4.2 Shared team state#

• Checkpoints Agent Framework : créés à la fin de chaque superstep ; ils capturent l'état des executors, les messages en attente, les requêtes et réponses en attente et le shared state. On reprend sur la même instance ou on réhydrate une nouvelle instance (même topologie, mêmes identités d'executors).
• Stockage de production : CosmosCheckpointStorage (paquet agent-framework-azure-cosmos, en préversion), clé de partition /workflow_name, authentification par managed identity recommandée.
• Durable Extension (Durable Task Scheduler) : l'exécution elle-même est durable, les étapes terminées ne sont pas rejouées après une panne, les orchestrations peuvent attendre un humain des jours sans consommer de compute.
• Le stockage des checkpoints est une frontière de confiance : ne jamais charger un checkpoint d'une source non maîtrisée.

4.3 Long-term semantic memory#

Le memory store Foundry (preview) extrait et consolide trois types de mémoire : user profile, chat summary, procedural. Côté spécification, retenir (chapitre 03 pour l'usage) :

• un memory store par agent recommandé (frontière d'accès et d'optimisation) ;
• scope : un utilisateur, une équipe ou un autre identifiant ; {{$userId}} dans le memory search tool avec l'en-tête x-memory-user-id (sinon repli sur l'identité Entra de l'appelant) ;
• écritures différées par update_delay (300 s par défaut) ; commandes directes « remember » et « forget » ;
• quotas : 100 scopes par store, 10 000 memories par scope ; pas d'intégration VNet ;
• risques : prompt injection et memory corruption (valider avec Content Safety, tester en adversarial).

# Spécification d'un memory store : ce qui est retenu, ce qui est exclu, combien de temps
from datetime import timedelta
from azure.ai.projects.models import MemoryStoreDefaultDefinition, MemoryStoreDefaultOptions

options = MemoryStoreDefaultOptions(
    chat_summary_enabled=True,
    user_profile_enabled=True,
    procedural_memory_enabled=True,
    default_ttl_seconds=timedelta(days=30),  # 0 = pas d'expiration
    user_profile_details="Avoid irrelevant or sensitive data, such as age, financials, precise location, and credentials",
)
definition = MemoryStoreDefaultDefinition(chat_model="<chat-deployment>", embedding_model="<embedding-deployment>",
                                          options=options)
store = project_client.beta.memory_stores.create(name="support-memory", definition=definition)

4.4 Cycle de vie et isolation des tenants#

Cycle de vie :

• mémoire : TTL de store (default_ttl_seconds), appliqué à toutes les entrées et réinitialisé à chaque consolidation ; le TTL ne s'applique qu'aux stores créés après son introduction ; une commande « remember » ne contourne pas le TTL ;
• sessions : idle timeout et suppression à 30 jours (hosted agents) ; sessions Durable avec TTL de nettoyage ;
• conversations et réponses stockées : purge explicite ; store=false quand rien ne doit rester côté service ;
• conformité : retention policies Purview, droit à l'oubli (supprimer les memory items d'un scope).

Isolation des tenants (guide Considerations for multitenant agentic systems) : conversations, mémoire et artefacts générés sont tous à isoler ; éviter le memory bleed (mémoire partagée entre tenants par un scope mal choisi) ; stocker des références plutôt que de recopier les données du tenant ; les identifiants de tenant sont calculés et vérifiés par du code déterministe, jamais par le modèle.

5. Les composants de compute#

5.1 Les options#

flowchart TD
    A[Nouvel agent] --> B{Instructions + tools suffisent ?}
    B -- oui --> P[Prompt agent]
    B -- non --> C{Code d'orchestration propre ?}
    C -- non --> P
    C -- oui --> D{Contrôle du runtime, du réseau ou de l'hôte exigé ?}
    D -- non --> H[Hosted agent]
    D -- oui --> E{Déclenché par événements, attentes longues ?}
    E -- oui --> F[Azure Functions + Durable Extension]
    E -- non --> G{Cluster Kubernetes ou GPU déjà en place ?}
    G -- oui --> K[AKS]
    G -- non --> CA[Azure Container Apps]

5.2 Hosted agents : ce qu'il faut savoir pour dimensionner#

• Déploiement : image dans Azure Container Registry ou archive .zip du code (Foundry construit l'image) ; à chaque déploiement, une version, une agent identity dédiée et un endpoint dédié.
• Taille par session : 0,5 vCPU / 1 GiB, 1 vCPU / 2 GiB ou 2 vCPU / 4 GiB ; disque jusqu'à 20 GiB par session à partir de 1 vCPU (environ 20 % réservés au système). Les valeurs CPU et mémoire décrivent une session, pas l'agent : la facture est CPU + mémoire de toutes les sessions actives, sur-dimensionner multiplie le coût par la concurrence.
• Scaling : par session, pas par replica ; pas de replica count ni de warm pool. Mesurer CPU, mémoire et durée dans Application Insights (Investigate > Performance) avant de choisir la taille.
• Résilience : le travail en cours survit aux interruptions de processus et les résultats streamés peuvent être rejoués à un client qui se reconnecte.
• Versions : l'endpoint envoie 100 % du trafic à une version (FixedRatio). Pour livrer sans risque : épingler la production, déployer la candidate, la tester dans une session épinglée sur la candidate, puis promouvoir à 100 % ; rollback = remettre l'ancien sélecteur. Les sessions existantes restent sur leur version.
• Réseau : registre privé (private endpoint, accès public coupé) pris en charge pour les projects créés après le 25/06/2026 ; les plus anciens exigent un registre joignable publiquement.

Écart dans la documentation (22/10/2026) : Manage hosted agents indique que la répartition du trafic entre versions n'est pas prise en charge, alors que l'article preview Promote hosted agents to production with azd décrit un déploiement progressif avec plusieurs règles FixedRatio. À l'examen, retenir : épingler, tester, promouvoir à 100 % ; un canary pondéré se fait au niveau d'un gateway devant deux agents.

5.3 Les critères de choix (Well-Architected)#

6. Les composants d'observabilité#

6.1 Corréler les traces entre services#

• OpenTelemetry partout, avec les semantic conventions GenAI (statut Development, susceptibles d'évoluer) et le W3C Trace Context : un même trace_id relie le gateway, l'orchestrateur, les agents A2A et les outils.
• Application Insights connecté au project Foundry : traces côté serveur des prompt agents, hosted agents et workflows, sans code, conservées 90 jours dans la vue Traces ; lecture avec Log Analytics Reader (plus Privileged Monitoring Data Reader si les tables sont protégées).
• Côté client (SDK) : propagation du trace context activée par défaut avec le tracing (AZURE_TRACING_GEN_AI_ENABLE_TRACE_CONTEXT_PROPAGATION), en-tête baggage désactivé par défaut (risque de fuite de PII) ; agent_reference (nom et id) dans l'appel pour rattacher la trace au bon agent ; OTEL_SERVICE_NAME pour distinguer les applications (cloud_RoleName dans les requêtes).
• Hosted agents : export configuré par variables d'environnement de la version (immuables : changer la destination = nouvelle version) ; Application Insights et un exporteur OTLP vers un autre outil peuvent fonctionner en même temps.
• API Management : X-Correlation-Id et attributs genai.agent.id / genai.agent.name sur les appels A2A.

sequenceDiagram
    participant C as Client
    participant G as AI gateway (APIM)
    participant O as Orchestrator (hosted agent)
    participant S as Specialist (A2A)
    participant T as MCP server
    participant AI as Application Insights
    C->>G: requête + traceparent
    G->>O: X-Correlation-Id, traceparent
    O->>S: A2A (JSON-RPC), même trace_id
    S->>T: execute_tool (MCP)
    T-->>S: résultat
    S-->>O: réponse
    O-->>C: réponse finale
    G--)AI: logs et métriques APIM
    O--)AI: spans invoke_agent, agent_planning
    S--)AI: spans agent_to_agent_interaction, execute_tool

6.2 Journaliser le chemin de raisonnement#

Les conventions multi-agents (contribution Microsoft et Cisco Outshift) structurent le « reasoning path » en spans et attributs, au lieu de logs texte :

Content recording (messages, arguments et résultats d'outils dans les spans) : OTEL_INSTRUMENTATION_GENAI_CAPTURE_MESSAGE_CONTENT=true, désactivé par défaut, à réserver au développement ou à un environnement dont la conformité l'autorise. Ne jamais mettre de secret dans un prompt, un argument d'outil ou un attribut de span ; traiter les traces comme des données de production (accès, rétention, coût selon le volume). Instrumentation détaillée : AI-103, 4.1 et chapitre 06.

6.3 Capturer de quoi rejouer#

« Agent replay capture » se spécifie avec plusieurs composants complémentaires :

7. Les composants de monitoring#

7.1 Suivre la coordination entre agents#

• Agent Monitoring Dashboard (onglet Monitor d'un agent) : token usage, latency (au-delà de 10 s : throttling, outils lents, réseau), run success rate (sous 95 % : enquêter), scores d'évaluation, résultats de red teaming.
• Foundry Control Plane > Operate : vue fleet de tous les agents, modèles et tools d'un abonnement, y compris des agents custom (via AI gateway) et d'autres plateformes ; santé, coût, alertes, comportements empêchés, drift.
• La coordination elle-même se lit dans les traces : spans agent_to_agent_interaction, attributs genai.agent.id posés par API Management, durée et taux d'échec par paire d'agents (requête KQL sur Application Insights).
• Agents hors Foundry : instrumentation OpenTelemetry GenAI et même Application Insights que le project pour profiter du dashboard et de la continuous evaluation.

7.2 Détecter la dérive et les régressions de qualité#

Pièges de configuration : max_hourly_runs limite les évaluations (100 par heure par défaut, au-delà elles sont ignorées) ; en SDK, la managed identity du project a besoin du rôle Foundry User ; sans trafic, pas de résultat. Les évaluators eux-mêmes (Task Adherence, Intent Resolution, Tool Call Accuracy…) : AI-103, 7.3 et chapitre 06.

7.3 Remédier automatiquement#

La remédiation se spécifie à deux niveaux :

1. Dans le code des agents (motifs d'échec connus) : retry avec backoff exponentiel sur 429 et timeouts, circuit breaker sur un outil défaillant, modèle de repli, approbation humaine sur les actions d'écriture, erreurs structurées propagées à l'orchestrateur plutôt qu'avalées (Claude Architecte, 4.1).
2. Dans la plateforme (déclenchée par une alerte Azure Monitor et son action group, vers une Logic App, une Function ou un runbook) :
   • remettre l'endpoint du hosted agent sur la version précédente (sélecteur à 100 %) ;
   • désactiver l'endpoint d'un agent pour le mettre hors ligne ; dans le Control Plane, stop (hosted, publié) ou block (agent custom : les requêtes entrantes sont refusées, l'agent continue de tourner) ;
   • durcir une policy au gateway (quota, blocage d'un tool) ;
   • ouvrir un incident vers le sponsor et l'owner de l'agent identity.

flowchart LR
    A[Alerte : run success rate sous 95 %] --> B{Nouvelle version récente ?}
    B -- oui --> C[Repinner la version précédente]
    B -- non --> D{Un tool en échec ?}
    D -- oui --> E[Circuit breaker ou blocage au gateway]
    D -- non --> F{Comportement dangereux ?}
    F -- oui --> G[Désactiver l'endpoint, stop ou block]
    F -- non --> H[Incident : sponsor et owner]
    C --> I[Réévaluer puis corriger]
    E --> I
    G --> I
    H --> I

Le Control Plane recommande aussi des corrections (prompts, version de modèle, configuration) et permet la remédiation en masse des écarts de conformité ; ces fonctions sont aujourd'hui dans le portail Foundry.

8. Les outils de développement et le SDLC#

8.1 Dev containers#

Un dev container (.devcontainer/devcontainer.json) ou GitHub Codespaces donne à toute l'équipe le même environnement : runtime, Azure CLI, azd, extensions VS Code. Les samples Microsoft (Azure-Samples, foundry-samples) en fournissent souvent un.

// .devcontainer/devcontainer.json : environnement commun de l'équipe agents
{
  "image": "mcr.microsoft.com/devcontainers/python:3.12",
  "features": {
    "ghcr.io/devcontainers/features/azure-cli:1": {},
    "ghcr.io/azure/azure-dev/azd:latest": {}
  },
  "customizations": {
    "vscode": { "extensions": ["ms-python.python"] }   // ajouter l'extension Foundry Toolkit (identifiant du Marketplace)
  },
  "postCreateCommand": "pip install -r requirements.txt && azd ext install azure.ai.agents"
}

8.2 Visual Studio Code et Foundry Toolkit#

• Microsoft Foundry Toolkit for Visual Studio Code (prérequis : runtime .NET) : ressources du project, création d'agents et de workflows à partir de samples Agent Framework, déploiement en hosted agent, tracing local.
• Agent Inspector (preview) : envoie des requêtes à l'agent local, montre l'activité du modèle et des outils, s'intègre au débogueur (debugpy en Python) et exporte des diagnostics. Il ne remplace pas les outils par des mocks : entrées de test non sensibles.
• Foundry DevPack : installation groupée de Foundry Toolkit, azd et azd ai, Foundry Canvas et Microsoft Foundry Skill.

8.3 La CLI : azd et l'extension agents#

azd ext install azure.ai.agents                     # extension agents (azd 1.23.0 ou plus)
azd ai agent init -m <url du azure.yaml d'un sample> # scaffold du projet
azd up                                              # provision (project, modèle, ACR, App Insights, identité) + deploy
azd deploy                                          # nouvelle version de l'agent seulement
azd ai agent show --output table                    # version, protocoles, ressources, variables
azd ai agent invoke                                 # tester l'agent déployé
azd ai agent monitor                                # logs de l'agent déployé
azd down --force --purge                            # nettoyage ; --purge libère le nom (soft-delete 48 h sinon)

azd deploy construit l'image à distance dans ACR par défaut (remoteBuild: false pour builder en local avec Docker), crée la version, l'agent identity et les rôles. Mode code (.zip, défaut pour Python et .NET) ou container. Pour l'infrastructure seule, Terraform est documenté (AI-103, 2.4).

8.4 Gestion des dépendances#

• Épingler les versions (requirements, fichier lock, <PackageReference> .NET) : plusieurs paquets agents sont en préversion (--pre) et changent vite ; une version non épinglée casse un agent sans changement de code.
• Résolution en mode code : dependencyResolution: remote_build (défaut, la plateforme installe) ou bundled (dépendances embarquées dans le .zip).
• Environnement isolé (venv Python, Python 3.10 minimum) ; scan des dépendances dans le pipeline.
• Piège connu : sur Windows ARM64, certains paquets (aiohttp, grpcio, cryptography, httptools) n'ont pas de wheels ; valider à distance (azd deploy puis azd ai agent invoke) ou utiliser un dev container.

# azure.yaml : hosted agent déployé depuis le code source
services:
  my-agent:
    host: azure.ai.agent
    project: src/my-agent
    kind: hosted
    codeConfiguration:
      runtime: python_3_13
      entryPoint: [python, main.py]
      dependencyResolution: remote_build

8.5 AI instructions#

« AI instructions » désigne les fichiers qui guident les assistants de code (GitHub Copilot, Claude Code…) sur le dépôt :

Ne pas confondre avec les instructions des agents eux-mêmes (system prompt), qui sont du code à versionner et à évaluer (chapitre 03), ni avec les Foundry skills (preview) injectés dans un hosted agent.

8.6 Du poste au pipeline#

1. Développer dans le dev container, tester en local avec Agent Inspector.
2. Pousser : pipeline OIDC (GitHub Actions ou Azure Pipelines), sans secret.
3. Build, tests, scan des dépendances, puis azd deploy d'une version candidate (production épinglée).
4. Porte d'évaluation (action GitHub ou tâche Azure DevOps d'évaluation Foundry) avec seuils.
5. Promotion explicite de la version testée ; conservation de la précédente pour le rollback.

9. Labs conseillés#

Abonnement de test, région prenant en charge hosted agents et memory. Coût principal : jetons, Application Insights (volume de traces), compute des sessions hosted ; supprimer le groupe de ressources à la fin (azd down --force --purge).

1. Hosted agent de bout en bout avec azd (environ 1 h)
   1. Dev container, azd ext install azure.ai.agents, azd ai agent init sur le sample Agent Framework 01-basic, azd up.
   2. Lire l'agent identity créée (azd ai agent show), lui attribuer un rôle de lecture sur un compte de stockage de test.
   3. Attendu : l'agent répond à azd ai agent invoke ; l'identité apparaît dans Entra ID > Agent ID.
2. Versions sans risque
   1. Épingler la version 1 à 100 %, déployer une version 2, l'appeler dans une session épinglée sur la version 2.
   2. Promouvoir la version 2, puis revenir à la version 1.
   3. Attendu : les nouvelles sessions suivent le sélecteur ; les sessions existantes restent sur leur version.
3. A2A et AI gateway
   1. Exposer un second agent en A2A, l'appeler depuis le premier avec l'A2A tool (dans une toolbox).
   2. Importer l'agent comme A2A agent API dans une instance API Management Developer ou Basic v2, activer Application Insights.
   3. Attendu : agent card réécrite avec le nom d'hôte APIM ; attributs genai.agent.id visibles dans les traces.
4. Traces, content recording et replay
   1. Connecter Application Insights au project, générer dix conversations, ouvrir Traces.
   2. Relancer en local avec OTEL_INSTRUMENTATION_GENAI_CAPTURE_MESSAGE_CONTENT=true et Agent Inspector ; créer un dataset depuis des traces.
   3. Attendu : spans invoke_agent et execute_tool ; contenu visible seulement avec content recording.
5. Monitoring et remédiation
   1. Créer une continuous evaluation (Task Adherence) et une alerte sur le run success rate.
   2. Brancher l'action group sur une Logic App de test qui remet l'endpoint sur la version précédente (appel REST).
   3. Attendu : l'alerte déclenche le repin ; aucune intervention humaine pour contenir.

10. Pièges d'examen#

11. Scénarios d'entraînement#

1. Une banque construit un agent d'instruction de crédit qui délègue l'analyse de risque à un agent développé par une filiale en LangGraph sur un autre cloud. La DSI veut des quotas par appelant, une authentification centralisée et la télémétrie de chaque appel inter-agents.

A2A : l'agent de la filiale expose un endpoint A2A et son agent card ; l'agent Foundry l'appelle avec l'A2A tool (dans une toolbox). L'endpoint est importé dans API Management comme A2A agent API (policies de quota et d'authentification, agent card réécrite), avec Application Insights pour genai.agent.id / genai.agent.name.

2. Vingt agents d'un même project utilisent cinq serveurs MCP internes. La sécurité exige un filtrage IP, un quota par project et l'audit des appels, sans modifier les serveurs.

Toolbox pour regrouper les outils et les credentials, et AI gateway connecté au Foundry resource (preview) : les MCP tools recréés après la connexion passent par API Management (ip-filter, rate-limit-by-key, correlation ID). Audit par les logs APIM ; les traces d'outil restent côté serveur MCP.

3. Un agent de facturation et un agent RH tournent dans le même project. Un audit montre que les deux utilisent la même identité, qui a accès aux deux bases.

Identité distincte par agent (Entra Agent ID), rôles de données sur sa base uniquement, sponsor et owner renseignés, Conditional Access for agents. Vérifier avec l'attack path analysis de Defender que le chemin RH → facturation a disparu.

4. Un assureur soumis à l'EU AI Act doit démontrer ses contrôles sur ses agents et garder les prompts sept ans.

Purview Compliance Manager avec le modèle EU Artificial Intelligence Act (et ISO/IEC 42001 si demandé), les actions d'évaluation synchronisées depuis Foundry ; retention policy Purview pour les Enterprise AI apps ; garde-fous imposés par le Foundry Control Plane et Azure Policy ; standard setup avec CMK.

5. Un éditeur SaaS sert 300 clients avec le même agent ; chaque client veut que l'agent retienne les préférences de ses utilisateurs, sans aucun risque de mélange.

Mémoire : memory store avec scope calculé côté serveur (tenant + utilisateur), jamais choisi par le modèle ; un store ou un project par tenant pour les gros clients (100 scopes par store) ; TTL et suppression à la demande. Conversations isolées par l'identité de l'appelant ; références plutôt que copies des données client.

6. Un workflow de revue de contrats enchaîne quatre agents sur plusieurs heures ; un redémarrage du conteneur fait tout recommencer, ce qui coûte cher en jetons.

Checkpoints Agent Framework stockés dans Cosmos DB (CosmosCheckpointStorage), reprise au dernier superstep ; ou Durable Extension si le workflow attend aussi des validations humaines longues. Stockage des checkpoints traité comme une frontière de confiance.

7. Une équipe hésite entre AKS, Container Apps et hosted agents pour un orchestrateur Agent Framework sans GPU, sans cluster existant, avec un trafic très variable et peu d'exploitants.

Hosted agents : code Agent Framework, scaling par session, identité et état gérés ; Container Apps si un contrôle du runtime ou de l'ingress est exigé ; AKS écarté (pas de cluster ni de GPU, exploitation lourde).

8. Les utilisateurs signalent des réponses incohérentes quand l'orchestrateur appelle l'agent juridique, mais rien n'apparaît dans les logs de l'agent juridique.

Le trace context n'est pas propagé : vérifier AZURE_TRACING_GEN_AI_ENABLE_TRACE_CONTEXT_PROPAGATION, le même Application Insights (ou un collecteur OTLP commun), puis suivre les spans agent_to_agent_interaction du même trace_id. Pour reproduire : dataset tiré des traces et relance locale avec Agent Inspector.

9. Après le passage à un nouveau modèle, le run success rate tombe à 88 % la nuit ; l'astreinte veut une réaction automatique.

Alert sur le run success rate et les scores de continuous evaluation, action group qui repinne la version précédente de l'agent ; scheduled evaluation sur dataset pour confirmer la dérive ; notification du sponsor et de l'owner ; correction puis promotion après la porte d'évaluation.

10. Une nouvelle équipe de cinq développeurs perd une semaine à installer les outils et Copilot propose du code qui n'utilise pas les bibliothèques de l'entreprise.

Dev container (Azure CLI, azd, extension agents, Foundry Toolkit), dépendances épinglées, .github/copilot-instructions.md (ou AGENTS.md) avec les conventions, et Microsoft Foundry Skill pour les tâches de déploiement et d'évaluation.

12. Pour aller plus loin#

• Multiplexer plusieurs utilisateurs dans une session de hosted agent : possible, mais le sandbox et $HOME deviennent partagés.
• Agent 365 et API Management : inventaire des serveurs MCP, blocage d'un serveur ou d'un outil, signaux d'exécution, pour une gouvernance au niveau du tenant Microsoft 365.
• Entra-authenticated trace ingestion (preview) : ingestion des traces Foundry sans clé d'instrumentation.
• Agent Optimizer (azd ai agent optimize) : candidats d'instructions évalués puis appliqués après revue.
• Unified model API (preview) d'API Management : plusieurs fournisseurs de modèles derrière un endpoint compatible OpenAI.
• Architecture center : AI agent orchestration patterns, Baseline Microsoft Foundry chat reference architecture, Multitenancy and Foundry Models.

13. Fiche à retenir#

• Sept couches à spécifier : intégration, Zero Trust, état, compute, observabilité, monitoring, SDLC.
• Architecture de référence : orchestrateur Agent Framework sur Container Apps, état dans Cosmos DB ; alternative managée Agent Service ; hybride possible.
• A2A : a2a GA (1.0), a2a_preview (0.3) ; A2A tool sortant, endpoint et agent card entrants ; Connected Agents retiré.
• API Management : A2A agent API (agent card réécrite, genai.agent.id), REST API as MCP server, MCP passthrough ; pas de Consumption tier pour A2A.
• AI gateway Foundry (preview) : seulement les MCP tools créés après la connexion, sans managed OAuth ; policies dans le portail Azure ; pas de traces d'outil.
• Toolbox = un endpoint MCP pour tous les outils ; Foundry IQ = routage vers les sources, ACL, citations.
• Entra Agent ID : blueprint (credentials, permissions héritables), agent identity (sans credentials, single-tenant), sponsor obligatoire, owner ; Azure RBAC sur l'identité, jamais sur le blueprint.
• Nouveau modèle : une agent identity par agent dès sa création ; legacy Agent Application : identité partagée du project, puis distincte à la publication (rôles à réattribuer).
• Mouvement latéral : MCSB v2 AI-4, rôles au plus juste, BYO VNet ou managed VNet, data proxy par project, attack path analysis.
• Conformité : Compliance Manager (EU AI Act, ISO/IEC 42001, ISO/IEC 23894, NIST AI RMF), Control Plane Compliance, Azure Policy, Defender, Purview.
• État : session (conversations, $HOME, 2–240 min, 30 j), équipe (checkpoints au superstep, Durable), mémoire (memory store preview, TTL, scope).
• Standard setup : BYO Cosmos DB (≥ 3 000 RU/s, agent-definitions-v1, run-state-v1), Storage, AI Search ; project = unité d'isolation.
• Memory : 100 scopes, 10 000 memories par scope, pas de VNet, {{$userId}} + x-memory-user-id, default_ttl_seconds (0 = jamais).
• Tenants : pas de memory bleed, scope et tenant calculés par le code, références plutôt que copies.
• Compute : prompt agent < hosted agent < Container Apps / Functions Durable < AKS ; hosted = sandbox par session (0,5–2 vCPU), facturé sur les sessions actives.
• Versions hosted : 100 % sur une version, pin → test en session épinglée → promotion ; canary au gateway.
• Observabilité : OpenTelemetry GenAI, W3C Trace Context, App Insights du project, traces serveur 90 j, content recording désactivé par défaut.
• Reasoning path : invoke_agent, agent_planning, agent_to_agent_interaction, execute_tool (tool.call.arguments, tool.call.results).
• Replay : traces, checkpoints, dataset depuis les traces, Agent Inspector local, streaming rejouable.
• Monitoring : dashboard (jetons, latence, run success rate), continuous (live) vs scheduled (dataset, drift), red team, alerts (preview), max_hourly_runs.
• Remédiation : retry, circuit breaker, fallback dans le code ; repin, endpoint désactivé, stop ou block, policy au gateway dans la plateforme.
• SDLC : dev container, Foundry Toolkit + Agent Inspector, azd ai agent, dépendances épinglées, AI instructions (copilot-instructions.md, AGENTS.md, Foundry Skill), pipeline OIDC avec porte d'évaluation.

Références#

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

• Study guide for Exam AI-500
• Build a multiple-agent workflow automation solution by using Microsoft Agent Framework
• Connect to an A2A agent endpoint from Foundry Agent Service
• Import an A2A agent API (API Management)
• AI gateway in Azure API Management
• Govern MCP tools by using an AI gateway (preview)
• Agent identities in Microsoft Entra Agent ID
• Agent 365 identity
• Agent identity concepts in Microsoft Foundry
• Microsoft cloud security benchmark v2 : Artificial Intelligence Security
• Security explorer and attack paths in Microsoft Defender for Cloud
• AI security posture management
• Networking options for Foundry Agent Service
• Deep dive into Foundry Agent Service networking
• Build and manage assessments in Compliance Manager (AI regulations)
• Manage compliance and security in Microsoft Foundry
• What is Microsoft Foundry Control Plane?
• Manage agents at scale in Microsoft Foundry Control Plane
• Set up standard agent resources
• Azure Cosmos DB integration with Foundry Agent Service
• Memory in Microsoft Foundry Agent Service (preview)
• Create and use memory in Foundry Agent Service (preview)
• Considerations for multitenant agentic systems
• Multitenancy and Foundry Models
• Isolate hosted agent sessions per user
• Microsoft Agent Framework Workflows : Checkpoints
• Durable Extension for Microsoft Agent Framework
• What are hosted agents?
• Manage hosted agents
• Promote hosted agents to production with the Azure Developer CLI (preview)
• Deploy a hosted agent
• Deploy a hosted agent from source code
• Agent tracing overview
• Set up tracing in Microsoft Foundry
• Add client-side tracing to Foundry agents (preview)
• Export hosted agent telemetry by using OpenTelemetry
• Monitor agents with the Agent Monitoring Dashboard
• Observability in generative AI
• Inspect a local agent with the Agent Inspector
• Debug agents with Agent Inspector in Microsoft Foundry Toolkit
• Install Microsoft Foundry Toolkit for Visual Studio Code
• Prepare your development environment
• Microsoft Foundry agent extension overview (azd)
• Use the Microsoft Foundry Skill in coding agents
• Copilot Autofix : repository instructions and skills