Azure SDK | The .NET Blog

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

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

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

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

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

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

Qu’est-ce qu’un MCP Bundle ?

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

Comment l’installer

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

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

2. Installez dans Claude Desktop

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

3. Authentifiez-vous auprès d’Azure

az login

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

Ce que vous pouvez faire avec

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

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

Pour commencer

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

Consultez le post complet.

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

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

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

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

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

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

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

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

Nouvelles Bibliothèques de Provisioning pour .NET

Conclusion

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

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.

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.