Cloud | The .NET Blog

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.

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

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

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.