Agents | The .NET Blog

NL2SQL est l'injection SQL de l'ère agentique

Emiliano Montesdeoca — Wed, 03 Jun 2026 00:00:00 +0000

Il existe une version du discours NL2SQL qui semble parfaite : les utilisateurs posent des questions en langage naturel, les agents génèrent du SQL, les données reviennent. Moins d’écrans, moins de requêtes, moins de code. Simple.

Puis vous y réfléchissez cinq minutes de plus.

Les problèmes dont personne ne parle dans la démo

Les schémas n’ont pas été conçus pour expliquer les choses. Noms de tables cryptiques, noms de colonnes incohérents, relations techniquement valides mais sémantiquement invalides sans prédicats supplémentaires — c’est normal dans les bases de données d’entreprise. Ce ne sont pas des bugs, c’est simplement l’histoire accumulée des changements métier. Mais quand vous demandez à un modèle d’inférer l’intention d’un schéma qui n’a pas été conçu pour communiquer l’intention, le modèle essaiera quand même. Il ne s’arrêtera pas. Il générera sa meilleure requête et retournera des résultats avec assurance.

Les modèles ne sont pas déterministes. Posez la même question sur la même base de données deux fois et vous pourriez obtenir du SQL différent. Le modèle calcule des probabilités, et de légères variations de contexte produisent des sorties différentes. Vous ne pouvez pas tester votre chemin vers une garantie que l’agent génère toujours la bonne requête.

La révision par l’utilisateur ne passe pas à l’échelle. “Vérifiez simplement chaque requête avant l’exécution” semble sûr. Mais cela suppose que les utilisateurs sont des experts à la fois dans le modèle de données et en SQL — exactement les personnes qui n’avaient pas besoin de l’interface en langage naturel. Cela introduit également une surcharge cognitive et une nouvelle classe de biais de confirmation, où les utilisateurs submergés par la complexité des requêtes approuvent des requêtes invalides plutôt que de les investiguer.

Et puis il y a l’injection. Dans le développement SQL traditionnel, la paramétrisation a résolu l’injection parce que la saisie utilisateur remplissait des paramètres, pas la structure SQL. Avec NL2SQL, le modèle génère le SQL lui-même. Le prompt, le contexte du schéma, l’historique de conversation et les données récupérées influencent tous ce qui est exécuté. Si quelqu’un élabore un prompt qui change ce que le modèle génère, c’est de l’injection — pas au niveau des paramètres, mais au niveau de la génération des requêtes. Et contrairement à la suppression d’une table (évident, récupérable), l’injection NL2SQL produit des requêtes qui retournent des résultats incorrects sans aucune erreur visible. Des décisions métier sont prises sur de mauvaises données.

Ce que SQL MCP Server résout réellement

C’est là que l’article fait son point pratique le plus utile. Plutôt que de donner à un agent un accès arbitraire au schéma et d’espérer le meilleur, SQL MCP Server expose une surface API organisée construite sur Data API builder.

La différence est importante : l’agent ne génère pas de SQL. Il appelle des endpoints nommés qui retournent des formes de résultat prédéfinies. Le SQL est écrit une fois, par un développeur, et est déterministe. Le non-déterminisme de l’agent se limite à choisir quel endpoint appeler, pas à construire des requêtes arbitraires.

C’est analogue à ce que la paramétrisation a fait pour l’injection SQL dans le modèle d’application traditionnel — vous supprimez la capacité de construire des requêtes arbitraires à partir d’entrées non fiables.

La bonne question

L’article ne dit pas “n’utilisez jamais NL2SQL.” Il dit : soyez délibéré sur où vous l’appliquez et ce que vous exposez. Pour une analyse exploratoire dans un environnement contrôlé, avec un schéma limité et un accès en lecture seule, NL2SQL pourrait convenir. Pour les systèmes de production où les décisions métier dépendent des résultats, une couche API organisée est significativement plus sûre.

Honnêteté : certains problèmes sont vraiment mieux résolus avec des requêtes structurées derrière des endpoints nommés qu’avec du langage naturel vers SQL. SQL MCP Server vous donne cette option sans abandonner entièrement l’interface agentique.

Publication originale : Considering NL2SQL? Should your database really be the prompt? How can SQL MCP Server help?

Votre Agent IA a un Problème d'Identité (Et Voici le Modèle qui le Résout)

Emiliano Montesdeoca — Wed, 20 May 2026 00:00:00 +0000

Il y a un moment dans chaque projet d’agent IA qui ressemble à ceci : la démo fonctionne parfaitement, l’agent interprète le langage naturel, appelle les bonnes API, retourne les bonnes données. Ensuite vous commencez à penser aux vrais utilisateurs.

Qu’est-ce qui empêche la session d’agent d’un utilisateur de voir les données d’un autre utilisateur ? Et si l’agent est trompé par une injection de prompt ? Et s’il appelle un outil d’une manière inattendue ?

Ce ne sont pas des cas limites. Ce sont des décisions de conception que vous devez prendre avant de livrer.

Un nouveau modèle azd de Curity et Microsoft vous donne une référence fonctionnelle pour exactement ce problème.

Le Problème Central : Authentification ≠ Autorisation

La plupart des exemples d’agents gèrent bien l’authentification des utilisateurs. Ils gèrent mal l’autorisation. Savoir qui est l’utilisateur ne vous dit pas quelles données il devrait voir.

Une application cliente traditionnelle fait des appels d’API prévisibles. Un agent IA est non déterministe — il interprète le langage naturel et décide quoi appeler. Il peut être créatif. Il peut aussi se tromper. Et s’il est manipulé par injection de prompt, vous avez besoin de règles qui ne dépendent pas du bon comportement de l’IA.

La solution démontrée par ce modèle : des tokens de courte durée qui transportent exactement les bonnes informations pour chaque saut.

Comment Fonctionne la Chaîne de Tokens

Le modèle utilise des tokens d’accès OAuth 2.0 avec échange de tokens pour réduire les permissions à chaque étape. Un token utilisateur est échangé deux fois avant d’atteindre le serveur MCP :

Premier échange — réduit la portée et convertit le token opaque en JWT
Deuxième échange — ajoute l’identité de l’agent et une nouvelle audience pour le saut du serveur MCP

À quoi ressemble le token du serveur MCP :

{
 "scope": "stocks/read",
 "sub": "62c839b8...",
 "aud": "https://mcp.demo.example",
 "customer_id": "178",
 "region": "USA"
}

Le customer_id est intégré dans le token par le serveur d’autorisation, pas passé comme paramètre que l’agent contrôle. L’API vérifie le token, pas les instructions de l’agent.

Cela signifie : même si quelqu’un trompe l’agent pour qu’il essaie d’obtenir les données d’un autre client, le token ne l’autorisera pas.

Ce que le Modèle Déploie

Avec quelques commandes azd vous obtenez :

Un agent backend sur Microsoft Foundry (C#, SDK Microsoft A2A et MCP)
Un serveur MCP exposant un exemple d’API de portefeuille
Curity Identity Server comme serveur d’autorisation, aux côtés d’Entra ID pour l’authentification
Des passerelles API externes et internes gérant l’échange de tokens et la journalisation d’audit
Bicep pour toute l’infrastructure Azure : Container Apps, VNet, ACR, Azure AI Foundry, Key Vault, Azure SQL Database, stockage

Tout le modèle est inspecTable et personnalisable.

Le Principe de Conception qui Vaut la Peine d’être Emprunté

Même si vous n’utilisez pas Curity, le modèle est transférable : les agents ne devraient jamais avoir un accès permanent à l’API. Chaque action devrait utiliser un token de courte durée avec le scope minimum nécessaire pour cet appel spécifique, émis pour l’identité spécifique de l’agent, portant les claims dont l’API a besoin pour prendre des décisions d’autorisation.

Cela résiste aux agents créatifs, aux erreurs et à l’injection de prompt d’une façon que “assurez-vous simplement que l’agent ne fait pas de mauvaises choses” ne fera jamais.

Conclusion

Les modèles de sécurité pour les agents IA sont encore en cours d’élaboration dans l’industrie. Ce modèle est l’une des implémentations de référence les plus complètes que j’ai vues — il couvre le flux d’autorisation réel, pas seulement l’authentification.

Post original : Least privilege AI agents: A new azd template from Curity and Microsoft

CodeAct dans Agent Framework : Comment Réduire la Latence de votre Agent de Moitié

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

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

Il y a ce moment dans tout projet d’agents où vous regardez la trace et pensez : « pourquoi est-ce que ça prend autant de temps ? » Le modèle est bien. Les outils fonctionnent. Mais il y a sept allers-retours pour obtenir un résultat qu’on pourrait calculer en une seule fois.

C’est exactement le problème que CodeAct résout — et l’équipe Agent Framework vient de publier un support alpha via le nouveau paquet agent-framework-hyperlight.

Qu’est-ce que CodeAct ?

Le pattern CodeAct est élégamment simple : au lieu de donner au modèle une liste d’outils à appeler un par un, vous lui donnez un seul outil execute_code et le laissez exprimer le plan complet comme un court programme Python. L’agent écrit le code une fois, le sandbox l’exécute, et vous récupérez un seul résultat consolidé.

Câblage	Temps	Tokens
Traditionnel	27,81s	6 890
CodeAct	13,23s	2 489
Amélioration	52,4%	63,9%

Sécurité : Micro-VMs Hyperlight

Le paquet agent-framework-hyperlight utilise des micro-VMs Hyperlight. Chaque appel execute_code obtient sa propre micro-VM fraîchement créée. Le démarrage se mesure en millisecondes. L’isolation est pratiquement gratuite.

Vos outils continuent de s’exécuter sur l’hôte. Le code de collage généré par le modèle s’exécute dans le sandbox. C’est le bon découpage.

Configuration minimale

from agent_framework import Agent, tool
from agent_framework_hyperlight import HyperlightCodeActProvider

@tool
def get_weather(city: str) -> dict[str, float | str]:
 """Return the current weather for a city."""
 return {"city": city, "temperature_c": 21.5, "conditions": "partly cloudy"}

codeact = HyperlightCodeActProvider(
 tools=[get_weather],
 approval_mode="never_require",
)

agent = Agent(
 client=client,
 name="CodeActAgent",
 instructions="You are a helpful assistant.",
 context_providers=[codeact],
)

Quand utiliser CodeAct (et quand ne pas l’utiliser)

Utilisez CodeAct quand :

La tâche enchaîne de nombreux petits appels d’outils (lookups, jointures, calculs)
La latence et le coût en tokens comptent
Vous voulez une isolation forte par appel pour le code généré par le modèle

Restez avec le tool-calling traditionnel quand :

L’agent ne fait qu’un ou deux appels d’outils par tour
Chaque appel a des effets secondaires à approuver individuellement
Les descriptions d’outils sont peu détaillées

Essayez maintenant

pip install agent-framework-hyperlight --pre

Consultez le post complet sur le blog Agent Framework pour une couverture approfondie.

Où votre Agent se Souvient-il des Choses ? Guide Pratique sur le Stockage de l'Historique de Chat

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

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

Lors de la création d’un agent IA, vous consacrez la majeure partie de votre énergie au modèle, aux outils et aux prompts. La question de l’endroit où vit l’historique des conversations semble être un détail d’implémentation — mais c’est l’une des décisions architecturales les plus importantes que vous prendrez.

Elle détermine si les utilisateurs peuvent bifurquer des conversations, annuler des réponses, reprendre des sessions après un redémarrage, et si vos données quittent jamais votre infrastructure. L’équipe Agent Framework a publié une analyse approfondie.

Deux modèles fondamentaux

Géré par le service : le service IA stocke l’état de la conversation. Votre application tient une référence et le service inclut automatiquement l’historique pertinent dans chaque requête.

Géré par le client : votre application maintient l’historique complet et envoie les messages pertinents avec chaque requête. Le service est sans état. Vous contrôlez tout.

Comment Agent Framework abstrait cela

// C# — fonctionne pareil quel que soit le fournisseur
AgentSession session = await agent.CreateSessionAsync();
var first = await agent.RunAsync("Je m'appelle Alice.", session);
var second = await agent.RunAsync("Quel est mon nom ?", session);

# Python
session = agent.create_session()
first = await agent.run("Je m'appelle Alice.", session=session)
second = await agent.run("Quel est mon nom ?", session=session)

Référence rapide des fournisseurs

Fournisseur	Stockage	Modèle	Compaction
OpenAI/Azure Chat Completions	Client	N/A	Vous
Foundry Agent Service	Service	Linéaire	Service
Responses API (défaut)	Service	Bifurquant	Service
Anthropic Claude, Ollama	Client	N/A	Vous

Comment choisir

Besoin de bifurcation ou « annuler » ? → Responses API géré par service
Besoin de souveraineté des données ? → Géré par client avec fournisseur base de données
Simple chatbot ? → Géré par service linéaire suffit

Lisez le post complet pour l’arbre de décision complet.

Foundry Toolboxes : Un seul endpoint pour tous les outils de vos agents

Emiliano Montesdeoca — Thu, 23 Apr 2026 00:00:00 +0000

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

Voici un problème qui semble banal jusqu’à ce qu’on le vive : l’organisation construit plusieurs agents IA, chacun nécessite des outils, et chaque équipe les reconfigure à partir de zéro. La même intégration de recherche web, la même config Azure AI Search, la même connexion au serveur MCP GitHub — mais dans un autre dépôt, par une autre équipe, avec d’autres credentials et sans gouvernance partagée.

Microsoft Foundry vient de lancer Toolboxes en preview publique, et c’est une réponse directe à ce problème.

Qu’est-ce qu’une Toolbox ?

Une Toolbox est un bundle d’outils nommé et réutilisable, défini une fois dans Foundry et exposé via un unique endpoint compatible MCP. N’importe quel runtime d’agent qui parle MCP peut le consommer — pas d’enfermement dans Foundry Agents.

La promesse est simple : build once, consume anywhere. Définir les outils, configurer l’authentification de façon centralisée (OAuth passthrough, identité managée Entra), publier l’endpoint. Chaque agent qui a besoin de ces outils se connecte à l’endpoint et les obtient tous.

Les quatre piliers (deux disponibles aujourd’hui)

Pilier	Statut	Ce qu’il fait
Discover	Bientôt	Trouver des outils approuvés sans recherche manuelle
Build	Disponible	Regrouper des outils en un bundle réutilisable
Consume	Disponible	Un endpoint MCP unique expose tous les outils
Govern	Bientôt	Auth centralisée + observabilité pour tous les appels

Exemple pratique

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

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

toolbox_version = client.beta.toolboxes.create_toolbox_version(
 toolbox_name="customer-feedback-triaging-toolbox",
 description="Chercher dans la documentation et répondre aux issues GitHub.",
 tools=[
 {"type": "web_search", "description": "Recherche dans la documentation publique"},
 {"type": "azure_ai_search", "index_name": "internal-docs"},
 {"type": "mcp_server", "server_url": "https://your-github-mcp-server.com"}
 ]
)

Une fois publié, Foundry fournit un endpoint unifié. Une connexion, tous les outils.

Pas d’enfermement dans Foundry Agents

Les Toolboxes sont créées et gérées dans Foundry, mais la surface de consommation est le protocole MCP ouvert. On peut les utiliser depuis des agents personnalisés (Microsoft Agent Framework, LangGraph), GitHub Copilot et autres IDEs compatibles MCP, et tout runtime parlant MCP.

Pourquoi c’est important maintenant

La vague multi-agents arrive en production. Chaque nouvel agent est une nouvelle surface pour de la configuration dupliquée, des credentials obsolètes et des comportements incohérents. La base Build + Consume suffit pour commencer à centraliser. Quand le pilier Govern arrivera, on aura une couche d’outils entièrement observable et contrôlée centralement pour toute la flotte d’agents.

Conclusion

C’est encore tôt — preview publique, SDK Python en premier, Discover et Govern à venir. Mais le modèle est solide et le design natif MCP signifie qu’il fonctionne avec les outils qu’on construit déjà. Tous les détails dans l’annonce officielle.

VS Code 1.117 : Les Agents Obtiennent Leurs Propres Branches Git et Je Suis Totalement Pour

Emiliano Montesdeoca — Sun, 19 Apr 2026 00:00:00 +0000

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

La frontière entre « assistant IA » et « coéquipier IA » continue de s’amincir. VS Code 1.117 vient de sortir et les notes de version complètes sont bien remplies, mais l’histoire est claire : les agents deviennent des citoyens de première classe dans votre workflow de développement.

Voici ce qui compte vraiment.

Le mode Autopilot se souvient enfin de votre préférence

Avant, il fallait réactiver Autopilot à chaque nouvelle session. Agaçant. Maintenant votre mode de permissions persiste d’une session à l’autre, et vous pouvez configurer la valeur par défaut.

L’Agent Host supporte trois configurations de session :

Default — les outils demandent confirmation avant de s’exécuter
Bypass — approuve tout automatiquement
Autopilot — totalement autonome, répond à ses propres questions et continue

Si vous construisez un nouveau projet .NET avec des migrations, Docker et de la CI — réglez-le sur Autopilot une fois et oubliez-le. Cette préférence reste.

Worktree et isolation git pour les sessions d’agents

C’est le gros morceau. Les sessions d’agents supportent maintenant l’isolation complète par worktree et git. Cela signifie que quand un agent travaille sur une tâche, il obtient sa propre branche et son propre répertoire de travail. Votre branche principale reste intacte.

Encore mieux — Copilot CLI génère des noms de branche significatifs pour ces sessions worktree. Fini le agent-session-abc123. Vous obtenez quelque chose qui décrit réellement ce que l’agent fait.

Pour les développeurs .NET qui gèrent plusieurs branches de fonctionnalités ou corrigent des bugs pendant qu’une longue tâche de scaffolding tourne, c’est un vrai changement. Vous pouvez avoir un agent qui construit vos contrôleurs d’API dans un worktree pendant que vous déboguez un problème dans la couche de services dans un autre. Pas de conflits. Pas de stashing. Pas de bazar.

Sous-agents et équipes d’agents

L’Agent Host Protocol supporte maintenant les sous-agents. Un agent peut lancer d’autres agents pour gérer des parties d’une tâche. Pensez-y comme de la délégation — votre agent principal coordonne, et des agents spécialisés s’occupent des morceaux.

C’est encore tôt, mais le potentiel pour les workflows .NET est évident. Imaginez un agent qui gère vos migrations EF Core pendant qu’un autre configure vos tests d’intégration. On n’y est pas encore complètement, mais le fait que le support du protocole arrive maintenant signifie que l’outillage suivra rapidement.

La sortie terminal automatiquement incluse quand les agents envoient de l’input

Petit mais significatif. Quand un agent envoie de l’input au terminal, la sortie du terminal est maintenant automatiquement incluse dans le contexte. Avant, l’agent devait faire un tour supplémentaire juste pour lire ce qui s’était passé.

Si vous avez déjà vu un agent exécuter dotnet build, échouer, puis faire un aller-retour supplémentaire juste pour voir l’erreur — cette friction a disparu. Il voit la sortie immédiatement et réagit.

L’application Agents sur macOS se met à jour automatiquement

L’application autonome Agents sur macOS se met maintenant à jour automatiquement. Plus besoin de télécharger manuellement les nouvelles versions. Elle reste simplement à jour.

Les petites choses qui valent la peine d’être connues

Les survols package.json affichent maintenant la version installée et la dernière disponible. Utile si vous gérez des outils npm aux côtés de vos projets .NET.
Les images dans les commentaires JSDoc s’affichent correctement dans les survols et les complétions.
Les sessions Copilot CLI indiquent maintenant si elles ont été créées par VS Code ou en externe — pratique quand vous sautez entre les terminaux.
Copilot CLI, Claude Code et Gemini CLI sont reconnus comme types de shell. L’éditeur sait ce que vous exécutez.

Ce qu’il faut retenir

VS Code 1.117 n’est pas un déversement de fonctionnalités tape-à-l’œil. C’est de l’infrastructure. Isolation par worktree, permissions persistantes, protocoles de sous-agents — ce sont les briques pour un workflow où les agents gèrent des tâches réelles et parallèles sans marcher sur votre code.

Si vous développez avec .NET et que vous ne vous êtes pas encore lancé dans le workflow agentique, honnêtement, c’est le moment de commencer.

Où héberger vos agents IA sur Azure ? Un guide de décision pratique

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

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

Si vous construisez des agents IA avec .NET en ce moment, vous avez probablement remarqué quelque chose : il y a beaucoup de façons de les héberger sur Azure. Container Apps, AKS, Functions, App Service, Foundry Agents, Foundry Hosted Agents — et tous semblent raisonnables jusqu’à ce que vous ayez réellement besoin d’en choisir un. Microsoft vient de publier un guide complet sur l’hébergement d’agents IA sur Azure qui clarifie tout ça, et je veux le décomposer du point de vue pratique d’un développeur .NET.

Les six options en un coup d’œil

Voici comment je résumerais le paysage :

Option	Idéal pour	Vous gérez
Container Apps	Contrôle total des conteneurs sans complexité K8s	Observabilité, état, cycle de vie
AKS	Conformité entreprise, multi-cluster, réseau personnalisé	Tout (c’est le but)
Azure Functions	Tâches d’agents événementielles et courtes	Presque rien — vrai serverless
App Service	Agents HTTP simples, trafic prévisible	Déploiement, config de scaling
Foundry Agents	Agents sans code via portail/SDK	Presque rien
Foundry Hosted Agents	Agents framework personnalisé avec infra gérée	Uniquement votre code d’agent

Les quatre premières sont du compute généraliste — vous pouvez y exécuter des agents, mais elles n’ont pas été conçues pour ça. Les deux dernières sont natives aux agents : elles comprennent les conversations, les appels d’outils et les cycles de vie des agents comme des concepts de première classe.

Foundry Hosted Agents — le sweet spot pour les développeurs .NET d’agents

C’est ce qui a attiré mon attention. Les Foundry Hosted Agents se situent pile au milieu : vous obtenez la flexibilité d’exécuter votre propre code (Semantic Kernel, Agent Framework, LangGraph — peu importe) mais la plateforme gère l’infrastructure, l’observabilité et la gestion des conversations.

La pièce clé est le Hosting Adapter — une fine couche d’abstraction qui connecte votre framework d’agents à la plateforme Foundry. Pour Microsoft Agent Framework, ça ressemble à ça :

from azure.ai.agentserver.agentframework import from_agent_framework

agent = ChatAgent(
 chat_client=AzureAIAgentClient(...),
 instructions="You are a helpful assistant.",
 tools=[get_local_time],
)

if __name__ == "__main__":
 from_agent_framework(agent).run()

C’est toute votre histoire d’hébergement. L’adapter gère la traduction de protocoles, le streaming via server-sent events, l’historique de conversation et le traçage OpenTelemetry — tout automatiquement. Pas de middleware personnalisé, pas de plomberie manuelle.

Le déploiement est vraiment simple

J’ai déployé des agents sur Container Apps avant et ça fonctionne, mais on finit par écrire beaucoup de code de colle pour la gestion d’état et l’observabilité. Avec Hosted Agents et azd, le déploiement c’est :

# Installer l'extension agent IA
azd ext install azure.ai.agents

# Initialiser depuis un template
azd ai agent init

# Construire, pousser, déployer — terminé
azd up

Ce seul azd up construit votre conteneur, le pousse vers ACR, provisionne le projet Foundry, déploie les endpoints de modèle et démarre votre agent. Cinq étapes condensées en une seule commande.

Gestion de conversations intégrée

C’est la partie qui fait gagner le plus de temps en production. Au lieu de construire votre propre store d’état de conversation, les Hosted Agents le gèrent nativement :

# Créer une conversation persistante
conversation = openai_client.conversations.create()

# Premier tour
response1 = openai_client.responses.create(
 conversation=conversation.id,
 extra_body={"agent_reference": {"name": "MyAgent", "type": "agent_reference"}},
 input="Remember: my favorite number is 42.",
)

# Deuxième tour — le contexte est préservé
response2 = openai_client.responses.create(
 conversation=conversation.id,
 extra_body={"agent_reference": {"name": "MyAgent", "type": "agent_reference"}},
 input="Multiply my favorite number by 10.",
)

Pas de Redis. Pas de store de sessions Cosmos DB. Pas de middleware personnalisé pour la sérialisation des messages. La plateforme gère tout simplement.

Mon framework de décision

Après avoir passé en revue les six options, voici mon modèle mental rapide :

Vous avez besoin de zéro infrastructure ? → Foundry Agents (portail/SDK, pas de conteneurs)
Vous avez du code d’agent personnalisé mais voulez un hébergement géré ? → Foundry Hosted Agents
Vous avez besoin de tâches d’agents événementielles et courtes ? → Azure Functions
Vous avez besoin d’un contrôle maximum des conteneurs sans K8s ? → Container Apps
Vous avez besoin de conformité stricte et multi-cluster ? → AKS
Vous avez un agent HTTP simple avec un trafic prévisible ? → App Service

Pour la plupart des développeurs .NET qui construisent avec Semantic Kernel ou Microsoft Agent Framework, Hosted Agents est probablement le bon point de départ. Vous obtenez le scale-to-zero, OpenTelemetry intégré, la gestion des conversations et la flexibilité de framework — sans gérer Kubernetes ni monter votre propre stack d’observabilité.

Pour conclure

Le paysage de l’hébergement d’agents sur Azure mûrit rapidement. Si vous démarrez un nouveau projet d’agent IA aujourd’hui, je considérerais sérieusement Foundry Hosted Agents avant de recourir à Container Apps ou AKS par habitude. L’infrastructure gérée fait gagner un temps réel, et le pattern hosting adapter vous permet de garder votre choix de framework.

Consultez le guide complet de Microsoft et le repo Foundry Samples pour des exemples fonctionnels.

Azure MCP Server 2.0 Est Arrivé — L'Automatisation Agentic Self-Hosted Est Ici

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

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

Si vous avez construit quelque chose avec MCP et Azure récemment, vous savez probablement que l’expérience locale fonctionne bien. Branchez un serveur MCP, laissez votre agent IA parler aux ressources Azure, et passez à la suite. Mais dès que vous avez besoin de partager cette configuration dans une équipe ? C’est là que les choses se compliquaient.

Plus maintenant. Azure MCP Server vient d’atteindre la version 2.0 stable, et la fonctionnalité phare est exactement ce que les équipes d’entreprise demandaient : le support du serveur MCP distant self-hosted.

Qu’est-ce qu’Azure MCP Server ?

Petit rappel. Azure MCP Server implémente la spécification Model Context Protocol et expose les capacités Azure en tant qu’outils structurés et découvrables que les agents IA peuvent invoquer. Pensez-y comme un pont standardisé entre votre agent et Azure — provisionnement, déploiement, monitoring, diagnostics, tout par une interface cohérente.

Les chiffres parlent d’eux-mêmes : 276 outils MCP sur 57 services Azure. C’est une couverture sérieuse.

Le grand changement : les déploiements distants self-hosted

Voici la chose. Exécuter MCP localement sur votre machine, c’est bien pour le développement et les expériences. Mais dans un scénario d’équipe réelle, vous avez besoin de :

Un accès partagé pour les développeurs et les systèmes d’agents internes
Une configuration centralisée (contexte de tenant, valeurs par défaut des abonnements, télémétrie)
Des limites de réseau et de politique d’entreprise
L’intégration dans les pipelines CI/CD

Azure MCP Server 2.0 s’adresse à tout cela. Vous pouvez le déployer comme un service interne géré de manière centralisée avec un transport basé sur HTTP, une authentification appropriée et une gouvernance cohérente.

Pour l’authentification, vous avez deux excellentes options :

Managed Identity — lors de l’exécution aux côtés de Microsoft Foundry
Le flux On-Behalf-Of (OBO) — une délégation OpenID Connect qui appelle les API Azure en utilisant le contexte de l’utilisateur connecté

Ce flux OBO est particulièrement intéressant pour nous, développeurs .NET. Cela signifie que vos workflows agentiques peuvent fonctionner avec les permissions réelles de l’utilisateur, pas un compte de service surprivilégié. Le principe du moindre privilège, intégré nativement.

Renforcement de la sécurité

Ce n’est pas seulement une sortie de fonctionnalité — c’est aussi une sortie de sécurité. La version 2.0 ajoute :

Une validation d’endpoint plus forte
Des protections contre les modèles d’injection dans les outils orientés requête
Des contrôles d’isolation plus serrés pour les environnements de développement

Si vous allez exposer MCP comme un service partagé, ces protections sont importantes. Vraiment importantes.

Où pouvez-vous l’utiliser ?

L’histoire de compatibilité des clients est large. Azure MCP Server 2.0 fonctionne avec :

IDEs : VS Code, Visual Studio, IntelliJ, Eclipse, Cursor
Agents CLI : GitHub Copilot CLI, Claude Code
Standalone : serveur local pour les configurations simples
Self-hosted distant : la nouvelle vedette de la version 2.0

Plus il y a le support du cloud souverain pour Azure US Government et Azure exploité par 21Vianet, ce qui est critique pour les déploiements réglementés.

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

Si vous construisez des applications agentiques avec .NET — qu’il s’agisse de Semantic Kernel, Microsoft Agent Framework, ou votre propre orchestration — Azure MCP Server 2.0 vous donne un moyen prêt pour la production de laisser vos agents interagir avec l’infrastructure Azure. Pas de wrappers REST personnalisés. Pas de modèles d’intégration spécifiques aux services. Juste MCP.

Combiné avec l’API fluide pour les applications MCP qui est arrivée il y a quelques jours, l’écosystème .NET MCP mûrit rapidement.

Démarrage

Choisissez votre chemin :

GitHub Repo — code source, documentation, tout
Image Docker — déploiement containerisé
Extension VS Code — intégration IDE
Guide de self-hosting — la fonctionnalité phare de la version 2.0

Conclusion

Azure MCP Server 2.0 est exactement le type de mise à niveau d’infrastructure qui ne brille pas dans une démo mais change tout en pratique. Un MCP distant self-hosted avec une authentification appropriée, un renforcement de la sécurité et un support du cloud souverain signifient que MCP est prêt pour les vraies équipes construisant de vrais workflows agentiques sur Azure. Si vous attendiez le signal « prêt pour l’entreprise » — c’est celui-ci.

L'Ingénierie de Plateformes Agentique Devient Réalité — Git-APE Montre Comment

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

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

L’ingénierie de plateformes est un de ces termes qui sonne bien en conférence mais qui signifie généralement « on a construit un portail interne et un wrapper Terraform. » La vraie promesse — une infrastructure en self-service qui soit réellement sécurisée, gouvernée et rapide — a toujours été à quelques pas.

L’équipe Azure vient de publier la Partie 2 de leur série sur l’ingénierie de plateformes agentique, et celle-ci porte sur l’implémentation concrète. Ils l’appellent Git-APE (oui, l’acronyme est intentionnel), et c’est un projet open source qui utilise les agents GitHub Copilot plus les serveurs Azure MCP pour transformer des requêtes en langage naturel en infrastructure validée et déployée.

Ce que Git-APE fait concrètement

L’idée principale : au lieu que les développeurs apprennent des modules Terraform, naviguent dans des UIs de portails ou déposent des tickets à l’équipe plateforme, ils parlent à un agent Copilot. L’agent interprète l’intention, génère de l’Infrastructure-as-Code, la valide contre les politiques et déploie — le tout dans VS Code.

Voici la mise en place :

git clone https://github.com/Azure/git-ape
cd git-ape

Ouvre le workspace dans VS Code, et les fichiers de configuration de l’agent sont automatiquement découverts par GitHub Copilot. Tu interagis directement avec l’agent :

@git-ape deploy a function app with storage in West Europe

L’agent utilise Azure MCP Server en interne pour interagir avec les services Azure. La configuration MCP dans les paramètres de VS Code active des capacités spécifiques :

{
 "azureMcp.serverMode": "namespace",
 "azureMcp.enabledServices": [
 "deploy", "bestpractices", "group",
 "subscription", "functionapp", "storage",
 "sql", "monitor"
 ],
 "azureMcp.readOnly": false
}

Pourquoi c’est important

Pour ceux d’entre nous qui construisent sur Azure, cela déplace la conversation de l’ingénierie de plateformes de « comment construire un portail » à « comment décrire nos garde-fous comme des APIs. » Quand l’interface de ta plateforme est un agent IA, la qualité de tes contraintes et politiques devient le produit.

Le blog de la Partie 1 posait la théorie : des APIs bien décrites, des schémas de contrôle et des garde-fous explicites rendent les plateformes agent-ready. La Partie 2 prouve que ça marche en livrant des outils concrets. L’agent ne génère pas aveuglément des ressources — il valide contre les bonnes pratiques, respecte les conventions de nommage et applique les politiques de ton organisation.

Le nettoyage est tout aussi simple :

@git-ape destroy my-resource-group

Mon avis

Je serai honnête — ici c’est plus le pattern que l’outil spécifique qui compte. Git-APE lui-même est une démo/architecture de référence. Mais l’idée sous-jacente — les agents comme interface de ta plateforme, MCP comme protocole, GitHub Copilot comme hôte — c’est la direction que prend l’expérience développeur en entreprise.

Si tu es une équipe plateforme qui cherche comment rendre son outillage interne agent-friendly, il n’y a pas de meilleur point de départ. Et si tu es un développeur .NET qui se demande comment ça se connecte à ton monde : Azure MCP Server et les agents GitHub Copilot fonctionnent avec n’importe quel workload Azure. Ton API ASP.NET Core, ton stack .NET Aspire, tes microservices containerisés — tout ça peut être la cible d’un flux de déploiement agentique.

Pour conclure

Git-APE est un aperçu précoce mais concret de l’ingénierie de plateformes agentique en pratique. Clone le repo, essaie la démo et commence à réfléchir à comment les APIs et politiques de ta plateforme devraient se présenter pour qu’un agent puisse les utiliser en toute sécurité.

Lis le post complet pour le walkthrough et les vidéos de démo.

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.

VS Code 1.116 — L'App Agents Obtient la Navigation Clavier et les Complétions de Contexte de Fichiers

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

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

VS Code 1.116 est la version d’avril 2026, et bien qu’elle soit plus légère que certaines mises à jour récentes, les changements sont ciblés et significatifs — surtout si vous utilisez l’app Agents au quotidien.

Voici ce qui a atterri, d’après les notes de version officielles.

Améliorations de l’app Agents

L’app Agents continue de mûrir avec un polissage de l’ergonomie qui fait une vraie différence dans les flux de travail quotidiens :

Raccourcis clavier dédiés — vous pouvez maintenant cibler la vue Changes, l’arborescence de fichiers dans Changes, et la vue des Personnalisations du Chat avec des commandes et raccourcis clavier dédiés. Si vous cliquiez partout dans l’app Agents pour naviguer, cela apporte des flux de travail entièrement pilotés au clavier.

Dialogue d’aide à l’accessibilité — appuyer sur Alt+F1 dans la zone de saisie du chat ouvre maintenant un dialogue d’aide à l’accessibilité montrant les commandes et raccourcis disponibles. Les utilisateurs de lecteurs d’écran peuvent aussi contrôler la verbosité des annonces. Une bonne accessibilité profite à tout le monde.

Complétions de contexte de fichiers — tapez # dans le chat de l’app Agents pour déclencher les complétions de contexte de fichiers limitées à votre espace de travail actuel. C’est une de ces petites améliorations de qualité de vie qui accélèrent chaque interaction — plus besoin de taper des chemins de fichiers complets en référençant du code.

Résolution des liens CSS `@import`

Agréable pour les développeurs frontend : VS Code résout maintenant les références CSS @import qui utilisent des chemins node_modules. Vous pouvez faire Ctrl+clic à travers des imports comme @import "some-module/style.css" en utilisant des bundlers. Petit mais élimine un point de friction dans les workflows CSS.

Conclusion

VS Code 1.116 est une affaire de raffinement — rendre l’app Agents plus navigable, plus accessible et plus conviviale au clavier. Si vous passez beaucoup de temps dans l’app Agents (et je soupçonne que beaucoup d’entre nous le font), ces changements s’accumulent.

Consultez les notes de version complètes pour la liste exhaustive.

azd permet maintenant d'exécuter et déboguer des agents IA localement — Ce qui a changé en mars 2026

Emiliano Montesdeoca — Thu, 02 Apr 2026 00:00:00 +0000

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

Sept versions en un mois. C’est ce que l’équipe Azure Developer CLI (azd) a livré en mars 2026, et la fonctionnalité phare est celle que j’attendais : une boucle locale d’exécution et débogage pour les agents IA.

PC Chan a publié le récapitulatif complet, et bien qu’il y ait beaucoup de contenu, laissez-moi filtrer ce qui compte vraiment pour les développeurs .NET qui construisent des apps alimentées par l’IA.

Exécuter et déboguer des agents IA sans déployer

C’est le gros morceau. La nouvelle extension azure.ai.agents ajoute des commandes qui offrent une vraie boucle interne pour les agents IA :

azd ai agent run — démarre votre agent localement
azd ai agent invoke — lui envoie des messages (local ou déployé)
azd ai agent show — affiche le statut du conteneur et sa santé
azd ai agent monitor — diffuse les logs du conteneur en temps réel

Avant, tester un agent IA signifiait déployer sur Microsoft Foundry à chaque modification. Maintenant, vous pouvez itérer localement, tester le comportement de votre agent, et ne déployer que quand vous êtes prêt.

GitHub Copilot configure votre projet azd

azd init offre maintenant une option “Set up with GitHub Copilot (Preview)”. Au lieu de répondre manuellement aux prompts, un agent Copilot génère la configuration pour vous. Quand une commande échoue, azd propose un dépannage assisté par IA — tout sans quitter le terminal.

Container App Jobs et améliorations de déploiement

Container App Jobs : azd déploie maintenant Microsoft.App/jobs via la config existante host: containerapp.
Timeouts configurables : Nouveau flag --timeout sur azd deploy et champ deployTimeout dans azure.yaml.
Fallback de build distant : En cas d’échec du build ACR, azd retombe automatiquement sur Docker/Podman local.
Validation preflight locale : Les paramètres Bicep sont validés localement avant le déploiement.

Améliorations DX

Détection automatique pnpm/yarn pour les projets JS/TS
Support pyproject.toml pour le packaging Python
Répertoires de templates locaux — azd init --template accepte les chemins du système de fichiers
Meilleurs messages d’erreur en mode --no-prompt
Variables d’environnement de build injectées dans tous les sous-processus de build (.NET, Node.js, Java, Python)

Pour conclure

La boucle locale de débogage d’agents IA est la star de cette version, mais l’accumulation d’améliorations de déploiement et de polish DX rend azd plus mature que jamais. Si vous déployez des apps .NET sur Azure — surtout des agents IA — cette mise à jour vaut le détour.

Consultez les notes de version complètes pour tous les détails.

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.

Agents | The .NET Blog

NL2SQL est l'injection SQL de l'ère agentique

Les problèmes dont personne ne parle dans la démo

Ce que SQL MCP Server résout réellement

La bonne question

Votre Agent IA a un Problème d'Identité (Et Voici le Modèle qui le Résout)

Le Problème Central : Authentification ≠ Autorisation

Comment Fonctionne la Chaîne de Tokens

Ce que le Modèle Déploie

Le Principe de Conception qui Vaut la Peine d’être Emprunté

Conclusion

CodeAct dans Agent Framework : Comment Réduire la Latence de votre Agent de Moitié

Qu’est-ce que CodeAct ?

Sécurité : Micro-VMs Hyperlight

Configuration minimale

Quand utiliser CodeAct (et quand ne pas l’utiliser)

Essayez maintenant

Où votre Agent se Souvient-il des Choses ? Guide Pratique sur le Stockage de l'Historique de Chat

Deux modèles fondamentaux

Comment Agent Framework abstrait cela

Référence rapide des fournisseurs

Comment choisir

Foundry Toolboxes : Un seul endpoint pour tous les outils de vos agents

Qu’est-ce qu’une Toolbox ?

Les quatre piliers (deux disponibles aujourd’hui)

Exemple pratique

Pas d’enfermement dans Foundry Agents

Pourquoi c’est important maintenant

Conclusion

VS Code 1.117 : Les Agents Obtiennent Leurs Propres Branches Git et Je Suis Totalement Pour

Le mode Autopilot se souvient enfin de votre préférence

Worktree et isolation git pour les sessions d’agents

Sous-agents et équipes d’agents

La sortie terminal automatiquement incluse quand les agents envoient de l’input

L’application Agents sur macOS se met à jour automatiquement

Les petites choses qui valent la peine d’être connues

Ce qu’il faut retenir

Où héberger vos agents IA sur Azure ? Un guide de décision pratique

Les six options en un coup d’œil

Foundry Hosted Agents — le sweet spot pour les développeurs .NET d’agents

Le déploiement est vraiment simple

Gestion de conversations intégrée

Mon framework de décision

Pour conclure

Azure MCP Server 2.0 Est Arrivé — L'Automatisation Agentic Self-Hosted Est Ici

Qu’est-ce qu’Azure MCP Server ?

Le grand changement : les déploiements distants self-hosted

Renforcement de la sécurité

Où pouvez-vous l’utiliser ?

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

Démarrage

Conclusion

L'Ingénierie de Plateformes Agentique Devient Réalité — Git-APE Montre Comment

Ce que Git-APE fait concrètement

Pourquoi c’est important

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

VS Code 1.116 — L'App Agents Obtient la Navigation Clavier et les Complétions de Contexte de Fichiers

Améliorations de l’app Agents

Résolution des liens CSS @import

Conclusion

azd permet maintenant d'exécuter et déboguer des agents IA localement — Ce qui a changé en mars 2026

Exécuter et déboguer des agents IA sans déployer

GitHub Copilot configure votre projet azd

Container App Jobs et améliorations de déploiement

Améliorations DX

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

Résolution des liens CSS `@import`