Azure Functions | The .NET Blog

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

Arrêtez de Pilonner une Dépendance en Difficulté : Patterns de Retry pour Azure Functions + Service Bus

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

Voici comment une panne récupérable devient une interruption dans une application Functions : une dépendance commence à générer des timeouts, chaque instance Function effectue des nouvelles tentatives immédiatement et indéfiniment, la dépendance reçoit des centaines de requêtes concurrentes échouées, et ce qui a commencé comme un problème transitoire se transforme en un événement de contre-pression à l’échelle du système.

Vous connaissez probablement cette histoire. Azure Functions scale rapidement — c’est tout le principe. Mais “scaler rapidement” et “réessayer immédiatement” ensemble peuvent rendre les défaillances dramatiquement pires.

Deux patterns aident. Exponential backoff et circuit breaker. Les deux sont désormais pris en charge nativement pour les Azure Functions déclenchées par Service Bus.

Deux Patterns, Rôles Différents

Ces patterns sont complémentaires, pas des alternatives :

L’exponential backoff répond à : quand devrais-je réessayer ? Il augmente le délai entre les tentatives pour qu’une dépendance ait le temps de récupérer. Au niveau du message, rythmant le timing des nouvelles tentatives.

Le circuit breaker répond à : devrais-je appeler cette dépendance en ce moment ? Il arrête les appels répétés vers une dépendance non saine après qu’un seuil d’échec est atteint, puis sonde prudemment après une période de refroidissement. Au niveau du système, prévenant les tempêtes de retry.

Vous voulez les deux. Le backoff gère le rythme des tentatives par message. Le circuit breaker gère les décisions de santé agrégées.

Pourquoi C’est Particulièrement Important pour Service Bus

La file absorbe le trafic en rafale, ce qui est bien. Mais sans contrôles, la file peut grossir pendant que les workers continuent de gaspiller des ressources de calcul sur des appels qui vont échouer. Les messages empoisonnés restent actifs plus longtemps qu’ils ne le devraient. Les partitions chaudes ou la capacité limitée en aval créent des problèmes en cascade.

Le design plus sécurisé :

Détecter la panne transitoire
Retarder la prochaine tentative avec exponential backoff
Arrêter d’appeler la dépendance quand un seuil d’échec est atteint (circuit ouvert)
Reprendre prudemment après une période de refroidissement (sonde de circuit)
Déplacer le travail irrécupérable vers dead-letter ou une voie de quarantaine

À Quoi Ressemble le Support Natif

Le nouveau support s’intègre avec le modèle d’hôte Azure Functions existant — pas de bibliothèques supplémentaires, pas d’implémentations personnalisées. La configuration va dans votre host.json :

{
 "extensions": {
 "serviceBus": {
 "messageHandlerOptions": {
 "maxRetryCount": 5,
 "retryPolicy": {
 "mode": "exponentialBackoff",
 "minBackoff": "00:00:02",
 "maxBackoff": "00:05:00",
 "maxRetryCount": 5
 }
 }
 }
 }
}

La configuration du circuit breaker définit le seuil d’échec et l’intervalle de réinitialisation pour que les dépendances non saines ne soient pas harcelées pendant la récupération.

Langages Couverts

Ce n’est pas uniquement pour .NET. La fonctionnalité couvre dotnet, JavaScript, TypeScript et Python — l’ensemble complet des langages supportés par le trigger Service Bus dans Azure Functions.

Conclusion

Les patterns de retry ne sont pas passionnants à configurer jusqu’à la première fois qu’une interruption en aval fait que vos Functions aggravent le problème au lieu de se dégrader gracieusement. Les configurer de manière proactive est peu coûteux. Les implémenter pendant un incident ne l’est pas.

Post original : Exponential backoff and circuit breaker for Service Bus-triggered Azure Functions

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

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

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

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

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

Pourquoi cette combinaison a du sens

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

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

Options d’authentification

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

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

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

Mise en place

Le flux général :

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

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

Mon avis

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

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

Pour conclure

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

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

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

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

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.