Foundry | The .NET Blog

Microsoft Foundry Avril 2026 : Foundry Local GA, GPT-5.5, CodeAct avec Hyperlight

Emiliano Montesdeoca — Tue, 02 Jun 2026 00:00:00 +0000

Un mois chargé pour Microsoft Foundry. Voici les annonces les plus importantes.

Foundry Local est Généralement Disponible

Foundry Local — le runtime d’IA local multiplateforme de Microsoft — passe de la préversion à la GA sur Windows, macOS (Apple Silicon) et Linux x64. Inférence de modèles locaux prête pour la production avec un SDK convivial pour les développeurs. La version 1.1 ajoute la transcription, les embeddings et la prise en charge de l’API Responses.

GPT-5.5

Le dernier modèle de la famille GPT-5 est maintenant disponible dans Foundry. Quota par défaut pour les abonnements Tier 5 et Tier 6. Si vous avez travaillé avec des variantes antérieures de GPT-5, cela vaut la peine d’être évalué pour vos cas d’utilisation.

Traçage d’Agent Framework dans Foundry

Deux fonctionnalités de traçage sont disponibles en préversion ce mois-ci :

Traçage de Microsoft Agent Framework — Les agents MAF peuvent maintenant émettre des traces OpenTelemetry dans Foundry. Déboguez le comportement des agents, tracez l’exécution en plusieurs étapes, exposez la latence et les erreurs dans les appels d’outils. Cela comble un vrai manque : savoir ce que votre agent a réellement fait en production, pas seulement ce qu’il a retourné.

Traçage des agents hébergés — Les sessions, appels d’outils et étapes d’exécution des agents hébergés apparaissent également dans les traces Foundry. La même histoire d’observabilité étendue au niveau hébergé.

CodeAct avec Hyperlight (Alpha)

C’est l’ajout techniquement le plus intéressant : Agent Framework peut désormais exécuter du code Python dans des micro-machines virtuelles Hyperlight.

CodeAct est le modèle où un agent génère et exécute du code Python comme outil. La préoccupation évidente est la sécurité — vous exécutez du code généré par le modèle. Les micro-VMs d’Hyperlight fournissent une isolation au niveau du processus avec un temps de démarrage proche du natif, rendant l’exécution de code en sandbox pratique sans la surcharge de conteneurs ou de VMs complets.

Pour les flux de travail agentiques où l’exécution de code est nécessaire, c’est une amélioration de sécurité significative par rapport à l’exécution de code dans le processus hôte.

Tableau de Bord de Surveillance des Agents (Préversion)

Un tableau de bord d’opérations unifié combinant l’utilisation des tokens, la latence, le taux de succès des exécutions et les scores des évaluateurs en une seule vue. La distinction par rapport aux tableaux de bord d’observabilité classiques : il inclut les résultats d’évaluation aux côtés des métriques opérationnelles, vous permettant de corréler « l’agent est plus lent » avec « les scores de l’évaluateur ont chuté » — ou de confirmer qu’ils ne sont pas liés.

Évaluateurs Personnalisés d’Évaluation Continue (Préversion)

Vous pouvez maintenant apporter vos propres évaluateurs basés sur du code ou des prompts dans les pipelines d’évaluation continue. Auparavant, l’évaluation continue était limitée aux évaluateurs intégrés. Les évaluateurs personnalisés vous permettent d’appliquer des critères de qualité spécifiques à votre équipe dans votre boucle de surveillance en production.

Inventaire des Agents dans le Plan de Contrôle

La vue Operate du Plan de Contrôle Foundry affiche désormais tous les agents pris en charge dans un abonnement : agents Foundry, Azure SRE Agent, boucles d’agents Logic Apps et agents personnalisés enregistrés. Une vue pour comprendre ce qui est déployé et où.

Publication originale : What’s new in Microsoft Foundry | April 2026

Votre Agent MAF Local Vient d'Obtenir une Maison en Production

Emiliano Montesdeoca — Sat, 30 May 2026 00:00:00 +0000

Faire fonctionner un agent localement est la partie amusante. La partie délicate est tout ce qui vient après : le déployer sans perdre la tête, gérer les sessions, configurer l’identité, câbler l’observabilité. Cela signifie généralement beaucoup d’infrastructure personnalisée.

Foundry Hosted Agents vient de supprimer la majeure partie de cette infrastructure pour les utilisateurs de Microsoft Agent Framework (MAF).

Ce que Foundry Hosted Agents Fait Vraiment

Lorsque vous déployez un agent MAF dans Foundry Hosted Agents, la plateforme gère une liste étonnamment longue de choses que vous auriez autrement à construire vous-même :

Mise à l’échelle à zéro — votre agent ne coûte rien en idle et redémarre automatiquement
Sandboxes isolés par VM par session — chaque session utilisateur obtient son propre sandbox avec persistance du système de fichiers qui survit aux événements de réduction d’échelle
Entra ID intégré — chaque agent obtient sa propre identité pour appeler les modèles Foundry, Toolbox et les services Azure sans secrets dans l’image
Déploiements versionnés — chaque déploiement est un instantané immuable, avec support de déploiement blue/green et canary
Observabilité sans configuration — APPLICATIONINSIGHTS_CONNECTION_STRING est injecté au runtime pour que les traces OpenTelemetry de MAF s’écoulent automatiquement dans App Insights

Ce dernier point est vraiment appréciable. Pas de câblage supplémentaire, pas de configuration additionnelle. Les traces apparaissent simplement.

La Différence de Code Est Minime

C’est ce que j’apprécie le plus dans cette intégration. Vous ne réécrivez pas votre agent. Vous l’encapsulez simplement :

En .NET :

using Microsoft.Agents.AI.Foundry.Hosting;

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddFoundryResponses(agent);

var app = builder.Build();
app.MapFoundryResponses();

app.Run();

En Python :

server = ResponsesHostServer(agent)
server.run()

C’est tout. La même logique que vous avez testée localement est ce qui s’exécute en production. La plateforme l’encapsule dans l’infrastructure de gestion de sessions, d’identité et de scaling.

Deux Protocoles, Un Agent

Les Hosted Agents supportent deux styles d’endpoints :

Responses (/responses) — compatible OpenAI, gère l’historique des conversations et le streaming. Bon défaut pour les agents de type chat.
Invocations (/invocations) — vous définissez le schéma requête/réponse. Bon pour les workflows non conversationnels.

Si vous construisez quelque chose qui ressemble à une conversation, commencez avec Responses. Si vous construisez un agent de type API qui prend une entrée structurée et retourne une sortie structurée, Invocations vous donne la flexibilité.

Le Flux de Déploiement avec `azd`

Lorsque vous exécutez azd up avec un agent MAF :

Crée optionnellement un projet Foundry et déploie un modèle
Empaquette votre code et pousse une image vers Azure Container Registry
Provisionne du calcul depuis l’image ACR
Attribue un Entra ID dédié à l’agent
Expose un endpoint stable (https://{project_endpoint}/agents/{agent_name})
Gère tout le reste à partir de ce point

Les sessions persistent jusqu’à 30 jours. Le calcul inactif est déprovisionné après 15 minutes et restauré transparemment sur la prochaine requête. Du point de vue de l’agent, rien n’a changé.

Conclusion

La distance entre “fonctionnant localement” et “s’exécutant en production” a toujours été longue et douloureuse pour les agents IA. Foundry Hosted Agents + MAF réduit considérablement cet écart. Si vous avez déjà un agent local construit avec Agent Framework, cela vaut la peine d’essayer aujourd’hui.

L’équipe annonce que GA arrive bientôt — c’est actuellement en preview. Consultez les docs d’intégration MAF Hosted Agent et les exemples .NET pour démarrer.

Article original : From Local to Production: Deploy Your Microsoft Agent Framework Agent with Foundry Hosted Agents

Foundry Local 1.1 : Transcription en Temps Réel, Embeddings et l'API de Réponses

Emiliano Montesdeoca — Thu, 28 May 2026 00:00:00 +0000

Foundry Local 1.0 a prouvé le concept : exécuter des modèles d’IA localement sur Windows, macOS (Apple Silicon) et Linux x64 avec un SDK adapté aux développeurs. La version 1.1 ajoute trois capacités qui couvrent de nombreux cas d’usage réels en production.

Transcription Audio en Direct

La nouvelle fonctionnalité la plus significative : le streaming de parole en texte en temps réel directement depuis le microphone. Sous-titres, interfaces vocales, transcription de réunions, outils d’accessibilité — tout s’exécutant localement sans aucune dépendance cloud.

L’API est basée sur des sessions et transmet les résultats au fur et à mesure qu’ils arrivent, avec des marqueurs is_final pour distinguer le texte intermédiaire du texte finalisé. Disponible pour toutes les liaisons de langages : JavaScript, C#, Python et Rust.

Chargez un modèle de parole en streaming depuis le catalogue, créez une session avec les paramètres audio (fréquence d’échantillonnage, canaux, langue), lancez-la, poussez des blocs audio PCM bruts et consommez le flux asynchrone de résultats. Le post contient des exemples complets en Python et C#.

Embeddings de Texte

Recherche sémantique, pipelines RAG, clustering, correspondance de similarité — tout cela nécessite des embeddings. Foundry Local 1.1 ajoute le support des modèles d’embedding pour générer des vecteurs localement depuis le même SDK, sans envoyer de données vers un endpoint cloud.

Pour les applications où la résidence des données est importante ou où vous traitez du contenu sensible, la génération locale d’embeddings est une capacité significative.

API de Réponses

Foundry Local prend maintenant en charge l’API de Réponses — l’interface structurée conçue pour les interactions agentiques. Cela ajoute :

Appel d’outils — laissez les modèles s’exécutant localement invoquer des outils que vous définissez
Entrée multimodale vision-langage — passez image + texte à des modèles capables de vision
Compatible avec la forme d’API standard, donc les agents existants ciblant l’API de Réponses d’OpenAI fonctionnent contre des modèles locaux

Améliorations de la Taille du Paquet

Deux changements réduisent la taille du paquet JavaScript :

La couche FFI koffi a été remplacée par un addon C Node-API personnalisé
Le fournisseur d’exécution WebGPU est livré comme plugin séparé, donc les applications qui n’ont pas besoin d’accélération GPU ne paient pas le coût de taille

Le SDK C# cible maintenant des versions de framework inférieures pour une compatibilité .NET plus large.

Pourquoi C’est Important

Les trois capacités ensemble — transcription, embeddings, appel d’outils — couvrent les blocs de construction essentiels de nombreuses applications d’IA. Les exécuter localement signifie :

Pas d’internet requis
Pas de coûts par token
Aucune donnée ne quitte la machine
Latence constante quelles que soient les conditions réseau

Foundry Local est le bon choix pour les scénarios en périphérie, les charges de travail sensibles à la vie privée, les applications hors ligne, ou tout ce où vous voulez éviter la dépendance cloud pendant le développement.

Post original : Foundry Local 1.1: Live Transcription, Embeddings, and Responses API

GPT-5.5 Est Là et Arrive dans Azure Foundry — Ce que les Développeurs .NET Doivent Savoir

Emiliano Montesdeoca — Sat, 25 Apr 2026 00:00:00 +0000

Ce post a été traduit automatiquement. Pour la version originale, cliquez ici.

Microsoft vient d’annoncer que GPT-5.5 est généralement disponible dans Microsoft Foundry. Si vous avez été en train de créer des agents sur Azure, c’est la mise à jour que vous attendiez.

La progression de GPT-5

GPT-5 : a unifié le raisonnement et la vitesse en un seul système
GPT-5.4 : raisonnement multi-étapes plus solide, capacités agentiques pour l’entreprise
GPT-5.5 : raisonnement en contexte long plus profond, exécution agentique plus fiable, meilleure efficacité des tokens

Ce qui a vraiment changé

Codage agentique amélioré : GPT-5.5 maintient le contexte sur de grandes bases de code, diagnostique les défaillances architecturales et anticipe les exigences de tests. Le modèle raisonne sur ce que d’autre une correction affecte avant d’agir.

Efficacité des tokens : Des sorties de meilleure qualité avec moins de tokens et moins de tentatives. Coût et latence directement réduits en production.

Analyse en contexte long : Gère de vastes documents et des historiques multi-sessions sans perdre le fil.

Tarification

Modèle	Entrée ($/M tokens)	Entrée en cache	Sortie ($/M tokens)
GPT-5.5	5,00 $	0,50 $	30,00 $
GPT-5.5 Pro	30,00 $	3,00 $	180,00 $

Pourquoi Foundry est important

Foundry Agent Service vous permet de définir des agents en YAML ou de les connecter avec Microsoft Agent Framework, GitHub Copilot SDK, LangGraph ou OpenAI Agents SDK — et de les exécuter comme agents hébergés isolés avec un système de fichiers persistant, une identité Microsoft Entra distincte et une tarification à l’échelle zéro.

AIAgent agent = aiProjectClient
 .AsAIAgent("gpt-5.5", instructions: "Vous êtes un assistant utile.", name: "MonAgent");

Consultez l’annonce complète pour tous les détails.

Le RFT de Foundry est désormais moins cher et plus intelligent — Voici ce qui a changé

Emiliano Montesdeoca — Sat, 18 Apr 2026 00:00:00 +0000

Cet article a été traduit automatiquement. Pour la version originale, cliquez ici.

Si vous développez des applications .NET qui reposent sur des modèles fine-tunés, les mises à jour Foundry de ce mois méritent votre attention. Le Reinforcement Fine-Tuning est devenu plus accessible et nettement moins cher.

Les détails complets sont dans l’annonce officielle, mais voici le résumé pratique.

Entraînement Global pour o4-mini

o4-mini est le modèle de référence pour les charges de travail intensives en raisonnement et agentiques. La grande nouvelle : vous pouvez désormais lancer des jobs de fine-tuning depuis plus de 13 régions Azure avec des tarifs d’entraînement par token inférieurs par rapport à l’entraînement Standard. Même infrastructure, même qualité, plus grande portée.

Si votre équipe est répartie géographiquement, c’est important. Vous n’êtes plus limité à une poignée de régions pour entraîner.

Voici l’appel API REST pour lancer un job d’entraînement global :

curl -X POST "https://<your-resource>.openai.azure.com/openai/fine_tuning/jobs?api-version=2025-04-01-preview" \
 -H "Content-Type: application/json" \
 -H "api-key: $AZURE_OPENAI_API_KEY" \
 -d '{
 "model": "o4-mini",
 "training_file": "<your-training-file-id>",
 "method": {
 "type": "reinforcement",
 "reinforcement": {
 "grader": {
 "type": "string_check",
 "name": "answer-check",
 "input": "{{sample.output_text}}",
 "reference": "{{item.reference_answer}}",
 "operation": "eq"
 }
 }
 },
 "hyperparameters": {
 "n_epochs": 2,
 "compute_multiplier": 1.0
 },
 "trainingType": "globalstandard"
 }'

Ce flag trainingType: globalstandard fait toute la différence.

Nouveaux Évaluateurs de Modèle : Famille GPT-4.1

Les évaluateurs définissent le signal de récompense contre lequel votre modèle optimise. Jusqu’à présent, les évaluateurs basés sur des modèles étaient limités à un ensemble restreint de modèles. Vous avez maintenant trois nouvelles options : GPT-4.1, GPT-4.1-mini et GPT-4.1-nano.

Quand faut-il utiliser des évaluateurs de modèle plutôt que des déterministes ? Quand la sortie de votre tâche est ouverte, quand vous avez besoin de notation partielle sur plusieurs dimensions, ou quand vous construisez des workflows agentiques où la justesse des appels d’outils dépend du contexte sémantique.

Le truc, c’est que la stratégie de niveaux est pratique :

GPT-4.1-nano pour les premières itérations. Coût faible, boucles de feedback rapides.
GPT-4.1-mini une fois que votre grille d’évaluation est stable et que vous avez besoin de plus de fidélité.
GPT-4.1 pour l’évaluation en production ou les grilles complexes où chaque décision de notation compte.

Vous pouvez même mixer les types d’évaluateurs dans un seul job RFT. Utilisez le string-match pour la dimension “bonne réponse” et un évaluateur de modèle pour évaluer la qualité du raisonnement. Cette flexibilité est honnêtement ce qui le rend utile pour des charges de travail réelles.

Le Piège du Format de Données RFT

C’est ce qui fait trébucher les gens. Le format de données RFT est différent du SFT. Le dernier message de chaque ligne doit avoir le rôle User ou Developer — pas Assistant. La réponse attendue va dans une clé de niveau supérieur comme reference_answer que l’évaluateur référence directement.

Si vous faisiez du supervised fine-tuning et que vous voulez passer au RFT, vous devez restructurer vos données d’entraînement. Ne sautez pas cette étape ou vos jobs échoueront silencieusement.

Pourquoi C’est Important pour les Développeurs .NET

Si vous appelez des modèles fine-tunés depuis vos applications .NET via le SDK Azure OpenAI, un entraînement moins cher signifie que vous pouvez itérer plus agressivement. Les options d’évaluateurs de modèle signifient que vous pouvez fine-tuner pour des tâches nuancées — pas seulement des scénarios de correspondance exacte. Et le guide de bonnes pratiques sur GitHub vous fera gagner un temps réel de débogage.

Commencez petit. Dix à cent échantillons. Évaluateur simple. Validez la boucle. Puis montez en charge.

Connectez vos serveurs MCP sur Azure Functions aux agents Foundry — Voici comment

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

Cet article a été traduit automatiquement. Pour la version originale, cliquez ici.

Voici ce que j’adore dans l’écosystème MCP : vous construisez votre serveur une fois, et il fonctionne partout. VS Code, Visual Studio, Cursor, ChatGPT — chaque client MCP peut découvrir et utiliser vos outils. Maintenant, Microsoft ajoute un autre consommateur à cette liste : les agents Foundry.

Lily Ma de l’équipe Azure SDK a publié un guide pratique sur la connexion de serveurs MCP déployés sur Azure Functions avec les agents Microsoft Foundry. Si vous avez déjà un serveur MCP, c’est de la valeur ajoutée pure — aucune reconstruction nécessaire.

Pourquoi cette combinaison a du sens

Azure Functions vous offre une infrastructure évolutive, une authentification intégrée et une facturation serverless pour héberger des serveurs MCP. Microsoft Foundry vous offre des agents IA capables de raisonner, planifier et agir. Les connecter signifie que vos outils personnalisés — interroger une base de données, appeler une API métier, exécuter une logique de validation — deviennent des capacités que les agents IA d’entreprise peuvent découvrir et utiliser de manière autonome.

Le point clé : votre serveur MCP reste le même. Vous ajoutez simplement Foundry comme un autre consommateur. Les mêmes outils qui fonctionnent dans votre configuration VS Code alimentent maintenant un agent IA avec lequel votre équipe ou vos clients interagissent.

Options d’authentification

C’est là que l’article apporte vraiment de la valeur. Quatre méthodes d’authentification selon votre scénario :

Méthode	Cas d’usage
Basée sur clé (par défaut)	Développement ou serveurs sans auth Entra
Microsoft Entra	Production avec identités managées
Passthrough d’identité OAuth	Production où chaque utilisateur s’authentifie individuellement
Sans authentification	Dev/tests ou données publiques uniquement

Pour la production, Microsoft Entra avec identité d’agent est le chemin recommandé. Le passthrough d’identité OAuth est pour les cas où le contexte utilisateur compte — l’agent demande aux utilisateurs de se connecter, et chaque requête porte le propre token de l’utilisateur.

Mise en place

Le flux général :

Déployez votre serveur MCP sur Azure Functions — des exemples sont disponibles pour .NET, Python, TypeScript et Java
Activez l’authentification MCP intégrée sur votre function app
Obtenez votre URL d’endpoint — https://<FUNCTION_APP_NAME>.azurewebsites.net/runtime/webhooks/mcp
Ajoutez le serveur MCP comme outil dans Foundry — naviguez vers votre agent dans le portail, ajoutez un nouvel outil MCP, fournissez l’endpoint et les credentials

Testez ensuite dans le playground de l’Agent Builder en envoyant un prompt qui déclenchera l’un de vos outils.

Mon avis

L’histoire de la composabilité devient vraiment solide ici. Construisez votre serveur MCP une fois en .NET (ou Python, TypeScript, Java), déployez-le sur Azure Functions, et chaque client compatible MCP peut l’utiliser — outils de programmation, apps de chat, et maintenant agents IA d’entreprise. C’est un pattern « écrire une fois, utiliser partout » qui fonctionne réellement.

Pour les développeurs .NET spécifiquement, l’extension MCP Azure Functions rend les choses simples. Vous définissez vos outils comme des Azure Functions, vous déployez, et vous avez un serveur MCP prêt pour la production avec toute la sécurité et la scalabilité qu’Azure Functions fournit.

Pour conclure

Si vous avez des outils MCP qui tournent sur Azure Functions, les connecter aux agents Foundry est un gain rapide — vos outils personnalisés deviennent des capacités IA d’entreprise avec une authentification appropriée et sans modification de code côté serveur.

Lisez le guide complet pour des instructions pas à pas sur chaque méthode d’authentification, et consultez la documentation détaillée pour les configurations de production.

Microsoft Foundry Mars 2026 — GPT-5.4, Agent Service en GA et la Refonte du SDK Qui Change Tout

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

Cet article a été traduit automatiquement. Pour la version originale, cliquez ici.

Les posts mensuels « Quoi de neuf dans Microsoft Foundry » sont généralement un mélange d’améliorations incrémentales et de fonctionnalités phares occasionnelles. L’édition de mars 2026 ? C’est pratiquement que des fonctionnalités phares. Foundry Agent Service passe en GA, GPT-5.4 arrive en production, le SDK reçoit une version stable majeure, et Fireworks AI apporte l’inférence de modèles ouverts sur Azure. Voyons ce qui compte pour les développeurs .NET.

Foundry Agent Service est prêt pour la production

C’est la grande nouvelle. Le runtime d’agents de nouvelle génération est en disponibilité générale — construit sur l’API Responses d’OpenAI, compatible au niveau du protocole avec les agents OpenAI, et ouvert aux modèles de plusieurs fournisseurs. Si vous construisez avec l’API Responses aujourd’hui, migrer vers Foundry ajoute la sécurité entreprise, le réseau privé, le RBAC Entra, le traçage complet et l’évaluation par-dessus votre logique d’agent existante.

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

project_client = AIProjectClient(
 endpoint=os.environ["AZURE_AI_PROJECT_ENDPOINT"],
 credential=DefaultAzureCredential()
)

agent = project_client.agents.create_version(
 agent_name="my-enterprise-agent",
 definition=PromptAgentDefinition(
 model=os.environ["AZURE_AI_MODEL_DEPLOYMENT_NAME"],
 instructions="You are a helpful assistant.",
 ),
)

Ajouts clés : réseau privé de bout en bout, extension de l’authentification MCP (y compris le passthrough OAuth), aperçu de Voice Live pour les agents voix-à-voix, et agents hébergés dans 6 nouvelles régions.

GPT-5.4 — la fiabilité plutôt que l’intelligence brute

GPT-5.4 n’est pas question d’être plus intelligent. C’est une question de fiabilité. Un raisonnement plus solide sur de longues interactions, une meilleure adhérence aux instructions, moins d’échecs en cours de workflow, et des capacités intégrées d’utilisation d’ordinateur. Pour les agents en production, cette fiabilité compte bien plus que les scores de benchmarks.

Modèle	Tarif (par M tokens)	Idéal pour
GPT-5.4 (≤272K)	$2.50 / $15 sortie	Agents en production, code, workflows documentaires
GPT-5.4 Pro	$30 / $180 sortie	Analyse approfondie, raisonnement scientifique
GPT-5.4 Mini	Économique	Classification, extraction, appels d’outils légers

La stratégie intelligente est le routage : GPT-5.4 Mini gère le travail à haut volume et faible latence tandis que GPT-5.4 prend les requêtes nécessitant un raisonnement intensif.

Le SDK est enfin stable

Le SDK azure-ai-projects a publié des versions stables dans tous les langages — Python 2.0.0, JS/TS 2.0.0, Java 2.0.0, et .NET 2.0.0 (1er avril). La dépendance azure-ai-agents a disparu — tout vit sous AIProjectClient. Installez avec pip install azure-ai-projects et le paquet inclut openai et azure-identity comme dépendances directes.

Pour les développeurs .NET, cela signifie un seul paquet NuGet pour toute la surface Foundry. Fini le jonglage entre des SDKs d’agents séparés.

Fireworks AI amène les modèles ouverts sur Azure

Peut-être l’ajout le plus intéressant architecturalement : Fireworks AI traitant plus de 13 billions de tokens par jour à ~180K requêtes/seconde, maintenant disponible via Foundry. DeepSeek V3.2, gpt-oss-120b, Kimi K2.5, et MiniMax M2.5 au lancement.

La vraie histoire est le bring-your-own-weights — téléchargez des poids quantifiés ou fine-tunés depuis n’importe où sans changer la pile de service. Déployez en mode serverless pay-per-token ou en débit provisionné.

Autres points forts

Phi-4 Reasoning Vision 15B — raisonnement multimodal pour graphiques, diagrammes et mises en page de documents
Evaluations GA — évaluateurs prêts à l’emploi avec surveillance continue de production intégrée à Azure Monitor
Priority Processing (Preview) — voie de calcul dédiée pour les charges de travail sensibles à la latence
Voice Live — runtime voix-à-voix connecté directement aux agents Foundry
Tracing GA — inspection de bout en bout des traces d’agents avec tri et filtrage
Dépréciation de PromptFlow — migration vers Microsoft Framework Workflows d’ici janvier 2027

Conclusion

Mars 2026 est un tournant pour Foundry. Agent Service en GA, SDKs stables dans tous les langages, GPT-5.4 pour des agents de production fiables, et inférence de modèles ouverts via Fireworks AI — la plateforme est prête pour des charges de travail sérieuses.

Lisez le récapitulatif complet et créez votre premier agent pour commencer.

Du laptop à la production : déployer des agents IA sur Microsoft Foundry en deux commandes

Emiliano Montesdeoca — Thu, 26 Mar 2026 00:00:00 +0000

Vous connaissez ce fossé entre “ça marche sur ma machine” et “c’est déployé et sert du trafic” ? Pour les agents IA, ce fossé a été douloureusement large. Il faut provisionner des ressources, déployer des modèles, configurer l’identité, mettre en place le monitoring — et tout ça avant que quiconque puisse réellement appeler votre agent.

L’Azure Developer CLI vient d’en faire une affaire de deux commandes.

Le nouveau workflow `azd ai agent`

Laissez-moi vous montrer ce que ça donne concrètement. Vous avez un projet d’agent IA — disons un agent concierge d’hôtel. Il fonctionne en local. Vous voulez qu’il tourne sur Microsoft Foundry.

azd ai agent init
azd up

C’est tout. Deux commandes. azd ai agent init génère l’infrastructure-as-code dans votre repo, et azd up provisionne tout sur Azure et publie votre agent. Vous obtenez un lien direct vers votre agent dans le portail Foundry.

Ce qui se passe sous le capot

La commande init génère de vrais templates Bicep inspectables dans votre repo :

Une Foundry Resource (conteneur de niveau supérieur)
Un Foundry Project (où vit votre agent)
Configuration du déploiement de modèle (GPT-4o, etc.)
Identité managée avec les attributions de rôles RBAC appropriées
azure.yaml pour la carte des services
agent.yaml avec les métadonnées de l’agent et les variables d’environnement

Le point clé : tout cela vous appartient. C’est du Bicep versionné dans votre repo. Vous pouvez l’inspecter, le personnaliser et le commiter aux côtés du code de votre agent. Pas de boîtes noires magiques.

La boucle interne de développement

Ce que j’aime vraiment, c’est l’expérience de développement local. Quand vous itérez sur la logique de l’agent, vous ne voulez pas redéployer à chaque modification d’un prompt :

azd ai agent run

Cela démarre votre agent localement. Combinez-le avec azd ai agent invoke pour envoyer des prompts de test, et vous avez une boucle de feedback rapide. Modifier le code, redémarrer, invoquer, répéter.

La commande invoke est intelligente pour le routage aussi — quand un agent local tourne, elle le cible automatiquement. Sinon, elle va vers l’endpoint distant.

Monitoring en temps réel

C’est la fonctionnalité qui m’a convaincu. Une fois votre agent déployé :

azd ai agent monitor --follow

Chaque requête et réponse transitant par votre agent est streamée vers votre terminal en temps réel. Pour déboguer des problèmes en production, c’est inestimable. Plus besoin de fouiller dans les Log Analytics, plus d’attente pour l’agrégation des métriques — vous voyez ce qui se passe maintenant.

L’ensemble complet des commandes

Voici la référence rapide :

Commande	Ce qu’elle fait
`azd ai agent init`	Scaffold d’un projet agent Foundry avec IaC
`azd up`	Provisionne les ressources Azure et déploie l’agent
`azd ai agent invoke`	Envoie des prompts à l’agent distant ou local
`azd ai agent run`	Exécute l’agent localement pour le développement
`azd ai agent monitor`	Streame les logs en temps réel de l’agent publié
`azd ai agent show`	Vérifie la santé et le statut de l’agent
`azd down`	Nettoie toutes les ressources Azure

Pourquoi c’est important pour les développeurs .NET

Même si l’exemple de l’annonce est basé sur Python, l’histoire de l’infrastructure est agnostique au langage. Votre agent .NET bénéficie du même scaffolding Bicep, de la même configuration d’identité managée, du même pipeline de monitoring. Et si vous utilisez déjà azd pour vos apps .NET Aspire ou vos déploiements Azure, ça s’intègre directement dans votre workflow existant.

Le fossé de déploiement pour les agents IA a été l’un des plus grands points de friction dans l’écosystème. Passer d’un prototype fonctionnel à un endpoint de production avec identité, réseau et monitoring appropriés ne devrait pas nécessiter une semaine de travail DevOps. Maintenant il faut deux commandes et quelques minutes.

Pour conclure

azd ai agent est disponible maintenant. Si vous avez repoussé le déploiement de vos agents IA parce que la mise en place de l’infrastructure semblait trop de travail, essayez. Consultez le walkthrough complet pour le guide étape par étape incluant l’intégration d’une app de chat frontend.

Foundry Agent Service est GA : Ce qui compte vraiment pour les développeurs d'agents .NET

Emiliano Montesdeoca — Thu, 26 Mar 2026 00:00:00 +0000

Soyons honnêtes — construire un prototype d’agent IA est la partie facile. La partie difficile, c’est tout ce qui suit : le mettre en production avec un isolement réseau approprié, exécuter des évaluations qui signifient réellement quelque chose, gérer les exigences de conformité, et ne rien casser à 2h du matin.

Le Foundry Agent Service vient de passer en GA, et cette version est focalisée comme un laser sur ce fossé du “tout ce qui suit”.

Construit sur la Responses API

Le titre principal : le Foundry Agent Service de nouvelle génération est construit sur l’OpenAI Responses API. Si vous construisez déjà avec ce protocole, migrer vers Foundry nécessite des changements de code minimaux. Ce que vous gagnez : sécurité entreprise, réseau privé, RBAC Entra, traçabilité complète et évaluation — par-dessus votre logique d’agent existante.

L’architecture est intentionnellement ouverte. Vous n’êtes pas verrouillé à un fournisseur de modèle ou un framework d’orchestration. Utilisez DeepSeek pour la planification, OpenAI pour la génération, LangGraph pour l’orchestration — le runtime gère la couche de cohérence.

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

with (
 DefaultAzureCredential() as credential,
 AIProjectClient(endpoint=os.environ["AZURE_AI_PROJECT_ENDPOINT"],
 credential=credential) as project_client,
 project_client.get_openai_client() as openai_client,
):
 agent = project_client.agents.create_version(
 agent_name="my-enterprise-agent",
 definition=PromptAgentDefinition(
 model=os.environ["AZURE_AI_MODEL_DEPLOYMENT_NAME"],
 instructions="You are a helpful assistant.",
 ),
 )

 conversation = openai_client.conversations.create()
 response = openai_client.responses.create(
 conversation=conversation.id,
 input="What are best practices for building AI agents?",
 extra_body={
 "agent_reference": {"name": agent.name, "type": "agent_reference"}
 },
 )
 print(response.output_text)

Si vous venez du package azure-ai-agents, les agents sont maintenant des opérations de première classe sur AIProjectClient dans azure-ai-projects. Supprimez la dépendance standalone et utilisez get_openai_client() pour piloter les réponses.

Réseau privé : le bloqueur entreprise supprimé

C’est la fonctionnalité qui débloque l’adoption enterprise. Foundry supporte maintenant le réseau privé complet de bout en bout avec BYO VNet :

Aucun egress public — le trafic de l’agent ne touche jamais l’internet public
Injection de conteneurs/sous-réseaux dans votre réseau pour la communication locale
Connectivité des outils incluse — serveurs MCP, Azure AI Search, agents de données Fabric fonctionnent tous sur des chemins privés

Ce dernier point est critique. Ce ne sont pas seulement les appels d’inférence qui restent privés — chaque invocation d’outil et appel de récupération reste aussi à l’intérieur de votre périmètre réseau. Pour les équipes opérant sous des politiques de classification de données qui interdisent le routage externe, c’est ce qui manquait.

Authentification MCP bien faite

Les connexions aux serveurs MCP supportent maintenant le spectre complet des patterns d’authentification :

Méthode d’auth	Quand l’utiliser
Basée sur clé	Accès partagé simple pour les outils internes à l’organisation
Entra Agent Identity	Service à service ; l’agent s’authentifie comme lui-même
Entra Managed Identity	Isolation par projet ; pas de gestion de credentials
OAuth Identity Passthrough	Accès délégué par utilisateur ; l’agent agit au nom des utilisateurs

OAuth Identity Passthrough est le plus intéressant. Quand les utilisateurs doivent donner à un agent l’accès à leurs données personnelles — leur OneDrive, leur organisation Salesforce, une API SaaS scopée par utilisateur — l’agent agit en leur nom avec des flux OAuth standard. Pas d’identité système partagée prétendant être tout le monde.

Voice Live : voix à voix sans la plomberie

Ajouter la voix à un agent signifiait auparavant assembler STT, LLM et TTS — trois services, trois sauts de latence, trois surfaces de facturation, le tout synchronisé à la main. Voice Live condense tout ça en une seule API managée avec :

Détection sémantique de l’activité vocale et de fin de tour (comprend le sens, pas juste le silence)
Suppression du bruit et annulation d’écho côté serveur
Support du barge-in (les utilisateurs peuvent interrompre en pleine réponse)

Les interactions vocales passent par le même runtime d’agent que le texte. Mêmes évaluateurs, mêmes traces, même visibilité des coûts. Pour le support client, le service terrain ou les scénarios d’accessibilité, ça remplace ce qui nécessitait auparavant un pipeline audio personnalisé.

Évaluations : de la case à cocher au monitoring continu

C’est là que Foundry devient sérieux sur la qualité en production. Le système d’évaluation a maintenant trois couches :

Évaluateurs prêts à l’emploi — cohérence, pertinence, fondement, qualité de récupération, sécurité. Connectez à un dataset ou au trafic en direct et obtenez des scores.
Évaluateurs personnalisés — encodez votre propre logique métier, standards de ton et règles de conformité spécifiques au domaine.
Évaluation continue — Foundry échantillonne le trafic de production en direct, exécute votre suite d’évaluateurs et affiche les résultats dans des tableaux de bord. Configurez des alertes Azure Monitor pour quand le fondement baisse ou que les seuils de sécurité sont dépassés.

Tout est publié dans Azure Monitor Application Insights. Qualité de l’agent, santé de l’infrastructure, coûts et télémétrie applicative — tout au même endroit.

eval_object = openai_client.evals.create(
 name="Agent Quality Evaluation",
 data_source_config=DataSourceConfigCustom(
 type="custom",
 item_schema={
 "type": "object",
 "properties": {"query": {"type": "string"}},
 "required": ["query"],
 },
 include_sample_schema=True,
 ),
 testing_criteria=[
 {
 "type": "azure_ai_evaluator",
 "name": "fluency",
 "evaluator_name": "builtin.fluency",
 "initialization_parameters": {
 "deployment_name": os.environ["AZURE_AI_MODEL_DEPLOYMENT_NAME"]
 },
 "data_mapping": {
 "query": "{{item.query}}",
 "response": "{{sample.output_text}}",
 },
 },
 ],
)

Six nouvelles régions pour les agents hébergés

Les agents hébergés sont maintenant disponibles dans East US, North Central US, Sweden Central, Southeast Asia, Japan East et plus. C’est important pour les exigences de résidence des données et pour comprimer la latence quand votre agent tourne près de ses sources de données.

Pourquoi c’est important pour les développeurs .NET

Même si les exemples de code dans l’annonce GA sont Python-first, l’infrastructure sous-jacente est agnostique au langage — et le SDK .NET pour azure-ai-projects suit les mêmes patterns. La Responses API, le framework d’évaluation, le réseau privé, l’auth MCP — tout cela est disponible depuis .NET.

Si vous attendiez que les agents IA passent de “démo cool” à “je peux réellement livrer ça au travail”, cette version GA est le signal. Réseau privé, authentification appropriée, évaluation continue et monitoring de production sont les pièces qui manquaient.

Pour conclure

Foundry Agent Service est disponible maintenant. Installez le SDK, ouvrez le portail et commencez à construire. Le guide de démarrage rapide vous amène de zéro à un agent en fonctionnement en quelques minutes.

Pour le deep-dive technique complet avec tous les exemples de code, consultez l’annonce GA.

Le serveur MCP Azure DevOps débarque dans Microsoft Foundry : ce que ça signifie pour vos agents IA

Emiliano Montesdeoca — Thu, 26 Mar 2026 00:00:00 +0000

MCP (Model Context Protocol) a le vent en poupe. Si vous suivez l’écosystème des agents IA, vous avez probablement remarqué que les serveurs MCP apparaissent partout — donnant aux agents la capacité d’interagir avec des outils et services externes via un protocole standardisé.

Maintenant le serveur MCP Azure DevOps est disponible dans Microsoft Foundry, et c’est une de ces intégrations qui fait réfléchir aux possibilités pratiques.

Ce qui se passe réellement ici

Microsoft a déjà publié le serveur MCP Azure DevOps en public preview — c’est le serveur MCP lui-même. La nouveauté, c’est l’intégration Foundry. Vous pouvez maintenant ajouter le serveur MCP Azure DevOps à vos agents Foundry directement depuis le catalogue d’outils.

Pour ceux qui ne connaissent pas encore Foundry : c’est la plateforme unifiée de Microsoft pour construire et gérer des applications et agents alimentés par l’IA à grande échelle. Accès aux modèles, orchestration, évaluation, déploiement — tout au même endroit.

La mise en place

La configuration est étonnamment simple :

Dans votre agent Foundry, allez dans Add Tools > Catalog
Cherchez “Azure DevOps”
Sélectionnez le Azure DevOps MCP Server (preview) et cliquez sur Create
Entrez le nom de votre organisation et connectez

C’est tout. Votre agent a maintenant accès aux outils Azure DevOps.

Contrôler ce à quoi votre agent peut accéder

C’est la partie que j’apprécie : vous n’êtes pas coincé avec une approche tout-ou-rien. Vous pouvez spécifier quels outils sont disponibles pour votre agent. Si vous voulez qu’il ne lise que les work items sans toucher aux pipelines, vous pouvez configurer ça. Principe du moindre privilège, appliqué à vos agents IA.

C’est important pour les scénarios enterprise où vous ne voulez pas qu’un agent déclenche accidentellement un pipeline de déploiement parce que quelqu’un lui a demandé d’“aider avec la release.”

Pourquoi c’est intéressant pour les équipes .NET

Pensez à ce que ça permet en pratique :

Assistants de planification de sprint — des agents qui peuvent récupérer les work items, analyser les données de vélocité et suggérer la capacité du sprint
Bots de code review — des agents qui comprennent le contexte de votre PR parce qu’ils peuvent réellement lire vos repos et work items liés
Réponse aux incidents — des agents qui peuvent créer des work items, interroger les déploiements récents et corréler les bugs avec les changements récents
Onboarding des développeurs — “Sur quoi devrais-je travailler ?” obtient une vraie réponse basée sur les données réelles du projet

Pour les équipes .NET qui utilisent déjà Azure DevOps pour leurs pipelines CI/CD et la gestion de projet, avoir un agent IA qui peut interagir directement avec ces systèmes est un pas significatif vers une automatisation utile.

La vision plus large de MCP

Cela fait partie d’une tendance plus large : les serveurs MCP deviennent le moyen standard par lequel les agents IA interagissent avec le monde extérieur. On les voit pour GitHub, Azure DevOps, les bases de données, les APIs SaaS — et Foundry devient le hub où toutes ces connexions convergent.

Si vous construisez des agents dans l’écosystème .NET, MCP mérite votre attention. Le protocole est standardisé, l’outillage mûrit, et l’intégration Foundry le rend accessible sans avoir à câbler manuellement les connexions serveur.

Pour conclure

Le serveur MCP Azure DevOps dans Foundry est en preview, alors attendez-vous à ce qu’il évolue. Mais le workflow de base est solide : connecter, configurer l’accès aux outils, et laisser vos agents travailler avec vos données DevOps. Si vous êtes déjà dans l’écosystème Foundry, c’est à quelques clics. Essayez et voyez quels workflows vous pouvez construire.

Consultez l’annonce complète pour la configuration étape par étape et plus de détails.

Foundry | The .NET Blog

Microsoft Foundry Avril 2026 : Foundry Local GA, GPT-5.5, CodeAct avec Hyperlight

Foundry Local est Généralement Disponible

GPT-5.5

Traçage d’Agent Framework dans Foundry

CodeAct avec Hyperlight (Alpha)

Tableau de Bord de Surveillance des Agents (Préversion)

Évaluateurs Personnalisés d’Évaluation Continue (Préversion)

Inventaire des Agents dans le Plan de Contrôle

Votre Agent MAF Local Vient d'Obtenir une Maison en Production

Ce que Foundry Hosted Agents Fait Vraiment

La Différence de Code Est Minime

Deux Protocoles, Un Agent

Le Flux de Déploiement avec azd

Conclusion

Foundry Local 1.1 : Transcription en Temps Réel, Embeddings et l'API de Réponses

Transcription Audio en Direct

Embeddings de Texte

API de Réponses

Améliorations de la Taille du Paquet

Pourquoi C’est Important

GPT-5.5 Est Là et Arrive dans Azure Foundry — Ce que les Développeurs .NET Doivent Savoir

La progression de GPT-5

Ce qui a vraiment changé

Tarification

Pourquoi Foundry est important

Le RFT de Foundry est désormais moins cher et plus intelligent — Voici ce qui a changé

Entraînement Global pour o4-mini

Nouveaux Évaluateurs de Modèle : Famille GPT-4.1

Le Piège du Format de Données RFT

Pourquoi C’est Important pour les Développeurs .NET

Connectez vos serveurs MCP sur Azure Functions aux agents Foundry — Voici comment

Pourquoi cette combinaison a du sens

Options d’authentification

Mise en place

Mon avis

Pour conclure

Microsoft Foundry Mars 2026 — GPT-5.4, Agent Service en GA et la Refonte du SDK Qui Change Tout

Foundry Agent Service est prêt pour la production

GPT-5.4 — la fiabilité plutôt que l’intelligence brute

Le SDK est enfin stable

Fireworks AI amène les modèles ouverts sur Azure

Autres points forts

Conclusion

Du laptop à la production : déployer des agents IA sur Microsoft Foundry en deux commandes

Le nouveau workflow azd ai agent

Ce qui se passe sous le capot

La boucle interne de développement

Monitoring en temps réel

L’ensemble complet des commandes

Pourquoi c’est important pour les développeurs .NET

Pour conclure

Foundry Agent Service est GA : Ce qui compte vraiment pour les développeurs d'agents .NET

Construit sur la Responses API

Réseau privé : le bloqueur entreprise supprimé

Authentification MCP bien faite

Voice Live : voix à voix sans la plomberie

Évaluations : de la case à cocher au monitoring continu

Six nouvelles régions pour les agents hébergés

Pourquoi c’est important pour les développeurs .NET

Pour conclure

Le serveur MCP Azure DevOps débarque dans Microsoft Foundry : ce que ça signifie pour vos agents IA

Ce qui se passe réellement ici

La mise en place

Contrôler ce à quoi votre agent peut accéder

Pourquoi c’est intéressant pour les équipes .NET

La vision plus large de MCP

Pour conclure

Le Flux de Déploiement avec `azd`

Le nouveau workflow `azd ai agent`