Ai | The .NET Blog

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

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

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

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

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

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

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

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

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

Ce que SQL MCP Server résout réellement

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

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

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

La bonne question

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

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

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

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

Le Modèle Handoff : Quand Un Agent Ne Suffit Pas

Emiliano Montesdeoca — Mon, 01 Jun 2026 00:00:00 +0000

À un moment donné, tout système multi-agents dépasse un simple routeur. Le premier signe apparaît généralement quand un agent spécialiste doit poser une question de suivi, ou réalise en milieu de tour qu’un autre agent devrait continuer. Un pipeline fixe échoue là. Un routeur à passage unique échoue là.

C’est exactement le problème que le modèle d’orchestration Handoff dans Microsoft Agent Framework est conçu pour résoudre.

Comment Fonctionne Handoff

Le développeur déclare un graphe : voici les agents, voici les arêtes entre eux. Le framework fait le reste — il synthétise un outil handoff par arête sortante et l’injecte dans chaque agent. Quand un agent décide de passer le contrôle, il appelle l’outil. Le framework applique la topologie.

Trois choses rendent cela différent du fait d’avoir simplement des agents qui s’appellent mutuellement :

Une transcription partagée — l’agent récepteur voit l’intégralité de l’historique de conversation. Pas de recommencement à zéro.
Application de la topologie — un agent ne peut faire handoff qu’à des cibles déclarées. Vous détectez les bugs de routage au moment de l’authoring, pas en production.
Terminaison naturelle — quand l’agent actif termine son tour sans appeler un outil handoff, le workflow cède à l’utilisateur. Pas de polling, pas de conditions de sortie explicites.

Un Exemple Minimal

En .NET, construire un workflow handoff ressemble à ceci :

using Microsoft.Agents.AI;
using Microsoft.Agents.AI.Workflows;

AIAgent triage = chatClient.AsAIAgent(
 instructions: "Route to the right specialist.",
 name: "Triage");

AIAgent billing = chatClient.AsAIAgent(
 instructions: "Handle billing questions.",
 name: "Billing");

AIAgent tech = chatClient.AsAIAgent(
 instructions: "Handle technical support.",
 name: "Tech");

var workflow = HandoffWorkflow.Create()
 .Add(triage, targets: [billing, tech])
 .Add(billing, targets: [triage])
 .Add(tech, targets: [triage, billing]);

Triage peut envoyer à l’un ou l’autre spécialiste. Les deux spécialistes peuvent renvoyer vers triage. Le graphe est compatible avec l’acyclique mais prend en charge les arêtes arrière quand vous en avez besoin (“j’ai besoin de plus d’informations” → retour à la recherche).

Quand Utiliser Handoff (et Quand Ne Pas Le Faire)

Handoff est un bon choix quand :

La propriété peut changer en cours de conversation — un agent peut réaliser qu’il est le mauvais spécialiste
Les arêtes arrière comptent — vous pourriez avoir besoin de revisiter une étape antérieure sans repartir à zéro
Les décisions de routage sont floues — la décision de faire un handoff est contextuelle et mieux prise par le modèle que par des prédicats typés

Ce n’est pas le bon choix quand :

Votre pipeline est fixe et séquentiel — utilisez le workflow Sequential pour cela
Chaque étape est indépendante — des agents partageant une transcription où seul l’un d’eux en avait besoin n’est que du bruit
Vous avez besoin de garanties strictes de traitement — le non-déterminisme du routage piloté par modèle n’est pas ce que vous voulez

Arêtes Arrière et Humain-dans-la-Boucle

L’une des formes les plus intéressantes qu’Handoff permet est les vraies arêtes arrière. Un agent peut décider “je n’ai pas assez d’informations” et revenir à une étape de recherche, pas avec une boucle codée en dur, mais parce que le modèle décide que c’est la bonne décision.

Les interactions humain-dans-la-boucle se composent également naturellement. Quand un spécialiste a besoin d’une entrée de l’utilisateur, le workflow cède à l’utilisateur via la boucle de tour par défaut, recueille la réponse et reprend avec le contexte complet. L’agent n’a jamais perdu la conversation.

Conclusion

Handoff est l’un de ces modèles qui semble simple mais permet beaucoup une fois intégré : routage décentralisé, contexte partagé, topologie appliquée, terminaison naturelle. C’est la prochaine étape appropriée quand vos agents commencent à dire “en fait, quelqu’un d’autre devrait gérer ça.”

Lisez le guide complet dans le post original : A Tour of the Handoff Orchestration Pattern

Workflows Durables dans Microsoft Agent Framework : De In-Memory à Azure Functions

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

L’un des points douloureux avec les premiers workflows d’agents IA : ils sont fragiles. Un workflow multi-étapes de longue durée lié à un seul processus signifie que le redémarrage du processus = état perdu. Pour des démos simples, c’est acceptable. Pour des charges de travail en production, ce ne l’est pas.

Le modèle de programmation de workflows de Microsoft Agent Framework prend désormais en charge l’exécution durable, basée sur le framework Durable Task, avec hébergement Azure Functions. Voici comment fonctionne le modèle de programmation et pourquoi l’histoire de la durabilité compte.

Les Blocs de Construction Fondamentaux

Les Executors sont l’unité fondamentale de travail. Chacun est typé — il prend une entrée spécifique et produit une sortie spécifique :

using Microsoft.Agents.AI.Workflows;

internal sealed class OrderLookup()
 : Executor<OrderCancelRequest, Order>("OrderLookup")
{
 public override async ValueTask<Order> HandleAsync(
 OrderCancelRequest message,
 IWorkflowContext context,
 CancellationToken cancellationToken = default)
 {
 // rechercher la commande, la retourner
 return new Order(Id: message.OrderId, ...);
 }
}

Les Workflows relient les executors en graphes dirigés en utilisant un constructeur fluide. Le framework gère l’exécution, le flux de données entre les étapes et la propagation des erreurs.

Vous pouvez modéliser :

Des chaînes séquentielles (étape A → étape B → étape C)
Fan-out/fan-in parallèle (exécuter les agents A, B, C en parallèle, agréger les résultats)
Branchement conditionnel
Approbations humain-dans-la-boucle (suspendre le workflow, attendre un signal externe)

Le Runner In-Memory pour le Développement Local

Démarrer est rapide :

dotnet add package Microsoft.Agents.AI
dotnet add package Microsoft.Agents.AI.Workflows

Le package principal inclut un runner léger en cours de processus. Pas de dépendances externes, pas de base de données, pas de ressources Azure. Fonctionne très bien pour le développement local et les tests unitaires.

Ajouter la Durabilité avec Durable Task

Quand un workflow doit survivre aux redémarrages de processus — parce qu’il est de longue durée, parce qu’il a des étapes humain-dans-la-boucle, parce qu’il se distribue sur de nombreux appels d’agents en parallèle — le runner in-memory n’est pas suffisant.

L’intégration Durable Task de MAF stocke l’état du workflow dans Azure Storage. Si le processus redémarre, le workflow reprend là où il s’était arrêté. Le modèle de programmation reste le même ; vous remplacez simplement le runner.

dotnet add package Microsoft.Agents.AI.Workflows.DurableTask

Les mêmes executors, le même graphe de workflow — basé sur un état durable.

Hébergement Azure Functions

La troisième couche est l’hébergement Azure Functions. Votre workflow devient une application Function : déclenchez le workflow via un endpoint HTTP, et le runtime durable gère la mise à l’échelle, l’état et la fiabilité.

Cela signifie qu’un workflow multi-agents avec des appels parallèles, des branches conditionnelles et des approbations humaines peut s’adapter à un environnement Functions serverless sans gestion d’état personnalisée.

Pourquoi C’est Important

La combinaison est significative pour les vrais systèmes IA :

Appels d’agents en parallèle — distribuer vers plusieurs agents spécialisés simultanément sans blocage, agréger les résultats quand tous terminent
Processus de longue durée — les workflows qui impliquent une approbation humaine ou des événements externes peuvent se suspendre et reprendre sur des heures ou des jours
Mise à l’échelle — Azure Functions fait évoluer l’exécution horizontalement ; le framework Durable Task gère la coordination de l’état parallèle

Si vous construisez des workflows MAF au-delà de simples démos locaux, c’est le chemin vers l’exécution de qualité production.

Publication originale : Durable Workflows in the Microsoft Agent Framework

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

Créer des Agents, C'est la Partie Facile — Les Exécuter en Toute Sécurité, C'est la Partie Difficile

Emiliano Montesdeoca — Fri, 29 May 2026 00:00:00 +0000

Il existe un modèle dans le développement d’agents IA que j’ai commencé à appeler le « regret de démo ». L’agent fonctionne très bien dans les démos. Ensuite, quelqu’un demande : que se passe-t-il s’il appelle le mauvais outil ? Et s’il accède à des données auxquelles il ne devrait pas ? Qui a audité ça ?

Microsoft Agent Framework vous soutient pour la construction et l’orchestration. Agent Governance Toolkit (AGT) couvre la partie après — gouvernance, application des politiques et auditabilité à l’exécution.

Ce Que Chaque Projet Fait Vraiment

Microsoft Agent Framework (MAF) vous offre le modèle de programmation : workflows multi-agents, interopérabilité du protocole A2A, hooks de middleware, mémoire et hébergement géré via Foundry Agent Service. Il gère la sécurité du contenu au niveau de l’entrée/sortie du modèle.

Agent Governance Toolkit (AGT) se connecte à ce même pipeline de middleware pour gouverner les actions. Chaque appel d’outil, accès aux ressources et message inter-agents est évalué par rapport à la politique avant l’exécution. Surcharge inférieure à la milliseconde. Pas de sidecars, pas de proxies, pas de prompts modifiés.

Action Agent --> Vérification Politique --> Autoriser / Refuser --> Journal Audit (< 0.1 ms)

Des couches différentes, une couverture complète, un pipeline.

S’intégrer, C’est Juste Ajouter un Middleware

En Python, AGT s’ajoute au même paramètre middleware que vous utiliseriez pour la journalisation ou les filtres de contenu :

agent = Agent(
 client=OpenAIChatClient(model="gpt-5.3"),
 name="Contoso Loan Officer",
 instructions="You are a governed loan assistant.",
 tools=[check_credit_score, get_loan_rates, approve_small_loan],
 middleware=[
 AuditTrailMiddleware(audit_log=audit_log, agent_did="loan-agent"),
 GovernancePolicyMiddleware(evaluator=evaluator, audit_log=audit_log),
 CapabilityGuardMiddleware(allowed_tools=["check_credit_score", "get_loan_rates"]),
 RogueDetectionMiddleware(detector=detector, agent_id="loan-agent"),
 ],
)

En .NET, même modèle via .Use() :

var agent = builder.BuildAIAgent(model: "gpt-5.3")
 .Use(new GovernancePolicyMiddleware(evaluator))
 .Use(new CapabilityGuardMiddleware(allowedTools))
 .Use(new AuditTrailMiddleware(auditLog));

Même agent, même orchestration, mêmes outils. AGT ajoute des capacités de gouvernance sans toucher à la logique de l’agent.

Ce Que Vous Obtenez

GovernancePolicyMiddleware — évalue chaque action par rapport aux règles de politique déclaratives
CapabilityGuardMiddleware — liste blanche des outils qu’un agent est autorisé à appeler (l’outil approve_small_loan n’est pas dans la liste autorisée ci-dessus — délibérément)
RogueDetectionMiddleware — détecte les modèles de comportement anormaux à l’exécution
AuditTrailMiddleware — journal d’audit chaîné par Merkle pour que chaque action soit cryptographiquement inviolable

Ce dernier point compte pour la conformité. Une chaîne Merkle signifie que si quelqu’un modifie le journal, la chaîne se rompt. L’audit est la preuve.

Cinq Scénarios Industriels

Le dépôt AGT comprend cinq scénarios complets de bout en bout : services financiers (agent de crédit), santé (données patient), juridique (examen de contrat), gouvernement (services aux citoyens) et fabrication (contrôle qualité). Chacun associe de vrais agents MAF avec un vrai middleware de gouvernance AGT.

Ce ne sont pas des démos jouets. Ce sont le type de scénarios où vous auriez vraiment besoin d’une gouvernance en production.

Conclusion

Si vous construisez des agents qui touchent des données réelles, prennent des décisions avec des conséquences, ou s’exécutent sans surveillance en production — la gouvernance n’est pas optionnelle. La combinaison MAF + AGT vous donne la pile complète : construisez-le avec Agent Framework, gouvernez-le avec AGT.

Les deux projets sont open source. L’article original contient des liens vers les exemples de code complets.

Publication originale : Governance at the Speed of Agents: Microsoft Agent Framework and Agent Governance Toolkit, Better Together

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

Azure SQL Peut Maintenant Générer des Embeddings — En T-SQL Pur, Sans Couche Applicative

Emiliano Montesdeoca — Fri, 22 May 2026 00:00:00 +0000

Si vous avez déjà construit un pipeline RAG, vous connaissez la taxe pipeline : vos données vivent dans SQL, mais pour générer des embeddings vous devez les extraire, appeler une API d’embeddings, gérer le traitement par lots et les limites de débit, et stocker les résultats quelque part avec une recherche vectorielle. Souvent dans une base de données entièrement différente.

Azure SQL vient d’éliminer la majeure partie de cela avec deux fonctionnalités désormais généralement disponibles : CREATE EXTERNAL MODEL et AI_GENERATE_EMBEDDINGS.

Ce Qu’elles Font

Ces deux fonctionnalités T-SQL fonctionnent comme un pipeline intégré :

CREATE EXTERNAL MODEL — enregistre un endpoint de modèle d’IA externe comme un objet de base de données nommé. Vous définissez l’emplacement, le format d’API, le type de modèle et les identifiants une seule fois. Réutilisez-les partout.

AI_GENERATE_EMBEDDINGS — une fonction T-SQL scalaire qui appelle le modèle enregistré et renvoie un tableau JSON de valeurs vectorielles. Fonctionne dans les instructions SELECT, INSERT, UPDATE et MERGE.

Ensemble, ils forment un pipeline d’embeddings de bout en bout sans quitter le moteur SQL.

Le Flux de Travail Complet

-- Étape 1 : Enregistrez votre fournisseur d'embeddings une fois
CREATE EXTERNAL MODEL MyEmbeddingModel
WITH (
 LOCATION = 'https://your-aoai-resource.openai.azure.com/',
 API_FORMAT = 'Azure OpenAI',
 MODEL_TYPE = EMBEDDINGS,
 MODEL = 'text-embedding-ada-002'
);

-- Étape 2 : Générez des embeddings en ligne en T-SQL
UPDATE docs
SET embedding = AI_GENERATE_EMBEDDINGS(content USE MODEL MyEmbeddingModel)
FROM documents AS docs;

-- Étape 3 : Recherche avec la distance vectorielle
SELECT TOP 10 id, content
FROM documents
ORDER BY VECTOR_DISTANCE('cosine', embedding,
 AI_GENERATE_EMBEDDINGS(@query USE MODEL MyEmbeddingModel));

C’est tout le pipeline : données dans SQL, embeddings générés dans SQL, recherche de similarité dans SQL. Pas de couche d’orchestration, pas d’ETL, pas de base de données vectorielle séparée.

Formats d’API et Options Supportés

En GA, API_FORMAT supporte Azure OpenAI et OpenAI. MODEL_TYPE est verrouillé sur EMBEDDINGS pour l’instant. Le JSON PARAMETERS vous permet de définir des valeurs par défaut au niveau du modèle, notamment le nombre de tentatives :

PARAMETERS = '{"sql_rest_options":{"retry_count":3}}'

L’authentification utilise les identifiants de la base de données, donc les secrets restent hors de votre code applicatif.

Ce Que Cela Permet pour les Applications .NET

Pour les développeurs .NET qui construisent des fonctionnalités d’IA sur des données SQL existantes, c’est significatif. Vous n’avez pas besoin de :

Extraire des données vers un magasin intermédiaire pour les embeddings
Gérer un pipeline d’embeddings externe
Configurer une base de données vectorielle séparée (bien que vous puissiez utiliser Azure AI Search si vous voulez un magasin vectoriel complet)
Modifier la couche d’accès aux données de votre application

Vous pouvez ajouter la recherche sémantique aux applications SQL existantes de manière incrémentale, en utilisant les mêmes outils T-SQL que vous avez déjà.

Conclusion

Les patterns RAG sur les données SQL sont devenus dramatiquement plus simples. AI_GENERATE_EMBEDDINGS + CREATE EXTERNAL MODEL signifie que votre application SQL existante peut acquérir des capacités de recherche vectorielle sans ajouter de nouvelle infrastructure.

Les deux fonctionnalités sont en GA dans Azure SQL Database et Azure SQL Managed Instance aujourd’hui.

Post original : Generate Embeddings Function and External Model Object Support Are Now Generally Available in Azure SQL

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

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.

Créer une application de conférence IA avec la pile composable de .NET

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

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

Créer une application de conférence IA avec la pile composable de .NET — Microsoft a créé ConferencePulse, une application Blazor Server pour les sessions de conférence en direct, en combinant cinq bibliothèques d’extension .NET. Elle a été utilisée au MVP Summit.

Ce que fait ConferencePulse

ConferencePulse s’exécute pendant les sessions en direct et fournit : des sondages générés par l’IA à partir du contenu de la session, des questions-réponses du public avec un pipeline RAG puisant dans une base de connaissances en direct, des insights générés automatiquement et des résumés de sessions produits par plusieurs agents IA concurrents. La pile est .NET 10, Blazor Server, Aspire, répartie sur cinq projets : Web, Core, Ingestion, Agents, Mcp et AppHost.

Microsoft.Extensions.AI : une abstraction pour tout

IChatClient est l’abstraction unifiée — on la configure une fois et la même interface fonctionne pour Azure OpenAI, OpenAI, Anthropic ou tout autre fournisseur. Six lignes pour obtenir un client entièrement configuré avec l’invocation de fonctions, le traçage OpenTelemetry et le middleware de journalisation :

services.AddChatClient(new AzureOpenAIClient(...).GetChatClient("gpt-4o"))
 .UseFunctionInvocation()
 .UseOpenTelemetry()
 .UseLogging();

Le même IChatClient est réutilisé plus tard pour l’étape d’enrichissement de l’ingestion de données — pas besoin d’un client séparé pour cela.

Pipeline DataIngestion

Le contenu de la session circule dans un pipeline : MarkdownReader → HeaderChunker (500 tokens, 50 tokens de chevauchement) → SummaryEnricher + KeywordEnricher → VectorStoreWriter (Qdrant). Les enrichisseurs utilisent le même IChatClient pour générer des résumés et extraire des mots-clés avant l’indexation. Les questions du public, les paires de questions-réponses et les résultats des sondages sont ingérés en temps réel au fur et à mesure de la session — la base de connaissances s’enrichit pendant la conférence.

VectorData : recherche indépendante du fournisseur

VectorStoreCollection.SearchAsync() fonctionne de la même manière que le magasin sous-jacent soit Qdrant ou Azure AI Search. La recherche hybride (vecteur + texte intégral) est prise en charge. Le pipeline RAG pour les questions-réponses du public interroge cette collection et récupère des extraits pertinents à transmettre comme contexte au client de chat.

MCP : contenu de session comme outils

Le contenu de la session est exposé via MCP afin que tout client compatible MCP puisse y accéder. Le serveur et le client sont tous deux implémentés — le serveur expose les connaissances de la session comme outils MCP, et le client permet d’appeler ces outils depuis le pipeline de l’agent.

Agent Framework : résumé multi-agents en parallèle

Le résumé de la session est généré par trois agents s’exécutant de manière concurrente — PollSummaryAgent, QuestionSummaryAgent et InsightSummaryAgent — puis fusionnés. Cela utilise le modèle de chat de groupe ou d’exécution parallèle de Microsoft Agent Framework. Chaque agent gère une préoccupation ; l’orchestrateur fusionne les sorties.

Le principe de conception

L’article soulève un point important : utiliser l’outil le plus simple qui convient. Les appels directs à IChatClient pour les tâches de génération simples. L’appel d’outil/fonction pour l’extraction de données structurées. Les agents complets uniquement quand on a besoin d’un raisonnement autonome en plusieurs étapes. La stratification des bibliothèques l’impose — on peut utiliser Microsoft.Extensions.AI sans inclure l’Agent Framework complet.

Consultez le post complet pour la structure complète du projet et les liens vers le code source.

Microsoft Agent Framework Partie 3 : Des outils aux workflows — Les blocs s'emboîtent

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

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

Si vous avez suivi la série Building Blocks for AI en .NET, vous savez que la Partie 1 nous a donné IChatClient (l’interface universelle de modèles) et la Partie 2 Microsoft.Extensions.VectorData (recherche sémantique et RAG). Ces deux éléments sont fondamentaux et utiles indépendamment. Mais c’est ici que tout commence à se connecter.

La Partie 3 porte sur le Microsoft Agent Framework — et franchement, c’est la pièce que j’attendais de voir arriver dans .NET. La version 1.0 est sortie en avril. L’API est stable. Il est temps de construire de vrais agents.

Ce qu’est vraiment un agent (vs. un chatbot)

Avant de plonger dans le code, clarifions cette distinction. Un chatbot reçoit un input, appelle un modèle, retourne un output. Boucle simple.

Un agent a de l’autonomie. Il peut raisonner sur une tâche, décider quels outils utiliser, les appeler, évaluer les résultats et décider quoi faire ensuite — tout cela sans que vous écriviez une logique étape par étape pour chaque scénario. Vous lui donnez des outils et des instructions, et il s’occupe de l’orchestration.

Voyez-le ainsi : IChatClient c’est comme avoir une conversation. Un agent c’est comme déléguer une liste de tâches à quelqu’un.

Votre premier agent en 10 lignes

dotnet add package Microsoft.Agents.AI

AIAgent agent = new AzureOpenAIClient(
 new Uri(endpoint),
 new DefaultAzureCredential())
 .GetChatClient(deploymentName)
 .AsAIAgent(
 instructions: "You are good at telling jokes.",
 name: "Joker");

Console.WriteLine(await agent.RunAsync("Tell me a joke about a pirate."));

La méthode d’extension .AsAIAgent() est le pont. Même pattern que .AsIChatClient() de MEAI — elle enveloppe le SDK du fournisseur dans une abstraction stable. Fonctionne avec Azure OpenAI, OpenAI, GitHub Models, Microsoft Foundry ou des modèles locaux.

Le streaming fonctionne aussi :

await foreach (var update in agent.RunStreamingAsync("Tell me a joke about a pirate."))
{
 Console.Write(update);
}

Donner des outils à l’agent

C’est là que les agents cessent d’être des chatbots sophistiqués. Les outils sont des fonctions que le modèle peut décider d’appeler selon ce que l’utilisateur demande. Pas de logique de routage nécessaire — le modèle le détermine lui-même.

[Description("Get the weather for a given location.")]
static string GetWeather(
 [Description("The location to get the weather for.")] string location)
 => $"The weather in {location} is cloudy with a high of 15°C.";

AIAgent agent = chatClient.AsAIAgent(
 instructions: "You are a helpful assistant",
 tools: [AIFunctionFactory.Create(GetWeather)]);

Deux choses à noter. Premièrement, AIFunctionFactory vient de MEAI — la même factory d’outils que vous utiliseriez avec un IChatClient normal. Si vous avez déjà défini des outils pour des scénarios de chat, ils fonctionnent ici aussi.

Deuxièmement, les attributs Description sont très importants. C’est comment le modèle comprend ce que fait un outil et quand l’utiliser. Traitez-les comme de la documentation pour votre IA, pas pour les humains.

Sessions : Des conversations avec une vraie mémoire

AgentSession session = await agent.CreateSessionAsync();

Console.WriteLine(await agent.RunAsync("Tell me a joke about a pirate.", session));

Console.WriteLine(await agent.RunAsync(
 "Now add some emojis and tell it in the voice of a pirate's parrot.",
 session));

Sans session, chaque appel à RunAsync est sans état. Avec une session, l’agent sait à quelle blague vous faites référence. AgentSession préserve l’historique de conversation entre les tours.

Pour les services sans état en production, les sessions se sérialisent proprement :

JsonElement sessionState = await agent.SerializeSessionAsync(session);
// ... stockez-le quelque part ...
var restoredSession = await agent.DeserializeSessionAsync(sessionState);
Console.WriteLine(await agent.RunAsync("What were we just talking about?", restoredSession));

C’est crucial si votre agent s’exécute dans un environnement serverless ou mis à l’échelle horizontalement.

AIContextProvider : Mémoire persistante entre les sessions

Les sessions préservent l’historique au sein d’une session. Mais qu’en est-il de connaître des choses sur un utilisateur entre les sessions ? AIContextProvider gère cela.

Il a deux hooks :

ProvideAIContextAsync — s’exécute avant chaque interaction, injecte du contexte dans l’agent
StoreAIContextAsync — s’exécute après chaque interaction, permet d’apprendre et de persister

Le pattern est élégant : vous pouvez empiler plusieurs providers — un pour les préférences utilisateur, un pour les interactions récentes, un qui interroge votre store VectorData pour des documents pertinents. Ce dernier est exactement le pattern RAG de la Partie 2, s’exécutant maintenant automatiquement à chaque appel d’agent.

Workflows multi-agents

C’est là que le framework mérite son nom. Il inclut un système de workflows basé sur des graphes où les executors (agents, fonctions, quoi que ce soit) se connectent via des arêtes.

Quelques patterns supportés nativement :

Séquentiel : La sortie de l’Agent A alimente l’Agent B
Concurrent (fan-out/fan-in) : Dispatch vers plusieurs agents en parallèle, collecte des résultats
Routage conditionnel : Achemine le travail vers différents agents selon la sortie
Boucles écrivain-critique : Un agent écrit, un autre évalue, boucle jusqu’à approbation
Sub-workflows : Composition hiérarchique de workflows

Un exemple écrivain-critique :

WorkflowBuilder builder = new(writerAgent);
builder
 .AddEdge(writerAgent, criticAgent)
 .AddEdge(criticAgent, writerAgent, condition: result => !result.IsApproved)
 .WithOutputFrom(criticAgent, condition: result => result.IsApproved);
var workflow = builder.Build();

Propre, lisible, et le routage basé sur des conditions signifie que vous n’écrivez pas la logique de boucle vous-même.

Human-in-the-Loop

Tout ne devrait pas s’exécuter de manière entièrement autonome. Pour les opérations sensibles — écritures en base de données, transactions financières, envoi de communications — vous voulez qu’un humain approuve avant que l’agent n’exécute.

Le framework a un support intégré pour cela via FunctionApprovalRequestContent et FunctionApprovalResponseContent. L’agent propose l’appel d’outil, votre code applicatif le présente à l’utilisateur, et la réponse détermine si l’exécution se poursuit.

C’est la bonne façon de penser aux agents dans les contextes d’entreprise : pas entièrement autonomes, mais autonomie avec des garde-fous.

Vue d’ensemble

Si vous prenez du recul :

MEAI vous donne une interface universelle vers n’importe quel modèle
VectorData donne à vos agents accès à la connaissance de votre organisation via la recherche sémantique
Agent Framework orchestre tout — utilise IChatClient en interne, se compose avec des context providers, et coordonne via des workflows

Chaque pièce a été conçue pour se composer avec les autres. Consultez le post original de Jeremy Likness et le dépôt GitHub de l’Agent Framework pour les exemples complets.

Conclusion

Le post Partie 3 du Microsoft Agent Framework boucle la boucle de la série Building Blocks. Pour les développeurs .NET qui veulent construire des agents IA — pas seulement des chatbots, de vrais agents qui utilisent des outils, se souviennent de choses et coordonnent — c’est votre voie.

La version stable 1.0 signifie que vous pouvez construire avec cela en production. Si vous attendiez de vous lancer dans le développement d’agents en .NET, c’est le bon moment.

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.

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

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

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

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

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

Qu’est-ce que CodeAct ?

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

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

Sécurité : Micro-VMs Hyperlight

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

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

Configuration minimale

from agent_framework import Agent, tool
from agent_framework_hyperlight import HyperlightCodeActProvider

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

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

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

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

Utilisez CodeAct quand :

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

Restez avec le tool-calling traditionnel quand :

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

Essayez maintenant

pip install agent-framework-hyperlight --pre

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

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.

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

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

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

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

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

Deux modèles fondamentaux

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

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

Comment Agent Framework abstrait cela

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

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

Référence rapide des fournisseurs

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

Comment choisir

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

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

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

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

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

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

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

Qu’est-ce qu’une Toolbox ?

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

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

Les quatre piliers (deux disponibles aujourd’hui)

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

Exemple pratique

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

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

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

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

Pas d’enfermement dans Foundry Agents

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

Pourquoi c’est important maintenant

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

Conclusion

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

Windows App Dev CLI v0.3 : F5 depuis le terminal et UI Automation pour les agents

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

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

L’expérience F5 de Visual Studio est formidable. Mais devoir ouvrir VS uniquement pour lancer et déboguer une application Windows packagée, c’est trop — que ce soit dans un pipeline CI, un workflow automatisé, ou quand un agent IA effectue les tests.

Windows App Development CLI v0.3 vient d’être publié et répond directement à ce besoin avec deux fonctionnalités phares : winapp run et winapp ui.

winapp run : F5 depuis n’importe où

winapp run prend un dossier d’application non packagée et un manifeste, et fait tout ce que VS fait au lancement debug : enregistre un package loose, lance l’application et préserve le LocalState entre les re-déploiements.

# Compiler l'app, puis la lancer comme app packagée
winapp run ./bin/Debug

Fonctionne pour WinUI, WPF, WinForms, Console, Avalonia et plus. Les modes sont conçus pour les développeurs et les workflows automatisés :

--detach : Lance et rend immédiatement le contrôle au terminal. Idéal pour CI/automation.
--unregister-on-exit : Nettoie le package enregistré à la fermeture de l’app.
--debug-output : Capture les messages OutputDebugString et les exceptions en temps réel.

Nouveau package NuGet : dotnet run pour les apps packagées

Pour les développeurs .NET, il y a un nouveau package NuGet : Microsoft.Windows.SDK.BuildTools.WinApp. Après installation, dotnet run gère tout l’inner loop : build, préparation du package loose-layout, enregistrement Windows et lancement — en une seule étape.

# Laisser winapp init tout configurer
winapp init
# Ou installer directement
dotnet add package Microsoft.Windows.SDK.BuildTools.WinApp

winapp ui : UI Automation depuis la ligne de commande

C’est la fonctionnalité qui ouvre les scénarios agentiques. winapp ui donne un accès UI Automation complet à toute application Windows en cours d’exécution — WPF, WinForms, Win32, Electron, WinUI3 — depuis le terminal.

Ce qu’on peut faire :

Lister toutes les fenêtres de niveau supérieur
Parcourir l’arborescence UI Automation complète d’une fenêtre
Rechercher des éléments par nom, type ou ID d’automatisation
Cliquer, invoquer et définir des valeurs
Prendre des captures d’écran
Attendre l’apparition d’éléments — idéal pour la synchronisation de tests

Combiner winapp ui avec winapp run donne un workflow complet build → lancement → vérification depuis le terminal. Un agent peut exécuter l’app, inspecter l’état de l’interface et valider le résultat.

Autres nouveautés

winapp unregister : Supprime un package sideloadé quand on a terminé.
winapp manifest add-alias : Ajoute un alias pour lancer l’app par nom depuis le terminal.
Complétion automatique : Un seul commande pour configurer la complétion PowerShell.

Installation

winget install Microsoft.WinAppCli
# ou
npm install -g @microsoft/winappcli

La CLI est en preview publique. Le dépôt GitHub contient la documentation complète et l’annonce originale tous les détails.

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

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

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

Voici ce qui compte vraiment.

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

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

L’Agent Host supporte trois configurations de session :

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

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

Worktree et isolation git pour les sessions d’agents

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

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

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

Sous-agents et équipes d’agents

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

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

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

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

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

L’application Agents sur macOS se met à jour automatiquement

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

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

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

Ce qu’il faut retenir

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

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

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.

Docker Sandbox permet aux agents Copilot de refactoriser votre code sans risque pour votre machine

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

Si vous avez utilisé le mode agent de Copilot pour autre chose que de petites modifications, vous connaissez la douleur. Chaque écriture de fichier, chaque commande terminal — encore une demande de permission. Maintenant, imaginez ça sur 50 projets. Pas vraiment fun.

L’équipe Azure vient de publier un article sur Docker Sandbox pour les agents GitHub Copilot, et honnêtement, c’est l’une des améliorations les plus pratiques que j’ai vues dans l’outillage agentique. Le système utilise des microVMs pour donner à Copilot un environnement totalement isolé où il peut faire ce qu’il veut — installer des paquets, lancer des builds, exécuter des tests — sans toucher à votre système hôte.

Ce que Docker Sandbox vous apporte concrètement

L’idée de base est simple : démarrer une microVM légère avec un environnement Linux complet, synchroniser votre workspace dedans, et laisser l’agent Copilot opérer librement à l’intérieur. Quand il a terminé, les modifications sont synchronisées en retour.

Voici ce qui en fait plus qu’un simple “exécuter des trucs dans un conteneur” :

Synchronisation bidirectionnelle du workspace qui préserve les chemins absolus. La structure de votre projet est identique à l’intérieur du sandbox. Pas d’échecs de build liés aux chemins.
Docker daemon privé tournant à l’intérieur de la microVM. L’agent peut construire et exécuter des conteneurs sans jamais monter le socket Docker de votre hôte. C’est un gros plus pour la sécurité.
Proxies de filtrage HTTP/HTTPS qui contrôlent ce que l’agent peut atteindre sur le réseau. Vous décidez quels registries et endpoints sont autorisés. Des attaques de supply chain via un npm install malveillant dans le sandbox ? Bloquées.
Mode YOLO — oui, c’est vraiment comme ça qu’ils l’appellent. L’agent tourne sans demandes de permission parce qu’il ne peut littéralement pas endommager votre hôte. Toute action destructrice est contenue.

Pourquoi les développeurs .NET devraient s’y intéresser

Pensez au travail de modernisation auquel tant d’équipes font face en ce moment. Vous avez une solution .NET Framework avec 30 projets, et vous devez la migrer vers .NET 9. Ce sont des centaines de modifications de fichiers — fichiers de projet, mises à jour de namespaces, remplacements d’API, migrations NuGet.

Avec Docker Sandbox, vous pouvez pointer un agent Copilot sur un projet, le laisser refactoriser librement dans la microVM, exécuter dotnet build et dotnet test pour valider, et n’accepter que les changements qui fonctionnent réellement. Aucun risque qu’il détruise accidentellement votre environnement de développement local en expérimentant.

L’article décrit également l’exécution d’une flotte d’agents en parallèle — chacun dans son propre sandbox — s’attaquant à différents projets simultanément. Pour les grandes solutions .NET ou les architectures microservices, c’est un gain de temps massif. Un agent par service, tous isolés, tous validés indépendamment.

L’angle sécurité compte

Voici ce que la plupart des gens ignorent : quand vous laissez un agent IA exécuter des commandes arbitraires, vous lui confiez l’intégralité de votre machine. Docker Sandbox inverse ce modèle. L’agent obtient une autonomie totale dans un environnement jetable. Le proxy réseau garantit qu’il ne peut télécharger que depuis des sources approuvées. Votre système de fichiers hôte, votre Docker daemon et vos identifiants restent intacts.

Pour les équipes avec des exigences de conformité — et c’est le cas de la plupart des entreprises .NET — c’est la différence entre “on ne peut pas utiliser l’IA agentique” et “on peut l’adopter en toute sécurité.”

À retenir

Docker Sandbox résout la tension fondamentale du coding agentique : les agents ont besoin de liberté pour être utiles, mais la liberté sur votre machine hôte est dangereuse. Les microVMs vous offrent les deux. Si vous planifiez un refactoring ou une modernisation .NET à grande échelle, ça vaut le coup de le mettre en place maintenant. La combinaison de l’intelligence de code de Copilot avec un environnement d’exécution sécurisé est exactement ce que les équipes de production attendaient.

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.

.NET Aspire 13.2 Veut Devenir le Meilleur Ami de Votre Agent IA

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

Tu connais ce moment où ton agent IA écrit du code solide, tu es tout excité, et puis tout s’effondre quand il essaie de lancer le truc ? Conflits de ports, processus fantômes, mauvaises variables d’environnement — soudain ton agent brûle des tokens à déboguer des problèmes de démarrage au lieu de construire des fonctionnalités.

L’équipe Aspire vient de publier un post très bien pensé sur exactement ce problème, et leur réponse est convaincante : Aspire 13.2 est conçu non seulement pour les humains, mais pour les agents IA.

Le problème est réel

Les agents IA sont incroyables pour écrire du code. Mais livrer une app full-stack fonctionnelle implique bien plus que générer des fichiers. Il faut démarrer les services dans le bon ordre, gérer les ports, configurer les variables d’environnement, connecter les bases de données et obtenir du feedback quand ça casse. Actuellement, la plupart des agents gèrent tout ça par essai-erreur — exécuter des commandes, lire les sorties d’erreur, réessayer.

On empile des instructions Markdown, des skills personnalisés et des prompts pour les guider, mais c’est imprévisible, ça ne se compile pas, et ça coûte des tokens juste pour parser. L’équipe Aspire a mis le doigt sur l’insight clé : les agents ont besoin de compilateurs et d’APIs structurées, pas de plus de Markdown.

Aspire comme infrastructure pour agents

Voici ce qu’Aspire 13.2 apporte à la table du développement agentique :

Toute ta stack en code typé. L’AppHost définit ta topologie complète — API, frontend, base de données, cache — en TypeScript ou C# compilable :

import { createBuilder } from './.modules/aspire.js';

const builder = await createBuilder();

const postgres = await builder.addPostgres("pg").addDatabase("catalog");
const cache = await builder.addRedis("cache");

const api = await builder
 .addNodeApp("api", "./api", "src/index.ts")
 .withHttpEndpoint({ env: "PORT" })
 .withReference(postgres)
 .withReference(cache);

await builder
 .addViteApp("frontend", "./frontend")
 .withReference(api)
 .waitFor(api);

await builder.build().run();

Un agent peut lire ça pour comprendre la topologie de l’app, ajouter des ressources, câbler les connexions et compiler pour vérifier. Le compilateur lui dit immédiatement si quelque chose ne va pas. Pas de devinettes, pas d’essai-erreur avec les fichiers de config.

Une seule commande pour les gouverner toutes. Au lieu que les agents jonglent entre docker compose up, npm run dev et les scripts de démarrage de base de données, tout est simplement aspire start. Toutes les ressources se lancent dans le bon ordre, sur les bons ports, avec la bonne configuration. Les processus longs ne bloquent pas non plus l’agent — Aspire les gère.

Mode isolé pour les agents parallèles. Avec --isolated, chaque exécution d’Aspire obtient ses propres ports aléatoires et secrets utilisateur séparés. Plusieurs agents travaillent sur des git worktrees ? Ils n’entreront pas en collision. C’est énorme pour des outils comme les agents en arrière-plan de VS Code qui créent des environnements parallèles.

Des yeux d’agent grâce à la télémétrie. C’est là que ça devient vraiment puissant. La CLI Aspire expose des données OpenTelemetry complètes pendant le développement — traces, métriques, logs structurés. Ton agent ne se contente pas de lire la sortie console en espérant que tout va bien. Il peut tracer une requête échouée à travers les services, profiler les endpoints lents et identifier précisément où les choses cassent. C’est de l’observabilité de niveau production dans la boucle de développement.

L’analogie des bumpers de bowling

L’équipe Aspire utilise une super analogie : pense à Aspire comme les bumpers de piste de bowling pour les agents IA. Si l’agent n’est pas parfait (et il ne le sera pas), les bumpers l’empêchent de faire des gouttières. La définition de la stack empêche les mauvaises configurations, le compilateur attrape les erreurs, la CLI gère les processus, et la télémétrie fournit la boucle de feedback.

Combine ça avec quelque chose comme Playwright CLI, et ton agent peut réellement utiliser ton app — cliquer dans les flux, vérifier le DOM, voir les trucs cassés dans la télémétrie, corriger le code, redémarrer et retester. Construire, exécuter, observer, corriger. C’est la boucle de développement autonome que nous poursuivons.

Pour démarrer

Nouveau avec Aspire ? Installe la CLI depuis get.aspire.dev et suis le guide de démarrage.

Tu utilises déjà Aspire ? Lance aspire update --self pour obtenir la 13.2, puis pointe ton agent de coding favori vers ton repo. Tu seras surpris de voir jusqu’où il ira avec les garde-fous d’Aspire.

Pour conclure

Aspire 13.2 n’est plus seulement un framework d’applications distribuées — il devient une infrastructure essentielle pour les agents. Des définitions de stack structurées, un démarrage en une commande, des exécutions parallèles isolées et de la télémétrie en temps réel donnent aux agents IA exactement ce dont ils ont besoin pour passer de l’écriture de code à la livraison d’apps.

Lis le post complet de l’équipe Aspire pour tous les détails et vidéos de démo.

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.

Les MCP Apps ont une API fluide — Créez des interfaces riches pour outils IA en .NET en trois étapes

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

Les outils MCP sont parfaits pour donner des capacités aux agents IA. Mais que faire si votre outil doit montrer quelque chose à l’utilisateur — un tableau de bord, un formulaire, une visualisation interactive ? C’est là qu’interviennent les MCP Apps, et elles sont devenues beaucoup plus faciles à créer.

Lilian Kasem de l’équipe Azure SDK a présenté la nouvelle API de configuration fluide pour les MCP Apps sur Azure Functions .NET, et c’est le genre d’amélioration de l’expérience développeur qui fait se demander pourquoi ce n’était pas déjà aussi simple.

Qu’est-ce que les MCP Apps ?

Les MCP Apps étendent le Model Context Protocol en permettant aux outils d’embarquer leurs propres vues UI, assets statiques et contrôles de sécurité. Au lieu de simplement retourner du texte, votre outil MCP peut rendre des expériences HTML complètes — tableaux de bord interactifs, visualisations de données, formulaires de configuration — le tout invocable par des agents IA et présenté aux utilisateurs par les clients MCP.

Le problème était que tout câbler manuellement nécessitait une connaissance approfondie de la spécification MCP : URIs ui://, types MIME spéciaux, coordination des métadonnées entre outils et ressources. Pas difficile, mais fastidieux.

L’API fluide en trois étapes

Étape 1 : Définissez votre fonction. Un outil MCP Azure Functions standard :

[Function(nameof(HelloApp))]
public string HelloApp(
 [McpToolTrigger("HelloApp", "A simple MCP App that says hello.")]
 ToolInvocationContext context)
{
 return "Hello from app";
}

Étape 2 : Promouvez-la en MCP App. Dans le démarrage de votre programme :

builder.ConfigureMcpTool("HelloApp")
 .AsMcpApp(app => app
 .WithView("assets/hello-app.html")
 .WithTitle("Hello App")
 .WithPermissions(McpAppPermissions.ClipboardWrite | McpAppPermissions.ClipboardRead)
 .WithCsp(csp =>
 {
 csp.AllowBaseUri("https://www.microsoft.com")
 .ConnectTo("https://www.microsoft.com");
 }));

Étape 3 : Ajoutez votre vue HTML. Créez assets/hello-app.html avec l’interface dont vous avez besoin.

C’est tout. L’API fluide gère toute la plomberie du protocole MCP — génère la fonction de ressource synthétique, définit le type MIME correct et injecte les métadonnées qui connectent votre outil à sa vue.

La surface de l’API est bien conçue

Quelques éléments que j’apprécie particulièrement :

Les sources de vues sont flexibles. Vous pouvez servir du HTML depuis des fichiers sur disque ou intégrer des ressources directement dans votre assembly pour des déploiements autonomes :

app.WithView(McpViewSource.FromFile("assets/my-view.html"))
app.WithView(McpViewSource.FromEmbeddedResource("MyApp.Resources.view.html"))

Le CSP est composable. Vous autorisez explicitement les origines dont votre app a besoin, en suivant le principe du moindre privilège. Appelez WithCsp plusieurs fois et les origines s’accumulent :

.WithCsp(csp =>
{
 csp.ConnectTo("https://api.example.com")
 .LoadResourcesFrom("https://cdn.example.com")
 .AllowFrame("https://youtube.com");
})

Contrôle de visibilité. Vous pouvez rendre un outil visible uniquement pour le LLM, uniquement pour l’UI de l’hôte, ou les deux. Vous voulez un outil qui ne fait que rendre de l’UI et ne devrait pas être appelé par le modèle ? Facile :

.WithVisibility(McpVisibility.App) // UI-only, hidden from the model

Pour commencer

Ajoutez le package preview :

dotnet add package Microsoft.Azure.Functions.Worker.Extensions.Mcp --version 1.5.0-preview.1

Si vous construisez déjà des outils MCP avec Azure Functions, c’est juste une mise à jour de package. Le quickstart MCP Apps est le meilleur point de départ si vous découvrez le concept.

Pour conclure

Les MCP Apps sont l’un des développements les plus passionnants dans l’espace des outils IA — des outils qui ne font pas que faire des choses mais peuvent aussi montrer des choses aux utilisateurs. L’API fluide supprime la complexité du protocole et vous permet de vous concentrer sur l’essentiel : la logique de votre outil et son interface.

Lisez le post complet pour la référence complète de l’API et des exemples.

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.

VS Code 1.115 — Notifications de Terminal en Arrière-plan, Mode Agent SSH et Plus

Emiliano Montesdeoca — Mon, 06 Apr 2026 00:00:00 +0000

VS Code 1.115 vient de sortir, et bien que ce soit une version plus légère en termes de fonctionnalités phares, les améliorations liées aux agents sont vraiment utiles si vous travaillez quotidiennement avec des assistants de code IA.

Permettez-moi de souligner ce qui vaut vraiment la peine d’être connu.

Les terminaux en arrière-plan communiquent avec les agents

C’est la fonctionnalité vedette. Les terminaux en arrière-plan notifient désormais automatiquement les agents lorsque les commandes se terminent, y compris le code de sortie et la sortie du terminal. Les invites de saisie dans les terminaux en arrière-plan sont également détectées et présentées à l’utilisateur.

Pourquoi est-ce important ? Si vous avez utilisé le mode agent de Copilot pour exécuter des commandes de build ou des suites de tests en arrière-plan, vous connaissez la frustration du “est-ce que c’est fini ?” — les terminaux en arrière-plan étaient essentiellement du fire-and-forget. Maintenant l’agent est notifié quand votre dotnet build ou dotnet test se termine, voit la sortie et peut réagir en conséquence. C’est un petit changement qui rend les workflows pilotés par les agents nettement plus fiables.

Il y a aussi un nouvel outil send_to_terminal qui permet aux agents d’envoyer des commandes aux terminaux en arrière-plan avec confirmation de l’utilisateur, corrigeant le problème où run_in_terminal avec un timeout déplaçait les terminaux en arrière-plan et les rendait en lecture seule.

Hébergement d’agents distants via SSH

VS Code prend désormais en charge la connexion à des machines distantes via SSH, en installant automatiquement le CLI et en le démarrant en mode hôte d’agents. Cela signifie que vos sessions d’agents IA peuvent cibler directement des environnements distants — utile pour les développeurs .NET qui compilent et testent sur des serveurs Linux ou des VMs cloud.

Suivi des modifications dans les sessions d’agents

Les modifications de fichiers effectuées pendant les sessions d’agents sont désormais suivies et restaurées, avec des diffs, annuler/rétablir et restauration d’état. Si un agent modifie votre code et que quelque chose tourne mal, vous pouvez voir exactement ce qui a changé et le reverter. La tranquillité d’esprit pour laisser les agents modifier votre codebase.

Reconnaissance des onglets du navigateur et autres améliorations

Quelques ajouts supplémentaires de qualité de vie :

Suivi des onglets du navigateur — le chat peut désormais suivre et lier les onglets du navigateur ouverts pendant une session, pour que les agents puissent référencer les pages web que vous consultez
Collage de fichiers dans le terminal — collez des fichiers (y compris des images) dans le terminal avec Ctrl+V, glisser-déposer ou clic droit
Couverture de tests dans la minimap — les indicateurs de couverture de tests s’affichent désormais dans la minimap pour un aperçu visuel rapide
Pinch-to-zoom sur Mac — le navigateur intégré prend en charge les gestes de pinch-to-zoom
Droits Copilot dans les Sessions — la barre d’état affiche les informations d’utilisation dans la vue Sessions
Favicon dans Aller au Fichier — les pages web ouvertes affichent des favicons dans la liste de sélection rapide

Pour conclure

VS Code 1.115 est une version incrémentale, mais les améliorations des agents — notifications de terminal en arrière-plan, hébergement d’agents SSH et suivi des modifications — contribuent à une expérience nettement plus fluide pour le développement assisté par IA. Si vous utilisez le mode agent de Copilot pour des projets .NET, ce sont le genre d’améliorations de qualité de vie qui réduisent les frictions au quotidien.

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

Aspire 13.2 embarque une CLI de documentation — et votre agent IA peut l'utiliser aussi

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

Vous connaissez ce moment où vous êtes plongé dans un Aspire AppHost, en train de câbler des intégrations, et vous devez vérifier exactement quels paramètres l’intégration Redis attend ? Vous faites alt-tab vers votre navigateur, vous cherchez sur aspire.dev, vous plissez les yeux sur les docs de l’API, puis vous revenez à votre éditeur. Contexte perdu. Flow brisé.

Aspire 13.2 vient de livrer une solution à ça. La CLI aspire docs vous permet de rechercher, parcourir et lire la documentation officielle d’Aspire directement depuis votre terminal. Et comme elle s’appuie sur des services réutilisables, les agents IA et les skills peuvent utiliser les mêmes commandes pour consulter la doc au lieu d’halluciner des APIs qui n’existent pas.

Le problème que ça résout vraiment

David Pine le dit parfaitement dans le post original : les agents IA étaient catastrophiques pour aider les développeurs à construire des apps Aspire. Ils recommandaient dotnet run au lieu de aspire run, référençaient learn.microsoft.com pour des docs qui se trouvent sur aspire.dev, suggéraient des packages NuGet obsolètes, et — mon préféré — hallucinaient des APIs inexistantes.

Pourquoi ? Parce qu’Aspire a été spécifique à .NET bien plus longtemps qu’il n’est polyglotte, et les LLMs travaillent avec des données d’entraînement qui précèdent les dernières fonctionnalités. Quand vous donnez à un agent IA la capacité de consulter les docs actuels, il arrête de deviner et commence à être utile.

Trois commandes, zéro onglet de navigateur

La CLI est d’une simplicité rafraîchissante :

Lister toute la documentation

aspire docs list

Retourne chaque page de documentation disponible sur aspire.dev. Besoin d’une sortie lisible par une machine ? Ajoutez --format Json.

Rechercher un sujet

aspire docs search "redis"

Recherche à la fois dans les titres et le contenu avec un score de pertinence pondéré. Le même moteur de recherche qui alimente les outils de documentation en interne. Vous obtenez des résultats classés avec titres, slugs et scores de pertinence.

Lire une page complète (ou juste une section)

aspire docs get redis-integration

Envoie la page complète en markdown dans votre terminal. Besoin d’une seule section ?

aspire docs get redis-integration --section "Add Redis resource"

Précision chirurgicale. Pas besoin de scroller 500 lignes. Juste la partie dont vous avez besoin.

L’angle agent IA

C’est là que ça devient intéressant pour nous, développeurs qui construisons avec des outils IA. Les mêmes commandes aspire docs fonctionnent comme outils pour les agents IA — via des skills, des serveurs MCP, ou de simples wrappers CLI.

Au lieu que votre assistant IA invente des APIs Aspire basées sur des données d’entraînement obsolètes, il peut appeler aspire docs search "postgres", trouver les docs d’intégration officiels, lire la bonne page, et vous donner l’approche documentée. De la documentation en temps réel et à jour — pas ce que le modèle a mémorisé il y a six mois.

L’architecture derrière tout ça est intentionnelle. L’équipe Aspire a construit des services réutilisables (IDocsIndexService, IDocsSearchService, IDocsFetcher, IDocsCache) plutôt qu’une intégration ponctuelle. Cela signifie que le même moteur de recherche fonctionne pour les humains dans le terminal, les agents IA dans votre éditeur, et l’automatisation dans votre pipeline CI.

Scénarios concrets

Consultations rapides dans le terminal : Vous êtes trois fichiers en profondeur et vous avez besoin des paramètres de configuration Redis. Deux commandes, quatre-vingt-dix secondes, retour au travail :

aspire docs search "redis" --limit 1
aspire docs get redis-integration --section "Configuration"

Développement assisté par IA : Votre skill VS Code encapsule les commandes CLI. Vous demandez « Ajoute une base de données PostgreSQL à mon AppHost » et l’agent consulte les vrais docs avant de répondre. Pas d’hallucinations.

Validation CI/CD : Votre pipeline valide les configurations AppHost contre la documentation officielle de manière programmatique. La sortie --format Json se connecte proprement à jq et d’autres outils.

Bases de connaissances personnalisées : Vous construisez vos propres outils IA ? Envoyez la sortie JSON structurée directement dans votre base de connaissances :

aspire docs search "monitoring" --format Json | jq '[.[] | {slug, title, summary}]'

Pas de web scraping. Pas de clés API. Les mêmes données structurées utilisées en interne par les outils de documentation.

La documentation est toujours à jour

C’est la partie que j’apprécie le plus. La CLI ne télécharge pas un snapshot — elle interroge aspire.dev avec un cache basé sur les ETags. Dès que la documentation est mise à jour, votre CLI et tout skill construit dessus le reflète. Pas de copies obsolètes, pas de moments « mais le wiki disait… ».

Pour conclure

aspire docs est une de ces petites fonctionnalités qui résout un vrai problème proprement. Les humains obtiennent un accès à la documentation natif au terminal. Les agents IA obtiennent un moyen d’arrêter de deviner et de commencer à référencer de vrais docs. Et tout est soutenu par la même source de vérité.

Si vous construisez avec .NET Aspire et n’avez pas encore essayé la CLI, lancez aspire docs search "votre-sujet-ici" et voyez comment ça se passe. Ensuite, envisagez d’intégrer ces commandes dans votre skill IA ou votre configuration d’automatisation — vos agents vous remercieront.

Consultez l’analyse approfondie de David Pine sur la construction des outils de documentation, et la référence officielle de la CLI pour tous les détails.

Microsoft Agent Framework Atteint la 1.0 — Voici Ce Qui Compte Vraiment pour les Développeurs .NET

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

Si vous avez suivi le parcours d’Agent Framework depuis les premiers jours de Semantic Kernel et AutoGen, celui-ci est significatif. Microsoft Agent Framework vient d’atteindre la version 1.0 — prêt pour la production, APIs stables, engagement de support à long terme. Il est disponible pour .NET et Python, et il est véritablement prêt pour les charges de travail réelles.

Laissez-moi couper à travers le bruit de l’annonce et me concentrer sur ce qui compte si vous construisez des applications alimentées par l’IA avec .NET.

La version courte

Agent Framework 1.0 unifie ce qui était auparavant Semantic Kernel et AutoGen en un seul SDK open source. Une abstraction d’agent. Un moteur d’orchestration. Plusieurs fournisseurs d’IA. Si vous avez jonglé entre Semantic Kernel pour les patterns entreprise et AutoGen pour les workflows multi-agent de niveau recherche, vous pouvez arrêter. C’est le seul SDK maintenant.

Démarrer est presque injustement simple

Voici un agent fonctionnel en .NET :

// dotnet add package Microsoft.Agents.AI.OpenAI --prerelease
using Microsoft.Agents.AI;
using Microsoft.Agents.AI.Foundry;
using Azure.Identity;

var agent = new AIProjectClient(endpoint: "https://your-project.services.ai.azure.com")
 .GetResponsesClient("gpt-5.3")
 .AsAIAgent(
 name: "HaikuBot",
 instructions: "You are an upbeat assistant that writes beautifully."
 );

Console.WriteLine(await agent.RunAsync("Write a haiku about shipping 1.0."));

C’est tout. Une poignée de lignes et vous avez un agent IA qui tourne contre Azure Foundry. L’équivalent Python est tout aussi concis. Ajoutez des outils de fonctions, des conversations multi-tours et du streaming au fur et à mesure — la surface de l’API monte en puissance sans devenir bizarre.

Orchestration multi-agent — c’est du sérieux

Les agents individuels sont bien pour les démos, mais les scénarios de production nécessitent généralement de la coordination. Agent Framework 1.0 est livré avec des patterns d’orchestration éprouvés au combat directement de Microsoft Research et AutoGen :

Séquentiel — les agents traitent dans l’ordre (rédacteur → réviseur → éditeur)
Concurrent — distribue vers plusieurs agents en parallèle, converge les résultats
Handoff — un agent délègue à un autre basé sur l’intention
Chat de groupe — plusieurs agents discutent et convergent vers une solution
Magentic-One — le pattern multi-agent de niveau recherche de MSR

Tous supportent le streaming, le checkpointing, les approbations humain-dans-la-boucle, et la pause/reprise. La partie checkpointing est cruciale — les workflows de longue durée survivent aux redémarrages de processus. Pour nous, développeurs .NET qui avons construit des workflows durables avec Azure Functions, ça nous parle.

Les fonctionnalités qui comptent le plus

Voici ma liste de ce qui vaut la peine d’être connu :

Hooks middleware. Vous savez comment ASP.NET Core a des pipelines middleware ? Même concept, mais pour l’exécution des agents. Interceptez chaque étape — ajoutez la sécurité du contenu, le logging, les politiques de conformité — sans toucher aux prompts de l’agent. C’est comme ça que vous rendez les agents prêts pour l’entreprise.

Mémoire pluggable. Historique conversationnel, état persistant clé-valeur, récupération basée sur les vecteurs. Choisissez votre backend : Foundry Agent Service, Mem0, Redis, Neo4j, ou créez le vôtre. La mémoire est ce qui transforme un appel LLM sans état en un agent qui se souvient réellement du contexte.

Agents YAML déclaratifs. Définissez les instructions de votre agent, ses outils, sa mémoire et sa topologie d’orchestration dans des fichiers YAML versionnés. Chargez et exécutez avec un seul appel API. C’est un changement de donne pour les équipes qui veulent itérer sur le comportement de l’agent sans redéployer du code.

Support A2A et MCP. MCP (Model Context Protocol) permet aux agents de découvrir et d’invoquer des outils externes dynamiquement. A2A (protocole Agent-to-Agent) permet la collaboration inter-runtime — vos agents .NET peuvent se coordonner avec des agents s’exécutant dans d’autres frameworks. Le support A2A 1.0 arrive bientôt.

Les fonctionnalités en preview à surveiller

Certaines fonctionnalités ont été livrées en preview dans la 1.0 — fonctionnelles mais les APIs peuvent évoluer :

DevUI — un débogueur local basé navigateur pour visualiser l’exécution de l’agent, les flux de messages et les appels d’outils en temps réel. Pensez Application Insights, mais pour le raisonnement de l’agent.
GitHub Copilot SDK et Claude Code SDK — utilisez Copilot ou Claude comme harness d’agent directement depuis votre code d’orchestration. Composez un agent capable de coder aux côtés de vos autres agents dans le même workflow.
Agent Harness — un runtime local personnalisable donnant aux agents l’accès au shell, au système de fichiers et aux boucles de messagerie. Pensez agents de codage et patterns d’automatisation.
Skills — des packages de capacités de domaine réutilisables qui donnent aux agents des capacités structurées prêtes à l’emploi.

Migration depuis Semantic Kernel ou AutoGen

Si vous avez du code Semantic Kernel ou AutoGen existant, il existe des assistants de migration dédiés qui analysent votre code et génèrent des plans de migration étape par étape. Le guide de migration Semantic Kernel et le guide de migration AutoGen vous accompagnent à travers tout.

Si vous étiez sur les packages RC, la mise à niveau vers 1.0 est juste un changement de version.

Pour conclure

Agent Framework 1.0 est le jalon de production que les équipes entreprise attendaient. APIs stables, support multi-fournisseur, patterns d’orchestration qui fonctionnent réellement à l’échelle, et des chemins de migration depuis Semantic Kernel et AutoGen.

Le framework est entièrement open source sur GitHub, et vous pouvez commencer dès aujourd’hui avec dotnet add package Microsoft.Agents.AI. Consultez le guide de démarrage rapide et les exemples pour mettre les mains dans le cambouis.

Si vous attendiez le signal « utilisable en production en toute sécurité » — c’est celui-ci.

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.

La mise à jour de mars de Visual Studio permet de créer des agents Copilot personnalisés — et find_symbol est révolutionnaire

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

Visual Studio vient de recevoir sa mise à jour Copilot la plus significative. Mark Downie a annoncé la version de mars, et le titre principal concerne les agents personnalisés — mais honnêtement, l’outil find_symbol pourrait être la fonctionnalité qui change le plus votre workflow.

Agents Copilot personnalisés dans votre repo

Envie que Copilot suive les standards de code de votre équipe ? Les agents personnalisés sont définis comme des fichiers .agent.md dans .github/agents/. Chaque agent a un accès complet au workspace, à la compréhension du code, aux outils, votre modèle préféré et aux connexions MCP.

Agent skills : packs d’instructions réutilisables

Les skills sont chargés automatiquement depuis .github/skills/ dans votre repo ou ~/.copilot/skills/ dans votre profil.

Le nouvel outil find_symbol donne au mode agent de Copilot une navigation de symboles basée sur les services de langage. Au lieu de chercher du texte, l’agent peut trouver toutes les références d’un symbole et accéder aux informations de type et de portée.

Pour les développeurs .NET, c’est une amélioration massive — les bases de code C# avec des hiérarchies de types profondes en bénéficient énormément.

Profiler des tests avec Copilot

Il y a un nouveau Profile with Copilot dans le menu contextuel du Test Explorer. Le Profiling Agent exécute le test et analyse automatiquement les performances.

Perf tips pendant le débogage en direct

L’optimisation des performances se fait maintenant pendant le débogage. Visual Studio affiche le temps d’exécution inline. Ligne lente ? Cliquez sur le Perf Tip et demandez à Copilot des suggestions.

Corriger les vulnérabilités NuGet depuis Solution Explorer

Un lien Fix with GitHub Copilot apparaît directement dans Solution Explorer quand une vulnérabilité est détectée.

Pour conclure

Les agents personnalisés et les skills font le titre, mais find_symbol est la pépite cachée — il change fondamentalement la précision de Copilot lors du refactoring de code .NET. Téléchargez Visual Studio 2026 Insiders pour tout essayer.

Le Dashboard d'Aspire 13.2 a maintenant une API de télémétrie — et ça change tout

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

Si vous développez des applications distribuées avec .NET Aspire, vous savez déjà que le dashboard est la meilleure chose de toute l’expérience. Toutes vos traces, logs et métriques au même endroit — pas de Jaeger externe, pas de configuration Seq, pas de moments « laissez-moi vérifier l’autre terminal ».

Aspire 13.2 vient de considérablement améliorer les choses. James Newton-King a annoncé la mise à jour, et honnêtement ? Les fonctionnalités d’export de télémétrie et l’API justifient à elles seules la mise à niveau.

Exporter la télémétrie comme une personne normale

Voici le scénario qu’on a tous vécu : vous déboguez un problème distribué, vous le reproduisez enfin après vingt minutes de configuration, et maintenant vous devez partager ce qui s’est passé avec votre équipe. Avant ? Des captures d’écran. Du copier-coller d’identifiants de traces. Le bazar habituel.

Aspire 13.2 ajoute un dialogue Gérer les logs et la télémétrie où vous pouvez :

Effacer toute la télémétrie (utile avant une tentative de reproduction)
Exporter la télémétrie sélectionnée dans un fichier ZIP au format standard OTLP/JSON
Ré-importer ce ZIP dans n’importe quel dashboard Aspire ultérieurement

Ce dernier point est la fonctionnalité phare. Vous reproduisez un bug, exportez la télémétrie, l’attachez à votre work item, et votre collègue peut l’importer dans son propre dashboard pour voir exactement ce que vous avez vu. Fini le « tu peux reproduire sur ta machine ? »

Les traces, spans et logs individuels ont aussi une option « Export JSON » dans leurs menus contextuels. Besoin de partager une trace spécifique ? Clic droit, copier le JSON, coller dans la description de votre PR. Terminé.

L’API de télémétrie est le vrai changement majeur

C’est ce qui m’enthousiasme le plus. Le dashboard expose maintenant une API HTTP sous /api/telemetry pour interroger les données de télémétrie programmatiquement. Endpoints disponibles :

GET /api/telemetry/resources — lister les ressources avec télémétrie
GET /api/telemetry/spans — interroger les spans avec des filtres
GET /api/telemetry/logs — interroger les logs avec des filtres
GET /api/telemetry/traces — lister les traces
GET /api/telemetry/traces/{traceId} — obtenir tous les spans d’une trace spécifique

Tout revient au format OTLP JSON. Cela alimente les nouvelles commandes CLI aspire agent mcp et aspire otel, mais l’implication réelle est plus grande : vous pouvez maintenant construire des outils, scripts et intégrations d’agents IA qui interrogent directement la télémétrie de votre app.

Imaginez un agent IA de codage qui peut voir vos traces distribuées réelles pendant le débogage. Ce n’est plus hypothétique — c’est ce que cette API permet.

La télémétrie GenAI devient pratique

Si vous construisez des apps alimentées par l’IA avec Semantic Kernel ou Microsoft.Extensions.AI, vous apprécierez le visualiseur de télémétrie GenAI amélioré. Aspire 13.2 ajoute :

Les descriptions d’outils IA rendues en Markdown
Un bouton GenAI dédié sur la page des traces pour un accès rapide
Une meilleure gestion des erreurs pour le JSON GenAI tronqué ou non standard
Une navigation click-to-highlight entre les définitions d’outils

L’article mentionne que VS Code Copilot chat, Copilot CLI et OpenCode supportent tous la configuration d’un OTEL_EXPORTER_OTLP_ENDPOINT. Pointez-les vers le dashboard Aspire et vous pouvez littéralement regarder vos agents IA réfléchir en temps réel via la télémétrie. C’est une expérience de débogage que vous ne trouverez nulle part ailleurs.

Pour conclure

Aspire 13.2 transforme le dashboard d’une « jolie UI de débogage » en « plateforme d’observabilité programmable ». Le workflow d’export/import seul fait gagner du temps réel en débogage distribué, et l’API de télémétrie ouvre la porte au diagnostic assisté par IA.

Si vous êtes déjà sur Aspire, mettez à jour. Sinon — c’est une bonne raison de découvrir aspire.dev.

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.

VS Code 1.112 : Ce qui devrait vraiment intéresser les développeurs .NET

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

VS Code 1.112 vient d’atterrir, et honnêtement ? Celui-ci frappe différemment si vous passez vos journées dans le monde .NET. Il y a beaucoup dans les notes de version officielles, mais laissez-moi vous épargner du défilement et me concentrer sur ce qui nous importe vraiment.

Copilot CLI est devenu bien plus utile

Le grand thème de cette version est l’autonomie de l’agent — donner à Copilot plus de liberté pour faire son travail sans que vous surveilliez chaque étape.

Direction et file d’attente de messages

Vous connaissez ce moment où Copilot CLI est à mi-chemin d’une tâche et vous réalisez que vous avez oublié de mentionner quelque chose ? Avant, vous deviez attendre. Maintenant vous pouvez envoyer des messages pendant qu’une requête est encore en cours — soit pour diriger la réponse actuelle, soit pour mettre en file d’attente des instructions de suivi.

C’est énorme pour ces tâches de scaffolding dotnet plus longues où vous regardez Copilot configurer un projet et pensez “oh attends, j’ai aussi besoin de MassTransit là-dedans.”

Niveaux de permissions

C’est celui qui m’excite le plus. Les sessions Copilot CLI supportent maintenant trois niveaux de permissions :

Permissions par défaut — le flux habituel où les outils demandent confirmation avant d’exécuter
Contourner les approbations — auto-approuve tout et réessaie en cas d’erreur
Autopilote — entièrement autonome : approuve les outils, répond à ses propres questions et continue jusqu’à ce que la tâche soit terminée

Si vous faites quelque chose comme créer une nouvelle API ASP.NET Core avec Entity Framework, des migrations et un setup Docker — le mode Autopilote signifie que vous décrivez ce que vous voulez et allez chercher un café. Il se débrouillera.

Vous pouvez activer l’Autopilote avec le paramètre chat.autopilot.enabled.

Prévisualiser les changements avant délégation

Quand vous déléguez une tâche à Copilot CLI, il crée un worktree. Avant, si vous aviez des changements non commités, vous deviez vérifier le Contrôle de Source pour voir ce qui serait affecté. Maintenant la vue Chat affiche les changements en attente juste là avant que vous décidiez de les copier, déplacer ou ignorer.

Petit détail, mais ça vous évite ce moment “attends, qu’est-ce que j’avais en staging ?”

Déboguez les apps web sans quitter VS Code

Le navigateur intégré supporte maintenant le débogage complet. Vous pouvez placer des breakpoints, parcourir le code pas à pas et inspecter les variables — le tout dans VS Code. Plus besoin de basculer vers Edge DevTools.

Il y a un nouveau type de débogage editor-browser, et si vous avez déjà des configurations de lancement msedge ou chrome, migrer est aussi simple que changer le champ type dans votre launch.json :

{
 "type": "editor-browser",
 "request": "launch",
 "name": "Debug Blazor App",
 "url": "https://localhost:5001"
}

Pour les développeurs Blazor, c’est un game changer. Vous exécutez déjà dotnet watch dans le terminal — maintenant votre débogage reste dans la même fenêtre aussi.

Le navigateur a aussi obtenu des niveaux de zoom indépendants (enfin), des menus contextuels avec clic droit appropriés, et le zoom est mémorisé par site web.

Sandboxing des serveurs MCP

Ceci importe plus que vous ne le pensez. Si vous utilisez des serveurs MCP — peut-être que vous en avez configuré un personnalisé pour vos ressources Azure ou vos requêtes de base de données — ils fonctionnaient avec les mêmes permissions que votre processus VS Code. Ça signifie un accès total à votre système de fichiers, réseau, tout.

Maintenant vous pouvez les sandboxer. Dans votre mcp.json :

{
 "servers": {
 "my-azure-tools": {
 "command": "node",
 "args": ["./mcp-server.js"],
 "sandboxEnabled": true
 }
 }
}

Quand un serveur sandboxé a besoin d’accéder à quelque chose qu’il n’a pas, VS Code vous demande d’accorder la permission. Bien mieux que l’approche “espérons que personne ne fait rien de bizarre”.

Découverte des personnalisations en monorepo

Si vous travaillez dans un monorepo (et soyons honnêtes, beaucoup de solutions .NET d’entreprise finissent par en être un), ça résout un vrai point douloureux.

Avant, si vous ouvriez un sous-dossier de votre repo, VS Code ne trouvait pas votre copilot-instructions.md, AGENTS.md ou vos skills personnalisés situés à la racine du dépôt. Maintenant avec le paramètre chat.useCustomizationsInParentRepositories, il remonte jusqu’à la racine .git et découvre tout.

Ça signifie que votre équipe peut partager des instructions d’agent, des fichiers de prompt et des outils personnalisés entre tous les projets dans un monorepo sans que tout le monde ait à ouvrir le dossier racine.

/troubleshoot pour le débogage d’agents

Vous avez déjà configuré des instructions personnalisées ou des skills et vous vous êtes demandé pourquoi ils ne sont pas détectés ? Le nouveau skill /troubleshoot lit les logs de débogage de l’agent et vous dit ce qui s’est passé — quels outils ont été utilisés ou ignorés, pourquoi les instructions n’ont pas chargé, et ce qui cause des réponses lentes.

Activez-le avec :

{
 "github.copilot.chat.agentDebugLog.enabled": true,
 "github.copilot.chat.agentDebugLog.fileLogging.enabled": true
}

Puis tapez simplement /troubleshoot why is my custom skill not loading? dans le chat.

Vous pouvez aussi exporter et importer ces logs de débogage maintenant, ce qui est super pour les partager avec votre équipe quand quelque chose ne fonctionne pas comme prévu.

Support des fichiers image et binaires

Les agents peuvent maintenant lire les fichiers image depuis le disque et les fichiers binaires nativement. Les fichiers binaires sont présentés au format hexdump, et les sorties image (comme les captures d’écran du navigateur intégré) s’affichent dans une vue carrousel.

Pour les développeurs .NET, pensez : collez une capture d’écran d’un bug UI dans le chat et laissez l’agent comprendre ce qui ne va pas, ou faites-lui analyser la sortie du rendu d’un composant Blazor.

Références de symboles automatiques

Petite amélioration de qualité de vie : quand vous copiez un nom de symbole (une classe, méthode, etc.) et le collez dans le chat, VS Code le convertit maintenant automatiquement en une référence #sym:Name. Ça donne à l’agent le contexte complet sur ce symbole sans que vous ayez à l’ajouter manuellement.

Si vous voulez du texte brut à la place, utilisez Ctrl+Shift+V.

Les plugins peuvent maintenant être activés/désactivés

Avant, désactiver un serveur MCP ou un plugin signifiait le désinstaller. Maintenant vous pouvez les activer et désactiver — globalement et par workspace. Clic droit dans la vue Extensions ou la vue Personnalisations et c’est fait.

Les plugins de npm et pypi peuvent aussi se mettre à jour automatiquement maintenant, bien qu’ils demanderont une approbation d’abord puisque les mises à jour signifient exécuter du nouveau code sur votre machine.

Pour conclure

VS Code 1.112 pousse clairement fort sur l’expérience agent — plus d’autonomie, meilleur débogage, sécurité plus serrée. Pour les développeurs .NET, le débogage du navigateur intégré et les améliorations de Copilot CLI sont les fonctionnalités phares.

Si vous n’avez pas encore essayé de lancer une session Copilot CLI complète en mode Autopilote pour un projet .NET, cette version est un bon moment pour commencer. N’oubliez pas de configurer vos permissions et laissez mijoter.

Télécharger VS Code 1.112 ou mettre à jour depuis VS Code via Aide > Vérifier les mises à jour.

Ai | The .NET Blog

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

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

Ce que SQL MCP Server résout réellement

La bonne question

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

Le Modèle Handoff : Quand Un Agent Ne Suffit Pas

Comment Fonctionne Handoff

Un Exemple Minimal

Quand Utiliser Handoff (et Quand Ne Pas Le Faire)

Arêtes Arrière et Humain-dans-la-Boucle

Conclusion

Workflows Durables dans Microsoft Agent Framework : De In-Memory à Azure Functions

Les Blocs de Construction Fondamentaux

Le Runner In-Memory pour le Développement Local

Ajouter la Durabilité avec Durable Task

Hébergement Azure Functions

Pourquoi C’est Important

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

Créer des Agents, C'est la Partie Facile — Les Exécuter en Toute Sécurité, C'est la Partie Difficile

Ce Que Chaque Projet Fait Vraiment

S’intégrer, C’est Juste Ajouter un Middleware

Ce Que Vous Obtenez

Cinq Scénarios Industriels

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

Azure SQL Peut Maintenant Générer des Embeddings — En T-SQL Pur, Sans Couche Applicative

Ce Qu’elles Font

Le Flux de Travail Complet

Formats d’API et Options Supportés

Ce Que Cela Permet pour les Applications .NET

Conclusion

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

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

Créer une application de conférence IA avec la pile composable de .NET

Ce que fait ConferencePulse

Microsoft.Extensions.AI : une abstraction pour tout

Pipeline DataIngestion

VectorData : recherche indépendante du fournisseur

MCP : contenu de session comme outils

Agent Framework : résumé multi-agents en parallèle

Le principe de conception

Microsoft Agent Framework Partie 3 : Des outils aux workflows — Les blocs s'emboîtent

Ce qu’est vraiment un agent (vs. un chatbot)

Le Flux de Déploiement avec `azd`