Mettre une plateforme d'agents IA en production sur Azure avec Microsoft Foundry et API Management

1. Pourquoi une plateforme, et pas une collection de projets

La première vague de projets GenAI s'est construite par équipe : chaque produit a créé sa ressource Azure OpenAI, généré sa clé API, stocké cette clé dans une variable d'environnement et branché un prompt. Six mois plus tard, la DSI découvre vingt ressources dans douze souscriptions, des clés qui circulent dans des dépôts Git, aucune idée du coût par équipe, et aucun moyen de couper un usage qui dérape. Le RSSI pose alors la question qui tue : « Qui peut appeler quel modèle avec quelles données ? » Personne ne sait répondre.

Une plateforme IA répond à cette question par construction. Elle centralise cinq choses que chaque projet refaisait mal : l'identité (qui appelle), la passerelle (par où passent les appels), les modèles et les agents (ce qui est appelé), les outils (ce que les agents ont le droit de faire) et l'observabilité (ce qui s'est passé et combien ça a coûté). Chaque équipe garde la liberté de ses cas d'usage ; la plateforme fixe les règles une seule fois.

Règle de conception n° 1 : aucune clé API, de bout en bout. Si un secret existe quelque part, il finira dans un dépôt, un ticket ou un fichier de logs. L'identité Microsoft Entra remplace la clé à chaque maillon : utilisateur, agent, passerelle, modèle, outil.

2. L'architecture de référence en cinq couches

L'architecture tient en cinq couches, chacune portée par un service Azure identifié. Les flèches vont toujours dans le même sens : un appel entre par l'identité, traverse la passerelle, atteint un modèle ou un agent Foundry, qui n'accède aux outils qu'à travers la passerelle, et tout est tracé.

Les sections suivantes détaillent chaque couche avec les décisions à prendre et, quand c'est utile, la configuration exacte.

3. Couche 1 — L'identité sans clé API

Tout commence par désactiver l'authentification locale (par clé) sur les ressources Foundry et Azure OpenAI. Tant qu'une clé fonctionne, quelqu'un l'utilisera. Une fois la clé désactivée, seuls les jetons Entra ID passent, et chaque appel est attribuable à une identité.

• Utilisateurs : authentification OIDC via Entra ID, avec accès conditionnel (MFA, appareil conforme) comme pour n'importe quelle application d'entreprise. L'agent reçoit un jeton au nom de l'utilisateur et peut le propager aux outils (on-behalf-of) quand l'outil doit appliquer les droits de la personne.
• Agents et services : une identité managée par agent ou par charge de travail. Sur AKS, Workload Identity fédère le compte de service Kubernetes avec une identité Entra : le pod obtient un jeton sans qu'aucun secret ne soit monté dans le conteneur.
• Passerelle : API Management s'authentifie auprès de Foundry avec sa propre identité managée. Les consommateurs s'authentifient auprès d'API Management avec un jeton Entra validé par la politique validate-azure-ad-token ; la clé d'abonnement APIM sert au comptage, pas à la sécurité.
• Rôles Foundry : affectez les rôles dédiés au moindre privilège. Foundry Agent Consumer pour une application qui appelle un agent, Foundry User pour une équipe qui développe, Project Manager pour un responsable de projet. Au niveau compte, projet ou agent selon le périmètre.

Test de validation : supprimez toutes les clés de votre coffre-fort et redéployez. Si quelque chose casse, vous avez trouvé une dette à résorber avant la mise en production.

4. Couche 2 — API Management comme passerelle IA

Azure API Management est devenu une vraie passerelle IA : il importe directement une ressource Microsoft Foundry (modèles Azure OpenAI ou autres fournisseurs), s'y connecte par identité managée et applique des politiques spécifiques aux grands modèles de langage. C'est là que se décident les quotas, le cache, le filtrage de contenu et la répartition de charge, pour toutes les équipes à la fois.

Quatre politiques structurent la couche. Elles s'appliquent au niveau d'une API, d'un produit (une équipe, un département) ou d'une opération.

1. llm-token-limit : plafonne les tokens par minute ou par période (heure, jour, mois) selon une clé de comptage libre — abonnement, produit, identité appelante. C'est l'outil du FinOps : une équipe a son quota et ne peut pas consommer celui des autres. L'estimation des tokens du prompt côté passerelle rejette les requêtes trop grosses avant même d'atteindre le modèle.
2. llm-emit-token-metric : envoie à Application Insights les tokens de prompt, de complétion et totaux, avec des dimensions personnalisées (équipe, application, modèle, utilisateur). Sans cette politique, vous ne saurez jamais qui a dépensé quoi.
3. llm-semantic-cache-lookup et llm-semantic-cache-store : mettent en cache les réponses par similarité sémantique du prompt (embeddings + Azure Managed Redis). Sur les questions répétitives d'un assistant interne, le taux de cache dépasse souvent 20 %, autant de tokens non facturés et de réponses instantanées.
4. llm-content-safety : transmet le prompt à Azure AI Content Safety avant de l'envoyer au modèle, et bloque les catégories que vous définissez (haine, violence, auto-mutilation, contenu sexuel, jailbreak via Prompt Shields). Le filtre est appliqué avant le modèle, quel que soit le fournisseur.

<policies>
  <inbound>
    <base />
    <!-- Le consommateur s'authentifie avec un jeton Entra ID, pas une clé -->
    <validate-azure-ad-token tenant-id="{{tenant-id}}">
      <audiences><audience>api://plateforme-ia</audience></audiences>
    </validate-azure-ad-token>

    <!-- Quota de tokens par produit APIM (= par équipe) : 50 000 TPM, 20 M / mois -->
    <llm-token-limit counter-key="@(context.Product.Id)"
                     tokens-per-minute="50000"
                     token-quota="20000000" token-quota-period="Monthly"
                     estimate-prompt-tokens="true"
                     remaining-tokens-variable-name="remainingTokens" />

    <!-- Filtrage de contenu avant le modèle -->
    <llm-content-safety backend-id="content-safety" shield-prompt="true">
      <categories output-type="EightSeverityLevels">
        <category name="Hate" threshold="4" />
        <category name="Violence" threshold="4" />
      </categories>
    </llm-content-safety>

    <!-- Cache sémantique : réponses similaires servies sans appel au modèle -->
    <llm-semantic-cache-lookup score-threshold="0.05"
                               embeddings-backend-id="embeddings"
                               embeddings-backend-auth="system-assigned" />

    <!-- Métriques de tokens vers Application Insights, par équipe et par application -->
    <llm-emit-token-metric namespace="plateforme-ia">
      <dimension name="Equipe" value="@(context.Product.Name)" />
      <dimension name="Application" value="@(context.Subscription.Name)" />
      <dimension name="Modele" value="@(context.Request.MatchedParameters["deployment-id"])" />
    </llm-emit-token-metric>

    <!-- Identité managée de la passerelle vers Foundry : aucune clé -->
    <authentication-managed-identity resource="https://cognitiveservices.azure.com" />
    <set-backend-service backend-id="foundry-pool" />
  </inbound>
  <outbound>
    <base />
    <llm-semantic-cache-store duration="300" />
  </outbound>
</policies>

Deux compléments valent le détour. Les backends avec pool et disjoncteur (circuit breaker) répartissent les appels entre plusieurs déploiements — une région en capacité réservée (PTU) en priorité, le paiement à l'usage en débordement — et basculent automatiquement quand un déploiement renvoie des erreurs 429. L'API de modèle unifiée (en préversion) expose plusieurs fournisseurs derrière un seul point d'entrée et traduit les formats, ce qui permet de changer de modèle sans toucher aux applications.

Depuis la fin 2025, la passerelle IA s'intègre aussi directement dans le portail Microsoft Foundry (préversion) : les quotas par déploiement, l'enregistrement des agents et des outils MCP se font depuis Foundry, l'instance API Management restant accessible pour les politiques avancées. C'est la direction que prend Microsoft : Foundry pour le plan de contrôle, API Management pour le plan de données.

5. Couche 3 — Microsoft Foundry : modèles, agents et garde-fous

Microsoft Foundry (anciennement Azure AI Foundry) est le plan de contrôle de la couche modèles et agents. Trois décisions y sont prises une fois pour toutes.

• Le catalogue de modèles ouvert à chaque projet. Foundry propose Azure OpenAI, Anthropic, Mistral, Meta, Cohere et d'autres ; le type de déploiement (standard, provisioned, batch, managed compute) fixe le compromis coût / latence / garantie de capacité. Décidez par projet quels modèles sont autorisés, et bloquez le reste par RBAC plutôt que par convention.
• L'hébergement des agents dans Foundry Agent Service : conteneur ou code source (Agent Framework, LangGraph, Semantic Kernel ou code libre), identité Entra dédiée par agent, endpoint propre, bac à sable isolé par session, versions immuables et traces dans Application Insights. L'agent devient un objet gouverné, avec un propriétaire, une version et un journal.
• Les garde-fous attachés aux déploiements : filtres de contenu en entrée et en sortie, Prompt Shields contre les injections, détection de matériel protégé et de données personnelles, et blocklists personnalisées en correspondance exacte ou en expression régulière (jusqu'à 10 000 termes par liste). Une blocklist regex sur les formats de numéros de carte, d'IBAN ou de matricules internes coûte une heure et évite une fuite.

La règle est de doubler les garde-fous : Content Safety à la passerelle pour tout ce qui entre, filtres Foundry sur chaque déploiement pour ce qui sort. Les deux couches ne voient pas la même chose et ne tombent pas en même temps.

Le plan de contrôle Foundry donne enfin l'inventaire : la liste des agents et des modèles de toute l'entreprise, leur consommation, leur propriétaire. C'est le document que le RSSI demandait, mis à jour en temps réel.

6. Couche 4 — Des outils MCP gouvernés, pas des connecteurs sauvages

Un agent utile agit : il lit un ticket Jira, interroge une base, crée une page SharePoint. Le Model Context Protocol (MCP) standardise cet accès aux outils, mais un serveur MCP branché directement sur un agent revient à donner à un LLM un accès réseau non filtré. La solution est la même que pour les modèles : tout passe par la passerelle.

• Exposer vos API REST existantes comme serveurs MCP depuis API Management, sans réécrire de code : la passerelle traduit les opérations OpenAPI en outils MCP, avec les politiques habituelles (authentification, limitation, filtrage d'IP, journalisation).
• Faire transiter les serveurs MCP existants (Jira, Azure DevOps, SharePoint, les vôtres) par API Management : l'endpoint que voit l'agent est celui de la passerelle, jamais celui du serveur. L'authentification se fait par OAuth 2.0 ou par passage de l'identité de l'utilisateur, selon que l'outil doit agir au nom de la plateforme ou de la personne.
• Autoriser par outil, pas par serveur : un agent de support a le droit de lire les tickets, pas de les supprimer. La politique est écrite une fois dans la passerelle et s'applique à tous les agents qui utilisent l'outil.
• Enregistrer les outils dans l'inventaire Foundry pour qu'ils soient découvrables par les équipes et gouvernés centralement, au lieu d'être recréés dans chaque projet.

Sur une plateforme Kubernetes, le même rôle peut être tenu par une passerelle d'agents dédiée (agentgateway, le projet CNCF porté par Solo.io, avec kagent pour déclarer les agents et kmcp pour les serveurs MCP). C'est l'architecture que j'ai mise en œuvre sur AKS pour une plateforme servant environ 3 000 collaborateurs : le JWT de l'utilisateur est validé à la passerelle, l'accès est autorisé outil par outil, et le pod de l'agent porte une Workload Identity sans aucun secret. API Management et agentgateway couvrent le même besoin ; le choix dépend de l'endroit où vivent vos agents — Foundry Agent Service ou vos propres clusters.

7. Couche 5 — Observabilité et FinOps des tokens

Une plateforme que l'on ne mesure pas est une plateforme que la direction financière finira par couper. Trois flux de données suffisent, à condition de les mettre en place dès le premier agent.

1. Les traces : les agents émettent des spans OpenTelemetry selon les conventions sémantiques GenAI (gen_ai.request.model, gen_ai.usage.input_tokens, gen_ai.usage.output_tokens, outils appelés, durées). Foundry Agent Service les produit nativement ; vos propres agents utilisent le SDK OpenTelemetry. Destination : Application Insights, ou Azure Monitor managed Prometheus et Grafana sur AKS.
2. Les métriques de tokens : la politique llm-emit-token-metric de la passerelle fournit la vérité comptable, indépendante du code des agents, avec les dimensions équipe, application et modèle. C'est sur elle que se construisent le showback et les alertes.
3. Les coûts : budgets Azure par souscription et par groupe de ressources, alertes à 80 % et 100 %, et un tableau de bord qui croise tokens consommés et facture réelle par équipe. Avec la capacité réservée (PTU), le tableau de bord suit aussi le taux d'utilisation pour dimensionner la réservation.

Le FinOps de l'IA tient en une boucle mensuelle : revue des coûts par équipe, ajustement des quotas dans la passerelle, décision réservé / à l'usage, et retrait des agents sans usage. Les quotas de la couche 2 rendent la décision exécutoire sans réunion : quand une équipe atteint son plafond, ses appels renvoient 429 et elle vient discuter.

8. La check-list de mise en production

Douze points à cocher avant d'ouvrir la plateforme au-delà de l'équipe pilote. Si l'un manque, vous le paierez en incident.

1. Authentification locale désactivée sur toutes les ressources Foundry et Azure OpenAI ; aucune clé en circulation.
2. Accès réseau privé : Private Endpoints sur Foundry, API Management, Redis et le stockage ; aucun endpoint public sur les modèles.
3. Identité managée ou Workload Identity pour chaque agent et pour la passerelle ; rôles Foundry au moindre privilège.
4. Quotas de tokens par équipe dans la passerelle, avec un quota mensuel en plus du débit par minute.
5. Métriques de tokens avec dimensions équipe / application / modèle, et tableau de bord de showback partagé aux responsables budgétaires.
6. Filtres de contenu à la passerelle et sur chaque déploiement, Prompt Shields activés, blocklists sur vos formats sensibles.
7. Outils MCP accessibles uniquement via la passerelle, autorisation par outil, journalisation des appels d'outils.
8. Traçage OpenTelemetry de bout en bout avec corrélation utilisateur → agent → modèle → outil.
9. Évaluation des agents avant mise en production (jeux de tests, métriques de qualité et de sécurité) et re-évaluation à chaque changement de modèle ou de prompt.
10. Stratégie de résilience : pool de backends multi-régions avec disjoncteur, repli du réservé vers l'à-l'usage.
11. Infrastructure as code pour tout (Terraform ou Bicep, politiques APIM incluses) ; aucun paramètre posé à la main dans un portail.
12. Processus d'onboarding d'un nouvel agent documenté : propriétaire, modèles autorisés, outils, quota, évaluation, revue de sécurité.

9. Les cinq erreurs que je vois le plus souvent

• Mettre la passerelle après coup. Les équipes ont déjà codé l'URL directe du modèle et la clé ; migrer coûte dix fois plus cher que de commencer par la passerelle avec un seul projet pilote.
• Confondre clé d'abonnement APIM et sécurité. La clé d'abonnement identifie une application pour le comptage ; l'authentification est le jeton Entra. Sans validate-azure-ad-token, une clé volée donne accès à tout.
• Un seul quota global. Si toutes les équipes partagent un quota, la première qui lance un traitement par lots bloque les autres. Un quota par produit APIM, c'est la différence entre un incident et un simple 429 chez l'équipe fautive.
• Des agents qui parlent directement aux outils. Chaque connecteur MCP câblé en dur est une autorisation réseau non revue et un secret de plus. La passerelle unique est la seule façon de répondre à « quel agent a accédé à quoi ».
• Pas d'évaluation continue. Un changement de version de modèle modifie les réponses ; sans jeu de tests rejoué automatiquement, la régression se découvre chez l'utilisateur.

10. Ce que ça change en pratique : retour d'expérience

Sur la plateforme agentique que j'ai architecturée pour un grand groupe média français (environ 3 000 collaborateurs servis), l'approche décrite ici a eu trois effets mesurables. D'abord, l'onboarding d'un nouvel agent est passé d'un projet à un formulaire : propriétaire, modèles, outils, quota, et l'agent est publié dans le catalogue avec sa Workload Identity, son endpoint derrière la passerelle et ses tableaux de bord déjà alimentés. Ensuite, le coût par équipe est devenu une donnée lue chaque mois par les managers, pas une surprise trimestrielle. Enfin, la revue sécurité d'un agent se fait sur des faits — la liste des outils qu'il peut appeler, les filtres actifs, ses traces — et non sur une promesse de l'équipe.

La plateforme a été construite sur AKS avec Microsoft Foundry pour les modèles, une passerelle d'agents pour l'autorisation par outil et OpenTelemetry pour l'observabilité. La même architecture se déploie avec API Management en passerelle et Foundry Agent Service pour l'hébergement quand l'entreprise ne veut pas exploiter de cluster Kubernetes : ce sont les cinq couches qui comptent, pas le produit choisi pour chacune.

11. Par où commencer

Pas par les agents. Commencez par la couche 1 et la couche 2 avec un seul cas d'usage à faible risque : désactivez les clés, placez API Management devant Foundry, posez un quota et les métriques de tokens. Vous aurez en quatre semaines une plateforme minuscule mais gouvernée, sur laquelle chaque agent suivant coûtera moins cher que le précédent. Les couches 3 à 5 s'ajoutent ensuite, dans l'ordre des besoins : garde-fous dès le premier agent exposé à des utilisateurs, outils MCP dès le premier agent qui agit, FinOps complet dès la deuxième équipe.

Si vous voulez un regard extérieur sur votre point de départ, c'est exactement l'objet du premier échange de 30 minutes.