05 · Design and implement a GenAIOps infrastructure

Version : 1.1 · Date : 2026-10-21 · Domaine 3 de l'examen : Design and implement a GenAIOps infrastructure (20 à 25 %)

En une phrase : la GenAIOps applique au LLM ce que la MLOps applique au modèle ML : des environnements Foundry isolés et déployés par IaC, des identités sans clé, un réseau privé, des foundation models choisis sur preuves et déployés sans casser la production (versions, canary, PTU), et des prompts traités comme du code (Git, pull request, version d'agent).

Ce que l'examen demande#

Domaine Design and implement a GenAIOps infrastructure du guide d'étude AI-300 :

Ce chapitre prend l'angle opérations (environnements, promotion, migration, capacité, prompts en tant que code). Les notions de développeur sont dans le cours AI-103 et ne sont pas répétées : elles sont signalées par un lien à chaque fois.

1. Les bases : GenAIOps et ce que vous savez déjà#

1.1 Le cycle GenAIOps#

La GenAIOps (parfois appelée LLMOps) est une spécialisation de la MLOps pour les applications qui intègrent des modèles de langage. La différence tient à ce qu'on gère : on ne construit pas le modèle, on gère des modèles pré-entraînés, des prompts, des agents et des connecteurs de données, et on les évalue avec des mesures nouvelles (cohérence, groundedness, coût par requête) plutôt que la seule précision.

Le cycle n'est pas linéaire : une dérive en production (réponses fausses, coût qui explose) renvoie dans la boucle Build (prompt, données) ou Explore (changer de modèle).

1.2 Ce qui est déjà traité ailleurs#

2. Foundry resources et project environments#

2.1 Resource ou project : où mettre la frontière#

Attention, toutes les capacités ne s'isolent pas par project (page Foundry rollout) :

2.2 Topologie par environnement#

Recommandation Microsoft : en production, l'isolation est le défaut ; la co-location y est une exception documentée (mêmes données, mêmes personas, risque accepté). En exploration, la co-location est le défaut. L'exemple de référence (Contoso) : une Foundry resource d'exploration partagée et limitée en capacité, puis des environnements dev/test, puis une production isolée pour le petit nombre de cas financés.

Règles d'exploitation :

• Même IaC, autres paramètres pour chaque environnement ; avec azd, un project par environnement (azd env new development | test | production) : le nom d'environnement azd n'isole aucune ressource Azure.
• Promouvoir la même révision de code d'un environnement à l'autre (pas un artefact partagé pour un hosted agent : on reconstruit à partir de la révision testée).
• Les connections créées au niveau resource sont visibles de tous les projects ; au niveau project, seulement de ce project.

2.3 Créer une Foundry resource et un project#

Prérequis CLI de la doc : Azure CLI 2.80 ou plus, rôle Contributor ou Owner sur le groupe de ressources.

# 1. Foundry resource : managed identity et project management obligatoires pour créer des projects
az cognitiveservices account create \
  --name aif-support-dev --resource-group rg-ai-dev --location swedencentral \
  --kind AIServices --sku S0 \
  --custom-domain aif-support-dev \
  --assign-identity \
  --allow-project-management true

# 2. Project
az cognitiveservices account project create \
  --name aif-support-dev --resource-group rg-ai-dev \
  --project-name support --location swedencentral

# 3. Endpoint du project, à donner à l'application (avec le nom du deployment)
az cognitiveservices account project show --name aif-support-dev --resource-group rg-ai-dev \
  --project-name support --query 'properties.endpoints."AI Foundry API"' --output tsv

3. Identité et RBAC#

Le détail des rôles est au AI-103 · 03, section 5.3. Le schéma d'exploitation à retenir :

Trois principes que l'examen teste :

1. Plan de contrôle ≠ plan de données : Owner ou Contributor gèrent la ressource mais ne suffisent pas pour discuter avec un agent dans le portail ; il faut aussi un rôle de plan de données (Foundry User).
2. Keyless : désactiver les clés locales (disableLocalAuth: true en Bicep, local_auth_enabled = false en Terraform) et authentifier tout le monde par Entra ID ; les clés ne gardent un sens que lorsque la granularité des rôles n'est pas requise.
3. Pas de rôle Cognitive Services pour Foundry, sauf Cognitive Services Usages Reader ; exception documentée : la doc du managed compute cite aussi Cognitive Services Contributor pour créer ou supprimer ses deployments.

Mapper des groupes Entra existants aux rôles Foundry à la bonne étendue, puis vérifier les deux chemins d'accès (gestion et développement) avant d'ouvrir l'environnement aux équipes.

4. Réseau privé#

Rappel détaillé : AI-103 · 02, section 2.3 et AI-103 · 03, section 5.4. Ce qu'il faut décider par environnement :

Le managed virtual network a trois modes sortants :

# Managed network « Allow only approved outbound » sur une Foundry resource existante
az cognitiveservices account managed-network create \
  --resource-group rg-ai-prd --name aif-support-prd \
  --managed-network allow_only_approved_outbound --firewall-sku Standard

# Vérifier le mode et les règles sortantes
az cognitiveservices account managed-network show --resource-group rg-ai-prd --name aif-support-prd
az cognitiveservices account managed-network outbound-rule list --resource-group rg-ai-prd --name aif-support-prd

Points d'examen :

• Avec le managed network, la managed identity de la Foundry resource doit avoir le rôle Azure AI Enterprise Network Connection Approver (approbation automatique des managed private endpoints).
• customSubDomainName, allowProjectManagement et networkInjections se définissent à la création de la resource ; la doc indique que la CLI ne sait pas encore créer une resource avec network injection (utiliser az rest, Bicep ou Terraform).
• Les managed private endpoints ne créent aucune carte réseau visible dans votre abonnement.
• Avec l'accès public désactivé, le plan de données n'est joignable que depuis le VNet : runners CI/CD auto-hébergés dans le VNet, jump box via Azure Bastion.
• Les ressources connectées (Storage, AI Search, Key Vault, Cosmos DB) ont leur propre réseau : les fermer une par une.

5. Bicep et Azure CLI#

Microsoft publie des modèles prêts à l'emploi (Bicep et Terraform) dans microsoft-foundry/foundry-samples (infrastructure/infrastructure-setup-bicep : 00-basic, standard agent setup, réseau privé, 18-managed-virtual-network…). On peut aussi partir de l'Export template d'une resource configurée dans le portail (Automation > Export template > Bicep), puis remplacer les valeurs en dur par des paramètres.

Un environnement minimal en Bicep (resource keyless, project, model deployment) :

param location string = resourceGroup().location
param foundryName string            // globalement unique : sert aussi de sous-domaine
param projectName string = 'support'
param modelName string              // pris dans « az cognitiveservices account list-models »
param modelVersion string

resource foundry 'Microsoft.CognitiveServices/accounts@2025-06-01' = {
  name: foundryName
  location: location
  kind: 'AIServices'
  sku: { name: 'S0' }
  identity: { type: 'SystemAssigned' }   // requis pour créer des projects
  properties: {
    allowProjectManagement: true         // non modifiable ensuite
    customSubDomainName: foundryName     // requis pour Entra ID et Private Endpoint
    disableLocalAuth: true               // keyless
    publicNetworkAccess: 'Disabled'      // accès par Private Endpoint uniquement
  }
}

resource project 'Microsoft.CognitiveServices/accounts/projects@2025-06-01' = {
  parent: foundry
  name: projectName
  location: location
  identity: { type: 'SystemAssigned' }
  properties: {}
}

resource chat 'Microsoft.CognitiveServices/accounts/deployments@2025-06-01' = {
  parent: foundry
  name: 'chat'                           // nom passé par le code dans « model »
  sku: {
    name: 'GlobalStandard'
    capacity: 50                         // en milliers de TPM
  }
  properties: {
    model: { format: 'OpenAI', name: modelName, version: modelVersion }
    versionUpgradeOption: 'OnceCurrentVersionExpired'
    raiPolicyName: 'Microsoft.DefaultV2'
  }
}

# Déploiement, puis vérification
az deployment group create --resource-group rg-ai-dev --template-file main.bicep \
  --parameters foundryName=aif-support-dev modelName=<modele> modelVersion=<version>
az resource list --resource-group rg-ai-dev --output table

# Modèles disponibles en GA dans la région (utile quand un modèle est retiré : erreur ServiceModelDeprecating)
az cognitiveservices model list --location swedencentral \
  --query "[?model.lifecycleStatus=='GenerallyAvailable']"

L'exemple utilise 2025-06-01, une version GA encore valide ; la page de référence Microsoft.CognitiveServices/accounts/projects liste au 21/10/2026 des versions GA plus récentes jusqu'à 2026-09-01 (et des préversions) : prendre la dernière GA pour un nouveau modèle et vérifier son change log. Les équivalents Terraform (azurerm_cognitive_account, azurerm_cognitive_account_project, azurerm_cognitive_deployment) sont au AI-103 · 02, section 2.4.

Pièges de déploiement relevés par la doc :

6. Serverless API ou managed compute#

Microsoft recommande la Serverless API dès que possible ; elle porte tous les deployment types (Standard, Provisioned, Batch, Developer). Le managed compute (preview) sert les modèles open source (collection Hugging Face du catalog, registre azure-huggingface), partenaires ou personnalisés sur des GPU dédiés gérés par Foundry. L'instant access (preview) n'est pas un deployment : on appelle un modèle pris en charge par son nom, pour essayer vite.

Le managed compute en détail :

flowchart TD
    A["Le modèle voulu est-il proposé<br/>en Serverless API ?"] -- Oui --> B{"Simple essai,<br/>sans deployment ?"}
    B -- Oui --> IA["Instant access (preview)"]
    B -- Non --> S["Serverless API<br/>puis choisir le deployment type"]
    A -- Non --> C{"Modèle open source<br/>de la collection Hugging Face ?"}
    C -- Oui --> MC["Managed compute (preview)<br/>template + accelerator + capacity"]
    C -- Non --> D["Hors Foundry managé :<br/>Azure Machine Learning ou AKS (KAITO)<br/>voir chapitre 08"]

Les modèles de partenaires vendus via Azure Marketplace demandent des droits Microsoft.MarketplaceOrdering/* et Microsoft.SaaS/* (inclus dans Owner et Contributor). Le code client ne change pas d'une option à l'autre : seul le nom du deployment change.

7. Choisir un modèle pour un cas d'usage#

Les critères (qualité, latence, coût, contexte, modalités, raisonnement, région, licence) et les familles de modèles sont au AI-103 · 01, section 2. Ici, la méthode.

7.1 Partir de la specification#

Un modèle se choisit contre l'agent specification (objectif, comportement, critères de succès, jeu de test). Exemple du module Microsoft : un agent de recommandation d'équipement au ton amical → un chat completion model plutôt qu'un reasoning model, et un SLM envisagé parce que le trafic attendu est élevé. Choisir le modèle qui tient la rubric, pas le plus puissant.

7.2 Model leaderboards (preview)#

Dans le model catalog (Discover), le Model leaderboard classe des modèles texte (LLM, SLM) et d'embeddings selon :

Outils : trade-off charts (qualité contre coût, débit ou sécurité), Compare de 2 ou 3 modèles côte à côte (performance, détails : contexte et langues, supported endpoints serverless ou managed compute, feature support : function calling, structured output, vision). Rôle requis : au moins Reader sur le project.

7.3 Les benchmarks filtrent, vos données décident#

• Les benchmarks sont calculés sur des jeux publics : un filtre, pas une conclusion. Évaluer la shortlist sur votre jeu de test (le Try with your own data de l'onglet Benchmarks n'existe que dans Foundry (classic) ; dans le nouveau portail, passer par les evaluations, voir chapitre 06).
• Projeter le coût sur votre trafic : jetons de raisonnement, jetons en cache et surcoût des sorties structurées peuvent changer l'économie d'un facteur 2 ou plus d'une génération à l'autre.
• Vérifier la disponibilité opérationnelle : région, deployment type, quota, et possibilité de faire tourner le candidat à côté de l'actuel (rollback).
• Pour une charge réglementée, la conformité (certification, région) filtre avant la qualité.
• Alternative : model router, qui choisit un modèle à chaque requête dans un seul deployment (AI-103 · 01, section 2.3).

7.4 Gouverner les modèles autorisés#

Deux définitions Azure Policy intégrées, évaluées au moment du déploiement (le catalog ne cache pas les modèles : le bouton Deploy est désactivé avec la raison) :

Effets Deny ou Audit ; rôle Owner ou Resource Policy Contributor pour assigner ; compter au moins 15 minutes avant que l'assignation s'applique. Ces policies s'appliquent aussi aux modèles que model router peut choisir. Une policy custom peut aussi interdire un deployment type (Microsoft.CognitiveServices/accounts/deployments/sku.name).

8. Versions de modèles et stratégies de déploiement#

8.1 Ce qui se passe à la date de retrait#

Délais garantis : le modèle de remplacement arrive environ 90 jours avant le retrait en Global Standard et 30 jours en provisioned ; les dates de retrait ne sont pas prolongeables. L'auto-upgrade est un filet de sécurité, pas un plan de migration. Sources du signal : Model retirement schedule, e-mails, Azure Service Health, API Models (lifecycleStatus, deprecationDate).

8.2 Le Model migration process en six phases#

Avant tout : préparer et geler le jeu de test (entrées réelles ou synthétiques, réponses attendues, critères). La capture de contenu en production est opt-in et jamais rétroactive : sans traces enregistrées, pas de rejeu possible.

8.3 Stratégies de déploiement en production#

Pour un agent : chaque modification crée une agent version immuable ; l'agent endpoint sert par défaut Always use latest. Épingler la production sur une version (version_selector avec une règle FixedRatio à 100 %) avant de créer une version candidate, puis tester le candidat dans une session qui le cible.

Écart dans la doc (vérifié le 21/10/2026) : les pages What are hosted agents? et Manage hosted agents disent explicitement que le partage de trafic entre versions d'agent n'est pas pris en charge (une seule règle FixedRatio à 100 %, même si version_selection_rules est un tableau). La page Promote hosted agents to production with the Azure Developer CLI, marquée preview, montre pourtant un canary 90 / 10 avec azd ai agent endpoint update. Réponse d'examen : épingler, tester une session sur la version candidate (--version ou version_ref), promouvoir à 100 %, revenir ; le canary pondéré se fait de façon sûre dans la passerelle (API Management) ou entre deux deployments de modèle.

9. Provisioned throughput units#

Le fonctionnement des PTU (leaky bucket, 429 immédiat à 100 %, réservations non interchangeables) est au AI-103 · 03, section 2.4 et le spillover au AI-103 · 02, section 3.3. L'AI-300 attend surtout le dimensionnement.

9.1 La méthode de calcul#

• Input TPM = RPM de pointe × taille moyenne de l'invite
• Output TPM = RPM de pointe × taille moyenne de la réponse
• Normalized TPM = input TPM × (1 − taux de cache) + output-to-input ratio × output TPM
• PTU = normalized TPM ÷ Input TPM per PTU, arrondi au minimum ou à l'incrément du deployment type (le plus grand)

Exemple de la doc (gpt-5.2, Data Zone Provisioned, Input TPM per PTU 3 400, ratio 8) :

Valeurs par modèle (extrait de la page Determine PTU sizing, à revérifier pour le modèle choisi) :

Règles à connaître :

• Le ratio reflète l'écart de prix entre jetons de sortie et d'entrée (par exemple 8 pour gpt-5, 4 pour gpt-4.1) : générer coûte plus de capacité que lire.
• Jetons en cache : déduits à 100 % de l'utilisation, sauf pour les modèles à comptage normalisé (GPT-6 Astra, GPT-6 Sol, GPT-6.1 Sol), où entrée en cache et écritures de cache consomment de la capacité selon leur poids de prix.
• Pour les modèles antérieurs à GPT-4o, la forme des appels compte : quelques gros appels consomment plus que beaucoup de petits de même moyenne.
• Les requêtes de plus de 128K jetons d'invite ne sont pas prises en charge en PTU pour certains modèles (gpt-5.4, gpt-4.1…) : elles partent vers le spillover s'il existe, sinon en erreur.

9.2 La démarche d'exploitation#

1. Estimer avec le capacity calculator (page Quota du portail Foundry).
2. Demander le quota PTU (par région et par forme Global, Data Zone, Regional).
3. Créer le deployment avant d'acheter une reservation (elle ne garantit pas la capacité).
4. Lancer un benchmark sur la forme de trafic estimée pendant au moins 10 minutes (outil azure-openai-benchmark), puis avec votre propre client et sa logique de retry.
5. Surveiller Provisioned-managed Utilization V2 (découpé par deployment) et activer le spillover vers un deployment Standard.

# Un deployment Data Zone Provisioned de 110 PTU, avec spillover vers le deployment standard « chat »
az cognitiveservices account deployment create -n aif-support-prd -g rg-ai-prd \
  --deployment-name chat-ptu --model-name <modele> --model-version <version> --model-format OpenAI \
  --sku-name DataZoneProvisionedManaged --sku-capacity 110

L'activation du spillover (spilloverDeploymentName ou en-tête x-ms-spillover-deployment) est détaillée au AI-103 · 02, section 3.3.

10. Concevoir et développer des prompts#

Les techniques (system message, few-shot, délimiteurs, sortie structurée, décomposition, paramètres d'échantillonnage, reasoning models) sont au AI-103 · 07, section 2. Côté GenAIOps, un prompt se conçoit comme un composant d'agent :

Démarche recommandée (module Plan and prepare a GenAIOps solution) : écrire une agent specification avec ses critères de succès et un jeu de test, puis optimiser par petites itérations : après chaque retouche du prompt, des smoke tests rapides ; avant un changement important, une évaluation automatisée sur tout le jeu, toujours contre la même rubric.

Un prompt de production est structuré et testable. Exemple de progression du module Microsoft (agent « trail guide ») :

v1 : You are a trail guide assistant. Help users find hiking trails and provide basic safety advice.

v3 : You are an expert trail guide assistant with deep knowledge of hiking safety and trail conditions. When helping users plan hikes:
1. Assess their experience level and fitness
2. Consider weather and seasonal factors
3. Recommend appropriate trails with difficulty ratings
4. Provide comprehensive gear lists
5. Include safety protocols and emergency contacts
6. Suggest alternative options for different conditions
Always prioritize user safety and provide actionable, specific guidance.

Le Prompt Optimizer (bouton Optimize sous les instructions dans l'Agent playground, Foundry seulement) restructure les instructions selon les bonnes pratiques et explique chaque changement. Copier le prompt d'origine avant : il n'y a pas d'historique de versions dans l'outil, et le résultat se réévalue contre le jeu gelé.

11. Prompt variants : comparer les performances#

Comparer des variants, c'est changer une seule chose à la fois (prompt, modèle ou configuration) et mesurer contre la même rubric. Le workflow Git du module Evaluate and optimize AI agents through structured experiments :

1. Une branche par variant : experiment/prompt-v2-concise, experiment/prompt-v2-detailed, experiment/gpt4o-mini-model, experiment/token-optimization (main = baseline de production).
2. Prompts de test (5 à 10 scénarios, dont des cas limites : demande vague, informations manquantes) dans test-prompts/.
3. Déployer la version de l'agent (python agent.py), exécuter les prompts de test (python run-agent.py), garder les réponses (experiments/<variant>/agent-responses.json).
4. Noter sur 3 à 5 critères (intent resolution, relevance, groundedness…, échelle de 1 à 5) dans un evaluation.csv au même format que l'export d'évaluation du portail, pour pouvoir consolider manuel et automatique.
5. Comparer et décider : fusionner le gagnant dans main et taguer ; documenter les échecs (par exemple « gpt4o-mini : qualité sous le seuil de 4,2 sur les demandes complexes »).

git checkout main
git merge experiment/prompt-v2-concise
git tag promoted-to-prod-2026-02-17
git push origin main --tags

À l'échelle, la comparaison s'automatise : l'action GitHub microsoft/ai-agent-evals évalue plusieurs versions d'un agent (agent-ids: "support-agent:3,support-agent:4", la première sert de référence) et publie un rapport avec intervalles de confiance et comparaison statistique (AI-103 · 02, section 5). Les evaluators eux-mêmes sont au chapitre 06.

Prompt flow (variants dans un flow visuel) est retiré le 20 avril 2027 dans Foundry et Azure Machine Learning : plus recommandé pour un nouveau développement, migrer vers Microsoft Agent Framework. Ses images de runtime ne reçoivent plus de mises à jour de sécurité.

12. Versionner les prompts dans Git#

12.1 Où et sous quelle forme#

Structure de dépôt recommandée :

project-root/
├── src/agents/support_agent/
│   ├── support_agent.py        # script de déploiement de l'agent
│   └── prompts/
│       ├── v1_instructions.txt
│       ├── v2_instructions.txt
│       └── v3_instructions.txt
├── tests/                      # tests automatisés de l'agent
├── evals/dataset.json          # jeu d'évaluation
├── infra/main.bicep            # infrastructure
├── .github/workflows/          # test-agents.yml, deploy-agents.yml
└── .env                        # configuration locale, jamais committée

Conventions : noms en minuscules, versions dans les noms de fichiers (v1_, v2_), au plus trois niveaux de dossiers, src/, tests/ et infra/ séparés. Aligner la numérotation des fichiers sur les agent versions que Foundry attribue (1, 2, 3…) et poser un tag Git par déploiement : on retrouve immédiatement quel état du dépôt a produit quelle version.

12.2 Déployer une version depuis le fichier#

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

project = AIProjectClient(endpoint=os.environ["FOUNDRY_PROJECT_ENDPOINT"], credential=DefaultAzureCredential())

with open("src/agents/support_agent/prompts/v3_instructions.txt", encoding="utf-8") as f:
    instructions = f.read().strip()           # le prompt vient du fichier versionné, pas du portail

agent = project.agents.create_version(
    agent_name="support-agent",
    definition=PromptAgentDefinition(model=os.environ["MODEL_DEPLOYMENT_NAME"], instructions=instructions),
)
print(agent.name, agent.version)

for v in project.agents.list_versions(agent_name="support-agent"):   # historique côté Foundry
    print(v.version)

Le module Microsoft montre encore l'ancienne syntaxe (AIProjectClient.from_connection_string(...), agents.create_agent(...)) ; le SDK actuel utilise l'endpoint du project et agents.create_version.

12.3 Promouvoir et revenir en arrière#

Épingler la version servie par l'agent endpoint (API REST, application/merge-patch+json) :

PATCH {project-endpoint}/agents/support-agent?api-version=v1
Content-Type: application/merge-patch+json

{ "agent_endpoint": { "version_selector": { "version_selection_rules": [
    { "type": "FixedRatio", "agent_version": "3", "traffic_percentage": 100 } ] } } }

Le rollback consiste à ré-épingler la version précédente : aucune reconstruction, aucune nouvelle version.

sequenceDiagram
    actor D as Développeur
    participant G as GitHub
    participant CI as Pipeline (OIDC)
    participant F as Foundry project
    D->>G: branche feature/…, modifie v3_instructions.txt
    D->>G: pull request
    G->>CI: déclenche la CI
    CI->>F: create_version (version candidate)
    CI->>F: évaluation de la candidate contre la production épinglée
    F-->>CI: rapport avec intervalles de confiance
    CI-->>G: résultat dans la pull request
    D->>G: merge sur main et tag v3
    CI->>F: version_selector sur la version 3 (100 %)
    Note over F: si régression, ré-épingler la version 2

Cycle de vie d'un prompt selon le module Microsoft : Development → Validation → Review → Production → Monitoring, avec des branches feature/…, hotfix/… et experiment/…. Ne sauter aucune étape : chacune évite un incident de production.

13. Labs conseillés#

Dans un abonnement de test, région où les modèles visés existent. Supprimer le groupe de ressources à la fin ; ne pas créer de deployment PTU pour s'entraîner (facturation horaire dès la création, minimum 15 PTU en Global ou Data Zone).

Coût : quelques euros de jetons Global Standard pour les labs 1, 2 et 4 (plus les jetons du modèle juge des évaluations).

14. Pièges d'examen#

15. Scénarios d'entraînement#

1. Contoso a cinq équipes qui explorent des idées d'agents et deux cas d'usage financés pour la production, l'un sur des données RH sensibles. Quelle topologie Foundry ?

Une Foundry resource d'exploration partagée (un project par équipe, capacité limitée, données de test) ; pour la production, une Foundry resource par workload (RH isolée), avec leur propre réseau, quota, RBAC et coûts, et des environnements dev/test déployés par la même IaC.

2. L'équipe plateforme veut que les développeurs construisent des agents mais qu'ils ne puissent ni créer de model deployments ni modifier le réseau. Quels rôles ?

Foundry User pour les développeurs sur leur project ; Foundry Account Owner réservé au groupe des platform admins sur la Foundry resource. Désactiver les clés locales pour que tout passe par Entra ID.

3. Un modèle Qwen open source doit tourner sur GPU dédiés dans un réseau totalement privé, avec filtrage des contenus dangereux. Que faire ?

Managed compute (GlobalManagedCompute), avec un deployment template adapté (accélérateur, contexte) et du quota managed compute pour la famille d'accélérateur ; le réseau privé fonctionne sans sortie vers Hugging Face ; le filtrage se fait en appelant Azure AI Content Safety depuis l'application, faute de content filtering intégré en preview.

4. Le modèle d'un assistant de support (deployment Global Provisioned de 200 PTU) sera retiré dans quatre mois. Plan ?

Suivre le Model migration process : Assess (leaderboard, Compare, quota du modèle cible, disponibilité en Global Provisioned), Adapt (rejouer d'abord sans changement, puis adapter prompts, outils, schémas), Validate (jeu gelé, mêmes evaluators sur source et cible), Roll out (migration side-by-side ou in-place, canary dans la passerelle, continuous evaluation), Retire. Ne pas compter sur l'auto-upgrade : il n'existe pas en provisioned.

5. Une banque ne peut pas exposer un nouveau modèle à de vrais clients avant validation. Comment le tester sur le trafic réel ?

Shadow / mirror : le candidat traite des entrées de production hors ligne, on compare ses réponses à celles du modèle actuel sans affecter les clients ; l'ancien deployment reste le seul servi.

6. Un chatbot reçoit 2 000 RPM de pointe, 500 jetons d'invite et 50 de réponse, sur gpt-4.1 en Data Zone Provisioned (Input TPM per PTU 3 000, ratio 4). Combien de PTU ?

Input TPM 1 000 000, output TPM 100 000, normalized TPM = 1 000 000 + 4 × 100 000 = 1 400 000 ; 1 400 000 ÷ 3 000 = 466,7 → 470 PTU (incrément de 5) ; puis benchmark sur le trafic réel et spillover vers un Standard.

7. Une modification du prompt de l'agent a dégradé les réponses en production, et personne ne sait quelle version était avant. Quelles pratiques auraient évité cela ?

Prompts dans des fichiers versionnés (v2_instructions.txt), changements par branche et pull request avec évaluation automatique, tag Git aligné sur l'agent version, production épinglée par version_selector ; le rollback se résume alors à ré-épingler la version précédente.

8. Deux variants de prompt et un modèle plus petit sont candidats. Comment les comparer proprement ?

Une branche par variant, une seule modification par branche, les mêmes 5 à 10 prompts de test, la même rubric (3 à 5 critères, échelle 1 à 5) ; automatiser avec microsoft/ai-agent-evals sur les versions d'agent et lire les intervalles de confiance ; fusionner le gagnant et documenter les perdants.

9. La sécurité exige qu'aucun modèle en preview ni hors liste approuvée ne soit déployé en production. Comment l'imposer ?

Assigner les policies intégrées Foundry model deployments should only use approved models (publishers ou asset IDs) et … should meet eligibility requirements (denyPreviewModels = true) en Deny sur le groupe d'administration de production ; elles s'appliquent aussi aux modèles choisis par model router.

10. Le déploiement Bicep d'un environnement échoue avec ServiceModelDeprecating. Cause et correction ?

Le modèle ou la version déclarés sont retirés ou en cours de retrait ; mettre à jour name et version du deployment après avoir listé les modèles GA (az cognitiveservices model list --location … --query "[?model.lifecycleStatus=='GenerallyAvailable']").

16. Pour aller plus loin#

• AI Gateway au niveau de la Foundry resource : une passerelle API Management partagée par tous les projects de la resource, avec des token limits par project ; pour des passerelles séparées, des Foundry resources séparées (voir SC-500 · 07 pour l'AI gateway).
• Foundry control plane : surveillance d'une flotte de ressources, enregistrement d'agents personnalisés, gouvernance des outils MCP par une passerelle.
• Agent 365 : remontée des traces des agents Foundry, Copilot Studio et Microsoft 365 dans une observabilité centrale.
• Model router et policies : des définitions Azure Policy dédiées au model router existent en preview (régions, règles de routage, journalisation).
• Fine-tuning et entraînement de LLM : chapitre 07 et chapitre 08 (hors examen : KAITO sur AKS, voir AKS · 06).

17. Fiche à retenir#

• GenAIOps : Explore, Build, Operationalize + management loop ; on gère prompts, agents, données et évaluations.
• Resource = gouvernance (réseau, quota, deployments, CMK), project = équipe ; fine-tuning, image, vidéo, batch et Translator ne s'isolent pas par project.
• Exploration co-localisée, production isolée (une resource par workload) ; même IaC, autres paramètres.
• Création : --assign-identity, --allow-project-management (définitif), --custom-domain unique ; CLI 2.80+.
• Rôles : Foundry Account Owner (deployments), Project Manager (publie, ne déploie pas), Foundry User (plan de données) ; Owner/Contributor ne suffisent pas pour le plan de données.
• Keyless (disableLocalAuth), pipeline par workload identity federation, project managed identity vers les ressources connectées.
• Réseau : Private Endpoint en entrée ; managed VNet (Allow internet outbound / Allow only approved outbound, non réversibles) ou BYO VNet en sortie.
• Bicep : accounts (kind AIServices), accounts/projects, accounts/deployments ; foundry-samples ; Export template.
• Serverless API d'abord ; managed compute = open source sur GPU dédiés, template, GlobalManagedCompute, pas de content filtering, quota distinct des VM ; instant access = essai sans deployment.
• Choix du modèle : specification → filtres → leaderboard (safety : plus bas = mieux) → Compare → vos données → pilote.
• Policies approved models et eligibility requirements (Deny / Audit, 15 minutes).
• Retrait : Standard = auto-upgrade (versionUpgradeOption) ; Provisioned, Batch, fine-tuned = manuel ; remplaçant ~90 jours avant (30 en provisioned) ; dates non prolongeables.
• Migration : Discover, Assess, Adapt, Validate, Roll out, Retire ; jeu gelé ; canary, shadow, rollback corridor.
• PTU = normalized TPM ÷ Input TPM per PTU ; normalized = input × (1 − cache) + ratio × output ; arrondi au minimum ou à l'incrément ; calculator puis benchmark ≥ 10 minutes.
• Prompts : fichiers versionnés, branches, pull request + évaluation, tag = agent version, épingler la production, rollback = ré-épingler ; prompt flow retiré le 20/04/2027.

Références#

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

• Study guide for Exam AI-300
• Operationalize generative AI applications (GenAIOps) — learning path
• Plan and prepare a GenAIOps solution
• Manage prompts for agents in Microsoft Foundry with GitHub
• Evaluate and optimize AI agents through structured experiments
• Microsoft Foundry rollout across my organization
• Microsoft Foundry architecture
• Create a project for Microsoft Foundry
• Quickstart: Deploy a Microsoft Foundry resource by using a Bicep file
• Role-based access control for Microsoft Foundry
• Configure managed virtual network for Microsoft Foundry projects
• Configure private link for Microsoft Foundry
• Deployment overview for Microsoft Foundry Models
• Deployment types for Microsoft Foundry Models
• Managed compute in Microsoft Foundry (preview)
• Deploy open-source models with managed compute (preview)
• Model leaderboards in Microsoft Foundry portal (preview)
• Compare models using the model leaderboard (preview)
• Built-in policies for model deployment in Microsoft Foundry portal
• Model migration process
• Determine PTU sizing for a workload
• Get started using provisioned deployments
• Manage hosted agents
• Configure and share your agent
• Promote hosted agents to production with the Azure Developer CLI
• Get started with prompt flow (avis de retrait)