Azure | 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

Cosmos DB Shell Est en Préversion Publique — Et Il a un Serveur MCP Intégré

Emiliano Montesdeoca — Sun, 24 May 2026 00:00:00 +0000

Si vous avez déjà dû naviguer entre un onglet de portail, un exemple de SDK et un script à moitié terminé juste pour répondre à une question Cosmos DB, vous connaissez déjà la friction que ce projet est conçu pour éliminer.

Azure Cosmos DB Shell vient d’entrer en préversion publique. C’est un CLI open source avec une syntaxe de type bash et — la partie qui le rend intéressant — un serveur MCP intégré.

Ce Qui le Différencie des Autres CLIs de Base de Données

Le CLI lui-même est utile : commandes familières, support de script, intégration CI/CD. Cette partie est le minimum attendu pour un outil de base de données orienté développeur.

La partie intéressante est l’intégration du serveur MCP. Chaque commande que le CLI expose devient disponible comme outil MCP que vos agents IA peuvent appeler. Il n’y a pas de couche API personnalisée, pas de code d’intégration à écrire. Votre agent peut :

Naviguer dans les hiérarchies de bases de données avec cd, ls, pwd
Exécuter des requêtes SQL avec query et obtenir des résultats structurés
Créer et modifier des éléments avec create item, update, rm
Gérer des bases de données et des conteneurs avec mkdb, mkcon, rmdb, rmcon
Inspecter le contexte actuel avec endpoint, pwd

Le changement clé : votre agent ne parle pas à une API Cosmos DB — il parle à la même interface shell que vous utilisez. Les commandes sont déterministes, auditables et open source pour que vous puissiez inspecter exactement ce qui se passe.

La Base Open Source Compte

Ce n’est pas un service géré boîte noire. Le shell est open source, ce qui signifie :

Les équipes de sécurité peuvent auditer l’implémentation
Les équipes de plateforme peuvent le forker et l’étendre pour leurs standards spécifiques
Les développeurs peuvent contribuer des améliorations qui bénéficient à tous

Pour les équipes d’entreprise adoptant des outils IA, “peut-on voir exactement comment ça fonctionne” est de plus en plus une exigence non optionnelle. L’open source ici est un différenciateur significatif.

Trois Scénarios Qui Deviennent Plus Faciles

Analyse intelligente des données — connectez un agent au shell, posez des questions en langage naturel, obtenez des résultats de requêtes structurés. L’agent gère la construction de la requête ; le shell gère l’exécution.

Gestion autonome des données — les workflows qui doivent créer, mettre à jour ou supprimer des données dans Cosmos DB peuvent le faire via les outils MCP sans avoir besoin d’une intégration personnalisée.

Surveillance et alertes en temps réel — un agent peut interroger périodiquement des conteneurs, comparer les résultats et signaler des anomalies via le canal de notification approprié.

L’interface MCP rend ces scénarios composables avec n’importe quelle plateforme IA qui parle MCP — pas seulement les outils Microsoft.

Pour Commencer

Le shell est en préversion publique. Installez-le, configurez votre connexion Cosmos DB et activez le serveur MCP. De là, tout hôte d’agent compatible MCP peut découvrir et utiliser les outils.

Post original : Announcing the Public Preview of Azure Cosmos DB Shell: Open-Source Power Meets AI-Driven Database Automation

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

Endpoints Privés, VNets, NSGs — Aspire Gère le Réseau Maintenant

Emiliano Montesdeoca — Tue, 19 May 2026 00:00:00 +0000

J’ai vu ce scénario trop de fois. L’application est terminée. La démo est excellente. Puis la liste de contrôle de sécurité arrive : sortir le stockage d’internet public, s’exécuter dans un VNet, fournir des IPs sortantes pour la liste d’autorisation du partenaire, prouver que seuls les bons sous-réseaux parlent aux bons services.

À ce stade, le modèle d’application et le modèle d’infrastructure commencent à diverger de manières douloureuses à maintenir.

Le nouveau support réseau d’entreprise Azure pour Aspire répond directement à cela. Vous décrivez la forme du réseau à côté des ressources qui l’utilisent, dans votre AppHost.

Les Blocs de Construction

Voici à quoi sert chaque concept réseau Azure, résumé :

Fonctionnalité	Utilisez-le quand	Pourquoi c’est important
Réseau virtuel	Vous avez besoin d’un espace d’adressage privé	La limite réseau pour les sous-réseaux, les endpoints privés et le routage
Sous-réseau	Vous devez séparer les charges de travail dans le VNet	Chaque partie du système obtient sa propre plage d’adresses et surface de politique
Sous-réseau délégué	Un service de plateforme (comme ACA) doit gérer un sous-réseau	Permet au service de placer une infrastructure gérée dans votre VNet en toute sécurité
Passerelle NAT	Vous avez besoin d’IPs publiques sortantes prévisibles	Adresse stable pour les listes d’autorisation et l’audit
Endpoint privé	Vous voulez une ressource PaaS accessible privément	Place une IP privée pour ce service dans votre VNet, supprime l’exposition publique
NSG	Vous avez besoin de règles de trafic au niveau du sous-réseau	Autoriser/refuser explicitement pour le trafic entrant et sortant par sous-réseau

Le Décrire dans votre AppHost

Le changement clé ici est que vous modélisez le réseau aux côtés des ressources qui l’utilisent, pas dans un fichier Bicep séparé qui dérive du modèle d’application avec le temps.

Depuis l’AppHost, vous pouvez :

Créer des VNets et des sous-réseaux avec AddVirtualNetwork() et AddSubnet()
Attacher une passerelle NAT aux sous-réseaux pour des IPs sortantes stables
Créer des endpoints privés pour le stockage, Key Vault, SQL et d’autres services PaaS
Définir des NSG avec des règles de sécurité entrantes et sortantes
Configurer des Périmètres de Sécurité Réseau pour des politiques inter-ressources

Le résultat est que lorsque vous exécutez azd up, l’infrastructure correspond à ce que le modèle d’application dit qu’il a besoin. Pas ce que dit un modèle maintenu manuellement.

Pourquoi C’est Important pour les Applications Réelles

Quelques choses qui deviennent significativement plus faciles une fois que le réseau est modélisé dans Aspire :

Endpoints privés pour Key Vault et stockage — vous décrivez WithPrivateEndpoint() sur ces ressources, et Aspire gère la configuration des zones DNS et l’attachement des endpoints. L’application ne change jamais.

IPs sortantes cohérentes — ajoutez une passerelle NAT au sous-réseau concerné et chaque requête sortante de votre application passe par une IP connue et stable. Les partenaires peuvent l’autoriser. Les auditeurs peuvent la tracer.

Règles NSG depuis le code — au lieu de cliquer dans le portail ou de maintenir un extrait Bicep, vos règles de sécurité vivent dans l’AppHost aux côtés des ressources qu’elles protègent.

C’est le type d’intégration qui ne rend pas les démos excitantes mais rend les systèmes de production maintenables.

Conclusion

La sécurité réseau apparaissant tard dans le cycle de vie du projet est un problème résolu si vous la modélisez aux côtés de l’application dès le début. Le support réseau d’entreprise d’Aspire rend cela possible sans nécessiter une piste d’infrastructure séparée.

Détails complets dans l’article original : Securing Azure apps with Aspire enterprise networking

Aspire 13.3 : Support Kubernetes, Journaux du Navigateur et la Compétence Aspireify

Emiliano Montesdeoca — Mon, 18 May 2026 00:00:00 +0000

Cinq semaines, ce n’est pas beaucoup pour une version, mais Aspire 13.3 ne le semble pas. Les éléments principaux sont significatifs : déploiement Kubernetes et AKS de première classe avec Helm, une compétence d’intégration assistée par agent appelée Aspireify, la capture des journaux du navigateur directement dans le dashboard et des résultats de commandes structurés. En plus, 45 nouvelles fonctionnalités, 134 améliorations et 93 corrections de bugs.

Passons aux points saillants.

Aspireify : Intégration Assistée par Agent

Ajouter Aspire à un projet existant semble simple — ajoutez un AppHost, c’est fait. En pratique, cela implique beaucoup d’archéologie : quels ports comptent, quelles variables d’environnement sont de vraies dépendances, quels services Docker Compose doivent correspondre aux intégrations Aspire.

La nouvelle compétence Aspireify donne à votre agent de code un flux de travail guidé précisément pour cela. Quand aspire init crée un AppHost squelette, la compétence Aspireify aide l’agent à inspecter le dépôt, à comprendre comment il fonctionne déjà et à câbler l’AppHost pour s’adapter à l’application — pas l’inverse.

La posture par défaut est “minimiser les modifications de votre code.” Si votre application lit déjà DATABASE_URL, l’agent le mappe avec WithEnvironment() au lieu de vous demander de réécrire votre configuration. Si un port est codé en dur, la compétence indique à l’agent quand le préserver.

C’est le type d’outillage IA qui fait réellement gagner du temps plutôt que de générer plus de travail à revoir.

Déploiement Kubernetes et AKS de Première Classe

Celui-là était sur la liste de souhaits depuis un moment. Aspire 13.3 inclut le support de déploiement Kubernetes et AKS de première classe avec Helm. Vous pouvez maintenant cibler AKS comme destination de déploiement directement depuis les outils Aspire.

Pour les équipes qui exécutent déjà des charges de travail de production sur AKS, cela comble un écart significatif. Votre modèle d’application Aspire a maintenant un chemin propre du développement local vers Kubernetes sans rédaction manuelle de charts Helm.

Journaux du Navigateur dans le Dashboard

C’est une de ces fonctionnalités qui semblent mineures jusqu’à ce que vous déboguiez un problème frontend.

La nouvelle API WithBrowserLogs() attache une ressource de navigateur suivie à toute ressource capable d’endpoints. Aspire lance Chromium en utilisant un pipe CDP privé et diffuse les journaux de console, les requêtes réseau et les erreurs directement dans le flux de journaux de la ressource :

var frontend = builder.AddViteApp("frontend", "../frontend")
 .WithHttpEndpoint(port: 3000)
 .WithBrowserLogs();

L’AppHost TypeScript prend en charge la même chose :

const frontend = await builder.addViteApp("frontend", "../frontend")
 .withHttpEndpoint({ port: 3000 })
 .withBrowserLogs();

Erreurs de console, requêtes réseau échouées, exceptions côté client — tout visible dans le même dashboard où vous regardez déjà les traces et métriques. Plus besoin de changer d’onglet vers les DevTools du navigateur pour les bases.

Résultats de Commandes Structurés

Les commandes de ressources ont reçu une mise à niveau significative. Jusqu’à présent, les commandes renvoyaient succès/échec. Maintenant elles retournent des résultats structurés : texte, JSON ou markdown qui circule à travers le modèle, l’interface du dashboard, la CLI et les outils MCP.

Le dashboard relie tout cela avec un nouveau centre de notifications dans l’en-tête. Les résultats des commandes apparaissent sous forme de notifications horodatées avec rendu markdown et une action “Voir la réponse”.

Cela rend les commandes de ressources véritablement composables. Une intégration peut maintenant exposer une commande qui renvoie une sortie significative — comme une URL de tunnel — plutôt que de simplement changer d’état quelque part.

En Résumé

Aspire 13.3 vaut la mise à jour ne serait-ce que pour le support Kubernetes. Les journaux du navigateur et les résultats de commandes structurés ressemblent au type d’améliorations de qualité de vie qui s’accumulent rapidement dans un flux de travail de développement quotidien.

Notes de version complètes : What’s New in Aspire 13.3

SDD Conference 2026

Mon, 11 May 2026 00:00:00 +0000

SDD 2026 se déroule du 11 au 15 mai 2026 au Barbican Centre à Londres. La conférence principale de 3 jours va du mardi au jeudi, avec des workshops optionnels d’une journée le lundi et le vendredi.

Avec 78 sessions et 14 workshops, c’est l’une des conférences développeurs les plus denses en Europe.

Sujets

Pensée Architecturale
Code Fonctionnel en C# 13
Design Serverless
IA Sémantique
Azure Kubernetes Services
Stratégies Lean DevOps
The Model Context Protocol (MCP)
IA Agentique en .NET
Refactoring du Monolithe
Coder Plus Vite avec les LLMs
Cryptographie dans un Monde Post-Quantique
Développement Local First

Speakers

Un plateau de classe mondiale avec Kevlin Henney, Neal Ford, Sander Hoogendoorn, Andrew Clymer, Jacqui Read, Christian Weyer, Jeff Prosise, Jules May, Oliver Sturm et Raju Gandhi.

Billets et informations

98 % des participants de SDD 2025 ont évalué l’expérience globale comme bonne, très bonne ou excellente.

SQL MCP Server sur Azure App Service — Sans Conteneurs

Emiliano Montesdeoca — Tue, 05 May 2026 00:00:00 +0000

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

Soyons honnêtes : chaque fois que je lis “nécessite un conteneur” dans un tutoriel, une petite partie de moi soupire. Les conteneurs sont formidables — jusqu’à ce que ton équipe n’ait pas de stratégie de conteneurs, et soudain une fonctionnalité qui semblait simple se retrouve bloquée par une complexité d’orchestration que personne n’avait anticipée.

C’est pourquoi celui-ci a retenu mon attention. Le SQL MCP Server peut désormais s’exécuter sur Azure App Service — sans Docker, sans Kubernetes, juste avec la même configuration Data API Builder (DAB) qui expose ta base de données SQL via MCP, REST et GraphQL.

Qu’est-ce que le SQL MCP Server ?

Contexte rapide si tu ne le connais pas encore. Le SQL MCP Server se place entre ton agent IA et ta base de données SQL. Au lieu de donner à ton agent un accès direct à la base de données (une très mauvaise idée), il expose tes tables et vues comme une couche d’abstraction — des entités avec des permissions définies.

Il est construit sur Data API Builder, ce qui signifie qu’un seul fichier de configuration gère MCP et REST et GraphQL simultanément. Ton agent parle à l’endpoint MCP. Ton application traditionnelle parle à REST ou GraphQL. Même config, même runtime, surfaces différentes.

C’est vraiment utile. Tu ne maintiens pas deux couches d’API séparées.

Le Problème des Conteneurs (et la Solution)

Le modèle de déploiement original du SQL MCP Server utilisait des conteneurs. Cela fonctionne bien dans beaucoup d’équipes — mais pas toutes. De nombreuses équipes .NET standardisent sur Azure App Service ou des VMs. Exiger un runtime de conteneur juste pour exposer un endpoint SQL ajoute de la friction que personne n’a demandée.

Le nouveau guide montre comment contourner entièrement le conteneur. Tout fonctionne avec une commande dab start, hébergé sur App Service comme un processus web .NET 8 standard.

# Installer Data API Builder
dotnet tool install microsoft.dataapibuilder --prerelease -g

# Initialiser la configuration
dab init --database-type mssql --host-mode Development --connection-string "@env('SQL_CONNECTION_STRING')"

# Ajouter une entité
dab add products --source dbo.products --permissions "authenticated:*"

# Configurer le fournisseur d'auth App Service
dab configure --runtime.host.authentication.provider AppService

# Démarrer le serveur
dab start

À ce stade, tu as MCP à /mcp, REST et GraphQL depuis le même processus, et rien qui tourne dans un conteneur.

Authentification Sans Clés d’API Partagées

C’est la partie que j’apprécie le plus. Quand tu déploies sur App Service, tu configures Microsoft Entra ID comme fournisseur d’authentification. Pas de secrets partagés dans les fichiers de configuration, pas de clés d’API à faire tourner.

La chaîne de connexion reste dans une variable d’environnement App Service (pas dans dab-config.json), et l’endpoint MCP est protégé par l’authentification de la plateforme. Si tu es déjà aligné sur Entra ID pour tes charges de travail Azure, cela s’intègre naturellement.

Pour le développement local, tu passes en mode Simulator et transport STDIO. Tu reviens en mode AppService avant le déploiement. Propre et explicite.

Déploiement sur App Service

az appservice plan create \
 --name <plan-name> \
 --resource-group <resource-group> \
 --sku B1 \
 --is-linux

az webapp create \
 --name <app-name> \
 --resource-group <resource-group> \
 --plan <plan-name> \
 --runtime "DOTNETCORE:8.0"

az webapp config set \
 --name <app-name> \
 --resource-group <resource-group> \
 --startup-file "dab start"

Ensuite tu déploies ton projet DAB en utilisant la méthode de déploiement de code que ton équipe utilise déjà. Le détail clé : c’est un déploiement de code, pas de conteneur.

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

Si tu construis des agents IA en .NET, ton agent devra tôt ou tard communiquer avec une base de données. Le SQL MCP Server te donne une façon structurée de le faire sans exposer des chaînes de connexion brutes.

Consulte le guide complet dans le billet original et le dépôt d’exemple sur GitHub.

Conclusion

Le SQL MCP Server sur App Service est une option pragmatique solide pour les équipes .NET qui souhaitent donner à leurs agents un accès structuré aux données SQL sans stratégie de conteneurs. Essaie-le — tes agents apprécieront la surface d’API propre.

Supprimer le Travail Répétitif de la Migration avec l'Agentic Platform Engineering

Emiliano Montesdeoca — Tue, 05 May 2026 00:00:00 +0000

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

Removing the Monkey Work of Migration with Agentic Platform Engineering — une présentation de Git-Ape (outil git d’ingénierie de plateforme agentique) qui migre un vrai dépôt Terraform AWS vers Azure, en se concentrant sur l’extraction d’intention plutôt que sur une conversion ligne par ligne.

L’entrée : contoso-migration

La source est un vrai projet Terraform (contoso-migration) qui déploie une application Next.js sur AWS — EC2 pour le calcul, ALB pour l’équilibrage de charge, S3 pour les artefacts, et des clés IAM pour l’identité. Coût : ~34 $/mois. L’objectif n’est pas de reproduire la même infrastructure sur Azure ; c’est de comprendre ce que le déploiement essaie réellement de faire et de le reconstruire avec des services natifs Azure.

Étape 1 : Validation et authentification

Git-Ape commence par valider tous les outils CLI requis — az, aws, gh, jq, git — et en confirmant les sessions d’authentification actives avant de toucher quoi que ce soit. Pas d’exécutions partielles.

Étape 2 : Extraction d’intention

L’agent lit l’intégralité du dépôt source via l’API GitHub et extrait l’intention de déploiement : runtime (Node.js), type de calcul, modèle d’ingress, gestion des artefacts, modèle d’identité, réseau et surveillance. C’est l’étape clé — elle construit un modèle sémantique de ce que fait le déploiement, pas quels mots-clés Terraform il utilise.

Étape 3 : Correspondance de services

Les services AWS sont mappés vers leurs équivalents Azure :

EC2 → App Service (Linux, Node 20 LTS)
ALB → Équilibrage de charge intégré d’App Service
Rôles/clés IAM → Managed Identity
Terraform → Bicep + GitHub Actions

Étape 4 : Agent de critique

Avant de générer la sortie, un agent de critique s’exécute et détecte deux problèmes bloquants :

Anti-modèle de build au démarrage — le Terraform original exécutait npm install && npm run build sur EC2 au démarrage. Correction : construire dans CI, déployer un artefact prêt.
Blob Storage inutile — S3 était utilisé pour la mise en attente d’artefacts qui pouvait être éliminé avec un CI/CD approprié. L’agent de critique l’a supprimé entièrement.

Étape 5 : Sortie générée

Le résultat est ~80 lignes de Bicep au lieu des 200+ lignes originales de Terraform. L’agent a créé un nouveau dépôt GitHub avec infra/main.bicep et .github/workflows/deploy.yml et supprimé tous les fichiers spécifiques à AWS.

Comparaison de la posture de sécurité

La migration a également produit une amélioration significative de la sécurité :

AWS original	Sortie Azure
HTTP uniquement	HTTPS uniquement, TLS 1.2
SSH ouvert à 0.0.0.0/0	Pas d’exposition SSH
Clés d’accès IAM	OIDC + Managed Identity
Pas de surveillance	Application Insights

Coût : ~13 $/mois vs les 34 $/mois originaux.

Ce qui le distingue d’un convertisseur de syntaxe

L’étape de l’agent de critique est ce qui sépare ceci d’une traduction mécanique. Il a détecté des modèles qui auraient fonctionné sur AWS mais seraient incorrects sur Azure — et les a corrigés plutôt que de les répliquer. La sortie n’est pas “AWS en syntaxe Azure” ; c’est un déploiement natif Azure qui atteint le même objectif plus proprement.

Consultez le guide complet pour la trace complète de l’agent et les fichiers générés.

SQL Server 2025 comme Base de Données Prête pour les Agents : Sécurité, Backup et MCP dans un Seul Moteur

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

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

J’ai suivi la série Polyglot Tax d’Aditya Badramraju avec beaucoup d’intérêt. La partie 4 clôt la série avec les parties qui déterminent vraiment si vous feriez confiance à cette architecture en production.

Un Modèle de Sécurité pour Tous les Modèles de Données

Une seule politique Row-Level Security couvre toutes les tables — relationnelles, JSON, graphes, vecteurs. Une politique, une preuve pour l’auditeur.

Backup Unifié = Récupération Atomique

Dans un stack polyglottes, la récupération point-in-time sur cinq bases de données est un cauchemar de cohérence. Avec une seule base de données, c’est atomique par définition.

Intégration MCP : Agents Sans Middleware

SQL Server 2025 supporte directement le SQL MCP Server. Les agents appellent des outils, le moteur impose l’isolation tenant et le masquage des colonnes automatiquement.

Conclusion

Pour les développeurs .NET qui construisent des applications agent-first sur Azure SQL, cette architecture mérite une sérieuse considération. Post original d’Aditya Badramraju : The Polyglot Tax – Part 4.

Azure MCP Server Est Maintenant un .mcpb — Installez-le sans Aucun Runtime

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

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

Vous savez ce qui était pénible dans la configuration des serveurs MCP ? Vous aviez besoin d’un runtime. Node.js pour la version npm, Python pour pip/uvx, .NET SDK pour la variante dotnet.

L’Azure MCP Server vient de changer cela. Il est maintenant disponible en tant que .mcpb — un MCP Bundle — et la configuration se fait par glisser-déposer.

Qu’est-ce qu’un MCP Bundle ?

Pensez-y comme à une extension VS Code (.vsix) ou une extension de navigateur (.crx), mais pour les serveurs MCP. Un fichier .mcpb est une archive ZIP autonome incluant le binaire du serveur et toutes ses dépendances.

Comment l’installer

1. Téléchargez le bundle pour votre plateforme

Allez sur la page GitHub Releases et téléchargez le fichier .mcpb pour votre OS et architecture.

2. Installez dans Claude Desktop

Le plus simple : faites glisser le fichier .mcpb dans la fenêtre Claude Desktop sur la page des paramètres Extensions (☰ → Fichier → Paramètres → Extensions). Vérifiez les détails du serveur, cliquez sur Installer, confirmez.

3. Authentifiez-vous auprès d’Azure

az login

C’est tout. Azure MCP Server utilise vos identifiants Azure existants.

Ce que vous pouvez faire avec

Plus de 100 outils de services Azure directement depuis votre client IA :

Interroger et gérer Cosmos DB, Storage, Key Vault, App Service, Foundry
Générer des commandes az CLI pour n’importe quelle tâche
Créer des modèles Bicep et Terraform

Pour commencer

Téléchargement : GitHub Releases
Dépôt : aka.ms/azmcp
Docs : aka.ms/azmcp/docs

Consultez le post complet.

Azure SDK Avril 2026 : AI Foundry 2.0 et Ce Que les Développeurs .NET Doivent Savoir

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

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

Les versions mensuelles du SDK sont souvent faciles à ignorer. Celle-ci a quelques points à retenir — surtout si vous construisez avec AI Foundry, Cosmos DB en Java, ou faites du provisionnement d’infrastructure depuis du code .NET.

Azure.AI.Projects 2.0.0 — Changements Cassants Qui Font Sens

Le paquet NuGet Azure.AI.Projects atteint la version stable 2.0.0: séparations de namespaces, types renommés, et convention Is* cohérente pour les booléens.

Cosmos DB Java : Correctif de Sécurité Critique (RCE)

La version 4.79.0 inclut un correctif critique pour une vulnérabilité d’exécution de code à distance (CWE-502). Mise à jour immédiate requise.

Nouvelles Bibliothèques de Provisioning pour .NET

Conclusion

Le point fort pour les développeurs .NET ce mois-ci : Azure.AI.Projects 2.0.0 est stable. Post original : Azure SDK Release (April 2026).

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.

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.

azd + GitHub Copilot : Configuration de projet assistée par IA et résolution intelligente des erreurs

Emiliano Montesdeoca — Tue, 21 Apr 2026 00:00:00 +0000

Tu connais ce moment où tu veux déployer une app existante sur Azure et tu te retrouves à fixer un azure.yaml vide, en essayant de te rappeler si ton API Express devrait utiliser Container Apps ou App Service ? Ce moment vient de devenir beaucoup plus court.

L’Azure Developer CLI (azd) s’intègre maintenant avec GitHub Copilot de deux façons concrètes : scaffolding assisté par IA pendant azd init, et résolution intelligente des erreurs quand les déploiements échouent. Les deux fonctionnalités restent entièrement dans ton terminal — exactement là où je veux qu’elles soient.

Configuration avec Copilot pendant azd init

Quand tu lances azd init, il y a maintenant une option “Set up with GitHub Copilot (Preview)”. Sélectionne-la et Copilot analyse ta base de code pour générer l’azure.yaml, les templates d’infrastructure et les modules Bicep — basés sur ton code réel.

azd init
# Sélectionne : "Set up with GitHub Copilot (Preview)"

Prérequis :

azd 1.23.11 ou supérieur — vérifie avec azd version ou mets à jour avec azd update
Un abonnement GitHub Copilot actif (Individual, Business ou Enterprise)
GitHub CLI (gh) — azd demandera la connexion si nécessaire

Ce que je trouve vraiment utile : ça fonctionne dans les deux sens. Tu construis depuis zéro ? Copilot t’aide à configurer les bons services Azure dès le départ. Tu as une app existante que tu voulais déployer depuis longtemps ? Pointe Copilot dessus et il génère la configuration sans que tu aies à restructurer quoi que ce soit.

Ce que ça fait concrètement

Imaginons une API Express Node.js avec une dépendance PostgreSQL. Au lieu de décider manuellement entre Container Apps et App Service, puis d’écrire du Bicep depuis zéro, Copilot détecte ton stack et génère :

Un azure.yaml avec les bons paramètres language, host et build
Un module Bicep pour Azure Container Apps
Un module Bicep pour Azure Database for PostgreSQL

Et il effectue des vérifications préalables avant de toucher quoi que ce soit — vérifie que ton répertoire git est propre, demande le consentement pour les outils du serveur MCP. Rien ne se passe sans que tu saches exactement ce qui va changer.

Résolution d’erreurs avec Copilot

Les erreurs de déploiement, ça arrive. Paramètres manquants, problèmes de permissions, disponibilité des SKUs — et le message d’erreur ne te dit rarement la seule chose dont tu as vraiment besoin : comment régler le problème.

Sans Copilot, la boucle ressemble à : copier l’erreur → chercher dans la doc → lire trois réponses Stack Overflow hors sujet → exécuter quelques commandes az CLI → réessayer en espérant que ça marche. Avec Copilot intégré dans azd, cette boucle s’effondre. Quand une commande azd échoue, elle propose immédiatement quatre options :

Explain — explication en langage naturel de ce qui s’est passé
Guidance — instructions étape par étape pour corriger le problème
Diagnose and Guide — analyse complète + Copilot applique le correctif (avec ton approbation) + nouvelle tentative optionnelle
Skip — gérer toi-même

L’essentiel : Copilot a déjà le contexte de ton projet, la commande qui a échoué et les détails de l’erreur. Ses suggestions sont spécifiques à ta situation, pas de la documentation générique.

Configurer un comportement par défaut

Si tu choisis toujours la même option, saute le prompt interactif :

azd config set copilot.errorHandling.category troubleshoot

Valeurs : explain, guidance, troubleshoot, fix, skip. Tu peux aussi activer l’auto-fix et le retry :

azd config set copilot.errorHandling.fix allow

Retour au mode interactif à tout moment :

azd config unset copilot.errorHandling.category

Conclusion

C’est exactement le type d’intégration Copilot qui apporte une vraie valeur. Essaie-le en lançant azd update pour obtenir la dernière version, puis utilise azd init sur ton prochain projet.

Lis l’annonce originale ici.

Global Azure Spain 2026

Sat, 18 Apr 2026 00:00:00 +0000

Global Azure Spain 2026 a lieu le 18 avril 2026 au Kinépolis Diversia à Alcobendas, Madrid. C’est le plus grand événement communautaire Azure en Espagne, réunissant 38 speakers sur 3 tracks parallèles couvrant les agents IA, le réseau Azure, Cosmos DB, Fabric, IoT, la sécurité et bien plus.

L’événement se déroule de 08h30 à 18h30 et comprend une keynote, des pauses café, un déjeuner et une session de clôture Q&A.

Points forts de l’agenda

Domando Agentes de IA : gouvernance, outils et APIs avec Azure AI Foundry et Azure API Management
Construyendo agentes con LibreChat en Azure
How Can I Steal Your Data with Azure Private Endpoints
Stop Building APIs. Forge Agents with Azure
Agentic DevOps Meets IoT: Real-Time Systems with Fabric and GitHub Copilot
El regreso de los tamagotchis! : systèmes multi-agents en action
Foundry Control Plane como plataforma de Agentes global
Rompiendo el perímetro: Zero Trust aplicado en Azure

Billets

L’inscription est une donation symbolique — le prix du billet est entièrement reversé à Plan International, soutenant les droits des enfants et l’égalité dans le monde. Capacité limitée, alors réservez votre place rapidement.

Azure Tour 2026

Au-delà de Madrid, le Global Azure Tour 2026 comprend également des étapes à Saragosse, Tenerife et Séville.

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

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.

Vos expériences IA sur Azure brûlent de l'argent — Voici comment y remédier

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

Si vous construisez des applications alimentées par l’IA sur Azure en ce moment, vous avez probablement remarqué quelque chose : votre facture cloud a changé. Pas juste plus élevée — plus bizarre. Avec des pics. Difficile à prévoir.

Microsoft vient de publier un excellent article sur les principes d’optimisation des coûts cloud qui comptent toujours, et honnêtement, le timing ne pourrait pas être meilleur. Parce que les charges de travail IA ont changé la donne en matière de coûts.

Pourquoi les charges de travail IA frappent différemment

Voilà le truc. Les charges de travail .NET traditionnelles sont relativement prévisibles. Vous connaissez votre niveau App Service, vous connaissez vos DTUs SQL, vous pouvez estimer les dépenses mensuelles assez précisément. Les charges de travail IA ? Pas vraiment.

Vous testez plusieurs modèles pour voir lequel convient. Vous démarrez de l’infrastructure GPU pour du fine-tuning. Vous faites des appels API à Azure OpenAI où la consommation de tokens varie énormément selon la longueur du prompt et le comportement des utilisateurs. Chaque expérience coûte de l’argent réel, et vous pourriez en mener des dizaines avant de trouver la bonne approche.

Cette imprévisibilité est ce qui rend l’optimisation des coûts critique — pas comme une réflexion après coup, mais dès le premier jour.

Gestion vs. optimisation — connaissez la différence

Une distinction de l’article que les développeurs négligent selon moi : il y a une différence entre la gestion des coûts et l’optimisation des coûts.

La gestion, c’est le suivi et le reporting. Vous configurez des budgets dans Azure Cost Management, vous recevez des alertes, vous consultez des tableaux de bord. C’est le minimum.

L’optimisation, c’est là que vous prenez réellement des décisions. Avez-vous vraiment besoin de ce tier S3, ou le S1 gérerait-il votre charge ? Cette instance de calcul toujours allumée est-elle inactive le week-end ? Pourriez-vous utiliser des instances spot pour vos jobs d’entraînement ?

En tant que développeurs .NET, nous avons tendance à nous concentrer sur le code et à laisser les décisions d’infrastructure à « l’équipe ops ». Mais si vous déployez sur Azure, ces décisions sont aussi les vôtres.

Ce qui fonctionne vraiment

En me basant sur l’article et ma propre expérience, voici ce qui fait la différence :

Sachez ce que vous dépensez et où. Taguez vos ressources. Sérieusement. Si vous ne pouvez pas identifier quel projet ou expérience mange votre budget, vous ne pouvez rien optimiser. Azure Cost Management avec un tagging approprié est votre meilleur allié.

Mettez des garde-fous avant d’expérimenter. Utilisez Azure Policy pour restreindre les SKUs coûteux dans les environnements dev/test. Définissez des limites de dépenses sur vos déploiements Azure OpenAI. N’attendez pas que la facture arrive pour réaliser que quelqu’un a laissé un cluster GPU tourner tout le week-end.

Dimensionnez en continu. Cette VM que vous avez choisie pendant le prototypage ? Elle est probablement inadaptée pour la production. Azure Advisor vous donne des recommandations — regardez-les vraiment. Faites une revue mensuelle, pas annuelle.

Pensez au cycle de vie. Les ressources de développement devraient s’éteindre. Les environnements de test n’ont pas besoin de tourner 24h/24. Utilisez des politiques d’arrêt automatique. Pour les charges de travail IA spécifiquement, envisagez des options serverless où vous payez par exécution au lieu de maintenir du calcul actif.

Mesurez la valeur, pas seulement le coût. Celle-ci est facile à oublier. Un modèle qui coûte plus cher mais fournit des résultats nettement meilleurs pourrait être le bon choix. L’objectif n’est pas de dépenser le moins possible — c’est de dépenser intelligemment.

Ce qu’il faut retenir

L’optimisation des coûts cloud n’est pas un nettoyage ponctuel. C’est une habitude. Et avec les charges de travail IA qui rendent les dépenses plus imprévisibles que jamais, prendre cette habitude tôt vous épargne des surprises douloureuses par la suite.

Si vous êtes un développeur .NET qui construit sur Azure, commencez à traiter votre facture cloud comme vous traitez votre code — révisez-la régulièrement, refactorisez quand ça devient désordonné, et ne déployez jamais sans comprendre ce que ça va vous coûter.

Les outils Azure MCP sont désormais intégrés dans Visual Studio 2022 — Aucune extension nécessaire

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

Si vous avez utilisé les outils Azure MCP dans Visual Studio via l’extension séparée, vous connaissez la chanson — installer le VSIX, redémarrer, espérer que rien ne casse, gérer les incompatibilités de versions. Cette friction, c’est terminé.

Yun Jung Choi a annoncé que les outils Azure MCP sont désormais livrés directement avec la charge de travail développement Azure dans Visual Studio 2022. Pas d’extension. Pas de VSIX. Pas de danse du redémarrage.

Ce que ça signifie concrètement

À partir de Visual Studio 2022 version 17.14.30, le Azure MCP Server est inclus dans la charge de travail développement Azure. Si vous avez déjà cette charge de travail installée, il suffit de l’activer dans GitHub Copilot Chat et c’est parti.

Plus de 230 outils couvrant 45 services Azure — accessibles directement depuis la fenêtre de chat. Listez vos comptes de stockage, déployez une app ASP.NET Core, diagnostiquez des problèmes App Service, interrogez Log Analytics — le tout sans ouvrir un onglet de navigateur.

Pourquoi c’est plus important qu’il n’y paraît

Voici le truc avec l’outillage développeur : chaque étape supplémentaire est de la friction, et la friction tue l’adoption. Avoir MCP en tant qu’extension séparée signifiait des incompatibilités de versions, des échecs d’installation, et une chose de plus à maintenir à jour. L’intégrer dans la charge de travail signifie :

Un seul chemin de mise à jour via le Visual Studio Installer
Pas de décalage de version entre l’extension et l’IDE
Toujours à jour — le MCP Server se met à jour avec les releases régulières de VS

Pour les équipes qui standardisent sur Azure, c’est un vrai gain. Vous installez la charge de travail une fois, activez les outils, et ils sont disponibles à chaque session.

Ce que vous pouvez faire avec

Les outils couvrent l’intégralité du cycle de développement via Copilot Chat :

Apprendre — posez des questions sur les services Azure, les bonnes pratiques, les patterns d’architecture
Concevoir et développer — obtenez des recommandations de services, configurez le code de votre application
Déployer — provisionnez des ressources et déployez directement depuis l’IDE
Dépanner — interrogez les logs, vérifiez l’état des ressources, diagnostiquez les problèmes en production

Un exemple rapide — tapez ceci dans Copilot Chat :

List my storage accounts in my current subscription.

Copilot appelle les outils Azure MCP en coulisses, interroge vos abonnements, et renvoie une liste formatée avec les noms, emplacements et SKUs. Pas besoin du portail.

Comment l’activer

Mettez à jour vers Visual Studio 2022 17.14.30 ou supérieur
Assurez-vous que la charge de travail Azure development est installée
Ouvrez GitHub Copilot Chat
Cliquez sur le bouton Select tools (l’icône des deux clés)
Activez Azure MCP Server

C’est tout. Ça reste activé entre les sessions.

Un bémol

Les outils sont désactivés par défaut — vous devez les activer manuellement. Et les outils spécifiques à VS 2026 ne sont pas disponibles dans VS 2022. La disponibilité des outils dépend également des permissions de votre abonnement Azure, comme sur le portail.

La vue d’ensemble

Cela fait partie d’une tendance claire : MCP est en train de devenir le standard pour exposer les outils cloud dans les IDEs de développement. Nous avons déjà vu la release stable d’Azure MCP Server 2.0 et des intégrations MCP dans VS Code et d’autres éditeurs. L’intégrer dans le système de charges de travail de Visual Studio est la progression naturelle.

Pour nous développeurs .NET qui vivons dans Visual Studio, ça élimine encore une raison de basculer vers le portail Azure. Et honnêtement, moins on change d’onglet, mieux c’est.

Aspire 13.2 accueille MongoDB EF Core et Azure Data Lake — Deux intégrations à essayer

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

Aspire 13.2 vient d’arriver avec deux nouvelles intégrations de bases de données qui méritent votre attention : MongoDB Entity Framework Core et Azure Data Lake Storage. Si vous vouliez utiliser EF Core avec MongoDB dans une app Aspire, ou si vous aviez besoin de connecter des workloads data lake avec du service discovery, cette version apporte les deux.

MongoDB rencontre EF Core dans Aspire

C’est celle qui m’enthousiasme le plus. Aspire supporte MongoDB depuis un moment, mais c’était toujours le driver brut — pas d’EF Core, pas de DbContext, pas de requêtes LINQ sur vos documents. Maintenant vous avez l’expérience complète d’EF Core avec MongoDB, plus les health checks automatiques et le service discovery d’Aspire.

La mise en place suit le pattern typique d’Aspire. Dans votre AppHost :

var mongodb = builder.AddMongoDB("mongodb")
 .WithDataVolume()
 .WithLifetime(ContainerLifetime.Persistent);

var apiService = builder.AddProject<Projects.ApiService>("api")
 .WithReference(mongodb);

Puis dans votre projet consommateur, ajoutez l’intégration EF Core :

dotnet add package Aspire.MongoDB.EntityFrameworkCore

Et enregistrez votre DbContext :

builder.AddMongoDbContext<MyDbContext>("mongodb", "mydb");

À partir de là, c’est de l’EF Core standard. Définissez vos entités, utilisez votre DbContext comme vous le feriez avec n’importe quel autre provider. L’intégration gère le connection pooling, les traces OpenTelemetry et les health checks en arrière-plan.

Pour les développeurs .NET qui utilisaient MongoDB avec le driver brut et configuraient les connection strings manuellement, c’est une belle amélioration. Vous obtenez l’abstraction complète d’EF Core sans perdre le service discovery d’Aspire.

Azure Data Lake Storage entre dans la danse

Le deuxième ajout majeur est une intégration Azure Data Lake Storage (ADLS). Si vous construisez des pipelines de données, des processus ETL ou des plateformes d’analytique, vous pouvez maintenant connecter des ressources Data Lake de la même façon que n’importe quelle autre dépendance Aspire.

Dans l’AppHost :

var storage = builder.AddAzureStorage("azure-storage");
var dataLake = storage.AddDataLake("data-lake");
var fileSystem = storage.AddDataLakeFileSystem("data-lake-file-system");

var analyticsService = builder.AddProject<Projects.AnalyticsService>("analytics")
 .WithReference(dataLake)
 .WithReference(fileSystem);

Dans le projet consommateur :

builder.AddAzureDataLakeServiceClient("data-lake");
builder.AddAzureDataLakeFileSystemClient("data-lake-file-system");

Pas de gestion manuelle de connection strings, pas de recherche de credentials. Aspire provisionne les ressources et les injecte. Pour ceux d’entre nous qui construisent des apps .NET cloud-native touchant à la fois aux données opérationnelles et aux workloads analytiques, cela fait du data lake un citoyen de première classe dans le modèle Aspire.

Les petits correctifs qui comptent

Au-delà des fonctionnalités principales, il y a quelques améliorations à noter :

Correction du connection string MongoDB — le slash avant le nom de la base de données est maintenant géré correctement. Si vous aviez un workaround, vous pouvez le supprimer
Exports SQL Server — Aspire.Hosting.SqlServer exporte maintenant des options de configuration serveur supplémentaires pour un contrôle plus fin
Mises à jour des émulateurs — émulateur ServiceBus 2.0.0, émulateur App Configuration 1.0.2, et l’émulateur preview de CosmosDB inclut maintenant une vérification de disponibilité
Azure Managed Redis — utilise maintenant rediss:// (Redis Secure) par défaut, donc les connexions sont chiffrées d’emblée

Ce dernier point est subtil mais important — un Redis chiffré par défaut signifie une chose de moins à configurer en production.

Pour conclure

Aspire 13.2 est une version incrémentale, mais les intégrations MongoDB EF Core et Data Lake comblent de vrais manques. Si vous attendiez un support EF Core correct avec MongoDB dans Aspire, ou si vous aviez besoin que Data Lake soit une dépendance de première classe, passez à la 13.2 et essayez-les. La commande aspire add génère tout ce dont vous avez besoin.

Lisez les notes de version complètes pour plus de détails, et consultez la galerie d’intégrations pour la liste complète.

azd update — Une seule commande pour tous vos gestionnaires de paquets

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

Vous connaissez ce message « Une nouvelle version de azd est disponible » qui apparaît toutes les quelques semaines ? Celui que vous ignorez parce que vous ne vous souvenez plus si vous avez installé azd via winget, Homebrew ou ce script curl que vous avez exécuté il y a six mois ? Eh bien, c’est enfin réglé.

Microsoft vient de publier azd update — une seule commande qui met à jour Azure Developer CLI vers la dernière version, quelle que soit la méthode d’installation d’origine. Windows, macOS, Linux — peu importe. Une seule commande.

Comment ça marche

azd update

C’est tout. Si vous voulez un accès anticipé aux nouvelles fonctionnalités, vous pouvez passer au build insiders quotidien :

azd update --channel daily
azd update --channel stable

La commande détecte votre méthode d’installation actuelle et utilise le mécanisme de mise à jour approprié en arrière-plan. Fini le « attends, j’ai utilisé winget ou choco sur cette machine ? »

Le petit bémol

azd update est disponible à partir de la version 1.23.x. Si vous êtes sur une version antérieure, vous devrez effectuer une dernière mise à jour manuelle en utilisant votre méthode d’installation d’origine. Après ça, azd update gère tout automatiquement.

Vérifiez votre version actuelle avec azd version. Si vous avez besoin d’une nouvelle installation, la documentation d’installation est là pour vous.

Pourquoi c’est important

C’est une petite amélioration de confort, mais pour ceux d’entre nous qui utilisent azd quotidiennement pour déployer des agents IA et des apps Aspire sur Azure, être à jour signifie moins de moments « ce bug était déjà corrigé dans la dernière version ». Une chose de moins à laquelle penser.

Lisez l’annonce complète et l’analyse approfondie de Jon Gallant pour plus de contexte.

Azure Smart Tier est en GA — Optimisation automatique des coûts de Blob Storage sans règles de cycle de vie

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

Si vous avez déjà passé du temps à peaufiner les politiques de cycle de vie d’Azure Blob Storage pour ensuite les voir s’effondrer quand les patterns d’accès ont changé, ceci est pour vous. Microsoft vient d’annoncer la disponibilité générale du smart tier pour Azure Blob et Data Lake Storage — une capacité de tiering entièrement gérée qui déplace automatiquement les objets entre les niveaux hot, cool et cold en fonction de l’utilisation réelle.

Ce que fait réellement le smart tier

Le concept est simple : le smart tier évalue en continu la dernière heure d’accès de chaque objet dans votre compte de stockage. Les données fréquemment consultées restent en hot, les données inactives passent en cool après 30 jours, puis en cold après 60 jours supplémentaires. Quand les données sont à nouveau consultées, elles sont repromues en hot immédiatement. Le cycle recommence.

Pas de règles de cycle de vie à configurer. Pas de prédictions de patterns d’accès. Pas de réglages manuels.

Pendant la preview, Microsoft a rapporté que plus de 50% de la capacité gérée par smart tier s’est automatiquement déplacée vers des niveaux plus froids en fonction des patterns d’accès réels. C’est une réduction de coûts significative pour les comptes de stockage volumineux.

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

Si vous développez des applications qui génèrent des logs, de la télémétrie, des données analytiques, ou tout type de patrimoine de données en croissance — et soyons honnêtes, qui ne le fait pas ? — les coûts de stockage s’accumulent vite. L’approche traditionnelle consistait à écrire des politiques de gestion de cycle de vie, les tester, puis les réajuster quand les patterns d’accès de votre application changeaient. Smart tier supprime entièrement ce workflow.

Quelques scénarios pratiques où cela aide :

Télémétrie et logs d’applications — hot lors du débogage, rarement consultés après quelques semaines
Pipelines de données et sorties ETL — sollicités intensément pendant le traitement, puis majoritairement cold
Contenu généré par les utilisateurs — les uploads récents sont hot, le contenu ancien refroidit progressivement
Données de sauvegarde et d’archivage — consultées occasionnellement pour la conformité, majoritairement inactives

Configuration

Activer le smart tier est une configuration unique :

Nouveaux comptes : Sélectionnez smart tier comme niveau d’accès par défaut lors de la création du compte de stockage (redondance zonale requise)
Comptes existants : Changez le niveau d’accès blob de votre valeur par défaut actuelle vers smart tier

Les objets de moins de 128 KiB restent en hot et n’engendrent pas de frais de surveillance. Pour tout le reste, vous payez les tarifs standard de capacité hot/cool/cold sans frais de transition de niveau, sans pénalités de suppression anticipée et sans coûts de récupération de données. Des frais de surveillance mensuels par objet couvrent l’orchestration.

Le compromis à connaître

Les règles de tiering du smart tier sont statiques (30 jours → cool, 90 jours → cold). Si vous avez besoin de seuils personnalisés — par exemple, passer en cool après 7 jours pour un workload spécifique — les règles de cycle de vie restent la solution. Et ne mélangez pas les deux : évitez d’utiliser des règles de cycle de vie sur des objets gérés par smart tier, car elles peuvent entrer en conflit.

Pour conclure

Ce n’est pas révolutionnaire, mais ça résout un vrai casse-tête opérationnel. Si vous gérez des comptes blob storage en croissance et que vous en avez assez de maintenir des politiques de cycle de vie, activez smart tier et laissez Azure s’en charger. C’est disponible dès aujourd’hui dans la quasi-totalité des régions zonales du cloud public.

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

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

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.

Les Agent Skills en .NET deviennent vraiment flexibles

Emiliano Montesdeoca — Tue, 14 Apr 2026 00:00:00 +0000

Si vous construisez des agents avec le Microsoft Agent Framework, vous connaissez le principe : vous définissez des skills, vous les connectez à un provider et vous laissez l’agent décider lequel invoquer. Ce qui est nouveau, c’est comment vous créez ces skills — et le gain en flexibilité est significatif.

La dernière mise à jour introduit trois patterns d’authoring pour les agent skills : basées sur des fichiers, basées sur des classes et définies en code inline. Les trois se branchent sur un seul AgentSkillsProviderBuilder, ce qui veut dire que vous pouvez les mixer sans logique de routage ni code spécial. Je vous présente chacune et quand l’utiliser.

Skills basées sur des fichiers : le point de départ

Les skills basées sur des fichiers sont exactement ce que leur nom suggère — un répertoire sur disque avec un fichier SKILL.md, des scripts optionnels et des documents de référence. La façon la plus directe de donner de nouvelles capacités à votre agent :

skills/
└── onboarding-guide/
├── SKILL.md
├── scripts/
│ └── check-provisioning.py
└── references/
└── onboarding-checklist.md

Le frontmatter du SKILL.md déclare le nom et la description, et la section d’instructions dit à l’agent comment utiliser les scripts et les références :

---
name: onboarding-guide
description: >-
 Walk new hires through their first-week setup checklist.
---

## Instructions

1. Ask for the employee's name and start date.
2. Run `scripts/check-provisioning.py` to verify accounts.
3. Walk through `references/onboarding-checklist.md`.
4. Follow up on incomplete items.

Ensuite vous le connectez avec SubprocessScriptRunner.RunAsync pour l’exécution des scripts :

var skillsProvider = new AgentSkillsProvider(
 Path.Combine(AppContext.BaseDirectory, "skills"),
 SubprocessScriptRunner.RunAsync);

AIAgent agent = new AzureOpenAIClient(new Uri(endpoint), new DefaultAzureCredential())
 .GetResponsesClient()
 .AsAIAgent(new ChatClientAgentOptions
 {
 Name = "HRAgent",
 ChatOptions = new() { Instructions = "You are a helpful HR assistant." },
 AIContextProviders = [skillsProvider],
 },
 model: deploymentName);

L’agent découvre la skill automatiquement et invoque le script de provisioning quand il doit vérifier le statut des comptes. Propre et simple.

Skills basées sur des classes : distribuer via NuGet

C’est là que ça devient intéressant pour les équipes. Les skills basées sur des classes dérivent de AgentClassSkill<T> et utilisent des attributs comme [AgentSkillResource] et [AgentSkillScript] pour que le framework découvre tout par réflexion :

public sealed class BenefitsEnrollmentSkill : AgentClassSkill<BenefitsEnrollmentSkill>
{
 public override AgentSkillFrontmatter Frontmatter { get; } = new(
 "benefits-enrollment",
 "Enroll an employee in health, dental, or vision plans.");

 protected override string Instructions => """
 1. Read the available-plans resource.
 2. Confirm the plan the employee wants.
 3. Use the enroll script to complete enrollment.
 """;

 [AgentSkillResource("available-plans")]
 [Description("Plan options with monthly pricing.")]
 public string AvailablePlans => """
 ## Available Plans (2026)
 - Health: Basic HMO ($0/month), Premium PPO ($45/month)
 - Dental: Standard ($12/month), Enhanced ($25/month)
 - Vision: Basic ($8/month)
 """;

 [AgentSkillScript("enroll")]
 [Description("Enrolls employee in the specified benefit plan.")]
 private static string Enroll(string employeeId, string planCode)
 {
 bool success = HrClient.EnrollInPlan(employeeId, planCode);
 return JsonSerializer.Serialize(new { success, employeeId, planCode });
 }
}

Le beau ici, c’est qu’une équipe peut packager ça en paquet NuGet. Vous l’ajoutez à votre projet, vous le mettez dans le builder, et ça fonctionne à côté de vos skills fichier sans coordination :

var skillsProvider = new AgentSkillsProviderBuilder()
 .UseFileSkill(Path.Combine(AppContext.BaseDirectory, "skills"))
 .UseSkill(new BenefitsEnrollmentSkill())
 .UseFileScriptRunner(SubprocessScriptRunner.RunAsync)
 .Build();

Les deux skills apparaissent dans le system prompt de l’agent. L’agent décide laquelle utiliser en fonction de la conversation — pas de code de routage nécessaire.

Skills inline : le pont rapide

Vous connaissez ce moment où une autre équipe construit exactement la skill dont vous avez besoin, mais elle ne sera pas prête avant le prochain sprint ? AgentInlineSkill est votre pont :

var timeOffSkill = new AgentInlineSkill(
 name: "time-off-balance",
 description: "Calculate remaining vacation and sick days.",
 instructions: """
 1. Ask for the employee ID if not provided.
 2. Use calculate-balance to get the remaining balance.
 3. Present used and remaining days clearly.
 """)
 .AddScript("calculate-balance", (string employeeId, string leaveType) =>
 {
 int totalDays = HrDatabase.GetAnnualAllowance(employeeId, leaveType);
 int daysUsed = HrDatabase.GetDaysUsed(employeeId, leaveType);
 int remaining = totalDays - daysUsed;
 return JsonSerializer.Serialize(new { employeeId, leaveType, totalDays, daysUsed, remaining });
 });

Ajoutez-la au builder comme les autres :

var skillsProvider = new AgentSkillsProviderBuilder()
 .UseFileSkill(Path.Combine(AppContext.BaseDirectory, "skills"))
 .UseSkill(new BenefitsEnrollmentSkill())
 .UseSkill(timeOffSkill)
 .UseFileScriptRunner(SubprocessScriptRunner.RunAsync)
 .Build();

Quand le paquet NuGet sort enfin, vous échangez la skill inline contre la version classe. L’agent ne voit pas la différence.

Les skills inline ne sont pas que pour les ponts. Elles sont aussi le bon choix quand vous devez générer des skills dynamiquement à l’exécution — pensez à une skill par unité métier chargée depuis la config — ou quand un script doit capturer un état local qui n’a pas sa place dans un conteneur DI.

Approbation de scripts : l’humain dans la boucle

Pour nous développeurs .NET qui construisons des agents de production, c’est la partie qui débloque vraiment les discussions de déploiement. Certains scripts ont des conséquences réelles — inscrire quelqu’un à des avantages, interroger l’infrastructure de production. Activez UseScriptApproval et l’agent se met en pause avant d’exécuter tout script :

var skillsProvider = new AgentSkillsProviderBuilder()
 .UseFileSkill(Path.Combine(AppContext.BaseDirectory, "skills"))
 .UseSkill(new BenefitsEnrollmentSkill())
 .UseSkill(timeOffSkill)
 .UseFileScriptRunner(SubprocessScriptRunner.RunAsync)
 .UseScriptApproval(true)
 .Build();

Quand l’agent veut exécuter un script, il retourne une demande d’approbation à la place. Votre app collecte la décision — approuver ou rejeter — et l’agent continue en conséquence. Dans les environnements réglementés, c’est la différence entre “on peut déployer ça” et “le juridique dit non.”

Pourquoi cette combinaison compte

Le vrai pouvoir n’est pas dans un pattern individuel — c’est dans la composition. Vous pouvez :

Commencer petit avec une skill fichier, itérer sur les instructions et la publier sans écrire de C#
Distribuer des skills réutilisables comme paquets NuGet que d’autres équipes ajoutent en une ligne
Combler les lacunes avec des skills inline quand vous avez besoin de quelque chose maintenant
Filtrer les répertoires partagés avec des prédicats pour que votre agent ne charge que ce qu’il doit
Ajouter une supervision humaine pour les scripts qui touchent les systèmes de production

Tout cela se compose via AgentSkillsProviderBuilder. Pas de routage spécial, pas de logique conditionnelle, pas de vérifications de type de skill.

Pour conclure

Les agent skills en .NET ont maintenant un modèle d’authoring véritablement flexible. Que vous soyez un développeur solo qui prototype avec des skills fichier ou une équipe enterprise qui distribue des capacités packagées via NuGet, les patterns s’adaptent. Et le mécanisme d’approbation de scripts le rend prêt pour la production dans les environnements où vous avez besoin de ce checkpoint humain.

Consultez l’annonce originale, la documentation Agent Skills sur Microsoft Learn et les exemples .NET sur GitHub pour vous lancer.

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.

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

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

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.

Construire des UIs Multi-Agents en Temps Réel Qui Ne Ressemblent Pas à une Boîte Noire

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

Voilà le truc avec les systèmes multi-agents : ils sont incroyables en démo. Trois agents qui se passent le travail, résolvent des problèmes, prennent des décisions. Puis tu essaies de le mettre devant de vrais utilisateurs et… silence. Un indicateur qui tourne. Aucune idée de quel agent fait quoi ni pourquoi le système est en pause. Ce n’est pas un produit — c’est un problème de confiance.

L’équipe Microsoft Agent Framework vient de publier un excellent tutoriel sur le couplage des workflows MAF avec AG-UI, un protocole ouvert pour streamer les événements d’exécution des agents vers un frontend via les Server-Sent Events. Et franchement ? C’est exactement le pont qui nous manquait.

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

Si tu construis des applications alimentées par l’IA, tu as probablement déjà heurté ce mur. Ton orchestration backend fonctionne parfaitement — les agents se passent le relais, les outils se déclenchent, les décisions sont prises. Mais le frontend n’a aucune idée de ce qui se passe en coulisses. AG-UI résout ça en définissant un protocole standard pour streamer les événements d’agents (pense à RUN_STARTED, STEP_STARTED, TOOL_CALL_*, TEXT_MESSAGE_*) directement vers ta couche UI via SSE.

La démo est un workflow de support client avec trois agents : un agent de triage qui route les demandes, un agent de remboursement qui gère les questions d’argent, et un agent de commandes qui gère les remplacements. Chaque agent a ses propres outils, et la topologie de handoff est définie explicitement — pas de « devine à partir du prompt ».

La topologie de handoff est la vraie star

Ce qui m’a marqué, c’est comment HandoffBuilder te permet de déclarer un graphe de routage dirigé entre les agents :

builder = HandoffBuilder(
 name="ag_ui_handoff_workflow_demo",
 participants=[triage, refund, order],
 termination_condition=termination_condition,
)

(
 builder
 .add_handoff(triage, [refund], description="Refunds, damaged-item claims...")
 .add_handoff(triage, [order], description="Replacement, exchange...")
 .add_handoff(refund, [order], description="Replacement logistics needed after refund.")
 .add_handoff(order, [triage], description="After replacement/shipping tasks complete.")
)

Chaque add_handoff crée une arête dirigée avec une description en langage naturel. Le framework génère des outils de handoff pour chaque agent en se basant sur cette topologie. Les décisions de routage reposent donc sur ta structure d’orchestration, pas juste sur ce que le LLM a envie de faire. C’est un gain énorme pour la fiabilité en production.

Le human-in-the-loop qui fonctionne vraiment

La démo présente deux patterns d’interruption dont toute app d’agents réelle a besoin :

Interruptions d’approbation d’outils — quand un agent appelle un outil marqué avec approval_mode="always_require", le workflow se met en pause et émet un événement. Le frontend affiche un modal d’approbation avec le nom de l’outil et ses arguments. Pas de boucles de retry qui brûlent des tokens — juste un flux propre pause-approbation-reprise.

Interruptions de demande d’information — quand un agent a besoin de plus de contexte de la part de l’utilisateur (comme un ID de commande), il se met en pause et pose la question. Le frontend affiche la question, l’utilisateur répond, et l’exécution reprend exactement là où elle s’était arrêtée.

Les deux patterns sont streamés en tant qu’événements AG-UI standard, donc ton frontend n’a pas besoin de logique personnalisée par agent — il affiche simplement chaque événement qui arrive via la connexion SSE.

L’intégration est étonnamment simple

L’intégration entre MAF et AG-UI se résume à un seul appel de fonction :

from agent_framework.ag_ui import (
 AgentFrameworkWorkflow,
 add_agent_framework_fastapi_endpoint,
)

app = FastAPI()

demo_workflow = AgentFrameworkWorkflow(
 workflow_factory=lambda _thread_id: create_handoff_workflow(),
 name="ag_ui_handoff_workflow_demo",
)

add_agent_framework_fastapi_endpoint(
 app=app, agent=demo_workflow, path="/handoff_demo",
)

La workflow_factory crée un workflow frais par thread, pour que chaque conversation ait son propre état isolé. L’endpoint gère toute la plomberie SSE automatiquement. Si tu utilises déjà FastAPI (ou que tu peux l’ajouter comme couche légère), c’est quasiment zéro friction.

Mon avis

Pour nous développeurs .NET, la question immédiate est : « Est-ce que je peux faire ça en C# ? » L’Agent Framework est disponible pour .NET et Python, et le protocole AG-UI est agnostique au langage (c’est juste du SSE). Donc même si cette démo spécifique utilise Python et FastAPI, le pattern se transpose directement. Tu pourrais câbler une API minimale ASP.NET Core avec des endpoints SSE suivant le même schéma d’événements AG-UI.

Le point plus important est que les UIs multi-agents deviennent une préoccupation de premier plan, pas un ajout après coup. Si tu construis quoi que ce soit où des agents interagissent avec des humains — support client, workflows d’approbation, traitement de documents — cette combinaison d’orchestration MAF et de transparence AG-UI est le pattern à suivre.

Pour conclure

AG-UI + Microsoft Agent Framework te donne le meilleur des deux mondes : une orchestration multi-agents robuste côté backend et une visibilité en temps réel côté frontend. Fini les interactions d’agents en boîte noire.

Consulte le tutoriel complet et le dépôt du protocole AG-UI pour aller plus loin.

L'évaluation de modernisation de GitHub Copilot est le meilleur outil de migration que vous n'utilisez pas encore

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

Migrer une application legacy .NET Framework vers .NET moderne est l’une de ces tâches que tout le monde sait devoir faire mais que personne ne veut commencer. Ce n’est jamais juste « changer le framework cible ». Ce sont des API qui ont disparu, des packages qui n’existent plus, des modèles d’hébergement qui fonctionnent totalement différemment, et un million de petites décisions sur ce qu’il faut containeriser, réécrire ou laisser tel quel.

Jeffrey Fritz vient de publier une plongée approfondie dans l’évaluation de modernisation de GitHub Copilot, et honnêtement ? C’est le meilleur outillage de migration que j’ai vu pour .NET. Pas à cause de la génération de code — c’est devenu standard maintenant. À cause du document d’évaluation qu’il produit.

Ce n’est pas qu’un moteur de suggestions de code

L’extension VS Code suit un modèle Évaluer → Planifier → Exécuter. La phase d’évaluation analyse l’intégralité de votre codebase et produit un document structuré qui capture tout : ce qui doit changer, quelles ressources Azure provisionner, quel modèle de déploiement utiliser. Tout en aval — infrastructure as code, containerisation, manifestes de déploiement — découle de ce que l’évaluation trouve.

L’évaluation est stockée sous .github/modernize/assessment/ dans votre projet. Chaque exécution produit un rapport indépendant, vous construisez ainsi un historique et pouvez suivre l’évolution de votre posture de migration au fur et à mesure que vous corrigez les issues.

Deux façons de commencer

Évaluation Recommandée — la voie rapide. Choisissez parmi des domaines curatés (Mise à jour Java/.NET, Cloud Readiness, Sécurité) et obtenez des résultats significatifs sans toucher à la configuration. Idéal pour un premier regard sur l’état de votre application.

Évaluation Personnalisée — la voie ciblée. Configurez exactement ce qu’il faut analyser : compute cible (App Service, AKS, Container Apps), OS cible, analyse de containerisation. Choisissez plusieurs cibles Azure pour comparer les approches de migration côte à côte.

Cette vue de comparaison est véritablement utile. Une app avec 3 issues obligatoires pour App Service pourrait en avoir 7 pour AKS. Voir les deux aide à prendre la décision d’hébergement avant de s’engager sur un chemin de migration.

Le détail des issues est actionnable

Chaque issue est accompagné d’un niveau de criticité :

Obligatoire — doit être corrigé sinon la migration échoue
Potentiel — pourrait impacter la migration, nécessite un jugement humain
Optionnel — améliorations recommandées, ne bloque pas la migration

Et chaque issue renvoie aux fichiers affectés et numéros de lignes, fournit une description détaillée de ce qui ne va pas et pourquoi c’est important pour votre plateforme cible, donne des étapes concrètes de remédiation (pas juste « corrigez ceci ») et inclut des liens vers la documentation officielle.

Vous pouvez confier des issues individuelles à des développeurs et ils ont tout ce dont ils ont besoin pour agir. C’est la différence entre un outil qui vous dit « il y a un problème » et un qui vous dit comment le résoudre.

Les chemins de mise à jour couverts

Pour .NET spécifiquement :

.NET Framework → .NET 10
ASP.NET → ASP.NET Core

Chaque chemin de mise à jour a des règles de détection qui savent quelles API ont été supprimées, quels patterns n’ont pas d’équivalent direct et quels problèmes de sécurité nécessitent une attention particulière.

Pour les équipes gérant plusieurs applications, il y a aussi un CLI qui supporte les évaluations batch multi-repo — clonez tous les repos, évaluez-les tous, obtenez des rapports par application plus une vue agrégée du portfolio.

Mon avis

Si vous êtes assis sur des applications legacy .NET Framework (et soyons honnêtes, la plupart des équipes enterprise le sont), c’est l’outil par lequel commencer. Le document d’évaluation seul vaut le temps — il transforme un vague « on devrait moderniser » en une liste concrète et priorisée d’éléments de travail avec des chemins clairs vers l’avant.

Le workflow collaboratif est malin aussi : exportez les évaluations, partagez-les avec votre équipe, importez-les sans relancer. Revues d’architecture où les décideurs ne sont pas ceux qui exécutent les outils ? Couvert.

Pour conclure

L’évaluation de modernisation de GitHub Copilot transforme la migration .NET d’un projet effrayant et indéfini en un processus structuré et traçable. Commencez avec une évaluation recommandée pour voir où vous en êtes, puis utilisez des évaluations personnalisées pour comparer les cibles Azure et construire votre plan de migration.

Lisez le walkthrough complet et récupérez l’extension VS Code pour l’essayer sur votre propre codebase.

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

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

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

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.

SQL MCP Server — La bonne façon de donner accès aux bases de données aux agents IA

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

Soyons honnêtes : la plupart des serveurs MCP de bases de données disponibles aujourd’hui sont effrayants. Ils prennent une requête en langage naturel, génèrent du SQL à la volée et l’exécutent contre vos données de production. Qu’est-ce qui pourrait mal tourner ? (Tout. Absolument tout.)

L’équipe Azure SQL vient de présenter SQL MCP Server, et il adopte une approche fondamentalement différente. Construit comme une fonctionnalité de Data API builder (DAB) 2.0, il donne aux agents IA un accès structuré et déterministe aux opérations de base de données — sans NL2SQL, sans exposer votre schéma, et avec un RBAC complet à chaque étape.

Pourquoi pas de NL2SQL ?

C’est la décision de conception la plus intéressante. Les modèles ne sont pas déterministes, et les requêtes complexes sont les plus susceptibles de produire des erreurs subtiles. Les requêtes exactes que les utilisateurs espèrent que l’IA peut générer sont aussi celles qui nécessitent le plus de vérification quand elles sont produites de manière non déterministe.

À la place, SQL MCP Server utilise une approche NL2DAB. L’agent travaille avec la couche d’abstraction d’entités de Data API builder et son constructeur de requêtes intégré pour produire du T-SQL précis et bien formé de manière déterministe. Même résultat pour l’utilisateur, mais sans le risque de JOINs hallucinés ou d’exposition accidentelle de données.

Sept outils, pas sept cents

SQL MCP Server expose exactement sept outils DML, quelle que soit la taille de la base de données :

describe_entities — découvrir les entités et opérations disponibles
create_record — insérer des lignes
read_records — interroger des tables et vues
update_record — modifier des lignes
delete_record — supprimer des lignes
execute_entity — exécuter des procédures stockées
aggregate_records — requêtes d’agrégation

C’est malin, car les fenêtres de contexte sont l’espace de réflexion de l’agent. Les inonder de centaines de définitions d’outils laisse moins de place au raisonnement. Sept outils fixes gardent l’agent concentré sur la réflexion plutôt que la navigation.

Chaque outil peut être activé ou désactivé individuellement :

"runtime": {
 "mcp": {
 "enabled": true,
 "path": "/mcp",
 "dml-tools": {
 "describe-entities": true,
 "create-record": true,
 "read-records": true,
 "update-record": true,
 "delete-record": true,
 "execute-entity": true,
 "aggregate-records": true
 }
 }
}

Démarrage en trois commandes

dab init \
 --database-type mssql \
 --connection-string "@env('sql_connection_string')"

dab add Customers \
 --source dbo.Customers \
 --permissions "anonymous:*"

dab start

Voilà un SQL MCP Server en fonctionnement qui expose votre table Customers. La couche d’abstraction d’entités vous permet de créer des alias pour les noms et colonnes, de limiter les champs par rôle et de contrôler exactement ce que les agents voient — sans exposer les détails internes du schéma.

L’aspect sécurité est solide

C’est là que la maturité de Data API builder porte ses fruits :

RBAC à chaque couche — chaque entité définit quels rôles peuvent lire, créer, mettre à jour ou supprimer, et quels champs sont visibles
Intégration Azure Key Vault — chaînes de connexion et secrets gérés de manière sécurisée
Microsoft Entra + OAuth personnalisé — authentification de niveau production
Content Security Policy — les agents interagissent via un contrat contrôlé, pas du SQL brut

L’abstraction du schéma est particulièrement importante. Vos noms internes de tables et colonnes ne sont jamais exposés à l’agent. Vous définissez des entités, des alias et des descriptions qui ont du sens pour l’interaction IA — pas votre diagramme ERD de base de données.

Multi-bases et multi-protocoles

SQL MCP Server supporte Microsoft SQL, PostgreSQL, Azure Cosmos DB et MySQL. Et comme c’est une fonctionnalité de DAB, vous obtenez des endpoints REST, GraphQL et MCP simultanément depuis la même configuration. Mêmes définitions d’entités, mêmes règles RBAC, même sécurité — sur les trois protocoles.

L’auto-configuration dans DAB 2.0 peut même inspecter votre base de données et construire la configuration dynamiquement, si vous êtes à l’aise avec moins d’abstraction pour du prototypage rapide.

Mon avis

C’est ainsi que l’accès base de données d’entreprise pour les agents IA devrait fonctionner. Pas « hey LLM, écris-moi du SQL et YOLO sur la prod ». À la place : une couche d’entités bien définie, une génération de requêtes déterministe, RBAC à chaque étape, cache, monitoring et télémétrie. C’est ennuyeux de la meilleure façon possible.

Pour les développeurs .NET, l’histoire d’intégration est propre — DAB est un outil .NET, le MCP Server tourne en conteneur, et il fonctionne avec Azure SQL, que la plupart d’entre nous utilisent déjà. Si vous construisez des agents IA qui ont besoin d’accéder aux données, commencez ici.

Pour conclure

SQL MCP Server est gratuit, open-source et tourne partout. C’est l’approche prescriptive de Microsoft pour donner aux agents IA un accès sécurisé aux bases de données. Consultez le post complet et la documentation pour commencer.

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

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.

KubeCon Europe 2026 : Ce que les développeurs .NET devraient vraiment retenir

Emiliano Montesdeoca — Sun, 29 Mar 2026 00:00:00 +0000

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

Vous connaissez cette sensation quand un énorme post d’annonces tombe et que vous scrollez en pensant « cool, mais concrètement ça change quoi pour moi » ? C’est moi à chaque saison KubeCon.

Microsoft vient de publier son récapitulatif complet de KubeCon Europe 2026 — écrit par Brendan Burns en personne — et honnêtement ? Il y a du vrai contenu ici. Pas juste des cases à cocher, mais des améliorations opérationnelles qui changent votre façon de gérer les choses en production.

Laissez-moi décortiquer ce qui compte vraiment pour nous développeurs .NET.

mTLS sans la taxe du service mesh

Voici le truc avec les service meshes : tout le monde veut les garanties de sécurité, personne ne veut la charge opérationnelle. AKS comble enfin cet écart.

Azure Kubernetes Application Network vous donne le TLS mutuel, l’autorisation consciente de l’application et la télémétrie du trafic — sans déployer un mesh complet avec sidecars. Combiné avec Cilium mTLS dans Advanced Container Networking Services, vous obtenez une communication chiffrée pod-à-pod utilisant des certificats X.509 et SPIRE pour la gestion des identités.

Ce que ça signifie en pratique : vos APIs ASP.NET Core qui communiquent avec des workers en arrière-plan, vos services gRPC qui s’appellent mutuellement — tout chiffré et vérifié au niveau réseau, sans aucune modification de code. C’est énorme.

Pour les équipes qui migrent depuis ingress-nginx, il y a aussi Application Routing avec Meshless Istio avec support complet de Kubernetes Gateway API. Pas de sidecars. Basé sur les standards. Et ils ont livré des outils ingress2gateway pour une migration incrémentale.

Observabilité GPU qui n’est pas une pensée après coup

Si vous exécutez de l’inférence IA aux côtés de vos services .NET (et soyons honnêtes, qui ne commence pas ?), vous avez probablement rencontré l’angle mort du monitoring GPU. Vous aviez de super dashboards CPU/mémoire et ensuite… rien pour les GPU sans configuration manuelle d’exporteurs.

AKS expose maintenant les métriques GPU nativement dans Prometheus et Grafana managés. Même stack, mêmes dashboards, même pipeline d’alertes. Pas d’exporteurs custom, pas d’agents tiers.

Côté réseau, ils ont ajouté de la visibilité par flux pour le trafic HTTP, gRPC et Kafka avec une expérience Azure Monitor en un clic. IPs, ports, workloads, direction des flux, décisions de policies — tout dans des dashboards intégrés.

Et voici celle qui m’a fait regarder deux fois : agentic container networking ajoute une interface web où vous pouvez poser des questions en langage naturel sur l’état réseau de votre cluster. « Pourquoi le pod X n’atteint-il pas le service Y ? » → diagnostics en lecture seule depuis la télémétrie en direct. C’est vraiment utile à 2h du matin.

Networking cross-cluster sans avoir besoin d’un doctorat

Le multi-cluster Kubernetes a toujours été une expérience « apportez votre propre colle réseau ». Azure Kubernetes Fleet Manager propose maintenant du networking cross-cluster via un cluster mesh Cilium managé :

Connectivité unifiée entre clusters AKS
Registre global de services pour la découverte cross-cluster
Configuration gérée centralement, pas répétée par cluster

Si vous exécutez des microservices .NET sur plusieurs régions pour la résilience ou la conformité, ça remplace beaucoup de colle custom fragile. Le Service A en West Europe peut découvrir et appeler le Service B en East US à travers le mesh, avec des politiques de routage et de sécurité cohérentes.

Des mises à jour qui ne demandent pas du courage

Soyons honnêtes — les mises à jour Kubernetes en production sont stressantes. « Mettre à jour et espérer » a été la stratégie de fait pour trop d’équipes, et c’est la raison principale pour laquelle les clusters restent en retard sur les versions.

Deux nouvelles capacités changent la donne :

Les blue-green agent pool upgrades créent un pool de nœuds parallèle avec la nouvelle configuration. Validez le comportement, déplacez le trafic progressivement et gardez un chemin de rollback propre. Plus de mutations in-place sur les nœuds de production.

Le rollback d’agent pool permet de revenir à la version Kubernetes et l’image de nœud précédentes d’un pool après qu’une mise à jour se passe mal — sans reconstruire le cluster.

Ensemble, ils donnent enfin aux opérateurs un vrai contrôle sur le cycle de vie des mises à jour. Pour les équipes .NET, c’est important car la vélocité de la plateforme contrôle directement la vitesse à laquelle vous pouvez adopter de nouveaux runtimes, patchs de sécurité et capacités réseau.

Les workloads IA deviennent des citoyens de première classe Kubernetes

Le travail upstream en open-source est tout aussi important. Dynamic Resource Allocation (DRA) vient de passer en GA dans Kubernetes 1.36, faisant du scheduling GPU une vraie fonctionnalité de première classe plutôt qu’un contournement.

Quelques projets à surveiller :

Projet	Ce qu’il fait
AI Runway	API Kubernetes commune pour l’inférence — déployez des modèles sans connaître K8s, avec découverte HuggingFace et estimations de coûts
HolmesGPT	Dépannage agentique pour le cloud-native — maintenant un projet CNCF Sandbox
Dalec	Builds déclaratifs d’images de conteneur avec génération de SBOM — moins de CVE à l’étape de build

La direction est claire : votre API .NET, votre couche d’orchestration Semantic Kernel et vos workloads d’inférence devraient tous tourner sur un modèle de plateforme cohérent. On y arrive.

Par où commencer cette semaine

Si vous évaluez ces changements pour votre équipe, voici ma liste de priorités honnête :

L’observabilité d’abord — activez les métriques GPU et les logs de flux réseau dans un cluster non-prod. Voyez ce que vous avez manqué.
Testez les blue-green upgrades — essayez le workflow de rollback avant votre prochaine mise à jour de cluster en production. Construisez la confiance dans le processus.
Pilotez le networking identity-aware — choisissez un chemin de service interne et activez mTLS avec Cilium. Mesurez l’overhead (spoiler : c’est minimal).
Évaluez Fleet Manager — si vous gérez plus de deux clusters, le networking cross-cluster se rentabilise tout seul en réduisant la colle custom.

Petites expériences, feedback rapide. C’est toujours le bon choix.

Pour conclure

Les annonces KubeCon peuvent être accablantes, mais cette fournée fait vraiment bouger les choses pour les équipes .NET sur AKS. Meilleure sécurité réseau sans overhead de mesh, vraie observabilité GPU, mises à jour plus sûres et des fondations d’infrastructure IA plus solides.

Si vous êtes déjà sur AKS, c’est un excellent moment pour renforcer votre baseline opérationnel. Et si vous prévoyez de migrer des workloads .NET vers Kubernetes — la plateforme vient de devenir nettement plus prête pour la production.

SQL MCP Server, Copilot dans SSMS et un Database Hub avec des agents IA : Ce qui compte vraiment de SQLCon 2026

Emiliano Montesdeoca — Sat, 28 Mar 2026 00:00:00 +0000

Microsoft vient de lancer SQLCon 2026 en parallèle de FabCon à Atlanta, et il y a beaucoup à décortiquer. L’annonce originale couvre tout, des plans d’économies aux fonctionnalités de conformité enterprise. Je vais passer les slides sur les tarifs enterprise et me concentrer sur les éléments qui comptent si vous êtes un développeur qui construit des choses avec Azure SQL et l’IA.

SQL MCP Server est en public preview

C’est le titre principal pour moi. Azure SQL Database Hyperscale dispose maintenant d’un SQL MCP Server en public preview qui vous permet de connecter vos données SQL de manière sécurisée à des agents IA et des Copilots en utilisant le Model Context Protocol.

Si vous avez suivi la vague MCP — et honnêtement, c’est difficile de la rater en ce moment — c’est une grosse nouvelle. Au lieu de construire des pipelines de données personnalisés pour alimenter vos agents IA en contexte depuis votre base de données, vous obtenez un protocole standardisé pour exposer les données SQL directement. Vos agents peuvent interroger, raisonner et agir sur des informations de base de données en temps réel.

Pour ceux d’entre nous qui construisent des agents IA avec Semantic Kernel ou le Microsoft Agent Framework, ça ouvre un chemin d’intégration propre. Votre agent a besoin de vérifier l’inventaire ? Chercher un enregistrement client ? Valider une commande ? MCP lui donne une façon structurée de le faire sans que vous écriviez du code de récupération de données sur mesure pour chaque scénario.

GitHub Copilot dans SSMS 22 est maintenant GA

Si vous passez du temps dans SQL Server Management Studio — et soyons honnêtes, la plupart d’entre nous le font encore — GitHub Copilot est maintenant disponible de manière générale dans SSMS 22. La même expérience Copilot que vous utilisez déjà dans VS Code et Visual Studio, mais pour T-SQL.

La valeur pratique est simple : une assistance par chat pour écrire des requêtes, refactoriser des procédures stockées, résoudre des problèmes de performance et gérer des tâches d’administration. Rien de révolutionnaire dans le concept, mais l’avoir directement dans SSMS signifie que vous n’avez pas besoin de changer de contexte vers un autre éditeur juste pour obtenir de l’aide IA sur votre travail de base de données.

Les index vectoriels ont reçu une sérieuse mise à jour

Azure SQL Database dispose maintenant d’index vectoriels plus rapides et plus performants avec un support complet pour l’insertion, la mise à jour et la suppression. Ça veut dire que vos données vectorielles restent à jour en temps réel — pas besoin de réindexation par lots.

Voici les nouveautés :

Quantification pour des tailles d’index plus petites sans trop perdre en précision
Filtrage itératif pour des résultats plus précis
Intégration plus étroite avec l’optimiseur de requêtes pour des performances prévisibles

Si vous faites du Retrieval-Augmented Generation (RAG) avec Azure SQL comme vector store, ces améliorations sont directement utiles. Vous pouvez garder vos vecteurs à côté de vos données relationnelles dans la même base de données, ce qui simplifie considérablement votre architecture par rapport à l’exécution d’une base de données vectorielle séparée.

Les mêmes améliorations vectorielles sont également disponibles dans SQL Database in Fabric, puisque les deux tournent sur le même moteur SQL en dessous.

Database Hub dans Fabric : gestion agentique

Celui-ci est plus tourné vers l’avenir, mais il est intéressant. Microsoft a annoncé le Database Hub dans Microsoft Fabric (accès anticipé), qui vous donne une vue unifiée sur Azure SQL, Cosmos DB, PostgreSQL, MySQL et SQL Server via Arc.

L’angle intéressant n’est pas juste la vue unifiée — c’est l’approche agentique de la gestion. Des agents IA surveillent en continu votre parc de bases de données, font remonter ce qui a changé, expliquent pourquoi c’est important et suggèrent quoi faire ensuite. C’est un modèle human-in-the-loop où l’agent fait le gros du travail et vous prenez les décisions.

Pour les équipes qui gèrent plus qu’une poignée de bases de données, ça pourrait vraiment réduire le bruit opérationnel. Au lieu de sauter entre les portails et de vérifier manuellement les métriques, l’agent vous apporte le signal.

Ce que ça signifie pour les développeurs .NET

Le fil conducteur de toutes ces annonces est clair : Microsoft intègre des agents IA à chaque couche de la pile de bases de données. Pas comme un gadget, mais comme une couche d’outillage pratique.

Si vous construisez des apps .NET adossées à Azure SQL, voici ce que je ferais concrètement :

Essayez le SQL MCP Server si vous construisez des agents IA. C’est la façon la plus propre de donner à vos agents un accès à la base de données sans plomberie personnalisée.
Activez Copilot dans SSMS si ce n’est pas déjà fait — un gain de productivité gratuit pour le travail SQL quotidien.
Regardez les index vectoriels si vous faites du RAG et que vous utilisez actuellement un vector store séparé. Consolider sur Azure SQL signifie un service de moins à gérer.

Pour conclure

L’annonce complète contient plus — plans d’économies, assistants de migration, fonctionnalités de conformité — mais l’histoire pour les développeurs se trouve dans le MCP Server, les améliorations vectorielles et la couche de gestion agentique. Ce sont les éléments qui changent la façon dont vous construisez, pas juste la façon dont vous budgétisez.

Consultez l’annonce complète de Shireesh Thota pour avoir le tableau complet, et inscrivez-vous pour l’accès anticipé au Database Hub si vous voulez essayer la nouvelle expérience de gestion.

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)

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.

Les réponses en arrière-plan dans Microsoft Agent Framework : fini l'angoisse des timeouts

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

Si vous avez construit quoi que ce soit avec des modèles de raisonnement comme o3 ou GPT-5.2, vous connaissez la douleur. Votre agent commence à réfléchir à une tâche complexe, le client attend, et quelque part entre “ça va” et “est-ce que ça a planté ?” votre connexion expire. Tout ce travail ? Perdu.

Microsoft Agent Framework vient de livrer les réponses en arrière-plan — et honnêtement, c’est une de ces fonctionnalités qui auraient dû exister depuis le premier jour.

Le problème avec les appels bloquants

Dans un schéma requête-réponse traditionnel, votre client bloque jusqu’à ce que l’agent termine. Ça marche bien pour les tâches rapides. Mais quand vous demandez à un modèle de raisonnement de faire une recherche approfondie, une analyse en plusieurs étapes, ou de générer un rapport de 20 pages ? Vous regardez des minutes de temps réel. Pendant cette fenêtre :

Les connexions HTTP peuvent expirer
Les coupures réseau tuent toute l’opération
Votre utilisateur fixe un spinner en se demandant s’il se passe quelque chose

Les réponses en arrière-plan inversent la donne.

Comment fonctionnent les tokens de continuation

Au lieu de bloquer, vous lancez la tâche de l’agent et récupérez un token de continuation. Pensez-y comme un ticket de retrait dans un atelier de réparation — vous ne restez pas debout au comptoir à attendre, vous revenez quand c’est prêt.

Le flux est direct :

Envoyez votre requête avec AllowBackgroundResponses = true
Si l’agent supporte le traitement en arrière-plan, vous recevez un token de continuation
Interrogez à votre rythme jusqu’à ce que le token retourne null — ça signifie que le résultat est prêt

Voici la version .NET :

AIAgent agent = new AzureOpenAIClient(
 new Uri("https://<myresource>.openai.azure.com"),
 new DefaultAzureCredential())
 .GetResponsesClient("<deployment-name>")
 .AsAIAgent();

AgentRunOptions options = new()
{
 AllowBackgroundResponses = true
};

AgentSession session = await agent.CreateSessionAsync();

AgentResponse response = await agent.RunAsync(
 "Write a detailed market analysis for the Q4 product launch.", session, options);

// Interroger jusqu'à complétion
while (response.ContinuationToken is not null)
{
 await Task.Delay(TimeSpan.FromSeconds(2));
 options.ContinuationToken = response.ContinuationToken;
 response = await agent.RunAsync(session, options);
}

Console.WriteLine(response.Text);

Si l’agent finit immédiatement (tâches simples, modèles qui n’ont pas besoin de traitement en arrière-plan), aucun token de continuation n’est renvoyé. Votre code fonctionne simplement — aucun traitement spécial nécessaire.

Streaming avec reprise : la vraie magie

Le polling convient pour les scénarios fire-and-forget, mais que faire quand vous voulez un progrès en temps réel ? Les réponses en arrière-plan supportent aussi le streaming avec reprise intégrée.

Chaque mise à jour streamée porte son propre token de continuation. Si votre connexion tombe en plein stream, vous reprenez exactement là où vous en étiez :

AgentRunOptions options = new()
{
 AllowBackgroundResponses = true
};

AgentSession session = await agent.CreateSessionAsync();
AgentResponseUpdate? latestUpdate = null;

await foreach (var update in agent.RunStreamingAsync(
 "Write a detailed market analysis for the Q4 product launch.", session, options))
{
 Console.Write(update.Text);
 latestUpdate = update;
 break; // Simuler une interruption réseau
}

// Reprendre exactement là où nous en étions
options.ContinuationToken = latestUpdate?.ContinuationToken;
await foreach (var update in agent.RunStreamingAsync(session, options))
{
 Console.Write(update.Text);
}

L’agent continue le traitement côté serveur indépendamment de ce qui se passe avec votre client. C’est de la tolérance aux pannes intégrée sans que vous écriviez de la logique de retry ou des circuit breakers.

Quand utiliser ça concrètement

Tous les appels d’agent n’ont pas besoin de réponses en arrière-plan. Pour les completions rapides, vous ajoutez de la complexité pour rien. Mais voici où elles brillent :

Tâches de raisonnement complexe — analyse en plusieurs étapes, recherche approfondie, tout ce qui fait vraiment réfléchir un modèle de raisonnement
Génération de contenu long — rapports détaillés, documents en plusieurs parties, analyses approfondies
Réseaux peu fiables — clients mobiles, déploiements edge, VPN d’entreprise instables
Patterns UX asynchrones — soumettez une tâche, allez faire autre chose, revenez pour les résultats

Pour nous développeurs .NET qui construisons des apps enterprise, ce dernier point est particulièrement intéressant. Pensez à une app Blazor où un utilisateur demande un rapport complexe — vous lancez la tâche de l’agent, affichez un indicateur de progression, et le laissez continuer à travailler. Pas d’acrobaties WebSocket, pas d’infrastructure de file d’attente personnalisée, juste un token et une boucle de polling.

Pour conclure

Les réponses en arrière-plan sont disponibles maintenant en .NET et Python via Microsoft Agent Framework. Si vous construisez des agents qui font plus que du simple Q&A, ça vaut le coup de l’ajouter à votre boîte à outils. Le pattern du token de continuation garde les choses simples tout en résolvant un vrai problème de production.

Consultez la documentation complète pour la référence API complète et plus d’exemples.

Azure | 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

Cosmos DB Shell Est en Préversion Publique — Et Il a un Serveur MCP Intégré

Ce Qui le Différencie des Autres CLIs de Base de Données

La Base Open Source Compte

Trois Scénarios Qui Deviennent Plus Faciles

Pour Commencer

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

Endpoints Privés, VNets, NSGs — Aspire Gère le Réseau Maintenant

Les Blocs de Construction

Le Décrire dans votre AppHost

Pourquoi C’est Important pour les Applications Réelles

Conclusion

Aspire 13.3 : Support Kubernetes, Journaux du Navigateur et la Compétence Aspireify

Aspireify : Intégration Assistée par Agent

Déploiement Kubernetes et AKS de Première Classe

Journaux du Navigateur dans le Dashboard

Résultats de Commandes Structurés

En Résumé

SDD Conference 2026

Sujets

Speakers

Billets et informations

SQL MCP Server sur Azure App Service — Sans Conteneurs

Qu’est-ce que le SQL MCP Server ?

Le Problème des Conteneurs (et la Solution)

Authentification Sans Clés d’API Partagées

Déploiement sur App Service

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

Conclusion

Supprimer le Travail Répétitif de la Migration avec l'Agentic Platform Engineering

L’entrée : contoso-migration

Étape 1 : Validation et authentification

Étape 2 : Extraction d’intention

Étape 3 : Correspondance de services

Étape 4 : Agent de critique

Étape 5 : Sortie générée

Comparaison de la posture de sécurité

Ce qui le distingue d’un convertisseur de syntaxe

SQL Server 2025 comme Base de Données Prête pour les Agents : Sécurité, Backup et MCP dans un Seul Moteur

Un Modèle de Sécurité pour Tous les Modèles de Données

Backup Unifié = Récupération Atomique

Intégration MCP : Agents Sans Middleware

Conclusion

Azure MCP Server Est Maintenant un .mcpb — Installez-le sans Aucun Runtime

Qu’est-ce qu’un MCP Bundle ?

Comment l’installer

Ce que vous pouvez faire avec

Pour commencer

Azure SDK Avril 2026 : AI Foundry 2.0 et Ce Que les Développeurs .NET Doivent Savoir

Azure.AI.Projects 2.0.0 — Changements Cassants Qui Font Sens

Cosmos DB Java : Correctif de Sécurité Critique (RCE)

Nouvelles Bibliothèques de Provisioning pour .NET

Conclusion

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

La progression de GPT-5

Le Flux de Déploiement avec `azd`