Devops | The .NET Blog

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.

Mises à jour d'Azure Developer CLI (azd) pour avril 2026

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

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

Azure Developer CLI (azd) a publié cinq versions en avril 2026 (de 1.23.14 à 1.24.2), avec pour grand thème les hooks qui s’exécutent désormais en Python, JavaScript, TypeScript et .NET — et pas seulement en Bash et PowerShell.

Hooks multi-langages dans azure.yaml

Les hooks peuvent désormais pointer vers des fichiers .py, .js, .ts ou .cs en plus des scripts shell. Chaque langage bénéficie d’une résolution automatique des dépendances :

Python — détecte requirements.txt ou pyproject.toml, crée un virtualenv et installe les dépendances avant l’exécution. Configurez le nom de l’environnement avec virtualEnvName.
JavaScript / TypeScript — détecte package.json et exécute npm install automatiquement. TypeScript s’exécute via npx tsx sans étape de compilation. Choisissez votre gestionnaire de paquets avec le bloc de configuration packageManager.
.NET — exécute les fichiers .cs avec dotnet run. Les scripts single-file sont pris en charge sur .NET 10+. Configurez le framework cible via le bloc configuration/framework.

Cela signifie que les équipes travaillant déjà dans l’un de ces langages n’ont plus besoin de maintenir un hook Bash ou PowerShell séparé juste pour connecter les événements du cycle de vie du provisionnement.

azd update passe en préversion publique

azd update est désormais en préversion publique sur toutes les plateformes. Une seule commande gère la mise à jour quelle que soit la façon dont azd a été installé initialement — plus besoin de gérer séparément les chemins Homebrew, WinGet ou MSI.

Mode non interactif via AZD_NON_INTERACTIVE

La définition de AZD_NON_INTERACTIVE=true (ou l’utilisation de --non-interactive / --no-prompt) produit désormais des échecs cohérents et déterministes dans les pipelines CI/CD lorsqu’une entrée requise ne peut pas être résolue automatiquement. Auparavant, le comportement était incohérent selon les commandes.

Vérification préalable du quota des modèles IA

azd provision valide le quota Azure Cognitive Services avant de tenter de provisionner des ressources de modèles IA. Les déploiements qui échoueraient en raison de limites de quota affichent désormais l’erreur tôt dans le processus plutôt qu’à mi-chemin du provisionnement.

« Corriger cette erreur » dans le dépannage Copilot

L’intégration de dépannage Copilot dans azd gagne la capacité d’appliquer directement un correctif suggéré — pas seulement de le décrire. Lorsque l’agent identifie un problème corrigeable, il peut effectuer le changement sur place.

Fournisseurs de provisionnement personnalisés et résolveur de secrets Key Vault

Les auteurs d’extensions peuvent désormais enregistrer des backends d’infrastructure alternatifs avec WithProvisioningProvider(). Par ailleurs, azd résout automatiquement les références @Microsoft.KeyVault(...) avant de transmettre la configuration aux extensions, supprimant la nécessité d’une résolution manuelle des secrets dans les fournisseurs personnalisés.

Exclusions pour les modèles et le mode watch

Deux nouveaux fichiers d’exclusion offrent un contrôle plus fin sur la gestion des fichiers :

.azdignore — exclut les fichiers réservés aux contributeurs (documentation, configurations CI) des copies de modèles pour que les utilisateurs finaux obtiennent un projet propre.
.azdxignore — exclut les répertoires du déclenchement de reconstructions pendant azd x watch, réduisant le bruit lors du développement itératif.

Vérification préalable des noms réservés et option docker.network

azd avertit désormais lorsque les noms de ressources prévus contiendraient des mots réservés Azure (MICROSOFT, WINDOWS ou le préfixe LOGIN) avant le début du provisionnement. Une nouvelle option docker.network passe --network à docker build, utile dans les environnements de proxy d’entreprise qui nécessitent un réseau Docker spécifique.

Correctifs de sécurité

Le paquet MSI Windows inclut désormais la vérification de signature de code. Un correctif distinct ferme une fuite de variable d’environnement qui pouvait exposer des valeurs entre les limites des commandes d’extension.

Un mois chargé — le support des hooks multi-langages en particulier supprime un vrai point de friction pour les équipes qui ne travaillent pas principalement en Bash. Consultez les notes de version complètes pour le changelog complet des cinq versions.

Azure DevOps Server Patch Avril 2026 — Correction du Complétion de PR et Mises à Jour de Sécurité

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

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

Petit rappel pour les équipes qui hébergent leur propre Azure DevOps Server : Microsoft a publié le Patch 3 d’avril 2026 avec trois correctifs ciblés.

Ce qui a été corrigé

Échecs de complétion des pull requests — une exception de référence nulle lors de l’auto-complétion des work items pouvait faire échouer les merges de PR. Si vous avez rencontré des erreurs aléatoires lors de la complétion de PR, c’est probablement la cause
Validation de la redirection à la déconnexion — validation améliorée lors de la déconnexion pour empêcher d’éventuelles redirections malveillantes. C’est un correctif de sécurité à appliquer rapidement
Connexions PAT vers GitHub Enterprise Server — la création de connexions par Personal Access Token vers GitHub Enterprise Server était cassée, c’est maintenant rétabli

Comment mettre à jour

Téléchargez le Patch 3 et lancez l’installateur. Pour vérifier que le patch est bien appliqué :

<patch-installer>.exe CheckInstall

Si vous utilisez Azure DevOps Server en auto-hébergement, Microsoft recommande vivement de rester sur le dernier patch pour la sécurité comme pour la fiabilité. Consultez les notes de version pour tous les détails.

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

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

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

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

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

Ce que Git-APE fait concrètement

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

Voici la mise en place :

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

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

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

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

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

Pourquoi c’est important

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

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

Le nettoyage est tout aussi simple :

@git-ape destroy my-resource-group

Mon avis

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

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

Pour conclure

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

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

Azure DevOps corrige enfin l'éditeur Markdown dont tout le monde se plaignait

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

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

Si vous utilisez Azure Boards, vous avez probablement vécu ça : vous lisez la description d’un work item, peut-être en vérifiant les critères d’acceptation, et vous double-cliquez accidentellement. Boom — vous êtes en mode édition. Vous ne vouliez rien modifier. Vous étiez en train de lire.

Dan Hellem a annoncé le correctif, et c’est un de ces changements qui semblent petits mais qui éliminent une vraie friction de votre workflow quotidien.

Ce qui a changé

L’éditeur Markdown pour les champs texte des work items s’ouvre désormais en mode aperçu par défaut. Vous pouvez lire et interagir avec le contenu — suivre les liens, vérifier le formatage — sans risquer d’entrer accidentellement en mode édition.

Quand vous voulez vraiment éditer, vous cliquez sur l’icône d’édition en haut du champ. Quand vous avez terminé, vous revenez explicitement au mode aperçu. Simple, intentionnel, prévisible.

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

Le fil de feedback communautaire était long. Le comportement de double-clic pour éditer a été introduit avec l’éditeur Markdown en juillet 2025, et les plaintes ont commencé presque immédiatement.

Pour les équipes qui font du sprint planning, du refinement ou du code review avec Azure Boards, ce type de micro-friction s’accumule.

État du déploiement

Ce changement est déjà en cours de déploiement pour un sous-ensemble de clients et s’étendra à tous dans les deux à trois prochaines semaines.

Pour conclure

Toute amélioration n’a pas besoin d’être une fonctionnalité phare. Parfois la meilleure mise à jour consiste simplement à supprimer quelque chose d’agaçant. C’est exactement ça — un petit correctif UX qui rend Azure Boards moins hostile pour les gens qui veulent juste lire leurs work items tranquillement.

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.